User:Shawndouglas/sandbox/sublevel30

From LIMSWiki
< User:Shawndouglas‎ | sandbox
Revision as of 22:42, 13 December 2019 by Shawndouglas (talk | contribs) (Created page with "<div class="nonumtoc">__TOC__</div> ==Appendix 1. A simplified description of NIST Cybersecurity Framework controls, with ties to LIMSpec== What follows is essentially a simpl...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

Appendix 1. A simplified description of NIST Cybersecurity Framework controls, with ties to LIMSpec

What follows is essentially a simplification of the NIST control descriptions found in NIST Special Publication 800-53, Revision 4: Security and Privacy Controls for Federal Information Systems and Organizations. As mentioned earlier, while this framework of security and privacy controls is tailored to federal systems and organizations, most of the "Low" baseline controls, as well as select "Moderate" and "High" baseline controls, are still worthy of consideration for non-federal 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 1: 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 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]

The general format used in Appendix 1 is to first separate the control descriptions by their NIST family, then their control name. Then, a simplified description—with occasional outside references—is added, based on the original text. Finally, 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 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)."

In some cases the 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 Access control policy and procedure

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 inactive accounts

This control enhancement recommends the system have the ability to automatically disable an inactive account 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: Role-based schemes

This control enhancement recommends the organization take additional action in regards to accounts with privileged roles. NIST 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 role, 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-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: Auditing 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 Session lock

This control recommends the system be able to prevent further access to a system using a session lock, which activates after a defined period of inactivity or upon a user request. The session 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-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: Automated monitoring and control

This control enhancement recommends the system have the ability to monitor and control remote access methods. By enabling authorized individuals to audit 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 wireless connection to the system (see AC-3 for said access enforcement).

Additional resources:

AC-20 Use of external information systems

This control recommends the organization develop and document a policy concerning the use of external information systems to access, process, store, and transmit data from the organization's system. External information 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 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)


Appendix 1.2 Awareness and training

AT-1 Security awareness and training policy and procedures

This control recommends the organization develop, document, disseminate, review, and update security training policies and procedures. It asks organizations to not only address the purpose, scope, roles, responsibilities, and enforcement of security training but also to address how it will be implemented, reviewed, and updated.

Additional resources:

AT-2 Security awareness training

This control recommends the organization provide the necessary basic security awareness training as part of initial training, as well as follow-up training, when the system changes, or at a specific mandated frequency. This broadly applies to all information system users and includes the use of training material, informational posters, security reminders and notices, system messages, and awareness events towards meeting the requirements of this control.

Additional resources:

AT-3 Role-based security training

This control recommends the organization provide the necessary role-specific security training to personnel with specific assigned security roles and responsibilities. The training should occur before authorization to access the system is provided, as well as when the system changes or at a specific mandated frequency. This includes the use of training material, policy and procedure documents, role-based security tools, manuals, and other materials towards meeting the requirements of this control.

Additional resources:

AT-4 Security training records

This control recommends the organization document and monitor basic and role-specific security training activities and retain that information for a designated period of time. Note that record retention requirements may vary based on regulations and standards that affect the organization and its operations.

Additional resources:


Appendix 1.3 Audit and accountability

AU-1 Audit and accountability policy and procedures

This control recommends the organization develop, document, disseminate, review, and update audit and accountability policies and procedures. It asks organizations to not only address the purpose, scope, roles, responsibilities, and enforcement of audit and accountability action but also to address how those policies and procedures will be implemented, reviewed, and updated.

Additional resources:

AU-2 Audit events

This control recommends the organization scrutinize the information system to ensure it's fully capable of auditing the events the organization requires to meet its business, cybersecurity, and regulatory goals. It also recommends the organization find common ground within other areas of the organization to improve selection of auditable events, provide rationale for their selection, and implement within the information system the selected auditable events at the recommended frequency or during a specific situation. NIST SP 800-53, Rev. 4 also notes: "Audit records can be generated at various levels of abstraction, including at the packet level as information traverses the network. Selecting the appropriate level of abstraction is a critical aspect of an audit capability and can facilitate the identification of root causes to problems."

Additional resources:

AU-3 Content of audit reports

This control recommends the system be capable of generating audit records that, at a minimum, provide who enacted an event, when it was enacted, where it occurred, what occurred, and what the outcome was. Regulations and standards may dictate what must be recorded beyond those aspects.

Additional resources:

AU-4 Audit storage capacity

This control recommends the organization allocate sufficient resources to ensure the storage capacity of the system is sufficient to hold all its audit records. What that storage capacity should be will be most heavily dictated by data retention regulations and standards (see AU-11), followed by available organizational resources to commit to long-term storage. Additional safeguards such as sending warning messages to designated personnel or system roles when storage space reaches a critical minimum may be useful.

Additional resources:

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

AU-5 Response to audit processing failures

This control recommends the system be able to alert specific personnel or system roles when an audit processing failure occurs and take action as specified by the organization. This action includes shutting down the system, overwriting the oldest audit record (because storage capacity is maxed), or discontinuing the generation of audit records. The system should also allow the organization to specify action differently for various types of failures.

Additional resources:

AU-6 Audit review, analysis, and reporting

This control recommends the organization, as part of policy, review, analyze, and report on the results from generated system audit records at defined frequencies, focusing on inappropriate or unusual activity that may compromise the security of the system. The finding may be reported to designated individuals within the organization, designated departments within the organization, or even regulatory bodies outside the organization.

Additional resources:

AU-6 (1) Audit review, analysis, and reporting: Process integration

This control enhancement recommends the organization implement some sort of automation into their system to better integrate audit review, analysis, and reporting processes with organizational investigation processes (e.g., incident response, continuous monitoring, etc.) in order to better and more quickly respond to cyber threats.

Additional resources:

AU-8 Time stamps

This control recommends the system use a reliable system clock for generating its audit records. The system clock should be able to generate time stamps in Coordinated Universal Time (UTC) or Greenwich Mean Time (GMT) and meet organizational requirements for granularity, all the way down to the millisecond level.

Additional resources:

AU-9 Protection of audit information

This control recommends the system be capable of logically protecting audit information (records, settings, and reports) and tools from unauthorized access, modification, and deletion.

Additional resources:

AU-11 Audit record retention

This control recommends the organization, in tandem with the its overall record retention policy, retain audit records for a defined period of time. That time period may be dictated by administrative, operational, or regulatory policy.

Additional resources:

AU-11 (1) Audit record retention:Long-term retrieval capability

This control enhancement recommends the organization ensure the availability and retrievability of audit information stored long-term. This assurance can be made in several ways, including verifying the information system is correctly providing access to the information to authorized individuals; ensuring records in old, difficult-to-read formats get updated; and retaining the necessary documentation and hardware to read and interpret older record systems.

Additional resources:

AU-12 Audit generation

This control aligns with AU-2 and AU-3, in as much as it recommends the system be capable of generating audit records for the auditable events defined in AU-2 at various organization-defined points in the information system. This control also recommends the system to allow authorized users to assign which auditable events are to be audited by which points in the system. And of course, the system should be capable of generating the audit records with the content as defined in AU-3.

Additional resources:


Appendix 1.4 Security assessment and authorization

CA-1 Security assessment and authorization policy and procedures

This control recommends the organization develop, document, disseminate, review, and update security assessment and authorization policies and procedures. It asks organizations to not only address the purpose, scope, roles, responsibilities, and enforcement of security assessment and authorization action but also to address how those policies and procedures will be implemented, reviewed, and updated.

Additional resources:

CA-2 Security assessments

This control recommends the organization develop, document, disseminate, review, and update a security assessment plan. This plan is focused on helping the organization ensure the assessment procedures, environment, team, roles, and responsibilities are defined and the security controls are correctly implemented, operating as intended, and meeting the established security requirements. The assessments should happen at defined frequency. Additionally, the organization is encouraged to report on the results of the implemented plan and corresponding assessments, disseminating the results to authorized personnel or roles.

Additional resources:

CA-2 (1) Security assessments: Independent assessors

This control enhancement recommends the organization employ some type of independent assessment team with a predetermined level of required independence to conduct security control assessments. that Ensuring the team is free from perceived or actual conflict of interest is important, and NIST adds that "[o]rganizations recognize that assessments performed for purposes other than direct support to authorization decisions are, when performed by assessors with sufficient independence, more likely to be useable for such decisions, thereby reducing the need to repeat assessments."

Additional resources:

CA-3 System interconnections

This control recommends the organization should explicitly authorize, document, review, and update interconnection security agreements (ISA) or system-based security plans, as they relate to the interconnection of information systems in the organization. Separately, in NIST SP 800-47, at D-1, NIST defines an ISA an an established agreement between owner-operators of connected IT systems to document and agree to the technical requirements associated with any interconnections between the organizations' systems. However, NIST notes, "[i]f interconnecting systems have the same authorizing official, organizations do not need to develop interconnection security agreements. Instead, organizations can describe the interface characteristics between those interconnecting systems in their respective security plans."

Additional resources:

CA-5 Plan of action and milestones

This control recommends the organization develop and update a security authorization-related plan of action and milestones for the documentation of planned remedial actions and vulnerability resolutions. These key security authorization documents should be reviewed and updated at a defined frequency, based off the results of security control assessments, security impact analyses, and continuous monitoring results.

Additional resources:

CA-6 Security authorization

This control recommends the organization assign a manager or member of senior leadership as an "authorizing official" that essentially approves the system to be put into operation based on the results of security assessments and accepts responsibility for the risks associated with operation. The authorization should also be updated at a defined frequency. It's important to note that this control is described by NIST as being an "inherently federal responsibility and therefore, authorizing officials must be federal employees." If applying this control to non-federal systems, there is still plenty of sense in designating a key individual in the organization as responsible for making the call post-security assessment of allowing the system to go live, as well as accepting the risks of putting the system into operation. The same principle can be applied to major security upgrades and reconfiguration of existing systems.

Additional resources:

CA-7 Continuous monitoring

This control recommends the organization develop a continuous monitoring program and implementation strategy. The program should define the metrics required for organizational performance indicators, as well as how often those metrics are applied and assessed for functionality and sufficiency. How the information is analyzed and correlated, how the organization responds to those activities, and how they are reported (who and when) must also be addressed. Metrics should follow the SMART principle of being specific, measurable, actionable, relevant, and focused on a timely nature.

Additional resources:

CA-9 Internal system connections

This control recommends the organization essentially create a systems map, documenting how the various parts of the system should interconnect—as well as the characteristics of the connection and the nature of the information transported through it—and explicitly authorizing the interconnection to occur. This includes connections through mobile devices, printers, computers, sensors, and servers. It may be useful to classify components of the system that have common characteristics or configurations to make authorizations (as classes) easier.

Additional resources:

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


Appendix 1.5 Configuration management

CM-1 Configuration management policy and procedures

This control recommends the organization develop, document, disseminate, review, and update configuration management policies and procedures. It asks organizations to not only address the purpose, scope, roles, responsibilities, and enforcement of configuration management action but also to address how those policies and procedures will be implemented, reviewed, and updated.

Additional resources:

CM-2 Baseline configuration

This control recommends the organization develop, document, and maintain a baseline configuration of the information system and its components, including their network topology and logical placement within the system. The end result should fully reflect the existing enterprise architecture.

Additional resources:

CM-3 Configuration change control

This control recommends the organization develop a series of configuration change control steps to ensure that system upgrades and modifications cause little to no impact in the overall cybersecurity strength of the system. NIST specifically recommends the organization determine which system changes are linked to configuration control, review and approve proposed changes, document and retain those decisions, implement the approved changes, and audit and review the changes.

Additional resources:

CM-3 (2) Configuration change control: Test, validate, and document changes

This control enhancement recommends the organization test, validate, and document changes to the system before actual implementation on the live system. Operational hardware systems may have to be taken offline or replicated as closely as feasible to test; software systems can often be tested in a separate test environment. In all cases, the organization seeks to minimize impact on active system operations.

Additional resources:

CM-4 Security impact analysis

This control recommends the organization perform security impact analysis on the system to determine the extent of potentially undesirable consequences upon implementing proposed changes. This typically requires one or more individuals explicitly familiar with the system, the organization's security plans, and the system's architecture documents. Some revelations may also come from enacting security control CM-3 (2).

Additional resources:

CM-5 Access restrictions for change

This control recommends the organization define, document, approve, and enforce all the physical and logical access restrictions associated with making changes to the system configuration. Doing so creates a base policy that helps ensure "only qualified and authorized individuals [can] access information systems for purposes of initiating changes, including upgrades and modifications."

Additional resources:

CM-5 (1) Access restrictions for change: Automated access enforcement and auditing

This control enhancement recommends the system allow for the configuration and automated enforcement of access restrictions, as well as the auditing of associated enforcement actions.

Additional resources:

CM-6 Configuration settings

This control recommends the organization develop and implement a complete set of configuration settings for the hardware, software, and firmware that make up the information system. Those settings should ultimately reflect restrictions consistent with operational requirements and organizational policy. Additionally, the organization should perform change control on the settings, such that suggested deviations are not detrimental to the system and overall cybersecurity goals.

Additional resources:

CM-7 Least functionality

This control recommends the organization configure the system to apply the principle of "least functionality." As Georgetown University describes it, "[t]he principle of least functionality provides that information systems are configured to provide only essential capabilities and to prohibit or restrict the use of non-essential functions, such as ports, protocols, and/or services that are not integral to the operation of that information system."[5] NIST also notes that "[o]rganizations can utilize network scanning tools, intrusion detection and prevention systems, and end-point protections such as firewalls and host-based intrusion detection systems to identify and prevent the use of prohibited functions, ports, protocols, and services."

Additional resources:

CM-8 Information system component inventory

This control recommends the organization develop and document a complete inventory of the various components within the authorization boundary of the system. That inventory should accurately portray the current system, have sufficient detail for accountability, and be detailed at a granular enough level for convenient tracking and reporting. The organization should also review and update the inventory in a defined frequency.

Additional resources:

CM-10 Software usage restrictions

This control recommends the organization make an effort to track the use of software and associated documentation to ensure both are being used legally and within contract agreements. The organization should also control against and document instances of software or documentation being copied, distributed, or used in an unauthorized fashion.

Additional resources:

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

CM-11 User-installed software

This control recommends the organization develop, document, and enforce policies governing if and when users may install software within the system. This includes monitoring for policy compliance at a defined frequency. Enforcement may be procedural, automated, or both.

Additional resources:

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


Appendix 1.6 Contingency planning

CP-1 Contingency planning policy and procedures

This control recommends the organization develop, document, disseminate, review, and update contingency planning policies and procedures. It asks organizations to not only address the purpose, scope, roles, responsibilities, and enforcement of contingency planning action but also to address how those policies and procedures will be implemented, reviewed, and updated.

Additional resources:

CP-2 Contingency plan

This control recommends the organization develop, document, disseminate, review, and update a contingency plan for the system. As part of this process, the organization should identify its business and cybersecurity goals, as well as its processes, particularly goals and processes that have been marked as critical or essential to overall operations. The plan should also address the importance of keeping those goals and processes intact despite any disruption, as well as any recovery objectives, restoration priorities, and responsible parties (including their roles and contact information). The plan should be reviewed and approved by key personnel, and reviewed again at a determined frequency, with any changes resulting in updating, communicating, and protecting the revised plan.

Additional resources:

CP-3 Contingency training

This control recommends the organization supply the appropriate training concerning contingency plan enactment to the relevant system users at a defined frequency, when the system changes significantly, or when a user takes on a contingency role or responsibility.

Additional resources:

CP-4 Contingency plan testing

This control recommends the organization develop and regularly use testing methods to test the system contingency plan for its effectiveness, as well as how well prepared system users are to execute the plan. The organization should review the results of such tests and apply corrective action, if needed.

Additional resources:

CP-9 Information system backup

This control recommends the organization back up the system's user-level and system-level information, as well as system documentation, at defined frequencies. The organization should make efforts to protect the confidentiality, integrity, and availability of any data backups.

Additional resources:

CP-10 Information system recovery and reconstitution

This control recommends the organization retain the capability of recovering and reconstituting the system to a recent known state in the wake of a system disruption, compromise, or failure. This may be done in an automatic or manual fashion.

Additional resources:


Appendix 1.7 Identification and authentication

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:

IA-2 Identification and authentication for organizational users

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:

IA-2 (1) Identification and authentication for organizational users: Network access to privileged accounts

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:

IA-2 (2) Identification and authentication for organizational users: Network access to non-privileged accounts

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)."

Additional resources:

IA-2 (3) Identification and authentication for organizational users: Local access to privileged accounts

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."

Additional resources:

IA-2 (4) Identification and authentication for organizational users: Local access to non-privileged accounts

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:

IA-2 (10) Identification and authentication for organizational users: Single sign-on

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:

IA-2 (12) Identification and authentication for organizational users: Acceptance of personal identity verification credentials

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."[6] 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:

IA-4 Identifier management

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:

IA-5 Authenticator management

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:

IA-5 (1) Authenticator management: Password-based authentication

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:

IA-5 (4) Authenticator management: Automated support for password strength determination

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:

IA-5 (11) Authenticator management: Hardware token-based authentication

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"[7]—employ mechanisms that satisfy organization-based token quality requirements.

Additional resources:

IA-6 Authenticator feedback

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.

Additional resources: 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:

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:

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."[6] 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:

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."[8]

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:

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."[8]

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:

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."[8]

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:


Appendix 1.8 Incident response

IR-1 Incident response policy and procedures

This control recommends the organization develop, document, disseminate, review, and update incident response policies and procedures. It asks organizations to not only address the purpose, scope, roles, responsibilities, and enforcement of incident response action but also to address how those policies and procedures will be implemented, reviewed, and updated.

Additional resources:

IR-2 Incident response training

This control recommends the organization provide incident response training to those system users with roles and responsibilities tied to incident response and, more broadly, business continuity planning. That training should occur initially, within an organization-defined period of time upon taking on a related role or responsibility, and when required by major changes to the system. Follow-up training should be conducted at a defined frequency afterwards.

Additional resources:

IR-4 Incident handling

This control recommends the organization, as part of their incident response planning (see IR-8), address how it will engage in preparation, detection and analysis, containment, eradication, and recovery from a security incident. That organization will also link its incident handling with its contingency planning activities and update its incident and business continuity plans, as well as affected training regiments, with "lessons learned" from internal and external events.

Additional resources:

IR-4 (1) Incident handling: Automated incident handling processes

This control enhancement recommends the organization employ automated mechanisms to better handle incident response initiatives. NIST gives the example of online incident management systems as a possible automated tool to use.

Additional resources:

IR-5 Incident monitoring

This control recommends the organization track and document security incidents affecting the system. For these purposes, the organization may consider pulling information from "incident reports, incident response teams, audit monitoring, network monitoring, physical access monitoring, and user/administrator reports."

Additional resources:

IR-6 Incident reporting

This control recommends the organization require security incidents, suspected and real, and any relevant information to be reported to the appropriate organizational personnel within a certain period of time.

Additional resources:

IR-6 (1) Incident reporting: Automated reporting

This control enhancement recommends the the organization employ automated mechanisms to better handle reporting of security incidents. These automated mechanisms would likely be tied to existing monitoring controls.

Additional resources:

IR-7 Incident response assistance

This control recommends the organization provide support resources that offer advice and assistance to system users confronted with handling and reporting security incidents. Those support resources could come in the form of help desk, a responsible individual designated in the incident response plan, ot in-house or third-party forensic services.

Additional resources:

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

IR-8 Incident response plan

This control recommends the organization develop, document, disseminate, review, update, and protect an organizational incident response plan. That plan should be sophisticated enough to contain an incident response roadmap for implementing the developed plan, which should include how the overall plan meshes with business and cybersecurity goals, the resources and responsible individuals that are part of the plan, what should be reportable, and what the associated metrics will be for measuring incident response and its aftermath. The plan should be reviewed and approved by one or more designated personnel, usually leadership or management. Any changes to the plan should be communicated to appropriate personnel, and any affected training should be updated.

Additional resources:


Appendix 1.9 Maintenance

MA-1 System maintenance policy and procedures

This control recommends the organization develop, document, disseminate, review, and update system maintenance policies and procedures. It asks organizations to not only address the purpose, scope, roles, responsibilities, and enforcement of system maintenance action but also to address how those policies and procedures will be implemented, reviewed, and updated.

Additional resources:

MA-2 Controlled maintenance

This control recommends the organization apply a "controlled maintenance" approach to its system. Not only should maintenance be regularly scheduled, performed, and thoroughly documented, but also that maintenance should be in-line with manufacturer, vendor, or organizational requirements. The maintenance should go through an approval and monitoring process whether conducted on- or off-site. Any off-site work will required proper data sanitization. After maintenance, the components and the system should be checked to ensure that all implemented controls still function as expected.

Additional resources:

MA-2 (2) Controlled maintenance: Automated maintenance activities

This control enhancement recommends the organization employ (or, ensure the system employs) some type of automation in scheduling, conducting, and/or documenting maintenance and repairs. That automated process should also ensure that all related documentation is complete and accurate in regards to requested, scheduled, processed, and completed maintenance and repair actions.

Additional resources:

MA-4 Non-local maintenance

This control recommends the organization place strong controls on non-local maintenance and diagnostics of the system or its components. "Nonlocal maintenance and diagnostic activities are those activities conducted by individuals communicating through either an external network (e.g., the Internet) or an internal network." Those controls include approving, monitoring, and thoroughly documenting non-local maintenance, ensuring the tools used in the process are documented and consistent with organizational policy, ensuring strong authenticators are employed during such maintenance sessions, and ensuring those sessions and network connections are terminated upon completion of maintenance activities.

Additional resources:

MA-5 Maintenance personnel

This control recommends the organization establish a list of authorized third-party maintenance personnel and organizations and a process for vetting them. Additionally, a policy of ensuring those authorized personnel or organizations have the appropriate security authorizations and designated supervisory personnel when on-site.

Additional resources:

MA-6 Timely maintenance

