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

From LIMSWiki
Jump to navigationJump to search
 
(48 intermediate revisions by the same user not shown)
Line 1: Line 1:
====IA-1 Identification and authentication policy and procedures====
This control recommends the organization develop, document, disseminate, review, and update identification and authentication policies and procedures. It asks organizations to not only address the purpose, scope, roles, responsibilities, and enforcement of identification and authentication action but also to address how those policies and procedures will be implemented, reviewed, and updated.


'''Additional resources''':
==The laws themselves==
* [https://csrc.nist.gov/publications/detail/sp/800-12/rev-1/final NIST Special Publications 800-12, Rev. 1], pages 62–63
* [https://csrc.nist.gov/publications/detail/sp/800-63/3/final NIST Special Publications 800-63-3]
* [https://csrc.nist.gov/publications/detail/sp/800-73/4/final NIST Special Publications 800-73-4]
* [https://csrc.nist.gov/publications/detail/sp/800-76/2/final NIST Special Publications 800-76-2]
* [https://csrc.nist.gov/publications/detail/sp/800-78/4/final NIST Special Publications 800-78-4]
* [https://www.limswiki.org/index.php/LII:LIMSpec/Maintaining_Laboratory_Workflow_and_Operations#7._Document_management LIMSpec 7.1, 7.2]


====IA-2 Identification and authentication for organizational users====
===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])===
This control recommends the system be able to identify and authenticate a user or user-propagated process as a single, unique entity by using one or more mechanisms. The choice of these mechanisms will be guided by organizational policy, regulations, laws, standards, and guidance documents. According to NIST, authentication mechanisms will be based on "(i) something you know (e.g., password, personal identification number [PIN]); (ii) something you have (e.g., cryptographic identification device, token); or (iii) something you are (e.g., biometric)."


'''Additional resources''':
<blockquote>'''(b) Manufacturing'''
* [https://csrc.nist.gov/publications/detail/sp/800-63/3/final NIST Special Publications 800-63-3]
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.
* [https://csrc.nist.gov/publications/detail/sp/800-73/4/final NIST Special Publications 800-73-4]
* [https://csrc.nist.gov/publications/detail/sp/800-76/2/final NIST Special Publications 800-76-2]
* [https://csrc.nist.gov/publications/detail/sp/800-78/4/final NIST Special Publications 800-78-4]
* [https://www.limswiki.org/index.php/LII:LIMSpec/Security_and_Integrity_of_Systems_and_Operations#32._Configuration_management LIMSpec 32.25, 32.35], [https://www.limswiki.org/index.php/LII:LIMSpec/Security_and_Integrity_of_Systems_and_Operations#34._System_administration 34.4], and [https://www.limswiki.org/index.php/LII:LIMSpec/Security_and_Integrity_of_Systems_and_Operations#35._Cybersecurity 35.3]


====IA-2 (1) Identification and authentication for organizational users: Network access to privileged accounts====
'''(c) Telecommunications services'''
This control enhancement recommends the system be able to implement multifactor authentication to privileged accounts being accessed over the network. "Multifactor authentication requires the use of two or more different factors to achieve authentication." NIST defines network access as "access to organizational information systems by users (or processes acting on behalf of users) where such access is obtained through network connections (i.e., nonlocal accesses)."


'''Additional resources''':
A provider of telecommunications service shall ensure that the service is accessible to and usable by individuals with disabilities, if readily achievable.
* [https://www.limswiki.org/index.php/LII:LIMSpec/Security_and_Integrity_of_Systems_and_Operations#35._Cybersecurity LIMSpec 35.3]


====IA-2 (2) Identification and authentication for organizational users: Network access to non-privileged accounts====
'''(d) Compatibility'''
This control enhancement recommends the system be able to implement multifactor authentication to non-privileged accounts being accessed over the network. "Multifactor authentication requires the use of two or more different factors to achieve authentication." NIST defines network access as "access to organizational information systems by users (or processes acting on behalf of users) where such access is obtained through network connections (i.e., nonlocal accesses)."
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>


'''Additional resources''':
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:
* [https://www.limswiki.org/index.php/LII:LIMSpec/Security_and_Integrity_of_Systems_and_Operations#35._Cybersecurity LIMSpec 35.3]


====IA-2 (3) Identification and authentication for organizational users: Local access to privileged accounts====
<blockquote>'''(1) Disability''' The term “disability” means, with respect to an individual—
This control enhancement recommends the system be able to implement multifactor authentication to privileged accounts being accessed locally. "Multifactor authentication requires the use of two or more different factors to achieve authentication." NIST defines local access as "any access to organizational information systems by users (or processes acting on behalf of users) where such access is obtained by direct connections without the use of networks."
:'''(A)''' a physical or mental impairment that substantially limits one or more major life activities of such individual;


'''Additional resources''':
:'''(B)''' a record of such an impairment; or
* [https://www.limswiki.org/index.php/LII:LIMSpec/Security_and_Integrity_of_Systems_and_Operations#35._Cybersecurity LIMSpec 35.3]


====IA-2 (4) Identification and authentication for organizational users: Local access to non-privileged accounts====
:'''(C)''' being regarded as having such an impairment (as described in paragraph (3)).</blockquote>
This control enhancement recommends the system be able to implement multifactor authentication to non-privileged accounts being accessed locally. "Multifactor authentication requires the use of two or more different factors to achieve authentication." NIST defines local access as "any access to organizational information systems by users (or processes acting on behalf of users) where such access is obtained by direct connections without the use of networks." Note that NIST considers this a "High" baseline control; this type of authentication for non-privileged local accounts may not be required.


'''Additional resources''':
The term '''readily achievable''' is [https://www.law.cornell.edu/uscode/text/42/12181 defined here]. It is defines as:
* [https://www.limswiki.org/index.php/LII:LIMSpec/Security_and_Integrity_of_Systems_and_Operations#35._Cybersecurity LIMSpec 35.3]


====IA-2 (10) Identification and authentication for organizational users: Single sign-on====
<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—
This control enhancement recommends the system be configurable to allow, if desired, single sign-on to specified system accounts and services, such that a user can log in once and gain access to multiple system resources.


'''Additional resources''':
:'''(A)''' the nature and cost of the action needed under this chapter;
* [https://www.limswiki.org/index.php/LII:LIMSpec/Security_and_Integrity_of_Systems_and_Operations#32._Configuration_management LIMSpec 32.24]
:'''(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>


====IA-2 (12) Identification and authentication for organizational users: Acceptance of personal identity verification credentials====
===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)===
This control enhancement recommends the system be capable of accepting and electronically verifying personal identity verification (PIV) credentials. The U.S. General Services Administration (GSA) says of PIV credentials: "PIV credentials have certificates and key pairs, pin numbers, biometrics like fingerprints and pictures, and other unique identifiers. When put together into a PIV credential, it provides the capability to implement multi-factor authentication for networks, applications and buildings."<ref name="GSA_IntroPIV">{{cite web |url=https://piv.idmanagement.gov/ |title=Introduction - PIV Guides |work=PIV Usage Guides |publisher=General Services Administration |accessdate=23 July 2020}}</ref> These types of credentials are most often associated with federal agencies, and as such this control enhancement may not be required for a non-federal entity or organization.


'''Additional resources''':
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):
* [https://www.limswiki.org/index.php/LII:LIMSpec/Security_and_Integrity_of_Systems_and_Operations#35._Cybersecurity LIMSpec 21.17]


====IA-4 Identifier management====
<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.
This control recommends the organization ensure the individual, group, role, and device identifiers in the system be selected, assigned, and disabled by authorized individuals or roles only. Those same individuals or roles will be responsible for both preventing the reuse of those identifiers for and disabling those identifiers after a specified period of time (including "never").


'''Additional resources''':
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.
* [https://csrc.nist.gov/publications/detail/sp/800-73/4/final NIST Special Publications 800-73-4]
* [https://csrc.nist.gov/publications/detail/sp/800-76/2/final NIST Special Publications 800-76-2]
* [https://csrc.nist.gov/publications/detail/sp/800-78/4/final NIST Special Publications 800-78-4]
* [https://www.limswiki.org/index.php/LII:LIMSpec/Security_and_Integrity_of_Systems_and_Operations#32._Configuration_management LIMSpec 32.26 and 32.28]


====IA-5 Authenticator management====
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>
This control recommends the organization ensure the individual, group, role, and device receiving a new authenticator has their identity verified, while also ensuring those new authenticators are properly defined, are sufficiently strong, and are backed by administrative and cybersecurity policy and procedure. That policy and procedure should address how authenticators are managed if lost, compromised, or damaged, as well as how to revoke the authenticators. Policy and procedure should also address use and reuse restrictions, refreshing rules, protection recommendations, personnel and device safeguards, and membership/role changes for authenticators.


'''Additional resources''':
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:
* [https://arch.idmanagement.gov/ FICAM Enterprise Architecture Guide]
* [https://www.idmanagement.gov/wp-content/uploads/sites/1171/uploads/FICAM_Roadmap_and_Implem_Guid.pdf FICAM Roadmap and Implementation Guidance]
* [https://csrc.nist.gov/publications/detail/sp/800-63/3/final NIST Special Publications 800-63-3]
* [https://csrc.nist.gov/publications/detail/sp/800-73/4/final NIST Special Publications 800-73-4]
* [https://csrc.nist.gov/publications/detail/sp/800-76/2/final NIST Special Publications 800-76-2]
* [https://csrc.nist.gov/publications/detail/sp/800-78/4/final NIST Special Publications 800-78-4]
* [https://www.limswiki.org/index.php/LII:LIMSpec/Security_and_Integrity_of_Systems_and_Operations#32._Configuration_management LIMSpec 32.25, 32.26, 32.27, 32.34, and 32.35]


====IA-5 (1) Authenticator management: Password-based authentication====
<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>
This control enhancement recommends the system's password-based authentication be configurable to allow specific password-related rules set by the organization. This includes rules related to password complexity (case sensitivity, number of characters by type, uppercase-lowercase mix, numbers and special characters), minimum and maximum password lifetime rules, changed and updated password rules, and password reuse rules. The system should also be capable of allowing for the creation of temporary passwords and the storage and transmittal of passwords in an encrypted fashion.


'''Additional resources''':
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/]
* [https://www.limswiki.org/index.php/LII:LIMSpec/Specialty_Laboratory_Functions#21._Forensic_case_and_data_management LIMSpec 21.10], [https://www.limswiki.org/index.php/LII:LIMSpec/Security_and_Integrity_of_Systems_and_Operations#32._Configuration_management 32.27, 32.28, and 32.40]


====IA-5 (4) Authenticator management: Automated support for password strength determination====
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].
This control enhancement recommends the organization employ (or, ensure the system employs) some type of automation in determining if password authenticators are sufficiently strong to satisfy organizational policy. This is strongly related to IA-5 (1).


'''Additional resources''':
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/]
* [https://www.limswiki.org/index.php/LII:LIMSpec/Specialty_Laboratory_Functions#21._Forensic_case_and_data_management LIMSpec 21.10] and [https://www.limswiki.org/index.php/LII:LIMSpec/Security_and_Integrity_of_Systems_and_Operations#32._Configuration_management 32.40]


====IA-5 (11) Authenticator management: Hardware token-based authentication====
==Additional information==
This control enhancement recommends the organization—if it plans on implementing public key infrastructure (PKI) tokens, which "provide secure storage for digital certificates and private keys"<ref name="MicrocosmPKITokens">{{cite web |url=https://www.microcosm.com/products/pki-tokens |title=PKI Tokens |publisher=Microcosm Ltd |accessdate=23 July 2020}}</ref>—employ mechanisms that satisfy organization-based token quality requirements.


'''Additional resources''':
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."
* [https://www.limswiki.org/index.php/LII:LIMSpec/Specialty_Laboratory_Functions#21._Forensic_case_and_data_management LIMSpec 21.17]
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]


====IA-6 Authenticator feedback====
3. Some additional posts and guides that may be revealing:
This control recommends the system obscure how authentication information, such as passwords, is entered, using mechanisms such as showing asterisks instead of the password characters or limiting visual feedback of each password character to an extremely brief period of time.
* [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)
'''Additional resources''':
* [https://www.dhs.gov/publication/dhs-section-508-compliance-test-processes DHS Section 508 Compliance Test Processes]
[https://www.limswiki.org/index.php/LII:LIMSpec/Security_and_Integrity_of_Systems_and_Operations#32._Configuration_management LIMSpec 32.41]
 
====IA-7 Cryptographic module verification====
This control recommends the system be capable of authenticating access to a cryptographic module, ensuring the user is authorized to assume the requested role and perform role-based actions within that module.
 
'''Additional resources''':
* [https://www.limswiki.org/index.php/LII:LIMSpec/Security_and_Integrity_of_Systems_and_Operations#35._Cybersecurity LIMSpec 35.5]
 
====IA-8 Identification and authentication for non-organizational users====
This control recommends the system be able to identify and authenticate a non-organizational user or user-propagated process as a single, unique entity by using one or more mechanisms. The choice of these mechanisms will be guided by organizational policy, regulations, laws, standards, and guidance documents. According to NIST, authentication mechanisms will be based on "(i) something you know (e.g., password, personal identification number [PIN]); (ii) something you have (e.g., cryptographic identification device, token); or (iii) something you are (e.g., biometric)."
 
'''Additional resources''':
* [https://pacs.idmanagement.gov/ GSA Physical Access Control System Guide]
* [https://csrc.nist.gov/publications/detail/sp/800-63/3/final NIST Special Publications 800-63-3]
* [https://csrc.nist.gov/publications/detail/sp/800-116/rev-1/final NIST Special Publications 800-116, Rev. 1]
* [https://www.limswiki.org/index.php/LII:LIMSpec/Security_and_Integrity_of_Systems_and_Operations#32._Configuration_management LIMSpec 32.25, 32.35], [https://www.limswiki.org/index.php/LII:LIMSpec/Security_and_Integrity_of_Systems_and_Operations#34._System_administration 34.4], and [https://www.limswiki.org/index.php/LII:LIMSpec/Security_and_Integrity_of_Systems_and_Operations#35._Cybersecurity 35.3]
 
====IA-8 (1) Identification and authentication for non-organizational users: Acceptance of personal identity verification credentials from other agencies====
This control enhancement recommends the system be capable of accepting and electronically verifying PIV credentials from more than just the primary organization or agency. The U.S. General Services Administration (GSA) says of PIV credentials: "PIV credentials have certificates and key pairs, pin numbers, biometrics like fingerprints and pictures, and other unique identifiers. When put together into a PIV credential, it provides the capability to implement multi-factor authentication for networks, applications and buildings."<ref name="GSA_IntroPIV" /> These types of credentials are most often associated with federal agencies, and as such this control enhancement may not be required for a non-federal entity or organization.
 
'''Additional resources''':
* [https://www.limswiki.org/index.php/LII:LIMSpec/Security_and_Integrity_of_Systems_and_Operations#35._Cybersecurity LIMSpec 21.17]
 
====IA-8 (2) Identification and authentication for non-organizational users: Acceptance of third-party credentials====
This control enhancement recommends the system be capable of accepting and electronically verifying FICAM-approved third-party credentials. FICAM is the U.S. federal government's implementation of the Identity, Credential, and Access Management (ICAM) architecture plan, which is a set of philosophies and resources that allow an organization to "enable the right individual to access the right resource at the right time for the right reason."<ref name="GSA-FICAM">{{cite web |url=https://arch.idmanagement.gov/ |title=Introduction |work=Federal Identity, Credential, and Access Management Architecture |publisher=General Services Administration |accessdate=23 July 2020}}</ref>
 
These types of credentials are most associated with federal agencies, and as such this control enhancement would not be required for a non-federal entity or organization. However, while specifically intended for ensuring non-federal government entities can access federal systems in a standardized way, this control enhancement could be altered to address the needs of non-federal organizations requiring authorized third parties (such as contractors) to use PKI token-based authentication for logical and physical access to systems.
 
'''Additional resources''':
* [https://arch.idmanagement.gov/ FICAM Enterprise Architecture Guide]
* [https://www.idmanagement.gov/wp-content/uploads/sites/1171/uploads/FICAM_Roadmap_and_Implem_Guid.pdf FICAM Roadmap and Implementation Guidance]
* No LIMSpec comp (LIMSpec currently doesn't address FICAM requirements)
 
====IA-8 (3) Identification and authentication for non-organizational users: Use of FICAM-approved products====
This control enhancement recommends the organization employ only FICAM-approved system components when accepting and electronically verifying FICAM-approved credentials. FICAM is the U.S. federal government's implementation of the Identity, Credential, and Access Management (ICAM) architecture plan, which is a set of philosophies and resources that allow an organization to "enable the right individual to access the right resource at the right time for the right reason."<ref name="GSA-FICAM" />
 
These types of credentials are most associated with federal agencies, and as such this control enhancement would not be required for a non-federal entity or organization. However, while specifically intended for ensuring non-federal government entities can access federal systems in a standardized way, this control enhancement could be altered to address the needs of non-federal organizations requiring authorized individuals to use PKI token-based authentication for logical and physical access to systems. In that case, the organization may wish to set a baseline standard for system components employed to accept and verify those PKI tokens.
 
'''Additional resources''':
* [https://arch.idmanagement.gov/ FICAM Enterprise Architecture Guide]
* [https://www.idmanagement.gov/wp-content/uploads/sites/1171/uploads/FICAM_Roadmap_and_Implem_Guid.pdf FICAM Roadmap and Implementation Guidance]
* No LIMSpec comp (LIMSpec currently doesn't address FICAM requirements)
 
====IA-8 (4) Identification and authentication for non-organizational users: Use of FICAM-issued profiles====
This control enhancement recommends a system that accepts and electronically verifies FICAM-approved credentials conform to FICAM-issued implementation profiles of protocols such as SAML 2.0 and OpenID 2.0, as well as other protocols such as the FICAM Backend Attribute Exchange. FICAM is the U.S. federal government's implementation of the Identity, Credential, and Access Management (ICAM) architecture plan, which is a set of philosophies and resources that allow an organization to "enable the right individual to access the right resource at the right time for the right reason."<ref name="GSA-FICAM" />
 
These types of credentials are most associated with federal agencies, and as such this control enhancement would not be required for a non-federal entity or organization. However, while specifically intended for ensuring non-federal government entities can access federal systems in a standardized way, this control enhancement could be altered to address the needs of non-federal organizations requiring authorized individuals to use PKI token-based authentication for logical and physical access to systems. In that case, the organization may wish to set a baseline standard for how the system implements protocols that manage how PKI tokens are accepted and verified.
 
'''Additional resources''':
* [https://arch.idmanagement.gov/ FICAM Enterprise Architecture Guide]
* [https://www.idmanagement.gov/wp-content/uploads/sites/1171/uploads/FICAM_Roadmap_and_Implem_Guid.pdf FICAM Roadmap and Implementation Guidance]
* No LIMSpec comp (LIMSpec currently doesn't address FICAM requirements)
 
==References==
{{Reflist|colwidth=30em}}

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: