Book:Comprehensive Guide to Developing and Implementing a Cybersecurity Plan/A simplified description of NIST Special Publication 800-53 controls, with ties to LIMSpec/Access control

From LIMSWiki
Jump to navigationJump to search
-----Return to the beginning of this guide-----

Appendix 1. A simplified description of NIST Special Publication 800-53 controls, with ties to LIMSpec

What follows is essentially a simplification of the NIST control descriptions found in NIST Special Publication 800-53, Revision 5: Security and Privacy Controls for Information Systems and Organizations. As mentioned earlier, most of the "Low" baseline controls, as well as select "Moderate" and "High" baseline controls, are worthy of consideration for most any systems and organizations. Also worth noting again is that if the NIST SP 800-53 controls and framework is too technical for your tastes, a simplified version was derived from 800-53 by NIST in the form of NIST Special Publication 800-171, Revision 2: Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations. In addition to making the controls and methodology a bit easier to understand, NIST includes a mapping table in Appendix D of 800-171 which maps its security requirements to both NIST SP 800-53 (Revision 4, with plans to update it to Revision 5) and ISO/IEC 27001. As such, you're able to not only see how it connects to the more advanced document but also to the International Organization for Standardization's international standard "for establishing, implementing, maintaining and continually improving an information security management system within the context of the organization."[1] For an even broader, more simplified NIST approach to 800-53, you may rather want to turn to the NIST Cybersecurity Framework, which is suitable for those without a technical background.

The general format used in Appendix 1 is to first separate the control descriptions by their NIST family, then their control name. Occasionally, you will also see selected NIST control enhancements in the form of NIST family, the control enhancement number in parentheses, the control name, and then the control enhancement name. Then, a simplified description—with occasional outside references—is added, based on the original text. Additional resources are included, where applicable. Those resources are typically based on references NIST used in making its framework, or additional resources that help you, the reader, gain additional context.

Finally, if you are implementing or have implemented information management software in your laboratory, you may also find links to LIMSpec in the additional resources. The LIMSpec has seen a handful of iterations over the years, but its primary goal remains the same: to provide software requirements specifications for the ever-evolving array of laboratory informatics systems being developed. We attempted to link NIST's security and privacy controls to specific software requirements specifications in LIMSpec. It should be noted that some 40+ NIST controls could not be directly linked to a software specification in LIMSpec. In almost every single case, those non-linked items reflect as organizational policy rather than an actual software specification. If a LIMSpec comparison was made, you'll find a link to the relevant section. If no LIMSpec comparison could be made, you'll see something like "No LIMSpec comp (organizational policy rather than system specification)." (Note that the selected control enhancements largely appear in this appendix because they both have a comp to LIMSpec and don't have a tight relation to another NIST control.)

In some cases the LIMSpec comparison may seem slightly confusing. For example, all NIST controls encouraging the establishment of policy and procedure are linked to LIMSpec 7.1 and 7.2. LIMSpec 7.1 states "the system shall be capable of creating, managing, and securely holding a variety of document types, while also allowing for the review and approval of those documents using version and release controls." To be clear, it's not that any particular software system itself conforms to the NIST controls specifying policies be created and managed. Rather, this particular software specification ensures that any software system built to meet the specification will provide the means for creating and managing policies and procedures, which in hand aids the organization in conforming to the NIST controls specifying policies be created and managed.

NOTE: Under "Additional resources," occasionally a guide, brochure, or blog post from a particular company will appear. That guide or brochure is added solely because it provides contextual information about the specific NIST control. The inclusion as a resource of such a guide, brochure, or blog post should not be considered an endorsement for the company that published it.


Appendix 1.1 Access control

AC-1 Policy and procedures

This control recommends the organization develop, document, disseminate, review, and update an access control policy. Taking into account regulations, standards, policy, guidance, and law, this policy essentially details the security controls and enhancements "that specify how access is managed and who may access information under what circumstances."[2]

Additional resources:

AC-2 Account management

This control recommends the organization develop a series of account management steps for its information systems. Among its many recommendations, it asks the organization to clearly define account types (e.g., individual, group, vendor, temporary, etc.), their associated membership requirements, and policy dictating how accounts should be managed; appoint one or more individuals to be in charge of account creation, approval, modification, compliance review, and removal; and provide proper communication to those account managers when an account needs to be modified, disabled, or removed.

Additional resources:

AC-2 (3) Account management: Disable accounts

This control enhancement recommends the system have the ability to automatically disable specific accounts (i.e., expired, unassociated, in-violation, and inactive) after a designated period of time.