This control recommends the organization designate a timeframe between which system component failure and maintenance support or component acquisition takes place. This will likely involve identifying the system components that are critical to maintaining system operations and organizational goals.

Additional resources:

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

MA-6 (1) Timely maintenance: Preventative maintenance

This control enhancement recommends the organization take a preventative maintenance approach to its system and components, scheduling at a defined frequency specific preventative maintenance actions on specified system components.

Additional resources:

MA-6 (2) Timely maintenance: Predictive maintenance

This control enhancement recommends the organization take a predictive maintenance approach to its system and components. This essentially means using "principles of statistical process control to determine at what point in the future maintenance activities will be appropriate," particularly "when the maintenance activity is most cost-effective and before the equipment loses performance within a threshold."

Additional resources:


Appendix 1.10 Media protection

MP-1 Media protection policy and procedures

This control recommends the organization develop, document, disseminate, review, and update media protection policies and procedures. It asks organizations to not only address the purpose, scope, roles, responsibilities, and enforcement of media protection action but also to address how those policies and procedures will be implemented, reviewed, and updated.

Additional resources:

MP-2 Media access

This control recommends the organization implement and enforce restrictions on specified digital and non-digital media, limiting access to only authorized personnel or roles within the organization. This will likely relate to controls on media containing sensitive, protected, or confidential data contained on the media.

Additional resources:

MP-6 Media sanitization

This control recommends the organization sanitize specified system media using authorized techniques prior to being disposed, released out of organizational control, or released for reuse. The techniques used should match the security or classification level assigned to the information contained on the media.

Additional resources:

MP-7 Media use

This control recommends the organization determine which, if any, digital and non-digital media should be prohibited from being used on which systems or system components. Note that "[i]n contrast to MP-2, which restricts user access to media, this control restricts the use of certain types of media on information systems, for example, restricting/prohibiting the use of flash drives or external hard disk drives" on the system or its subsystems.

Additional resources:

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


Appendix 1.11 Physical and environmental protection

PE-1 Physical and environmental protection policy and procedures

This control recommends the organization develop, document, disseminate, review, and update physical and environmental protection policies and procedures. It asks organizations to not only address the purpose, scope, roles, responsibilities, and enforcement of physical and environmental protection action but also to address how those policies and procedures will be implemented, reviewed, and updated.

Additional resources:

PE-2 Physical access authorizations

This control recommends the organization develop, approve, and maintain a list of individuals who are vetted and authorized to access the facilities where the system physically resides. Those individuals should be issued credentials to access the facility, and those credentials should be reviewed at a defined frequency. Those individuals who no longer require access to the facility should be removed from the physical access list promptly.

Additional resources:

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

PE-3 Physical access control

This control recommends the organization enact physical access controls through the facility where the system physically resides. Those controls include verifying individual access authorization before allowing admittance, using access control devices or personnel, maintaining physical access audit logs, providing security safeguards for accessing controlled areas from public areas, escorting visitors, monitoring visitor activity, securing keys and passwords controls, inventorying physical access devices regularly, and changing keys and password controls when circumstances require.

Additional resources:

PE-3 (1) Physical access control: Information system access

This control enhancement recommends the organization provide, in addition to overall facility access control, a mechanism for physically securing areas within the facility that house critical information system components.

Additional resources:

PE-6 Monitoring physical access

This control recommends the organization monitor the areas within the facility that house critical information system components for detecting and responding to physical security incidents. The organization should also review physical access logs at a determined frequency or when a security event (or possibility of a security event) is identified. Individuals with responsibility for monitoring the system's physical locations should also coordinate with the incident response team in reviews and investigations.

Additional resources:

PE-6 (1) Monitoring physical access: Intrusion alarms and surveillance equipment

This control enhancement recommends the organization monitor physical intrusion alarms and surveillance equipment.

Additional resources:

PE-6 (4) Monitoring physical access: Monitoring physical access to information systems

This control enhancement recommends the organization provide, in addition to overall facility monitoring, a means of monitoring areas within the facility that house critical information system components.

Additional resources:

PE-8 Visitor access recorded

This control recommends the organization retain visitor access records to the facility housing the physical information system for a designated period of time, reviewing those records at a defined frequency.

Additional resources:

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

PE-12 Emergency lighting

This control recommends the organization ensure the facility housing the physical information system employs and maintains automatic emergency lighting capable of activating off of its own independent power supply during a power outage or other type of disruption.

Additional resources:

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

PE-13 Fire protection

This control recommends the organization ensure the facility housing the physical information system employs and maintains fire suppression and detection systems capable of activating off of its own independent power supply during a fire incident.

Additional resources:

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

PE-14 Temperature and humidity controls

This control recommends the organization maintain temperature and humidity in the facility housing the physical information system at a defined set of acceptable levels, monitoring those levels at a defined frequency.

Additional resources:

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

PE-15 Water damage protection

This control recommends the organization ensure the facility housing the physical information system has emergency water shutoff or isolation valves that are accessible, functional, and clearly marked and known to personnel, with the goal of protecting the system components from water leakage.

Additional resources:

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

PE-16 Delivery and removal

This control recommends the organization ensure any pick-up or drop-off activities of information system components at the facility housing the physical information system are authorized, monitored, and controlled, preferably isolating such activities outside of areas where critical system components or media are located.

Additional resources:

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


Appendix 1.12 Planning

PL-1 Security planning policy and procedures

This control recommends the organization develop, document, disseminate, review, and update security planning policies and procedures. It asks organizations to not only address the purpose, scope, roles, responsibilities, and enforcement of security planning action but also to address how those policies and procedures will be implemented, reviewed, and updated.

Additional resources:

PL-2 System security plan

