Difference between revisions of "User:Shawndouglas/sandbox/sublevel3"

From LIMSWiki
Jump to navigationJump to search
 
(109 intermediate revisions by the same user not shown)
Line 1: Line 1:
[[File:Cybersecurity training (37345726182).jpg|right|450px]]In the introductory section, a cybersecurity plan was defined as a developed, distributed, reviewed, updated, and protected collection of policy and other types of components that shapes how an organization protects against and responds to cybersecurity threats. One of the more significant activities of plan development includes applying the security controls, program development, and risk management aspects of one or more cybersecurity standards frameworks for the identification of, protection from, detection of, response to, and recovery from cybersecurity threats and incidents.


The National Institute of Standards and Technology (NIST) defines a security control as "a safeguard or countermeasure prescribed for an information system or an organization designed to protect the confidentiality, integrity, and availability of its information and to meet a set of defined security requirements."<ref name="NISTSecurity19">{{cite web |url=https://csrc.nist.gov/glossary/term/security_control |title=security control |work=Computer Security Resource Center |publisher=National Institute of Standards and Technology |date=2019 |accessdate=23 July 2020}}</ref> Many, but not all, cybersecurity frameworks include a catalog of such controls, which give the implementing organization a concrete set of configurable goals to apply to their overall cybersecurity strategy. However, as mentioned in the previous section, some frameworks exist to provide a more program-based or risk-based approach to plan development. Choosing the best frameworks will likely depend on multiple factors, including the organization's industry type, the amount of technical expertise within the organization, the budget, the organizational goals, the amount of buy-in from key organizational stakeholders, and those stakeholders' preferred approach.
==The laws themselves==


Let's take a look at one NIST control in particular, from their SP 800-53 framework, which will be discussed further in the next section. Their "PL-2 System security plan" control recommends the organization develop, distribute, review, update, and protect a cybersecurity plan for its information system. Its supplemental guidance reads as follows:
===1. Federal Telecommunications Act of 1996, Section 255 ([https://www.law.cornell.edu/uscode/text/47/255 47 U.S.C. § 255 - Access by persons with disabilities])===


<blockquote>Security plans relate security requirements to a set of security controls and control enhancements. Security plans also describe, at a high level, how the security controls and control enhancements meet those security requirements, but do not provide detailed, technical descriptions of the specific design or implementation of the controls/enhancements. Security plans contain sufficient information (including the specification of parameter values for assignment and selection statements either explicitly or by reference) to enable a design and implementation that is unambiguously compliant with the intent of the plans and subsequent determinations of risk to organizational operations and assets, individuals, other organizations, and the Nation if the plan is implemented as intended.</blockquote>
<blockquote>'''(b) Manufacturing'''
A manufacturer of telecommunications equipment or customer premises equipment shall ensure that the equipment is designed, developed, and fabricated to be accessible to and usable by individuals with disabilities, if readily achievable.


This wording essentially indicates that when you make your plan, there should be a high-level connection between what the organization needs to implement in regards to cybersecurity and how to go about doing it using best practices (e.g., using framework controls and guidance). It also means that, if developed, implemented, and maintained correctly, the plan should empower the organization to have an information system that is clearly compliant with the intent and purpose of the organization's goals, operations, and risk determinations. In other words, the organization first needs a clear picture of what it wants to achieve and the risks associated with operating an information system to meet those goals before it can develop its cybersecurity plan; afterwards, cybersecurity standards frameworks and controls can assist with plan development.
'''(c) Telecommunications services'''


<blockquote>Security plans need not be single documents; the plans can be a collection of various documents including documents that already exist. Effective security plans make extensive use of references to policies, procedures, and additional documents (e.g., design and implementation specifications) where more detailed information can be obtained. This reduces the documentation requirements associated with security programs and maintains security-related information in other established management/operational areas related to enterprise architecture, system development life cycle, systems engineering, and acquisition. For example, security plans do not contain detailed contingency plan or incident response plan information but instead provide explicitly or by reference, sufficient information to define what needs to be accomplished by those plans.</blockquote>
A provider of telecommunications service shall ensure that the service is accessible to and usable by individuals with disabilities, if readily achievable.


The rest of NIST's wording indicates that a plan isn't necessarily a single, comprehensive document that attacks everything. Rather, it will make reference to other important policies and procedures that will further drive the overall success of your cybersecurity plan. You may even choose to have a separate document dedicated to the security controls you select for your organization. (Note that in the actual plan development section of this guide, recommendations for creating the additional "policies, procedures, and additional documents" you'll need will be given. Despite those recommendations, NIST's guidance still holds true: your actual plan document should make reference to them and provide sufficient description of what those external plans intend to accomplish within the scope of the cybersecurity plan. In the end, though, this decision to have one lengthy document or branched documents linked to the overall plan is a matter of organizational choice.)
'''(d) Compatibility'''
Whenever the requirements of subsections (b) and (c) are not readily achievable, such a manufacturer or provider shall ensure that the equipment or service is compatible with existing peripheral devices or specialized customer premises equipment commonly used by individuals with disabilities to achieve access, if readily achievable.</blockquote>


The takeaway from this analysis of NIST's language is that the while any standards framework you use can guide the development of a cybersecurity plan, it can't be done in a vacuum that doesn't take into account organizational goals, system and data aspects, and risk assessments. Additionally, while driven by the framework, the cybersecurity plan also doesn't need to contain every detail recommended by the framework; sometimes it's easier to have policy external to but referenced within the plan.
The term '''disability''' is [https://www.law.cornell.edu/uscode/text/42/12102 defined here]. You can read the full entry, but the basics are:


Some additional considerations and tips concerning the blending of a cybersecurity standards framework with your organization's cybersecurity plan include<ref name="NiliUnderstand14">{{cite web |url=https://corpgov.law.harvard.edu/2014/08/25/understanding-and-implementing-the-nist-cybersecurity-framework/ |title=Understanding and Implementing the NIST Cybersecurity Framework |author=Nili, T. |work=Harvard Law School Forum on Corporate Governance and Financial Regulation |publisher=Harvard |date=25 August 2014 |accessdate=23 July 2020}}</ref><ref name="NISTAnIntro19">{{cite web |url=https://www.nist.gov/cyberframework/online-learning/components-framework |title=An Introduction to the Components of the Framework |publisher=National Institute of Standards and Technology |date=08 October 2019 |accessdate=23 July 2020}}</ref><ref name="MorganHowToUse18">{{cite web |url=https://www.securitymagazine.com/blogs/14-security-blog/post/88890-how-to-use-the-nist-cybersecurity-framework |title=How to Use the NIST Cybersecurity Framework: A Conversation with NIST’s Matthew Barrett |author=Morgan, J. |work=Security |publisher=BNP Media |date=04 April 2018 |accessdate=23 July 2020}}</ref><ref name="CorneliusUnder18">{{cite web |url=https://www.linkedin.com/pulse/understanding-cybersecurity-privacy-best-practices-tom-cornelius/ |title=Understanding Cybersecurity & Privacy Best Practices |author=Cornelius, T. |work=LinkedIn Pulse |date=31 July 2018 |accessdate=23 July 2020}}</ref>:
<blockquote>'''(1) Disability''' The term “disability” means, with respect to an individual—
:'''(A)''' a physical or mental impairment that substantially limits one or more major life activities of such individual;


* After selecting one or more frameworks, ensure at a minimum that key stakeholders and related personnel are given a chance to become more familiar with the frameworks before continuing with extensive plan development.
:'''(B)''' a record of such an impairment; or
* Map cybersecurity requirements, organizational objectives, and planned process and procedure to security controls, and then compare the results to your current operating state to understand what gaps exist, if any.
* Don't be afraid to customize controls and other framework elements in order for your organization to get the maximum benefit out of them. Do keep relevant regulations affecting your organization in mind, however, when customizing.
* Think of the framework as the defining sauce or crust base of a pizza: it allows you to bake security and privacy principles into your overall cybersecurity strategy, with an end result of being more naturally prepared to address regulatory and contractual obligations.
* Don't forget to look for additional implementation resources created by the developer of the framework, e.g., from [https://www.isa.org/technical-topics/cybersecurity/cybersecurity-resources/ ISA], [https://www.sans.org/critical-security-controls/ SANS], and [https://www.cisecurity.org/controls/cis-controls-list/ CIS].
* If expertise isn't available in-house, you may want to turn to a cybersecurity services provider to assist with integrating a framework into your plan.


==References==
:'''(C)''' being regarded as having such an impairment (as described in paragraph (3)).</blockquote>
{{Reflist|colwidth=30em}}
 
The term '''readily achievable''' is [https://www.law.cornell.edu/uscode/text/42/12181 defined here]. It is defines as:
 
<blockquote>'''(9) Readily achievable''' The term “readily achievable” means easily accomplishable and able to be carried out without much difficulty or expense. In determining whether an action is readily achievable, factors to be considered include—
 
:'''(A)''' the nature and cost of the action needed under this chapter;
:'''(B)''' the overall financial resources of the facility or facilities involved in the action; the number of persons employed at such facility; the effect on expenses and resources, or the impact otherwise of such action upon the operation of the facility;
:'''(C)''' the overall financial resources of the covered entity; the overall size of the business of a covered entity with respect to the number of its employees; the number, type, and location of its facilities; and
:'''(D)''' the type of operation or operations of the covered entity, including the composition, structure, and functions of the workforce of such entity; the geographic separateness, administrative or fiscal relationship of the facility or facilities in question to the covered entity.</blockquote>
 
===2. Rehabilitation Act of 1973, Section 508, amended ([https://www.law.cornell.edu/uscode/text/29/794d 29 U.S.C. 794d] - Electronic and information technology)===
 
There's a government website dedicated to Section 508: [https://www.section508.gov/ https://www.section508.gov/] The related laws and polices can be [https://www.section508.gov/manage/laws-and-policies/ found here]. The intro states (italics emphasis mine):
 
<blockquote>In 1998, Congress amended the Rehabilitation Act of 1973 to require Federal agencies to make their electronic and information technology (EIT) accessible to people with disabilities. The law (29 U.S.C § 794 (d)) ''applies to all Federal agencies when they develop, procure, maintain, or use electronic and information technology''. Under Section 508, agencies must give ''disabled employees and members of the public'' access to information comparable to the access available to others.
 
The [https://www.access-board.gov/ U.S. Access Board] is responsible for developing Information and Communication Technology (ICT) accessibility ''standards'' to ''incorporate into regulations that govern Federal procurement practices.'' On January 18, 2017, the Access Board issued a final rule that updated accessibility requirements covered by Section 508, and refreshed guidelines for telecommunications equipment subject to Section 255 of the Communications Act. The final rule went into effect on January 18, 2018.
 
The rule updated and reorganized the Section 508 Standards and Section 255 Guidelines ''in response to market trends and innovations in technology.'' The refresh also harmonized these requirements with other guidelines and standards both in the U.S. and abroad, including standards issued by the European Commission, ''and with the World Wide Web Consortium (W3C) Web Content Accessibility Guidelines (WCAG 2.0), a globally recognized voluntary consensus standard for web content and ICT.''</blockquote>
 
In discussing ICT, the U.S. Access Board [https://www.access-board.gov/ict/#b-summary-of-key-provisions summarized the key provisions] as such:
 
<blockquote>The Revised 508 Standards and 255 Guidelines replace the current product-based regulatory approach with an approach based on ICT functions. The revised technical requirements, which are organized along the lines of ICT functionality, provide requirements to ensure that covered hardware, software, electronic content, and support documentation and services are accessible to people with disabilities. In addition, the revised requirements include functional performance criteria, which are outcome-based provisions that apply in two limited instances: when the technical requirements do not address one or more features of ICT or when evaluation of an alternative design or technology is needed under equivalent facilitation.</blockquote>
 
The full (lengthy) information about the ICT Accessibility 508 Standards and 255 Guidelines is found here: [https://www.access-board.gov/ict/ https://www.access-board.gov/ict/]
 
The specific software requirements that LabLynx will likely need to consider under Section 508 appear to be found in [https://www.access-board.gov/ict/#chapter-5-software Chapter 5: Software] and [https://www.access-board.gov/ict/#chapter-6-support-documentation-and-services Chapter 6: Support Documentation and Services]. (If for some reason LLX is in the hardware domain, they'll want to also consider[https://www.access-board.gov/ict/#chapter-4-hardware Chapter 4: Hardware] If you're curious about the underlying standards, you can find them in [https://www.access-board.gov/ict/#chapter-7-%C2%A0-referenced-standards Chapter 7: Referenced Standards].
 
Finally, the Section 508 government website has a full Design & Develop section that may be applicable to development process: [https://www.section508.gov/develop/ https://www.section508.gov/develop/]
 
==Additional information==
 
1. The Section 508 website and its glossary mention LIMS under "[https://www.section508.gov/art/glossary/#S scientific instrument]," though only secondarily. At the end: "If a scientific instrument is integrated with a computer or a monitor, the computer (and associated operating system) and the monitor would be separate EIT deliverables, requiring their own Government Product Accessibility Templates (GPAT). If the computer included application software, this software would be another EIT deliverable requiring its own GPAT."
2. It appears some software can qualify for "a legally-defined Exception (Back Office)," as found in this example with STARLIMS and the VA: [https://www.oit.va.gov/Services/TRM/ToolPage.aspx?tid=7502 https://www.oit.va.gov/Services/TRM/ToolPage.aspx?tid=7502]
 
3. Some additional posts and guides that may be revealing:
* [https://www.levelaccess.com/how-do-i-determine-if-my-web-site-or-application-is-section-508-compliant/ How do I determine if my website or application is Section 508 compliant?]
* [https://ftp.cdc.gov/pub/Software/RegistryPlus/508%20Compliance/508softwareandos.doc GSA Guide For Making Software Applications and Operating Systems Accessible] (.doc file; NOTE: No date, so not sure if incorporates amended material, so be careful)
* [https://www.dhs.gov/publication/dhs-section-508-compliance-test-processes DHS Section 508 Compliance Test Processes]

Latest revision as of 21:23, 28 February 2022

The laws themselves

1. Federal Telecommunications Act of 1996, Section 255 (47 U.S.C. § 255 - Access by persons with disabilities)

(b) Manufacturing

A manufacturer of telecommunications equipment or customer premises equipment shall ensure that the equipment is designed, developed, and fabricated to be accessible to and usable by individuals with disabilities, if readily achievable.

(c) Telecommunications services

A provider of telecommunications service shall ensure that the service is accessible to and usable by individuals with disabilities, if readily achievable.

(d) Compatibility

Whenever the requirements of subsections (b) and (c) are not readily achievable, such a manufacturer or provider shall ensure that the equipment or service is compatible with existing peripheral devices or specialized customer premises equipment commonly used by individuals with disabilities to achieve access, if readily achievable.

The term disability is defined here. You can read the full entry, but the basics are:

(1) Disability The term “disability” means, with respect to an individual—

(A) a physical or mental impairment that substantially limits one or more major life activities of such individual;
(B) a record of such an impairment; or
(C) being regarded as having such an impairment (as described in paragraph (3)).

The term readily achievable is defined here. It is defines as:

(9) Readily achievable The term “readily achievable” means easily accomplishable and able to be carried out without much difficulty or expense. In determining whether an action is readily achievable, factors to be considered include—

(A) the nature and cost of the action needed under this chapter;
(B) the overall financial resources of the facility or facilities involved in the action; the number of persons employed at such facility; the effect on expenses and resources, or the impact otherwise of such action upon the operation of the facility;
(C) the overall financial resources of the covered entity; the overall size of the business of a covered entity with respect to the number of its employees; the number, type, and location of its facilities; and
(D) the type of operation or operations of the covered entity, including the composition, structure, and functions of the workforce of such entity; the geographic separateness, administrative or fiscal relationship of the facility or facilities in question to the covered entity.

2. Rehabilitation Act of 1973, Section 508, amended (29 U.S.C. 794d - Electronic and information technology)

There's a government website dedicated to Section 508: https://www.section508.gov/ The related laws and polices can be found here. The intro states (italics emphasis mine):

In 1998, Congress amended the Rehabilitation Act of 1973 to require Federal agencies to make their electronic and information technology (EIT) accessible to people with disabilities. The law (29 U.S.C § 794 (d)) applies to all Federal agencies when they develop, procure, maintain, or use electronic and information technology. Under Section 508, agencies must give disabled employees and members of the public access to information comparable to the access available to others.

The U.S. Access Board is responsible for developing Information and Communication Technology (ICT) accessibility standards to incorporate into regulations that govern Federal procurement practices. On January 18, 2017, the Access Board issued a final rule that updated accessibility requirements covered by Section 508, and refreshed guidelines for telecommunications equipment subject to Section 255 of the Communications Act. The final rule went into effect on January 18, 2018.

The rule updated and reorganized the Section 508 Standards and Section 255 Guidelines in response to market trends and innovations in technology. The refresh also harmonized these requirements with other guidelines and standards both in the U.S. and abroad, including standards issued by the European Commission, and with the World Wide Web Consortium (W3C) Web Content Accessibility Guidelines (WCAG 2.0), a globally recognized voluntary consensus standard for web content and ICT.

In discussing ICT, the U.S. Access Board summarized the key provisions as such:

The Revised 508 Standards and 255 Guidelines replace the current product-based regulatory approach with an approach based on ICT functions. The revised technical requirements, which are organized along the lines of ICT functionality, provide requirements to ensure that covered hardware, software, electronic content, and support documentation and services are accessible to people with disabilities. In addition, the revised requirements include functional performance criteria, which are outcome-based provisions that apply in two limited instances: when the technical requirements do not address one or more features of ICT or when evaluation of an alternative design or technology is needed under equivalent facilitation.

The full (lengthy) information about the ICT Accessibility 508 Standards and 255 Guidelines is found here: https://www.access-board.gov/ict/

The specific software requirements that LabLynx will likely need to consider under Section 508 appear to be found in Chapter 5: Software and Chapter 6: Support Documentation and Services. (If for some reason LLX is in the hardware domain, they'll want to also considerChapter 4: Hardware If you're curious about the underlying standards, you can find them in Chapter 7: Referenced Standards.

Finally, the Section 508 government website has a full Design & Develop section that may be applicable to development process: https://www.section508.gov/develop/

Additional information

1. The Section 508 website and its glossary mention LIMS under "scientific instrument," though only secondarily. At the end: "If a scientific instrument is integrated with a computer or a monitor, the computer (and associated operating system) and the monitor would be separate EIT deliverables, requiring their own Government Product Accessibility Templates (GPAT). If the computer included application software, this software would be another EIT deliverable requiring its own GPAT."

2. It appears some software can qualify for "a legally-defined Exception (Back Office)," as found in this example with STARLIMS and the VA: https://www.oit.va.gov/Services/TRM/ToolPage.aspx?tid=7502

3. Some additional posts and guides that may be revealing:

Retrieved from "https://www.limswiki.org/index.php?title=User:Shawndouglas/sandbox/sublevel3&oldid=46646"