Additional resources:

AC-2 (4) Account management: Automated audit actions

This control enhancement recommends the system have the ability to automatically audit creation, modification, enabling, disabling, and removal actions performed on accounts, as well as notify designated individuals or roles of those actions.

Additional resources:

AC-2 (7) Account management: Privileged user accounts

This control enhancement recommends the organization take additional action in regards to accounts with privileged roles. AC-2 (7) defines privileged roles as "organization-defined roles assigned to individuals that allow those individuals to perform certain security-relevant functions that ordinary users are not authorized to perform." The organization should not only use a role-based mechanism for assigning privileges to an account, but also the organization should monitor the activities of privileged accounts and manage those accounts when the role is no longer appropriate.

Additional resources:

AC-2 (11) Account management: Usage conditions

This control enhancement recommends the system allow for the configuration of specific usage conditions or circumstances under which an account type can be used. Conditions or circumstances for account activity may include physical location, logical location, network address, or chronometric criterion (time of day, day of week/month).

Additional resources:

AC-3 Access enforcement

This control recommends the system be capable of enforcing system access based upon the configured access controls (policies and mechanisms) put into place by the organization. This enforcement could occur at the overall information system level, or be more granular at the application and service levels.

Additional resources:

AC-3 (7) Access enforcement: Role-based access control

This control enhancement recommends the system be able to effectively monitor and enforce a role-based access control policy to objects and system functions, as well users of a defined role. However, this requires system administrators and organizational managers work together to ensure only those permissions critical to supporting "organizational missions or business functions" are enacted upon the assignable roles, and that those assigned roles are appropriate for the user account.

Additional resources:

AC-6 Least privilege

This control recommends the organization use the principle of "least privilege" when implementing and managing accounts in the system. The concept of least privilege essentially "requires giving each user, service, and application only the permissions needed to perform their work and no more."[3]

Additional resources:

AC-6 (1) Least privilege: Authorize access to security functions

This control enhancement recommends the organization provide access to specific security-related functions and information in the system to explicitly authorized personnel. In other words, one or more specific system administrators, network administrators, security officers, etc. should be given access to configure security permissions, monitoring, cryptographic keys, services, etc. required to ensure the system is correctly protected.

Additional resources:

AC-6 (4) Least privilege: Separate processing domains

This control enhancement recommends the system provide separate processing domains in order to make user privilege allocation more granular. This essentially means that through using virtualization, domain separation mechanisms, or separate physical domains, the overall information system can create additional fine layers of access control for a particular domain.

Additional resources:

AC-6 (9) Least privilege: Log use of privileged functions

This control enhancement recommends the system perform auditing functions on any privileged functions that get executed in the system. This allows organizations to review audit records to ensure the effects of intentional or unintentional misuse of privileged functions is caught early and mitigated effectively.

Additional resources:

AC-7 Unsuccessful logon attempts

This control recommends the system be capable of not only enforcing a specific number of failed logon attempts in a given period of time, but also automatically locking or disabling an account until released by the system after a designated period of time, or manually by an administrator.

Additional resources:

AC-8 System use notification

This control recommends the system be configurable to allow the creation of a system-wide notification message or banner before logon that provides vital privacy, security, and authorized use information related to the system. The message or banner should remain on the screen until acknowledged by the user and the user logs on. Note that the wording of such message or banner may require legal review and approval before implementation.

Additional resources:

AC-10 Concurrent session control

This control recommends the system be able to limit the number of concurrent (running at the same time) sessions (log ins) globally, for a given account type, for a given a user, or by using a combination of such limiters. NIST gives the example of wanting to tighten security by limiting the number of concurrent sessions for system administrators or users working in domains containing sensitive data.

Additional resources:

AC-11 Device lock

This control recommends the system be able to prevent further access to a system using a device lock, which activates after a defined period of inactivity or upon a user request. AC-11 defines a device lock as "temporary actions taken to prevent logical access to organizational systems when users stop work and move away from the immediate vicinity of those systems but do not want to log out because of the temporary nature of their absences." The device lock must be able to remain in place until the user associated with the session again goes through the system's identification and authentication process.

Additional resources:

AC-12 Session termination

This control recommends the system be able to automatically terminate a user session after a defined period of time or pre-defined events (e.g., time-of-day restriction) occur.

Additional resources:

AC-14 Permitted actions without identification or authentication