This control recommends the organization develop, distribute, review, update, and protect a security plan for its information system. The plan should take into consideration the organization's enterprise architecture and the organizations business and cybersecurity goals, defining the logical and physical boundaries of the system based on the architecture and goals. The operational environment, classification of the system's data, security configuration requirements, and necessary and proposed security controls should also be addressed. The plan should be reviewed and approved by designated personnel.

Additional resources:

PL-4 Rules of behavior

This control recommends the organization establish a set of baseline rules of behavior that address organizational expectations and personal responsibilities of users accessing the system. Each individual should sign an acknowledgment that they have read, understand, and agree to abide by the rules of behavior. Those baseline rules should be reviewed at a designated frequency, and if updates are made, the affected individuals should be required to read, understand, and sign acknowledgement of the revised rules.

Additional resources:


Appendix 1.13 Personnel security

PS-1 Personnel security policy and procedures

This control recommends the organization develop, document, disseminate, review, and update personnel security policies and procedures. It asks organizations to not only address the purpose, scope, roles, responsibilities, and enforcement of personnel security action but also to address how those policies and procedures will be implemented, reviewed, and updated.

Additional resources:

PS-2 Position risk designation

This control recommends the organization assign risk designations to all organizational positions. NIST states that risk designations "can guide and inform the types of authorizations individuals receive when accessing organizational information and information systems." Deciding on the appropriate risk level designation (e.g., high, moderate, or low) for a position may be "determined by the position's potential for adverse impact to the efficiency or integrity of the service."[9] Those authorizations should be created only after screening criteria for the position have been met. Additionally, the organization shouldreview and updated their risk designations at a defined frequency.

Additional resources:

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

PS-3 Personnel screening

This control recommends the organization perform a security screening of individuals before authorizing them to access the information system, as well as rescreen those individuals based on organization-defined conditions and frequencies.

Additional resources:

PS-4 Personnel termination

This control recommends the organization conduct a series of security steps upon termination of personnel. Those steps include disabling system access within an organization-defined period of time, revoking the individual's autheticators or credentials, having an exit interview with the individual about system security topics, retrieving any organizational information and property related to the information system controlled by the individual, and notifying the appropriate staff within an organization-defined period of time upon completion of these security steps.

Additional resources:

PS-5 Personnel transfer

This control recommends the organization conduct a series of security steps upon the reassignment or transfer of personnel. Those steps include reviewing and confirming the ongoing need for the individual's current access authorizations, initiating any necessary access modification or other types of action within an organization-defined period of time, and notifying the appropriate staff within an organization-defined period of time upon completion of these security steps.

Additional resources:

PS-6 Access agreements

This control recommends the organization develop, document, review, and update access agreements for organizational information systems, ensuring that individuals requiring access to the system sign the agreement before accessing the system and resign the agreement upon the agreement being updated by the organization, or at a designated frequency.

Additional resources:

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

PS-7 Third-part personnel security

This control recommends the organization establish a set of security requirements for third-party personnel. Those requirements should elaborate on third-party personnel security roles, responsibilities, and requirements; require said personnel to comply with organizational personnel security policy and procedures; require prompt notification from third-party providers when associated personnel possessing authenticators or credentials and who have access to the system transfer or leave; and compel the organization to monitor provider compliance.

Additional resources:

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

PS-8 Personnel sanctions

This control recommends the organization put into place a formal sanctions process for individuals who fail to comply with organizational information security policies and procedures. When a formal sanction process is initiated, the organization will notify designated personnel or roles within an organization-defined period of time of the sanctions, including who is affected and the reasoning behind the sanctions.

Additional resources:

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


Appendix 1.14 Risk assessment

RA-1 Risk assessment policy and procedures

This control recommends the organization develop, document, disseminate, review, and update risk assessment policies and procedures. It asks organizations to not only address the purpose, scope, roles, responsibilities, and enforcement of risk asssessment action but also to address how those policies and procedures will be implemented, reviewed, and updated.

Additional resources:

RA-2 Security categorization

This control recommends the organization categorize the information system and its data based on security. More specifically, NIST notes the security categorization should be based upon "the potential adverse impacts to organizational operations, organizational assets, and individuals if organizational information and information systems are comprised through a loss of confidentiality, integrity, or availability." Additionally, the organization should document the results and supporting rationale of the security categorization and ensure the results are reviewed and approved by the authorizing individuals or roles in the organization.

Additional resources:

RA-3 Risk assessment

This control recommends the organization conduct risk assessments of the information system and the data that is processed, stored, and transmitted within it. The assessment should address the likelihood and potential outcomes of unauthorized "access, use, disclosure, disruption, modification, or destruction" of the system and its data. The results of this assessment should be documented as part of a security plan, risk assessment report, or some other type of organizational document and disseminated to the appropriate individuals. The document should be reviewed at a defined frequency updated when significant changes to the system or cybersecurity threats occur.

Additional resources:

RA-5 Vulnerability scanning

This control recommends the organization conduct vulnerability scanning of its system. "Vulnerability scanning includes, for example: (i) scanning for patch levels; (ii) scanning for functions, ports, protocols, and services that should not be accessible to users or devices; and (iii) scanning for improperly configured or incorrectly operating information flow control mechanisms." These scans should occur at a defined frequency, randomly as part of organizational processes, or when new vulnerabilities have been identified. The tools employed should be standardized to detect software flaws and improper configurations using formatting checklists test procedures, while also measuring vulnerability impact. The organizations should analyze the results of these scans, remediated legitimate vulnerabilities, and share details with appropriate personnel or roles, particularly when vulnerabilities may affect other portions of the system.

Additional resources:


Appendix 1.15 System and services acquisition

SA-1 System and services acquisition policy and procedures

This control recommends the organization develop, document, disseminate, review, and update system and services acquisition policies and procedures. It asks organizations to not only address the purpose, scope, roles, responsibilities, and enforcement of system and services acquisition action but also to address how those policies and procedures will be implemented, reviewed, and updated.

Additional resources:

SA-2 Allocation of resources

This control recommends the organization determine, document, and allocate the resources required to protect the information system and its service as part of business process planning, capital planning, and cybersecurity planning. Those associated plans should have a discrete line item pertaining to information security.

Additional resources:

SA-3 System development lifecycle

This control recommends the organization use a system development life cycle in the management of its information system. As part of this approach, the organization should define and document security roles and responsibilities for the phases of the life cycle, identify the key individuals involved, and ensure the organization's security risk management process is integrated into development life cycle activities. As such, the development life cycle benefits from consistency "with organizational risk management and information security strategies."

Additional resources:

SA-4 Acquisition process

This control recommends the organization, as part of the acquisition process, include security functional, strength, and assurance requirements; requirements for security documentation and its protection; description of the developmental and operational system environments; and acceptance criteria in the acquisition contracts for the information system, its components, and its services.

Additional resources:

SA-4 (1) Acquisition process: Functional properties of security controls

This control enhancement recommends the organization require of an information system, system component, or software developer a description of the functional properties of the security controls (i.e., the functionality visible at the interfaces of the security controls) the system, component, or software will employ.

Additional resources:

SA-4 (2) Acquisition process: Design and implementation information for security controls

This control enhancement recommends the organization require of an information system, system component, or software developer information on the design and implementation of the security controls inherent to the system, component, or software. This could include security-relevant external system interfaces, high-level design, low-level design, source code, or hardware schematics.

Additional resources:

SA-4 (3) Acquisition process: Development methods, techniques, and practices

This control enhancement recommends the organization require of an information system, system component, or software developer proof of using a development life cycle that includes current and relevant system and security engineering methods, software development methods, testing and validation techniques, and quality control procedures.

Additional resources:

SA-5 Information system documentation

This control recommends the organization require of an information system, system component, or software developer administrator documentation that describes configuration, installation, and operation; effective use and maintenance of security mechanisms; known vulnerabilities of privileged functions; best user practices to ensure system security; and administrator and user responsibilities for maintaining the security. The organization should document any attempts (and failures) to acquire such administrator documentation, protect that documentation internally, and distribute it to the appropriate personnel or roles.

Additional resources:

SA-9 External information system services

This control recommends the organization hold providers of external information system services accountable to organizational security requirements, as well as defined security controls. The organization should also document government oversight and user roles and responsibilities associated with the services. The organization should also monitor the external information system services provider for compliance with organizational security requirements and security controls.

Additional resources:

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

SA-16 Developer-provided training

This control recommends the organization require of an information system, system component, or software developer specific training on the correct operation of the security functions, controls, and mechanisms of the system, system component, or software.

Additional resources:


Appendix 1.16 System and communications protection

SC-1 System and communications protection policy and procedures

This control recommends the organization develop, document, disseminate, review, and update system and communications protection policies and procedures. It asks organizations to not only address the purpose, scope, roles, responsibilities, and enforcement of system and communications protection action but also to address how those policies and procedures will be implemented, reviewed, and updated.

Additional resources:

SC-5 Denial of service protection

This control recommends the system be capable of protecting against and limiting the damage from a denial of service (DoS) attack by using specific safeguards. The organization will typically identify what types of DoS attacks are most likely to be a risk and state its plans for safeguarding against them.

Additional resources:

  • No LIMSpec comp (largely outside the domain of laboratory software and more the domain of networking and IT systems)

SC-7 Boundary protection

This control recommends the system monitor and control communications at external logical boundaries and at critical internal logical boundaries. Additionally subnetworks for publicly accessible system components that are logically or physically separated from internal networks should be implemented. The system should solely depend on managed interfaces (boundary detection devices) for connecting to external networks and information systems.

Additional resources:

SC-12 Cryptographic key establishment and management

This control recommends the organization establish and manage cryptographic keys for the cryptography modules implemented within the system using organization-defined key generation, distribution, storage, access, and destruction requirements.

Additional resources:

SC-13 Cryptographic protection

This control recommends the system implement the types and uses of cryptography required for organizational security in such a way that they comply with applicable laws, regulations, and standards.

Additional resources:

SC-15 Collaborative computing devices

This control recommends the system prohibit remote activation of collaborative computing devices such as attached cameras, microphones, and networked whiteboards, unless explicitly allowed by the organization. Additional, the system should provide an explicit notification that the device is in use to users physically present at the device.

Additional resources:

SC-20 Secure name-address resolutions service and use of an authoritative source

This control recommends the system, when returning a response to external name-address resolution queries, provide additional contextual information about the origin and integrity of the data received. Additional, the system should indicate what security statuses exist for child zones and enable chain-of-trust verification among parent and child domains, particularly when operating as part of a distributed, hierarchical namespace. (Note that this control is networking-related and difficult to put into simplified terms.)

Additional resources:

SC-21 Secure name-address resolutions service and use of a recursive or caching resolver

This control recommends the system request and perform authentication and data integrity verification of the name-address resolution responses it receives. (Note that this control is networking-related and difficult to put into simplified terms.)

Additional resources:

SC-22 Architecture and provision for name-address resolution service

This control recommends the system be fault-tolerant and implement internal-external role separation if it collectively provides a name-address resolution service to the organization. (Note that this control is networking-related and difficult to put into simplified terms.)

Additional resources:

SC-28 Protection of information at rest

This control recommends the system protect the confidentiality and/or integrity of designated information at rest contained in the system. (" Information at rest refers to the state of information when it is located on storage devices as specific components of information systems.")

Additional resources:

SC-28 (1) Protection of information at rest: Cryptographic protection

This control enhancement recommends the system be capable of implementing cryptographic mechanisms to protect against the misuse and modification of specified organizational information housed in specified system components (or across the entire system).

Additional resources:

SC-39 Process isolation

This control recommends the system maintain a separate execution domain for each executing process (i.e., assign each process a separate address space) "so that communication between processes is performed in a manner controlled through the security functions, and one process cannot modify the executing code of another process."

Additional resources:


Appendix 1.17 System and information integrity

SI-1 System and information integrity policy and procedures

This control recommends the organization develop, document, disseminate, review, and update system and information integrity policies and procedures. It asks organizations to not only address the purpose, scope, roles, responsibilities, and enforcement of system and information integrity action but also to address how those policies and procedures will be implemented, reviewed, and updated.

Additional resources:

SI-2 Flaw remediation

This control recommends the organization identify, report, and correct flaws in the information system. When attempting to correct a flaw with a software of firmware update, the organization should first test the effectiveness and potential side effects of the update before installing on the operational system. The organization should agree to update flaws withing an organization-defined time period after the release of the update, and incorporate flaw remediation into the organization's existing configuration management processes and procedures.

Additional resources:

SI-2 (5) Flaw remediation: Automatic software and firmware updates

This control enhancement recommends the organization selectively employ automatic mechanisms for the installation of specified security-relevant software and firmware updates to specified system components (or across the entire system).

Additional resources:

SI-3 Malicious code protection

This control recommends the organization employ, configure, and regularly update malicious code protection mechanisms at information system entry and exit points. The configuration of these mechanisms should allow for periodic scans of the system at a defined frequency, as well as real-time scans of external files, and should also block malicious code, quarantine it, and/or send alerts to an administrator or specific organizational role. The mechanisms should also allow the organization to manage false positives and their potential impact on the system.

Additional resources:

SI-4 Information system monitoring

This control recommends the organization employ various forms of monitoring on the system in order to detect attacks, unauthorized local, network, and remote connections; and unauthorized processes, either actual or indications of. The forms of monitoring used should deployed strategically with the system and at ad hoc locations, and those forms of monitoring should be vetted with legal opinion in regard to their adherence to laws and regulations. The organization should protect protect information gained from monitoring the system and heighten the level of monitoring when indications exist of increased risk to the system. Finally, the organization should disseminate monitoring information to designated personnel or roles as needed or at a defined frequency.

Additional resources:

SI-4 (5) Information system monitoring: System-generated alerts

This control enhancement recommends the system send alerts to designated personnel or roles when any of a list of organization-defined indications of compromise or potential compromise occur.

Additional resources:

SI-4 (7) Information system monitoring: Automated response to suspicious alerts

This control enhancement recommends the system send alerts to designated personnel or roles when a suspicious event is detected and then take the least-disruptive action from a list of organizational-defined actions in order to terminate the suspicious event.

Additional resources:

SI-5 Security alerts, advisories, and directives

This control recommends the organization choose a source for information system security alerts, advisories, and directives and receive regular updates from the source. Additionally, the organization should generate their own internal security alerts, advisories, and directives when necessary. In all cases, this received and generated information should be disseminated to defined personnel, roles, groups, external organizations, etc. Of course, the organization should also act upon the information received, implementing a fix within an established time frame, notifying a designated individual or role of any degree of noncompliance.

Additional resources:

SI-12 Information handling and retention

This control recommends the organization manage and retain information stored and transmitted within the system according law, regulation, standards, and operational requirements.

Additional resources:

SI-16 Memory protection

This control recommends the organization choose and employ hardware- or software-enforced security safeguards into the system that protect its memory from unauthorized code execution. Safeguards might include methods such as data execution prevention and address space layout randomization.

Additional resources:

  • No LIMSpec comp (largely outside the domain of laboratory software and more the domain of networking and IT systems)

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 07 December 2019. 
  2. ↑ "Access Control Policy and Implementation Guides". Computer Security Resource Center. National Institute of Standards and Technology. 29 March 2018. https://csrc.nist.gov/Projects/Access-Control-Policy-and-Implementation-Guides. Retrieved 07 December 2019. 
  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 08 December 2019. 
  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 10 December 2019. 
  5. ↑ "UIS.203.7 Least Functionality Guidelines". UIS.203 Configuration Management Policy. University Information Security Office, Georgetown University. https://security.georgetown.edu/config-mgt-policy/least-functionality-guidelines/. Retrieved 10 December 2019. 
  6. ↑ 6.0 6.1 "Introduction - PIV Guides". PIV Usage Guides. General Services Administration. https://piv.idmanagement.gov/. Retrieved 12 December 2019. 
  7. ↑ "PKI Tokens". Microcosm Ltd. https://www.microcosm.com/products/pki-tokens. Retrieved 12 December 2019. 
  8. ↑ 8.0 8.1 8.2 "Introduction". Federal Identity, Credential, and Access Management Architecture. General Services Administration. https://arch.idmanagement.gov/. Retrieved 12 December 2019. 
  9. ↑ "5 CFR § 731.106 - Designation of public trust positions and investigative requirements". Legal Information Institute. Cornell. https://www.law.cornell.edu/cfr/text/5/731.106. Retrieved 13 December 2019. 
Retrieved from "https://www.limswiki.org/index.php?title=User:Shawndouglas/sandbox/sublevel30&oldid=37111"