This control recommends the organization develop a list of user actions, if any, that can be performed on the system without going through the system's identification and authentication process. Any such list should be documented and provide supporting rationale as to why the authentication can be bypassed. This may largely pertain to public websites or other publicly accessible systems.

Additional resources:

  • No LIMSpec comp (organizational policy rather than system specification)

AC-17 Remote access

This control recommends the organization develop and document a remote access policy that addresses each type of remote access allowed into the system. Remote access involves communicating with the system through an external network, usually the internet. The policy should address the usage restrictions, configuration requirements, connection requirements, and implementation rules for the approved methods (e.g., wireless, broadband, Bluetooth, etc.). Some sort of access enforcement process should take place prior to allowing remote access (see AC-3 for said access enforcement).

Additional resources:

AC-17 (1) Remote access: Monitoring and control

This control enhancement recommends the system have the ability to automatically monitor and control remote access methods. By enabling the automatic auditing of the connection activity of remote users, compliance with remote access policies (see AC-17) can be ensured and cyber attacks caught early.

Additional resources:

AC-17 (2) Remote access: Protection of confidentiality and integrity using encryption

This control enhancement recommends the system have the ability to implement encryption mechanisms for remote access. This involves using "encryption to protect communications between the access device and the institution," using encryption "to protect sensitive data residing on the access device," or both.[4]

Additional resources:

AC-18 Wireless access

This control recommends the organization develop and document a wireless access policy, probably best done in conjunction with AC-17. NIST gives examples of wireless technologies such as microwave, packet radio, 802.11x, and Bluetooth. The policy should address the usage restrictions, configuration requirements, connection requirements, and implementation rules for the approved wireless technologies. Some sort of access enforcement process should take place prior to allowing a wireless connection to the system (see AC-3 for said access enforcement). In most cases this will be a built-in authentication protocol for the wireless network.

Additional resources:

AC-19 Access control for mobile devices

This control recommends the organization develop and document a mobile device (e.g., smart phone, tablet, e-reader) use and access policy. The policy should address the usage restrictions, configuration requirements, connection requirements, and implementation rules for the approved wireless technologies. Some sort of access enforcement process should take place prior to allowing a mobile connection to the system (see AC-3 for said access enforcement).

Additional resources:

AC-20 Use of external systems

This control recommends the organization develop and document a policy concerning the use of external systems to access, process, store, and transmit data from the organization's system. External systems include (but are not limited to) personal devices, private or public computing devices in commercial or public facilities, non-federal government systems, and federal systems not operated or owned by the organization. This includes the use of cloud-based service providers. The organization should consider the trust relationships already established with internal business divisions, as well as contractors and other third parties when developing this policy.

  • No LIMSpec comp (organizational policy rather than system specification)

AC-22 Publicly accessible content

This control recommend the organization develop and document policy on the use and management of public-facing components of the system, typically the public website. This control ensures that sensitive, protected, or classified information is not accessible by the general public. The organizational policy should address who's responsible for posting information to the public-facing system; how to verify the information being posted does not contain sensitive, protected, or classified information; and how to monitor the public-facing system to ensure any non-public information is removed upon discovery.

  • No LIMSpec comp (organizational policy rather than system specification)

References

  1. ↑ "SO/IEC 27001:2013 Information technology — Security techniques — Information security management systems — Requirements". International Organization for Standardization. 3 June 2019. https://www.iso.org/standard/54534.html. Retrieved 21 March 2023. 
  2. ↑ "Access Control Policy and Implementation Guides". Computer Security Resource Center. National Institute of Standards and Technology. 27 January 2023. https://csrc.nist.gov/Projects/Access-Control-Policy-and-Implementation-Guides. Retrieved 21 March 2023. 
  3. ↑ "Best Practice Guide to Implementing the Least Privilege Principle". Netwrix Corporation. 5 April 2019. https://www.netwrix.com/guide_to_implementing_the_least_privilege_principle. Retrieved 21 March 2023. 
  4. ↑ "Guidelines on Information Security, Electronic Banking, Technology Risk Management and Cyber Frauds" (PDF). Reserve Bank of India. p. 46. https://rbidocs.rbi.org.in/rdocs/content/PDFs/GBS300411F.pdf. Retrieved 21 March 2023. 
Retrieved from "https://www.limswiki.org/index.php?title=Book:Comprehensive_Guide_to_Developing_and_Implementing_a_Cybersecurity_Plan/A_simplified_description_of_NIST_Special_Publication_800-53_controls,_with_ties_to_LIMSpec/Access_control&oldid=39890"