personnel or roles to whom the access control policy is to be disseminated - is/are defined;
-personnel or roles to whom the access control procedures are to be - disseminated is/are defined;
-an official to manage the access control policy and procedures is defined;
-the frequency at which the current access control policy is reviewed and - updated is defined;
-events that would require the current access control policy to be reviewed - and updated are defined;
-the frequency at which the current access control procedures are reviewed and - updated is defined;
-events that would require procedures to be reviewed and updated are defined;
-Develop, document, and disseminate to
Addresses purpose, scope, roles, responsibilities, management - commitment, coordination among organizational entities, and - compliance; and
-Is consistent with applicable laws, executive orders, directives, - regulations, policies, standards, and guidelines; and
-Procedures to facilitate the implementation of the access control policy - and the associated access controls;
-Designate an
Review and update the current access control:
-Policy
Procedures
Access control policy and procedures address the controls in the AC family that - are implemented within systems and organizations. The risk management strategy - is an important factor in establishing such policies and procedures. Policies - and procedures contribute to security and privacy assurance. Therefore, it is - important that security and privacy programs collaborate on the development of - access control policy and procedures. Security and privacy program policies and - procedures at the organization level are preferable, in general, and may obviate - the need for mission- or system-specific policies and procedures. The policy can - be included as part of the general security and privacy policy or be represented - by multiple policies reflecting the complex nature of organizations. Procedures - can be established for security and privacy programs, for mission or business - processes, and for systems, if needed. Procedures describe how the policies or - controls are implemented and can be directed at the individual or role that is - the object of the procedure. Procedures can be documented in system security and - privacy plans or in one or more separate documents. Events that may precipitate - an update to access control policy and procedures include assessment or audit - findings, security incidents or breaches, or changes in laws, executive orders, - directives, regulations, policies, standards, and guidelines. Simply restating - controls does not constitute an organizational policy or procedure.
-an access control policy is developed and documented;
- -the access control policy is disseminated to
access control procedures to facilitate the implementation of the access - control policy and associated controls are developed and documented;
- -the access control procedures are disseminated to
the
the
the
the
the
the
the
the
the
the current access control policy is reviewed and updated
the current access control policy is reviewed and updated following
the current access control procedures are reviewed and updated
the current access control procedures are reviewed and updated
- following
Access control policy and procedures
-system security plan
-privacy plan
-other relevant documents or records
-Organizational personnel with access control responsibilities
-organizational personnel with information security with information security - and privacy responsibilities
-prerequisites and criteria for group and role membership are defined;
-attributes (as required) for each account are defined;
-personnel or roles required to approve requests to create accounts is/are - defined;
-policy, procedures, prerequisites, and criteria for account creation, - enabling, modification, disabling, and removal are defined;
-personnel or roles to be notified is/are defined;
-time period within which to notify account managers when accounts are no - longer required is defined;
-time period within which to notify account managers when users are terminated - or transferred is defined;
-time period within which to notify account managers when system usage or the - need to know changes for an individual is defined;
-attributes needed to authorize system access (as required) are defined;
-the frequency of account review is defined;
-Define and document the types of accounts allowed and specifically prohibited - for use within the system;
-Assign account managers;
-Require
Specify:
-Authorized users of the system;
-Group and role membership; and
-Access authorizations (i.e., privileges) and
Require approvals by
Create, enable, modify, disable, and remove accounts in accordance with
Monitor the use of accounts;
-Notify account managers and
Authorize access to the system based on:
-A valid access authorization;
-Intended system usage; and
-Review accounts for compliance with account management requirements
Establish and implement a process for changing shared or group account - authenticators (if deployed) when individuals are removed from the group; - and
-Align account management processes with personnel termination and transfer - processes.
-Examples of system account types include individual, shared, group, system, - guest, anonymous, emergency, developer, temporary, and service. Identification - of authorized system users and the specification of access privileges reflect - the requirements in other controls in the security plan. Users requiring - administrative privileges on system accounts receive additional scrutiny by - organizational personnel responsible for approving such accounts and privileged - access, including system owner, mission or business owner, senior agency - information security officer, or senior agency official for privacy. Types of - accounts that organizations may wish to prohibit due to increased risk include - shared, group, emergency, anonymous, temporary, and guest accounts.
-Where access involves personally identifiable information, security programs - collaborate with the senior agency official for privacy to establish the - specific conditions for group and role membership; specify authorized users, - group and role membership, and access authorizations for each account; and - create, adjust, or remove system accounts in accordance with organizational - policies. Policies can include such information as account expiration dates or - other factors that trigger the disabling of accounts. Organizations may choose - to define access privileges or other attributes by account, type of account, or - a combination of the two. Examples of other attributes required for authorizing - access include restrictions on time of day, day of week, and point of origin. In - defining other system account attributes, organizations consider system-related - requirements and mission/business requirements. Failure to consider these - factors could affect system availability.
-Temporary and emergency accounts are intended for short-term use. Organizations - establish temporary accounts as part of normal account activation procedures - when there is a need for short-term accounts without the demand for immediacy in - account activation. Organizations establish emergency accounts in response to - crisis situations and with the need for rapid account activation. Therefore, - emergency account activation may bypass normal account authorization processes. - Emergency and temporary accounts are not to be confused with infrequently used - accounts, including local logon accounts used for special tasks or when network - resources are unavailable (may also be known as accounts of last resort). Such - accounts remain available and are not subject to automatic disabling or removal - dates. Conditions for disabling or deactivating accounts include when - shared/group, emergency, or temporary accounts are no longer required and when - individuals are transferred or terminated. Changing shared/group authenticators - when members leave the group is intended to ensure that former group members do - not retain access to the shared or group account. Some types of system accounts - may require specialized training.
-account types allowed for use within the system are defined and - documented;
- -account types specifically prohibited for use within the system are - defined and documented;
- -account managers are assigned;
- -authorized users of the system are specified;
- -group and role membership are specified;
- -access authorizations (i.e., privileges) are specified for each - account;
- -approvals are required by
accounts are created in accordance with
accounts are enabled in accordance with
accounts are modified in accordance with
accounts are disabled in accordance with
accounts are removed in accordance with
the use of accounts is monitored;
- -account managers and
account managers and
account managers and
access to the system is authorized based on a valid access authorization;
- -access to the system is authorized based on intended system usage;
- -access to the system is authorized based on
accounts are reviewed for compliance with account management requirements
a process is established for changing shared or group account - authenticators (if deployed) when individuals are removed from the - group;
- -a process is implemented for changing shared or group account - authenticators (if deployed) when individuals are removed from the - group;
- -account management processes are aligned with personnel termination - processes;
- -account management processes are aligned with personnel transfer - processes.
- -Access control policy
-personnel termination policy and procedure
-personnel transfer policy and procedure
-procedures for addressing account management
-system design documentation
-system configuration settings and associated documentation
-list of active system accounts along with the name of the individual - associated with each account
-list of recently disabled system accounts and the name of the individual - associated with each account
-list of conditions for group and role membership
-notifications of recent transfers, separations, or terminations of employees
-access authorization records
-account management compliance reviews
-system monitoring records
-system audit records
-system security plan
-privacy plan
-other relevant documents or records
-Organizational personnel with account management responsibilities
-system/network administrators
-organizational personnel with information security with information security - and privacy responsibilities
-Organizational processes for account management on the system
-mechanisms for implementing account management
-automated mechanisms used to support the management of system accounts - are defined;
-Support the management of system accounts using
Automated system account management includes using automated mechanisms to - create, enable, modify, disable, and remove accounts; notify account - managers when an account is created, enabled, modified, disabled, or - removed, or when users are terminated or transferred; monitor system account - usage; and report atypical system account usage. Automated mechanisms can - include internal system functions and email, telephonic, and text messaging - notifications.
-the management of system accounts is supported using
Access control policy
-procedures for addressing account management
-system design documentation
-system configuration settings and associated documentation
-system audit records
-system security plan
-other relevant documents or records
-Organizational personnel with account management responsibilities
-system/network administrators
-organizational personnel with information security with information - security responsibilities
-system developers
-Automated mechanisms for implementing account management functions
-the time period after which to automatically remove or disable temporary - or emergency accounts is defined;
-Automatically
Management of temporary and emergency accounts includes the removal or - disabling of such accounts automatically after a predefined time period - rather than at the convenience of the system administrator. Automatic - removal or disabling of accounts provides a more consistent implementation.
-temporary and emergency accounts are automatically
Access control policy
-procedures for addressing account management
-system design documentation
-system configuration settings and associated documentation
-system-generated list of temporary accounts removed and/or disabled
-system-generated list of emergency accounts removed and/or disabled
-system audit records
-system security plan
-other relevant documents or records
-Organizational personnel with account management responsibilities
-system/network administrators
-organizational personnel with information security with information - security responsibilities
-system developers
-Automated mechanisms for implementing account management functions
-time period within which to disable accounts is defined;
-time period for account inactivity before disabling is defined;
-Disable accounts within
Have expired;
-Are no longer associated with a user or individual;
-Are in violation of organizational policy; or
-Have been inactive for
Disabling expired, inactive, or otherwise anomalous accounts supports the - concepts of least privilege and least functionality which reduce the attack - surface of the system.
-accounts are disabled within
accounts are disabled within
accounts are disabled within
accounts are disabled within
Access control policy
-procedures for addressing account management
-system security plan
-system design documentation
-system configuration settings and associated documentation
-system-generated list of accounts removed
-system-generated list of emergency accounts disabled
-system audit records
-system security plan
-other relevant documents or records
-Organizational personnel with account management responsibilities
-system/network administrators
-organizational personnel with information security responsibilities
-system developers
-Mechanisms for implementing account management functions
-Automatically audit account creation, modification, enabling, disabling, and - removal actions.
-Account management audit records are defined in accordance with AU-02 and reviewed, analyzed, and reported in - accordance with AU-06.
-account creation is automatically audited;
- -account modification is automatically audited;
- -account enabling is automatically audited;
- -account disabling is automatically audited;
- -account removal actions are automatically audited.
- -Access control policy
-procedures addressing account management
-system design documentation
-system configuration settings and associated documentation
-notifications/alerts of account creation, modification, enabling, - disabling, and removal actions
-system audit records
-system security plan
-other relevant documents or records
-Organizational personnel with account management responsibilities
-system/network administrators
-organizational personnel with information security responsibilities
-Automated mechanisms implementing account management functions
-the time period of expected inactivity or description of when to log out - is defined;
-Require that users log out when
Inactivity logout is behavior- or policy-based and requires users to take - physical action to log out when they are expecting inactivity longer than - the defined period. Automatic enforcement of inactivity logout is addressed - by AC-11.
-users are required to log out when
Access control policy
-procedures addressing account management
-system design documentation
-system configuration settings and associated documentation
-security violation reports
-system audit records
-system security plan
-other relevant documents or records
-Organizational personnel with account management responsibilities
-system/network administrators
-organizational personnel with information security responsibilities
-users that must comply with inactivity logout policy
-time period within which to disable accounts of individuals who are - discovered to pose significant risk is defined;
-significant risks leading to disabling accounts are defined;
-Disable accounts of individuals within
Users who pose a significant security and/or privacy risk include individuals - for whom reliable evidence indicates either the intention to use authorized - access to systems to cause harm or through whom adversaries will cause harm. - Such harm includes adverse impacts to organizational operations, - organizational assets, individuals, other organizations, or the Nation. - Close coordination among system administrators, legal staff, human resource - managers, and authorizing officials is essential when disabling system - accounts for high-risk individuals.
-accounts of individuals are disabled within
Access control policy
-procedures addressing account management
-system design documentation
-system configuration settings and associated documentation
-system-generated list of disabled accounts
-list of user activities posing significant organizational risk
-system audit records
-system security plan
-other relevant documents or records
-Organizational personnel with account management responsibilities
-system/network administrators
-organizational personnel with information security responsibilities
-Mechanisms implementing account management functions
-Enforce approved authorizations for logical access to information and system - resources in accordance with applicable access control policies.
-Access control policies control access between active entities or subjects (i.e., - users or processes acting on behalf of users) and passive entities or objects - (i.e., devices, files, records, domains) in organizational systems. In addition - to enforcing authorized access at the system level and recognizing that systems - can host many applications and services in support of mission and business - functions, access enforcement mechanisms can also be employed at the application - and service level to provide increased information security and privacy. In - contrast to logical access controls that are implemented within the system, - physical access controls are addressed by the controls in the Physical and - Environmental Protection ( PE ) family.
-approved authorizations for logical access to information and system resources - are enforced in accordance with applicable access control policies.
- -Access control policy
-procedures addressing access enforcement
-system design documentation
-system configuration settings and associated documentation
-list of approved authorizations (user privileges)
-system audit records
-system security plan
-privacy plan
-other relevant documents or records
-Organizational personnel with access enforcement responsibilities
-system/network administrators
-organizational personnel with information security and privacy - responsibilities
-system developers
-Mechanisms implementing access control policy
-information flow control policies within the system and between connected - systems are defined;
-Enforce approved authorizations for controlling the flow of information within
- the system and between connected systems based on
Information flow control regulates where information can travel within a system - and between systems (in contrast to who is allowed to access the information) - and without regard to subsequent accesses to that information. Flow control - restrictions include blocking external traffic that claims to be from within the - organization, keeping export-controlled information from being transmitted in - the clear to the Internet, restricting web requests that are not from the - internal web proxy server, and limiting information transfers between - organizations based on data structures and content. Transferring information - between organizations may require an agreement specifying how the information - flow is enforced (see CA-3 ). Transferring information - between systems in different security or privacy domains with different security - or privacy policies introduces the risk that such transfers violate one or more - domain security or privacy policies. In such situations, information - owners/stewards provide guidance at designated policy enforcement points between - connected systems. Organizations consider mandating specific architectural - solutions to enforce specific security and privacy policies. Enforcement - includes prohibiting information transfers between connected systems (i.e., - allowing access only), verifying write permissions before accepting information - from another security or privacy domain or connected system, employing hardware - mechanisms to enforce one-way information flows, and implementing trustworthy - regrading mechanisms to reassign security or privacy attributes and labels.
-Organizations commonly employ information flow control policies and enforcement - mechanisms to control the flow of information between designated sources and - destinations within systems and between connected systems. Flow control is based - on the characteristics of the information and/or the information path. - Enforcement occurs, for example, in boundary protection devices that employ rule - sets or establish configuration settings that restrict system services, provide - a packet-filtering capability based on header information, or provide a - message-filtering capability based on message content. Organizations also - consider the trustworthiness of filtering and/or inspection mechanisms (i.e., - hardware, firmware, and software components) that are critical to information - flow enforcement. Control enhancements 3 through 32 primarily address - cross-domain solution needs that focus on more advanced filtering techniques, - in-depth analysis, and stronger flow enforcement mechanisms implemented in - cross-domain products, such as high-assurance guards. Such capabilities are - generally not available in commercial off-the-shelf products. Information flow - enforcement also applies to control plane traffic (e.g., routing and DNS).
-approved authorizations are enforced for controlling the flow of information
- within the system and between connected systems based on
Access control policy
-information flow control policies
-procedures addressing information flow enforcement
-security architecture documentation
-privacy architecture documentation
-system design documentation
-system configuration settings and associated documentation
-system baseline configuration
-list of information flow authorizations
-system audit records
-system security plan
-privacy plan
-other relevant documents or records
-System/network administrators
-organizational personnel with information security and privacy architecture - development responsibilities
-organizational personnel with information security and privacy - responsibilities
-system developers
-Mechanisms implementing information flow enforcement policy
-duties of individuals requiring separation are defined;
-Identify and document
Define system access authorizations to support separation of duties.
-Separation of duties addresses the potential for abuse of authorized privileges - and helps to reduce the risk of malevolent activity without collusion. - Separation of duties includes dividing mission or business functions and support - functions among different individuals or roles, conducting system support - functions with different individuals, and ensuring that security personnel who - administer access control functions do not also administer audit functions. - Because separation of duty violations can span systems and application domains, - organizations consider the entirety of systems and system components when - developing policy on separation of duties. Separation of duties is enforced - through the account management activities in AC-2 , access - control mechanisms in AC-3 , and identity management - activities in IA-2, IA-4 , and IA-12.
-system access authorizations to support separation of duties are defined.
- -Access control policy
-procedures addressing divisions of responsibility and separation of duties
-system configuration settings and associated documentation
-list of divisions of responsibility and separation of duties
-system access authorizations
-system audit records
-system security plan
-other relevant documents or records
-Organizational personnel with responsibilities for defining appropriate - divisions of responsibility and separation of duties
-organizational personnel with information security responsibilities
-system/network administrators
-Mechanisms implementing separation of duties policy
-Employ the principle of least privilege, allowing only authorized accesses for - users (or processes acting on behalf of users) that are necessary to accomplish - assigned organizational tasks.
-Organizations employ least privilege for specific duties and systems. The - principle of least privilege is also applied to system processes, ensuring that - the processes have access to systems and operate at privilege levels no higher - than necessary to accomplish organizational missions or business functions. - Organizations consider the creation of additional processes, roles, and accounts - as necessary to achieve least privilege. Organizations apply least privilege to - the development, implementation, and operation of organizational systems.
-the principle of least privilege is employed, allowing only authorized accesses - for users (or processes acting on behalf of users) that are necessary to - accomplish assigned organizational tasks.
- -Access control policy
-procedures addressing least privilege
-list of assigned access authorizations (user privileges)
-system configuration settings and associated documentation
-system audit records
-system security plan
-other relevant documents or records
-Organizational personnel with responsibilities for defining least privileges - necessary to accomplish specified tasks
-organizational personnel with information security responsibilities
-system/network administrators
-Mechanisms implementing least privilege functions
-individuals and roles with authorized access to security functions and - security-relevant information are defined;
-security functions (deployed in hardware) for authorized access are - defined;
-security functions (deployed in software) for authorized access are - defined;
-security functions (deployed in firmware) for authorized access are - defined;
-security-relevant information for authorized access is defined;
-Authorize access for
Security functions include establishing system accounts, configuring access - authorizations (i.e., permissions, privileges), configuring settings for - events to be audited, and establishing intrusion detection parameters. - Security-relevant information includes filtering rules for routers or - firewalls, configuration parameters for security services, cryptographic key - management information, and access control lists. Authorized personnel - include security administrators, system administrators, system security - officers, system programmers, and other privileged users.
-access is authorized for
access is authorized for
access is authorized for
access is authorized for
Access control policy
-procedures addressing least privilege
-list of security functions (deployed in hardware, software, and firmware) - and security-relevant information for which access must be explicitly - authorized
-system configuration settings and associated documentation
-system audit records
-system security plan
-other relevant documents or records
-Organizational personnel with responsibilities for defining least - privileges necessary to accomplish specified tasks
-organizational personnel with information security responsibilities
-system/network administrators
-Mechanisms implementing least privilege functions
-security functions or security-relevant information, the access to which - requires users to use non-privileged accounts to access non-security - functions, are defined;
-Require that users of system accounts (or roles) with access to
Requiring the use of non-privileged accounts when accessing nonsecurity - functions limits exposure when operating from within privileged accounts or - roles. The inclusion of roles addresses situations where organizations - implement access control policies, such as role-based access control, and - where a change of role provides the same degree of assurance in the change - of access authorizations for the user and the processes acting on behalf of - the user as would be provided by a change between a privileged and - non-privileged account.
-users of system accounts (or roles) with access to
Access control policy
-procedures addressing least privilege
-list of system-generated security functions or security-relevant - information assigned to system accounts or roles
-system configuration settings and associated documentation
-system audit records
-system security plan
-other relevant documents or records
-Organizational personnel with responsibilities for defining least - privileges necessary to accomplish specified tasks
-organizational personnel with information security responsibilities
-system/network administrators
-Mechanisms implementing least privilege functions
-personnel or roles to which privileged accounts on the system are to be - restricted is/are defined;
-Restrict privileged accounts on the system to
Privileged accounts, including super user accounts, are typically described - as system administrator for various types of commercial off-the-shelf - operating systems. Restricting privileged accounts to specific personnel or - roles prevents day-to-day users from accessing privileged information or - privileged functions. Organizations may differentiate in the application of - restricting privileged accounts between allowed privileges for local - accounts and for domain accounts provided that they retain the ability to - control system configurations for key parameters and as otherwise necessary - to sufficiently mitigate risk.
-privileged accounts on the system are restricted to
Access control policy
-procedures addressing least privilege
-list of system-generated privileged accounts
-list of system administration personnel
-system configuration settings and associated documentation
-system audit records
-system security plan
-other relevant documents or records
-Organizational personnel with responsibilities for defining least - privileges necessary to accomplish specified tasks
-organizational personnel with information security responsibilities
-system/network administrators
-Mechanisms implementing least privilege functions
-the frequency at which to review the privileges assigned to roles or - classes of users is defined;
-roles or classes of users to which privileges are assigned are defined;
-Review
Reassign or remove privileges, if necessary, to correctly reflect - organizational mission and business needs.
-The need for certain assigned user privileges may change over time to reflect - changes in organizational mission and business functions, environments of - operation, technologies, or threats. A periodic review of assigned user - privileges is necessary to determine if the rationale for assigning such - privileges remains valid. If the need cannot be revalidated, organizations - take appropriate corrective actions.
-privileges assigned to
privileges are reassigned or removed, if necessary, to correctly reflect - organizational mission and business needs.
- -Access control policy
-procedures addressing least privilege
-list of system-generated roles or classes of users and assigned - privileges
-system design documentation
-system configuration settings and associated documentation
-validation reviews of privileges assigned to roles or classes or users
-records of privilege removals or reassignments for roles or classes of - users
-system audit records
-system security plan
-other relevant documents or records
-Organizational personnel with responsibilities for reviewing least - privileges necessary to accomplish specified tasks
-organizational personnel with information security responsibilities
-system/network administrators
-Mechanisms implementing review of user privileges
-Log the execution of privileged functions.
-The misuse of privileged functions, either intentionally or unintentionally - by authorized users or by unauthorized external entities that have - compromised system accounts, is a serious and ongoing concern and can have - significant adverse impacts on organizations. Logging and analyzing the use - of privileged functions is one way to detect such misuse and, in doing so, - help mitigate the risk from insider threats and the advanced persistent - threat.
-the execution of privileged functions is logged.
- -Access control policy
-procedures addressing least privilege
-system design documentation
-system configuration settings and associated documentation
-list of privileged functions to be audited
-list of audited events
-system audit records
-system security plan
-other relevant documents or records
-Organizational personnel with responsibilities for reviewing least - privileges necessary to accomplish specified tasks
-organizational personnel with information security responsibilities
-system/network administrators
-system developers
-Mechanisms auditing the execution of least privilege functions
-Prevent non-privileged users from executing privileged functions.
-Privileged functions include disabling, circumventing, or altering - implemented security or privacy controls, establishing system accounts, - performing system integrity checks, and administering cryptographic key - management activities. Non-privileged users are individuals who do not - possess appropriate authorizations. Privileged functions that require - protection from non-privileged users include circumventing intrusion - detection and prevention mechanisms or malicious code protection mechanisms. - Preventing non-privileged users from executing privileged functions is - enforced by AC-3.
-non-privileged users are prevented from executing privileged functions.
- -Access control policy
-procedures addressing least privilege
-system design documentation
-system configuration settings and associated documentation
-list of privileged functions and associated user account assignments
-system audit records
-system security plan
-other relevant documents or records
-Organizational personnel with responsibilities for defining least - privileges necessary to accomplish specified tasks
-organizational personnel with information security responsibilities
-system developers
-Mechanisms implementing least privilege functions for non-privileged - users
-the number of consecutive invalid logon attempts by a user allowed during a - time period is defined;
-the time period to which the number of consecutive invalid logon attempts by - a user is limited is defined;
-time period for an account or node to be locked is defined (if selected);
-delay algorithm for the next logon prompt is defined (if selected);
-other action to be taken when the maximum number of unsuccessful attempts is - exceeded is defined (if selected);
-Enforce a limit of
Automatically
The need to limit unsuccessful logon attempts and take subsequent action when the - maximum number of attempts is exceeded applies regardless of whether the logon - occurs via a local or network connection. Due to the potential for denial of - service, automatic lockouts initiated by systems are usually temporary and - automatically release after a predetermined, organization-defined time period. - If a delay algorithm is selected, organizations may employ different algorithms - for different components of the system based on the capabilities of those - components. Responses to unsuccessful logon attempts may be implemented at the - operating system and the application levels. Organization-defined actions that - may be taken when the number of allowed consecutive invalid logon attempts is - exceeded include prompting the user to answer a secret question in addition to - the username and password, invoking a lockdown mode with limited user - capabilities (instead of full lockout), allowing users to only logon from - specified Internet Protocol (IP) addresses, requiring a CAPTCHA to prevent - automated attacks, or applying user profiles such as location, time of day, IP - address, device, or Media Access Control (MAC) address. If automatic system - lockout or execution of a delay algorithm is not implemented in support of the - availability objective, organizations consider a combination of other actions to - help prevent brute force attacks. In addition to the above, organizations can - prompt users to respond to a secret question before the number of allowed - unsuccessful logon attempts is exceeded. Automatically unlocking an account - after a specified period of time is generally not permitted. However, exceptions - may be required based on operational mission or need.
-a limit of
automatically
Access control policy
-procedures addressing unsuccessful logon attempts
-system design documentation
-system configuration settings and associated documentation
-system audit records
-system security plan
-other relevant documents or records
-Organizational personnel with information security responsibilities
-system developers
-system/network administrators
-Mechanisms implementing access control policy for unsuccessful logon attempts
-system use notification message or banner to be displayed by the system to - users before granting access to the system is defined;
-conditions for system use to be displayed by the system before granting - further access are defined;
-Display
Users are accessing a U.S. Government system;
-System usage may be monitored, recorded, and subject to audit;
-Unauthorized use of the system is prohibited and subject to criminal and - civil penalties; and
-Use of the system indicates consent to monitoring and recording;
-Retain the notification message or banner on the screen until users - acknowledge the usage conditions and take explicit actions to log on to or - further access the system; and
-For publicly accessible systems:
-Display system use information
Display references, if any, to monitoring, recording, or auditing that - are consistent with privacy accommodations for such systems that - generally prohibit those activities; and
-Include a description of the authorized uses of the system.
-System use notifications can be implemented using messages or warning banners - displayed before individuals log in to systems. System use notifications are - used only for access via logon interfaces with human users. Notifications are - not required when human interfaces do not exist. Based on an assessment of risk, - organizations consider whether or not a secondary system use notification is - needed to access applications or other system resources after the initial - network logon. Organizations consider system use notification messages or - banners displayed in multiple languages based on organizational needs and the - demographics of system users. Organizations consult with the privacy office for - input regarding privacy messaging and the Office of the General Counsel or - organizational equivalent for legal review and approval of warning banner - content.
-the system use notification states that users are accessing a U.S. - Government system;
- -the system use notification states that system usage may be monitored, - recorded, and subject to audit;
- -the system use notification states that unauthorized use of the system is - prohibited and subject to criminal and civil penalties; and
- -the system use notification states that use of the system indicates - consent to monitoring and recording;
- -the notification message or banner is retained on the screen until users - acknowledge the usage conditions and take explicit actions to log on to or - further access the system;
- -for publicly accessible systems, system use information
for publicly accessible systems, any references to monitoring, recording, - or auditing that are consistent with privacy accommodations for such - systems that generally prohibit those activities are displayed;
- -for publicly accessible systems, a description of the authorized uses of - the system is included.
- -Access control policy
-privacy and security policies, procedures addressing system use notification
-documented approval of system use notification messages or banners
-system audit records
-user acknowledgements of notification message or banner
-system design documentation
-system configuration settings and associated documentation
-system use notification messages
-system security plan
-privacy plan
-privacy impact assessment
-privacy assessment report
-other relevant documents or records
-System/network administrators
-organizational personnel with information security and privacy - responsibilities
-legal counsel
-system developers
-Mechanisms implementing system use notification
-time period of inactivity after which a device lock is initiated is defined - (if selected);
-Prevent further access to the system by
Retain the device lock until the user reestablishes access using established - identification and authentication procedures.
-Device locks are 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. Device locks can be implemented at the operating - system level or at the application level. A proximity lock may be used to - initiate the device lock (e.g., via a Bluetooth-enabled device or dongle). - User-initiated device locking is behavior or policy-based and, as such, requires - users to take physical action to initiate the device lock. Device locks are not - an acceptable substitute for logging out of systems, such as when organizations - require users to log out at the end of workdays.
-further access to the system is prevented by
device lock is retained until the user re-establishes access using - established identification and authentication procedures.
- -Access control policy
-procedures addressing session lock
-procedures addressing identification and authentication
-system design documentation
-system configuration settings and associated documentation
-security plan
-system security plan
-other relevant documents or records
-System/network administrators
-organizational personnel with information security responsibilities
-system developers
-Mechanisms implementing access control policy for session lock
-Conceal, via the device lock, information previously visible on the display - with a publicly viewable image.
-The pattern-hiding display can include static or dynamic images, such as - patterns used with screen savers, photographic images, solid colors, clock, - battery life indicator, or a blank screen with the caveat that controlled - unclassified information is not displayed.
-information previously visible on the display is concealed, via device lock, - with a publicly viewable image.
- -Access control policy
-procedures addressing session lock
-display screen with session lock activated
-system design documentation
-system configuration settings and associated documentation
-system security plan
-other relevant documents or records
-System/network administrators
-organizational personnel with information security responsibilities
-system developers
-System session lock mechanisms
-conditions or trigger events requiring session disconnect are defined;
-Automatically terminate a user session after
Session termination addresses the termination of user-initiated logical sessions - (in contrast to SC-10 , which addresses the termination of - network connections associated with communications sessions (i.e., network - disconnect)). A logical session (for local, network, and remote access) is - initiated whenever a user (or process acting on behalf of a user) accesses an - organizational system. Such user sessions can be terminated without terminating - network sessions. Session termination ends all processes associated with a - user’s logical session except for those processes that are specifically created - by the user (i.e., session owner) to continue after the session is terminated. - Conditions or trigger events that require automatic termination of the session - include organization-defined periods of user inactivity, targeted responses to - certain types of incidents, or time-of-day restrictions on system use.
-a user session is automatically terminated after
Access control policy
-procedures addressing session termination
-system design documentation
-system configuration settings and associated documentation
-list of conditions or trigger events requiring session disconnect
-system audit records
-system security plan
-other relevant documents or records
-System/network administrators
-organizational personnel with information security responsibilities
-system developers
-Automated mechanisms implementing user session termination
-user actions that can be performed on the system without identification or - authentication are defined;
-Identify
Document and provide supporting rationale in the security plan for the - system, user actions not requiring identification or authentication.
-Specific user actions may be permitted without identification or authentication
- if organizations determine that identification and authentication are not
- required for the specified user actions. Organizations may allow a limited
- number of user actions without identification or authentication, including when
- individuals access public websites or other publicly accessible federal systems,
- when individuals use mobile phones to receive calls, or when facsimiles are
- received. Organizations identify actions that normally require identification or
- authentication but may, under certain circumstances, allow identification or
- authentication mechanisms to be bypassed. Such bypasses may occur, for example,
- via a software-readable physical switch that commands bypass of the logon
- functionality and is protected from accidental or unmonitored use. Permitting
- actions without identification or authentication does not apply to situations
- where identification and authentication have already occurred and are not
- repeated but rather to situations where identification and authentication have
- not yet occurred. Organizations may decide that there are no user actions that
- can be performed on organizational systems without identification and
- authentication, and therefore, the value for the assignment operation can be
- none.
user actions not requiring identification or authentication are - documented in the security plan for the system;
- -a rationale for user actions not requiring identification or - authentication is provided in the security plan for the system.
- -Access control policy
-procedures addressing permitted actions without identification or - authentication
-system configuration settings and associated documentation
-security plan
-list of user actions that can be performed without identification or - authentication
-system audit records
-system security plan
-other relevant documents or records
-System/network administrators
-organizational personnel with information security responsibilities
-Establish and document usage restrictions, configuration/connection - requirements, and implementation guidance for each type of remote access - allowed; and
-Authorize each type of remote access to the system prior to allowing such - connections.
-Remote access is access to organizational systems (or processes acting on behalf - of users) that communicate through external networks such as the Internet. Types - of remote access include dial-up, broadband, and wireless. Organizations use - encrypted virtual private networks (VPNs) to enhance confidentiality and - integrity for remote connections. The use of encrypted VPNs provides sufficient - assurance to the organization that it can effectively treat such connections as - internal networks if the cryptographic mechanisms used are implemented in - accordance with applicable laws, executive orders, directives, regulations, - policies, standards, and guidelines. Still, VPN connections traverse external - networks, and the encrypted VPN does not enhance the availability of remote - connections. VPNs with encrypted tunnels can also affect the ability to - adequately monitor network communications traffic for malicious code. Remote - access controls apply to systems other than public web servers or systems - designed for public access. Authorization of each remote access type addresses - authorization prior to allowing remote access without specifying the specific - formats for such authorization. While organizations may use information exchange - and system connection security agreements to manage remote access connections to - other systems, such agreements are addressed as part of CA-3 - . Enforcing access restrictions for remote access is addressed via AC-3.
-usage restrictions are established and documented for each type of remote - access allowed;
- -configuration/connection requirements are established and documented for - each type of remote access allowed;
- -implementation guidance is established and documented for each type of - remote access allowed;
- -each type of remote access to the system is authorized prior to allowing such - connections.
- -Access control policy
-procedures addressing remote access implementation and usage (including - restrictions)
-configuration management plan
-system configuration settings and associated documentation
-remote access authorizations
-system audit records
-system security plan
-other relevant documents or records
-Organizational personnel with responsibilities for managing remote access - connections
-system/network administrators
-organizational personnel with information security responsibilities
-Remote access management capability for the system
-Employ automated mechanisms to monitor and control remote access methods.
-Monitoring and control of remote access methods allows organizations to - detect attacks and help ensure compliance with remote access policies by - auditing the connection activities of remote users on a variety of system - components, including servers, notebook computers, workstations, smart - phones, and tablets. Audit logging for remote access is enforced by AU-2 . Audit events are defined in AU-2a.
-automated mechanisms are employed to monitor remote access methods;
- -automated mechanisms are employed to control remote access methods.
- -Access control policy
-procedures addressing remote access to the system
-system design documentation
-system configuration settings and associated documentation
-system audit records
-system monitoring records
-system security plan
-other relevant documents or records
-System/network administrators
-organizational personnel with information security responsibilities
-system developers
-Automated mechanisms monitoring and controlling remote access methods
-Implement cryptographic mechanisms to protect the confidentiality and - integrity of remote access sessions.
-Virtual private networks can be used to protect the confidentiality and - integrity of remote access sessions. Transport Layer Security (TLS) is an - example of a cryptographic protocol that provides end-to-end communications - security over networks and is used for Internet communications and online - transactions.
-cryptographic mechanisms are implemented to protect the confidentiality and - integrity of remote access sessions.
- -Access control policy
-procedures addressing remote access to the system
-system design documentation
-system configuration settings and associated documentation
-cryptographic mechanisms and associated configuration documentation
-system audit records
-system security plan
-other relevant documents or records
-System/network administrators
-organizational personnel with information security responsibilities
-system developers
-Cryptographic mechanisms protecting confidentiality and integrity of - remote access sessions
-Route remote accesses through authorized and managed network access control - points.
-Organizations consider the Trusted Internet Connections (TIC) initiative DHS TIC requirements - for external network connections since limiting the number of access control - points for remote access reduces attack surfaces.
-remote accesses are routed through authorized and managed network access - control points.
- -Access control policy
-procedures addressing remote access to the system
-system design documentation
-list of all managed network access control points
-system configuration settings and associated documentation
-system audit records
-system security plan
-other relevant documents or records
-System/network administrators
-organizational personnel with information security responsibilities
-Mechanisms routing all remote accesses through managed network access - control points
-needs requiring execution of privileged commands via remote access are - defined;
-needs requiring access to security-relevant information via remote access - are defined;
-Authorize the execution of privileged commands and access to
- security-relevant information via remote access only in a format that
- provides assessable evidence and for the following needs:
Document the rationale for remote access in the security plan for the - system.
-Remote access to systems represents a significant potential vulnerability - that can be exploited by adversaries. As such, restricting the execution of - privileged commands and access to security-relevant information via remote - access reduces the exposure of the organization and the susceptibility to - threats by adversaries to the remote access capability.
-the execution of privileged commands via remote access is authorized - only in a format that provides assessable evidence;
- -access to security-relevant information via remote access is - authorized only in a format that provides assessable evidence;
- -the execution of privileged commands via remote access is authorized
- only for the following needs:
access to security-relevant information via remote access is
- authorized only for the following needs:
the rationale for remote access is documented in the security plan for - the system.
- -Access control policy
-procedures addressing remote access to the system
-system configuration settings and associated documentation
-security plan
-system audit records
-system security plan
-other relevant documents or records
-System/network administrators
-organizational personnel with information security responsibilities
-Mechanisms implementing remote access management
-Establish configuration requirements, connection requirements, and - implementation guidance for each type of wireless access; and
-Authorize each type of wireless access to the system prior to allowing such - connections.
-Wireless technologies include microwave, packet radio (ultra-high frequency or - very high frequency), 802.11x, and Bluetooth. Wireless networks use - authentication protocols that provide authenticator protection and mutual - authentication.
-configuration requirements are established for each type of wireless - access;
- -connection requirements are established for each type of wireless access;
- -implementation guidance is established for each type of wireless access;
- -each type of wireless access to the system is authorized prior to allowing - such connections.
- -Access control policy
-procedures addressing wireless access implementation and usage (including - restrictions)
-configuration management plan
-system design documentation
-system configuration settings and associated documentation
-wireless access authorizations
-system audit records
-system security plan
-other relevant documents or records
-Organizational personnel with responsibilities for managing wireless access - connections
-organizational personnel with information security responsibilities
-Wireless access management capability for the system
-Protect wireless access to the system using authentication of
Wireless networking capabilities represent a significant potential - vulnerability that can be exploited by adversaries. To protect systems with - wireless access points, strong authentication of users and devices along - with strong encryption can reduce susceptibility to threats by adversaries - involving wireless technologies.
-wireless access to the system is protected using authentication of
wireless access to the system is protected using encryption.
- -Access control policy
-procedures addressing wireless implementation and usage (including - restrictions)
-system design documentation
-system configuration settings and associated documentation
-system audit records
-system security plan
-other relevant documents or records
-System/network administrators
-organizational personnel with information security responsibilities
-system developers
-Mechanisms implementing wireless access protections to the system
-Disable, when not intended for use, wireless networking capabilities embedded - within system components prior to issuance and deployment.
-Wireless networking capabilities that are embedded within system components - represent a significant potential vulnerability that can be exploited by - adversaries. Disabling wireless capabilities when not needed for essential - organizational missions or functions can reduce susceptibility to threats by - adversaries involving wireless technologies.
-when not intended for use, wireless networking capabilities embedded within - system components are disabled prior to issuance and deployment.
- -Access control policy
-procedures addressing wireless implementation and usage (including - restrictions)
-system design documentation
-system configuration settings and associated documentation
-system audit records
-system security plan
-other relevant documents or records
-System/network administrators
-organizational personnel with information security responsibilities
-Mechanisms managing the disabling of wireless networking capabilities - internally embedded within system components
-Establish configuration requirements, connection requirements, and - implementation guidance for organization-controlled mobile devices, to - include when such devices are outside of controlled areas; and
-Authorize the connection of mobile devices to organizational systems.
-A mobile device is a computing device that has a small form factor such that it - can easily be carried by a single individual; is designed to operate without a - physical connection; possesses local, non-removable or removable data storage; - and includes a self-contained power source. Mobile device functionality may also - include voice communication capabilities, on-board sensors that allow the device - to capture information, and/or built-in features for synchronizing local data - with remote locations. Examples include smart phones and tablets. Mobile devices - are typically associated with a single individual. The processing, storage, and - transmission capability of the mobile device may be comparable to or merely a - subset of notebook/desktop systems, depending on the nature and intended purpose - of the device. Protection and control of mobile devices is behavior or - policy-based and requires users to take physical action to protect and control - such devices when outside of controlled areas. Controlled areas are spaces for - which organizations provide physical or procedural controls to meet the - requirements established for protecting information and systems.
-Due to the large variety of mobile devices with different characteristics and - capabilities, organizational restrictions may vary for the different classes or - types of such devices. Usage restrictions and specific implementation guidance - for mobile devices include configuration management, device identification and - authentication, implementation of mandatory protective software, scanning - devices for malicious code, updating virus protection software, scanning for - critical software updates and patches, conducting primary operating system (and - possibly other resident software) integrity checks, and disabling unnecessary - hardware.
-Usage restrictions and authorization to connect may vary among organizational - systems. For example, the organization may authorize the connection of mobile - devices to its network and impose a set of usage restrictions, while a system - owner may withhold authorization for mobile device connection to specific - applications or impose additional usage restrictions before allowing mobile - device connections to a system. Adequate security for mobile devices goes beyond - the requirements specified in AC-19 . Many safeguards for - mobile devices are reflected in other controls. AC-20 - addresses mobile devices that are not organization-controlled.
-configuration requirements are established for organization-controlled - mobile devices, including when such devices are outside of the - controlled area;
- -connection requirements are established for organization-controlled - mobile devices, including when such devices are outside of the - controlled area;
- -implementation guidance is established for organization-controlled mobile - devices, including when such devices are outside of the controlled area;
- -the connection of mobile devices to organizational systems is authorized.
- -Access control policy
-procedures addressing access control for mobile device usage (including - restrictions)
-configuration management plan
-system design documentation
-system configuration settings and associated documentation
-authorizations for mobile device connections to organizational systems
-system audit records
-system security plan
-other relevant documents or records
-Organizational personnel using mobile devices to access organizational - systems
-system/network administrators
-organizational personnel with information security responsibilities
-Access control capability for mobile device connections to organizational - systems
-configurations of mobile devices
-mobile devices on which to employ encryption are defined;
-Employ
Container-based encryption provides a more fine-grained approach to data and - information encryption on mobile devices, including encrypting selected data - structures such as files, records, or fields.
-Access control policy
-procedures addressing access control for mobile devices
-system design documentation
-system configuration settings and associated documentation
-encryption mechanisms and associated configuration documentation
-system audit records
-system security plan
-other relevant documents or records
-Organizational personnel with access control responsibilities for mobile - devices
-system/network administrators
-organizational personnel with information security responsibilities
-Encryption mechanisms protecting confidentiality and integrity of - information on mobile devices
-terms and conditions consistent with the trust relationships established with - other organizations owning, operating, and/or maintaining external systems - are defined (if selected);
-controls asserted to be implemented on external systems consistent with the - trust relationships established with other organizations owning, operating, - and/or maintaining external systems are defined (if selected);
-types of external systems prohibited from use are defined;
-Access the system from external systems; and
-Process, store, or transmit organization-controlled information using - external systems; or
-Prohibit the use of
External systems are systems that are used by but not part of organizational - systems, and for which the organization has no direct control over the - implementation of required controls or the assessment of control effectiveness. - External systems include personally owned systems, components, or devices; - privately owned computing and communications devices in commercial or public - facilities; systems owned or controlled by nonfederal organizations; systems - managed by contractors; and federal information systems that are not owned by, - operated by, or under the direct supervision or authority of the organization. - External systems also include systems owned or operated by other components - within the same organization and systems within the organization with different - authorization boundaries. Organizations have the option to prohibit the use of - any type of external system or prohibit the use of specified types of external - systems, (e.g., prohibit the use of any external system that is not - organizationally owned or prohibit the use of personally-owned systems).
-For some external systems (i.e., systems operated by other organizations), the - trust relationships that have been established between those organizations and - the originating organization may be such that no explicit terms and conditions - are required. Systems within these organizations may not be considered external. - These situations occur when, for example, there are pre-existing information - exchange agreements (either implicit or explicit) established between - organizations or components or when such agreements are specified by applicable - laws, executive orders, directives, regulations, policies, or standards. - Authorized individuals include organizational personnel, contractors, or other - individuals with authorized access to organizational systems and over which - organizations have the authority to impose specific rules of behavior regarding - system access. Restrictions that organizations impose on authorized individuals - need not be uniform, as the restrictions may vary depending on trust - relationships between organizations. Therefore, organizations may choose to - impose different security restrictions on contractors than on state, local, or - tribal governments.
-External systems used to access public interfaces to organizational systems are - outside the scope of AC-20 . Organizations establish - specific terms and conditions for the use of external systems in accordance with - organizational security policies and procedures. At a minimum, terms and - conditions address the specific types of applications that can be accessed on - organizational systems from external systems and the highest security category - of information that can be processed, stored, or transmitted on external - systems. If the terms and conditions with the owners of the external systems - cannot be established, organizations may impose restrictions on organizational - personnel using those external systems.
-the use of
Access control policy
-procedures addressing the use of external systems
-external systems terms and conditions
-list of types of applications accessible from external systems
-maximum security categorization for information processed, stored, or - transmitted on external systems
-system configuration settings and associated documentation
-system security plan
-other relevant documents or records
-Organizational personnel with responsibilities for defining terms and - conditions for use of external systems to access organizational systems
-system/network administrators
-organizational personnel with information security responsibilities
-Mechanisms implementing terms and conditions on the use of external systems
-Permit authorized individuals to use an external system to access the system - or to process, store, or transmit organization-controlled information only - after:
-Verification of the implementation of controls on the external system as - specified in the organization’s security and privacy policies and - security and privacy plans; or
-Retention of approved system connection or processing agreements with the - organizational entity hosting the external system.
-Limiting authorized use recognizes circumstances where individuals using - external systems may need to access organizational systems. Organizations - need assurance that the external systems contain the necessary controls so - as not to compromise, damage, or otherwise harm organizational systems. - Verification that the required controls have been implemented can be - achieved by external, independent assessments, attestations, or other means, - depending on the confidence level required by organizations.
-authorized individuals are permitted to use an external system to access - the system or to process, store, or transmit organization-controlled - information only after verification of the implementation of controls on - the external system as specified in the organization’s security and - privacy policies and security and privacy plans (if applicable);
- -authorized individuals are permitted to use an external system to access - the system or to process, store, or transmit organization-controlled - information only after retention of approved system connection or - processing agreements with the organizational entity hosting the - external system (if applicable).
- -Access control policy
-procedures addressing the use of external systems
-system connection or processing agreements
-account management documents
-system security plan
-other relevant documents or records
-System/network administrators
-organizational personnel with information security responsibilities
-Mechanisms implementing limits on use of external systems
-restrictions on the use of organization-controlled portable storage - devices by authorized individuals on external systems are defined;
-Restrict the use of organization-controlled portable storage devices by
- authorized individuals on external systems using
Limits on the use of organization-controlled portable storage devices in - external systems include restrictions on how the devices may be used and - under what conditions the devices may be used.
-the use of organization-controlled portable storage devices by authorized
- individuals is restricted on external systems using
Access control policy
-procedures addressing the use of external systems
-system configuration settings and associated documentation
-system connection or processing agreements
-account management documents
-system security plan
-other relevant documents or records
-Organizational personnel with responsibilities for restricting or - prohibiting the use of organization-controlled storage devices on - external systems
-system/network administrators
-organizational personnel with information security responsibilities
-Mechanisms implementing restrictions on the use of portable storage - devices
-information-sharing circumstances where user discretion is required to - determine whether access authorizations assigned to a sharing partner match - the information’s access and use restrictions are defined;
-automated mechanisms or manual processes that assist users in making - information-sharing and collaboration decisions are defined;
-Enable authorized users to determine whether access authorizations assigned
- to a sharing partner match the information’s access and use restrictions for
Employ
Information sharing applies to information that may be restricted in some manner - based on some formal or administrative determination. Examples of such - information include, contract-sensitive information, classified information - related to special access programs or compartments, privileged information, - proprietary information, and personally identifiable information. Security and - privacy risk assessments as well as applicable laws, regulations, and policies - can provide useful inputs to these determinations. Depending on the - circumstances, sharing partners may be defined at the individual, group, or - organizational level. Information may be defined by content, type, security - category, or special access program or compartment. Access restrictions may - include non-disclosure agreements (NDA). Information flow techniques and - security attributes may be used to provide automated assistance to users making - sharing and collaboration decisions.
-authorized users are enabled to determine whether access authorizations
- assigned to a sharing partner match the information’s access and use
- restrictions for
Access control policy
-procedures addressing user-based collaboration and information sharing - (including restrictions)
-system design documentation
-system configuration settings and associated documentation
-list of users authorized to make information-sharing/collaboration decisions
-list of information-sharing circumstances requiring user discretion
-non-disclosure agreements
-acquisitions/contractual agreements
-system security plan
-privacy plan
-privacy impact assessment
-security and privacy risk assessments
-other relevant documents or records
-Organizational personnel responsible for information-sharing/collaboration - decisions
-organizational personnel with responsibility for acquisitions/contractual - agreements
-system/network administrators
-organizational personnel with information security and privacy - responsibilities
-Automated mechanisms or manual process implementing access authorizations - supporting information-sharing/user collaboration decisions
-the frequency at which to review the content on the publicly accessible - system for non-public information is defined;
-Designate individuals authorized to make information publicly accessible;
-Train authorized individuals to ensure that publicly accessible information - does not contain nonpublic information;
-Review the proposed content of information prior to posting onto the publicly - accessible system to ensure that nonpublic information is not included; and
-Review the content on the publicly accessible system for nonpublic
- information
In accordance with applicable laws, executive orders, directives, policies, - regulations, standards, and guidelines, the public is not authorized to have - access to nonpublic information, including information protected under the PRIVACT and proprietary - information. Publicly accessible content addresses systems that are controlled - by the organization and accessible to the public, typically without - identification or authentication. Posting information on non-organizational - systems (e.g., non-organizational public websites, forums, and social media) is - covered by organizational policy. While organizations may have individuals who - are responsible for developing and implementing policies about the information - that can be made publicly accessible, publicly accessible content addresses the - management of the individuals who make such information publicly accessible.
-designated individuals are authorized to make information publicly - accessible;
- -authorized individuals are trained to ensure that publicly accessible - information does not contain non-public information;
- -the proposed content of information is reviewed prior to posting onto the - publicly accessible system to ensure that non-public information is not - included;
- -the content on the publicly accessible system is reviewed for non-public
- information
non-public information is removed from the publicly accessible system, if - discovered.
- -Access control policy
-procedures addressing publicly accessible content
-list of users authorized to post publicly accessible content on - organizational systems
-training materials and/or records
-records of publicly accessible information reviews
-records of response to non-public information on public websites
-system audit logs
-security awareness training records
-system security plan
-other relevant documents or records
-Organizational personnel with responsibilities for managing publicly - accessible information posted on organizational systems
-organizational personnel with information security responsibilities
-Mechanisms implementing management of publicly accessible content
-personnel or roles to whom the awareness and training policy is to be - disseminated is/are defined;
-personnel or roles to whom the awareness and training procedures are to be - disseminated is/are defined;
-an official to manage the awareness and training policy and procedures is - defined;
-the frequency at which the current awareness and training policy is reviewed - and updated is defined;
-events that would require the current awareness and training policy to be - reviewed and updated are defined;
-the frequency at which the current awareness and training procedures are - reviewed and updated is defined;
-events that would require procedures to be reviewed and updated are defined;
-Develop, document, and disseminate to
Addresses purpose, scope, roles, responsibilities, management - commitment, coordination among organizational entities, and - compliance; and
-Is consistent with applicable laws, executive orders, directives, - regulations, policies, standards, and guidelines; and
-Procedures to facilitate the implementation of the awareness and training - policy and the associated awareness and training controls;
-Designate an
Review and update the current awareness and training:
-Policy
Procedures
Awareness and training policy and procedures address the controls in the AT - family that are implemented within systems and organizations. The risk - management strategy is an important factor in establishing such policies and - procedures. Policies and procedures contribute to security and privacy - assurance. Therefore, it is important that security and privacy programs - collaborate on the development of awareness and training policy and procedures. - Security and privacy program policies and procedures at the organization level - are preferable, in general, and may obviate the need for mission- or - system-specific policies and procedures. The policy can be included as part of - the general security and privacy policy or be represented by multiple policies - that reflect the complex nature of organizations. Procedures can be established - for security and privacy programs, for mission or business processes, and for - systems, if needed. Procedures describe how the policies or controls are - implemented and can be directed at the individual or role that is the object of - the procedure. Procedures can be documented in system security and privacy plans - or in one or more separate documents. Events that may precipitate an update to - awareness and training policy and procedures include assessment or audit - findings, security incidents or breaches, or changes in applicable laws, - executive orders, directives, regulations, policies, standards, and guidelines. - Simply restating controls does not constitute an organizational policy or - procedure.
-an awareness and training policy is developed and documented;
- -the awareness and training policy is disseminated to
awareness and training procedures to facilitate the implementation of the - awareness and training policy and associated access controls are - developed and documented;
- -the awareness and training procedures are disseminated to
the
the
the
the
the
the
the
the
the
the current awareness and training policy is reviewed and updated
the current awareness and training policy is reviewed and updated
- following
the current awareness and training procedures are reviewed and
- updated
the current awareness and training procedures are reviewed and
- updated following
System security plan
-privacy plan
-awareness and training policy and procedures
-other relevant documents or records
-Organizational personnel with awareness and training responsibilities
-organizational personnel with information security and privacy - responsibilities
-the frequency at which to provide security literacy training to system users - (including managers, senior executives, and contractors) after initial - training is defined;
-the frequency at which to provide privacy literacy training to system users - (including managers, senior executives, and contractors) after initial - training is defined;
-events that require security literacy training for system users are defined;
-events that require privacy literacy training for system users are defined;
-techniques to be employed to increase the security and privacy awareness of - system users are defined;
-the frequency at which to update literacy training and awareness content is - defined;
-events that would require literacy training and awareness content to be - updated are defined;
-Provide security and privacy literacy training to system users (including - managers, senior executives, and contractors):
-As part of initial training for new users and
When required by system changes or following
Employ the following techniques to increase the security and privacy
- awareness of system users
Update literacy training and awareness content
Incorporate lessons learned from internal or external security incidents or - breaches into literacy training and awareness techniques.
-Organizations provide basic and advanced levels of literacy training to system - users, including measures to test the knowledge level of users. Organizations - determine the content of literacy training and awareness based on specific - organizational requirements, the systems to which personnel have authorized - access, and work environments (e.g., telework). The content includes an - understanding of the need for security and privacy as well as actions by users - to maintain security and personal privacy and to respond to suspected incidents. - The content addresses the need for operations security and the handling of - personally identifiable information.
-Awareness techniques include displaying posters, offering supplies inscribed with - security and privacy reminders, displaying logon screen messages, generating - email advisories or notices from organizational officials, and conducting - awareness events. Literacy training after the initial training described in AT-2a.1 is conducted at a minimum frequency - consistent with applicable laws, directives, regulations, and policies. - Subsequent literacy training may be satisfied by one or more short ad hoc - sessions and include topical information on recent attack schemes, changes to - organizational security and privacy policies, revised security and privacy - expectations, or a subset of topics from the initial training. Updating literacy - training and awareness content on a regular basis helps to ensure that the - content remains relevant. Events that may precipitate an update to literacy - training and awareness content include, but are not limited to, assessment or - audit findings, security incidents or breaches, or changes in applicable laws, - executive orders, directives, regulations, policies, standards, and guidelines.
-security literacy training is provided to system users (including - managers, senior executives, and contractors) as part of initial - training for new users;
- -privacy literacy training is provided to system users (including - managers, senior executives, and contractors) as part of initial - training for new users;
- -security literacy training is provided to system users (including
- managers, senior executives, and contractors)
privacy literacy training is provided to system users (including
- managers, senior executives, and contractors)
security literacy training is provided to system users (including
- managers, senior executives, and contractors) when required by
- system changes or following
privacy literacy training is provided to system users (including
- managers, senior executives, and contractors) when required by
- system changes or following
literacy training and awareness content is updated
literacy training and awareness content is updated following
lessons learned from internal or external security incidents or breaches are - incorporated into literacy training and awareness techniques.
- -System security plan
-privacy plan
-literacy training and awareness policy
-procedures addressing literacy training and awareness implementation
-appropriate codes of federal regulations
-security and privacy literacy training curriculum
-security and privacy literacy training materials
-training records
-other relevant documents or records
-Organizational personnel with responsibilities for literacy training and - awareness
-organizational personnel with information security and privacy - responsibilities
-organizational personnel comprising the general system user community
-Mechanisms managing information security and privacy literacy training
-Provide literacy training on recognizing and reporting potential indicators - of insider threat.
-Potential indicators and possible precursors of insider threat can include - behaviors such as inordinate, long-term job dissatisfaction; attempts to - gain access to information not required for job performance; unexplained - access to financial resources; bullying or harassment of fellow employees; - workplace violence; and other serious violations of policies, procedures, - directives, regulations, rules, or practices. Literacy training includes how - to communicate the concerns of employees and management regarding potential - indicators of insider threat through channels established by the - organization and in accordance with established policies and procedures. - Organizations may consider tailoring insider threat awareness topics to the - role. For example, training for managers may be focused on changes in the - behavior of team members, while training for employees may be focused on - more general observations.
-literacy training on recognizing potential indicators of insider threat - is provided;
- -literacy training on reporting potential indicators of insider threat is - provided.
- -System security plan
-privacy plan
-literacy training and awareness policy
-procedures addressing literacy training and awareness implementation
-literacy training and awareness curriculum
-literacy training and awareness materials
-other relevant documents or records
-Organizational personnel who receive literacy training and awareness
-organizational personnel with responsibilities for literacy training and - awareness
-organizational personnel with information security and privacy - responsibilities
-Provide literacy training on recognizing and reporting potential and actual - instances of social engineering and social mining.
-Social engineering is an attempt to trick an individual into revealing - information or taking an action that can be used to breach, compromise, or - otherwise adversely impact a system. Social engineering includes phishing, - pretexting, impersonation, baiting, quid pro quo, thread-jacking, social - media exploitation, and tailgating. Social mining is an attempt to gather - information about the organization that may be used to support future - attacks. Literacy training includes information on how to communicate the - concerns of employees and management regarding potential and actual - instances of social engineering and data mining through organizational - channels based on established policies and procedures.
-literacy training on recognizing potential and actual instances of social - engineering is provided;
- -literacy training on reporting potential and actual instances of social - engineering is provided;
- -literacy training on recognizing potential and actual instances of social - mining is provided;
- -literacy training on reporting potential and actual instances of social - mining is provided.
- -System security plan
-privacy plan
-literacy training and awareness policy
-procedures addressing literacy training and awareness implementation
-literacy training and awareness curriculum
-literacy training and awareness materials
-other relevant documents or records
-Organizational personnel who receive literacy training and awareness
-organizational personnel with responsibilities for literacy training and - awareness
-organizational personnel with information security and privacy - responsibilities
-roles and responsibilities for role-based security training are defined;
-roles and responsibilities for role-based privacy training are defined;
-the frequency at which to provide role-based security and privacy training to - assigned personnel after initial training is defined;
-the frequency at which to update role-based training content is defined;
-events that require role-based training content to be updated are defined;
-Provide role-based security and privacy training to personnel with the
- following roles and responsibilities:
Before authorizing access to the system, information, or performing
- assigned duties, and
When required by system changes;
-Update role-based training content
Incorporate lessons learned from internal or external security incidents or - breaches into role-based training.
-Organizations determine the content of training based on the assigned roles and - responsibilities of individuals as well as the security and privacy requirements - of organizations and the systems to which personnel have authorized access, - including technical training specifically tailored for assigned duties. Roles - that may require role-based training include senior leaders or management - officials (e.g., head of agency/chief executive officer, chief information - officer, senior accountable official for risk management, senior agency - information security officer, senior agency official for privacy), system - owners; authorizing officials; system security officers; privacy officers; - acquisition and procurement officials; enterprise architects; systems engineers; - software developers; systems security engineers; privacy engineers; system, - network, and database administrators; auditors; personnel conducting - configuration management activities; personnel performing verification and - validation activities; personnel with access to system-level software; control - assessors; personnel with contingency planning and incident response duties; - personnel with privacy management responsibilities; and personnel with access to - personally identifiable information.
-Comprehensive role-based training addresses management, operational, and - technical roles and responsibilities covering physical, personnel, and technical - controls. Role-based training also includes policies, procedures, tools, - methods, and artifacts for the security and privacy roles defined. Organizations - provide the training necessary for individuals to fulfill their responsibilities - related to operations and supply chain risk management within the context of - organizational security and privacy programs. Role-based training also applies - to contractors who provide services to federal agencies. Types of training - include web-based and computer-based training, classroom-style training, and - hands-on training (including micro-training). Updating role-based training on a - regular basis helps to ensure that the content remains relevant and effective. - Events that may precipitate an update to role-based training content include, - but are not limited to, assessment or audit findings, security incidents or - breaches, or changes in applicable laws, executive orders, directives, - regulations, policies, standards, and guidelines.
-role-based security training is provided to
role-based privacy training is provided to
role-based security training is provided to
role-based privacy training is provided to
role-based security training is provided to personnel with assigned - security roles and responsibilities when required by system changes;
- -role-based privacy training is provided to personnel with assigned - security roles and responsibilities when required by system changes;
- -role-based training content is updated
role-based training content is updated following
lessons learned from internal or external security incidents or breaches are - incorporated into role-based training.
- -System security plan
-privacy plan
-security and privacy awareness and training policy
-procedures addressing security and privacy training implementation
-codes of federal regulations
-security and privacy training curriculum
-security and privacy training materials
-training records
-other relevant documents or records
-Organizational personnel with responsibilities for role-based security and - privacy training
-organizational personnel with assigned system security and privacy roles and - responsibilities
-Mechanisms managing role-based security and privacy training
-time period for retaining individual training records is defined;
-Document and monitor information security and privacy training activities, - including security and privacy awareness training and specific role-based - security and privacy training; and
-Retain individual training records for
Documentation for specialized training may be maintained by individual - supervisors at the discretion of the organization. The National Archives and - Records Administration provides guidance on records retention for federal - agencies.
-information security and privacy training activities, including security - and privacy awareness training and specific role-based security and - privacy training, are documented;
- -information security and privacy training activities, including security - and privacy awareness training and specific role-based security and - privacy training, are monitored;
- -individual training records are retained for
Security and privacy awareness and training policy
-procedures addressing security and privacy training records
-security and privacy awareness and training records
-system security plan
-privacy plan
-other relevant documents or records
-Organizational personnel with information security and privacy training - record retention responsibilities
-Mechanisms supporting the management of security and privacy training records
-personnel or roles to whom the audit and accountability policy is to be - disseminated is/are defined;
-personnel or roles to whom the audit and accountability procedures are to be - disseminated is/are defined;
-an official to manage the audit and accountability policy and procedures is - defined;
-the frequency at which the current audit and accountability policy is - reviewed and updated is defined;
-events that would require the current audit and accountability policy to be - reviewed and updated are defined;
-the frequency at which the current audit and accountability procedures are - reviewed and updated is defined;
-events that would require audit and accountability procedures to be reviewed - and updated are defined;
-Develop, document, and disseminate to
Addresses purpose, scope, roles, responsibilities, management - commitment, coordination among organizational entities, and - compliance; and
-Is consistent with applicable laws, executive orders, directives, - regulations, policies, standards, and guidelines; and
-Procedures to facilitate the implementation of the audit and - accountability policy and the associated audit and accountability - controls;
-Designate an
Review and update the current audit and accountability:
-Policy
Procedures
Audit and accountability policy and procedures address the controls in the AU - family that are implemented within systems and organizations. The risk - management strategy is an important factor in establishing such policies and - procedures. Policies and procedures contribute to security and privacy - assurance. Therefore, it is important that security and privacy programs - collaborate on the development of audit and accountability policy and - procedures. Security and privacy program policies and procedures at the - organization level are preferable, in general, and may obviate the need for - mission- or system-specific policies and procedures. The policy can be included - as part of the general security and privacy policy or be represented by multiple - policies that reflect the complex nature of organizations. Procedures can be - established for security and privacy programs, for mission or business - processes, and for systems, if needed. Procedures describe how the policies or - controls are implemented and can be directed at the individual or role that is - the object of the procedure. Procedures can be documented in system security and - privacy plans or in one or more separate documents. Events that may precipitate - an update to audit and accountability policy and procedures include assessment - or audit findings, security incidents or breaches, or changes in applicable - laws, executive orders, directives, regulations, policies, standards, and - guidelines. Simply restating controls does not constitute an organizational - policy or procedure.
-an audit and accountability policy is developed and documented;
- -the audit and accountability policy is disseminated to
audit and accountability procedures to facilitate the implementation of - the audit and accountability policy and associated audit and - accountability controls are developed and documented;
- -the audit and accountability procedures are disseminated to
the
the
the
the
the
the
the
the
the
the current audit and accountability policy is reviewed and updated
the current audit and accountability policy is reviewed and updated
- following
the current audit and accountability procedures are reviewed and
- updated
the current audit and accountability procedures are reviewed and
- updated following
Audit and accountability policy and procedures
-system security plan
-privacy plan
-other relevant documents or records
-Organizational personnel with audit and accountability responsibilities
-organizational personnel with information security and privacy - responsibilities
-the event types that the system is capable of logging in support of the audit - function are defined;
-the event types (subset of AU-02_ODP[01]) for logging within the system are - defined;
-the frequency or situation requiring logging for each specified event type is - defined;
-the frequency of event types selected for logging are reviewed and updated;
-Identify the types of events that the system is capable of logging in support
- of the audit function:
Coordinate the event logging function with other organizational entities - requiring audit-related information to guide and inform the selection - criteria for events to be logged;
-Specify the following event types for logging within the system:
Provide a rationale for why the event types selected for logging are deemed - to be adequate to support after-the-fact investigations of incidents; and
-Review and update the event types selected for logging
An event is an observable occurrence in a system. The types of events that - require logging are those events that are significant and relevant to the - security of systems and the privacy of individuals. Event logging also supports - specific monitoring and auditing needs. Event types include password changes, - failed logons or failed accesses related to systems, security or privacy - attribute changes, administrative privilege usage, PIV credential usage, data - action changes, query parameters, or external credential usage. In determining - the set of event types that require logging, organizations consider the - monitoring and auditing appropriate for each of the controls to be implemented. - For completeness, event logging includes all protocols that are operational and - supported by the system.
-To balance monitoring and auditing requirements with other system needs, event - logging requires identifying the subset of event types that are logged at a - given point in time. For example, organizations may determine that systems need - the capability to log every file access successful and unsuccessful, but not - activate that capability except for specific circumstances due to the potential - burden on system performance. The types of events that organizations desire to - be logged may change. Reviewing and updating the set of logged events is - necessary to help ensure that the events remain relevant and continue to support - the needs of the organization. Organizations consider how the types of logging - events can reveal information about individuals that may give rise to privacy - risk and how best to mitigate such risks. For example, there is the potential to - reveal personally identifiable information in the audit trail, especially if the - logging event is based on patterns or time of usage.
-Event logging requirements, including the need to log specific event types, may - be referenced in other controls and control enhancements. These include AC-2(4), - AC-3(10), AC-6(9), AC-17(1), CM-3f, - CM-5(1), - IA-3(3)(b), - MA-4(1), - MP-4(2), PE-3, - PM-21, - PT-7, - RA-8, - SC-7(9), - SC-7(15), - SI-3(8), - SI-4(22), - SI-7(8) , and - SI-10(1) . Organizations include event types that are required by applicable - laws, executive orders, directives, policies, regulations, standards, and - guidelines. Audit records can be generated at various levels, including at the - packet level as information traverses the network. Selecting the appropriate - level of event logging is an important part of a monitoring and auditing - capability and can identify the root causes of problems. When defining event - types, organizations consider the logging necessary to cover related event - types, such as the steps in distributed, transaction-based processes and the - actions that occur in service-oriented architectures.
-the event logging function is coordinated with other organizational entities - requiring audit-related information to guide and inform the selection - criteria for events to be logged;
- -the specified event types are logged within the system
a rationale is provided for why the event types selected for logging are - deemed to be adequate to support after-the-fact investigations of incidents;
- -the event types selected for logging are reviewed and updated
Audit and accountability policy
-procedures addressing auditable events
-system security plan
-privacy plan
-system design documentation
-system configuration settings and associated documentation
-system audit records
-system auditable events
-other relevant documents or records
-Organizational personnel with audit and accountability responsibilities
-organizational personnel with information security and privacy - responsibilities
-system/network administrators
-Mechanisms implementing system auditing
-Ensure that audit records contain information that establishes the following:
-What type of event occurred;
-When the event occurred;
-Where the event occurred;
-Source of the event;
-Outcome of the event; and
-Identity of any individuals, subjects, or objects/entities associated with - the event.
-Audit record content that may be necessary to support the auditing function - includes event descriptions (item a), time stamps (item b), source and - destination addresses (item c), user or process identifiers (items d and f), - success or fail indications (item e), and filenames involved (items a, c, e, and - f) . Event outcomes include indicators of event success or failure and - event-specific results, such as the system security and privacy posture after - the event occurred. Organizations consider how audit records can reveal - information about individuals that may give rise to privacy risks and how best - to mitigate such risks. For example, there is the potential to reveal personally - identifiable information in the audit trail, especially if the trail records - inputs or is based on patterns or time of usage.
-audit records contain information that establishes what type of event - occurred;
- -audit records contain information that establishes when the event occurred;
- -audit records contain information that establishes where the event occurred;
- -audit records contain information that establishes the source of the event;
- -audit records contain information that establishes the outcome of the event;
- -audit records contain information that establishes the identity of any - individuals, subjects, or objects/entities associated with the event.
- -Audit and accountability policy
-system security plan
-privacy plan
-procedures addressing content of audit records
-system design documentation
-system configuration settings and associated documentation
-list of organization-defined auditable events
-system audit records
-system incident reports
-other relevant documents or records
-Organizational personnel with audit and accountability responsibilities
-organizational personnel with information security and privacy - responsibilities
-system/network administrators
-Mechanisms implementing system auditing of auditable events
-additional information to be included in audit records is defined;
-Generate audit records containing the following additional information:
The ability to add information generated in audit records is dependent on - system functionality to configure the audit record content. Organizations - may consider additional information in audit records including, but not - limited to, access control or flow control rules invoked and individual - identities of group account users. Organizations may also consider limiting - additional audit record information to only information that is explicitly - needed for audit requirements. This facilitates the use of audit trails and - audit logs by not including information in audit records that could - potentially be misleading, make it more difficult to locate information of - interest, or increase the risk to individuals' privacy.
-generated audit records contain the following
Audit and accountability policy
-procedures addressing content of audit records
-system security plan
-privacy plan
-system design documentation
-system configuration settings and associated documentation
-list of organization-defined auditable events
-system audit records
-other relevant documents or records
-Organizational personnel with audit and accountability responsibilities
-organizational personnel with information security and privacy - responsibilities
-system/network administrators
-system developers
-system audit capability
-audit log retention requirements are defined;
-Allocate audit log storage capacity to accommodate
Organizations consider the types of audit logging to be performed and the audit - log processing requirements when allocating audit log storage capacity. - Allocating sufficient audit log storage capacity reduces the likelihood of such - capacity being exceeded and resulting in the potential loss or reduction of - audit logging capability.
-audit log storage capacity is allocated to accommodate
Audit and accountability policy
-procedures addressing audit storage capacity
-system security plan
-privacy plan
-system design documentation
-system configuration settings and associated documentation
-audit record storage requirements
-audit record storage capability for system components
-system audit records
-other relevant documents or records
-Organizational personnel with audit and accountability responsibilities
-organizational personnel with information security and privacy - responsibilities
-system/network administrators
-system developers
-Audit record storage capacity and related configuration settings
-personnel or roles receiving audit logging process failure alerts are - defined;
-time period for personnel or roles receiving audit logging process failure - alerts is defined;
-additional actions to be taken in the event of an audit logging process - failure are defined;
-Alert
Take the following additional actions:
Audit logging process failures include software and hardware errors, failures in - audit log capturing mechanisms, and reaching or exceeding audit log storage - capacity. Organization-defined actions include overwriting oldest audit records, - shutting down the system, and stopping the generation of audit records. - Organizations may choose to define additional actions for audit logging process - failures based on the type of failure, the location of the failure, the severity - of the failure, or a combination of such factors. When the audit logging process - failure is related to storage, the response is carried out for the audit log - storage repository (i.e., the distinct system component where the audit logs are - stored), the system on which the audit logs reside, the total audit log storage - capacity of the organization (i.e., all audit log storage repositories - combined), or all three. Organizations may decide to take no additional actions - after alerting designated roles or personnel.
-Audit and accountability policy
-procedures addressing response to audit processing failures
-system design documentation
-system security plan
-privacy plan
-system configuration settings and associated documentation
-list of personnel to be notified in case of an audit processing failure
-system audit records
-other relevant documents or records
-Organizational personnel with audit and accountability responsibilities
-organizational personnel with information security and privacy - responsibilities
-system/network administrators
-system developers
-Mechanisms implementing system response to audit processing failures
-frequency at which system audit records are reviewed and analyzed is defined;
-inappropriate or unusual activity is defined;
-personnel or roles to receive findings from reviews and analyses of system - records is/are defined;
-Review and analyze system audit records
Report findings to
Adjust the level of audit record review, analysis, and reporting within the - system when there is a change in risk based on law enforcement information, - intelligence information, or other credible sources of information.
-Audit record review, analysis, and reporting covers information security- and - privacy-related logging performed by organizations, including logging that - results from the monitoring of account usage, remote access, wireless - connectivity, mobile device connection, configuration settings, system component - inventory, use of maintenance tools and non-local maintenance, physical access, - temperature and humidity, equipment delivery and removal, communications at - system interfaces, and use of mobile code or Voice over Internet Protocol - (VoIP). Findings can be reported to organizational entities that include the - incident response team, help desk, and security or privacy offices. If - organizations are prohibited from reviewing and analyzing audit records or - unable to conduct such activities, the review or analysis may be carried out by - other organizations granted such authority. The frequency, scope, and/or depth - of the audit record review, analysis, and reporting may be adjusted to meet - organizational needs based on new information received.
-system audit records are reviewed and analyzed
findings are reported to
the level of audit record review, analysis, and reporting within the system - is adjusted when there is a change in risk based on law enforcement - information, intelligence information, or other credible sources of - information.
- -Audit and accountability policy
-system security plan
-privacy plan
-procedures addressing audit review, analysis, and reporting
-reports of audit findings
-records of actions taken in response to reviews/analyses of audit records
-other relevant documents or records
-Organizational personnel with audit review, analysis, and reporting - responsibilities
-organizational personnel with information security and privacy - responsibilities
-automated mechanisms used for integrating audit record review, analysis, - and reporting processes are defined;
-Integrate audit record review, analysis, and reporting processes using
Organizational processes that benefit from integrated audit record review, - analysis, and reporting include incident response, continuous monitoring, - contingency planning, investigation and response to suspicious activities, - and Inspector General audits.
-audit record review, analysis, and reporting processes are integrated using
Audit and accountability policy
-system security plan
-privacy plan
-procedures addressing audit review, analysis, and reporting
-procedures addressing investigation and response to suspicious activities
-system design documentation
-system configuration settings and associated documentation
-system audit records
-other relevant documents or records
-Organizational personnel with audit review, analysis, and reporting - responsibilities
-organizational personnel with information security and privacy - responsibilities
-Automated mechanisms integrating audit review, analysis, and reporting - processes
-Analyze and correlate audit records across different repositories to gain - organization-wide situational awareness.
-Organization-wide situational awareness includes awareness across all three - levels of risk management (i.e., organizational level, mission/business - process level, and information system level) and supports cross-organization - awareness.
-audit records across different repositories are analyzed and correlated to - gain organization-wide situational awareness.
- -Audit and accountability policy
-system security plan
-privacy plan
-procedures addressing audit review, analysis, and reporting
-system design documentation
-system configuration settings and associated documentation
-system audit records across different repositories
-other relevant documents or records
-Organizational personnel with audit review, analysis, and reporting - responsibilities
-organizational personnel with information security and privacy - responsibilities
-Mechanisms supporting the analysis and correlation of audit records
-Provide and implement an audit record reduction and report generation capability - that:
-Supports on-demand audit record review, analysis, and reporting requirements - and after-the-fact investigations of incidents; and
-Does not alter the original content or time ordering of audit records.
-Audit record reduction is a process that manipulates collected audit log - information and organizes it into a summary format that is more meaningful to - analysts. Audit record reduction and report generation capabilities do not - always emanate from the same system or from the same organizational entities - that conduct audit logging activities. The audit record reduction capability - includes modern data mining techniques with advanced data filters to identify - anomalous behavior in audit records. The report generation capability provided - by the system can generate customizable reports. Time ordering of audit records - can be an issue if the granularity of the timestamp in the record is - insufficient.
-an audit record reduction and report generation capability is provided - that supports on-demand audit record review, analysis, and reporting - requirements and after-the-fact investigations of incidents;
- -an audit record reduction and report generation capability is implemented - that supports on-demand audit record review, analysis, and reporting - requirements and after-the-fact investigations of incidents;
- -an audit record reduction and report generation capability is provided - that does not alter the original content or time ordering of audit - records;
- -an audit record reduction and report generation capability is implemented - that does not alter the original content or time ordering of audit - records.
- -Audit and accountability policy
-system security plan
-privacy plan
-procedures addressing audit reduction and report generation
-system design documentation
-system configuration settings and associated documentation
-audit reduction, review, analysis, and reporting tools
-system audit records
-other relevant documents or records
-Organizational personnel with audit reduction and report generation - responsibilities
-organizational personnel with information security and privacy - responsibilities
-Audit reduction and report generation capability
-fields within audit records that can be processed, sorted, or searched - are defined;
-Provide and implement the capability to process, sort, and search audit
- records for events of interest based on the following content:
Events of interest can be identified by the content of audit records, - including system resources involved, information objects accessed, - identities of individuals, event types, event locations, event dates and - times, Internet Protocol addresses involved, or event success or failure. - Organizations may define event criteria to any degree of granularity - required, such as locations selectable by a general networking location or - by specific system component.
-the capability to process, sort, and search audit records for events of
- interest based on
the capability to process, sort, and search audit records for events of
- interest based on
Audit and accountability policy
-system security plan
-privacy plan
-procedures addressing audit reduction and report generation
-system design documentation
-system configuration settings and associated documentation
-audit reduction, review, analysis, and reporting tools
-audit record criteria (fields) establishing events of interest
-system audit records
-other relevant documents or records
-Organizational personnel with audit reduction and report generation - responsibilities
-organizational personnel with information security and privacy - responsibilities
-system developers
-Audit reduction and report generation capability
-granularity of time measurement for audit record timestamps is defined;
-Use internal system clocks to generate time stamps for audit records; and
-Record time stamps for audit records that meet
Time stamps generated by the system include date and time. Time is commonly - expressed in Coordinated Universal Time (UTC), a modern continuation of - Greenwich Mean Time (GMT), or local time with an offset from UTC. Granularity of - time measurements refers to the degree of synchronization between system clocks - and reference clocks (e.g., clocks synchronizing within hundreds of milliseconds - or tens of milliseconds). Organizations may define different time granularities - for different system components. Time service can be critical to other security - capabilities such as access control and identification and authentication, - depending on the nature of the mechanisms used to support those capabilities.
-internal system clocks are used to generate timestamps for audit records;
- -timestamps are recorded for audit records that meet
Audit and accountability policy
-system security plan
-privacy plan
-procedures addressing timestamp generation
-system design documentation
-system configuration settings and associated documentation
-system audit records
-other relevant documents or records
-Organizational personnel with information security and privacy - responsibilities
-system/network administrators
-system developers
-Mechanisms implementing timestamp generation
-personnel or roles to be alerted upon detection of unauthorized access, - modification, or deletion of audit information is/are defined;
-Protect audit information and audit logging tools from unauthorized access, - modification, and deletion; and
-Alert
Audit information includes all information needed to successfully audit system - activity, such as audit records, audit log settings, audit reports, and - personally identifiable information. Audit logging tools are those programs and - devices used to conduct system audit and logging activities. Protection of audit - information focuses on technical protection and limits the ability to access and - execute audit logging tools to authorized individuals. Physical protection of - audit information is addressed by both media protection controls and physical - and environmental protection controls.
-audit information and audit logging tools are protected from unauthorized - access, modification, and deletion;
- -Audit and accountability policy
-system security plan
-privacy plan
-access control policy and procedures
-procedures addressing protection of audit information
-system design documentation
-system configuration settings and associated documentation
-system audit records
-audit tools
-other relevant documents or records
-Organizational personnel with audit and accountability responsibilities
-organizational personnel with information security and privacy - responsibilities
-system/network administrators
-system developers
-Mechanisms implementing audit information protection
-a subset of privileged users or roles authorized to access management of - audit logging functionality is defined;
-Authorize access to management of audit logging functionality to only
Individuals or roles with privileged access to a system and who are also the - subject of an audit by that system may affect the reliability of the audit - information by inhibiting audit activities or modifying audit records. - Requiring privileged access to be further defined between audit-related - privileges and other privileges limits the number of users or roles with - audit-related privileges.
-access to management of audit logging functionality is authorized only to
Audit and accountability policy
-system security plan
-privacy plan
-access control policy and procedures
-procedures addressing protection of audit information
-system design documentation
-system configuration settings and associated documentation
-system-generated list of privileged users with access to management of - audit functionality
-access authorizations
-access control list
-system audit records
-other relevant documents or records
-Organizational personnel with audit and accountability responsibilities
-organizational personnel with information security and privacy - responsibilities
-system/network administrators
-Mechanisms managing access to audit functionality
-a time period to retain audit records that is consistent with the records - retention policy is defined;
-Retain audit records for
Organizations retain audit records until it is determined that the records are no - longer needed for administrative, legal, audit, or other operational purposes. - This includes the retention and availability of audit records relative to - Freedom of Information Act (FOIA) requests, subpoenas, and law enforcement - actions. Organizations develop standard categories of audit records relative to - such types of actions and standard response processes for each type of action. - The National Archives and Records Administration (NARA) General Records - Schedules provide federal policy on records retention.
-audit records are retained for
Audit and accountability policy
-system security plan
-privacy plan
-audit record retention policy and procedures
-security plan
-organization-defined retention period for audit records
-audit record archives
-audit logs
-audit records
-other relevant documents or records
-Organizational personnel with audit record retention responsibilities
-organizational personnel with information security and privacy - responsibilities
-system/network administrators
-system components that provide an audit record generation capability for the - events types (defined in AU-02_ODP[02]) are defined;
-personnel or roles allowed to select the event types that are to be logged by - specific components of the system is/are defined;
-Provide audit record generation capability for the event types the system is
- capable of auditing as defined in AU-2a on
Allow
Generate audit records for the event types defined in - AU-2c that include the audit record content defined in - AU-3.
-Audit records can be generated from many different system components. The event - types specified in AU-2d are the event types for which - audit logs are to be generated and are a subset of all event types for which the - system can generate audit records.
-audit record generation capability for the event types the system is capable
- of auditing (defined in AU-02_ODP[01]) is provided by
audit records for the event types defined in AU-02_ODP[02] that include the - audit record content defined in AU-03 are generated.
- -Audit and accountability policy
-procedures addressing audit record generation
-system security plan
-privacy plan
-system design documentation
-system configuration settings and associated documentation
-list of auditable events
-system audit records
-other relevant documents or records
-Organizational personnel with audit record generation responsibilities
-organizational personnel with information security and privacy - responsibilities
-system/network administrators
-system developers
-Mechanisms implementing audit record generation capability
-personnel or roles to whom the assessment, authorization, and monitoring - policy is to be disseminated is/are defined;
-personnel or roles to whom the assessment, authorization, and monitoring - procedures are to be disseminated is/are defined;
-an official to manage the assessment, authorization, and monitoring policy - and procedures is defined;
-the frequency at which the current assessment, authorization, and monitoring - policy is reviewed and updated is defined;
-events that would require the current assessment, authorization, and - monitoring policy to be reviewed and updated are defined;
-the frequency at which the current assessment, authorization, and monitoring - procedures are reviewed and updated is defined;
-events that would require assessment, authorization, and monitoring - procedures to be reviewed and updated are defined;
-Develop, document, and disseminate to
Addresses purpose, scope, roles, responsibilities, management - commitment, coordination among organizational entities, and - compliance; and
-Is consistent with applicable laws, executive orders, directives, - regulations, policies, standards, and guidelines; and
-Procedures to facilitate the implementation of the assessment, - authorization, and monitoring policy and the associated assessment, - authorization, and monitoring controls;
-Designate an
Review and update the current assessment, authorization, and monitoring:
-Policy
Procedures
Assessment, authorization, and monitoring policy and procedures address the - controls in the CA family that are implemented within systems and organizations. - The risk management strategy is an important factor in establishing such - policies and procedures. Policies and procedures contribute to security and - privacy assurance. Therefore, it is important that security and privacy programs - collaborate on the development of assessment, authorization, and monitoring - policy and procedures. Security and privacy program policies and procedures at - the organization level are preferable, in general, and may obviate the need for - mission- or system-specific policies and procedures. The policy can be included - as part of the general security and privacy policy or be represented by multiple - policies that reflect the complex nature of organizations. Procedures can be - established for security and privacy programs, for mission or business - processes, and for systems, if needed. Procedures describe how the policies or - controls are implemented and can be directed at the individual or role that is - the object of the procedure. Procedures can be documented in system security and - privacy plans or in one or more separate documents. Events that may precipitate - an update to assessment, authorization, and monitoring policy and procedures - include assessment or audit findings, security incidents or breaches, or changes - in applicable laws, executive orders, directives, regulations, policies, - standards, and guidelines. Simply restating controls does not constitute an - organizational policy or procedure.
-an assessment, authorization, and monitoring policy is developed and - documented;
- -the assessment, authorization, and monitoring policy is disseminated to
assessment, authorization, and monitoring procedures to facilitate the - implementation of the assessment, authorization, and monitoring policy - and associated assessment, authorization, and monitoring controls are - developed and documented;
- -the assessment, authorization, and monitoring procedures are disseminated
- to
the
the
the
the
the
the
the
the
the
the current assessment, authorization, and monitoring policy is
- reviewed and updated
the current assessment, authorization, and monitoring policy is
- reviewed and updated following
the current assessment, authorization, and monitoring procedures are
- reviewed and updated
the current assessment, authorization, and monitoring procedures are
- reviewed and updated following
Assessment, authorization, and monitoring policy and procedures
-system security plan
-privacy plan
-other relevant documents or records
-Organizational personnel with assessment, authorization, and monitoring - policy responsibilities
-organizational personnel with information security and privacy - responsibilities
-the frequency at which to assess controls in the system and its environment - of operation is defined;
-individuals or roles to whom control assessment results are to be provided - are defined;
-Select the appropriate assessor or assessment team for the type of assessment - to be conducted;
-Develop a control assessment plan that describes the scope of the assessment - including:
-Controls and control enhancements under assessment;
-Assessment procedures to be used to determine control effectiveness; and
-Assessment environment, assessment team, and assessment roles and - responsibilities;
-Ensure the control assessment plan is reviewed and approved by the - authorizing official or designated representative prior to conducting the - assessment;
-Assess the controls in the system and its environment of operation
Produce a control assessment report that document the results of the - assessment; and
-Provide the results of the control assessment to
Organizations ensure that control assessors possess the required skills and - technical expertise to develop effective assessment plans and to conduct - assessments of system-specific, hybrid, common, and program management controls, - as appropriate. The required skills include general knowledge of risk management - concepts and approaches as well as comprehensive knowledge of and experience - with the hardware, software, and firmware system components implemented.
-Organizations assess controls in systems and the environments in which those - systems operate as part of initial and ongoing authorizations, continuous - monitoring, FISMA annual assessments, system design and development, systems - security engineering, privacy engineering, and the system development life - cycle. Assessments help to ensure that organizations meet information security - and privacy requirements, identify weaknesses and deficiencies in the system - design and development process, provide essential information needed to make - risk-based decisions as part of authorization processes, and comply with - vulnerability mitigation procedures. Organizations conduct assessments on the - implemented controls as documented in security and privacy plans. Assessments - can also be conducted throughout the system development life cycle as part of - systems engineering and systems security engineering processes. The design for - controls can be assessed as RFPs are developed, responses assessed, and design - reviews conducted. If a design to implement controls and subsequent - implementation in accordance with the design are assessed during development, - the final control testing can be a simple confirmation utilizing previously - completed control assessment and aggregating the outcomes.
-Organizations may develop a single, consolidated security and privacy assessment - plan for the system or maintain separate plans. A consolidated assessment plan - clearly delineates the roles and responsibilities for control assessment. If - multiple organizations participate in assessing a system, a coordinated approach - can reduce redundancies and associated costs.
-Organizations can use other types of assessment activities, such as vulnerability - scanning and system monitoring, to maintain the security and privacy posture of - systems during the system life cycle. Assessment reports document assessment - results in sufficient detail, as deemed necessary by organizations, to determine - the accuracy and completeness of the reports and whether the controls are - implemented correctly, operating as intended, and producing the desired outcome - with respect to meeting requirements. Assessment results are provided to the - individuals or roles appropriate for the types of assessments being conducted. - For example, assessments conducted in support of authorization decisions are - provided to authorizing officials, senior agency officials for privacy, senior - agency information security officers, and authorizing official designated - representatives.
-To satisfy annual assessment requirements, organizations can use assessment - results from the following sources: initial or ongoing system authorizations, - continuous monitoring, systems engineering processes, or system development life - cycle activities. Organizations ensure that assessment results are current, - relevant to the determination of control effectiveness, and obtained with the - appropriate level of assessor independence. Existing control assessment results - can be reused to the extent that the results are still valid and can also be - supplemented with additional assessments as needed. After the initial - authorizations, organizations assess controls during continuous monitoring. - Organizations also establish the frequency for ongoing assessments in accordance - with organizational continuous monitoring strategies. External audits, including - audits by external entities such as regulatory agencies, are outside of the - scope of CA-2.
-an appropriate assessor or assessment team is selected for the type of - assessment to be conducted;
- -a control assessment plan is developed that describes the scope of the - assessment, including controls and control enhancements under - assessment;
- -a control assessment plan is developed that describes the scope of the - assessment, including assessment procedures to be used to determine - control effectiveness;
- -a control assessment plan is developed that describes the scope of - the assessment, including the assessment environment;
- -a control assessment plan is developed that describes the scope of - the assessment, including the assessment team;
- -a control assessment plan is developed that describes the scope of - the assessment, including assessment roles and responsibilities;
- -the control assessment plan is reviewed and approved by the authorizing - official or designated representative prior to conducting the assessment;
- -controls are assessed in the system and its environment of operation
controls are assessed in the system and its environment of operation
a control assessment report is produced that documents the results of the - assessment;
- -the results of the control assessment are provided to
Assessment, authorization, and monitoring policy
-procedures addressing assessment planning
-procedures addressing control assessments
-control assessment plan
-control assessment report
-system security plan
-privacy plan
-other relevant documents or records
-Organizational personnel with control assessment responsibilities
-organizational personnel with information security and privacy - responsibilities
-Mechanisms supporting control assessment, control assessment plan - development, and/or control assessment reporting
-Employ independent assessors or assessment teams to conduct control - assessments.
-Independent assessors or assessment teams are individuals or groups who - conduct impartial assessments of systems. Impartiality means that assessors - are free from any perceived or actual conflicts of interest regarding the - development, operation, sustainment, or management of the systems under - assessment or the determination of control effectiveness. To achieve - impartiality, assessors do not create a mutual or conflicting interest with - the organizations where the assessments are being conducted, assess their - own work, act as management or employees of the organizations they are - serving, or place themselves in positions of advocacy for the organizations - acquiring their services.
-Independent assessments can be obtained from elements within organizations or - be contracted to public or private sector entities outside of organizations. - Authorizing officials determine the required level of independence based on - the security categories of systems and/or the risk to organizational - operations, organizational assets, or individuals. Authorizing officials - also determine if the level of assessor independence provides sufficient - assurance that the results are sound and can be used to make credible, - risk-based decisions. Assessor independence determination includes whether - contracted assessment services have sufficient independence, such as when - system owners are not directly involved in contracting processes or cannot - influence the impartiality of the assessors conducting the assessments. - During the system design and development phase, having independent assessors - is analogous to having independent SMEs involved in design reviews.
-When organizations that own the systems are small or the structures of the - organizations require that assessments be conducted by individuals that are - in the developmental, operational, or management chain of the system owners, - independence in assessment processes can be achieved by ensuring that - assessment results are carefully reviewed and analyzed by independent teams - of experts to validate the completeness, accuracy, integrity, and - reliability of the results. Assessments performed for purposes other than to - support authorization decisions are more likely to be useable for such - decisions when performed by assessors with sufficient independence, thereby - reducing the need to repeat assessments.
-independent assessors or assessment teams are employed to conduct control - assessments.
- -Assessment, authorization, and monitoring policy
-procedures addressing control assessments
-previous control assessment plan
-previous control assessment report
-plan of action and milestones
-existing authorization statement
-system security plan
-privacy plan
-other relevant documents or records
-Organizational personnel with security assessment responsibilities
-organizational personnel with information security and privacy - responsibilities
-the type of agreement used to approve and manage the exchange of information - is defined (if selected);
-the frequency at which to review and update agreements is defined;
-Approve and manage the exchange of information between the system and other
- systems using
Document, as part of each exchange agreement, the interface characteristics, - security and privacy requirements, controls, and responsibilities for each - system, and the impact level of the information communicated; and
-Review and update the agreements
System information exchange requirements apply to information exchanges between - two or more systems. System information exchanges include connections via leased - lines or virtual private networks, connections to internet service providers, - database sharing or exchanges of database transaction information, connections - and exchanges with cloud services, exchanges via web-based services, or - exchanges of files via file transfer protocols, network protocols (e.g., IPv4, - IPv6), email, or other organization-to-organization communications. - Organizations consider the risk related to new or increased threats that may be - introduced when systems exchange information with other systems that may have - different security and privacy requirements and controls. This includes systems - within the same organization and systems that are external to the organization. - A joint authorization of the systems exchanging information, as described in - CA-6(1) or - CA-6(2) , may help to communicate and reduce risk.
-Authorizing officials determine the risk associated with system information - exchange and the controls needed for appropriate risk mitigation. The types of - agreements selected are based on factors such as the impact level of the - information being exchanged, the relationship between the organizations - exchanging information (e.g., government to government, government to business, - business to business, government or business to service provider, government or - business to individual), or the level of access to the organizational system by - users of the other system. If systems that exchange information have the same - authorizing official, organizations need not develop agreements. Instead, the - interface characteristics between the systems (e.g., how the information is - being exchanged. how the information is protected) are described in the - respective security and privacy plans. If the systems that exchange information - have different authorizing officials within the same organization, the - organizations can develop agreements or provide the same information that would - be provided in the appropriate agreement type from CA-3a - in the respective security and privacy plans for the systems. Organizations may - incorporate agreement information into formal contracts, especially for - information exchanges established between federal agencies and nonfederal - organizations (including service providers, contractors, system developers, and - system integrators). Risk considerations include systems that share the same - networks.
-the exchange of information between the system and other systems is approved
- and managed using
the interface characteristics are documented as part of each exchange - agreement;
- -security requirements are documented as part of each exchange agreement;
- -privacy requirements are documented as part of each exchange agreement;
- -controls are documented as part of each exchange agreement;
- -responsibilities for each system are documented as part of each exchange - agreement;
- -the impact level of the information communicated is documented as part of - each exchange agreement;
- -agreements are reviewed and updated
Access control policy
-procedures addressing system connections
-system and communications protection policy
-system interconnection security agreements
-information exchange security agreements
-memoranda of understanding or agreements
-service level agreements
-non-disclosure agreements
-system design documentation
-enterprise architecture
-system architecture
-system configuration settings and associated documentation
-system security plan
-privacy plan
-other relevant documents or records
-Organizational personnel with responsibilities for developing, implementing, - or approving system interconnection agreements
-organizational personnel with information security and privacy - responsibilities
-personnel managing the system(s) to which the interconnection security - agreement applies
-the frequency at which to update an existing plan of action and milestones - based on the findings from control assessments, independent audits or - reviews, and continuous monitoring activities is defined;
-Develop a plan of action and milestones for the system to document the - planned remediation actions of the organization to correct weaknesses or - deficiencies noted during the assessment of the controls and to reduce or - eliminate known vulnerabilities in the system; and
-Update existing plan of action and milestones
Plans of action and milestones are useful for any type of organization to track - planned remedial actions. Plans of action and milestones are required in - authorization packages and subject to federal reporting requirements established - by OMB.
-a plan of action and milestones for the system is developed to document the - planned remediation actions of the organization to correct weaknesses or - deficiencies noted during the assessment of the controls and to reduce or - eliminate known vulnerabilities in the system;
- -existing plan of action and milestones are updated
Assessment, authorization, and monitoring policy
-procedures addressing plan of action and milestones
-control assessment plan
-control assessment report
-control assessment evidence
-plan of action and milestones
-system security plan
-privacy plan
-other relevant documents or records
-Organizational personnel with plan of action and milestones development and - implementation responsibilities
-organizational personnel with information security and privacy - responsibilities
-Mechanisms for developing, implementing, and maintaining plan of action and - milestones
-frequency at which to update the authorizations is defined;
-Assign a senior official as the authorizing official for the system;
-Assign a senior official as the authorizing official for common controls - available for inheritance by organizational systems;
-Ensure that the authorizing official for the system, before commencing - operations:
-Accepts the use of common controls inherited by the system; and
-Authorizes the system to operate;
-Ensure that the authorizing official for common controls authorizes the use - of those controls for inheritance by organizational systems;
-Update the authorizations
Authorizations are official management decisions by senior officials to authorize - operation of systems, authorize the use of common controls for inheritance by - organizational systems, and explicitly accept the risk to organizational - operations and assets, individuals, other organizations, and the Nation based on - the implementation of agreed-upon controls. Authorizing officials provide - budgetary oversight for organizational systems and common controls or assume - responsibility for the mission and business functions supported by those systems - or common controls. The authorization process is a federal responsibility, and - therefore, authorizing officials must be federal employees. Authorizing - officials are both responsible and accountable for security and privacy risks - associated with the operation and use of organizational systems. Nonfederal - organizations may have similar processes to authorize systems and senior - officials that assume the authorization role and associated responsibilities.
-Authorizing officials issue ongoing authorizations of systems based on evidence - produced from implemented continuous monitoring programs. Robust continuous - monitoring programs reduce the need for separate reauthorization processes. - Through the employment of comprehensive continuous monitoring processes, the - information contained in authorization packages (i.e., security and privacy - plans, assessment reports, and plans of action and milestones) is updated on an - ongoing basis. This provides authorizing officials, common control providers, - and system owners with an up-to-date status of the security and privacy posture - of their systems, controls, and operating environments. To reduce the cost of - reauthorization, authorizing officials can leverage the results of continuous - monitoring processes to the maximum extent possible as the basis for rendering - reauthorization decisions.
-a senior official is assigned as the authorizing official for the system;
- -a senior official is assigned as the authorizing official for common controls - available for inheritance by organizational systems;
- -before commencing operations, the authorizing official for the system - accepts the use of common controls inherited by the system;
- -before commencing operations, the authorizing official for the system - authorizes the system to operate;
- -the authorizing official for common controls authorizes the use of those - controls for inheritance by organizational systems;
- -the authorizations are updated
Assessment, authorization, and monitoring policy
-procedures addressing authorization
-system security plan, privacy plan, assessment report, plan of action and - milestones
-authorization statement
-other relevant documents or records
-Organizational personnel with authorization responsibilities
-organizational personnel with information security and privacy - responsibilities
-Mechanisms that facilitate authorizations and updates
-system-level metrics to be monitored are defined;
-frequencies at which to monitor control effectiveness are defined;
-frequencies at which to assess control effectiveness are defined;
-personnel or roles to whom the security status of the system is reported are - defined;
-frequency at which the security status of the system is reported is defined;
-personnel or roles to whom the privacy status of the system is reported are - defined;
-frequency at which the privacy status of the system is reported is defined;
-Develop a system-level continuous monitoring strategy and implement continuous - monitoring in accordance with the organization-level continuous monitoring - strategy that includes:
-Establishing the following system-level metrics to be monitored:
Establishing
Ongoing control assessments in accordance with the continuous monitoring - strategy;
-Ongoing monitoring of system and organization-defined metrics in accordance - with the continuous monitoring strategy;
-Correlation and analysis of information generated by control assessments and - monitoring;
-Response actions to address results of the analysis of control assessment and - monitoring information; and
-Reporting the security and privacy status of the system to
Continuous monitoring at the system level facilitates ongoing awareness of the
- system security and privacy posture to support organizational risk management
- decisions. The terms continuous
and ongoing
imply that
- organizations assess and monitor their controls and risks at a frequency
- sufficient to support risk-based decisions. Different types of controls may
- require different monitoring frequencies. The results of continuous monitoring
- generate risk response actions by organizations. When monitoring the
- effectiveness of multiple controls that have been grouped into capabilities, a
- root-cause analysis may be needed to determine the specific control that has
- failed. Continuous monitoring programs allow organizations to maintain the
- authorizations of systems and common controls in highly dynamic environments of
- operation with changing mission and business needs, threats, vulnerabilities,
- and technologies. Having access to security and privacy information on a
- continuing basis through reports and dashboards gives organizational officials
- the ability to make effective and timely risk management decisions, including
- ongoing authorization decisions.
Automation supports more frequent updates to hardware, software, and firmware - inventories, authorization packages, and other system information. Effectiveness - is further enhanced when continuous monitoring outputs are formatted to provide - information that is specific, measurable, actionable, relevant, and timely. - Continuous monitoring activities are scaled in accordance with the security - categories of systems. Monitoring requirements, including the need for specific - monitoring, may be referenced in other controls and control enhancements, such - as AC-2g, - AC-2(7), - AC-2(12)(a), - AC-2(7)(b), - AC-2(7)(c), AC-17(1), AT-4a - , - AU-13, - AU-13(1), - AU-13(2), CM-3f, CM-6d, CM-11c, IR-5, MA-2b, MA-3a, MA-4a, PE-3d, PE-6, PE-14b, - PE-16, - PE-20, - PM-6, - PM-23, - PM-31, PS-7e, SA-9c, - SR-4, - SC-5(3)(b), SC-7a, - SC-7(24)(b), SC-18b, - SC-43b , and SI-4.
-a system-level continuous monitoring strategy is developed;
- -system-level continuous monitoring is implemented in accordance with the - organization-level continuous monitoring strategy;
- -system-level continuous monitoring includes establishment of the following
- system-level metrics to be monitored:
system-level continuous monitoring includes established
system-level continuous monitoring includes established
system-level continuous monitoring includes ongoing control assessments in - accordance with the continuous monitoring strategy;
- -system-level continuous monitoring includes ongoing monitoring of system and - organization-defined metrics in accordance with the continuous monitoring - strategy;
- -system-level continuous monitoring includes correlation and analysis of - information generated by control assessments and monitoring;
- -system-level continuous monitoring includes response actions to address the - results of the analysis of control assessment and monitoring information;
- -system-level continuous monitoring includes reporting the security status
- of the system to
system-level continuous monitoring includes reporting the privacy status
- of the system to
Assessment, authorization, and monitoring policy
-organizational continuous monitoring strategy
-system-level continuous monitoring strategy
-procedures addressing continuous monitoring of system controls
-procedures addressing configuration management
-control assessment report
-plan of action and milestones
-system monitoring records
-configuration management records
-impact analyses
-status reports
-system security plan
-privacy plan
-other relevant documents or records
-Organizational personnel with continuous monitoring responsibilities
-organizational personnel with information security and privacy - responsibilities
-system/network administrators
-Mechanisms implementing continuous monitoring
-mechanisms supporting response actions to address assessment and monitoring - results
-mechanisms supporting security and privacy status reporting
-Employ independent assessors or assessment teams to monitor the controls in - the system on an ongoing basis.
-Organizations maximize the value of control assessments by requiring that - assessments be conducted by assessors with appropriate levels of - independence. The level of required independence is based on organizational - continuous monitoring strategies. Assessor independence provides a degree of - impartiality to the monitoring process. To achieve such impartiality, - assessors do not create a mutual or conflicting interest with the - organizations where the assessments are being conducted, assess their own - work, act as management or employees of the organizations they are serving, - or place themselves in advocacy positions for the organizations acquiring - their services.
-independent assessors or assessment teams are employed to monitor the - controls in the system on an ongoing basis.
- -Assessment, authorization, and monitoring policy
-organizational continuous monitoring strategy
-system-level continuous monitoring strategy
-procedures addressing continuous monitoring of system controls
-control assessment report
-plan of action and milestones
-system monitoring records
-impact analyses
-status reports
-system security plan
-privacy plan
-other relevant documents or records
-Organizational personnel with continuous monitoring responsibilities
-organizational personnel with information security and privacy - responsibilities
-Ensure risk monitoring is an integral part of the continuous monitoring - strategy that includes the following:
-Effectiveness monitoring;
-Compliance monitoring; and
-Change monitoring.
-Risk monitoring is informed by the established organizational risk tolerance. - Effectiveness monitoring determines the ongoing effectiveness of the - implemented risk response measures. Compliance monitoring verifies that - required risk response measures are implemented. It also verifies that - security and privacy requirements are satisfied. Change monitoring - identifies changes to organizational systems and environments of operation - that may affect security and privacy risk.
-risk monitoring is an integral part of the continuous monitoring strategy;
-effectiveness monitoring is included in risk monitoring;
- -compliance monitoring is included in risk monitoring;
- -change monitoring is included in risk monitoring.
- -Assessment, authorization, and monitoring policy
-organizational continuous monitoring strategy
-system-level continuous monitoring strategy
-procedures addressing continuous monitoring of system controls
-assessment report
-plan of action and milestones
-system monitoring records
-impact analyses
-status reports
-system security plan
-privacy plan
-other relevant documents or records
-Organizational personnel with continuous monitoring responsibilities
-organizational personnel with information security and privacy - responsibilities
-Mechanisms supporting risk monitoring
-system components or classes of components requiring internal connections to - the system are defined;
-conditions requiring termination of internal connections are defined;
-frequency at which to review the continued need for each internal connection - is defined;
-Authorize internal connections of
Document, for each internal connection, the interface characteristics, - security and privacy requirements, and the nature of the information - communicated;
-Terminate internal system connections after
Review
Internal system connections are connections between organizational systems and - separate constituent system components (i.e., connections between components - that are part of the same system) including components used for system - development. Intra-system connections include connections with mobile devices, - notebook and desktop computers, tablets, printers, copiers, facsimile machines, - scanners, sensors, and servers. Instead of authorizing each internal system - connection individually, organizations can authorize internal connections for a - class of system components with common characteristics and/or configurations, - including printers, scanners, and copiers with a specified processing, - transmission, and storage capability or smart phones and tablets with a specific - baseline configuration. The continued need for an internal system connection is - reviewed from the perspective of whether it provides support for organizational - missions or business functions.
-internal connections of
for each internal connection, the interface characteristics are - documented;
- -for each internal connection, the security requirements are documented;
- -for each internal connection, the privacy requirements are documented;
- -for each internal connection, the nature of the information communicated - is documented;
- -internal system connections are terminated after
the continued need for each internal connection is reviewed
Assessment, authorization, and monitoring policy
-access control policy
-procedures addressing system connections
-system and communications protection policy
-system design documentation
-system configuration settings and associated documentation
-list of components or classes of components authorized as internal system - connections
-assessment report
-system audit records
-system security plan
-privacy plan
-other relevant documents or records
-Organizational personnel with responsibilities for developing, implementing, - or authorizing internal system connections
-organizational personnel with information security and privacy - responsibilities
-Mechanisms supporting internal system connections
-personnel or roles to whom the configuration management policy is to be - disseminated is/are defined;
-personnel or roles to whom the configuration management procedures are to be - disseminated is/are defined;
-an official to manage the configuration management policy and procedures is - defined;
-the frequency at which the current configuration management policy is - reviewed and updated is defined;
-events that would require the current configuration management policy to be - reviewed and updated are defined;
-the frequency at which the current configuration management procedures are - reviewed and updated is defined;
-events that would require configuration management procedures to be reviewed - and updated are defined;
-Develop, document, and disseminate to
Addresses purpose, scope, roles, responsibilities, management - commitment, coordination among organizational entities, and - compliance; and
-Is consistent with applicable laws, executive orders, directives, - regulations, policies, standards, and guidelines; and
-Procedures to facilitate the implementation of the configuration - management policy and the associated configuration management controls;
-Designate an
Review and update the current configuration management:
-Policy
Procedures
Configuration management policy and procedures address the controls in the CM - family that are implemented within systems and organizations. The risk - management strategy is an important factor in establishing such policies and - procedures. Policies and procedures contribute to security and privacy - assurance. Therefore, it is important that security and privacy programs - collaborate on the development of configuration management policy and - procedures. Security and privacy program policies and procedures at the - organization level are preferable, in general, and may obviate the need for - mission- or system-specific policies and procedures. The policy can be included - as part of the general security and privacy policy or be represented by multiple - policies that reflect the complex nature of organizations. Procedures can be - established for security and privacy programs, for mission/business processes, - and for systems, if needed. Procedures describe how the policies or controls are - implemented and can be directed at the individual or role that is the object of - the procedure. Procedures can be documented in system security and privacy plans - or in one or more separate documents. Events that may precipitate an update to - configuration management policy and procedures include, but are not limited to, - assessment or audit findings, security incidents or breaches, or changes in - applicable laws, executive orders, directives, regulations, policies, standards, - and guidelines. Simply restating controls does not constitute an organizational - policy or procedure.
-a configuration management policy is developed and documented;
- -the configuration management policy is disseminated to
configuration management procedures to facilitate the implementation of - the configuration management policy and associated configuration - management controls are developed and documented;
- -the configuration management procedures are disseminated to
the
the
the
the
the
the
the
the configuration management policy is consistent with applicable - laws, Executive Orders, directives, regulations, policies, - standards, and guidelines;
- -the
the current configuration management policy is reviewed and updated
the current configuration management policy is reviewed and updated
- following
the current configuration management procedures are reviewed and
- updated
the current configuration management procedures are reviewed and
- updated following
Configuration management policy and procedures
-security and privacy program policies and procedures
-assessment or audit findings
-documentation of security incidents or breaches
-system security plan
-privacy plan
-risk management strategy
-other relevant artifacts, documents, or records
-Organizational personnel with configuration management responsibilities
-organizational personnel with information security and privacy - responsibilities
-the frequency of baseline configuration review and update is defined;
-the circumstances requiring baseline configuration review and update are - defined;
-Develop, document, and maintain under configuration control, a current - baseline configuration of the system; and
-Review and update the baseline configuration of the system:
-When required due to
When system components are installed or upgraded.
-Baseline configurations for systems and system components include connectivity, - operational, and communications aspects of systems. Baseline configurations are - documented, formally reviewed, and agreed-upon specifications for systems or - configuration items within those systems. Baseline configurations serve as a - basis for future builds, releases, or changes to systems and include security - and privacy control implementations, operational procedures, information about - system components, network topology, and logical placement of components in the - system architecture. Maintaining baseline configurations requires creating new - baselines as organizational systems change over time. Baseline configurations of - systems reflect the current enterprise architecture.
-a current baseline configuration of the system is developed and - documented;
- -a current baseline configuration of the system is maintained under - configuration control;
- -the baseline configuration of the system is reviewed and updated
the baseline configuration of the system is reviewed and updated when
- required due to
the baseline configuration of the system is reviewed and updated when - system components are installed or upgraded.
- -Configuration management policy
-procedures addressing the baseline configuration of the system
-configuration management plan
-enterprise architecture documentation
-system design documentation
-system security plan
-privacy plan
-system architecture and configuration documentation
-system configuration settings and associated documentation
-system component inventory
-change control records
-other relevant documents or records
-Organizational personnel with configuration management responsibilities
-organizational personnel with information security and privacy - responsibilities
-system/network administrators
-Organizational processes for managing baseline configurations
-mechanisms supporting configuration control of the baseline configuration
-automated mechanisms for maintaining baseline configuration of the system - are defined;
-Maintain the currency, completeness, accuracy, and availability of the
- baseline configuration of the system using
Automated mechanisms that help organizations maintain consistent baseline - configurations for systems include configuration management tools, hardware, - software, firmware inventory tools, and network management tools. Automated - tools can be used at the organization level, mission and business process - level, or system level on workstations, servers, notebook computers, network - components, or mobile devices. Tools can be used to track version numbers on - operating systems, applications, types of software installed, and current - patch levels. Automation support for accuracy and currency can be satisfied - by the implementation of - CM-8(2) for organizations that combine system component inventory and - baseline configuration activities.
-the currency of the baseline configuration of the system is maintained
- using
the completeness of the baseline configuration of the system is
- maintained using
the accuracy of the baseline configuration of the system is maintained
- using
the availability of the baseline configuration of the system is
- maintained using
Configuration management policy
-procedures addressing the baseline configuration of the system
-configuration management plan
-system design documentation
-system architecture and configuration documentation
-system configuration settings and associated documentation
-system component inventory
-configuration change control records
-system security plan
-other relevant documents or records
-Organizational personnel with configuration management responsibilities
-organizational personnel with information security responsibilities
-system/network administrators
-Organizational processes for managing baseline configurations
-automated mechanisms implementing baseline configuration maintenance
-the number of previous baseline configuration versions to be retained is - defined;
-Retain
Retaining previous versions of baseline configurations to support rollback - include hardware, software, firmware, configuration files, configuration - records, and associated documentation.
-Configuration management policy
-procedures addressing the baseline configuration of the system
-configuration management plan
-system architecture and configuration documentation
-system configuration settings and associated documentation
-copies of previous baseline configuration versions
-system security plan
-other relevant documents or records
-Organizational personnel with configuration management responsibilities
-organizational personnel with information security responsibilities
-system/network administrators
-Organizational processes for managing baseline configurations
-the systems or system components to be issued when individuals travel to - high-risk areas are defined;
-configurations for systems or system components to be issued when - individuals travel to high-risk areas are defined;
-the controls to be applied when the individuals return from travel are - defined;
-Issue
Apply the following controls to the systems or components when the
- individuals return from travel:
When it is known that systems or system components will be in high-risk areas - external to the organization, additional controls may be implemented to - counter the increased threat in such areas. For example, organizations can - take actions for notebook computers used by individuals departing on and - returning from travel. Actions include determining the locations that are of - concern, defining the required configurations for the components, ensuring - that components are configured as intended before travel is initiated, and - applying controls to the components after travel is completed. Specially - configured notebook computers include computers with sanitized hard drives, - limited applications, and more stringent configuration settings. Controls - applied to mobile devices upon return from travel include examining the - mobile device for signs of physical tampering and purging and reimaging disk - drives. Protecting information that resides on mobile devices is addressed - in the MP (Media Protection) family.
-Configuration management policy
-configuration management plan
-procedures addressing the baseline configuration of the system
-procedures addressing system component installations and upgrades
-system architecture and configuration documentation
-system configuration settings and associated documentation
-system component inventory
-records of system baseline configuration reviews and updates
-system component installations/upgrades and associated records
-change control records
-system security plan
-other relevant documents or records
-Organizational personnel with configuration management responsibilities
-organizational personnel with information security responsibilities
-system/network administrators
-Organizational processes for managing baseline configurations
-the time period to retain records of configuration-controlled changes is - defined;
-the configuration change control element responsible for coordinating and - overseeing change control activities is defined;
-the frequency at which the configuration control element convenes is defined - (if selected);
-configuration change conditions that prompt the configuration control element - to convene are defined (if selected);
-Determine and document the types of changes to the system that are - configuration-controlled;
-Review proposed configuration-controlled changes to the system and approve or - disapprove such changes with explicit consideration for security and privacy - impact analyses;
-Document configuration change decisions associated with the system;
-Implement approved configuration-controlled changes to the system;
-Retain records of configuration-controlled changes to the system for
Monitor and review activities associated with configuration-controlled - changes to the system; and
-Coordinate and provide oversight for configuration change control activities
- through
Configuration change control for organizational systems involves the systematic - proposal, justification, implementation, testing, review, and disposition of - system changes, including system upgrades and modifications. Configuration - change control includes changes to baseline configurations, configuration items - of systems, operational procedures, configuration settings for system - components, remediate vulnerabilities, and unscheduled or unauthorized changes. - Processes for managing configuration changes to systems include Configuration - Control Boards or Change Advisory Boards that review and approve proposed - changes. For changes that impact privacy risk, the senior agency official for - privacy updates privacy impact assessments and system of records notices. For - new systems or major upgrades, organizations consider including representatives - from the development organizations on the Configuration Control Boards or Change - Advisory Boards. Auditing of changes includes activities before and after - changes are made to systems and the auditing activities required to implement - such changes. See also SA-10.
-the types of changes to the system that are configuration-controlled are - determined and documented;
- -proposed configuration-controlled changes to the system are reviewed;
- -proposed configuration-controlled changes to the system are approved or - disapproved with explicit consideration for security and privacy impact - analyses;
- -configuration change decisions associated with the system are documented;
- -approved configuration-controlled changes to the system are implemented;
- -records of configuration-controlled changes to the system are retained for
activities associated with configuration-controlled changes to the system - are monitored;
- -activities associated with configuration-controlled changes to the system - are reviewed;
- -configuration change control activities are coordinated and overseen by
the configuration control element convenes
Configuration management policy
-procedures addressing system configuration change control
-configuration management plan
-system architecture and configuration documentation
-change control records
-system audit records
-change control audit and review reports
-agenda/minutes/documentation from configuration change control oversight - meetings
-system security plan
-privacy plan
-privacy impact assessments
-system of records notices
-other relevant documents or records
-Organizational personnel with configuration change control responsibilities
-organizational personnel with information security and privacy - responsibilities
-system/network administrators
-members of change control board or similar
-Organizational processes for configuration change control
-mechanisms that implement configuration change control
-Test, validate, and document changes to the system before finalizing the - implementation of the changes.
-Changes to systems include modifications to hardware, software, or firmware - components and configuration settings defined in CM-6 . - Organizations ensure that testing does not interfere with system operations - that support organizational mission and business functions. Individuals or - groups conducting tests understand security and privacy policies and - procedures, system security and privacy policies and procedures, and the - health, safety, and environmental risks associated with specific facilities - or processes. Operational systems may need to be taken offline, or - replicated to the extent feasible, before testing can be conducted. If - systems must be taken offline for testing, the tests are scheduled to occur - during planned system outages whenever possible. If the testing cannot be - conducted on operational systems, organizations employ compensating - controls.
-changes to the system are tested before finalizing the implementation of - the changes;
- -changes to the system are validated before finalizing the implementation - of the changes;
- -changes to the system are documented before finalizing the implementation - of the changes.
- -Configuration management policy
-configuration management plan
-procedures addressing system configuration change control
-system design documentation
-system architecture and configuration documentation
-system configuration settings and associated documentation
-test records
-validation records
-change control records
-system audit records
-system security plan
-other relevant documents or records
-Organizational personnel with configuration change control - responsibilities
-organizational personnel with information security responsibilities
-system/network administrators
-system developers
-members of change control board or similar
-Organizational processes for configuration change control
-mechanisms supporting and/or implementing, testing, validating, and - documenting system changes
-security representatives required to be members of the change control - element are defined;
-privacy representatives required to be members of the change control - element are defined;
-the configuration change control element of which the security and - privacy representatives are to be members is defined;
-Require
Information security and privacy representatives include system security - officers, senior agency information security officers, senior agency - officials for privacy, or system privacy officers. Representation by - personnel with information security and privacy expertise is important - because changes to system configurations can have unintended side effects, - some of which may be security- or privacy-relevant. Detecting such changes - early in the process can help avoid unintended, negative consequences that - could ultimately affect the security and privacy posture of systems. The - configuration change control element referred to in the second - organization-defined parameter reflects the change control elements defined - by organizations in CM-3g.
-Configuration management policy
-procedures addressing system configuration change control
-configuration management plan
-system security plan
-privacy plan
-other relevant documents or records
-Organizational personnel with configuration change control - responsibilities
-organizational personnel with information security and privacy - responsibilities
-members of change control board or similar
-Organizational processes for configuration change control
-Analyze changes to the system to determine potential security and privacy impacts - prior to change implementation.
-Organizational personnel with security or privacy responsibilities conduct impact - analyses. Individuals conducting impact analyses possess the necessary skills - and technical expertise to analyze the changes to systems as well as the - security or privacy ramifications. Impact analyses include reviewing security - and privacy plans, policies, and procedures to understand control requirements; - reviewing system design documentation and operational procedures to understand - control implementation and how specific system changes might affect the - controls; reviewing the impact of changes on organizational supply chain - partners with stakeholders; and determining how potential changes to a system - create new risks to the privacy of individuals and the ability of implemented - controls to mitigate those risks. Impact analyses also include risk assessments - to understand the impact of the changes and determine if additional controls are - required.
-changes to the system are analyzed to determine potential security impacts - prior to change implementation;
- -changes to the system are analyzed to determine potential privacy impacts - prior to change implementation.
- -Configuration management policy
-procedures addressing security impact analyses for changes to the system
-procedures addressing privacy impact analyses for changes to the system
-configuration management plan
-security impact analysis documentation
-privacy impact analysis documentation
-privacy impact assessment
-privacy risk assessment documentation, system design documentation
-analysis tools and associated outputs
-change control records
-system audit records
-system security plan
-privacy plan
-other relevant documents or records
-Organizational personnel with responsibility for conducting security impact - analyses
-organizational personnel with responsibility for conducting privacy impact - analyses
-organizational personnel with information security and privacy - responsibilities
-system developer
-system/network administrators
-members of change control board or similar
-Organizational processes for security impact analyses
-organizational processes for privacy impact analyses
-After system changes, verify that the impacted controls are implemented - correctly, operating as intended, and producing the desired outcome with - regard to meeting the security and privacy requirements for the system.
-Implementation in this context refers to installing changed code in the - operational system that may have an impact on security or privacy controls.
-the impacted controls are implemented correctly with regard to meeting - the security requirements for the system after system changes;
- -the impacted controls are implemented correctly with regard to meeting - the privacy requirements for the system after system changes;
- -the impacted controls are operating as intended with regard to meeting - the security requirements for the system after system changes;
- -the impacted controls are operating as intended with regard to meeting - the privacy requirements for the system after system changes;
- -the impacted controls are producing the desired outcome with regard to - meeting the security requirements for the system after system changes;
- -the impacted controls are producing the desired outcome with regard to - meeting the privacy requirements for the system after system changes.
- -Configuration management policy
-procedures addressing security impact analyses for changes to the system
-procedures addressing privacy impact analyses for changes to the system
-privacy risk assessment documentation
-configuration management plan
-security and privacy impact analysis documentation
-privacy impact assessment
-analysis tools and associated outputs
-change control records
-control assessment results
-system audit records
-system component inventory
-system security plan
-privacy plan
-other relevant documents or records
-Organizational personnel with responsibility for conducting security and - privacy impact analyses
-organizational personnel with information security and privacy - responsibilities
-system/network administrators
-security and privacy assessors
-Organizational processes for security and privacy impact analyses
-mechanisms supporting and/or implementing security and privacy impact - analyses of changes
-Define, document, approve, and enforce physical and logical access restrictions - associated with changes to the system.
-Changes to the hardware, software, or firmware components of systems or the - operational procedures related to the system can potentially have significant - effects on the security of the systems or individuals’ privacy. Therefore, - organizations permit only qualified and authorized individuals to access systems - for purposes of initiating changes. Access restrictions include physical and - logical access controls (see AC-3 and PE-3 - ), software libraries, workflow automation, media libraries, abstract layers - (i.e., changes implemented into external interfaces rather than directly into - systems), and change windows (i.e., changes occur only during specified times).
-physical access restrictions associated with changes to the system are - defined and documented;
- -physical access restrictions associated with changes to the system are - approved;
- -physical access restrictions associated with changes to the system are - enforced;
- -logical access restrictions associated with changes to the system are defined - and documented;
- -logical access restrictions associated with changes to the system are - approved;
- -logical access restrictions associated with changes to the system are - enforced.
- -Configuration management policy
-procedures addressing access restrictions for changes to the system
-configuration management plan
-system design documentation
-system architecture and configuration documentation
-system configuration settings and associated documentation
-logical access approvals
-physical access approvals
-access credentials
-change control records
-system audit records
-system security plan
-other relevant documents or records
-Organizational personnel with logical access control responsibilities
-organizational personnel with physical access control responsibilities
-organizational personnel with information security responsibilities
-system/network administrators
-Organizational processes for managing access restrictions to change
-mechanisms supporting, implementing, or enforcing access restrictions - associated with changes to the system
-common secure configurations to establish and document configuration settings - for components employed within the system are defined;
-system components for which approval of deviations is needed are defined;
-operational requirements necessitating approval of deviations are defined;
-Establish and document configuration settings for components employed within
- the system that reflect the most restrictive mode consistent with
- operational requirements using
Implement the configuration settings;
-Identify, document, and approve any deviations from established configuration
- settings for
Monitor and control changes to the configuration settings in accordance with - organizational policies and procedures.
-Configuration settings are the parameters that can be changed in the hardware, - software, or firmware components of the system that affect the security and - privacy posture or functionality of the system. Information technology products - for which configuration settings can be defined include mainframe computers, - servers, workstations, operating systems, mobile devices, input/output devices, - protocols, and applications. Parameters that impact the security posture of - systems include registry settings; account, file, or directory permission - settings; and settings for functions, protocols, ports, services, and remote - connections. Privacy parameters are parameters impacting the privacy posture of - systems, including the parameters required to satisfy other privacy controls. - Privacy parameters include settings for access controls, data processing - preferences, and processing and retention permissions. Organizations establish - organization-wide configuration settings and subsequently derive specific - configuration settings for systems. The established settings become part of the - configuration baseline for the system.
-Common secure configurations (also known as security configuration checklists, - lockdown and hardening guides, and security reference guides) provide - recognized, standardized, and established benchmarks that stipulate secure - configuration settings for information technology products and platforms as well - as instructions for configuring those products or platforms to meet operational - requirements. Common secure configurations can be developed by a variety of - organizations, including information technology product developers, - manufacturers, vendors, federal agencies, consortia, academia, industry, and - other organizations in the public and private sectors.
-Implementation of a common secure configuration may be mandated at the - organization level, mission and business process level, system level, or at a - higher level, including by a regulatory agency. Common secure configurations - include the United States Government Configuration Baseline USGCB and security - technical implementation guides (STIGs), which affect the implementation of CM-6 and other controls such as AC-19 - and CM-7 . The Security Content Automation Protocol (SCAP) - and the defined standards within the protocol provide an effective method to - uniquely identify, track, and control configuration settings.
-configuration settings that reflect the most restrictive mode consistent with
- operational requirements are established and documented for components
- employed within the system using
the configuration settings documented in CM-06a are implemented;
- -any deviations from established configuration settings for
any deviations from established configuration settings for
changes to the configuration settings are monitored in accordance with - organizational policies and procedures;
- -changes to the configuration settings are controlled in accordance with - organizational policies and procedures.
- -Configuration management policy
-procedures addressing configuration settings for the system
-configuration management plan
-system design documentation
-system configuration settings and associated documentation
-common secure configuration checklists
-system component inventory
-evidence supporting approved deviations from established configuration - settings
-change control records
-system data processing and retention permissions
-system audit records
-system security plan
-privacy plan
-other relevant documents or records
-Organizational personnel with security configuration management - responsibilities
-organizational personnel with privacy configuration management - responsibilities
-organizational personnel with information security and privacy - responsibilities
-system/network administrators
-Organizational processes for managing configuration settings
-mechanisms that implement, monitor, and/or control system configuration - settings
-mechanisms that identify and/or document deviations from established - configuration settings
-mission-essential capabilities for the system are defined;
-functions to be prohibited or restricted are defined;
-ports to be prohibited or restricted are defined;
-protocols to be prohibited or restricted are defined;
-software to be prohibited or restricted is defined;
-services to be prohibited or restricted are defined;
-Configure the system to provide only
Prohibit or restrict the use of the following functions, ports, protocols,
- software, and/or services:
Systems provide a wide variety of functions and services. Some of the functions - and services routinely provided by default may not be necessary to support - essential organizational missions, functions, or operations. Additionally, it is - sometimes convenient to provide multiple services from a single system - component, but doing so increases risk over limiting the services provided by - that single component. Where feasible, organizations limit component - functionality to a single function per component. Organizations consider - removing unused or unnecessary software and disabling unused or unnecessary - physical and logical ports and protocols to prevent unauthorized connection of - components, transfer of information, and tunneling. Organizations employ network - scanning tools, intrusion detection and prevention systems, and end-point - protection technologies, such as firewalls and host-based intrusion detection - systems, to identify and prevent the use of prohibited functions, protocols, - ports, and services. Least functionality can also be achieved as part of the - fundamental design and development of the system (see SA-8, SC-2 , and - SC-3).
-the system is configured to provide only
the use of
the use of
the use of
the use of
the use of
Configuration management policy
-procedures addressing least functionality in the system
-configuration management plan
-system design documentation
-system configuration settings and associated documentation
-system component inventory
-common secure configuration checklists
-system security plan
-other relevant documents or records
-Organizational personnel with security configuration management - responsibilities
-organizational personnel with information security responsibilities
-system/network administrators
-system developers
-Organizational processes prohibiting or restricting functions, ports, - protocols, software, and/or services
-mechanisms implementing restrictions or prohibition of functions, ports, - protocols, software, and/or services
-the frequency at which to review the system to identify unnecessary - and/or non-secure functions, ports, protocols, software, and/or services - is defined;
-functions to be disabled or removed when deemed unnecessary or non-secure - are defined;
-ports to be disabled or removed when deemed unnecessary or non-secure are - defined;
-protocols to be disabled or removed when deemed unnecessary or non-secure - are defined;
-software to be disabled or removed when deemed unnecessary or non-secure - is defined;
-services to be disabled or removed when deemed unnecessary or non-secure - are defined;
-Review the system
Disable or remove
Organizations review functions, ports, protocols, and services provided by - systems or system components to determine the functions and services that - are candidates for elimination. Such reviews are especially important during - transition periods from older technologies to newer technologies (e.g., - transition from IPv4 to IPv6). These technology transitions may require - implementing the older and newer technologies simultaneously during the - transition period and returning to minimum essential functions, ports, - protocols, and services at the earliest opportunity. Organizations can - either decide the relative security of the function, port, protocol, and/or - service or base the security decision on the assessment of other entities. - Unsecure protocols include Bluetooth, FTP, and peer-to-peer networking.
-the system is reviewed
Configuration management policy
-procedures addressing least functionality in the system
-configuration management plan
-system design documentation
-system configuration settings and associated documentation
-common secure configuration checklists
-documented reviews of functions, ports, protocols, and/or services
-change control records
-system audit records
-system security plan
-other relevant documents or records
-Organizational personnel with responsibilities for reviewing functions, - ports, protocols, and services on the system
-organizational personnel with information security responsibilities
-system/network administrators
-system developers
-Organizational processes for reviewing or disabling functions, ports, - protocols, and services on the system
-mechanisms implementing review and disabling of functions, ports, - protocols, and/or services
-policies, rules of behavior, and/or access agreements regarding software - program usage and restrictions are defined (if selected);
-Prevent program execution in accordance with
Prevention of program execution addresses organizational policies, rules of - behavior, and/or access agreements that restrict software usage and the - terms and conditions imposed by the developer or manufacturer, including - software licensing and copyrights. Restrictions include prohibiting - auto-execute features, restricting roles allowed to approve program - execution, permitting or prohibiting specific software programs, or - restricting the number of program instances executed at the same time.
-program execution is prevented in accordance with
Configuration management policy
-procedures addressing least functionality in the system
-configuration management plan
-system design documentation
-system configuration settings and associated documentation
-system component inventory
-common secure configuration checklists
-specifications for preventing software program execution
-change control records
-system audit records
-system security plan
-other relevant documents or records
-Organizational personnel with information security responsibilities
-system/network administrators
-system developers
-Organizational processes preventing program execution on the system
-organizational processes for software program usage and restrictions
-mechanisms preventing program execution on the system
-mechanisms supporting and/or implementing software program usage and - restrictions
-software programs authorized to execute on the system are defined;
-frequency at which to review and update the list of authorized software - programs is defined;
-Identify
Employ a deny-all, permit-by-exception policy to allow the execution of - authorized software programs on the system; and
-Review and update the list of authorized software programs
Authorized software programs can be limited to specific versions or from a - specific source. To facilitate a comprehensive authorized software process - and increase the strength of protection for attacks that bypass application - level authorized software, software programs may be decomposed into and - monitored at different levels of detail. These levels include applications, - application programming interfaces, application modules, scripts, system - processes, system services, kernel functions, registries, drivers, and - dynamic link libraries. The concept of permitting the execution of - authorized software may also be applied to user actions, system ports and - protocols, IP addresses/ranges, websites, and MAC addresses. Organizations - consider verifying the integrity of authorized software programs using - digital signatures, cryptographic checksums, or hash functions. Verification - of authorized software can occur either prior to execution or at system - startup. The identification of authorized URLs for websites is addressed in - CA-3(5) and SC-7.
-a deny-all, permit-by-exception policy to allow the execution of - authorized software programs on the system is employed;
- -the list of authorized software programs is reviewed and updated
Configuration management policy
-procedures addressing least functionality in the system
-configuration management plan
-system design documentation
-system configuration settings and associated documentation
-list of software programs authorized to execute on the system
-system component inventory
-common secure configuration checklists
-review and update records associated with list of authorized software - programs
-change control records
-system audit records
-system security plan
-other relevant documents or records
-Organizational personnel with responsibilities for identifying software - authorized to execute on the system
-organizational personnel with information security responsibilities
-system/network administrators
-Organizational process for identifying, reviewing, and updating programs - authorized to execute on the system
-organizational process for implementing authorized software policy
-mechanisms supporting and/or implementing authorized software policy
-information deemed necessary to achieve effective system component - accountability is defined;
-frequency at which to review and update the system component inventory is - defined;
-Develop and document an inventory of system components that:
-Accurately reflects the system;
-Includes all components within the system;
-Does not include duplicate accounting of components or components - assigned to any other system;
-Is at the level of granularity deemed necessary for tracking and - reporting; and
-Includes the following information to achieve system component
- accountability:
Review and update the system component inventory
System components are discrete, identifiable information technology assets that - include hardware, software, and firmware. Organizations may choose to implement - centralized system component inventories that include components from all - organizational systems. In such situations, organizations ensure that the - inventories include system-specific information required for component - accountability. The information necessary for effective accountability of system - components includes the system name, software owners, software version numbers, - hardware inventory specifications, software license information, and for - networked components, the machine names and network addresses across all - implemented protocols (e.g., IPv4, IPv6). Inventory specifications include date - of receipt, cost, model, serial number, manufacturer, supplier information, - component type, and physical location.
-Preventing duplicate accounting of system components addresses the lack of - accountability that occurs when component ownership and system association is - not known, especially in large or complex connected systems. Effective - prevention of duplicate accounting of system components necessitates use of a - unique identifier for each component. For software inventory, centrally managed - software that is accessed via other systems is addressed as a component of the - system on which it is installed and managed. Software installed on multiple - organizational systems and managed at the system level is addressed for each - individual system and may appear more than once in a centralized component - inventory, necessitating a system association for each software instance in the - centralized inventory to avoid duplicate accounting of components. Scanning - systems implementing multiple network protocols (e.g., IPv4 and IPv6) can result - in duplicate components being identified in different address spaces. The - implementation of - CM-8(7) can help to eliminate duplicate accounting of components.
-an inventory of system components that accurately reflects the system is - developed and documented;
- -an inventory of system components that includes all components within the - system is developed and documented;
- -an inventory of system components that does not include duplicate - accounting of components or components assigned to any other system is - developed and documented;
- -an inventory of system components that is at the level of granularity - deemed necessary for tracking and reporting is developed and documented;
- -an inventory of system components that includes
the system component inventory is reviewed and updated
Configuration management policy
-procedures addressing system component inventory
-configuration management plan
-system security plan
-system design documentation
-system component inventory
-inventory reviews and update records
-system security plan
-other relevant documents or records
-Organizational personnel with component inventory management responsibilities
-organizational personnel with information security responsibilities
-system/network administrators
-Organizational processes for managing the system component inventory
-mechanisms supporting and/or implementing system component inventory
-Update the inventory of system components as part of component installations, - removals, and system updates.
-Organizations can improve the accuracy, completeness, and consistency of - system component inventories if the inventories are updated as part of - component installations or removals or during general system updates. If - inventories are not updated at these key times, there is a greater - likelihood that the information will not be appropriately captured and - documented. System updates include hardware, software, and firmware - components.
-the inventory of system components is updated as part of component - installations;
- -the inventory of system components is updated as part of component - removals;
- -the inventory of system components is updated as part of system updates.
- -Configuration management policy
-procedures addressing system component inventory
-configuration management plan
-system security plan
-system component inventory
-inventory reviews and update records
-change control records
-component installation records
-component removal records
-system security plan
-other relevant documents or records
-Organizational personnel with component inventory updating - responsibilities
-organizational personnel with information security responsibilities
-system/network administrators
-Organizational processes for updating the system component inventory
-mechanisms supporting and/or implementing system component inventory - updates
-automated mechanisms used to detect the presence of unauthorized hardware - within the system are defined;
-automated mechanisms used to detect the presence of unauthorized software - within the system are defined;
-automated mechanisms used to detect the presence of unauthorized firmware - within the system are defined;
-frequency at which automated mechanisms are used to detect the presence - of unauthorized system components within the system is defined;
-personnel or roles to be notified when unauthorized components are - detected is/are defined (if selected);
-Detect the presence of unauthorized hardware, software, and firmware
- components within the system using
Take the following actions when unauthorized components are detected:
Automated unauthorized component detection is applied in addition to the
- monitoring for unauthorized remote connections and mobile devices.
- Monitoring for unauthorized system components may be accomplished on an
- ongoing basis or by the periodic scanning of systems for that purpose.
- Automated mechanisms may also be used to prevent the connection of
- unauthorized components (see
- CM-7(9) ). Automated mechanisms can be implemented in systems or in
- separate system components. When acquiring and implementing automated
- mechanisms, organizations consider whether such mechanisms depend on the
- ability of the system component to support an agent or supplicant in order
- to be detected since some types of components do not have or cannot support
- agents (e.g., IoT devices, sensors). Isolation can be achieved , for
- example, by placing unauthorized system components in separate domains or
- subnets or quarantining such components. This type of component isolation is
- commonly referred to as sandboxing.
the presence of unauthorized hardware within the system is detected
- using
the presence of unauthorized software within the system is detected
- using
the presence of unauthorized firmware within the system is detected
- using
Configuration management policy
-procedures addressing system component inventory
-configuration management plan
-system design documentation
-system security plan
-system component inventory
-change control records
-alerts/notifications of unauthorized components within the system
-system monitoring records
-system maintenance records
-system audit records
-system security plan
-other relevant documents or records
-Organizational personnel with component inventory management - responsibilities
-organizational personnel with responsibilities for managing the automated - mechanisms implementing unauthorized system component detection
-organizational personnel with information security responsibilities
-system/network administrators
-system developers
-Organizational processes for detection of unauthorized system components
-organizational processes for taking action when unauthorized system - components are detected
-automated mechanisms supporting and/or implementing the detection of - unauthorized system components
-automated mechanisms supporting and/or implementing actions taken when - unauthorized system components are detected
-personnel or roles to review and approve the configuration management plan - is/are defined;
-Develop, document, and implement a configuration management plan for the system - that:
-Addresses roles, responsibilities, and configuration management processes and - procedures;
-Establishes a process for identifying configuration items throughout the - system development life cycle and for managing the configuration of the - configuration items;
-Defines the configuration items for the system and places the configuration - items under configuration management;
-Is reviewed and approved by
Protects the configuration management plan from unauthorized disclosure and - modification.
-Configuration management activities occur throughout the system development life - cycle. As such, there are developmental configuration management activities - (e.g., the control of code and software libraries) and operational configuration - management activities (e.g., control of installed components and how the - components are configured). Configuration management plans satisfy the - requirements in configuration management policies while being tailored to - individual systems. Configuration management plans define processes and - procedures for how configuration management is used to support system - development life cycle activities.
-Configuration management plans are generated during the development and - acquisition stage of the system development life cycle. The plans describe how - to advance changes through change management processes; update configuration - settings and baselines; maintain component inventories; control development, - test, and operational environments; and develop, release, and update key - documents.
-Organizations can employ templates to help ensure the consistent and timely - development and implementation of configuration management plans. Templates can - represent a configuration management plan for the organization with subsets of - the plan implemented on a system by system basis. Configuration management - approval processes include the designation of key stakeholders responsible for - reviewing and approving proposed changes to systems, and personnel who conduct - security and privacy impact analyses prior to the implementation of changes to - the systems. Configuration items are the system components, such as the - hardware, software, firmware, and documentation to be configuration-managed. As - systems continue through the system development life cycle, new configuration - items may be identified, and some existing configuration items may no longer - need to be under configuration control.
-a configuration management plan for the system is developed and documented;
- -a configuration management plan for the system is implemented;
- -the configuration management plan addresses roles;
- -the configuration management plan addresses responsibilities;
- -the configuration management plan addresses configuration management - processes and procedures;
- -the configuration management plan establishes a process for identifying - configuration items throughout the system development life cycle;
- -the configuration management plan establishes a process for managing the - configuration of the configuration items;
- -the configuration management plan defines the configuration items for the - system;
- -the configuration management plan places the configuration items under - configuration management;
- -the configuration management plan is reviewed and approved by
the configuration management plan is protected from unauthorized - disclosure;
- -the configuration management plan is protected from unauthorized - modification.
- -Configuration management policy
-procedures addressing configuration management planning
-configuration management plan
-system design documentation
-system security plan
-privacy plan
-other relevant documents or records
-Organizational personnel with responsibilities for developing the - configuration management plan
-organizational personnel with responsibilities for implementing and managing - processes defined in the configuration management plan
-organizational personnel with responsibilities for protecting the - configuration management plan
-organizational personnel with information security and privacy - responsibilities
-system/network administrators
-Organizational processes for developing and documenting the configuration - management plan
-organizational processes for identifying and managing configuration items
-organizational processes for protecting the configuration management plan
-mechanisms implementing the configuration management plan
-mechanisms for managing configuration items
-mechanisms for protecting the configuration management plan
-Use software and associated documentation in accordance with contract - agreements and copyright laws;
-Track the use of software and associated documentation protected by quantity - licenses to control copying and distribution; and
-Control and document the use of peer-to-peer file sharing technology to - ensure that this capability is not used for the unauthorized distribution, - display, performance, or reproduction of copyrighted work.
-Software license tracking can be accomplished by manual or automated methods, - depending on organizational needs. Examples of contract agreements include - software license agreements and non-disclosure agreements.
-software and associated documentation are used in accordance with contract - agreements and copyright laws;
- -the use of software and associated documentation protected by quantity - licenses is tracked to control copying and distribution;
- -the use of peer-to-peer file sharing technology is controlled and documented - to ensure that peer-to-peer file sharing is not used for the unauthorized - distribution, display, performance, or reproduction of copyrighted work.
- -Configuration management policy
-software usage restrictions
-software contract agreements and copyright laws
-site license documentation
-list of software usage restrictions
-software license tracking reports
-configuration management plan
-system security plan
-system security plan
-other relevant documents or records
-Organizational personnel operating, using, and/or maintaining the system
-organizational personnel with software license management responsibilities
-organizational personnel with information security responsibilities
-system/network administrators
-Organizational processes for tracking the use of software protected by - quantity licenses
-organizational processes for controlling/documenting the use of peer-to-peer - file sharing technology
-mechanisms implementing software license tracking
-mechanisms implementing and controlling the use of peer-to-peer files sharing - technology
-policies governing the installation of software by users are defined;
-methods used to enforce software installation policies are defined;
-frequency with which to monitor compliance is defined;
-Establish
Enforce software installation policies through the following methods:
Monitor policy compliance
If provided the necessary privileges, users can install software in
- organizational systems. To maintain control over the software installed,
- organizations identify permitted and prohibited actions regarding software
- installation. Permitted software installations include updates and security
- patches to existing software and downloading new applications from
- organization-approved app stores.
Prohibited software installations
- include software with unknown or suspect pedigrees or software that
- organizations consider potentially malicious. Policies selected for governing
- user-installed software are organization-developed or provided by some external
- entity. Policy enforcement methods can include procedural methods and automated
- methods.
software installation policies are enforced through
compliance with
Configuration management policy
-procedures addressing user-installed software
-configuration management plan
-system security plan
-system design documentation
-system configuration settings and associated documentation
-list of rules governing user installed software
-system monitoring records
-system audit records
-continuous monitoring strategy
-system security plan
-other relevant documents or records
-Organizational personnel with responsibilities for governing user-installed - software
-organizational personnel operating, using, and/or maintaining the system
-organizational personnel monitoring compliance with user-installed software - policy
-organizational personnel with information security responsibilities
-system/network administrators
-Organizational processes governing user-installed software on the system
-mechanisms enforcing policies and methods for governing the installation of - software by users
-mechanisms monitoring policy compliance
-information for which the location is to be identified and documented is - defined;
-Identify and document the location of
Identify and document the users who have access to the system and system - components where the information is processed and stored; and
-Document changes to the location (i.e., system or system components) where - the information is processed and stored.
-Information location addresses the need to understand where information is being - processed and stored. Information location includes identifying where specific - information types and information reside in system components and how - information is being processed so that information flow can be understood and - adequate protection and policy management provided for such information and - system components. The security category of the information is also a factor in - determining the controls necessary to protect the information and the system - component where the information resides (see FIPS 199 ). The location of - the information and system components is also a factor in the architecture and - design of the system (see SA-4, SA-8, - SA-17).
-the location of
the specific system components on which
the specific system components on which
the users who have access to the system and system components where
the users who have access to the system and system components where
changes to the location (i.e., system or system components) where
changes to the location (i.e., system or system components) where
Configuration management policy
-procedures addressing identification and documentation of information - location
-configuration management plan
-system design documentation
-system architecture documentation
-PII inventory documentation
-data mapping documentation
-audit records
-list of users with system and system component access
-change control records
-system component inventory
-system security plan
-privacy plan
-other relevant documents or records
-Organizational personnel with responsibilities for managing information - location and user access to information
-organizational personnel with responsibilities for operating, using, and/or - maintaining the system
-organizational personnel with information security and privacy - responsibilities
-system/network administrators
-system developers
-Organizational processes governing information location
-mechanisms enforcing policies and methods for governing information location
-information to be protected is defined by information type;
-system components where the information is located are defined;
-Use automated tools to identify
The use of automated tools helps to increase the effectiveness and efficiency - of the information location capability implemented within the system. - Automation also helps organizations manage the data produced during - information location activities and share such information across the - organization. The output of automated information location tools can be used - to guide and inform system architecture and design decisions.
-automated tools are used to identify
Configuration management policy
-procedures addressing identification and documentation of information - location
-configuration management plan
-system design documentation
-PII inventory documentation
-data mapping documentation
-change control records
-system component inventory
-system security plan
-privacy plan
-other relevant documents or records
-Organizational personnel with responsibilities for managing information - location
-organizational personnel with information security responsibilities
-system/network administrators
-system developers
-Organizational processes governing information location
-automated mechanisms enforcing policies and methods for governing - information location
-automated tools used to identify information on system components
-personnel or roles to whom the contingency planning policy is to be - disseminated is/are defined;
-personnel or roles to whom the contingency planning procedures are to be - disseminated is/are defined;
-an official to manage the contingency planning policy and procedures is - defined;
-the frequency at which the current contingency planning policy is reviewed - and updated is defined;
-events that would require the current contingency planning policy to be - reviewed and updated are defined;
-the frequency at which the current contingency planning procedures are - reviewed and updated is defined;
-events that would require procedures to be reviewed and updated are defined;
-Develop, document, and disseminate to
Addresses purpose, scope, roles, responsibilities, management - commitment, coordination among organizational entities, and - compliance; and
-Is consistent with applicable laws, executive orders, directives, - regulations, policies, standards, and guidelines; and
-Procedures to facilitate the implementation of the contingency planning - policy and the associated contingency planning controls;
-Designate an
Review and update the current contingency planning:
-Policy
Procedures
Contingency planning policy and procedures address the controls in the CP family - that are implemented within systems and organizations. The risk management - strategy is an important factor in establishing such policies and procedures. - Policies and procedures contribute to security and privacy assurance. Therefore, - it is important that security and privacy programs collaborate on the - development of contingency planning policy and procedures. Security and privacy - program policies and procedures at the organization level are preferable, in - general, and may obviate the need for mission- or system-specific policies and - procedures. The policy can be included as part of the general security and - privacy policy or be represented by multiple policies that reflect the complex - nature of organizations. Procedures can be established for security and privacy - programs, for mission or business processes, and for systems, if needed. - Procedures describe how the policies or controls are implemented and can be - directed at the individual or role that is the object of the procedure. - Procedures can be documented in system security and privacy plans or in one or - more separate documents. Events that may precipitate an update to contingency - planning policy and procedures include assessment or audit findings, security - incidents or breaches, or changes in laws, executive orders, directives, - regulations, policies, standards, and guidelines. Simply restating controls does - not constitute an organizational policy or procedure.
-a contingency planning policy is developed and documented;
- -the contingency planning policy is disseminated to
contingency planning procedures to facilitate the implementation of the - contingency planning policy and associated contingency planning controls - are developed and documented;
- -the contingency planning procedures are disseminated to
the
the
the
the
the
the
the
the
the
the current contingency planning policy is reviewed and updated
the current contingency planning policy is reviewed and updated
- following
the current contingency planning procedures are reviewed and updated
the current contingency planning procedures are reviewed and updated
- following
Contingency planning policy and procedures
-system security plan
-privacy plan
-other relevant documents or records
-Organizational personnel with contingency planning responsibilities
-organizational personnel with information security and privacy - responsibilities
-personnel or roles to review a contingency plan is/are defined;
-personnel or roles to approve a contingency plan is/are defined;
-key contingency personnel (identified by name and/or by role) to whom copies - of the contingency plan are distributed are defined;
-key contingency organizational elements to which copies of the contingency - plan are distributed are defined;
-frequency of contingency plan review is defined;
-key contingency personnel (identified by name and/or by role) to communicate - changes to are defined;
-key contingency organizational elements to communicate changes to are - defined;
-Develop a contingency plan for the system that:
-Identifies essential mission and business functions and associated - contingency requirements;
-Provides recovery objectives, restoration priorities, and metrics;
-Addresses contingency roles, responsibilities, assigned individuals with - contact information;
-Addresses maintaining essential mission and business functions despite a - system disruption, compromise, or failure;
-Addresses eventual, full system restoration without deterioration of the - controls originally planned and implemented;
-Addresses the sharing of contingency information; and
-Is reviewed and approved by
Distribute copies of the contingency plan to
Coordinate contingency planning activities with incident handling activities;
-Review the contingency plan for the system
Update the contingency plan to address changes to the organization, system, - or environment of operation and problems encountered during contingency plan - implementation, execution, or testing;
-Communicate contingency plan changes to
Incorporate lessons learned from contingency plan testing, training, or - actual contingency activities into contingency testing and training; and
-Protect the contingency plan from unauthorized disclosure and modification.
-Contingency planning for systems is part of an overall program for achieving - continuity of operations for organizational mission and business functions. - Contingency planning addresses system restoration and implementation of - alternative mission or business processes when systems are compromised or - breached. Contingency planning is considered throughout the system development - life cycle and is a fundamental part of the system design. Systems can be - designed for redundancy, to provide backup capabilities, and for resilience. - Contingency plans reflect the degree of restoration required for organizational - systems since not all systems need to fully recover to achieve the level of - continuity of operations desired. System recovery objectives reflect applicable - laws, executive orders, directives, regulations, policies, standards, - guidelines, organizational risk tolerance, and system impact level.
-Actions addressed in contingency plans include orderly system degradation, system - shutdown, fallback to a manual mode, alternate information flows, and operating - in modes reserved for when systems are under attack. By coordinating contingency - planning with incident handling activities, organizations ensure that the - necessary planning activities are in place and activated in the event of an - incident. Organizations consider whether continuity of operations during an - incident conflicts with the capability to automatically disable the system, as - specified in - IR-4(5) . Incident response planning is part of contingency planning for - organizations and is addressed in the IR (Incident Response) - family.
-a contingency plan for the system is developed that identifies essential - mission and business functions and associated contingency requirements;
- -a contingency plan for the system is developed that provides recovery - objectives;
- -a contingency plan for the system is developed that provides - restoration priorities;
- -a contingency plan for the system is developed that provides metrics;
- -a contingency plan for the system is developed that addresses - contingency roles;
- -a contingency plan for the system is developed that addresses - contingency responsibilities;
- -a contingency plan for the system is developed that addresses - assigned individuals with contact information;
- -a contingency plan for the system is developed that addresses maintaining - essential mission and business functions despite a system disruption, - compromise, or failure;
- -a contingency plan for the system is developed that addresses eventual, - full-system restoration without deterioration of the controls originally - planned and implemented;
- -a contingency plan for the system is developed that addresses the sharing - of contingency information;
- -a contingency plan for the system is developed that is reviewed by
a contingency plan for the system is developed that is approved by
copies of the contingency plan are distributed to
copies of the contingency plan are distributed to
contingency planning activities are coordinated with incident handling - activities;
- -the contingency plan for the system is reviewed
the contingency plan is updated to address changes to the organization, - system, or environment of operation;
- -the contingency plan is updated to address problems encountered during - contingency plan implementation, execution, or testing;
- -contingency plan changes are communicated to
contingency plan changes are communicated to
lessons learned from contingency plan testing or actual contingency - activities are incorporated into contingency testing;
- -lessons learned from contingency plan training or actual contingency - activities are incorporated into contingency testing and training;
- -the contingency plan is protected from unauthorized disclosure;
- -the contingency plan is protected from unauthorized modification.
- -Contingency planning policy
-procedures addressing contingency operations for the system
-contingency plan
-evidence of contingency plan reviews and updates
-system security plan
-other relevant documents or records
-Organizational personnel with contingency planning and plan implementation - responsibilities
-organizational personnel with incident handling responsibilities
-organizational personnel with knowledge of requirements for mission and - business functions
-organizational personnel with information security responsibilities
-Organizational processes for contingency plan development, review, update, - and protection
-mechanisms for developing, reviewing, updating, and/or protecting the - contingency plan
-Coordinate contingency plan development with organizational elements - responsible for related plans.
-Plans that are related to contingency plans include Business Continuity - Plans, Disaster Recovery Plans, Critical Infrastructure Plans, Continuity of - Operations Plans, Crisis Communications Plans, Insider Threat Implementation - Plans, Data Breach Response Plans, Cyber Incident Response Plans, Breach - Response Plans, and Occupant Emergency Plans.
-contingency plan development is coordinated with organizational elements - responsible for related plans.
- -Contingency planning policy
-procedures addressing contingency operations for the system
-contingency plan
-business contingency plans
-disaster recovery plans
-continuity of operations plans
-crisis communications plans
-critical infrastructure plans
-cyber incident response plan
-insider threat implementation plans
-occupant emergency plans
-system security plan
-other relevant documents or records
-Organizational personnel with contingency planning and plan - implementation responsibilities
-organizational personnel with information security responsibilities
-personnel with responsibility for related plans
-the contingency plan activation time period within which to resume - mission and business functions is defined;
-Plan for the resumption of
Organizations may choose to conduct contingency planning activities to resume - mission and business functions as part of business continuity planning or as - part of business impact analyses. Organizations prioritize the resumption of - mission and business functions. The time period for resuming mission and - business functions may be dependent on the severity and extent of the - disruptions to the system and its supporting infrastructure.
-the resumption of
Contingency planning policy
-procedures addressing contingency operations for the system
-contingency plan
-business impact assessment
-system security plan
-privacy plan
-other related plans
-system security plan
-other relevant documents or records
-Organizational personnel with contingency planning and plan - implementation responsibilities
-organizational personnel with information security and privacy - responsibilities
-organizational personnel with knowledge of requirements for mission and - business functions
-Organizational processes for resumption of missions and business - functions
-Identify critical system assets supporting
Organizations may choose to identify critical assets as part of criticality - analysis, business continuity planning, or business impact analyses. - Organizations identify critical system assets so that additional controls - can be employed (beyond the controls routinely implemented) to help ensure - that organizational mission and business functions can continue to be - conducted during contingency operations. The identification of critical - information assets also facilitates the prioritization of organizational - resources. Critical system assets include technical and operational aspects. - Technical aspects include system components, information technology - services, information technology products, and mechanisms. Operational - aspects include procedures (i.e., manually executed operations) and - personnel (i.e., individuals operating technical controls and/or executing - manual procedures). Organizational program protection plans can assist in - identifying critical assets. If critical assets are resident within or - supported by external service providers, organizations consider implementing - CP-2(7) as a control enhancement.
-critical system assets supporting
Contingency planning policy
-procedures addressing contingency operations for the system
-contingency plan
-business impact assessment
-system security plan
-other relevant documents or records
-Organizational personnel with contingency planning and plan - implementation responsibilities
-organizational personnel with knowledge of requirements for mission and - business functions
-organizational personnel with information security responsibilities
-the time period within which to provide contingency training after assuming a - contingency role or responsibility is defined;
-frequency at which to provide training to system users with a contingency - role or responsibility is defined;
-frequency at which to review and update contingency training content is - defined;
-events necessitating review and update of contingency training are defined;
-Provide contingency training to system users consistent with assigned roles - and responsibilities:
-Within
When required by system changes; and
-Review and update contingency training content
Contingency training provided by organizations is linked to the assigned roles - and responsibilities of organizational personnel to ensure that the appropriate - content and level of detail is included in such training. For example, some - individuals may only need to know when and where to report for duty during - contingency operations and if normal duties are affected; system administrators - may require additional training on how to establish systems at alternate - processing and storage sites; and organizational officials may receive more - specific training on how to conduct mission-essential functions in designated - off-site locations and how to establish communications with other governmental - entities for purposes of coordination on contingency-related activities. - Training for contingency roles or responsibilities reflects the specific - continuity requirements in the contingency plan. Events that may precipitate an - update to contingency training content include, but are not limited to, - contingency plan testing or an actual contingency (lessons learned), assessment - or audit findings, security incidents or breaches, or changes in laws, executive - orders, directives, regulations, policies, standards, and guidelines. At the - discretion of the organization, participation in a contingency plan test or - exercise, including lessons learned sessions subsequent to the test or exercise, - may satisfy contingency plan training requirements.
-contingency training is provided to system users consistent with assigned
- roles and responsibilities within
contingency training is provided to system users consistent with assigned - roles and responsibilities when required by system changes;
- -contingency training is provided to system users consistent with assigned
- roles and responsibilities
the contingency plan training content is reviewed and updated
the contingency plan training content is reviewed and updated following
Contingency planning policy
-procedures addressing contingency training
-contingency plan
-contingency training curriculum
-contingency training material
-contingency training records
-system security plan
-other relevant documents or records
-Organizational personnel with contingency planning, plan implementation, and - training responsibilities
-organizational personnel with information security responsibilities
-Organizational processes for contingency training
-frequency of testing the contingency plan for the system is defined;
-tests for determining the effectiveness of the contingency plan are defined;
-tests for determining readiness to execute the contingency plan are defined;
-Test the contingency plan for the system
Review the contingency plan test results; and
-Initiate corrective actions, if needed.
-Methods for testing contingency plans to determine the effectiveness of the plans - and identify potential weaknesses include checklists, walk-through and tabletop - exercises, simulations (parallel or full interrupt), and comprehensive - exercises. Organizations conduct testing based on the requirements in - contingency plans and include a determination of the effects on organizational - operations, assets, and individuals due to contingency operations. Organizations - have flexibility and discretion in the breadth, depth, and timelines of - corrective actions.
-the contingency plan for the system is tested
the contingency plan test results are reviewed;
- -corrective actions are initiated, if needed.
- -Contingency planning policy
-procedures addressing contingency plan testing
-contingency plan
-contingency plan test documentation
-contingency plan test results
-system security plan
-other relevant documents or records
-Organizational personnel with responsibilities for contingency plan testing, - reviewing, or responding to contingency plan tests
-organizational personnel with information security responsibilities
-Organizational processes for contingency plan testing
-mechanisms supporting the contingency plan and/or contingency plan testing
-Coordinate contingency plan testing with organizational elements responsible - for related plans.
-Plans related to contingency planning for organizational systems include - Business Continuity Plans, Disaster Recovery Plans, Continuity of Operations - Plans, Crisis Communications Plans, Critical Infrastructure Plans, Cyber - Incident Response Plans, and Occupant Emergency Plans. Coordination of - contingency plan testing does not require organizations to create - organizational elements to handle related plans or to align such elements - with specific plans. However, it does require that if such organizational - elements are responsible for related plans, organizations coordinate with - those elements.
-contingency plan testing is coordinated with organizational elements - responsible for related plans.
- -Contingency planning policy
-incident response policy
-procedures addressing contingency plan testing
-contingency plan testing documentation
-contingency plan
-business continuity plans
-disaster recovery plans
-continuity of operations plans
-crisis communications plans
-critical infrastructure plans
-cyber incident response plans
-occupant emergency plans
-system security plan
-other relevant documents or records
-Organizational personnel with contingency plan testing responsibilities
-personnel with responsibilities for related plans
-organizational personnel with information security responsibilities
-Establish an alternate storage site, including necessary agreements to permit - the storage and retrieval of system backup information; and
-Ensure that the alternate storage site provides controls equivalent to that - of the primary site.
-Alternate storage sites are geographically distinct from primary storage sites - and maintain duplicate copies of information and data if the primary storage - site is not available. Similarly, alternate processing sites provide processing - capability if the primary processing site is not available. Geographically - distributed architectures that support contingency requirements may be - considered alternate storage sites. Items covered by alternate storage site - agreements include environmental conditions at the alternate sites, access rules - for systems and facilities, physical and environmental protection requirements, - and coordination of delivery and retrieval of backup media. Alternate storage - sites reflect the requirements in contingency plans so that organizations can - maintain essential mission and business functions despite compromise, failure, - or disruption in organizational systems.
-an alternate storage site is established;
- -establishment of the alternate storage site includes necessary agreements - to permit the storage and retrieval of system backup information;
- -the alternate storage site provides controls equivalent to that of the - primary site.
- -Contingency planning policy
-procedures addressing alternate storage sites
-contingency plan
-alternate storage site agreements
-primary storage site agreements
-system security plan
-other relevant documents or records
-Organizational personnel with contingency plan alternate storage site - responsibilities
-organizational personnel with system recovery responsibilities
-organizational personnel with information security responsibilities
-Organizational processes for storing and retrieving system backup information - at the alternate storage site
-mechanisms supporting and/or implementing the storage and retrieval of system - backup information at the alternate storage site
-Identify an alternate storage site that is sufficiently separated from the - primary storage site to reduce susceptibility to the same threats.
-Threats that affect alternate storage sites are defined in organizational - risk assessments and include natural disasters, structural failures, hostile - attacks, and errors of omission or commission. Organizations determine what - is considered a sufficient degree of separation between primary and - alternate storage sites based on the types of threats that are of concern. - For threats such as hostile attacks, the degree of separation between sites - is less relevant.
-an alternate storage site that is sufficiently separated from the primary - storage site is identified to reduce susceptibility to the same threats.
- -Contingency planning policy
-procedures addressing alternate storage sites
-contingency plan
-alternate storage site
-alternate storage site agreements
-primary storage site agreements
-system security plan
-other relevant documents or records
-Organizational personnel with contingency plan alternate storage site - responsibilities
-organizational personnel with system recovery responsibilities
-organizational personnel with information security responsibilities
-Identify potential accessibility problems to the alternate storage site in - the event of an area-wide disruption or disaster and outline explicit - mitigation actions.
-Area-wide disruptions refer to those types of disruptions that are broad in - geographic scope with such determinations made by organizations based on - organizational assessments of risk. Explicit mitigation actions include - duplicating backup information at other alternate storage sites if access - problems occur at originally designated alternate sites or planning for - physical access to retrieve backup information if electronic accessibility - to the alternate site is disrupted.
-potential accessibility problems to the alternate storage site in the - event of an area-wide disruption or disaster are identified;
- -explicit mitigation actions to address identified accessibility problems - are outlined.
- -Contingency planning policy
-procedures addressing alternate storage sites
-contingency plan
-alternate storage site
-list of potential accessibility problems to alternate storage site
-mitigation actions for accessibility problems to alternate storage site
-organizational risk assessments
-system security plan
-other relevant documents or records
-Organizational personnel with contingency plan alternate storage site - responsibilities
-organizational personnel with system recovery responsibilities
-organizational personnel with information security responsibilities
-system operations for essential mission and business functions are defined;
-time period consistent with recovery time and recovery point objectives is - defined;
-Establish an alternate processing site, including necessary agreements to
- permit the transfer and resumption of
Make available at the alternate processing site, the equipment and supplies - required to transfer and resume operations or put contracts in place to - support delivery to the site within the organization-defined time period for - transfer and resumption; and
-Provide controls at the alternate processing site that are equivalent to - those at the primary site.
-Alternate processing sites are geographically distinct from primary processing - sites and provide processing capability if the primary processing site is not - available. The alternate processing capability may be addressed using a physical - processing site or other alternatives, such as failover to a cloud-based service - provider or other internally or externally provided processing service. - Geographically distributed architectures that support contingency requirements - may also be considered alternate processing sites. Controls that are covered by - alternate processing site agreements include the environmental conditions at - alternate sites, access rules, physical and environmental protection - requirements, and the coordination for the transfer and assignment of personnel. - Requirements are allocated to alternate processing sites that reflect the - requirements in contingency plans to maintain essential mission and business - functions despite disruption, compromise, or failure in organizational systems.
-an alternate processing site, including necessary agreements to permit the
- transfer and resumption of
the equipment and supplies required to transfer operations are made
- available at the alternate processing site or if contracts are in place
- to support delivery to the site within
the equipment and supplies required to resume operations are made
- available at the alternate processing site or if contracts are in place
- to support delivery to the site within
controls provided at the alternate processing site are equivalent to those at - the primary site.
- -Contingency planning policy
-procedures addressing alternate processing sites
-contingency plan
-alternate processing site agreements
-primary processing site agreements
-spare equipment and supplies inventory at alternate processing site
-equipment and supply contracts
-service-level agreements
-system security plan
-other relevant documents or records
-Organizational personnel with responsibilities for contingency planning - and/or alternate site arrangements
-organizational personnel with information security responsibilities
-Organizational processes for recovery at the alternate site
-mechanisms supporting and/or implementing recovery at the alternate - processing site
-Identify an alternate processing site that is sufficiently separated from the - primary processing site to reduce susceptibility to the same threats.
-Threats that affect alternate processing sites are defined in organizational - assessments of risk and include natural disasters, structural failures, - hostile attacks, and errors of omission or commission. Organizations - determine what is considered a sufficient degree of separation between - primary and alternate processing sites based on the types of threats that - are of concern. For threats such as hostile attacks, the degree of - separation between sites is less relevant.
-an alternate processing site that is sufficiently separated from the primary - processing site to reduce susceptibility to the same threats is identified.
- -Contingency planning policy
-procedures addressing alternate processing sites
-contingency plan
-alternate processing site
-alternate processing site agreements
-primary processing site agreements
-system security plan
-other relevant documents or records
-Organizational personnel with contingency plan alternate processing site - responsibilities
-organizational personnel with system recovery responsibilities
-organizational personnel with information security responsibilities
-Identify potential accessibility problems to alternate processing sites in - the event of an area-wide disruption or disaster and outlines explicit - mitigation actions.
-Area-wide disruptions refer to those types of disruptions that are broad in - geographic scope with such determinations made by organizations based on - organizational assessments of risk.
-potential accessibility problems to alternate processing sites in the - event of an area-wide disruption or disaster are identified;
- -explicit mitigation actions to address identified accessibility problems - are outlined.
- -Contingency planning policy
-procedures addressing alternate processing sites
-contingency plan
-alternate processing site
-alternate processing site agreements
-primary processing site agreements
-system security plan
-other relevant documents or records
-Organizational personnel with contingency plan alternate processing site - responsibilities
-organizational personnel with system recovery responsibilities
-organizational personnel with information security responsibilities
-Develop alternate processing site agreements that contain priority-of-service - provisions in accordance with availability requirements (including recovery - time objectives).
-Priority of service agreements refer to negotiated agreements with service - providers that ensure that organizations receive priority treatment - consistent with their availability requirements and the availability of - information resources for logical alternate processing and/or at the - physical alternate processing site. Organizations establish recovery time - objectives as part of contingency planning.
-alternate processing site agreements that contain priority-of-service - provisions in accordance with availability requirements (including recovery - time objectives) are developed.
- -Contingency planning policy
-procedures addressing alternate processing sites
-contingency plan
-alternate processing site agreements
-service-level agreements
-system security plan
-other relevant documents or records
-Organizational personnel with contingency plan alternate processing site - responsibilities
-organizational personnel with system recovery responsibilities
-organizational personnel with information security responsibilities
-organizational personnel with responsibility for acquisitions/contractual - agreements
-system operations to be resumed for essential mission and business functions - are defined;
-time period within which to resume essential mission and business functions - when the primary telecommunications capabilities are unavailable is defined;
-Establish alternate telecommunications services, including necessary agreements
- to permit the resumption of
Telecommunications services (for data and voice) for primary and alternate - processing and storage sites are in scope for CP-8 . - Alternate telecommunications services reflect the continuity requirements in - contingency plans to maintain essential mission and business functions despite - the loss of primary telecommunications services. Organizations may specify - different time periods for primary or alternate sites. Alternate - telecommunications services include additional organizational or commercial - ground-based circuits or lines, network-based approaches to telecommunications, - or the use of satellites. Organizations consider factors such as availability, - quality of service, and access when entering into alternate telecommunications - agreements.
-alternate telecommunications services, including necessary agreements to permit
- the resumption of
Contingency planning policy
-procedures addressing alternate telecommunications services
-contingency plan
-primary and alternate telecommunications service agreements
-system security plan
-other relevant documents or records
-Organizational personnel with contingency plan telecommunications - responsibilities
-organizational personnel with system recovery responsibilities
-organizational personnel with knowledge of requirements for mission and - business functions
-organizational personnel with information security responsibilities
-organizational personnel with responsibility for acquisitions/contractual - agreements
-Mechanisms supporting telecommunications
-Develop primary and alternate telecommunications service agreements that - contain priority-of-service provisions in accordance with availability - requirements (including recovery time objectives); and
-Request Telecommunications Service Priority for all telecommunications - services used for national security emergency preparedness if the - primary and/or alternate telecommunications services are provided by a - common carrier.
-Organizations consider the potential mission or business impact in situations - where telecommunications service providers are servicing other organizations - with similar priority of service provisions. Telecommunications Service - Priority (TSP) is a Federal Communications Commission (FCC) program that - directs telecommunications service providers (e.g., wireline and wireless - phone companies) to give preferential treatment to users enrolled in the - program when they need to add new lines or have their lines restored - following a disruption of service, regardless of the cause. The FCC sets the - rules and policies for the TSP program, and the Department of Homeland - Security manages the TSP program. The TSP program is always in effect and - not contingent on a major disaster or attack taking place. Federal - sponsorship is required to enroll in the TSP program.
-primary telecommunications service agreements that contain - priority-of-service provisions in accordance with availability - requirements (including recovery time objectives) are developed;
- -alternate telecommunications service agreements that contain - priority-of-service provisions in accordance with availability - requirements (including recovery time objectives) are developed;
- -Telecommunications Service Priority is requested for all - telecommunications services used for national security emergency - preparedness if the primary and/or alternate telecommunications services - are provided by a common carrier.
- -Contingency planning policy
-procedures addressing primary and alternate telecommunications services
-contingency plan
-primary and alternate telecommunications service agreements
-Telecommunications Service Priority documentation
-system security plan
-other relevant documents or records
-Organizational personnel with contingency plan telecommunications - responsibilities
-organizational personnel with system recovery responsibilities
-organizational personnel with information security responsibilities
-organizational personnel with responsibility for acquisitions/contractual - agreements
-Mechanisms supporting telecommunications
-Obtain alternate telecommunications services to reduce the likelihood of - sharing a single point of failure with primary telecommunications services.
-In certain circumstances, telecommunications service providers or services - may share the same physical lines, which increases the vulnerability of a - single failure point. It is important to have provider transparency for the - actual physical transmission capability for telecommunication services.
-alternate telecommunications services to reduce the likelihood of sharing a - single point of failure with primary telecommunications services are - obtained.
- -Contingency planning policy
-procedures addressing primary and alternate telecommunications services
-contingency plan
-primary and alternate telecommunications service agreements
-system security plan
-other relevant documents or records
-Organizational personnel with contingency plan telecommunications - responsibilities
-organizational personnel with system recovery responsibilities
-primary and alternate telecommunications service providers
-organizational personnel with information security responsibilities
-system components for which to conduct backups of user-level information is - defined;
-frequency at which to conduct backups of user-level information consistent - with recovery time and recovery point objectives is defined;
-frequency at which to conduct backups of system-level information consistent - with recovery time and recovery point objectives is defined;
-frequency at which to conduct backups of system documentation consistent with - recovery time and recovery point objectives is defined;
-Conduct backups of user-level information contained in
Conduct backups of system-level information contained in the system
Conduct backups of system documentation, including security- and
- privacy-related documentation
Protect the confidentiality, integrity, and availability of backup - information.
-System-level information includes system state information, operating system - software, middleware, application software, and licenses. User-level information - includes information other than system-level information. Mechanisms employed to - protect the integrity of system backups include digital signatures and - cryptographic hashes. Protection of system backup information while in transit - is addressed by MP-5 and SC-8 . System - backups reflect the requirements in contingency plans as well as other - organizational requirements for backing up information. Organizations may be - subject to laws, executive orders, directives, regulations, or policies with - requirements regarding specific categories of information (e.g., personal health - information). Organizational personnel consult with the senior agency official - for privacy and legal counsel regarding such requirements.
-backups of user-level information contained in
backups of system-level information contained in the system are conducted
backups of system documentation, including security- and privacy-related
- documentation are conducted
the confidentiality of backup information is protected;
- -the integrity of backup information is protected;
- -the availability of backup information is protected.
- -Contingency planning policy
-procedures addressing system backup
-contingency plan
-backup storage location(s)
-system backup logs or records
-system security plan
-privacy plan
-other relevant documents or records
-Organizational personnel with system backup responsibilities
-organizational personnel with information security and privacy - responsibilities
-Organizational processes for conducting system backups
-mechanisms supporting and/or implementing system backups
-frequency at which to test backup information for media reliability is - defined;
-frequency at which to test backup information for information integrity - is defined;
-Test backup information
Organizations need assurance that backup information can be reliably - retrieved. Reliability pertains to the systems and system components where - the backup information is stored, the operations used to retrieve the - information, and the integrity of the information being retrieved. - Independent and specialized tests can be used for each of the aspects of - reliability. For example, decrypting and transporting (or transmitting) a - random sample of backup files from the alternate storage or backup site and - comparing the information to the same information at the primary processing - site can provide such assurance.
-backup information is tested
backup information is tested
Contingency planning policy
-procedures addressing system backup
-contingency plan
-system backup test results
-contingency plan test documentation
-contingency plan test results
-system security plan
-other relevant documents or records
-Organizational personnel with system backup responsibilities
-organizational personnel with information security responsibilities
-Organizational processes for conducting system backups
-mechanisms supporting and/or implementing system backups
-backup information to protect against unauthorized disclosure and - modification is defined;
-Implement cryptographic mechanisms to prevent unauthorized disclosure and
- modification of
The selection of cryptographic mechanisms is based on the need to protect the - confidentiality and integrity of backup information. The strength of - mechanisms selected is commensurate with the security category or - classification of the information. Cryptographic protection applies to - system backup information in storage at both primary and alternate - locations. Organizations that implement cryptographic mechanisms to protect - information at rest also consider cryptographic key management solutions.
-cryptographic mechanisms are implemented to prevent unauthorized disclosure
- and modification of
Contingency planning policy
-procedures addressing system backup
-contingency plan
-system design documentation
-system configuration settings and associated documentation
-system security plan
-other relevant documents or records
-Organizational personnel with system backup responsibilities
-organizational personnel with information security responsibilities
-Mechanisms supporting and/or implementing cryptographic protection of - backup information
-time period consistent with recovery time and recovery point objectives for - the recovery of the system is determined;
-time period consistent with recovery time and recovery point objectives for - the reconstitution of the system is determined;
-Provide for the recovery and reconstitution of the system to a known state within
Recovery is executing contingency plan activities to restore organizational - mission and business functions. Reconstitution takes place following recovery - and includes activities for returning systems to fully operational states. - Recovery and reconstitution operations reflect mission and business priorities; - recovery point, recovery time, and reconstitution objectives; and organizational - metrics consistent with contingency plan requirements. Reconstitution includes - the deactivation of interim system capabilities that may have been needed during - recovery operations. Reconstitution also includes assessments of fully restored - system capabilities, reestablishment of continuous monitoring activities, system - reauthorization (if required), and activities to prepare the system and - organization for future disruptions, breaches, compromises, or failures. - Recovery and reconstitution capabilities can include automated mechanisms and - manual procedures. Organizations establish recovery time and recovery point - objectives as part of contingency planning.
-the recovery of the system to a known state is provided within
a reconstitution of the system to a known state is provided within
Contingency planning policy
-procedures addressing system backup
-contingency plan
-system backup test results
-contingency plan test results
-contingency plan test documentation
-redundant secondary system for system backups
-location(s) of redundant secondary backup system(s)
-system security plan
-other relevant documents or records
-Organizational personnel with contingency planning, recovery, and/or - reconstitution responsibilities
-organizational personnel with information security responsibilities
-Organizational processes implementing system recovery and reconstitution - operations
-mechanisms supporting and/or implementing system recovery and reconstitution - operations
-Implement transaction recovery for systems that are transaction-based.
-Transaction-based systems include database management systems and transaction - processing systems. Mechanisms supporting transaction recovery include - transaction rollback and transaction journaling.
-transaction recovery is implemented for systems that are transaction-based.
- -Contingency planning policy
-procedures addressing system recovery and reconstitution
-contingency plan
-system design documentation
-system configuration settings and associated documentation
-contingency plan test documentation
-contingency plan test results
-system transaction recovery records
-system audit records
-system security plan
-other relevant documents or records
-Organizational personnel with responsibility for transaction recovery
-organizational personnel with information security responsibilities
-Mechanisms supporting and/or implementing transaction recovery capability
-personnel or roles to whom the identification and authentication policy is to - be disseminated are defined;
-personnel or roles to whom the identification and authentication procedures - are to be disseminated is/are defined;
-an official to manage the identification and authentication policy and - procedures is defined;
-the frequency at which the current identification and authentication policy - is reviewed and updated is defined;
-events that would require the current identification and authentication - policy to be reviewed and updated are defined;
-the frequency at which the current identification and authentication - procedures are reviewed and updated is defined;
-events that would require identification and authentication procedures to be - reviewed and updated are defined;
-Develop, document, and disseminate to
Addresses purpose, scope, roles, responsibilities, management - commitment, coordination among organizational entities, and - compliance; and
-Is consistent with applicable laws, executive orders, directives, - regulations, policies, standards, and guidelines; and
-Procedures to facilitate the implementation of the identification and - authentication policy and the associated identification and - authentication controls;
-Designate an
Review and update the current identification and authentication:
-Policy
Procedures
Identification and authentication policy and procedures address the controls in - the IA family that are implemented within systems and organizations. The risk - management strategy is an important factor in establishing such policies and - procedures. Policies and procedures contribute to security and privacy - assurance. Therefore, it is important that security and privacy programs - collaborate on the development of identification and authentication policy and - procedures. Security and privacy program policies and procedures at the - organization level are preferable, in general, and may obviate the need for - mission- or system-specific policies and procedures. The policy can be included - as part of the general security and privacy policy or be represented by multiple - policies that reflect the complex nature of organizations. Procedures can be - established for security and privacy programs, for mission or business - processes, and for systems, if needed. Procedures describe how the policies or - controls are implemented and can be directed at the individual or role that is - the object of the procedure. Procedures can be documented in system security and - privacy plans or in one or more separate documents. Events that may precipitate - an update to identification and authentication policy and procedures include - assessment or audit findings, security incidents or breaches, or changes in - applicable laws, executive orders, directives, regulations, policies, standards, - and guidelines. Simply restating controls does not constitute an organizational - policy or procedure.
-an identification and authentication policy is developed and documented;
- -the identification and authentication policy is disseminated to
identification and authentication procedures to facilitate the - implementation of the identification and authentication policy and - associated identification and authentication controls are developed and - documented;
- -the identification and authentication procedures are disseminated to
the
the
the
the
the
the
the
the
the
the current identification and authentication policy is reviewed and
- updated
the current identification and authentication policy is reviewed and
- updated following
the current identification and authentication procedures are reviewed
- and updated
the current identification and authentication procedures are reviewed
- and updated following
Identification and authentication policy and procedures
-system security plan
-privacy plan
-risk management strategy documentation
-list of events requiring identification and authentication procedures to be - reviewed and updated (e.g., audit findings)
-other relevant documents or records
-Organizational personnel with identification and authentication - responsibilities
-organizational personnel with information security and privacy - responsibilities
-Uniquely identify and authenticate organizational users and associate that unique - identification with processes acting on behalf of those users.
-Organizations can satisfy the identification and authentication requirements by - complying with the requirements in HSPD 12 . Organizational - users include employees or individuals who organizations consider to have an - equivalent status to employees (e.g., contractors and guest researchers). Unique - identification and authentication of users applies to all accesses other than - those that are explicitly identified in AC-14 and that - occur through the authorized use of group authenticators without individual - authentication. Since processes execute on behalf of groups and roles, - organizations may require unique identification of individuals in group accounts - or for detailed accountability of individual activity.
-Organizations employ passwords, physical authenticators, or biometrics to - authenticate user identities or, in the case of multi-factor authentication, - some combination thereof. Access to organizational systems is defined as either - local access or network access. Local access is any access to organizational - systems by users or processes acting on behalf of users, where access is - obtained through direct connections without the use of networks. Network access - is access to organizational systems by users (or processes acting on behalf of - users) where access is obtained through network connections (i.e., nonlocal - accesses). Remote access is a type of network access that involves communication - through external networks. Internal networks include local area networks and - wide area networks.
-The use of encrypted virtual private networks for network connections between - organization-controlled endpoints and non-organization-controlled endpoints may - be treated as internal networks with respect to protecting the confidentiality - and integrity of information traversing the network. Identification and - authentication requirements for non-organizational users are described in IA-8.
-organizational users are uniquely identified and authenticated;
- -the unique identification of authenticated organizational users is associated - with processes acting on behalf of those users.
- -Identification and authentication policy
-procedures addressing user identification and authentication
-system security plan, system design documentation
-system configuration settings and associated documentation
-system audit records
-list of system accounts
-other relevant documents or records
-Organizational personnel with system operations responsibilities
-organizational personnel with information security responsibilities
-system/network administrators
-organizational personnel with account management responsibilities
-system developers
-Organizational processes for uniquely identifying and authenticating users
-mechanisms supporting and/or implementing identification and authentication - capabilities
-Implement multi-factor authentication for access to privileged accounts.
-Multi-factor authentication requires the use of two or more different factors - to achieve authentication. The authentication factors are defined as - follows: something you know (e.g., a personal identification number [PIN]), - something you have (e.g., a physical authenticator such as a cryptographic - private key), or something you are (e.g., a biometric). Multi-factor - authentication solutions that feature physical authenticators include - hardware authenticators that provide time-based or challenge-response - outputs and smart cards such as the U.S. Government Personal Identity - Verification (PIV) card or the Department of Defense (DoD) Common Access - Card (CAC). In addition to authenticating users at the system level (i.e., - at logon), organizations may employ authentication mechanisms at the - application level, at their discretion, to provide increased security. - Regardless of the type of access (i.e., local, network, remote), privileged - accounts are authenticated using multi-factor options appropriate for the - level of risk. Organizations can add additional security measures, such as - additional or more rigorous authentication mechanisms, for specific types of - access.
-multi-factor authentication is implemented for access to privileged accounts.
- -Identification and authentication policy
-procedures addressing user identification and authentication
-system security plan
-system design documentation
-system configuration settings and associated documentation
-system audit records
-list of system accounts
-other relevant documents or records
-Organizational personnel with system operations responsibilities
-organizational personnel with account management responsibilities
-organizational personnel with information security responsibilities
-system/network administrators
-system developers
-Mechanisms supporting and/or implementing a multi-factor authentication - capability
-Implement multi-factor authentication for access to non-privileged accounts.
-Multi-factor authentication requires the use of two or more different factors - to achieve authentication. The authentication factors are defined as - follows: something you know (e.g., a personal identification number [PIN]), - something you have (e.g., a physical authenticator such as a cryptographic - private key), or something you are (e.g., a biometric). Multi-factor - authentication solutions that feature physical authenticators include - hardware authenticators that provide time-based or challenge-response - outputs and smart cards such as the U.S. Government Personal Identity - Verification card or the DoD Common Access Card. In addition to - authenticating users at the system level, organizations may also employ - authentication mechanisms at the application level, at their discretion, to - provide increased information security. Regardless of the type of access - (i.e., local, network, remote), non-privileged accounts are authenticated - using multi-factor options appropriate for the level of risk. Organizations - can provide additional security measures, such as additional or more - rigorous authentication mechanisms, for specific types of access.
-multi-factor authentication for access to non-privileged accounts is - implemented.
- -Identification and authentication policy
-system security plan
-procedures addressing user identification and authentication
-system design documentation
-system configuration settings and associated documentation
-system audit records
-list of system accounts
-other relevant documents or records
-Organizational personnel with system operations responsibilities
-organizational personnel with account management responsibilities
-organizational personnel with information security responsibilities
-system/network administrators
-system developers
-Mechanisms supporting and/or implementing a multi-factor authentication - capability
-Implement replay-resistant authentication mechanisms for access to
Authentication processes resist replay attacks if it is impractical to - achieve successful authentications by replaying previous authentication - messages. Replay-resistant techniques include protocols that use nonces or - challenges such as time synchronous or cryptographic authenticators.
-replay-resistant authentication mechanisms for access to
Identification and authentication policy
-system security plan
-procedures addressing user identification and authentication
-system design documentation
-system configuration settings and associated documentation
-system audit records
-list of privileged system accounts
-other relevant documents or records
-Organizational personnel with system operations responsibilities
-organizational personnel with account management responsibilities
-organizational personnel with information security responsibilities
-system/network administrators
-system developers
-Mechanisms supporting and/or implementing identification and - authentication capabilities
-Mechanisms supporting and/or implementing replay-resistant authentication - mechanisms
-Accept and electronically verify Personal Identity Verification-compliant - credentials.
-Acceptance of Personal Identity Verification (PIV)-compliant credentials - applies to organizations implementing logical access control and physical - access control systems. PIV-compliant credentials are those credentials - issued by federal agencies that conform to FIPS Publication 201 and - supporting guidance documents. The adequacy and reliability of PIV card - issuers are authorized using SP - 800-79-2 . Acceptance of PIV-compliant credentials includes derived PIV - credentials, the use of which is addressed in SP 800-166 . The DOD - Common Access Card (CAC) is an example of a PIV credential.
-Personal Identity Verification-compliant credentials are accepted and - electronically verified.
- -Identification and authentication policy
-system security plan
-procedures addressing user identification and authentication
-system design documentation
-system configuration settings and associated documentation
-system audit records
-PIV verification records
-evidence of PIV credentials
-PIV credential authorizations
-other relevant documents or records
-Organizational personnel with system operations responsibilities
-organizational personnel with account management responsibilities
-organizational personnel with information security responsibilities
-system/network administrators
-system developers
-Mechanisms supporting and/or implementing acceptance and verification of - PIV credentials
-devices and/or types of devices to be uniquely identified and authenticated - before establishing a connection are defined;
-Uniquely identify and authenticate
Devices that require unique device-to-device identification and authentication - are defined by type, device, or a combination of type and device. - Organization-defined device types include devices that are not owned by the - organization. Systems use shared known information (e.g., Media Access Control - [MAC], Transmission Control Protocol/Internet Protocol [TCP/IP] addresses) for - device identification or organizational authentication solutions (e.g., - Institute of Electrical and Electronics Engineers (IEEE) 802.1x and Extensible - Authentication Protocol [EAP], RADIUS server with EAP-Transport Layer Security - [TLS] authentication, Kerberos) to identify and authenticate devices on local - and wide area networks. Organizations determine the required strength of - authentication mechanisms based on the security categories of systems and - mission or business requirements. Because of the challenges of implementing - device authentication on a large scale, organizations can restrict the - application of the control to a limited number/type of devices based on mission - or business needs.
-Identification and authentication policy
-system security plan
-procedures addressing device identification and authentication
-system design documentation
-list of devices requiring unique identification and authentication
-device connection reports
-system configuration settings and associated documentation
-other relevant documents or records
-Organizational personnel with operational responsibilities for device - identification and authentication
-organizational personnel with information security responsibilities
-system/network administrators
-system developers
-Mechanisms supporting and/or implementing device identification and - authentication capabilities
-personnel or roles from whom authorization must be received to assign an - identifier are defined;
-a time period for preventing reuse of identifiers is defined;
-Manage system identifiers by:
-Receiving authorization from
Selecting an identifier that identifies an individual, group, role, service, - or device;
-Assigning the identifier to the intended individual, group, role, service, or - device; and
-Preventing reuse of identifiers for
Common device identifiers include Media Access Control (MAC) addresses, Internet - Protocol (IP) addresses, or device-unique token identifiers. The management of - individual identifiers is not applicable to shared system accounts. Typically, - individual identifiers are the usernames of the system accounts assigned to - those individuals. In such instances, the account management activities of AC-2 use account names provided by IA-4 - . Identifier management also addresses individual identifiers not necessarily - associated with system accounts. Preventing the reuse of identifiers implies - preventing the assignment of previously used individual, group, role, service, - or device identifiers to different individuals, groups, roles, services, or - devices.
-system identifiers are managed by receiving authorization from
system identifiers are managed by selecting an identifier that identifies an - individual, group, role, service, or device;
- -system identifiers are managed by assigning the identifier to the intended - individual, group, role, service, or device;
- -system identifiers are managed by preventing reuse of identifiers for
Identification and authentication policy
-procedures addressing identifier management
-procedures addressing account management
-system security plan
-system design documentation
-system configuration settings and associated documentation
-list of system accounts
-list of identifiers generated from physical access control devices
-other relevant documents or records
-Organizational personnel with identifier management responsibilities
-organizational personnel with information security responsibilities
-system/network administrators
-system developers
-Mechanisms supporting and/or implementing identifier management
-characteristics used to identify individual status is defined;
-Manage individual identifiers by uniquely identifying each individual as
Characteristics that identify the status of individuals include contractors, - foreign nationals, and non-organizational users. Identifying the status of - individuals by these characteristics provides additional information about - the people with whom organizational personnel are communicating. For - example, it might be useful for a government employee to know that one of - the individuals on an email message is a contractor.
-individual identifiers are managed by uniquely identifying each individual as
Identification and authentication policy
-system security plan
-procedures addressing identifier management
-procedures addressing account management
-list of characteristics identifying individual status
-other relevant documents or records
-Organizational personnel with identifier management responsibilities
-organizational personnel with information security responsibilities
-system/network administrators
-Mechanisms supporting and/or implementing identifier management
-a time period for changing or refreshing authenticators by authenticator type - is defined;
-events that trigger the change or refreshment of authenticators are defined;
-Manage system authenticators by:
-Verifying, as part of the initial authenticator distribution, the identity of - the individual, group, role, service, or device receiving the authenticator;
-Establishing initial authenticator content for any authenticators issued by - the organization;
-Ensuring that authenticators have sufficient strength of mechanism for their - intended use;
-Establishing and implementing administrative procedures for initial - authenticator distribution, for lost or compromised or damaged - authenticators, and for revoking authenticators;
-Changing default authenticators prior to first use;
-Changing or refreshing authenticators
Protecting authenticator content from unauthorized disclosure and - modification;
-Requiring individuals to take, and having devices implement, specific - controls to protect authenticators; and
-Changing authenticators for group or role accounts when membership to those - accounts changes.
-Authenticators include passwords, cryptographic devices, biometrics, - certificates, one-time password devices, and ID badges. Device authenticators - include certificates and passwords. Initial authenticator content is the actual - content of the authenticator (e.g., the initial password). In contrast, the - requirements for authenticator content contain specific criteria or - characteristics (e.g., minimum password length). Developers may deliver system - components with factory default authentication credentials (i.e., passwords) to - allow for initial installation and configuration. Default authentication - credentials are often well known, easily discoverable, and present a significant - risk. The requirement to protect individual authenticators may be implemented - via control PL-4 or PS-6 for - authenticators in the possession of individuals and by controls - AC-3, AC-6 , and SC-28 for - authenticators stored in organizational systems, including passwords stored in - hashed or encrypted formats or files containing encrypted or hashed passwords - accessible with administrator privileges.
-Systems support authenticator management by organization-defined settings and - restrictions for various authenticator characteristics (e.g., minimum password - length, validation time window for time synchronous one-time tokens, and number - of allowed rejections during the verification stage of biometric - authentication). Actions can be taken to safeguard individual authenticators, - including maintaining possession of authenticators, not sharing authenticators - with others, and immediately reporting lost, stolen, or compromised - authenticators. Authenticator management includes issuing and revoking - authenticators for temporary access when no longer needed.
-system authenticators are managed through the verification of the identity of - the individual, group, role, service, or device receiving the authenticator - as part of the initial authenticator distribution;
- -system authenticators are managed through the establishment of initial - authenticator content for any authenticators issued by the organization;
- -system authenticators are managed to ensure that authenticators have - sufficient strength of mechanism for their intended use;
- -system authenticators are managed through the establishment and - implementation of administrative procedures for initial authenticator - distribution; lost, compromised, or damaged authenticators; and the - revocation of authenticators;
- -system authenticators are managed through the change of default - authenticators prior to first use;
- -system authenticators are managed through the change or refreshment of
- authenticators
system authenticators are managed through the protection of authenticator - content from unauthorized disclosure and modification;
- -system authenticators are managed through the requirement for individuals - to take specific controls to protect authenticators;
- -system authenticators are managed through the requirement for devices to - implement specific controls to protect authenticators;
- -system authenticators are managed through the change of authenticators for - group or role accounts when membership to those accounts changes.
- -Identification and authentication policy
-system security plan
-addressing authenticator management
-system design documentation
-system configuration settings and associated documentation
-list of system authenticator types
-change control records associated with managing system authenticators
-system audit records
-other relevant documents or records
-Organizational personnel with authenticator management responsibilities
-organizational personnel with information security responsibilities
-system/network administrators
-Mechanisms supporting and/or implementing authenticator management capability
-the frequency at which to update the list of commonly used, expected, or - compromised passwords is defined;
-authenticator composition and complexity rules are defined;
-For password-based authentication:
-Maintain a list of commonly-used, expected, or compromised passwords and
- update the list
Verify, when users create or update passwords, that the passwords are not - found on the list of commonly-used, expected, or compromised passwords - in IA-5(1)(a);
-Transmit passwords only over cryptographically-protected channels;
-Store passwords using an approved salted key derivation function, - preferably using a keyed hash;
-Require immediate selection of a new password upon account recovery;
-Allow user selection of long passwords and passphrases, including spaces - and all printable characters;
-Employ automated tools to assist the user in selecting strong password - authenticators; and
-Enforce the following composition and complexity rules:
Password-based authentication applies to passwords regardless of whether they - are used in single-factor or multi-factor authentication. Long passwords or - passphrases are preferable over shorter passwords. Enforced composition - rules provide marginal security benefits while decreasing usability. - However, organizations may choose to establish certain rules for password - generation (e.g., minimum character length for long passwords) under certain - circumstances and can enforce this requirement in IA-5(1)(h). Account - recovery can occur, for example, in situations when a password is forgotten. - Cryptographically protected passwords include salted one-way cryptographic - hashes of passwords. The list of commonly used, compromised, or expected - passwords includes passwords obtained from previous breach corpuses, - dictionary words, and repetitive or sequential characters. The list includes - context-specific words, such as the name of the service, username, and - derivatives thereof.
-for password-based authentication, a list of commonly used, expected, or
- compromised passwords is maintained and updated
for password-based authentication when passwords are created or updated - by users, the passwords are verified not to be found on the list of - commonly used, expected, or compromised passwords in IA-05(01)(a);
- -for password-based authentication, passwords are only transmitted over - cryptographically protected channels;
- -for password-based authentication, passwords are stored using an approved - salted key derivation function, preferably using a keyed hash;
- -for password-based authentication, immediate selection of a new password - is required upon account recovery;
- -for password-based authentication, user selection of long passwords and - passphrases is allowed, including spaces and all printable characters;
- -for password-based authentication, automated tools are employed to assist - the user in selecting strong password authenticators;
- -for password-based authentication,
Identification and authentication policy
-password policy
-procedures addressing authenticator management
-system security plan
-system design documentation
-system configuration settings and associated documentation
-password configurations and associated documentation
-other relevant documents or records
-Organizational personnel with authenticator management responsibilities
-organizational personnel with information security responsibilities
-system/network administrators
-system developers
-Mechanisms supporting and/or implementing password-based authenticator - management capability
-For public key-based authentication:
-Enforce authorized access to the corresponding private key; and
-Map the authenticated identity to the account of the individual or - group; and
-When public key infrastructure (PKI) is used:
-Validate certificates by constructing and verifying a certification - path to an accepted trust anchor, including checking certificate - status information; and
-Implement a local cache of revocation data to support path discovery - and validation.
-Public key cryptography is a valid authentication mechanism for individuals, - machines, and devices. For PKI solutions, status information for - certification paths includes certificate revocation lists or certificate - status protocol responses. For PIV cards, certificate validation involves - the construction and verification of a certification path to the Common - Policy Root trust anchor, which includes certificate policy processing. - Implementing a local cache of revocation data to support path discovery and - validation also supports system availability in situations where - organizations are unable to access revocation information via the network.
-authorized access to the corresponding private key is enforced for - public key-based authentication;
- -the authenticated identity is mapped to the account of the individual - or group for public key-based authentication;
- -when public key infrastructure (PKI) is used, certificates are - validated by constructing and verifying a certification path to an - accepted trust anchor, including checking certificate status - information;
- -when public key infrastructure (PKI) is used, a local cache of - revocation data is implemented to support path discovery and - validation.
- -Identification and authentication policy
-procedures addressing authenticator management
-system security plan
-system design documentation
-system configuration settings and associated documentation
-PKI certification validation records
-PKI certification revocation lists
-other relevant documents or records
-Organizational personnel with PKI-based, authenticator management - responsibilities
-organizational personnel with information security responsibilities
-system/network administrators
-system developers
-Mechanisms supporting and/or implementing PKI-based, authenticator - management capability
-Protect authenticators commensurate with the security category of the - information to which use of the authenticator permits access.
-For systems that contain multiple security categories of information without - reliable physical or logical separation between categories, authenticators - used to grant access to the systems are protected commensurate with the - highest security category of information on the systems. Security categories - of information are determined as part of the security categorization - process.
-authenticators are protected commensurate with the security category of the - information to which use of the authenticator permits access.
- -Identification and authentication policy
-procedures addressing authenticator management
-security categorization documentation for the system
-security assessments of authenticator protections
-risk assessment results
-system security plan
-other relevant documents or records
-Organizational personnel with authenticator management responsibilities
-organizational personnel implementing and/or maintaining authenticator - protections
-organizational personnel with information security responsibilities
-system/network administrators
-Mechanisms supporting and/or implementing authenticator management - capability
-mechanisms protecting authenticators
-Obscure feedback of authentication information during the authentication process - to protect the information from possible exploitation and use by unauthorized - individuals.
-Authentication feedback from systems does not provide information that would - allow unauthorized individuals to compromise authentication mechanisms. For some - types of systems, such as desktops or notebooks with relatively large monitors, - the threat (referred to as shoulder surfing) may be significant. For other types - of systems, such as mobile devices with small displays, the threat may be less - significant and is balanced against the increased likelihood of typographic - input errors due to small keyboards. Thus, the means for obscuring - authentication feedback is selected accordingly. Obscuring authentication - feedback includes displaying asterisks when users type passwords into input - devices or displaying feedback for a very limited time before obscuring it.
-the feedback of authentication information is obscured during the authentication - process to protect the information from possible exploitation and use by - unauthorized individuals.
- -Identification and authentication policy
-system security plan
-procedures addressing authenticator feedback
-system design documentation
-system configuration settings and associated documentation
-system audit records
-other relevant documents or records
-Organizational personnel with information security responsibilities
-system/network administrators
-system developers
-Mechanisms supporting and/or implementing the obscuring of feedback of - authentication information during authentication
-Implement mechanisms for authentication to a cryptographic module that meet the - requirements of applicable laws, executive orders, directives, policies, - regulations, standards, and guidelines for such authentication.
-Authentication mechanisms may be required within a cryptographic module to - authenticate an operator accessing the module and to verify that the operator is - authorized to assume the requested role and perform services within that role.
-mechanisms for authentication to a cryptographic module are implemented that meet - the requirements of applicable laws, executive orders, directives, policies, - regulations, standards, and guidelines for such authentication.
- -Identification and authentication policy
-system security plan
-procedures addressing cryptographic module authentication
-system design documentation
-system configuration settings and associated documentation
-system audit records
-other relevant documents or records
-Organizational personnel with responsibility for cryptographic module - authentication
-organizational personnel with information security responsibilities
-system/network administrators
-system developers
-Mechanisms supporting and/or implementing cryptographic module authentication
-Uniquely identify and authenticate non-organizational users or processes acting - on behalf of non-organizational users.
-Non-organizational users include system users other than organizational users - explicitly covered by IA-2 . Non-organizational users are - uniquely identified and authenticated for accesses other than those explicitly - identified and documented in AC-14 . Identification and - authentication of non-organizational users accessing federal systems may be - required to protect federal, proprietary, or privacy-related information (with - exceptions noted for national security systems). Organizations consider many - factors—including security, privacy, scalability, and practicality—when - balancing the need to ensure ease of use for access to federal information and - systems with the need to protect and adequately mitigate risk.
-non-organizational users or processes acting on behalf of non-organizational - users are uniquely identified and authenticated.
- -Identification and authentication policy
-system security plan
-privacy plan
-procedures addressing user identification and authentication
-system design documentation
-system configuration settings and associated documentation
-system audit records
-list of system accounts
-other relevant documents or records
-Organizational personnel with system operations responsibilities
-organizational personnel with information security and privacy - responsibilities
-system/network administrators
-organizational personnel with account management responsibilities
-Mechanisms supporting and/or implementing identification and authentication - capabilities
-Accept and electronically verify Personal Identity Verification-compliant - credentials from other federal agencies.
-Acceptance of Personal Identity Verification (PIV) credentials from other - federal agencies applies to both logical and physical access control - systems. PIV credentials are those credentials issued by federal agencies - that conform to FIPS Publication 201 and supporting guidelines. The adequacy - and reliability of PIV card issuers are addressed and authorized using SP 800-79-2.
-Personal Identity Verification-compliant credentials from other federal - agencies are accepted;
- -Personal Identity Verification-compliant credentials from other federal - agencies are electronically verified.
- -Identification and authentication policy
-system security plan
-procedures addressing user identification and authentication
-system design documentation
-system configuration settings and associated documentation
-system audit records
-PIV verification records
-evidence of PIV credentials
-PIV credential authorizations
-other relevant documents or records
-Organizational personnel with system operations responsibilities
-organizational personnel with information security responsibilities
-system/network administrators
-system developers
-organizational personnel with account management responsibilities
-Mechanisms supporting and/or implementing identification and - authentication capabilities
-mechanisms that accept and verify PIV credentials
-Accept only external authenticators that are NIST-compliant; and
-Document and maintain a list of accepted external authenticators.
-Acceptance of only NIST-compliant external authenticators applies to - organizational systems that are accessible to the public (e.g., - public-facing websites). External authenticators are issued by nonfederal - government entities and are compliant with SP 800-63B . Approved - external authenticators meet or exceed the minimum Federal Government-wide - technical, security, privacy, and organizational maturity requirements. - Meeting or exceeding Federal requirements allows Federal Government relying - parties to trust external authenticators in connection with an - authentication transaction at a specified authenticator assurance level.
-only external authenticators that are NIST-compliant are accepted;
- -a list of accepted external authenticators is documented;
- -a list of accepted external authenticators is maintained.
- -Identification and authentication policy
-system security plan
-procedures addressing user identification and authentication
-system design documentation
-system configuration settings and associated documentation
-system audit records
-list of third-party credentialing products, components, or services - procured and implemented by organization
-third-party credential verification records
-evidence of third-party credentials
-third-party credential authorizations
-other relevant documents or records
-Organizational personnel with system operations responsibilities
-organizational personnel with information security responsibilities
-system/network administrators
-system developers
-organizational personnel with account management responsibilities
-Mechanisms supporting and/or implementing identification and - authentication capabilities
-mechanisms that accept external credentials
-identity management profiles are defined;
-Conform to the following profiles for identity management
Organizations define profiles for identity management based on open identity - management standards. To ensure that open identity management standards are - viable, robust, reliable, sustainable, and interoperable as documented, the - Federal Government assesses and scopes the standards and technology - implementations against applicable laws, executive orders, directives, - policies, regulations, standards, and guidelines.
-there is conformance with
Identification and authentication policy
-system security plan
-system design documentation
-system configuration settings and associated documentation
-system audit records
-other relevant documents or records
-Organizational personnel with system operations responsibilities
-organizational personnel with information security responsibilities
-system/network administrators
-system developers
-organizational personnel with account management responsibilities
-Mechanisms supporting and/or implementing identification and - authentication capabilities
-mechanisms supporting and/or implementing conformance with profiles
-circumstances or situations requiring re-authentication are defined;
-Require users to re-authenticate when
In addition to the re-authentication requirements associated with device locks, - organizations may require re-authentication of individuals in certain - situations, including when roles, authenticators or credentials change, when - security categories of systems change, when the execution of privileged - functions occurs, after a fixed time period, or periodically.
-users are required to re-authenticate when
Identification and authentication policy
-procedures addressing user and device re-authentication
-system security plan
-system design documentation
-system configuration settings and associated documentation
-list of circumstances or situations requiring re-authentication
-system audit records
-other relevant documents or records
-Organizational personnel with system operations responsibilities
-organizational personnel with information security responsibilities
-system/network administrators
-system developers
-organizational personnel with identification and authentication - responsibilities
-Mechanisms supporting and/or implementing identification and authentication - capabilities
-Identity proof users that require accounts for logical access to systems - based on appropriate identity assurance level requirements as specified in - applicable standards and guidelines;
-Resolve user identities to a unique individual; and
-Collect, validate, and verify identity evidence.
-Identity proofing is the process of collecting, validating, and verifying a - user’s identity information for the purposes of establishing credentials for - accessing a system. Identity proofing is intended to mitigate threats to the - registration of users and the establishment of their accounts. Standards and - guidelines specifying identity assurance levels for identity proofing include SP 800-63-3 and SP 800-63A . Organizations - may be subject to laws, executive orders, directives, regulations, or policies - that address the collection of identity evidence. Organizational personnel - consult with the senior agency official for privacy and legal counsel regarding - such requirements.
-users who require accounts for logical access to systems based on appropriate - identity assurance level requirements as specified in applicable standards - and guidelines are identity proofed;
- -user identities are resolved to a unique individual;
- -identity evidence is collected;
- -identity evidence is validated;
- -identity evidence is verified.
- -Identification and authentication policy
-procedures addressing identity proofing
-system security plan
-privacy plan
-other relevant documents or records
-Organizational personnel with system operations responsibilities
-organizational personnel with information security and privacy - responsibilities
-legal counsel
-system/network administrators
-system developers
-organizational personnel with identification and authentication - responsibilities
-Mechanisms supporting and/or implementing identification and authentication - capabilities
-Require evidence of individual identification be presented to the - registration authority.
-Identity evidence, such as documentary evidence or a combination of documents - and biometrics, reduces the likelihood of individuals using fraudulent - identification to establish an identity or at least increases the work - factor of potential adversaries. The forms of acceptable evidence are - consistent with the risks to the systems, roles, and privileges associated - with the user’s account.
-evidence of individual identification is presented to the registration - authority.
- -Identification and authentication policy
-procedures addressing identity proofing
-system security plan
-other relevant documents or records
-Organizational personnel with system operations responsibilities
-organizational personnel with information security responsibilities
-system/network administrators
-system developers
-organizational personnel with identification and authentication - responsibilities
-Mechanisms supporting and/or implementing identification and - authentication capabilities
-methods of validation and verification of identity evidence are defined;
-Require that the presented identity evidence be validated and verified
- through
Validation and verification of identity evidence increases the assurance that - accounts and identifiers are being established for the correct user and - authenticators are being bound to that user. Validation refers to the - process of confirming that the evidence is genuine and authentic, and the - data contained in the evidence is correct, current, and related to an - individual. Verification confirms and establishes a linkage between the - claimed identity and the actual existence of the user presenting the - evidence. Acceptable methods for validating and verifying identity evidence - are consistent with the risks to the systems, roles, and privileges - associated with the users account.
-the presented identity evidence is validated and verified through
Identification and authentication policy
-procedures addressing identity proofing
-system security plan
-other relevant documents or records
-Organizational personnel with system operations responsibilities
-organizational personnel with information security responsibilities
-system/network administrators
-system developers
-organizational personnel with identification and authentication - responsibilities
-Mechanisms supporting and/or implementing identification and - authentication capabilities
-Require that a
To make it more difficult for adversaries to pose as legitimate users during - the identity proofing process, organizations can use out-of-band methods to - ensure that the individual associated with an address of record is the same - individual that participated in the registration. Confirmation can take the - form of a temporary enrollment code or a notice of proofing. The delivery - address for these artifacts is obtained from records and not self-asserted - by the user. The address can include a physical or digital address. A home - address is an example of a physical address. Email addresses and telephone - numbers are examples of digital addresses.
-a
Identification and authentication policy
-procedures addressing identity proofing
-system security plan
-other relevant documents or records
-Organizational personnel with system operations responsibilities
-organizational personnel with information security responsibilities
-system/network administrators
-system developers
-organizational personnel with identification and authentication - responsibilities
-Mechanisms supporting and/or implementing identification and - authentication capabilities
-personnel or roles to whom the incident response policy is to be disseminated - is/are defined;
-personnel or roles to whom the incident response procedures are to be - disseminated is/are defined;
-an official to manage the incident response policy and procedures is defined;
-the frequency at which the current incident response policy is reviewed and - updated is defined;
-events that would require the current incident response policy to be reviewed - and updated are defined;
-the frequency at which the current incident response procedures are reviewed - and updated is defined;
-events that would require the incident response procedures to be reviewed and - updated are defined;
-Develop, document, and disseminate to
Addresses purpose, scope, roles, responsibilities, management - commitment, coordination among organizational entities, and - compliance; and
-Is consistent with applicable laws, executive orders, directives, - regulations, policies, standards, and guidelines; and
-Procedures to facilitate the implementation of the incident response - policy and the associated incident response controls;
-Designate an
Review and update the current incident response:
-Policy
Procedures
Incident response policy and procedures address the controls in the IR family - that are implemented within systems and organizations. The risk management - strategy is an important factor in establishing such policies and procedures. - Policies and procedures contribute to security and privacy assurance. Therefore, - it is important that security and privacy programs collaborate on the - development of incident response policy and procedures. Security and privacy - program policies and procedures at the organization level are preferable, in - general, and may obviate the need for mission- or system-specific policies and - procedures. The policy can be included as part of the general security and - privacy policy or be represented by multiple policies that reflect the complex - nature of organizations. Procedures can be established for security and privacy - programs, for mission or business processes, and for systems, if needed. - Procedures describe how the policies or controls are implemented and can be - directed at the individual or role that is the object of the procedure. - Procedures can be documented in system security and privacy plans or in one or - more separate documents. Events that may precipitate an update to incident - response policy and procedures include assessment or audit findings, security - incidents or breaches, or changes in laws, executive orders, directives, - regulations, policies, standards, and guidelines. Simply restating controls does - not constitute an organizational policy or procedure.
-an incident response policy is developed and documented;
- -the incident response policy is disseminated to
incident response procedures to facilitate the implementation of the - incident response policy and associated incident response controls are - developed and documented;
- -the incident response procedures are disseminated to
the
the
the
the
the
the
the
the
the
the current incident response policy is reviewed and updated
the current incident response policy is reviewed and updated
- following
the current incident response procedures are reviewed and updated
the current incident response procedures are reviewed and updated
- following
Incident response policy and procedures
-system security plan
-privacy plan
-other relevant documents or records
-Organizational personnel with incident response responsibilities
-organizational personnel with information security and privacy - responsibilities
-a time period within which incident response training is to be provided to - system users assuming an incident response role or responsibility is - defined;
-frequency at which to provide incident response training to users is defined;
-frequency at which to review and update incident response training content is - defined;
-events that initiate a review of the incident response training content are - defined;
-Provide incident response training to system users consistent with assigned - roles and responsibilities:
-Within
When required by system changes; and
-Review and update incident response training content
Incident response training is associated with the assigned roles and - responsibilities of organizational personnel to ensure that the appropriate - content and level of detail are included in such training. For example, users - may only need to know who to call or how to recognize an incident; system - administrators may require additional training on how to handle incidents; and - incident responders may receive more specific training on forensics, data - collection techniques, reporting, system recovery, and system restoration. - Incident response training includes user training in identifying and reporting - suspicious activities from external and internal sources. Incident response - training for users may be provided as part of AT-2 or AT-3 . Events that may precipitate an update to incident - response training content include, but are not limited to, incident response - plan testing or response to an actual incident (lessons learned), assessment or - audit findings, or changes in applicable laws, executive orders, directives, - regulations, policies, standards, and guidelines.
-incident response training is provided to system users consistent with
- assigned roles and responsibilities within
incident response training is provided to system users consistent with - assigned roles and responsibilities when required by system changes;
- -incident response training is provided to system users consistent with
- assigned roles and responsibilities
incident response training content is reviewed and updated
incident response training content is reviewed and updated following
Incident response policy
-procedures addressing incident response training
-incident response training curriculum
-incident response training materials
-privacy plan
-incident response plan
-incident response training records
-system security plan
-privacy plan
-other relevant documents or records
-Organizational personnel with incident response training and operational - responsibilities
-organizational personnel with information security and privacy - responsibilities
-frequency at which to test the effectiveness of the incident response - capability for the system is defined;
-tests used to test the effectiveness of the incident response capability for - the system are defined;
-Test the effectiveness of the incident response capability for the system
Organizations test incident response capabilities to determine their - effectiveness and identify potential weaknesses or deficiencies. Incident - response testing includes the use of checklists, walk-through or tabletop - exercises, and simulations (parallel or full interrupt). Incident response - testing can include a determination of the effects on organizational operations - and assets and individuals due to incident response. The use of qualitative and - quantitative data aids in determining the effectiveness of incident response - processes.
-the effectiveness of the incident response capability for the system is tested
Incident response policy
-contingency planning policy
-procedures addressing incident response testing
-procedures addressing contingency plan testing
-incident response testing material
-incident response test results
-incident response test plan
-incident response plan
-contingency plan
-system security plan
-privacy plan
-other relevant documents or records
-Organizational personnel with incident response testing responsibilities
-organizational personnel with information security and privacy - responsibilities
-Coordinate incident response testing with organizational elements responsible - for related plans.
-Organizational plans related to incident response testing include business - continuity plans, disaster recovery plans, continuity of operations plans, - contingency plans, crisis communications plans, critical infrastructure - plans, and occupant emergency plans.
-incident response testing is coordinated with organizational elements - responsible for related plans.
- -Incident response policy
-contingency planning policy
-procedures addressing incident response testing
-incident response testing documentation
-incident response plan
-business continuity plans
-contingency plans
-disaster recovery plans
-continuity of operations plans
-crisis communications plans
-critical infrastructure plans
-occupant emergency plans
-system security plan
-privacy plan
-other relevant documents or records
-Organizational personnel with incident response testing responsibilities
-organizational personnel with responsibilities for testing organizational - plans related to incident response testing
-organizational personnel with information security and privacy - responsibilities
-Implement an incident handling capability for incidents that is consistent - with the incident response plan and includes preparation, detection and - analysis, containment, eradication, and recovery;
-Coordinate incident handling activities with contingency planning activities;
-Incorporate lessons learned from ongoing incident handling activities into - incident response procedures, training, and testing, and implement the - resulting changes accordingly; and
-Ensure the rigor, intensity, scope, and results of incident handling - activities are comparable and predictable across the organization.
-Organizations recognize that incident response capabilities are dependent on the - capabilities of organizational systems and the mission and business processes - being supported by those systems. Organizations consider incident response as - part of the definition, design, and development of mission and business - processes and systems. Incident-related information can be obtained from a - variety of sources, including audit monitoring, physical access monitoring, and - network monitoring; user or administrator reports; and reported supply chain - events. An effective incident handling capability includes coordination among - many organizational entities (e.g., mission or business owners, system owners, - authorizing officials, human resources offices, physical security offices, - personnel security offices, legal departments, risk executive [function], - operations personnel, procurement offices). Suspected security incidents include - the receipt of suspicious email communications that can contain malicious code. - Suspected supply chain incidents include the insertion of counterfeit hardware - or malicious code into organizational systems or system components. For federal - agencies, an incident that involves personally identifiable information is - considered a breach. A breach results in unauthorized disclosure, the loss of - control, unauthorized acquisition, compromise, or a similar occurrence where a - person other than an authorized user accesses or potentially accesses personally - identifiable information or an authorized user accesses or potentially accesses - such information for other than authorized purposes.
-an incident handling capability for incidents is implemented that is - consistent with the incident response plan;
- -the incident handling capability for incidents includes preparation;
- -the incident handling capability for incidents includes detection and - analysis;
- -the incident handling capability for incidents includes containment;
- -the incident handling capability for incidents includes eradication;
- -the incident handling capability for incidents includes recovery;
- -incident handling activities are coordinated with contingency planning - activities;
- -lessons learned from ongoing incident handling activities are - incorporated into incident response procedures, training, and testing;
- -the changes resulting from the incorporated lessons learned are - implemented accordingly;
- -the rigor of incident handling activities is comparable and predictable - across the organization;
- -the intensity of incident handling activities is comparable and - predictable across the organization;
- -the scope of incident handling activities is comparable and predictable - across the organization;
- -the results of incident handling activities are comparable and - predictable across the organization.
- -Incident response policy
-contingency planning policy
-procedures addressing incident handling
-incident response plan
-contingency plan
-system security plan
-privacy plan
-other relevant documents or records
-Organizational personnel with incident handling responsibilities
-organizational personnel with contingency planning responsibilities
-organizational personnel with information security and privacy - responsibilities
-Incident handling capability for the organization
-automated mechanisms used to support the incident handling process are - defined;
-Support the incident handling process using
Automated mechanisms that support incident handling processes include online - incident management systems and tools that support the collection of live - response data, full network packet capture, and forensic analysis.
-the incident handling process is supported using
Incident response policy
-procedures addressing incident handling
-automated mechanisms supporting incident handling
-system design documentation
-system configuration settings and associated documentation
-system audit records
-incident response plan
-system security plan
-other relevant documents or records
-Organizational personnel with incident handling responsibilities
-organizational personnel with information security responsibilities
-Automated mechanisms that support and/or implement the incident handling - process
-Track and document incidents.
-Documenting incidents includes maintaining records about each incident, the - status of the incident, and other pertinent information necessary for forensics - as well as evaluating incident details, trends, and handling. Incident - information can be obtained from a variety of sources, including network - monitoring, incident reports, incident response teams, user complaints, supply - chain partners, audit monitoring, physical access monitoring, and user and - administrator reports. IR-4 provides information on the - types of incidents that are appropriate for monitoring.
-incidents are tracked;
- -incidents are documented.
- -Incident response policy
-procedures addressing incident monitoring
-incident response records and documentation
-incident response plan
-system security plan
-privacy plan
-other relevant documents or records
-Organizational personnel with incident monitoring responsibilities
-organizational personnel with information security and privacy - responsibilities
-Incident monitoring capability for the organization
-mechanisms supporting and/or implementing the tracking and documenting of - system security incidents
-time period for personnel to report suspected incidents to the organizational - incident response capability is defined;
-authorities to whom incident information is to be reported are defined;
-Require personnel to report suspected incidents to the organizational
- incident response capability within
Report incident information to
The types of incidents reported, the content and timeliness of the reports, and - the designated reporting authorities reflect applicable laws, executive orders, - directives, regulations, policies, standards, and guidelines. Incident - information can inform risk assessments, control effectiveness assessments, - security requirements for acquisitions, and selection criteria for technology - products.
-personnel is/are required to report suspected incidents to the organizational
- incident response capability within
incident information is reported to
Incident response policy
-procedures addressing incident reporting
-incident reporting records and documentation
-incident response plan
-system security plan
-privacy plan
-other relevant documents or records
-Organizational personnel with incident reporting responsibilities
-organizational personnel with information security and privacy - responsibilities
-personnel who have/should have reported incidents
-personnel (authorities) to whom incident information is to be reported
-system users
-Organizational processes for incident reporting
-mechanisms supporting and/or implementing incident reporting
-automated mechanisms used for reporting incidents are defined;
-Report incidents using
The recipients of incident reports are specified in - IR-6b . Automated reporting mechanisms include email, posting on - websites (with automatic updates), and automated incident response tools and - programs.
-incidents are reported using
Incident response policy
-procedures addressing incident reporting
-automated mechanisms supporting incident reporting
-system design documentation
-system configuration settings and associated documentation
-incident response plan
-system security plan
-other relevant documents or records
-Organizational personnel with incident reporting responsibilities
-organizational personnel with information security responsibilities
-Organizational processes for incident reporting
-automated mechanisms supporting and/or implementing the reporting of - security incidents
-Provide incident information to the provider of the product or service and - other organizations involved in the supply chain or supply chain governance - for systems or system components related to the incident.
-Organizations involved in supply chain activities include product developers, - system integrators, manufacturers, packagers, assemblers, distributors, - vendors, and resellers. Entities that provide supply chain governance - include the Federal Acquisition Security Council (FASC). Supply chain - incidents include compromises or breaches that involve information - technology products, system components, development processes or personnel, - distribution processes, or warehousing facilities. Organizations determine - the appropriate information to share and consider the value gained from - informing external organizations about supply chain incidents, including the - ability to improve processes or to identify the root cause of an incident.
-incident information is provided to the provider of the product or service - and other organizations involved in the supply chain or supply chain - governance for systems or system components related to the incident.
- -Incident response policy
-procedures addressing supply chain coordination and supply chain risk - information sharing with the Federal Acquisition Security Council
-acquisition policy
-acquisition contracts
-service-level agreements
-incident response plan
-supply chain risk management plan
-system security plan
-plans of other organizations involved in supply chain activities
-other relevant documents or records
-Organizational personnel with incident reporting responsibilities
-organizational personnel with information security responsibilities
-organizational personnel with supply chain risk management - responsibilities
-organization personnel with acquisition responsibilities
-Organizational processes for incident reporting
-organizational processes for supply chain risk information sharing
-mechanisms supporting and/or implementing the reporting of incident - information involved in the supply chain
-Provide an incident response support resource, integral to the organizational - incident response capability, that offers advice and assistance to users of the - system for the handling and reporting of incidents.
-Incident response support resources provided by organizations include help desks, - assistance groups, automated ticketing systems to open and track incident - response tickets, and access to forensics services or consumer redress services, - when required.
-an incident response support resource, integral to the organizational - incident response capability, is provided;
- -the incident response support resource offers advice and assistance to users - of the system for the response and reporting of incidents.
- -Incident response policy
-procedures addressing incident response assistance
-incident response plan
-system security plan
-privacy plan
-other relevant documents or records
-Organizational personnel with incident response assistance and support - responsibilities
-organizational personnel with access to incident response support and - assistance capability
-organizational personnel with information security and privacy - responsibilities
-Organizational processes for incident response assistance
-mechanisms supporting and/or implementing incident response assistance
-automated mechanisms used to increase the availability of incident - response information and support are defined;
-Increase the availability of incident response information and support using
Automated mechanisms can provide a push or pull capability for users to - obtain incident response assistance. For example, individuals may have - access to a website to query the assistance capability, or the assistance - capability can proactively send incident response information to users - (general distribution or targeted) as part of increasing understanding of - current response capabilities and support.
-the availability of incident response information and support is increased
- using
Incident response policy
-procedures addressing incident response assistance
-automated mechanisms supporting incident response support and assistance
-system design documentation
-system configuration settings and associated documentation
-incident response plan
-system security plan
-other relevant documents or records
-Organizational personnel with incident response support and assistance - responsibilities
-organizational personnel with access to incident response support and - assistance capability
-organizational personnel with information security responsibilities
-Organizational processes for incident response assistance
-automated mechanisms supporting and/or implementing an increase in the - availability of incident response information and support
-personnel or roles that review and approve the incident response plan is/are - identified;
-the frequency at which to review and approve the incident response plan is - defined;
-entities, personnel, or roles with designated responsibility for incident - response are defined;
-incident response personnel (identified by name and/or by role) to whom - copies of the incident response plan are to be distributed is/are defined;
-organizational elements to which copies of the incident response plan are to - be distributed are defined;
-incident response personnel (identified by name and/or by role) to whom - changes to the incident response plan is/are communicated are defined;
-organizational elements to which changes to the incident response plan are - communicated are defined;
-Develop an incident response plan that:
-Provides the organization with a roadmap for implementing its incident - response capability;
-Describes the structure and organization of the incident response - capability;
-Provides a high-level approach for how the incident response capability - fits into the overall organization;
-Meets the unique requirements of the organization, which relate to - mission, size, structure, and functions;
-Defines reportable incidents;
-Provides metrics for measuring the incident response capability within - the organization;
-Defines the resources and management support needed to effectively - maintain and mature an incident response capability;
-Addresses the sharing of incident information;
-Is reviewed and approved by
Explicitly designates responsibility for incident response to
Distribute copies of the incident response plan to
Update the incident response plan to address system and organizational - changes or problems encountered during plan implementation, execution, or - testing;
-Communicate incident response plan changes to
Protect the incident response plan from unauthorized disclosure and - modification.
-It is important that organizations develop and implement a coordinated approach - to incident response. Organizational mission and business functions determine - the structure of incident response capabilities. As part of the incident - response capabilities, organizations consider the coordination and sharing of - information with external organizations, including external service providers - and other organizations involved in the supply chain. For incidents involving - personally identifiable information (i.e., breaches), include a process to - determine whether notice to oversight organizations or affected individuals is - appropriate and provide that notice accordingly.
-an incident response plan is developed that provides the organization - with a roadmap for implementing its incident response capability;
- -an incident response plan is developed that describes the structure and - organization of the incident response capability;
- -an incident response plan is developed that provides a high-level - approach for how the incident response capability fits into the overall - organization;
- -an incident response plan is developed that meets the unique requirements - of the organization with regard to mission, size, structure, and - functions;
- -an incident response plan is developed that defines reportable incidents;
- -an incident response plan is developed that provides metrics for - measuring the incident response capability within the organization;
- -an incident response plan is developed that defines the resources and - management support needed to effectively maintain and mature an incident - response capability;
- -an incident response plan is developed that addresses the sharing of - incident information;
- -an incident response plan is developed that is reviewed and approved by
an incident response plan is developed that explicitly designates
- responsibility for incident response to
copies of the incident response plan are distributed to
copies of the incident response plan are distributed to
the incident response plan is updated to address system and organizational - changes or problems encountered during plan implementation, execution, or - testing;
- -incident response plan changes are communicated to
incident response plan changes are communicated to
the incident response plan is protected from unauthorized disclosure;
- -the incident response plan is protected from unauthorized modification.
- -Incident response policy
-procedures addressing incident response planning
-incident response plan
-system security plan
-privacy plan
-records of incident response plan reviews and approvals
-other relevant documents or records
-Organizational personnel with incident response planning responsibilities
-organizational personnel with information security and privacy - responsibilities
-Organizational incident response plan and related organizational processes
-personnel or roles to whom the maintenance policy is to be disseminated - is/are defined;
-personnel or roles to whom the maintenance procedures are to be disseminated - is/are defined;
-an official to manage the maintenance policy and procedures is defined;
-the frequency with which the current maintenance policy is reviewed and - updated is defined;
-events that would require the current maintenance policy to be reviewed and - updated are defined;
-the frequency with which the current maintenance procedures are reviewed and - updated is defined;
-events that would require the maintenance procedures to be reviewed and - updated are defined;
-Develop, document, and disseminate to
Addresses purpose, scope, roles, responsibilities, management - commitment, coordination among organizational entities, and - compliance; and
-Is consistent with applicable laws, executive orders, directives, - regulations, policies, standards, and guidelines; and
-Procedures to facilitate the implementation of the maintenance policy and - the associated maintenance controls;
-Designate an
Review and update the current maintenance:
-Policy
Procedures
Maintenance policy and procedures address the controls in the MA family that are - implemented within systems and organizations. The risk management strategy is an - important factor in establishing such policies and procedures. Policies and - procedures contribute to security and privacy assurance. Therefore, it is - important that security and privacy programs collaborate on the development of - maintenance policy and procedures. Security and privacy program policies and - procedures at the organization level are preferable, in general, and may obviate - the need for mission- or system-specific policies and procedures. The policy can - be included as part of the general security and privacy policy or be represented - by multiple policies that reflect the complex nature of organizations. - Procedures can be established for security and privacy programs, for mission or - business processes, and for systems, if needed. Procedures describe how the - policies or controls are implemented and can be directed at the individual or - role that is the object of the procedure. Procedures can be documented in system - security and privacy plans or in one or more separate documents. Events that may - precipitate an update to maintenance policy and procedures assessment or audit - findings, security incidents or breaches, or changes in applicable laws, - executive orders, directives, regulations, policies, standards, and guidelines. - Simply restating controls does not constitute an organizational policy or - procedure.
-a maintenance policy is developed and documented;
- -the maintenance policy is disseminated to
maintenance procedures to facilitate the implementation of the - maintenance policy and associated maintenance controls are developed and - documented;
- -the maintenance procedures are disseminated to
the
the
the
the
the
the
the
the
the
the current maintenance policy is reviewed and updated
the current maintenance policy is reviewed and updated following
the current maintenance procedures are reviewed and updated
the current maintenance procedures are reviewed and updated following
Maintenance policy and procedures
-system security plan
-privacy plan
-organizational risk management strategy
-other relevant documents or records
-Organizational personnel with maintenance responsibilities
-organizational personnel with information security and privacy - responsibilities
-personnel or roles required to explicitly approve the removal of the system - or system components from organizational facilities for off-site maintenance - or repairs is/are defined;
-information to be removed from associated media prior to removal from - organizational facilities for off-site maintenance, repair, or replacement - is defined;
-information to be included in organizational maintenance records is defined;
-Schedule, document, and review records of maintenance, repair, and - replacement on system components in accordance with manufacturer or vendor - specifications and/or organizational requirements;
-Approve and monitor all maintenance activities, whether performed on site or - remotely and whether the system or system components are serviced on site or - removed to another location;
-Require that
Sanitize equipment to remove the following information from associated media
- prior to removal from organizational facilities for off-site maintenance,
- repair, or replacement:
Check all potentially impacted controls to verify that the controls are still - functioning properly following maintenance, repair, or replacement actions; - and
-Include the following information in organizational maintenance records:
Controlling system maintenance addresses the information security aspects of the - system maintenance program and applies to all types of maintenance to system - components conducted by local or nonlocal entities. Maintenance includes - peripherals such as scanners, copiers, and printers. Information necessary for - creating effective maintenance records includes the date and time of - maintenance, a description of the maintenance performed, names of the - individuals or group performing the maintenance, name of the escort, and system - components or equipment that are removed or replaced. Organizations consider - supply chain-related risks associated with replacement components for systems.
-maintenance, repair, and replacement of system components are scheduled - in accordance with manufacturer or vendor specifications and/or - organizational requirements;
- -maintenance, repair, and replacement of system components are documented - in accordance with manufacturer or vendor specifications and/or - organizational requirements;
- -records of maintenance, repair, and replacement of system components are - reviewed in accordance with manufacturer or vendor specifications and/or - organizational requirements;
- -all maintenance activities, whether performed on site or remotely and - whether the system or system components are serviced on site or removed - to another location, are approved;
- -all maintenance activities, whether performed on site or remotely and - whether the system or system components are serviced on site or removed - to another location, are monitored;
- -equipment is sanitized to remove
all potentially impacted controls are checked to verify that the controls are - still functioning properly following maintenance, repair, or replacement - actions;
- -Maintenance policy
-procedures addressing controlled system maintenance
-maintenance records
-manufacturer/vendor maintenance specifications
-equipment sanitization records
-media sanitization records
-system security plan
-other relevant documents or records
-Organizational personnel with system maintenance responsibilities
-organizational personnel with information security responsibilities
-organizational personnel responsible for media sanitization
-system/network administrators
-Organizational processes for scheduling, performing, documenting, reviewing, - approving, and monitoring maintenance and repairs for the system
-organizational processes for sanitizing system components
-mechanisms supporting and/or implementing controlled maintenance
-mechanisms implementing the sanitization of system components
-frequency at which to review previously approved system maintenance tools is - defined;
-Approve, control, and monitor the use of system maintenance tools; and
-Review previously approved system maintenance tools
Approving, controlling, monitoring, and reviewing maintenance tools address
- security-related issues associated with maintenance tools that are not within
- system authorization boundaries and are used specifically for diagnostic and
- repair actions on organizational systems. Organizations have flexibility in
- determining roles for the approval of maintenance tools and how that approval is
- documented. A periodic review of maintenance tools facilitates the withdrawal of
- approval for outdated, unsupported, irrelevant, or no-longer-used tools.
- Maintenance tools can include hardware, software, and firmware items and may be
- pre-installed, brought in with maintenance personnel on media, cloud-based, or
- downloaded from a website. Such tools can be vehicles for transporting malicious
- code, either intentionally or unintentionally, into a facility and subsequently
- into systems. Maintenance tools can include hardware and software diagnostic
- test equipment and packet sniffers. The hardware and software components that
- support maintenance and are a part of the system (including the software
- implementing utilities such as ping,
ls,
ipconfig,
or the
- hardware and software implementing the monitoring port of an Ethernet switch)
- are not addressed by maintenance tools.
the use of system maintenance tools is approved;
- -the use of system maintenance tools is controlled;
- -the use of system maintenance tools is monitored;
- -previously approved system maintenance tools are reviewed
Maintenance policy
-procedures addressing system maintenance tools
-system maintenance tools and associated documentation
-maintenance records
-system security plan
-other relevant documents or records
-Organizational personnel with system maintenance responsibilities
-organizational personnel with information security responsibilities
-Organizational processes for approving, controlling, and monitoring - maintenance tools
-mechanisms supporting and/or implementing the approval, control, and/or - monitoring of maintenance tools
-Inspect the maintenance tools used by maintenance personnel for improper or - unauthorized modifications.
-Maintenance tools can be directly brought into a facility by maintenance - personnel or downloaded from a vendor’s website. If, upon inspection of the - maintenance tools, organizations determine that the tools have been modified - in an improper manner or the tools contain malicious code, the incident is - handled consistent with organizational policies and procedures for incident - handling.
-maintenance tools used by maintenance personnel are inspected for improper or - unauthorized modifications.
- -Maintenance policy
-procedures addressing system maintenance tools
-system maintenance tools and associated documentation
-maintenance tool inspection records
-maintenance records
-system security plan
-other relevant documents or records
-Organizational personnel with system maintenance responsibilities
-organizational personnel with information security responsibilities
-Organizational processes for inspecting maintenance tools
-mechanisms supporting and/or implementing the inspection of maintenance - tools
-Check media containing diagnostic and test programs for malicious code before - the media are used in the system.
-If, upon inspection of media containing maintenance, diagnostic, and test - programs, organizations determine that the media contains malicious code, - the incident is handled consistent with organizational incident handling - policies and procedures.
-media containing diagnostic and test programs are checked for malicious code - before the media are used in the system.
- -Maintenance policy
-procedures addressing system maintenance tools
-system maintenance tools and associated documentation
-maintenance records
-system security plan
-other relevant documents or records
-Organizational personnel with system maintenance responsibilities
-organizational personnel with information security responsibilities
-Organizational process for inspecting media for malicious code
-mechanisms supporting and/or implementing the inspection of media used - for maintenance
-personnel or roles who can authorize removal of equipment from the - facility is/are defined;
-Prevent the removal of maintenance equipment containing organizational - information by:
-Verifying that there is no organizational information contained on the - equipment;
-Sanitizing or destroying the equipment;
-Retaining the equipment within the facility; or
-Obtaining an exemption from
Organizational information includes all information owned by organizations - and any information provided to organizations for which the organizations - serve as information stewards.
-the removal of maintenance equipment containing organizational - information is prevented by verifying that there is no organizational - information contained on the equipment; or
- -the removal of maintenance equipment containing organizational - information is prevented by sanitizing or destroying the equipment; or
- -the removal of maintenance equipment containing organizational - information is prevented by retaining the equipment within the facility; - or
- -the removal of maintenance equipment containing organizational
- information is prevented by obtaining an exemption from
Maintenance policy
-procedures addressing system maintenance tools
-system maintenance tools and associated documentation
-maintenance records
-equipment sanitization records
-media sanitization records
-exemptions for equipment removal
-system security plan
-other relevant documents or records
-Organizational personnel with system maintenance responsibilities
-organizational personnel with information security responsibilities
-organizational personnel responsible for media sanitization
-Organizational process for preventing unauthorized removal of information
-mechanisms supporting media sanitization or destruction of equipment
-mechanisms supporting verification of media sanitization
-Approve and monitor nonlocal maintenance and diagnostic activities;
-Allow the use of nonlocal maintenance and diagnostic tools only as consistent - with organizational policy and documented in the security plan for the - system;
-Employ strong authentication in the establishment of nonlocal maintenance and - diagnostic sessions;
-Maintain records for nonlocal maintenance and diagnostic activities; and
-Terminate session and network connections when nonlocal maintenance is - completed.
-Nonlocal maintenance and diagnostic activities are conducted by individuals who - communicate through either an external or internal network. Local maintenance - and diagnostic activities are carried out by individuals who are physically - present at the system location and not communicating across a network - connection. Authentication techniques used to establish nonlocal maintenance and - diagnostic sessions reflect the network access requirements in - IA-2 . Strong authentication requires authenticators that are resistant to - replay attacks and employ multi-factor authentication. Strong authenticators - include PKI where certificates are stored on a token protected by a password, - passphrase, or biometric. Enforcing requirements in MA-4 is - accomplished, in part, by other controls. SP 800-63B provides - additional guidance on strong authentication and authenticators.
-nonlocal maintenance and diagnostic activities are approved;
- -nonlocal maintenance and diagnostic activities are monitored;
- -the use of nonlocal maintenance and diagnostic tools are allowed only as - consistent with organizational policy;
- -the use of nonlocal maintenance and diagnostic tools are documented in - the security plan for the system;
- -strong authentication is employed in the establishment of nonlocal - maintenance and diagnostic sessions;
- -records for nonlocal maintenance and diagnostic activities are maintained;
- -session connections are terminated when nonlocal maintenance is - completed;
- -network connections are terminated when nonlocal maintenance is - completed.
- -Maintenance policy
-procedures addressing nonlocal system maintenance
-remote access policy
-remote access procedures
-system design documentation
-system configuration settings and associated documentation
-maintenance records
-records of remote access
-diagnostic records
-system security plan
-other relevant documents or records
-Organizational personnel with system maintenance responsibilities
-organizational personnel with information security responsibilities
-system/network administrators
-Organizational processes for managing nonlocal maintenance
-mechanisms implementing, supporting, and/or managing nonlocal maintenance
-mechanisms for strong authentication of nonlocal maintenance diagnostic - sessions
-mechanisms for terminating nonlocal maintenance sessions and network - connections
-Establish a process for maintenance personnel authorization and maintain a - list of authorized maintenance organizations or personnel;
-Verify that non-escorted personnel performing maintenance on the system - possess the required access authorizations; and
-Designate organizational personnel with required access authorizations and - technical competence to supervise the maintenance activities of personnel - who do not possess the required access authorizations.
-Maintenance personnel refers to individuals who perform hardware or software - maintenance on organizational systems, while PE-2 addresses - physical access for individuals whose maintenance duties place them within the - physical protection perimeter of the systems. Technical competence of - supervising individuals relates to the maintenance performed on the systems, - while having required access authorizations refers to maintenance on and near - the systems. Individuals not previously identified as authorized maintenance - personnel—such as information technology manufacturers, vendors, systems - integrators, and consultants—may require privileged access to organizational - systems, such as when they are required to conduct maintenance activities with - little or no notice. Based on organizational assessments of risk, organizations - may issue temporary credentials to these individuals. Temporary credentials may - be for one-time use or for very limited time periods.
-a process for maintenance personnel authorization is established;
- -a list of authorized maintenance organizations or personnel is - maintained;
- -non-escorted personnel performing maintenance on the system possess the - required access authorizations;
- -organizational personnel with required access authorizations and technical - competence is/are designated to supervise the maintenance activities of - personnel who do not possess the required access authorizations.
- -Maintenance policy
-procedures addressing maintenance personnel
-service provider contracts
-service-level agreements
-list of authorized personnel
-maintenance records
-access control records
-system security plan
-other relevant documents or records
-Organizational personnel with system maintenance responsibilities
-organizational personnel with information security responsibilities
-Organizational processes for authorizing and managing maintenance personnel
-mechanisms supporting and/or implementing authorization of maintenance - personnel
-system components for which maintenance support and/or spare parts are - obtained are defined;
-time period within which maintenance support and/or spare parts are to be - obtained after a failure are defined;
-Obtain maintenance support and/or spare parts for
Organizations specify the system components that result in increased risk to - organizational operations and assets, individuals, other organizations, or the - Nation when the functionality provided by those components is not operational. - Organizational actions to obtain maintenance support include having appropriate - contracts in place.
-maintenance support and/or spare parts are obtained for
Maintenance policy
-procedures addressing system maintenance
-service provider contracts
-service-level agreements
-inventory and availability of spare parts
-system security plan
-other relevant documents or records
-Organizational personnel with system maintenance responsibilities
-organizational personnel with acquisition responsibilities
-organizational personnel with information security responsibilities
-system/network administrators
-Organizational processes for ensuring timely maintenance
-personnel or roles to whom the media protection policy is to be disseminated - is/are defined;
-personnel or roles to whom the media protection procedures are to be - disseminated is/are defined;
-an official to manage the media protection policy and procedures is defined;
-the frequency with which the current media protection policy is reviewed and - updated is defined;
-events that would require the current media protection policy to be reviewed - and updated are defined;
-the frequency with which the current media protection procedures are reviewed - and updated is defined;
-events that would require media protection procedures to be reviewed and - updated are defined;
-Develop, document, and disseminate to
Addresses purpose, scope, roles, responsibilities, management - commitment, coordination among organizational entities, and - compliance; and
-Is consistent with applicable laws, executive orders, directives, - regulations, policies, standards, and guidelines; and
-Procedures to facilitate the implementation of the media protection - policy and the associated media protection controls;
-Designate an
Review and update the current media protection:
-Policy
Procedures
Media protection policy and procedures address the controls in the MP family that - are implemented within systems and organizations. The risk management strategy - is an important factor in establishing such policies and procedures. Policies - and procedures contribute to security and privacy assurance. Therefore, it is - important that security and privacy programs collaborate on the development of - media protection policy and procedures. Security and privacy program policies - and procedures at the organization level are preferable, in general, and may - obviate the need for mission- or system-specific policies and procedures. The - policy can be included as part of the general security and privacy policy or be - represented by multiple policies that reflect the complex nature of - organizations. Procedures can be established for security and privacy programs, - for mission or business processes, and for systems, if needed. Procedures - describe how the policies or controls are implemented and can be directed at the - individual or role that is the object of the procedure. Procedures can be - documented in system security and privacy plans or in one or more separate - documents. Events that may precipitate an update to media protection policy and - procedures include assessment or audit findings, security incidents or breaches, - or changes in applicable laws, executive orders, directives, regulations, - policies, standards, and guidelines. Simply restating controls does not - constitute an organizational policy or procedure.
-a media protection policy is developed and documented;
- -the media protection policy is disseminated to
media protection procedures to facilitate the implementation of the media - protection policy and associated media protection controls are developed - and documented;
- -the media protection procedures are disseminated to
the
the
the
the
the
the
the
the media protection policy is consistent with applicable laws, - Executive Orders, directives, regulations, policies, standards, and - guidelines;
- -the
the current media protection policy is reviewed and updated
the current media protection policy is reviewed and updated following
the current media protection procedures are reviewed and updated
the current media protection procedures are reviewed and updated
- following
Media protection policy and procedures
-organizational risk management strategy
-system security plan
-privacy plan
-other relevant documents or records
-Organizational personnel with media protection responsibilities
-organizational personnel with information security and privacy - responsibilities
-types of digital media to which access is restricted are defined;
-personnel or roles authorized to access digital media is/are defined;
-types of non-digital media to which access is restricted are defined;
-personnel or roles authorized to access non-digital media is/are defined;
-Restrict access to
System media includes digital and non-digital media. Digital media includes flash - drives, diskettes, magnetic tapes, external or removable hard disk drives (e.g., - solid state, magnetic), compact discs, and digital versatile discs. Non-digital - media includes paper and microfilm. Denying access to patient medical records in - a community hospital unless the individuals seeking access to such records are - authorized healthcare providers is an example of restricting access to - non-digital media. Limiting access to the design specifications stored on - compact discs in the media library to individuals on the system development team - is an example of restricting access to digital media.
-access to
access to
System media protection policy
-procedures addressing media access restrictions
-access control policy and procedures
-physical and environmental protection policy and procedures
-media storage facilities
-access control records
-system security plan
-other relevant documents or records
-Organizational personnel with system media protection responsibilities
-organizational personnel with information security responsibilities
-system/network administrators
-Organizational processes for restricting information media
-mechanisms supporting and/or implementing media access restrictions
-types of system media exempt from marking when remaining in controlled areas - are defined;
-controlled areas where media is exempt from marking are defined;
-Mark system media indicating the distribution limitations, handling caveats, - and applicable security markings (if any) of the information; and
-Exempt
Security marking refers to the application or use of human-readable security - attributes. Digital media includes diskettes, magnetic tapes, external or - removable hard disk drives (e.g., solid state, magnetic), flash drives, compact - discs, and digital versatile discs. Non-digital media includes paper and - microfilm. Controlled unclassified information is defined by the National - Archives and Records Administration along with the appropriate safeguarding and - dissemination requirements for such information and is codified in 32 CFR 2002 . Security - markings are generally not required for media that contains information - determined by organizations to be in the public domain or to be publicly - releasable. Some organizations may require markings for public information - indicating that the information is publicly releasable. System media marking - reflects applicable laws, executive orders, directives, policies, regulations, - standards, and guidelines.
-system media is marked to indicate distribution limitations, handling - caveats, and applicable security markings (if any) of the information;
- -System media protection policy
-procedures addressing media marking
-physical and environmental protection policy and procedures
-list of system media marking security attributes
-designated controlled areas
-system security plan
-other relevant documents or records
-Organizational personnel with system media protection and marking - responsibilities
-organizational personnel with information security responsibilities
-Organizational processes for marking information media
-mechanisms supporting and/or implementing media marking
-types of digital media to be physically controlled are defined (if selected);
-types of non-digital media to be physically controlled are defined (if - selected);
-types of digital media to be securely stored are defined (if selected);
-types of non-digital media to be securely stored are defined (if selected);
-controlled areas within which to securely store digital media are defined;
-controlled areas within which to securely store non-digital media are - defined;
-Physically control and securely store
Protect system media types defined in MP-4a until the media are destroyed or - sanitized using approved equipment, techniques, and procedures.
-System media includes digital and non-digital media. Digital media includes flash - drives, diskettes, magnetic tapes, external or removable hard disk drives (e.g., - solid state, magnetic), compact discs, and digital versatile discs. Non-digital - media includes paper and microfilm. Physically controlling stored media includes - conducting inventories, ensuring procedures are in place to allow individuals to - check out and return media to the library, and maintaining accountability for - stored media. Secure storage includes a locked drawer, desk, or cabinet or a - controlled media library. The type of media storage is commensurate with the - security category or classification of the information on the media. Controlled - areas are spaces that provide physical and procedural controls to meet the - requirements established for protecting information and systems. Fewer controls - may be needed for media that contains information determined to be in the public - domain, publicly releasable, or have limited adverse impacts on organizations, - operations, or individuals if accessed by other than authorized personnel. In - these situations, physical access controls provide adequate protection.
-system media types (defined in MP-04_ODP[01], MP-04_ODP[02], MP-04_ODP[03], - MP-04_ODP[04]) are protected until the media are destroyed or sanitized - using approved equipment, techniques, and procedures.
- -System media protection policy
-procedures addressing media storage
-physical and environmental protection policy and procedures
-access control policy and procedures
-system media
-designated controlled areas
-system security plan
-other relevant documents or records
-Organizational personnel with system media protection and storage - responsibilities
-organizational personnel with information security responsibilities
-Organizational processes for storing information media
-mechanisms supporting and/or implementing secure media storage/media - protection
-types of system media to protect and control during transport outside of - controlled areas are defined;
-controls used to protect system media outside of controlled areas are - defined;
-controls used to control system media outside of controlled areas are - defined;
-Protect and control
Maintain accountability for system media during transport outside of - controlled areas;
-Document activities associated with the transport of system media; and
-Restrict the activities associated with the transport of system media to - authorized personnel.
-System media includes digital and non-digital media. Digital media includes flash - drives, diskettes, magnetic tapes, external or removable hard disk drives (e.g., - solid state and magnetic), compact discs, and digital versatile discs. - Non-digital media includes microfilm and paper. Controlled areas are spaces for - which organizations provide physical or procedural controls to meet requirements - established for protecting information and systems. Controls to protect media - during transport include cryptography and locked containers. Cryptographic - mechanisms can provide confidentiality and integrity protections depending on - the mechanisms implemented. Activities associated with media transport include - releasing media for transport, ensuring that media enters the appropriate - transport processes, and the actual transport. Authorized transport and courier - personnel may include individuals external to the organization. Maintaining - accountability of media during transport includes restricting transport - activities to authorized personnel and tracking and/or obtaining records of - transport activities as the media moves through the transportation system to - prevent and detect loss, destruction, or tampering. Organizations establish - documentation requirements for activities associated with the transport of - system media in accordance with organizational assessments of risk. - Organizations maintain the flexibility to define record-keeping methods for the - different types of media transport as part of a system of transport-related - records.
-accountability for system media is maintained during transport outside of - controlled areas;
- -activities associated with the transport of system media are documented;
- -personnel authorized to conduct media transport activities is/are - identified;
- -activities associated with the transport of system media are restricted - to identified authorized personnel.
- -System media protection policy
-procedures addressing media storage
-physical and environmental protection policy and procedures
-access control policy and procedures
-authorized personnel list
-system media
-designated controlled areas
-system security plan
-other relevant documents or records
-Organizational personnel with system media protection and storage - responsibilities
-organizational personnel with information security responsibilities
-system/network administrators
-Organizational processes for storing information media
-mechanisms supporting and/or implementing media storage/media protection
-system media to be sanitized prior to disposal is defined;
-system media to be sanitized prior to release from organizational control is - defined;
-system media to be sanitized prior to release for reuse is defined;
-sanitization techniques and procedures to be used for sanitization prior to - disposal are defined;
-sanitization techniques and procedures to be used for sanitization prior to - release from organizational control are defined;
-sanitization techniques and procedures to be used for sanitization prior to - release for reuse are defined;
-Sanitize
Employ sanitization mechanisms with the strength and integrity commensurate - with the security category or classification of the information.
-Media sanitization applies to all digital and non-digital system media subject to - disposal or reuse, whether or not the media is considered removable. Examples - include digital media in scanners, copiers, printers, notebook computers, - workstations, network components, mobile devices, and non-digital media (e.g., - paper and microfilm). The sanitization process removes information from system - media such that the information cannot be retrieved or reconstructed. - Sanitization techniques—including clearing, purging, cryptographic erase, - de-identification of personally identifiable information, and - destruction—prevent the disclosure of information to unauthorized individuals - when such media is reused or released for disposal. Organizations determine the - appropriate sanitization methods, recognizing that destruction is sometimes - necessary when other methods cannot be applied to media requiring sanitization. - Organizations use discretion on the employment of approved sanitization - techniques and procedures for media that contains information deemed to be in - the public domain or publicly releasable or information deemed to have no - adverse impact on organizations or individuals if released for reuse or - disposal. Sanitization of non-digital media includes destruction, removing a - classified appendix from an otherwise unclassified document, or redacting - selected sections or words from a document by obscuring the redacted sections or - words in a manner equivalent in effectiveness to removing them from the - document. NSA standards and policies control the sanitization process for media - that contains classified information. NARA policies control the sanitization - process for controlled unclassified information.
-sanitization mechanisms with strength and integrity commensurate with the - security category or classification of the information are employed.
- -System media protection policy
-procedures addressing media sanitization and disposal
-applicable federal standards and policies addressing media sanitization - policy
-media sanitization records
-system audit records
-system design documentation
-records retention and disposition policy
-records retention and disposition procedures
-system configuration settings and associated documentation
-system security plan
-privacy plan
-other relevant documents or records
-Organizational personnel with media sanitization responsibilities
-organizational personnel with records retention and disposition - responsibilities
-organizational personnel with information security and privacy - responsibilities
-system/network administrators
-Organizational processes for media sanitization
-mechanisms supporting and/or implementing media sanitization
-types of system media to be restricted or prohibited from use on systems or - system components are defined;
-systems or system components on which the use of specific types of system - media to be restricted or prohibited are defined;
-controls to restrict or prohibit the use of specific types of system media on - systems or system components are defined;
-Prohibit the use of portable storage devices in organizational systems when - such devices have no identifiable owner.
-System media includes both digital and non-digital media. Digital media includes - diskettes, magnetic tapes, flash drives, compact discs, digital versatile discs, - and removable hard disk drives. Non-digital media includes paper and microfilm. - Media use protections also apply to mobile devices with information storage - capabilities. In contrast to MP-2 , which restricts user - access to media, MP-7 restricts the use of certain types of media on systems, - for example, restricting or prohibiting the use of flash drives or external hard - disk drives. Organizations use technical and nontechnical controls to restrict - the use of system media. Organizations may restrict the use of portable storage - devices, for example, by using physical cages on workstations to prohibit access - to certain external ports or disabling or removing the ability to insert, read, - or write to such devices. Organizations may also limit the use of portable - storage devices to only approved devices, including devices provided by the - organization, devices provided by other approved organizations, and devices that - are not personally owned. Finally, organizations may restrict the use of - portable storage devices based on the type of device, such as by prohibiting the - use of writeable, portable storage devices and implementing this restriction by - disabling or removing the capability to write to such devices. Requiring - identifiable owners for storage devices reduces the risk of using such devices - by allowing organizations to assign responsibility for addressing known - vulnerabilities in the devices.
-the use of
the use of portable storage devices in organizational systems is prohibited - when such devices have no identifiable owner.
- -System media protection policy
-system use policy
-procedures addressing media usage restrictions
-rules of behavior
-system design documentation
-system configuration settings and associated documentation
-audit records
-system security plan
-other relevant documents or records
-Organizational personnel with system media use responsibilities
-organizational personnel with information security responsibilities
-system/network administrators
-Organizational processes for media use
-mechanisms restricting or prohibiting the use of system media on systems or - system components
-personnel or roles to whom the physical and environmental protection policy - is to be disseminated is/are defined;
-personnel or roles to whom the physical and environmental protection - procedures are to be disseminated is/are defined;
-an official to manage the physical and environmental protection policy and - procedures is defined;
-the frequency at which the current physical and environmental protection - policy is reviewed and updated is defined;
-events that would require the current physical and environmental protection - policy to be reviewed and updated are defined;
-the frequency at which the current physical and environmental protection - procedures are reviewed and updated is defined;
-events that would require the physical and environmental protection - procedures to be reviewed and updated are defined;
-Develop, document, and disseminate to
Addresses purpose, scope, roles, responsibilities, management - commitment, coordination among organizational entities, and - compliance; and
-Is consistent with applicable laws, executive orders, directives, - regulations, policies, standards, and guidelines; and
-Procedures to facilitate the implementation of the physical and - environmental protection policy and the associated physical and - environmental protection controls;
-Designate an
Review and update the current physical and environmental protection:
-Policy
Procedures
Physical and environmental protection policy and procedures address the controls - in the PE family that are implemented within systems and organizations. The risk - management strategy is an important factor in establishing such policies and - procedures. Policies and procedures contribute to security and privacy - assurance. Therefore, it is important that security and privacy programs - collaborate on the development of physical and environmental protection policy - and procedures. Security and privacy program policies and procedures at the - organization level are preferable, in general, and may obviate the need for - mission- or system-specific policies and procedures. The policy can be included - as part of the general security and privacy policy or be represented by multiple - policies that reflect the complex nature of organizations. Procedures can be - established for security and privacy programs, for mission or business - processes, and for systems, if needed. Procedures describe how the policies or - controls are implemented and can be directed at the individual or role that is - the object of the procedure. Procedures can be documented in system security and - privacy plans or in one or more separate documents. Events that may precipitate - an update to physical and environmental protection policy and procedures include - assessment or audit findings, security incidents or breaches, or changes in - applicable laws, executive orders, directives, regulations, policies, standards, - and guidelines. Simply restating controls does not constitute an organizational - policy or procedure.
-a physical and environmental protection policy is developed and - documented;
- -the physical and environmental protection policy is disseminated to
physical and environmental protection procedures to facilitate the - implementation of the physical and environmental protection policy and - associated physical and environmental protection controls are developed - and documented;
- -the physical and environmental protection procedures are disseminated to
the
the
the
the
the
the
the
the
the
the current physical and environmental protection policy is reviewed
- and updated
the current physical and environmental protection policy is reviewed
- and updated following
the current physical and environmental protection procedures are
- reviewed and updated
the current physical and environmental protection procedures are
- reviewed and updated following
Physical and environmental protection policy and procedures
-system security plan
-privacy plan
-organizational risk management strategy
-other relevant documents or records
-Organizational personnel with physical and environmental protection - responsibilities
-organizational personnel with information security and privacy - responsibilities
-frequency at which to review the access list detailing authorized facility - access by individuals is defined;
-Develop, approve, and maintain a list of individuals with authorized access - to the facility where the system resides;
-Issue authorization credentials for facility access;
-Review the access list detailing authorized facility access by individuals
Remove individuals from the facility access list when access is no longer - required.
-Physical access authorizations apply to employees and visitors. Individuals with - permanent physical access authorization credentials are not considered visitors. - Authorization credentials include ID badges, identification cards, and smart - cards. Organizations determine the strength of authorization credentials needed - consistent with applicable laws, executive orders, directives, regulations, - policies, standards, and guidelines. Physical access authorizations may not be - necessary to access certain areas within facilities that are designated as - publicly accessible.
-a list of individuals with authorized access to the facility where the - system resides has been developed;
- -the list of individuals with authorized access to the facility where the - system resides has been approved;
- -the list of individuals with authorized access to the facility where the - system resides has been maintained;
- -authorization credentials are issued for facility access;
- -the access list detailing authorized facility access by individuals is
- reviewed
individuals are removed from the facility access list when access is no - longer required.
- -Physical and environmental protection policy
-procedures addressing physical access authorizations
-authorized personnel access list
-authorization credentials
-physical access list reviews
-physical access termination records and associated documentation
-system security plan
-other relevant documents or records
-Organizational personnel with physical access authorization responsibilities
-organizational personnel with physical access to system facility
-organizational personnel with information security responsibilities
-Organizational processes for physical access authorizations
-mechanisms supporting and/or implementing physical access authorizations
-entry and exit points to the facility in which the system resides are - defined;
-physical access control systems or devices used to control ingress and egress - to the facility are defined (if selected);
-entry or exit points for which physical access logs are maintained are - defined;
-physical access controls to control access to areas within the facility - designated as publicly accessible are defined;
-circumstances requiring visitor escorts and control of visitor activity are - defined;
-physical access devices to be inventoried are defined;
-frequency at which to inventory physical access devices is defined;
-frequency at which to change combinations is defined;
-frequency at which to change keys is defined;
-Enforce physical access authorizations at
Verifying individual access authorizations before granting access to the - facility; and
-Controlling ingress and egress to the facility using
Maintain physical access audit logs for
Control access to areas within the facility designated as publicly accessible
- by implementing the following controls:
Escort visitors and control visitor activity
Secure keys, combinations, and other physical access devices;
-Inventory
Change combinations and keys
Physical access control applies to employees and visitors. Individuals with - permanent physical access authorizations are not considered visitors. Physical - access controls for publicly accessible areas may include physical access - control logs/records, guards, or physical access devices and barriers to prevent - movement from publicly accessible areas to non-public areas. Organizations - determine the types of guards needed, including professional security staff, - system users, or administrative staff. Physical access devices include keys, - locks, combinations, biometric readers, and card readers. Physical access - control systems comply with applicable laws, executive orders, directives, - policies, regulations, standards, and guidelines. Organizations have flexibility - in the types of audit logs employed. Audit logs can be procedural, automated, or - some combination thereof. Physical access points can include facility access - points, interior access points to systems that require supplemental access - controls, or both. Components of systems may be in areas designated as publicly - accessible with organizations controlling access to the components.
-physical access authorizations are enforced at
physical access authorizations are enforced at
physical access audit logs are maintained for
access to areas within the facility designated as publicly accessible are
- maintained by implementing
visitors are escorted;
- -visitor activity is controlled
keys are secured;
- -combinations are secured;
- -other physical access devices are secured;
- -combinations are changed
keys are changed
Physical and environmental protection policy
-procedures addressing physical access control
-physical access control logs or records
-inventory records of physical access control devices
-system entry and exit points
-records of key and lock combination changes
-storage locations for physical access control devices
-physical access control devices
-list of security safeguards controlling access to designated publicly - accessible areas within facility
-system security plan
-other relevant documents or records
-Organizational personnel with physical access control responsibilities
-organizational personnel with information security responsibilities
-Organizational processes for physical access control
-mechanisms supporting and/or implementing physical access control
-physical access control devices
-system distribution and transmission lines requiring physical access controls - are defined;
-security controls to be implemented to control physical access to system - distribution and transmission lines within the organizational facility are - defined;
-Control physical access to
Security controls applied to system distribution and transmission lines prevent - accidental damage, disruption, and physical tampering. Such controls may also be - necessary to prevent eavesdropping or modification of unencrypted transmissions. - Security controls used to control physical access to system distribution and - transmission lines include disconnected or locked spare jacks, locked wiring - closets, protection of cabling by conduit or cable trays, and wiretapping - sensors.
-physical access to
Physical and environmental protection policy
-procedures addressing access control for transmission mediums
-system design documentation
-facility communications and wiring diagrams
-list of physical security safeguards applied to system distribution and - transmission lines
-system security plan
-other relevant documents or records
-Organizational personnel with physical access control responsibilities
-organizational personnel with information security responsibilities
-Organizational processes for access control to distribution and transmission - lines
-mechanisms/security safeguards supporting and/or implementing access control - to distribution and transmission lines
-output devices that require physical access control to output are defined;
-Control physical access to output from
Controlling physical access to output devices includes placing output devices in - locked rooms or other secured areas with keypad or card reader access controls - and allowing access to authorized individuals only, placing output devices in - locations that can be monitored by personnel, installing monitor or screen - filters, and using headphones. Examples of output devices include monitors, - printers, scanners, audio devices, facsimile machines, and copiers.
-physical access to output from
Physical and environmental protection policy
-procedures addressing access control for display medium
-facility layout of system components
-actual displays from system components
-list of output devices and associated outputs requiring physical access - controls
-physical access control logs or records for areas containing output devices - and related outputs
-system security plan
-other relevant documents or records
-Organizational personnel with physical access control responsibilities
-organizational personnel with information security responsibilities
-Organizational processes for access control to output devices
-mechanisms supporting and/or implementing access control to output devices
-the frequency at which to review physical access logs is defined;
-events or potential indication of events requiring physical access logs to be - reviewed are defined;
-Monitor physical access to the facility where the system resides to detect - and respond to physical security incidents;
-Review physical access logs
Coordinate results of reviews and investigations with the organizational - incident response capability.
-Physical access monitoring includes publicly accessible areas within - organizational facilities. Examples of physical access monitoring include the - employment of guards, video surveillance equipment (i.e., cameras), and sensor - devices. Reviewing physical access logs can help identify suspicious activity, - anomalous events, or potential threats. The reviews can be supported by audit - logging controls, such as AU-2 , if the access logs are part - of an automated system. Organizational incident response capabilities include - investigations of physical security incidents and responses to the incidents. - Incidents include security violations or suspicious physical access activities. - Suspicious physical access activities include accesses outside of normal work - hours, repeated accesses to areas not normally accessed, accesses for unusual - lengths of time, and out-of-sequence accesses.
-physical access to the facility where the system resides is monitored to - detect and respond to physical security incidents;
- -physical access logs are reviewed
physical access logs are reviewed upon occurrence of
results of reviews are coordinated with organizational incident response - capabilities;
- -results of investigations are coordinated with organizational incident - response capabilities.
- -Physical and environmental protection policy
-procedures addressing physical access monitoring
-physical access logs or records
-physical access monitoring records
-physical access log reviews
-system security plan
-other relevant documents or records
-Organizational personnel with physical access monitoring responsibilities
-organizational personnel with incident response responsibilities
-organizational personnel with information security responsibilities
-Organizational processes for monitoring physical access
-mechanisms supporting and/or implementing physical access monitoring
-mechanisms supporting and/or implementing the review of physical access logs
-Monitor physical access to the facility where the system resides using - physical intrusion alarms and surveillance equipment.
-Physical intrusion alarms can be employed to alert security personnel when - unauthorized access to the facility is attempted. Alarm systems work in - conjunction with physical barriers, physical access control systems, and - security guards by triggering a response when these other forms of security - have been compromised or breached. Physical intrusion alarms can include - different types of sensor devices, such as motion sensors, contact sensors, - and broken glass sensors. Surveillance equipment includes video cameras - installed at strategic locations throughout the facility.
-physical access to the facility where the system resides is monitored - using physical intrusion alarms;
- -physical access to the facility where the system resides is monitored - using physical surveillance equipment.
- -Physical and environmental protection policy
-procedures addressing physical access monitoring
-physical access logs or records
-physical access monitoring records
-physical access log reviews
-system security plan
-privacy plan
-privacy impact assessment
-privacy risk assessment documentation
-other relevant documents or records
-Organizational personnel with physical access monitoring responsibilities
-organizational personnel with incident response responsibilities
-organizational personnel with information security and privacy - responsibilities
-Organizational processes for monitoring physical intrusion alarms and - surveillance equipment
-mechanisms supporting and/or implementing physical access monitoring
-mechanisms supporting and/or implementing physical intrusion alarms and - surveillance equipment
-time period for which to maintain visitor access records for the facility - where the system resides is defined;
-the frequency at which to review visitor access records is defined;
-personnel to whom visitor access records anomalies are reported to is/are - defined;
-Maintain visitor access records to the facility where the system resides for
Review visitor access records
Report anomalies in visitor access records to
Visitor access records include the names and organizations of individuals - visiting, visitor signatures, forms of identification, dates of access, entry - and departure times, purpose of visits, and the names and organizations of - individuals visited. Access record reviews determine if access authorizations - are current and are still required to support organizational mission and - business functions. Access records are not required for publicly accessible - areas.
-visitor access records for the facility where the system resides are
- maintained for
visitor access records are reviewed
visitor access records anomalies are reported to
Physical and environmental protection policy
-procedures addressing visitor access records
-visitor access control logs or records
-visitor access record or log reviews
-system security plan
-privacy plan
-privacy impact assessment
-privacy risk assessment documentation
-other relevant documents or records
-Organizational personnel with visitor access record responsibilities
-organizational personnel with information security and privacy - responsibilities
-Organizational processes for maintaining and reviewing visitor access records
-mechanisms supporting and/or implementing the maintenance and review of - visitor access records
-Protect power equipment and power cabling for the system from damage and - destruction.
-Organizations determine the types of protection necessary for the power equipment - and cabling employed at different locations that are both internal and external - to organizational facilities and environments of operation. Types of power - equipment and cabling include internal cabling and uninterruptable power sources - in offices or data centers, generators and power cabling outside of buildings, - and power sources for self-contained components such as satellites, vehicles, - and other deployable systems.
-power equipment for the system is protected from damage and destruction;
- -power cabling for the system is protected from damage and destruction.
- -Physical and environmental protection policy
-procedures addressing power equipment/cabling protection
-facilities housing power equipment/cabling
-system security plan
-other relevant documents or records
-Organizational personnel with the responsibility to protect power - equipment/cabling
-organizational personnel with information security responsibilities
-Mechanisms supporting and/or implementing the protection of power - equipment/cabling
-system or individual system components that require the capability to shut - off power in emergency situations is/are defined;
-location of emergency shutoff switches or devices by system or system - component is defined;
-Provide the capability of shutting off power to
Place emergency shutoff switches or devices in
Protect emergency power shutoff capability from unauthorized activation.
-Emergency power shutoff primarily applies to organizational facilities that - contain concentrations of system resources, including data centers, mainframe - computer rooms, server rooms, and areas with computer-controlled machinery.
-the capability to shut off power to
emergency shutoff switches or devices are placed in
the emergency power shutoff capability is protected from unauthorized - activation.
- -Physical and environmental protection policy
-procedures addressing power source emergency shutoff
-emergency shutoff controls or switches
-locations housing emergency shutoff switches and devices
-security safeguards protecting the emergency power shutoff capability from - unauthorized activation
-system security plan
-other relevant documents or records
-Organizational personnel with the responsibility for the emergency power - shutoff capability (both implementing and using the capability)
-organizational personnel with information security responsibilities
-Mechanisms supporting and/or implementing emergency power shutoff
-Provide an uninterruptible power supply to facilitate
An uninterruptible power supply (UPS) is an electrical system or mechanism that - provides emergency power when there is a failure of the main power source. A UPS - is typically used to protect computers, data centers, telecommunication - equipment, or other electrical equipment where an unexpected power disruption - could cause injuries, fatalities, serious mission or business disruption, or - loss of data or information. A UPS differs from an emergency power system or - backup generator in that the UPS provides near-instantaneous protection from - unanticipated power interruptions from the main power source by providing energy - stored in batteries, supercapacitors, or flywheels. The battery duration of a - UPS is relatively short but provides sufficient time to start a standby power - source, such as a backup generator, or properly shut down the system.
-an uninterruptible power supply is provided to facilitate
Physical and environmental protection policy
-procedures addressing emergency power
-uninterruptible power supply
-uninterruptible power supply documentation
-uninterruptible power supply test records
-system security plan
-other relevant documents or records
-Organizational personnel with the responsibility for emergency power and/or - planning
-organizational personnel with information security responsibilities
-Mechanisms supporting and/or implementing an uninterruptible power supply
-the uninterruptable power supply
-Employ and maintain automatic emergency lighting for the system that activates in - the event of a power outage or disruption and that covers emergency exits and - evacuation routes within the facility.
-The provision of emergency lighting applies primarily to organizational - facilities that contain concentrations of system resources, including data - centers, server rooms, and mainframe computer rooms. Emergency lighting - provisions for the system are described in the contingency plan for the - organization. If emergency lighting for the system fails or cannot be provided, - organizations consider alternate processing sites for power-related - contingencies.
-automatic emergency lighting that activates in the event of a power outage or - disruption is employed for the system;
- -automatic emergency lighting that activates in the event of a power outage or - disruption is maintained for the system;
- -automatic emergency lighting for the system covers emergency exits within the - facility;
- -automatic emergency lighting for the system covers evacuation routes within - the facility.
- -Physical and environmental protection policy
-procedures addressing emergency lighting
-emergency lighting documentation
-emergency lighting test records
-emergency exits and evacuation routes
-system security plan
-other relevant documents or records
-Organizational personnel with the responsibility for emergency lighting - and/or planning
-organizational personnel with information security responsibilities
-Mechanisms supporting and/or implementing an emergency lighting capability
-Employ and maintain fire detection and suppression systems that are supported by - an independent energy source.
-The provision of fire detection and suppression systems applies primarily to - organizational facilities that contain concentrations of system resources, - including data centers, server rooms, and mainframe computer rooms. Fire - detection and suppression systems that may require an independent energy source - include sprinkler systems and smoke detectors. An independent energy source is - an energy source, such as a microgrid, that is separate, or can be separated, - from the energy sources providing power for the other parts of the facility.
-fire detection systems are employed;
- -employed fire detection systems are supported by an independent energy - source;
- -employed fire detection systems are maintained;
- -fire suppression systems are employed;
- -employed fire suppression systems are supported by an independent energy - source;
- -employed fire suppression systems are maintained.
- -Physical and environmental protection policy
-procedures addressing fire protection
-fire suppression and detection devices/systems
-fire suppression and detection devices/systems documentation
-test records of fire suppression and detection devices/systems
-system security plan
-other relevant documents or records
-Organizational personnel with responsibilities for fire detection and - suppression devices/systems
-organizational personnel with information security responsibilities
-Mechanisms supporting and/or implementing fire suppression/detection - devices/systems
-personnel or roles to be notified in the event of a fire is/are defined;
-emergency responders to be notified in the event of a fire are defined;
-Employ fire detection systems that activate automatically and notify
Organizations can identify personnel, roles, and emergency responders if - individuals on the notification list need to have access authorizations or - clearances (e.g., to enter to facilities where access is restricted due to - the classification or impact level of information within the facility). - Notification mechanisms may require independent energy sources to ensure - that the notification capability is not adversely affected by the fire.
-fire detection systems that activate automatically are employed in the - event of a fire;
- -fire detection systems that notify
fire detection systems that notify
Physical and environmental protection policy
-procedures addressing fire protection
-facility housing the information system
-alarm service-level agreements
-test records of fire suppression and detection devices/systems
-fire suppression and detection devices/systems documentation
-alerts/notifications of fire events
-system security plan
-other relevant documents or records
-Organizational personnel with responsibilities for fire detection and - suppression devices/systems
-organizational personnel with responsibilities for notifying appropriate - personnel, roles, and emergency responders of fires
-organizational personnel with information security responsibilities
-Mechanisms supporting and/or implementing fire detection devices/systems
-activation of fire detection devices/systems (simulated)
-automated notifications
-environmental control(s) for which to maintain a specified level in the - facility where the system resides are defined (if selected);
-acceptable levels for environmental controls are defined;
-frequency at which to monitor environmental control levels is defined;
-Maintain
Monitor environmental control levels
The provision of environmental controls applies primarily to organizational - facilities that contain concentrations of system resources (e.g., data centers, - mainframe computer rooms, and server rooms). Insufficient environmental - controls, especially in very harsh environments, can have a significant adverse - impact on the availability of systems and system components that are needed to - support organizational mission and business functions.
-environmental control levels are monitored
Physical and environmental protection policy
-procedures addressing temperature and humidity control
-temperature and humidity controls
-facility housing the system
-temperature and humidity controls documentation
-temperature and humidity records
-system security plan
-other relevant documents or records
-Organizational personnel with responsibilities for system environmental - controls
-organizational personnel with information security responsibilities
-Mechanisms supporting and/or implementing the maintenance and monitoring of - temperature and humidity levels
-Protect the system from damage resulting from water leakage by providing master - shutoff or isolation valves that are accessible, working properly, and known to - key personnel.
-The provision of water damage protection primarily applies to organizational - facilities that contain concentrations of system resources, including data - centers, server rooms, and mainframe computer rooms. Isolation valves can be - employed in addition to or in lieu of master shutoff valves to shut off water - supplies in specific areas of concern without affecting entire organizations.
-the system is protected from damage resulting from water leakage by providing - master shutoff or isolation valves;
- -the master shutoff or isolation valves are accessible;
- -the master shutoff or isolation valves are working properly;
- -the master shutoff or isolation valves are known to key personnel.
- -Physical and environmental protection policy
-procedures addressing water damage protection
-facility housing the system
-master shutoff valves
-list of key personnel with knowledge of location and activation procedures - for master shutoff valves for the plumbing system
-master shutoff valve documentation
-system security plan
-other relevant documents or records
-Organizational personnel with responsibilities for system environmental - controls
-organizational personnel with information security responsibilities
-Master water-shutoff valves
-organizational process for activating master water shutoff
-types of system components to be authorized and controlled when entering the - facility are defined;
-types of system components to be authorized and controlled when exiting the - facility are defined;
-Authorize and control
Maintain records of the system components.
-Enforcing authorizations for entry and exit of system components may require - restricting access to delivery areas and isolating the areas from the system and - media libraries.
-records of the system components are maintained.
- -Physical and environmental protection policy
-procedures addressing the delivery and removal of system components from the - facility
-facility housing the system
-records of items entering and exiting the facility
-system security plan
-other relevant documents or records
-Organizational personnel with responsibilities for controlling system - components entering and exiting the facility
-organizational personnel with information security responsibilities
-Organizational process for authorizing, monitoring, and controlling - system-related items entering and exiting the facility
-mechanisms supporting and/or implementing, authorizing, monitoring, and - controlling system-related items entering and exiting the facility
-alternate work sites allowed for use by employees are defined;
-controls to be employed at alternate work sites are defined;
-Determine and document the
Employ the following controls at alternate work sites:
Assess the effectiveness of controls at alternate work sites; and
-Provide a means for employees to communicate with information security and - privacy personnel in case of incidents.
-Alternate work sites include government facilities or the private residences of - employees. While distinct from alternative processing sites, alternate work - sites can provide readily available alternate locations during contingency - operations. Organizations can define different sets of controls for specific - alternate work sites or types of sites depending on the work-related activities - conducted at the sites. Implementing and assessing the effectiveness of - organization-defined controls and providing a means to communicate incidents at - alternate work sites supports the contingency planning activities of - organizations.
-the effectiveness of controls at alternate work sites is assessed;
- -a means for employees to communicate with information security and privacy - personnel in case of incidents is provided.
- -Physical and environmental protection policy
-procedures addressing alternate work sites for organizational personnel
-list of security controls required for alternate work sites
-assessments of security controls at alternate work sites
-system security plan
-privacy plan
-other relevant documents or records
-Organizational personnel approving the use of alternate work sites
-organizational personnel using alternate work sites
-organizational personnel assessing controls at alternate work sites
-organizational personnel with information security and privacy - responsibilities
-Organizational processes for security and privacy at alternate work sites
-mechanisms supporting alternate work sites
-security and privacy controls employed at alternate work sites
-means of communication between personnel at alternate work sites and security - and privacy personnel
-personnel or roles to whom the planning policy is to be disseminated is/are - defined;
-personnel or roles to whom the planning procedures are to be disseminated - is/are defined;
-an official to manage the planning policy and procedures is defined;
-the frequency with which the current planning policy is reviewed and updated - is defined;
-events that would require the current planning policy to be reviewed and - updated are defined;
-the frequency with which the current planning procedures are reviewed and - updated is defined;
-events that would require procedures to be reviewed and updated are defined;
-Develop, document, and disseminate to
Addresses purpose, scope, roles, responsibilities, management - commitment, coordination among organizational entities, and - compliance; and
-Is consistent with applicable laws, executive orders, directives, - regulations, policies, standards, and guidelines; and
-Procedures to facilitate the implementation of the planning policy and - the associated planning controls;
-Designate an
Review and update the current planning:
-Policy
Procedures
Planning policy and procedures for the controls in the PL family implemented - within systems and organizations. The risk management strategy is an important - factor in establishing such policies and procedures. Policies and procedures - contribute to security and privacy assurance. Therefore, it is important that - security and privacy programs collaborate on their development. Security and - privacy program policies and procedures at the organization level are - preferable, in general, and may obviate the need for mission level or - system-specific policies and procedures. The policy can be included as part of - the general security and privacy policy or be represented by multiple policies - that reflect the complex nature of organizations. Procedures can be established - for security and privacy programs, for mission/business processes, and for - systems, if needed. Procedures describe how the policies or controls are - implemented and can be directed at the individual or role that is the object of - the procedure. Procedures can be documented in system security and privacy plans - or in one or more separate documents. Events that may precipitate an update to - planning policy and procedures include, but are not limited to, assessment or - audit findings, security incidents or breaches, or changes in laws, executive - orders, directives, regulations, policies, standards, and guidelines. Simply - restating controls does not constitute an organizational policy or procedure.
-a planning policy is developed and documented.
- -the planning policy is disseminated to
planning procedures to facilitate the implementation of the planning - policy and associated planning controls are developed and documented;
- -the planning procedures are disseminated to
the
the
the
the
the
the
the
the
the
the current planning policy is reviewed and updated
the current planning policy is reviewed and updated following
the current planning procedures are reviewed and updated
the current planning procedures are reviewed and updated following
Planning policy and procedures
-system security plan
-privacy plan
-other relevant documents or records
-Organizational personnel with planning responsibilities
-organizational personnel with information security and privacy - responsibilities
-individuals or groups with whom security and privacy-related activities - affecting the system that require planning and coordination is/are assigned;
-personnel or roles to receive distributed copies of the system security and - privacy plans is/are assigned;
-frequency to review system security and privacy plans is defined;
-Develop security and privacy plans for the system that:
-Are consistent with the organization’s enterprise architecture;
-Explicitly define the constituent system components;
-Describe the operational context of the system in terms of mission and - business processes;
-Identify the individuals that fulfill system roles and responsibilities;
-Identify the information types processed, stored, and transmitted by the - system;
-Provide the security categorization of the system, including supporting - rationale;
-Describe any specific threats to the system that are of concern to the - organization;
-Provide the results of a privacy risk assessment for systems processing - personally identifiable information;
-Describe the operational environment for the system and any dependencies - on or connections to other systems or system components;
-Provide an overview of the security and privacy requirements for the - system;
-Identify any relevant control baselines or overlays, if applicable;
-Describe the controls in place or planned for meeting the security and - privacy requirements, including a rationale for any tailoring decisions;
-Include risk determinations for security and privacy architecture and - design decisions;
-Include security- and privacy-related activities affecting the system
- that require planning and coordination with
Are reviewed and approved by the authorizing official or designated - representative prior to plan implementation.
-Distribute copies of the plans and communicate subsequent changes to the
- plans to
Review the plans
Update the plans to address changes to the system and environment of - operation or problems identified during plan implementation or control - assessments; and
-Protect the plans from unauthorized disclosure and modification.
-System security and privacy plans are scoped to the system and system components - within the defined authorization boundary and contain an overview of the - security and privacy requirements for the system and the controls selected to - satisfy the requirements. The plans describe the intended application of each - selected control in the context of the system with a sufficient level of detail - to correctly implement the control and to subsequently assess the effectiveness - of the control. The control documentation describes how system-specific and - hybrid controls are implemented and the plans and expectations regarding the - functionality of the system. System security and privacy plans can also be used - in the design and development of systems in support of life cycle-based security - and privacy engineering processes. System security and privacy plans are living - documents that are updated and adapted throughout the system development life - cycle (e.g., during capability determination, analysis of alternatives, requests - for proposal, and design reviews). Section 2.1 describes the - different types of requirements that are relevant to organizations during the - system development life cycle and the relationship between requirements and - controls.
-Organizations may develop a single, integrated security and privacy plan or - maintain separate plans. Security and privacy plans relate security and privacy - requirements to a set of controls and control enhancements. The plans describe - how the controls and control enhancements meet the security and privacy - requirements but do not provide detailed, technical descriptions of the design - or implementation of the controls and control enhancements. Security and privacy - plans contain sufficient information (including specifications of control - parameter values for selection and assignment operations explicitly or by - reference) to enable a design and implementation that is unambiguously compliant - with the intent of the plans and subsequent determinations of risk to - organizational operations and assets, individuals, other organizations, and the - Nation if the plan is implemented.
-Security and privacy plans need not be single documents. The plans can be a - collection of various documents, including documents that already exist. - Effective security and privacy plans make extensive use of references to - policies, procedures, and additional documents, including design and - implementation specifications where more detailed information can be obtained. - The use of references helps reduce the documentation associated with security - and privacy programs and maintains the security- and privacy-related information - in other established management and operational areas, including enterprise - architecture, system development life cycle, systems engineering, and - acquisition. Security and privacy plans need not contain detailed contingency - plan or incident response plan information but can instead provide—explicitly or - by reference—sufficient information to define what needs to be accomplished by - those plans.
-Security- and privacy-related activities that may require coordination and - planning with other individuals or groups within the organization include - assessments, audits, inspections, hardware and software maintenance, acquisition - and supply chain risk management, patch management, and contingency plan - testing. Planning and coordination include emergency and nonemergency (i.e., - planned or non-urgent unplanned) situations. The process defined by - organizations to plan and coordinate security- and privacy-related activities - can also be included in other documents, as appropriate.
-a security plan for the system is developed that is consistent with - the organization’s enterprise architecture;
- -a privacy plan for the system is developed that is consistent with - the organization’s enterprise architecture;
- -a security plan for the system is developed that explicitly defines - the constituent system components;
- -a privacy plan for the system is developed that explicitly defines - the constituent system components;
- -a security plan for the system is developed that describes the - operational context of the system in terms of mission and business - processes;
- -a privacy plan for the system is developed that describes the - operational context of the system in terms of mission and business - processes;
- -a security plan for the system is developed that identifies the - individuals that fulfill system roles and responsibilities;
- -a privacy plan for the system is developed that identifies the - individuals that fulfill system roles and responsibilities;
- -a security plan for the system is developed that identifies the - information types processed, stored, and transmitted by the system;
- -a privacy plan for the system is developed that identifies the - information types processed, stored, and transmitted by the system;
- -a security plan for the system is developed that provides the - security categorization of the system, including supporting - rationale;
- -a privacy plan for the system is developed that provides the security - categorization of the system, including supporting rationale;
- -a security plan for the system is developed that describes any - specific threats to the system that are of concern to the - organization;
- -a privacy plan for the system is developed that describes any - specific threats to the system that are of concern to the - organization;
- -a security plan for the system is developed that provides the results - of a privacy risk assessment for systems processing personally - identifiable information;
- -a privacy plan for the system is developed that provides the results - of a privacy risk assessment for systems processing personally - identifiable information;
- -a security plan for the system is developed that describes the - operational environment for the system and any dependencies on or - connections to other systems or system components;
- -a privacy plan for the system is developed that describes the - operational environment for the system and any dependencies on or - connections to other systems or system components;
- -a security plan for the system is developed that provides an overview - of the security requirements for the system;
- -a privacy plan for the system is developed that provides an overview - of the privacy requirements for the system;
- -a security plan for the system is developed that identifies any - relevant control baselines or overlays, if applicable;
- -a privacy plan for the system is developed that identifies any - relevant control baselines or overlays, if applicable;
- -a security plan for the system is developed that describes the - controls in place or planned for meeting the security requirements, - including rationale for any tailoring decisions;
- -a privacy plan for the system is developed that describes the - controls in place or planned for meeting the privacy requirements, - including rationale for any tailoring decisions;
- -a security plan for the system is developed that includes risk - determinations for security architecture and design decisions;
- -a privacy plan for the system is developed that includes risk - determinations for privacy architecture and design decisions;
- -a security plan for the system is developed that includes
- security-related activities affecting the system that require
- planning and coordination with
a privacy plan for the system is developed that includes
- privacy-related activities affecting the system that require
- planning and coordination with
a security plan for the system is developed that is reviewed and - approved by the authorizing official or designated representative - prior to plan implementation;
- -a privacy plan for the system is developed that is reviewed and - approved by the authorizing official or designated representative - prior to plan implementation.
- -copies of the plans are distributed to
subsequent changes to the plans are communicated to
plans are reviewed
plans are updated to address changes to the system and environment of - operations;
- -plans are updated to address problems identified during the plan - implementation;
- -plans are updated to address problems identified during control - assessments;
- -plans are protected from unauthorized disclosure;
- -plans are protected from unauthorized modification.
- -Security and privacy planning policy
-procedures addressing system security and privacy plan development and - implementation
-procedures addressing security and privacy plan reviews and updates
-enterprise architecture documentation
-system security plan
-privacy plan
-records of system security and privacy plan reviews and updates
-security and privacy architecture and design documentation
-risk assessments
-risk assessment results
-control assessment documentation
-other relevant documents or records
-Organizational personnel with system security and privacy planning and plan - implementation responsibilities
-system developers
-organizational personnel with information security and privacy - responsibilities
-Organizational processes for system security and privacy plan development, - review, update, and approval
-mechanisms supporting the system security and privacy plan
-frequency for reviewing and updating the rules of behavior is defined;
-frequency for individuals to read and re-acknowledge the rules of behavior is - defined (if selected);
-Establish and provide to individuals requiring access to the system, the - rules that describe their responsibilities and expected behavior for - information and system usage, security, and privacy;
-Receive a documented acknowledgment from such individuals, indicating that - they have read, understand, and agree to abide by the rules of behavior, - before authorizing access to information and the system;
-Review and update the rules of behavior
Require individuals who have acknowledged a previous version of the rules of
- behavior to read and re-acknowledge
Rules of behavior represent a type of access agreement for organizational users. - Other types of access agreements include nondisclosure agreements, - conflict-of-interest agreements, and acceptable use agreements (see PS-6 ). Organizations consider rules of behavior based on - individual user roles and responsibilities and differentiate between rules that - apply to privileged users and rules that apply to general users. Establishing - rules of behavior for some types of non-organizational users, including - individuals who receive information from federal systems, is often not feasible - given the large number of such users and the limited nature of their - interactions with the systems. Rules of behavior for organizational and - non-organizational users can also be established in AC-8 . - The related controls section provides a list of controls that are relevant to - organizational rules of behavior. PL-4b , the - documented acknowledgment portion of the control, may be satisfied by the - literacy training and awareness and role-based training programs conducted by - organizations if such training includes rules of behavior. Documented - acknowledgements for rules of behavior include electronic or physical signatures - and electronic agreement check boxes or radio buttons.
-rules that describe responsibilities and expected behavior for - information and system usage, security, and privacy are established for - individuals requiring access to the system;
- -rules that describe responsibilities and expected behavior for - information and system usage, security, and privacy are provided to - individuals requiring access to the system;
- -before authorizing access to information and the system, a documented - acknowledgement from such individuals indicating that they have read, - understand, and agree to abide by the rules of behavior is received;
- -rules of behavior are reviewed and updated
individuals who have acknowledged a previous version of the rules of behavior
- are required to read and reacknowledge
Security and privacy planning policy
-procedures addressing rules of behavior for system users
-rules of behavior
-signed acknowledgements
-records for rules of behavior reviews and updates
-other relevant documents or records
-Organizational personnel with responsibility for establishing, reviewing, and - updating rules of behavior
-organizational personnel with responsibility for literacy training and - awareness and role-based training
-organizational personnel who are authorized users of the system and have - signed and resigned rules of behavior
-organizational personnel with information security and privacy - responsibilities
-Organizational processes for establishing, reviewing, disseminating, and - updating rules of behavior
-mechanisms supporting and/or implementing the establishment, review, - dissemination, and update of rules of behavior
-Include in the rules of behavior, restrictions on:
-Use of social media, social networking sites, and external - sites/applications;
-Posting organizational information on public websites; and
-Use of organization-provided identifiers (e.g., email addresses) and - authentication secrets (e.g., passwords) for creating accounts on - external sites/applications.
-Social media, social networking, and external site/application usage - restrictions address rules of behavior related to the use of social media, - social networking, and external sites when organizational personnel are - using such sites for official duties or in the conduct of official business, - when organizational information is involved in social media and social - networking transactions, and when personnel access social media and - networking sites from organizational systems. Organizations also address - specific rules that prevent unauthorized entities from obtaining non-public - organizational information from social media and networking sites either - directly or through inference. Non-public information includes personally - identifiable information and system account information.
-the rules of behavior include restrictions on the use of social media, - social networking sites, and external sites/applications;
- -the rules of behavior include restrictions on posting organizational - information on public websites;
- -the rules of behavior include restrictions on the use of - organization-provided identifiers (e.g., email addresses) and - authentication secrets (e.g., passwords) for creating accounts on - external sites/applications.
- -Security and privacy planning policy
-procedures addressing rules of behavior for system users
-rules of behavior
-training policy
-other relevant documents or records
-Organizational personnel with responsibility for establishing, reviewing, - and updating rules of behavior
-organizational personnel with responsibility for literacy training and - awareness and role-based training
-organizational personnel who are authorized users of the system and have - signed rules of behavior
-organizational personnel with information security and privacy - responsibilities
-Organizational processes for establishing rules of behavior
-mechanisms supporting and/or implementing the establishment of rules of - behavior
-frequency for review and update to reflect changes in the enterprise - architecture;
-Develop security and privacy architectures for the system that:
-Describe the requirements and approach to be taken for protecting the - confidentiality, integrity, and availability of organizational - information;
-Describe the requirements and approach to be taken for processing - personally identifiable information to minimize privacy risk to - individuals;
-Describe how the architectures are integrated into and support the - enterprise architecture; and
-Describe any assumptions about, and dependencies on, external systems and - services;
-Review and update the architectures
Reflect planned architecture changes in security and privacy plans, Concept - of Operations (CONOPS), criticality analysis, organizational procedures, and - procurements and acquisitions.
-The security and privacy architectures at the system level are consistent with - the organization-wide security and privacy architectures described in - PM-7 , which are integral to and developed as part of the enterprise - architecture. The architectures include an architectural description, the - allocation of security and privacy functionality (including controls), security- - and privacy-related information for external interfaces, information being - exchanged across the interfaces, and the protection mechanisms associated with - each interface. The architectures can also include other information, such as - user roles and the access privileges assigned to each role; security and privacy - requirements; types of information processed, stored, and transmitted by the - system; supply chain risk management requirements; restoration priorities of - information and system services; and other protection needs.
-SP 800-160-1 provides - guidance on the use of security architectures as part of the system development - life cycle process. OMB M-19-03 - requires the use of the systems security engineering concepts described in SP 800-160-1 for high value - assets. Security and privacy architectures are reviewed and updated throughout - the system development life cycle, from analysis of alternatives through review - of the proposed architecture in the RFP responses to the design reviews before - and during implementation (e.g., during preliminary design reviews and critical - design reviews).
-In today’s modern computing architectures, it is becoming less common for - organizations to control all information resources. There may be key - dependencies on external information services and service providers. Describing - such dependencies in the security and privacy architectures is necessary for - developing a comprehensive mission and business protection strategy. - Establishing, developing, documenting, and maintaining under configuration - control a baseline configuration for organizational systems is critical to - implementing and maintaining effective architectures. The development of the - architectures is coordinated with the senior agency information security officer - and the senior agency official for privacy to ensure that the controls needed to - support security and privacy requirements are identified and effectively - implemented. In many circumstances, there may be no distinction between the - security and privacy architecture for a system. In other circumstances, security - objectives may be adequately satisfied, but privacy objectives may only be - partially satisfied by the security requirements. In these cases, consideration - of the privacy requirements needed to achieve satisfaction will result in a - distinct privacy architecture. The documentation, however, may simply reflect - the combined architectures.
-PL-8 is primarily directed at organizations to ensure that - architectures are developed for the system and, moreover, that the architectures - are integrated with or tightly coupled to the enterprise architecture. In - contrast, - SA-17 is primarily directed at the external information technology product - and system developers and integrators. - SA-17 , which is complementary to PL-8 , is selected - when organizations outsource the development of systems or components to - external entities and when there is a need to demonstrate consistency with the - organization’s enterprise architecture and security and privacy architectures.
-a security architecture for the system describes the requirements and - approach to be taken for protecting the confidentiality, integrity, and - availability of organizational information;
- -a privacy architecture describes the requirements and approach to be - taken for processing personally identifiable information to minimize - privacy risk to individuals;
- -a security architecture for the system describes how the architecture - is integrated into and supports the enterprise architecture;
- -a privacy architecture for the system describes how the architecture - is integrated into and supports the enterprise architecture;
- -a security architecture for the system describes any assumptions - about and dependencies on external systems and services;
- -a privacy architecture for the system describes any assumptions about - and dependencies on external systems and services;
- -changes in the enterprise architecture are reviewed and updated
planned architecture changes are reflected in the security plan;
- -planned architecture changes are reflected in the privacy plan;
- -planned architecture changes are reflected in the Concept of Operations - (CONOPS);
- -planned architecture changes are reflected in criticality analysis;
- -planned architecture changes are reflected in organizational procedures;
- -planned architecture changes are reflected in procurements and - acquisitions.
- -Security and privacy planning policy
-procedures addressing information security and privacy architecture - development
-procedures addressing information security and privacy architecture reviews - and updates
-enterprise architecture documentation
-information security and privacy architecture documentation
-system security plan
-privacy plan
-security and privacy CONOPS for the system
-records of information security and privacy architecture reviews and updates
-other relevant documents or records
-Organizational personnel with security and privacy planning and plan - implementation responsibilities
-organizational personnel with information security and privacy architecture - development responsibilities
-organizational personnel with information security and privacy - responsibilities
-Organizational processes for developing, reviewing, and updating the - information security and privacy architecture
-mechanisms supporting and/or implementing the development, review, and update - of the information security and privacy architecture
-Select a control baseline for the system.
-Control baselines are predefined sets of controls specifically assembled to - address the protection needs of a group, organization, or community of interest. - Controls are chosen for baselines to either satisfy mandates imposed by laws, - executive orders, directives, regulations, policies, standards, and guidelines - or address threats common to all users of the baseline under the assumptions - specific to the baseline. Baselines represent a starting point for the - protection of individuals’ privacy, information, and information systems with - subsequent tailoring actions to manage risk in accordance with mission, - business, or other constraints (see PL-11 ). Federal - control baselines are provided in SP 800-53B . The selection - of a control baseline is determined by the needs of stakeholders. Stakeholder - needs consider mission and business requirements as well as mandates imposed by - applicable laws, executive orders, directives, policies, regulations, standards, - and guidelines. For example, the control baselines in SP 800-53B are based on the - requirements from FISMA and PRIVACT . The requirements, - along with the NIST standards and guidelines implementing the legislation, - direct organizations to select one of the control baselines after the reviewing - the information types and the information that is processed, stored, and - transmitted on the system; analyzing the potential adverse impact of the loss or - compromise of the information or system on the organization’s operations and - assets, individuals, other organizations, or the Nation; and considering the - results from system and organizational risk assessments. CNSSI 1253 provides - guidance on control baselines for national security systems.
-a control baseline for the system is selected.
- -Security and privacy planning policy
-procedures addressing system security and privacy plan development and - implementation
-procedures addressing system security and privacy plan reviews and updates
-system design documentation
-system architecture and configuration documentation
-system categorization decision
-information types stored, transmitted, and processed by the system
-system element/component information
-stakeholder needs analysis
-list of security and privacy requirements allocated to the system, system - elements, and environment of operation
-list of contractual requirements allocated to external providers of the - system or system element
-business impact analysis or criticality analysis
-risk assessments
-risk management strategy
-organizational security and privacy policy
-federal or organization-approved or mandated baselines or overlays
-system security plan
-privacy plan
-other relevant documents or records
-Organizational personnel with security and privacy planning and plan - implementation responsibilities
-organizational personnel with information security and privacy - responsibilities
-organizational personnel with responsibility for organizational risk - management activities
-Tailor the selected control baseline by applying specified tailoring actions.
-The concept of tailoring allows organizations to specialize or customize a set of - baseline controls by applying a defined set of tailoring actions. Tailoring - actions facilitate such specialization and customization by allowing - organizations to develop security and privacy plans that reflect their specific - mission and business functions, the environments where their systems operate, - the threats and vulnerabilities that can affect their systems, and any other - conditions or situations that can impact their mission or business success. - Tailoring guidance is provided in SP 800-53B . Tailoring a - control baseline is accomplished by identifying and designating common controls, - applying scoping considerations, selecting compensating controls, assigning - values to control parameters, supplementing the control baseline with additional - controls as needed, and providing information for control implementation. The - general tailoring actions in SP - 800-53B can be supplemented with additional actions based on the needs of - organizations. Tailoring actions can be applied to the baselines in SP 800-53B in accordance - with the security and privacy requirements from FISMA, PRIVACT , and OMB A-130 . Alternatively, - other communities of interest adopting different control baselines can apply the - tailoring actions in SP 800-53B - to specialize or customize the controls that represent the specific needs and - concerns of those entities.
-the selected control baseline is tailored by applying specified tailoring - actions.
- -Security and privacy planning policy
-procedures addressing system security and privacy plan development and - implementation
-system design documentation
-system categorization decision
-information types stored, transmitted, and processed by the system
-system element/component information
-stakeholder needs analysis
-list of security and privacy requirements allocated to the system, system - elements, and environment of operation
-list of contractual requirements allocated to external providers of the - system or system element
-business impact analysis or criticality analysis
-risk assessments
-risk management strategy
-organizational security and privacy policy
-federal or organization-approved or mandated baselines or overlays
-baseline tailoring rationale
-system security plan
-privacy plan
-records of system security and privacy plan reviews and updates
-other relevant documents or records
-Organizational personnel with security and privacy planning and plan - implementation responsibilities
-organizational personnel with information security and privacy - responsibilities
-personnel or roles to whom the personnel security policy is to be - disseminated is/are defined;
-personnel or roles to whom the personnel security procedures are to be - disseminated is/are defined;
-an official to manage the personnel security policy and procedures is - defined;
-the frequency at which the current personnel security policy is reviewed and - updated is defined;
-events that would require the current personnel security policy to be - reviewed and updated are defined;
-the frequency at which the current personnel security procedures are reviewed - and updated is defined;
-events that would require the personnel security procedures to be reviewed - and updated are defined;
-Develop, document, and disseminate to
Addresses purpose, scope, roles, responsibilities, management - commitment, coordination among organizational entities, and - compliance; and
-Is consistent with applicable laws, executive orders, directives, - regulations, policies, standards, and guidelines; and
-Procedures to facilitate the implementation of the personnel security - policy and the associated personnel security controls;
-Designate an
Review and update the current personnel security:
-Policy
Procedures
Personnel security policy and procedures for the controls in the PS family that - are implemented within systems and organizations. The risk management strategy - is an important factor in establishing such policies and procedures. Policies - and procedures contribute to security and privacy assurance. Therefore, it is - important that security and privacy programs collaborate on their development. - Security and privacy program policies and procedures at the organization level - are preferable, in general, and may obviate the need for mission level or - system-specific policies and procedures. The policy can be included as part of - the general security and privacy policy or be represented by multiple policies - reflecting the complex nature of organizations. Procedures can be established - for security and privacy programs, for mission/business processes, and for - systems, if needed. Procedures describe how the policies or controls are - implemented and can be directed at the individual or role that is the object of - the procedure. Procedures can be documented in system security and privacy plans - or in one or more separate documents. Events that may precipitate an update to - personnel security policy and procedures include, but are not limited to, - assessment or audit findings, security incidents or breaches, or changes in - applicable laws, executive orders, directives, regulations, policies, standards, - and guidelines. Simply restating controls does not constitute an organizational - policy or procedure.
-a personnel security policy is developed and documented;
- -the personnel security policy is disseminated to
personnel security procedures to facilitate the implementation of the - personnel security policy and associated personnel security controls are - developed and documented;
- -the personnel security procedures are disseminated to
the
the
the
the
the
the
the
the
the
the current personnel security policy is reviewed and updated
the current personnel security policy is reviewed and updated
- following
the current personnel security procedures are reviewed and updated
the current personnel security procedures are reviewed and updated
- following
Personnel security policy
-personnel security procedures
-system security plan
-privacy plan
-risk management strategy documentation
-audit findings
-other relevant documents or records
-Organizational personnel with personnel security responsibilities
-organizational personnel with information security responsibilities
-the frequency at which to review and update position risk designations is - defined;
-Assign a risk designation to all organizational positions;
-Establish screening criteria for individuals filling those positions; and
-Review and update position risk designations
Position risk designations reflect Office of Personnel Management (OPM) policy - and guidance. Proper position designation is the foundation of an effective and - consistent suitability and personnel security program. The Position Designation - System (PDS) assesses the duties and responsibilities of a position to determine - the degree of potential damage to the efficiency or integrity of the service due - to misconduct of an incumbent of a position and establishes the risk level of - that position. The PDS assessment also determines if the duties and - responsibilities of the position present the potential for position incumbents - to bring about a material adverse effect on national security and the degree of - that potential effect, which establishes the sensitivity level of a position. - The results of the assessment determine what level of investigation is conducted - for a position. Risk designations can guide and inform the types of - authorizations that individuals receive when accessing organizational - information and information systems. Position screening criteria include - explicit information security role appointment requirements. Parts 1400 and 731 - of Title 5, Code of Federal Regulations, establish the requirements for - organizations to evaluate relevant covered positions for a position sensitivity - and position risk designation commensurate with the duties and responsibilities - of those positions.
-a risk designation is assigned to all organizational positions;
- -screening criteria are established for individuals filling organizational - positions;
- -position risk designations are reviewed and updated
Personnel security policy
-procedures addressing position categorization
-appropriate codes of federal regulations
-list of risk designations for organizational positions
-records of position risk designation reviews and updates
-system security plan
-other relevant documents or records
-Organizational personnel with personnel security responsibilities
-organizational personnel with information security responsibilities
-Organizational processes for assigning, reviewing, and updating position risk - designations
-organizational processes for establishing screening criteria
-conditions requiring rescreening of individuals are defined;
-the frequency of rescreening individuals where it is so indicated is defined;
-Screen individuals prior to authorizing access to the system; and
-Rescreen individuals in accordance with
Personnel screening and rescreening activities reflect applicable laws, executive - orders, directives, regulations, policies, standards, guidelines, and specific - criteria established for the risk designations of assigned positions. Examples - of personnel screening include background investigations and agency checks. - Organizations may define different rescreening conditions and frequencies for - personnel accessing systems based on types of information processed, stored, or - transmitted by the systems.
-individuals are screened prior to authorizing access to the system;
- -individuals are rescreened in accordance with
where rescreening is so indicated, individuals are rescreened
Personnel security policy
-procedures addressing personnel screening
-records of screened personnel
-system security plan
-other relevant documents or records
-Organizational personnel with personnel security responsibilities
-organizational personnel with information security responsibilities
-Organizational processes for personnel screening
-a time period within which to disable system access is defined;
-information security topics to be discussed when conducting exit interviews - are defined;
-Upon termination of individual employment:
-Disable system access within
Terminate or revoke any authenticators and credentials associated with the - individual;
-Conduct exit interviews that include a discussion of
Retrieve all security-related organizational system-related property; and
-Retain access to organizational information and systems formerly controlled - by terminated individual.
-System property includes hardware authentication tokens, system administration - technical manuals, keys, identification cards, and building passes. Exit - interviews ensure that terminated individuals understand the security - constraints imposed by being former employees and that proper accountability is - achieved for system-related property. Security topics at exit interviews include - reminding individuals of nondisclosure agreements and potential limitations on - future employment. Exit interviews may not always be possible for some - individuals, including in cases related to the unavailability of supervisors, - illnesses, or job abandonment. Exit interviews are important for individuals - with security clearances. The timely execution of termination actions is - essential for individuals who have been terminated for cause. In certain - situations, organizations consider disabling the system accounts of individuals - who are being terminated prior to the individuals being notified.
-upon termination of individual employment, system access is disabled within
upon termination of individual employment, any authenticators and credentials - are terminated or revoked;
- -upon termination of individual employment, exit interviews that include a
- discussion of
upon termination of individual employment, all security-related - organizational system-related property is retrieved;
- -upon termination of individual employment, access to organizational - information and systems formerly controlled by the terminated individual are - retained.
- -Personnel security policy
-procedures addressing personnel termination
-records of personnel termination actions
-list of system accounts
-records of terminated or revoked authenticators/credentials
-records of exit interviews
-system security plan
-other relevant documents or records
-Organizational personnel with personnel security responsibilities
-organizational personnel with account management responsibilities
-system/network administrators
-organizational personnel with information security responsibilities
-Organizational processes for personnel termination
-mechanisms supporting and/or implementing personnel termination notifications
-mechanisms for disabling system access/revoking authenticators
-transfer or reassignment actions to be initiated following transfer or - reassignment are defined;
-the time period within which transfer or reassignment actions must occur - following transfer or reassignment is defined;
-personnel or roles to be notified when individuals are reassigned or - transferred to other positions within the organization is/are defined;
-time period within which to notify organization-defined personnel or roles - when individuals are reassigned or transferred to other positions within the - organization is defined;
-Review and confirm ongoing operational need for current logical and physical - access authorizations to systems and facilities when individuals are - reassigned or transferred to other positions within the organization;
-Initiate
Modify access authorization as needed to correspond with any changes in - operational need due to reassignment or transfer; and
-Notify
Personnel transfer applies when reassignments or transfers of individuals are - permanent or of such extended duration as to make the actions warranted. - Organizations define actions appropriate for the types of reassignments or - transfers, whether permanent or extended. Actions that may be required for - personnel transfers or reassignments to other positions within organizations - include returning old and issuing new keys, identification cards, and building - passes; closing system accounts and establishing new accounts; changing system - access authorizations (i.e., privileges); and providing for access to official - records to which individuals had access at previous work locations and in - previous system accounts.
-the ongoing operational need for current logical and physical access - authorizations to systems and facilities are reviewed and confirmed when - individuals are reassigned or transferred to other positions within the - organization;
- -access authorization is modified as needed to correspond with any changes in - operational need due to reassignment or transfer;
- -Personnel security policy
-procedures addressing personnel transfer
-records of personnel transfer actions
-list of system and facility access authorizations
-system security plan
-other relevant documents or records
-Organizational personnel with personnel security responsibilities
-organizational personnel with account management responsibilities
-system/network administrators
-organizational personnel with information security responsibilities
-Organizational processes for personnel transfer
-mechanisms supporting and/or implementing personnel transfer notifications
-mechanisms for disabling system access/revoking authenticators
-the frequency at which to review and update access agreements is defined;
-the frequency at which to re-sign access agreements to maintain access to - organizational information is defined;
-Develop and document access agreements for organizational systems;
-Review and update the access agreements
Verify that individuals requiring access to organizational information and - systems:
-Sign appropriate access agreements prior to being granted access; and
-Re-sign access agreements to maintain access to organizational systems
- when access agreements have been updated or
Access agreements include nondisclosure agreements, acceptable use agreements, - rules of behavior, and conflict-of-interest agreements. Signed access agreements - include an acknowledgement that individuals have read, understand, and agree to - abide by the constraints associated with organizational systems to which access - is authorized. Organizations can use electronic signatures to acknowledge access - agreements unless specifically prohibited by organizational policy.
-access agreements are developed and documented for organizational systems;
- -the access agreements are reviewed and updated
individuals requiring access to organizational information and systems - sign appropriate access agreements prior to being granted access;
- -individuals requiring access to organizational information and systems
- re-sign access agreements to maintain access to organizational systems
- when access agreements have been updated or
Personnel security policy
-personnel security procedures
-procedures addressing access agreements for organizational information and - systems
-access control policy
-access control procedures
-access agreements (including non-disclosure agreements, acceptable use - agreements, rules of behavior, and conflict-of-interest agreements)
-documentation of access agreement reviews, updates, and re-signing
-system security plan
-privacy plan
-other relevant documents or records
-Organizational personnel with personnel security responsibilities
-organizational personnel who have signed/resigned access agreements
-organizational personnel with information security and privacy - responsibilities
-Organizational processes for reviewing, updating, and re-signing access - agreements
-mechanisms supporting the reviewing, updating, and re-signing of access - agreements
-personnel or roles to be notified of any personnel transfers or terminations - of external personnel who possess organizational credentials and/or badges - or who have system privileges is/are defined;
-time period within which third-party providers are required to notify - organization-defined personnel or roles of any personnel transfers or - terminations of external personnel who possess organizational credentials - and/or badges or who have system privileges is defined;
-Establish personnel security requirements, including security roles and - responsibilities for external providers;
-Require external providers to comply with personnel security policies and - procedures established by the organization;
-Document personnel security requirements;
-Require external providers to notify
Monitor provider compliance with personnel security requirements.
-External provider refers to organizations other than the organization operating - or acquiring the system. External providers include service bureaus, - contractors, and other organizations that provide system development, - information technology services, testing or assessment services, outsourced - applications, and network/security management. Organizations explicitly include - personnel security requirements in acquisition-related documents. External - providers may have personnel working at organizational facilities with - credentials, badges, or system privileges issued by organizations. Notifications - of external personnel changes ensure the appropriate termination of privileges - and credentials. Organizations define the transfers and terminations deemed - reportable by security-related characteristics that include functions, roles, - and the nature of credentials or privileges associated with transferred or - terminated individuals.
-personnel security requirements are established, including security roles and - responsibilities for external providers;
- -external providers are required to comply with personnel security policies - and procedures established by the organization;
- -personnel security requirements are documented;
- -external providers are required to notify
provider compliance with personnel security requirements is monitored.
- -Personnel security policy
-procedures addressing external personnel security
-list of personnel security requirements
-acquisition documents
-service-level agreements
-compliance monitoring process
-system security plan
-other relevant documents or records
-Organizational personnel with personnel security responsibilities
-external providers
-system/network administrators
-organizational personnel with account management responsibilities
-organizational personnel with information security responsibilities
-Organizational processes for managing and monitoring external personnel - security
-mechanisms supporting and/or implementing the monitoring of provider - compliance
-personnel or roles to be notified when a formal employee sanctions process is - initiated is/are defined;
-the time period within which organization-defined personnel or roles must be - notified when a formal employee sanctions process is initiated is defined;
-Employ a formal sanctions process for individuals failing to comply with - established information security and privacy policies and procedures; and
-Notify
Organizational sanctions reflect applicable laws, executive orders, directives, - regulations, policies, standards, and guidelines. Sanctions processes are - described in access agreements and can be included as part of general personnel - policies for organizations and/or specified in security and privacy policies. - Organizations consult with the Office of the General Counsel regarding matters - of employee sanctions.
-a formal sanctions process is employed for individuals failing to comply with - established information security and privacy policies and procedures;
- -Personnel security policy
-personnel security procedures
-procedures addressing personnel sanctions
-access agreements (including non-disclosure agreements, acceptable use - agreements, rules of behavior, and conflict-of-interest agreements)
-list of personnel or roles to be notified of formal employee sanctions
-records or notifications of formal employee sanctions
-system security plan
-privacy plan
-personally identifiable information processing policy
-other relevant documents or records
-Organizational personnel with personnel security responsibilities
-legal counsel
-organizational personnel with information security and privacy - responsibilities
-Organizational processes for managing formal employee sanctions
-mechanisms supporting and/or implementing formal employee sanctions - notifications
-Incorporate security and privacy roles and responsibilities into organizational - position descriptions.
-Specification of security and privacy roles in individual organizational position - descriptions facilitates clarity in understanding the security or privacy - responsibilities associated with the roles and the role-based security and - privacy training requirements for the roles.
-security roles and responsibilities are incorporated into organizational - position descriptions;
- -privacy roles and responsibilities are incorporated into organizational - position descriptions.
- -Personnel security policy
-personnel security procedures
-procedures addressing position descriptions
-security and privacy position descriptions
-system security plan
-privacy plan
-privacy program plan
-other relevant documents or records
-Organizational personnel with personnel security responsibilities
-organizational personnel with information security and privacy - responsibilities
-organizational personnel with human capital management responsibilities
-Organizational processes for managing position descriptions
-personnel or roles to whom the risk assessment policy is to be disseminated - is/are defined;
-personnel or roles to whom the risk assessment procedures are to be - disseminated is/are defined;
-an official to manage the risk assessment policy and procedures is defined;
-the frequency at which the current risk assessment policy is reviewed and - updated is defined;
-events that would require the current risk assessment policy to be reviewed - and updated are defined;
-the frequency at which the current risk assessment procedures are reviewed - and updated is defined;
-events that would require risk assessment procedures to be reviewed and - updated are defined;
-Develop, document, and disseminate to
Addresses purpose, scope, roles, responsibilities, management - commitment, coordination among organizational entities, and - compliance; and
-Is consistent with applicable laws, executive orders, directives, - regulations, policies, standards, and guidelines; and
-Procedures to facilitate the implementation of the risk assessment policy - and the associated risk assessment controls;
-Designate an
Review and update the current risk assessment:
-Policy
Procedures
Risk assessment policy and procedures address the controls in the RA family that - are implemented within systems and organizations. The risk management strategy - is an important factor in establishing such policies and procedures. Policies - and procedures contribute to security and privacy assurance. Therefore, it is - important that security and privacy programs collaborate on the development of - risk assessment policy and procedures. Security and privacy program policies and - procedures at the organization level are preferable, in general, and may obviate - the need for mission- or system-specific policies and procedures. The policy can - be included as part of the general security and privacy policy or be represented - by multiple policies reflecting the complex nature of organizations. Procedures - can be established for security and privacy programs, for mission or business - processes, and for systems, if needed. Procedures describe how the policies or - controls are implemented and can be directed at the individual or role that is - the object of the procedure. Procedures can be documented in system security and - privacy plans or in one or more separate documents. Events that may precipitate - an update to risk assessment policy and procedures include assessment or audit - findings, security incidents or breaches, or changes in laws, executive orders, - directives, regulations, policies, standards, and guidelines. Simply restating - controls does not constitute an organizational policy or procedure.
-a risk assessment policy is developed and documented;
- -the risk assessment policy is disseminated to
risk assessment procedures to facilitate the implementation of the risk - assessment policy and associated risk assessment controls are developed - and documented;
- -the risk assessment procedures are disseminated to
the
the
the
the
the
the
the
the
the
the current risk assessment policy is reviewed and updated
the current risk assessment policy is reviewed and updated following
the current risk assessment procedures are reviewed and updated
the current risk assessment procedures are reviewed and updated
- following
Risk assessment policy and procedures
-system security plan
-privacy plan
-other relevant documents or records
-Organizational personnel with risk assessment responsibilities
-organizational personnel with security and privacy responsibilities
-Categorize the system and information it processes, stores, and transmits;
-Document the security categorization results, including supporting rationale, - in the security plan for the system; and
-Verify that the authorizing official or authorizing official designated - representative reviews and approves the security categorization decision.
-Security categories describe the potential adverse impacts or negative - consequences to organizational operations, organizational assets, and - individuals if organizational information and systems are compromised through a - loss of confidentiality, integrity, or availability. Security categorization is - also a type of asset loss characterization in systems security engineering - processes that is carried out throughout the system development life cycle. - Organizations can use privacy risk assessments or privacy impact assessments to - better understand the potential adverse effects on individuals. CNSSI 1253 provides - additional guidance on categorization for national security systems.
-Organizations conduct the security categorization process as an organization-wide - activity with the direct involvement of chief information officers, senior - agency information security officers, senior agency officials for privacy, - system owners, mission and business owners, and information owners or stewards. - Organizations consider the potential adverse impacts to other organizations and, - in accordance with USA PATRIOT - and Homeland Security Presidential Directives, potential national-level adverse - impacts.
-Security categorization processes facilitate the development of inventories of - information assets and, along with CM-8 , mappings to - specific system components where information is processed, stored, or - transmitted. The security categorization process is revisited throughout the - system development life cycle to ensure that the security categories remain - accurate and relevant.
-the system and the information it processes, stores, and transmits are - categorized;
- -the security categorization results, including supporting rationale, are - documented in the security plan for the system;
- -the authorizing official or authorizing official designated representative - reviews and approves the security categorization decision.
- -Risk assessment policy
-security planning policy and procedures
-procedures addressing security categorization of organizational information - and systems
-security categorization documentation
-system security plan
-privacy plan
-other relevant documents or records
-Organizational personnel with security categorization and risk assessment - responsibilities
-organizational personnel with security and privacy responsibilities
-Organizational processes for security categorization
-a document in which risk assessment results are to be documented (if not - documented in the security and privacy plans or risk assessment report) is - defined (if selected);
-the frequency to review risk assessment results is defined;
-personnel or roles to whom risk assessment results are to be disseminated - is/are defined;
-the frequency to update the risk assessment is defined;
-Conduct a risk assessment, including:
-Identifying threats to and vulnerabilities in the system;
-Determining the likelihood and magnitude of harm from unauthorized - access, use, disclosure, disruption, modification, or destruction of the - system, the information it processes, stores, or transmits, and any - related information; and
-Determining the likelihood and impact of adverse effects on individuals - arising from the processing of personally identifiable information;
-Integrate risk assessment results and risk management decisions from the - organization and mission or business process perspectives with system-level - risk assessments;
-Document risk assessment results in
Review risk assessment results
Disseminate risk assessment results to
Update the risk assessment
Risk assessments consider threats, vulnerabilities, likelihood, and impact to - organizational operations and assets, individuals, other organizations, and the - Nation. Risk assessments also consider risk from external parties, including - contractors who operate systems on behalf of the organization, individuals who - access organizational systems, service providers, and outsourcing entities.
-Organizations can conduct risk assessments at all three levels in the risk - management hierarchy (i.e., organization level, mission/business process level, - or information system level) and at any stage in the system development life - cycle. Risk assessments can also be conducted at various steps in the Risk - Management Framework, including preparation, categorization, control selection, - control implementation, control assessment, authorization, and control - monitoring. Risk assessment is an ongoing activity carried out throughout the - system development life cycle.
-Risk assessments can also address information related to the system, including - system design, the intended use of the system, testing results, and supply - chain-related information or artifacts. Risk assessments can play an important - role in control selection processes, particularly during the application of - tailoring guidance and in the earliest phases of capability determination.
-a risk assessment is conducted to identify threats to and vulnerabilities - in the system;
- -a risk assessment is conducted to determine the likelihood and magnitude - of harm from unauthorized access, use, disclosure, disruption, - modification, or destruction of the system; the information it - processes, stores, or transmits; and any related information;
- -a risk assessment is conducted to determine the likelihood and impact of - adverse effects on individuals arising from the processing of personally - identifiable information;
- -risk assessment results and risk management decisions from the organization - and mission or business process perspectives are integrated with - system-level risk assessments;
- -risk assessment results are documented in
risk assessment results are reviewed
risk assessment results are disseminated to
the risk assessment is updated
Risk assessment policy
-risk assessment procedures
-security and privacy planning policy and procedures
-procedures addressing organizational assessments of risk
-risk assessment
-risk assessment results
-risk assessment reviews
-risk assessment updates
-system security plan
-privacy plan
-other relevant documents or records
-Organizational personnel with risk assessment responsibilities
-organizational personnel with security and privacy responsibilities
-Organizational processes for risk assessment
-mechanisms supporting and/or conducting, documenting, reviewing, - disseminating, and updating the risk assessment
-systems, system components, and system services to assess supply chain - risks are defined;
-the frequency at which to update the supply chain risk assessment is - defined;
-Assess supply chain risks associated with
Update the supply chain risk assessment
Supply chain-related events include disruption, use of defective components, - insertion of counterfeits, theft, malicious development practices, improper - delivery practices, and insertion of malicious code. These events can have a - significant impact on the confidentiality, integrity, or availability of a - system and its information and, therefore, can also adversely impact - organizational operations (including mission, functions, image, or - reputation), organizational assets, individuals, other organizations, and - the Nation. The supply chain-related events may be unintentional or - malicious and can occur at any point during the system life cycle. An - analysis of supply chain risk can help an organization identify systems or - components for which additional supply chain risk mitigations are required.
-supply chain risks associated with
the supply chain risk assessment is updated
Supply chain risk management policy
-inventory of critical systems, system components, and system services
-risk assessment policy
-security planning policy and procedures
-procedures addressing organizational assessments of supply chain risk
-risk assessment
-risk assessment results
-risk assessment reviews
-risk assessment updates
-acquisition policy
-system security plan
-supply chain risk management plan
-other relevant documents or records
-Organizational personnel with risk assessment responsibilities
-organizational personnel with security responsibilities
-organizational personnel with supply chain risk management - responsibilities
-Organizational processes for risk assessment
-mechanisms supporting and/or conducting, documenting, reviewing, - disseminating, and updating the supply chain risk assessment
-frequency for monitoring systems and hosted applications for vulnerabilities - is defined;
-frequency for scanning systems and hosted applications for vulnerabilities is - defined;
-response times to remediate legitimate vulnerabilities in accordance with an - organizational assessment of risk are defined;
-personnel or roles with whom information obtained from the vulnerability - scanning process and control assessments is to be shared;
-Monitor and scan for vulnerabilities in the system and hosted applications
Employ vulnerability monitoring tools and techniques that facilitate - interoperability among tools and automate parts of the vulnerability - management process by using standards for:
-Enumerating platforms, software flaws, and improper configurations;
-Formatting checklists and test procedures; and
-Measuring vulnerability impact;
-Analyze vulnerability scan reports and results from vulnerability monitoring;
-Remediate legitimate vulnerabilities
Share information obtained from the vulnerability monitoring process and
- control assessments with
Employ vulnerability monitoring tools that include the capability to readily - update the vulnerabilities to be scanned.
-Security categorization of information and systems guides the frequency and - comprehensiveness of vulnerability monitoring (including scans). Organizations - determine the required vulnerability monitoring for system components, ensuring - that the potential sources of vulnerabilities—such as infrastructure components - (e.g., switches, routers, guards, sensors), networked printers, scanners, and - copiers—are not overlooked. The capability to readily update vulnerability - monitoring tools as new vulnerabilities are discovered and announced and as new - scanning methods are developed helps to ensure that new vulnerabilities are not - missed by employed vulnerability monitoring tools. The vulnerability monitoring - tool update process helps to ensure that potential vulnerabilities in the system - are identified and addressed as quickly as possible. Vulnerability monitoring - and analyses for custom software may require additional approaches, such as - static analysis, dynamic analysis, binary analysis, or a hybrid of the three - approaches. Organizations can use these analysis approaches in source code - reviews and in a variety of tools, including web-based application scanners, - static analysis tools, and binary analyzers.
-Vulnerability monitoring includes scanning for patch levels; scanning for - functions, ports, protocols, and services that should not be accessible to users - or devices; and scanning for flow control mechanisms that are improperly - configured or operating incorrectly. Vulnerability monitoring may also include - continuous vulnerability monitoring tools that use instrumentation to - continuously analyze components. Instrumentation-based tools may improve - accuracy and may be run throughout an organization without scanning. - Vulnerability monitoring tools that facilitate interoperability include tools - that are Security Content Automated Protocol (SCAP)-validated. Thus, - organizations consider using scanning tools that express vulnerabilities in the - Common Vulnerabilities and Exposures (CVE) naming convention and that employ the - Open Vulnerability Assessment Language (OVAL) to determine the presence of - vulnerabilities. Sources for vulnerability information include the Common - Weakness Enumeration (CWE) listing and the National Vulnerability Database - (NVD). Control assessments, such as red team exercises, provide additional - sources of potential vulnerabilities for which to scan. Organizations also - consider using scanning tools that express vulnerability impact by the Common - Vulnerability Scoring System (CVSS).
-Vulnerability monitoring includes a channel and process for receiving reports of - security vulnerabilities from the public at-large. Vulnerability disclosure - programs can be as simple as publishing a monitored email address or web form - that can receive reports, including notification authorizing good-faith research - and disclosure of security vulnerabilities. Organizations generally expect that - such research is happening with or without their authorization and can use - public vulnerability disclosure channels to increase the likelihood that - discovered vulnerabilities are reported directly to the organization for - remediation.
-Organizations may also employ the use of financial incentives (also known as bug
- bounties
) to further encourage external security researchers to report
- discovered vulnerabilities. Bug bounty programs can be tailored to the
- organization’s needs. Bounties can be operated indefinitely or over a defined
- period of time and can be offered to the general public or to a curated group.
- Organizations may run public and private bounties simultaneously and could
- choose to offer partially credentialed access to certain participants in order
- to evaluate security vulnerabilities from privileged vantage points.
systems and hosted applications are monitored for vulnerabilities
systems and hosted applications are scanned for vulnerabilities
vulnerability monitoring tools and techniques are employed to facilitate - interoperability among tools;
-vulnerability monitoring tools and techniques are employed to automate - parts of the vulnerability management process by using standards for - enumerating platforms, software flaws, and improper configurations;
- -vulnerability monitoring tools and techniques are employed to facilitate - interoperability among tools and to automate parts of the vulnerability - management process by using standards for formatting checklists and test - procedures;
- -vulnerability monitoring tools and techniques are employed to facilitate - interoperability among tools and to automate parts of the vulnerability - management process by using standards for measuring vulnerability - impact;
- -vulnerability scan reports and results from vulnerability monitoring are - analyzed;
- -legitimate vulnerabilities are remediated
information obtained from the vulnerability monitoring process and control
- assessments is shared with
vulnerability monitoring tools that include the capability to readily update - the vulnerabilities to be scanned are employed.
- -Risk assessment policy
-procedures addressing vulnerability scanning
-risk assessment
-assessment report
-vulnerability scanning tools and associated configuration documentation
-vulnerability scanning results
-patch and vulnerability management records
-system security plan
-other relevant documents or records
-Organizational personnel with risk assessment, control assessment, and - vulnerability scanning responsibilities
-organizational personnel with vulnerability scan analysis responsibilities
-organizational personnel with vulnerability remediation responsibilities
-organizational personnel with security responsibilities
-system/network administrators
-Organizational processes for vulnerability scanning, analysis, remediation, - and information sharing
-mechanisms supporting and/or implementing vulnerability scanning, analysis, - remediation, and information sharing
-the frequency for updating the system vulnerabilities to be scanned is - defined (if selected);
-Update the system vulnerabilities to be scanned
Due to the complexity of modern software, systems, and other factors, new - vulnerabilities are discovered on a regular basis. It is important that - newly discovered vulnerabilities are added to the list of vulnerabilities to - be scanned to ensure that the organization can take steps to mitigate those - vulnerabilities in a timely manner.
-the system vulnerabilities to be scanned are updated
Procedures addressing vulnerability scanning
-assessment report
-vulnerability scanning tools and associated configuration documentation
-vulnerability scanning results
-patch and vulnerability management records
-system security plan
-other relevant documents or records
-Organizational personnel with vulnerability scanning responsibilities
-organizational personnel with vulnerability scan analysis - responsibilities
-organizational personnel with security responsibilities
-system/network administrators
-Organizational processes for vulnerability scanning
-mechanisms/tools supporting and/or implementing vulnerability scanning
-system components to which privileged access is authorized for selected - vulnerability scanning activities are defined;
-vulnerability scanning activities selected for privileged access - authorization to system components are defined;
-Implement privileged access authorization to
In certain situations, the nature of the vulnerability scanning may be more - intrusive, or the system component that is the subject of the scanning may - contain classified or controlled unclassified information, such as - personally identifiable information. Privileged access authorization to - selected system components facilitates more thorough vulnerability scanning - and protects the sensitive nature of such scanning.
-privileged access authorization is implemented to
Risk assessment policy
-procedures addressing vulnerability scanning
-system design documentation
-system configuration settings and associated documentation
-list of system components for vulnerability scanning
-personnel access authorization list
-authorization credentials
-access authorization records
-system security plan
-other relevant documents or records
-Organizational personnel with vulnerability scanning responsibilities
-system/network administrators
-organizational personnel responsible for access control to the system
-organizational personnel responsible for configuration management of the - system
-system developers
-organizational personnel with security responsibilities
-Organizational processes for vulnerability scanning
-organizational processes for access control
-mechanisms supporting and/or implementing access control
-mechanisms/tools supporting and/or implementing vulnerability scanning
-Establish a public reporting channel for receiving reports of vulnerabilities - in organizational systems and system components.
-The reporting channel is publicly discoverable and contains clear language - authorizing good-faith research and the disclosure of vulnerabilities to the - organization. The organization does not condition its authorization on an - expectation of indefinite non-disclosure to the public by the reporting - entity but may request a specific time period to properly remediate the - vulnerability.
-a public reporting channel is established for receiving reports of - vulnerabilities in organizational systems and system components.
- -Risk assessment policy
-procedures addressing vulnerability scanning
-risk assessment
-vulnerability scanning tools and techniques documentation
-vulnerability scanning results
-vulnerability management records
-audit records
-public reporting channel
-system security plan
-other relevant documents or records
-Organizational personnel with vulnerability scanning responsibilities
-organizational personnel with vulnerability scan analysis - responsibilities
-organizational personnel with security responsibilities
-Organizational processes for vulnerability scanning
-mechanisms/tools supporting and/or implementing vulnerability scanning
-mechanisms implementing the public reporting of vulnerabilities
-Respond to findings from security and privacy assessments, monitoring, and audits - in accordance with organizational risk tolerance.
-Organizations have many options for responding to risk including mitigating risk - by implementing new controls or strengthening existing controls, accepting risk - with appropriate justification or rationale, sharing or transferring risk, or - avoiding risk. The risk tolerance of the organization influences risk response - decisions and actions. Risk response addresses the need to determine an - appropriate response to risk before generating a plan of action and milestones - entry. For example, the response may be to accept risk or reject risk, or it may - be possible to mitigate the risk immediately so that a plan of action and - milestones entry is not needed. However, if the risk response is to mitigate the - risk, and the mitigation cannot be completed immediately, a plan of action and - milestones entry is generated.
-findings from security assessments are responded to in accordance with - organizational risk tolerance;
- -findings from privacy assessments are responded to in accordance with - organizational risk tolerance;
- -findings from monitoring are responded to in accordance with organizational - risk tolerance;
- -findings from audits are responded to in accordance with organizational risk - tolerance.
- -Risk assessment policy
-assessment reports
-audit records/event logs
-system security plan
-privacy plan
-other relevant documents or records
-Organizational personnel with assessment and auditing responsibilities
-system/network administrators
-organizational personnel with security and privacy responsibilities
-Organizational processes for assessments and audits
-mechanisms/tools supporting and/or implementing assessments and auditing
-systems, system components, or system services to be analyzed for criticality - are defined;
-decision points in the system development life cycle when a criticality - analysis is to be performed are defined;
-Identify critical system components and functions by performing a criticality
- analysis for
Not all system components, functions, or services necessarily require significant - protections. For example, criticality analysis is a key tenet of supply chain - risk management and informs the prioritization of protection activities. The - identification of critical system components and functions considers applicable - laws, executive orders, regulations, directives, policies, standards, system - functionality requirements, system and component interfaces, and system and - component dependencies. Systems engineers conduct a functional decomposition of - a system to identify mission-critical functions and components. The functional - decomposition includes the identification of organizational missions supported - by the system, decomposition into the specific functions to perform those - missions, and traceability to the hardware, software, and firmware components - that implement those functions, including when the functions are shared by many - components within and external to the system.
-The operational environment of a system or a system component may impact the - criticality, including the connections to and dependencies on cyber-physical - systems, devices, system-of-systems, and outsourced IT services. System - components that allow unmediated access to critical system components or - functions are considered critical due to the inherent vulnerabilities that such - components create. Component and function criticality are assessed in terms of - the impact of a component or function failure on the organizational missions - that are supported by the system that contains the components and functions.
-Criticality analysis is performed when an architecture or design is being - developed, modified, or upgraded. If such analysis is performed early in the - system development life cycle, organizations may be able to modify the system - design to reduce the critical nature of these components and functions, such as - by adding redundancy or alternate paths into the system design. Criticality - analysis can also influence the protection measures required by development - contractors. In addition to criticality analysis for systems, system components, - and system services, criticality analysis of information is an important - consideration. Such analysis is conducted as part of security categorization in RA-2.
-critical system components and functions are identified by performing a
- criticality analysis for
Risk assessment policy
-assessment reports
-criticality analysis/finalized criticality for each component/subcomponent
-audit records/event logs
-analysis reports
-system security plan
-other relevant documents or records
-Organizational personnel with assessment and auditing responsibilities
-organizational personnel with criticality analysis responsibilities
-system/network administrators
-organizational personnel with security responsibilities
-Organizational processes for assessments and audits
-mechanisms/tools supporting and/or implementing assessments and auditing
-personnel or roles to whom the system and services acquisition policy is to - be disseminated is/are defined;
-personnel or roles to whom the system and services acquisition procedures are - to be disseminated is/are defined;
-an official to manage the system and services acquisition policy and - procedures is defined;
-the frequency at which the current system and services acquisition policy is - reviewed and updated is defined;
-events that would require the current system and services acquisition policy - to be reviewed and updated are defined;
-the frequency at which the current system and services acquisition procedures - are reviewed and updated is defined;
-events that would require the system and services acquisition procedures to - be reviewed and updated are defined;
-Develop, document, and disseminate to
Addresses purpose, scope, roles, responsibilities, management - commitment, coordination among organizational entities, and - compliance; and
-Is consistent with applicable laws, executive orders, directives, - regulations, policies, standards, and guidelines; and
-Procedures to facilitate the implementation of the system and services - acquisition policy and the associated system and services acquisition - controls;
-Designate an
Review and update the current system and services acquisition:
-Policy
Procedures
System and services acquisition policy and procedures address the controls in the - SA family that are implemented within systems and organizations. The risk - management strategy is an important factor in establishing such policies and - procedures. Policies and procedures contribute to security and privacy - assurance. Therefore, it is important that security and privacy programs - collaborate on the development of system and services acquisition policy and - procedures. Security and privacy program policies and procedures at the - organization level are preferable, in general, and may obviate the need for - mission- or system-specific policies and procedures. The policy can be included - as part of the general security and privacy policy or be represented by multiple - policies that reflect the complex nature of organizations. Procedures can be - established for security and privacy programs, for mission or business - processes, and for systems, if needed. Procedures describe how the policies or - controls are implemented and can be directed at the individual or role that is - the object of the procedure. Procedures can be documented in system security and - privacy plans or in one or more separate documents. Events that may precipitate - an update to system and services acquisition policy and procedures include - assessment or audit findings, security incidents or breaches, or changes in - laws, executive orders, directives, regulations, policies, standards, and - guidelines. Simply restating controls does not constitute an organizational - policy or procedure.
-a system and services acquisition policy is developed and documented;
- -the system and services acquisition policy is disseminated to
system and services acquisition procedures to facilitate the - implementation of the system and services acquisition policy and - associated system and services acquisition controls are developed and - documented;
- -the system and services acquisition procedures are disseminated to
the
the
the
the
the
the
the
the
the
the system and services acquisition policy is reviewed and updated
the current system and services acquisition policy is reviewed and
- updated following
the current system and services acquisition procedures are reviewed
- and updated
the current system and services acquisition procedures are reviewed
- and updated following
System and services acquisition policy
-system and services acquisition procedures
-supply chain risk management policy
-supply chain risk management procedures
-supply chain risk management plan
-system security plan
-privacy plan
-other relevant documents or records
-Organizational personnel with system and services acquisition - responsibilities
-organizational personnel with information security and privacy - responsibilities
-organizational personnel with supply chain risk management responsibilities
-Determine the high-level information security and privacy requirements for - the system or system service in mission and business process planning;
-Determine, document, and allocate the resources required to protect the - system or system service as part of the organizational capital planning and - investment control process; and
-Establish a discrete line item for information security and privacy in - organizational programming and budgeting documentation.
-Resource allocation for information security and privacy includes funding for - system and services acquisition, sustainment, and supply chain-related risks - throughout the system development life cycle.
-the high-level information security requirements for the system or system - service are determined in mission and business process planning;
- -the high-level privacy requirements for the system or system service are - determined in mission and business process planning;
- -the resources required to protect the system or system service are - determined and documented as part of the organizational capital planning - and investment control process;
- -the resources required to protect the system or system service are - allocated as part of the organizational capital planning and investment - control process;
- -a discrete line item for information security is established in - organizational programming and budgeting documentation;
- -a discrete line item for privacy is established in organizational - programming and budgeting documentation.
- -System and services acquisition policy
-system and services acquisition procedures
-system and services acquisition strategy and plans
-procedures addressing the allocation of resources to information security and - privacy requirements
-procedures addressing capital planning and investment control
-organizational programming and budgeting documentation
-system security plan
-privacy plan
-supply chain risk management policy
-other relevant documents or records
-Organizational personnel with capital planning, investment control, - organizational programming, and budgeting responsibilities
-organizational personnel with information security and privacy - responsibilities
-organizational personnel with supply chain risk management responsibilities
-Organizational processes for determining information security and privacy - requirements
-organizational processes for capital planning, programming, and budgeting
-mechanisms supporting and/or implementing organizational capital planning, - programming, and budgeting
-system development life cycle is defined;
-Acquire, develop, and manage the system using
Define and document information security and privacy roles and - responsibilities throughout the system development life cycle;
-Identify individuals having information security and privacy roles and - responsibilities; and
-Integrate the organizational information security and privacy risk management - process into system development life cycle activities.
-A system development life cycle process provides the foundation for the - successful development, implementation, and operation of organizational systems. - The integration of security and privacy considerations early in the system - development life cycle is a foundational principle of systems security - engineering and privacy engineering. To apply the required controls within the - system development life cycle requires a basic understanding of information - security and privacy, threats, vulnerabilities, adverse impacts, and risk to - critical mission and business functions. The security engineering principles in SA-8 help individuals properly design, code, and test - systems and system components. Organizations include qualified personnel (e.g., - senior agency information security officers, senior agency officials for - privacy, security and privacy architects, and security and privacy engineers) in - system development life cycle processes to ensure that established security and - privacy requirements are incorporated into organizational systems. Role-based - security and privacy training programs can ensure that individuals with key - security and privacy roles and responsibilities have the experience, skills, and - expertise to conduct assigned system development life cycle activities.
-The effective integration of security and privacy requirements into enterprise - architecture also helps to ensure that important security and privacy - considerations are addressed throughout the system life cycle and that those - considerations are directly related to organizational mission and business - processes. This process also facilitates the integration of the information - security and privacy architectures into the enterprise architecture, consistent - with the risk management strategy of the organization. Because the system - development life cycle involves multiple organizations, (e.g., external - suppliers, developers, integrators, service providers), acquisition and supply - chain risk management functions and controls play significant roles in the - effective management of the system during the life cycle.
-the system is acquired, developed, and managed using
the system is acquired, developed, and managed using
information security roles and responsibilities are defined and - documented throughout the system development life cycle;
- -privacy roles and responsibilities are defined and documented throughout - the system development life cycle;
- -individuals with information security roles and responsibilities are - identified;
- -individuals with privacy roles and responsibilities are identified;
- -organizational information security risk management processes are - integrated into system development life cycle activities;
- -organizational privacy risk management processes are integrated into - system development life cycle activities.
- -System and services acquisition policy
-system and services acquisition procedures
-procedures addressing the integration of information security and privacy and - supply chain risk management into the system development life cycle process
-system development life cycle documentation
-organizational risk management strategy
-information security and privacy risk management strategy documentation
-system security plan
-privacy plan
-privacy program plan
-enterprise architecture documentation
-role-based security and privacy training program documentation
-data mapping documentation
-other relevant documents or records
-Organizational personnel with information security and privacy - responsibilities
-organizational personnel with system life cycle development responsibilities
-organizational personnel with supply chain risk management responsibilities
-Organizational processes for defining and documenting the system development - life cycle
-organizational processes for identifying system development life cycle roles - and responsibilities
-organizational processes for integrating information security and privacy and - supply chain risk management into the system development life cycle
-mechanisms supporting and/or implementing the system development life cycle
-contract language is defined (if selected);
-Include the following requirements, descriptions, and criteria, explicitly or by
- reference, using
Security and privacy functional requirements;
-Strength of mechanism requirements;
-Security and privacy assurance requirements;
-Controls needed to satisfy the security and privacy requirements.
-Security and privacy documentation requirements;
-Requirements for protecting security and privacy documentation;
-Description of the system development environment and environment in which - the system is intended to operate;
-Allocation of responsibility or identification of parties responsible for - information security, privacy, and supply chain risk management; and
-Acceptance criteria.
-Security and privacy functional requirements are typically derived from the - high-level security and privacy requirements described in SA-2 - . The derived requirements include security and privacy capabilities, functions, - and mechanisms. Strength requirements associated with such capabilities, - functions, and mechanisms include degree of correctness, completeness, - resistance to tampering or bypass, and resistance to direct attack. Assurance - requirements include development processes, procedures, and methodologies as - well as the evidence from development and assessment activities that provide - grounds for confidence that the required functionality is implemented and - possesses the required strength of mechanism. SP 800-160-1 describes the - process of requirements engineering as part of the system development life - cycle.
-Controls can be viewed as descriptions of the safeguards and protection - capabilities appropriate for achieving the particular security and privacy - objectives of the organization and for reflecting the security and privacy - requirements of stakeholders. Controls are selected and implemented in order to - satisfy system requirements and include developer and organizational - responsibilities. Controls can include technical, administrative, and physical - aspects. In some cases, the selection and implementation of a control may - necessitate additional specification by the organization in the form of derived - requirements or instantiated control parameter values. The derived requirements - and control parameter values may be necessary to provide the appropriate level - of implementation detail for controls within the system development life cycle.
-Security and privacy documentation requirements address all stages of the system - development life cycle. Documentation provides user and administrator guidance - for the implementation and operation of controls. The level of detail required - in such documentation is based on the security categorization or classification - level of the system and the degree to which organizations depend on the - capabilities, functions, or mechanisms to meet risk response expectations. - Requirements can include mandated configuration settings that specify allowed - functions, ports, protocols, and services. Acceptance criteria for systems, - system components, and system services are defined in the same manner as the - criteria for any organizational acquisition or procurement.
-security functional requirements, descriptions, and criteria are included
- explicitly or by reference using
privacy functional requirements, descriptions, and criteria are included
- explicitly or by reference using
strength of mechanism requirements, descriptions, and criteria are included
- explicitly or by reference using
security assurance requirements, descriptions, and criteria are included
- explicitly or by reference using
privacy assurance requirements, descriptions, and criteria are included
- explicitly or by reference using
controls needed to satisfy the security requirements, descriptions, and
- criteria are included explicitly or by reference using
controls needed to satisfy the privacy requirements, descriptions, and
- criteria are included explicitly or by reference using
security documentation requirements, descriptions, and criteria are
- included explicitly or by reference using
privacy documentation requirements, descriptions, and criteria are
- included explicitly or by reference using
requirements for protecting security documentation, descriptions, and
- criteria are included explicitly or by reference using
requirements for protecting privacy documentation, descriptions, and
- criteria are included explicitly or by reference using
the description of the system development environment and environment in
- which the system is intended to operate, requirements, and criteria are
- included explicitly or by reference using
the allocation of responsibility or identification of parties responsible
- for information security requirements, descriptions, and criteria are
- included explicitly or by reference using
the allocation of responsibility or identification of parties responsible
- for privacy requirements, descriptions, and criteria are included
- explicitly or by reference using
the allocation of responsibility or identification of parties responsible
- for supply chain risk management requirements, descriptions, and
- criteria are included explicitly or by reference using
acceptance criteria requirements and descriptions are included explicitly or
- by reference using
System and services acquisition policy
-system and services acquisition procedures
-procedures addressing the integration of information security and privacy and - supply chain risk management into the acquisition process
-configuration management plan
-acquisition contracts for the system, system component, or system service
-system design documentation
-system security plan
-supply chain risk management plan
-privacy plan
-other relevant documents or records
-Organizational personnel with acquisition/contracting responsibilities
-organizational personnel with information security and privacy - responsibilities
-system/network administrators
-organizational personnel with supply chain risk management responsibilities
-Organizational processes for determining system security and privacy - functional, strength, and assurance requirements
-organizational processes for developing acquisition contracts
-mechanisms supporting and/or implementing acquisitions and the inclusion of - security and privacy requirements in contracts
-Require the developer of the system, system component, or system service to - provide a description of the functional properties of the controls to be - implemented.
-Functional properties of security and privacy controls describe the - functionality (i.e., security or privacy capability, functions, or - mechanisms) visible at the interfaces of the controls and specifically - exclude functionality and data structures internal to the operation of the - controls.
-the developer of the system, system component, or system service is required - to provide a description of the functional properties of the controls to be - implemented.
- -System and services acquisition policy
-system and services acquisition procedures
-procedures addressing the integration of security and privacy - requirements, descriptions, and criteria into the acquisition process
-solicitation documents
-acquisition documentation
-acquisition contracts for the system, system component, or system - services
-system security plan
-privacy plan
-other relevant documents or records
-Organizational personnel with acquisition/contracting responsibilities
-organizational personnel with information security and privacy - responsibilities
-system developers
-Organizational processes for determining system security functional - requirements
-organizational processes for developing acquisition contracts
-mechanisms supporting and/or implementing acquisitions and the inclusion - of security and privacy requirements in contracts
-design and implementation information is defined (if selected);
-level of detail is defined;
-Require the developer of the system, system component, or system service to
- provide design and implementation information for the controls that
- includes:
Organizations may require different levels of detail in the documentation for - the design and implementation of controls in organizational systems, system - components, or system services based on mission and business requirements, - requirements for resiliency and trustworthiness, and requirements for - analysis and testing. Systems can be partitioned into multiple subsystems. - Each subsystem within the system can contain one or more modules. The - high-level design for the system is expressed in terms of subsystems and the - interfaces between subsystems providing security-relevant functionality. The - low-level design for the system is expressed in terms of modules and the - interfaces between modules providing security-relevant functionality. Design - and implementation documentation can include manufacturer, version, serial - number, verification hash signature, software libraries used, date of - purchase or download, and the vendor or download source. Source code and - hardware schematics are referred to as the implementation representation of - the system.
-the developer of the system, system component, or system service is required
- to provide design and implementation information for the controls that
- includes using
System and services acquisition policy
-system and services acquisition procedures
-procedures addressing the integration of security requirements, - descriptions, and criteria into the acquisition process
-solicitation documents
-acquisition documentation
-acquisition contracts for the system, system components, or system - services
-design and implementation information for controls employed in the - system, system component, or system service
-system security plan
-other relevant documents or records
-Organizational personnel with acquisition/contracting responsibilities
-organizational personnel with the responsibility to determine system - security requirements
-system developers or service provider
-organizational personnel with information security responsibilities
-Organizational processes for determining the level of detail for system - design and controls
-organizational processes for developing acquisition contracts
-mechanisms supporting and/or implementing the development of system - design details
-Require the developer of the system, system component, or system service to - identify the functions, ports, protocols, and services intended for - organizational use.
-The identification of functions, ports, protocols, and services early in the - system development life cycle (e.g., during the initial requirements - definition and design stages) allows organizations to influence the design - of the system, system component, or system service. This early involvement - in the system development life cycle helps organizations avoid or minimize - the use of functions, ports, protocols, or services that pose unnecessarily - high risks and understand the trade-offs involved in blocking specific - ports, protocols, or services or requiring system service providers to do - so. Early identification of functions, ports, protocols, and services avoids - costly retrofitting of controls after the system, component, or system - service has been implemented. SA-9 describes the - requirements for external system services. Organizations identify which - functions, ports, protocols, and services are provided from external - sources.
-the developer of the system, system component, or system service is - required to identify the functions intended for organizational use;
- -the developer of the system, system component, or system service is - required to identify the ports intended for organizational use;
- -the developer of the system, system component, or system service is - required to identify the protocols intended for organizational use;
- -the developer of the system, system component, or system service is - required to identify the services intended for organizational use.
- -System and services acquisition policy
-procedures addressing the integration of security requirements, - descriptions, and criteria into the acquisition process
-system design documentation
-system documentation, including functions, ports, protocols, and services - intended for organizational use
-acquisition contracts for systems or services
-acquisition documentation
-solicitation documentation
-service level agreements
-organizational security requirements, descriptions, and criteria for - developers of systems, system components, and system services
-system security plan
-other relevant documents or records
-Organizational personnel with acquisition/contracting responsibilities
-organizational personnel with the responsibility for determining system - security requirements
-system/network administrators
-organizational personnel operating, using, and/or maintaining the system
-system developers
-organizational personnel with information security responsibilities
-Employ only information technology products on the FIPS 201-approved products - list for Personal Identity Verification (PIV) capability implemented within - organizational systems.
-Products on the FIPS 201-approved products list meet NIST requirements for - Personal Identity Verification (PIV) of Federal Employees and Contractors. - PIV cards are used for multi-factor authentication in systems and - organizations.
-only information technology products on the FIPS 201-approved products list - for the Personal Identity Verification (PIV) capability implemented within - organizational systems are employed.
- -Supply chain risk management plan
-system and services acquisition policy
-procedures addressing the integration of security requirements, - descriptions, and criteria into the acquisition process
-solicitation documentation
-acquisition documentation
-acquisition contracts for the system, system component, or system service
-service level agreements
-FIPS 201 approved products list
-system security plan
-other relevant documents or records
-Organizational personnel with acquisition/contracting responsibilities
-organizational personnel with the responsibility for determining system - security requirements
-organizational personnel with the responsibility for ensuring that only - FIPS 201- approved products are implemented
-organizational personnel with information security responsibilities
-Organizational processes for selecting and employing FIPS 201-approved - products
-actions to take when system, system component, or system service - documentation is either unavailable or nonexistent are defined;
-personnel or roles to distribute system documentation to is/are defined;
-Obtain or develop administrator documentation for the system, system - component, or system service that describes:
-Secure configuration, installation, and operation of the system, - component, or service;
-Effective use and maintenance of security and privacy functions and - mechanisms; and
-Known vulnerabilities regarding configuration and use of administrative - or privileged functions;
-Obtain or develop user documentation for the system, system component, or - system service that describes:
-User-accessible security and privacy functions and mechanisms and how to - effectively use those functions and mechanisms;
-Methods for user interaction, which enables individuals to use the - system, component, or service in a more secure manner and protect - individual privacy; and
-User responsibilities in maintaining the security of the system, - component, or service and privacy of individuals;
-Document attempts to obtain system, system component, or system service
- documentation when such documentation is either unavailable or nonexistent
- and take
Distribute documentation to
System documentation helps personnel understand the implementation and operation - of controls. Organizations consider establishing specific measures to determine - the quality and completeness of the content provided. System documentation may - be used to support the management of supply chain risk, incident response, and - other functions. Personnel or roles that require documentation include system - owners, system security officers, and system administrators. Attempts to obtain - documentation include contacting manufacturers or suppliers and conducting - web-based searches. The inability to obtain documentation may occur due to the - age of the system or component or the lack of support from developers and - contractors. When documentation cannot be obtained, organizations may need to - recreate the documentation if it is essential to the implementation or operation - of the controls. The protection provided for the documentation is commensurate - with the security category or classification of the system. Documentation that - addresses system vulnerabilities may require an increased level of protection. - Secure operation of the system includes initially starting the system and - resuming secure system operation after a lapse in system operation.
-administrator documentation for the system, system component, or - system service that describes the secure configuration of the - system, component, or service is obtained or developed;
- -administrator documentation for the system, system component, or - system service that describes the secure installation of the system, - component, or service is obtained or developed;
- -administrator documentation for the system, system component, or - system service that describes the secure operation of the system, - component, or service is obtained or developed;
- -administrator documentation for the system, system component, or - system service that describes the effective use of security - functions and mechanisms is obtained or developed;
- -administrator documentation for the system, system component, or - system service that describes the effective maintenance of security - functions and mechanisms is obtained or developed;
- -administrator documentation for the system, system component, or - system service that describes the effective use of privacy functions - and mechanisms is obtained or developed;
- -administrator documentation for the system, system component, or - system service that describes the effective maintenance of privacy - functions and mechanisms is obtained or developed;
- -administrator documentation for the system, system component, or - system service that describes known vulnerabilities regarding the - configuration of administrative or privileged functions is obtained - or developed;
- -administrator documentation for the system, system component, or - system service that describes known vulnerabilities regarding the - use of administrative or privileged functions is obtained or - developed;
- -user documentation for the system, system component, or system - service that describes user-accessible security functions and - mechanisms is obtained or developed;
- -user documentation for the system, system component, or system - service that describes how to effectively use those (user-accessible - security) functions and mechanisms is obtained or developed;
- -user documentation for the system, system component, or system - service that describes user-accessible privacy functions and - mechanisms is obtained or developed;
- -user documentation for the system, system component, or system - service that describes how to effectively use those (user-accessible - privacy) functions and mechanisms is obtained or developed;
- -user documentation for the system, system component, or system - service that describes methods for user interaction, which enable - individuals to use the system, component, or service in a more - secure manner is obtained or developed;
- -user documentation for the system, system component, or system - service that describes methods for user interaction, which enable - individuals to use the system, component, or service to protect - individual privacy is obtained or developed;
- -user documentation for the system, system component, or system - service that describes user responsibilities for maintaining the - security of the system, component, or service is obtained or - developed;
- -user documentation for the system, system component, or system - service that describes user responsibilities for maintaining the - privacy of individuals is obtained or developed;
- -attempts to obtain system, system component, or system service - documentation when such documentation is either unavailable or - nonexistent is documented;
- -after attempts to obtain system, system component, or system service
- documentation when such documentation is either unavailable or
- nonexistent,
documentation is distributed to
System and services acquisition policy
-system and services acquisition procedures
-procedures addressing system documentation
-system documentation, including administrator and user guides
-system design documentation
-records documenting attempts to obtain unavailable or nonexistent system - documentation
-list of actions to be taken in response to documented attempts to obtain - system, system component, or system service documentation
-risk management strategy documentation
-system security plan
-privacy plan
-privacy impact assessment
-privacy risk assessment documentation
-other relevant documents or records
-Organizational personnel with acquisition/contracting responsibilities
-organizational personnel with information security and privacy - responsibilities
-system administrators
-organizational personnel responsible for operating, using, and/or maintaining - the system
-system developers
-Organizational processes for obtaining, protecting, and distributing system - administrator and user documentation
-systems security engineering principles are defined;
-privacy engineering principles are defined;
-Apply the following systems security and privacy engineering principles in the
- specification, design, development, implementation, and modification of the
- system and system components:
Systems security and privacy engineering principles are closely related to and - implemented throughout the system development life cycle (see - SA-3 ). Organizations can apply systems security and privacy engineering - principles to new systems under development or to systems undergoing upgrades. - For existing systems, organizations apply systems security and privacy - engineering principles to system upgrades and modifications to the extent - feasible, given the current state of hardware, software, and firmware components - within those systems.
-The application of systems security and privacy engineering principles helps - organizations develop trustworthy, secure, and resilient systems and reduces the - susceptibility to disruptions, hazards, threats, and the creation of privacy - problems for individuals. Examples of system security engineering principles - include: developing layered protections; establishing security and privacy - policies, architecture, and controls as the foundation for design and - development; incorporating security and privacy requirements into the system - development life cycle; delineating physical and logical security boundaries; - ensuring that developers are trained on how to build secure software; tailoring - controls to meet organizational needs; and performing threat modeling to - identify use cases, threat agents, attack vectors and patterns, design patterns, - and compensating controls needed to mitigate risk.
-Organizations that apply systems security and privacy engineering concepts and - principles can facilitate the development of trustworthy, secure systems, system - components, and system services; reduce risk to acceptable levels; and make - informed risk management decisions. System security engineering principles can - also be used to protect against certain supply chain risks, including - incorporating tamper-resistant hardware into a design.
-System and services acquisition policy
-system and services acquisition procedures
-assessment and authorization procedures
-procedures addressing security and privacy engineering principles used in the - specification, design, development, implementation, and modification of the - system
-system design documentation
-security and privacy requirements and specifications for the system
-system security plan
-privacy plan
-privacy impact assessment
-privacy risk assessment documentation
-other relevant documents or records
-Organizational personnel with acquisition/contracting responsibilities
-organizational personnel with information security and privacy - responsibilities
-organizational personnel with system specification, design, development, - implementation, and modification responsibilities
-system developers
-Organizational processes for applying security and privacy engineering - principles in system specification, design, development, implementation, and - modification
-mechanisms supporting the application of security and privacy engineering - principles in system specification, design, development, implementation, and - modification
-controls to be employed by external system service providers are defined;
-processes, methods, and techniques employed to monitor control compliance by - external service providers are defined;
-Require that providers of external system services comply with organizational
- security and privacy requirements and employ the following controls:
Define and document organizational oversight and user roles and - responsibilities with regard to external system services; and
-Employ the following processes, methods, and techniques to monitor control
- compliance by external service providers on an ongoing basis:
External system services are provided by an external provider, and the - organization has no direct control over the implementation of the required - controls or the assessment of control effectiveness. Organizations establish - relationships with external service providers in a variety of ways, including - through business partnerships, contracts, interagency agreements, lines of - business arrangements, licensing agreements, joint ventures, and supply chain - exchanges. The responsibility for managing risks from the use of external system - services remains with authorizing officials. For services external to - organizations, a chain of trust requires that organizations establish and retain - a certain level of confidence that each provider in the consumer-provider - relationship provides adequate protection for the services rendered. The extent - and nature of this chain of trust vary based on relationships between - organizations and the external providers. Organizations document the basis for - the trust relationships so that the relationships can be monitored. External - system services documentation includes government, service providers, end user - security roles and responsibilities, and service-level agreements. Service-level - agreements define the expectations of performance for implemented controls, - describe measurable outcomes, and identify remedies and response requirements - for identified instances of noncompliance.
-providers of external system services comply with organizational security - requirements;
- -providers of external system services comply with organizational privacy - requirements;
- -providers of external system services employ
organizational oversight with regard to external system services are - defined and documented;
- -user roles and responsibilities with regard to external system services - are defined and documented;
- -System and services acquisition policy
-system and services acquisition procedures
-procedures addressing methods and techniques for monitoring control - compliance by external service providers of system services
-acquisition documentation
-contracts
-service level agreements
-interagency agreements
-licensing agreements
-list of organizational security and privacy requirements for external - provider services
-control assessment results or reports from external providers of system - services
-system security plan
-privacy plan
-supply chain risk management plan
-other relevant documents or records
-Organizational personnel with acquisition responsibilities
-external providers of system services
-organizational personnel with information security and privacy - responsibilities
-organizational personnel with supply chain risk management responsibilities
-Organizational processes for monitoring security and privacy control - compliance by external service providers on an ongoing basis
-mechanisms for monitoring security and privacy control compliance by external - service providers on an ongoing basis
-external system services that require the identification of functions, - ports, protocols, and other services are defined;
-Require providers of the following external system services to identify the
- functions, ports, protocols, and other services required for the use of such
- services:
Information from external service providers regarding the specific functions, - ports, protocols, and services used in the provision of such services can be - useful when the need arises to understand the trade-offs involved in - restricting certain functions and services or blocking certain ports and - protocols.
-providers of
System and services acquisition policy
-supply chain risk management policy and procedures
-procedures addressing external system services
-acquisition contracts for the system, system component, or system service
-acquisition documentation
-solicitation documentation
-service level agreements
-organizational security requirements and security specifications for - external service providers
-list of required functions, ports, protocols, and other services
-system security plan
-other relevant documents or records
-Organizational personnel with system and service acquisition - responsibilities
-organizational personnel with information security responsibilities
-system/network administrators
-external providers of system services
-configuration items under configuration management are defined;
-personnel to whom security flaws and flaw resolutions within the system, - component, or service are reported is/are defined;
-Require the developer of the system, system component, or system service to:
-Perform configuration management during system, component, or service
Document, manage, and control the integrity of changes to
Implement only organization-approved changes to the system, component, or - service;
-Document approved changes to the system, component, or service and the - potential security and privacy impacts of such changes; and
-Track security flaws and flaw resolution within the system, component, or
- service and report findings to
Organizations consider the quality and completeness of configuration management - activities conducted by developers as direct evidence of applying effective - security controls. Controls include protecting the master copies of material - used to generate security-relevant portions of the system hardware, software, - and firmware from unauthorized modification or destruction. Maintaining the - integrity of changes to the system, system component, or system service requires - strict configuration control throughout the system development life cycle to - track authorized changes and prevent unauthorized changes.
-The configuration items that are placed under configuration management include - the formal model; the functional, high-level, and low-level design - specifications; other design data; implementation documentation; source code and - hardware schematics; the current running version of the object code; tools for - comparing new versions of security-relevant hardware descriptions and source - code with previous versions; and test fixtures and documentation. Depending on - the mission and business needs of organizations and the nature of the - contractual relationships in place, developers may provide configuration - management support during the operations and maintenance stage of the system - development life cycle.
-the developer of the system, system component, or system service is required
- to perform configuration management during system, component, or service
the developer of the system, system component, or system service is
- required to document the integrity of changes to
the developer of the system, system component, or system service is
- required to manage the integrity of changes to
the developer of the system, system component, or system service is
- required to control the integrity of changes to
the developer of the system, system component, or system service is required - to implement only organization-approved changes to the system, component, or - service;
- -the developer of the system, system component, or system service is - required to document approved changes to the system, component, or - service;
- -the developer of the system, system component, or system service is - required to document the potential security impacts of approved changes;
- -the developer of the system, system component, or system service is - required to document the potential privacy impacts of approved changes;
- -the developer of the system, system component, or system service is - required to track security flaws within the system, component, or - service;
- -the developer of the system, system component, or system service is - required to track security flaw resolutions within the system, - component, or service;
- -the developer of the system, system component, or system service is
- required to report findings to
System and services acquisition policy
-procedures addressing system developer configuration management
-solicitation documentation
-acquisition documentation
-service level agreements
-acquisition contracts for the system, system component, or system service
-system developer configuration management plan
-security flaw and flaw resolution tracking records
-system change authorization records
-change control records
-configuration management records
-system security plan
-other relevant documents or records
-Organizational personnel with system and service acquisition responsibilities
-organizational personnel with information security responsibilities
-organizational personnel with configuration management responsibilities
-system developers
-Organizational processes for monitoring developer configuration management
-mechanisms supporting and/or implementing the monitoring of developer - configuration management
-frequency at which to conduct
depth and coverage of
Require the developer of the system, system component, or system service, at all - post-design stages of the system development life cycle, to:
-Develop and implement a plan for ongoing security and privacy control - assessments;
-Perform
Produce evidence of the execution of the assessment plan and the results of - the testing and evaluation;
-Implement a verifiable flaw remediation process; and
-Correct flaws identified during testing and evaluation.
-Developmental testing and evaluation confirms that the required controls are - implemented correctly, operating as intended, enforcing the desired security and - privacy policies, and meeting established security and privacy requirements. - Security properties of systems and the privacy of individuals may be affected by - the interconnection of system components or changes to those components. The - interconnections or changes—including upgrading or replacing applications, - operating systems, and firmware—may adversely affect previously implemented - controls. Ongoing assessment during development allows for additional types of - testing and evaluation that developers can conduct to reduce or eliminate - potential flaws. Testing custom software applications may require approaches - such as manual code review, security architecture review, and penetration - testing, as well as and static analysis, dynamic analysis, binary analysis, or a - hybrid of the three analysis approaches.
-Developers can use the analysis approaches, along with security instrumentation - and fuzzing, in a variety of tools and in source code reviews. The security and - privacy assessment plans include the specific activities that developers plan to - carry out, including the types of analyses, testing, evaluation, and reviews of - software and firmware components; the degree of rigor to be applied; the - frequency of the ongoing testing and evaluation; and the types of artifacts - produced during those processes. The depth of testing and evaluation refers to - the rigor and level of detail associated with the assessment process. The - coverage of testing and evaluation refers to the scope (i.e., number and type) - of the artifacts included in the assessment process. Contracts specify the - acceptance criteria for security and privacy assessment plans, flaw remediation - processes, and the evidence that the plans and processes have been diligently - applied. Methods for reviewing and protecting assessment plans, evidence, and - documentation are commensurate with the security category or classification - level of the system. Contracts may specify protection requirements for - documentation.
-the developer of the system, system component, or system service is - required at all post-design stages of the system development life cycle - to develop a plan for ongoing security assessments;
- -the developer of the system, system component, or system service is - required at all post-design stages of the system development life cycle - to implement a plan for ongoing security assessments;
- -the developer of the system, system component, or system service is - required at all post-design stages of the system development life cycle - to develop a plan for privacy assessments;
- -the developer of the system, system component, or system service is - required at all post-design stages of the system development life cycle - to implement a plan for ongoing privacy assessments;
- -the developer of the system, system component, or system service is required
- at all post-design stages of the system development life cycle to perform
the developer of the system, system component, or system service is - required at all post-design stages of the system development life cycle - to produce evidence of the execution of the assessment plan;
- -the developer of the system, system component, or system service is - required at all post-design stages of the system development life cycle - to produce the results of the testing and evaluation;
- -the developer of the system, system component, or system service is required - at all post-design stages of the system development life cycle to implement - a verifiable flaw remediation process;
- -the developer of the system, system component, or system service is required - at all post-design stages of the system development life cycle to correct - flaws identified during testing and evaluation.
- -System and services acquisition policy
-system and services acquisition procedures
-procedures addressing system developer security and privacy testing
-procedures addressing flaw remediation
-solicitation documentation
-acquisition documentation
-service level agreements
-acquisition contracts for the system, system component, or system service
-security and privacy architecture
-system design documentation
-system developer security and privacy assessment plans
-results of developer security and privacy assessments for the system, system - component, or system service
-security and privacy flaw and remediation tracking records
-system security plan
-privacy plan
-privacy impact assessment
-privacy risk assessment documentation
-other relevant documents or records
-Organizational personnel with system and service acquisition responsibilities
-organizational personnel with information security and privacy - responsibilities
-organizational personnel with developer security and privacy testing - responsibilities
-system developers
-Organizational processes for monitoring developer security testing and - evaluation
-mechanisms supporting and/or implementing the monitoring of developer - security and privacy testing and evaluation
-frequency at which to review the development process, standards, tools, tool - options, and tool configurations is defined;
-security requirements to be satisfied by the process, standards, tools, tool - options, and tool configurations are defined;
-privacy requirements to be satisfied by the process, standards, tools, tool - options, and tool configurations are defined;
-Require the developer of the system, system component, or system service to - follow a documented development process that:
-Explicitly addresses security and privacy requirements;
-Identifies the standards and tools used in the development process;
-Documents the specific tool options and tool configurations used in the - development process; and
-Documents, manages, and ensures the integrity of changes to the process - and/or tools used in development; and
-Review the development process, standards, tools, tool options, and tool
- configurations
Development tools include programming languages and computer-aided design - systems. Reviews of development processes include the use of maturity models to - determine the potential effectiveness of such processes. Maintaining the - integrity of changes to tools and processes facilitates effective supply chain - risk assessment and mitigation. Such integrity requires configuration control - throughout the system development life cycle to track authorized changes and - prevent unauthorized changes.
-the developer of the system, system component, or system service is - required to follow a documented development process that explicitly - addresses security requirements;
- -the developer of the system, system component, or system service is - required to follow a documented development process that explicitly - addresses privacy requirements;
- -the developer of the system, system component, or system service is - required to follow a documented development process that identifies - the standards used in the development process;
- -the developer of the system, system component, or system service is - required to follow a documented development process that identifies - the tools used in the development process;
- -the developer of the system, system component, or system service is - required to follow a documented development process that documents - the specific tool used in the development process;
- -the developer of the system, system component, or system service is - required to follow a documented development process that documents - the specific tool configurations used in the development process;
- -the developer of the system, system component, or system service is - required to follow a documented development process that documents, - manages, and ensures the integrity of changes to the process and/or - tools used in development;
- -the developer of the system, system component, or system service is
- required to follow a documented development process in which the
- development process, standards, tools, tool options, and tool
- configurations are reviewed
the developer of the system, system component, or system service is
- required to follow a documented development process in which the
- development process, standards, tools, tool options, and tool
- configurations are reviewed
System and services acquisition policy
-system and services acquisition procedures
-procedures addressing development process, standards, and tools
-procedures addressing the integration of security and privacy requirements - during the development process
-solicitation documentation
-acquisition documentation
-critical component inventory documentation
-service level agreements
-acquisition contracts for the system, system component, or system service
-system developer documentation listing tool options/configuration guides
-configuration management policy
-configuration management records
-documentation of development process reviews using maturity models
-change control records
-configuration control records
-documented reviews of the development process, standards, tools, and tool - options/configurations
-system security plan
-privacy plan
-privacy impact assessment
-privacy risk assessment documentation
-other relevant documents or records
-Organizational personnel with system and service acquisition responsibilities
-organizational personnel with information security and privacy - responsibilities
-system developer
-decision points in the system development life cycle are defined;
-the breadth of criticality analysis is defined;
-the depth of criticality analysis is defined;
-Require the developer of the system, system component, or system service to - perform a criticality analysis:
-At the following decision points in the system development life cycle:
At the following level of rigor:
Criticality analysis performed by the developer provides input to the - criticality analysis performed by organizations. Developer input is - essential to organizational criticality analysis because organizations may - not have access to detailed design documentation for system components that - are developed as commercial off-the-shelf products. Such design - documentation includes functional specifications, high-level designs, - low-level designs, source code, and hardware schematics. Criticality - analysis is important for organizational systems that are designated as high - value assets. High value assets can be moderate- or high-impact systems due - to heightened adversarial interest or potential adverse effects on the - federal enterprise. Developer input is especially important when - organizations conduct supply chain criticality analyses.
-the developer of the system, system component, or system service is
- required to perform a criticality analysis at
the developer of the system, system component, or system service is
- required to perform a criticality analysis at the following rigor
- level:
the developer of the system, system component, or system service is
- required to perform a criticality analysis at the following rigor
- level:
Supply chain risk management plan
-system and services acquisition policy
-procedures addressing development process, standards, and tools
-procedures addressing criticality analysis requirements for the system, - system component, or system service
-solicitation documentation
-acquisition documentation
-service level agreements
-acquisition contracts for the system, system component, or system service
-criticality analysis documentation
-business impact analysis documentation
-software development life cycle documentation
-system security plan
-other relevant documents or records
-Organizational personnel with system and service acquisition - responsibilities
-organizational personnel with information security responsibilities
-organizational personnel responsible for performing criticality analysis
-system developer
-organizational personnel with supply chain risk management - responsibilities
-Organizational processes for performing criticality analysis
-mechanisms supporting and/or implementing criticality analysis
-support from external providers is defined (if selected);
-Replace system components when support for the components is no longer - available from the developer, vendor, or manufacturer; or
-Provide the following options for alternative sources for continued support
- for unsupported components
Support for system components includes software patches, firmware updates, - replacement parts, and maintenance contracts. An example of unsupported - components includes when vendors no longer provide critical software patches or - product updates, which can result in an opportunity for adversaries to exploit - weaknesses in the installed components. Exceptions to replacing unsupported - system components include systems that provide critical mission or business - capabilities where newer technologies are not available or where the systems are - so isolated that installing replacement components is not an option.
-Alternative sources for support address the need to provide continued support for - system components that are no longer supported by the original manufacturers, - developers, or vendors when such components remain essential to organizational - mission and business functions. If necessary, organizations can establish - in-house support by developing customized patches for critical software - components or, alternatively, obtain the services of external providers who - provide ongoing support for the designated unsupported components through - contractual relationships. Such contractual relationships can include - open-source software value-added vendors. The increased risk of using - unsupported system components can be mitigated, for example, by prohibiting the - connection of such components to public or uncontrolled networks, or - implementing other forms of isolation.
-system components are replaced when support for the components is no longer - available from the developer, vendor, or manufacturer;
- -System and services acquisition policy
-procedures addressing the replacement or continued use of unsupported system - components
-documented evidence of replacing unsupported system components
-documented approvals (including justification) for the continued use of - unsupported system components
-system security plan
-supply chain risk management plan
-other relevant documents or records
-Organizational personnel with system and service acquisition responsibilities
-organizational personnel with information security responsibilities
-organizational personnel with the responsibility for the system development - life cycle
-organizational personnel responsible for component replacement
-Organizational processes for replacing unsupported system components
-mechanisms supporting and/or implementing the replacement of unsupported - system components
-personnel or roles to whom the system and communications protection policy is - to be disseminated is/are defined;
-personnel or roles to whom the system and communications protection - procedures are to be disseminated is/are defined;
-an official to manage the system and communications protection policy and - procedures is defined;
-the frequency at which the current system and communications protection - policy is reviewed and updated is defined;
-events that would require the current system and communications protection - policy to be reviewed and updated are defined;
-the frequency at which the current system and communications protection - procedures are reviewed and updated is defined;
-events that would require the system and communications protection procedures - to be reviewed and updated are defined;
-Develop, document, and disseminate to
Addresses purpose, scope, roles, responsibilities, management - commitment, coordination among organizational entities, and - compliance; and
-Is consistent with applicable laws, executive orders, directives, - regulations, policies, standards, and guidelines; and
-Procedures to facilitate the implementation of the system and - communications protection policy and the associated system and - communications protection controls;
-Designate an
Review and update the current system and communications protection:
-Policy
Procedures
System and communications protection policy and procedures address the controls - in the SC family that are implemented within systems and organizations. The risk - management strategy is an important factor in establishing such policies and - procedures. Policies and procedures contribute to security and privacy - assurance. Therefore, it is important that security and privacy programs - collaborate on the development of system and communications protection policy - and procedures. Security and privacy program policies and procedures at the - organization level are preferable, in general, and may obviate the need for - mission- or system-specific policies and procedures. The policy can be included - as part of the general security and privacy policy or be represented by multiple - policies that reflect the complex nature of organizations. Procedures can be - established for security and privacy programs, for mission or business - processes, and for systems, if needed. Procedures describe how the policies or - controls are implemented and can be directed at the individual or role that is - the object of the procedure. Procedures can be documented in system security and - privacy plans or in one or more separate documents. Events that may precipitate - an update to system and communications protection policy and procedures include - assessment or audit findings, security incidents or breaches, or changes in - applicable laws, executive orders, directives, regulations, policies, standards, - and guidelines. Simply restating controls does not constitute an organizational - policy or procedure.
-a system and communications protection policy is developed and - documented;
- -the system and communications protection policy is disseminated to
system and communications protection procedures to facilitate the - implementation of the system and communications protection policy and - associated system and communications protection controls are developed - and documented;
- -the system and communications protection procedures are disseminated to
the
the
the
the
the
the
the
the
the
the current system and communications protection policy is reviewed
- and updated
the current system and communications protection policy is reviewed
- and updated following
the current system and communications protection procedures are
- reviewed and updated
the current system and communications protection procedures are
- reviewed and updated following
System and communications protection policy
-system and communications protection procedures
-system security plan
-privacy plan
-risk management strategy documentation
-audit findings
-other relevant documents or records
-Organizational personnel with system and communications protection - responsibilities
-organizational personnel with information security and privacy - responsibilities
-Separate user functionality, including user interface services, from system - management functionality.
-System management functionality includes functions that are necessary to - administer databases, network components, workstations, or servers. These - functions typically require privileged user access. The separation of user - functions from system management functions is physical or logical. Organizations - may separate system management functions from user functions by using different - computers, instances of operating systems, central processing units, or network - addresses; by employing virtualization techniques; or some combination of these - or other methods. Separation of system management functions from user functions - includes web administrative interfaces that employ separate authentication - methods for users of any other system resources. Separation of system and user - functions may include isolating administrative interfaces on different domains - and with additional access controls. The separation of system and user - functionality can be achieved by applying the systems security engineering - design principles in SA-8 , including - SA-8(1), - SA-8(3), - SA-8(4), - SA-8(10), - SA-8(12), - SA-8(13), - SA-8(14) , and - SA-8(18).
-user functionality, including user interface services, is separated from system - management functionality.
- -System and communications protection policy
-procedures addressing application partitioning
-system design documentation
-system configuration settings and associated documentation
-system audit records
-system security plan
-other relevant documents or records
-System/network administrators
-organizational personnel with information security responsibilities
-system developer
-Separation of user functionality from system management functionality
-Prevent unauthorized and unintended information transfer via shared system - resources.
-Preventing unauthorized and unintended information transfer via shared system - resources stops information produced by the actions of prior users or roles (or - the actions of processes acting on behalf of prior users or roles) from being - available to current users or roles (or current processes acting on behalf of - current users or roles) that obtain access to shared system resources after - those resources have been released back to the system. Information in shared - system resources also applies to encrypted representations of information. In - other contexts, control of information in shared system resources is referred to - as object reuse and residual information protection. Information in shared - system resources does not address information remanence, which refers to the - residual representation of data that has been nominally deleted; covert channels - (including storage and timing channels), where shared system resources are - manipulated to violate information flow restrictions; or components within - systems for which there are only single users or roles.
-unauthorized information transfer via shared system resources is prevented;
- -unintended information transfer via shared system resources is prevented.
- -System and communications protection policy
-procedures addressing information protection in shared system resources
-system design documentation
-system configuration settings and associated documentation
-system audit records
-system security plan
-other relevant documents or records
-System/network administrators
-organizational personnel with information security responsibilities
-system developer
-Mechanisms preventing the unauthorized and unintended transfer of information - via shared system resources
-types of denial-of-service events to be protected against or limited are - defined;
-controls to achieve the denial-of-service objective by type of - denial-of-service event are defined;
-Employ the following controls to achieve the denial-of-service objective:
Denial-of-service events may occur due to a variety of internal and external - causes, such as an attack by an adversary or a lack of planning to support - organizational needs with respect to capacity and bandwidth. Such attacks can - occur across a wide range of network protocols (e.g., IPv4, IPv6). A variety of - technologies are available to limit or eliminate the origination and effects of - denial-of-service events. For example, boundary protection devices can filter - certain types of packets to protect system components on internal networks from - being directly affected by or the source of denial-of-service attacks. Employing - increased network capacity and bandwidth combined with service redundancy also - reduces the susceptibility to denial-of-service events.
-the effects of
System and communications protection policy
-procedures addressing denial-of-service protection
-system design documentation
-list of denial-of-service attacks requiring employment of security safeguards - to protect against or limit effects of such attacks
-list of security safeguards protecting against or limiting the effects of - denial-of-service attacks
-system configuration settings and associated documentation
-system audit records
-system security plan
-other relevant documents or records
-System/network administrators
-organizational personnel with information security responsibilities
-organizational personnel with incident response responsibilities
-system developer
-Mechanisms protecting against or limiting the effects of denial-of-service - attacks
-Monitor and control communications at the external managed interfaces to the - system and at key internal managed interfaces within the system;
-Implement subnetworks for publicly accessible system components that are
Connect to external networks or systems only through managed interfaces - consisting of boundary protection devices arranged in accordance with an - organizational security and privacy architecture.
-Managed interfaces include gateways, routers, firewalls, guards, network-based - malicious code analysis, virtualization systems, or encrypted tunnels - implemented within a security architecture. Subnetworks that are physically or - logically separated from internal networks are referred to as demilitarized - zones or DMZs. Restricting or prohibiting interfaces within organizational - systems includes restricting external web traffic to designated web servers - within managed interfaces, prohibiting external traffic that appears to be - spoofing internal addresses, and prohibiting internal traffic that appears to be - spoofing external addresses. SP - 800-189 provides additional information on source address validation - techniques to prevent ingress and egress of traffic with spoofed addresses. - Commercial telecommunications services are provided by network components and - consolidated management systems shared by customers. These services may also - include third party-provided access lines and other service elements. Such - services may represent sources of increased risk despite contract security - provisions. Boundary protection may be implemented as a common control for all - or part of an organizational network such that the boundary to be protected is - greater than a system-specific boundary (i.e., an authorization boundary).
-communications at external managed interfaces to the system are - monitored;
- -communications at external managed interfaces to the system are - controlled;
- -communications at key internal managed interfaces within the system are - monitored;
- -communications at key internal managed interfaces within the system are - controlled;
- -subnetworks for publicly accessible system components are
external networks or systems are only connected to through managed interfaces - consisting of boundary protection devices arranged in accordance with an - organizational security and privacy architecture.
- -System and communications protection policy
-procedures addressing boundary protection
-list of key internal boundaries of the system
-system design documentation
-boundary protection hardware and software
-system configuration settings and associated documentation
-enterprise security architecture documentation
-system audit records
-system security plan
-other relevant documents or records
-System/network administrators
-organizational personnel with information security responsibilities
-system developer
-organizational personnel with boundary protection responsibilities
-Mechanisms implementing boundary protection capabilities
-Limit the number of external network connections to the system.
-Limiting the number of external network connections facilitates monitoring of - inbound and outbound communications traffic. The Trusted Internet Connection DHS TIC initiative is - an example of a federal guideline that requires limits on the number of - external network connections. Limiting the number of external network - connections to the system is important during transition periods from older - to newer technologies (e.g., transitioning from IPv4 to IPv6 network - protocols). Such transitions may require implementing the older and newer - technologies simultaneously during the transition period and thus increase - the number of access points to the system.
-the number of external network connections to the system is limited.
- -System and communications protection policy
-procedures addressing boundary protection
-system design documentation
-boundary protection hardware and software
-system architecture and configuration documentation
-system configuration settings and associated documentation
-communications and network traffic monitoring logs
-system audit records
-system security plan
-other relevant documents or records
-System/network administrators
-organizational personnel with information security responsibilities
-organizational personnel with boundary protection responsibilities
-Mechanisms implementing boundary protection capabilities
-mechanisms limiting the number of external network connections to the - system
-the frequency at which to review exceptions to traffic flow policy is - defined;
-Implement a managed interface for each external telecommunication - service;
-Establish a traffic flow policy for each managed interface;
-Protect the confidentiality and integrity of the information being - transmitted across each interface;
-Document each exception to the traffic flow policy with a supporting - mission or business need and duration of that need;
-Review exceptions to the traffic flow policy
Prevent unauthorized exchange of control plane traffic with external - networks;
-Publish information to enable remote networks to detect unauthorized - control plane traffic from internal networks; and
-Filter unauthorized control plane traffic from external networks.
-External telecommunications services can provide data and/or voice - communications services. Examples of control plane traffic include Border - Gateway Protocol (BGP) routing, Domain Name System (DNS), and management - protocols. See SP 800-189 - for additional information on the use of the resource public key - infrastructure (RPKI) to protect BGP routes and detect unauthorized BGP - announcements.
-a managed interface is implemented for each external telecommunication - service;
- -a traffic flow policy is established for each managed interface;
- -the confidentiality of the information being transmitted across each - interface is protected;
- -the integrity of the information being transmitted across each - interface is protected;
- -each exception to the traffic flow policy is documented with a supporting - mission or business need and duration of that need;
- -exceptions to the traffic flow policy are reviewed
exceptions to the traffic flow policy that are no longer supported by - an explicit mission or business need are removed;
- -unauthorized exchanges of control plan traffic with external networks are - prevented;
- -information is published to enable remote networks to detect unauthorized - control plane traffic from internal networks;
- -unauthorized control plane traffic is filtered from external networks.
- -System and communications protection policy
-traffic flow policy
-information flow control policy
-procedures addressing boundary protection
-system security architecture
-system design documentation
-boundary protection hardware and software
-system architecture and configuration documentation
-system configuration settings and associated documentation
-records of traffic flow policy exceptions
-system audit records
-system security plan
-other relevant documents or records
-System/network administrators
-organizational personnel with information security responsibilities
-organizational personnel with boundary protection responsibilities
-Organizational processes for documenting and reviewing exceptions to the - traffic flow policy
-organizational processes for removing exceptions to the traffic flow - policy
-mechanisms implementing boundary protection capabilities
-managed interfaces implementing traffic flow policy
-systems for which network communications traffic is denied by default and - network communications traffic is allowed by exception are defined (if - selected).
-Deny network communications traffic by default and allow network
- communications traffic by exception
Denying by default and allowing by exception applies to inbound and outbound - network communications traffic. A deny-all, permit-by-exception network - communications traffic policy ensures that only those system connections - that are essential and approved are allowed. Deny by default, allow by - exception also applies to a system that is connected to an external system.
-network communications traffic is denied by default
network communications traffic is allowed by exception
System and communications protection policy
-procedures addressing boundary protection
-system design documentation
-system configuration settings and associated documentation
-system audit records
-system security plan
-other relevant documents or records
-System/network administrators
-organizational personnel with information security responsibilities
-system developer
-organizational personnel with boundary protection responsibilities
-Mechanisms implementing traffic management at managed interfaces
-safeguards to securely provision split tunneling are defined;
-Prevent split tunneling for remote devices connecting to organizational
- systems unless the split tunnel is securely provisioned using
Split tunneling is the process of allowing a remote user or device to - establish a non-remote connection with a system and simultaneously - communicate via some other connection to a resource in an external network. - This method of network access enables a user to access remote devices and - simultaneously, access uncontrolled networks. Split tunneling might be - desirable by remote users to communicate with local system resources, such - as printers or file servers. However, split tunneling can facilitate - unauthorized external connections, making the system vulnerable to attack - and to exfiltration of organizational information. Split tunneling can be - prevented by disabling configuration settings that allow such capability in - remote devices and by preventing those configuration settings from being - configurable by users. Prevention can also be achieved by the detection of - split tunneling (or of configuration settings that allow split tunneling) in - the remote device, and by prohibiting the connection if the remote device is - using split tunneling. A virtual private network (VPN) can be used to - securely provision a split tunnel. A securely provisioned VPN includes - locking connectivity to exclusive, managed, and named environments, or to a - specific set of pre-approved addresses, without user control.
-split tunneling is prevented for remote devices connecting to organizational
- systems unless the split tunnel is securely provisioned using
System and communications protection policy
-procedures addressing boundary protection
-system design documentation
-system hardware and software
-system architecture
-system configuration settings and associated documentation
-system audit records
-system security plan
-other relevant documents or records
-System/network administrators
-organizational personnel with information security responsibilities
-system developer
-organizational personnel with boundary protection responsibilities
-Mechanisms implementing boundary protection capabilities
-mechanisms supporting/restricting non-remote connections
-internal communications traffic to be routed to external networks is - defined;
-external networks to which internal communications traffic is to be - routed are defined;
-Route
External networks are networks outside of organizational control. A proxy
- server is a server (i.e., system or application) that acts as an
- intermediary for clients requesting system resources from non-organizational
- or other organizational servers. System resources that may be requested
- include files, connections, web pages, or services. Client requests
- established through a connection to a proxy server are assessed to manage
- complexity and provide additional protection by limiting direct
- connectivity. Web content filtering devices are one of the most common proxy
- servers that provide access to the Internet. Proxy servers can support the
- logging of Transmission Control Protocol sessions and the blocking of
- specific Uniform Resource Locators, Internet Protocol addresses, and domain
- names. Web proxies can be configured with organization-defined lists of
- authorized and unauthorized websites. Note that proxy servers may inhibit
- the use of virtual private networks (VPNs) and create the potential for
- man-in-the-middle
attacks (depending on the implementation).
System and communications protection policy
-procedures addressing boundary protection
-system design documentation
-system hardware and software
-system architecture
-system configuration settings and associated documentation
-system audit records
-system security plan
-other relevant documents or records
-System/network administrators
-organizational personnel with information security responsibilities
-system developer
-organizational personnel with boundary protection responsibilities
-Mechanisms implementing traffic management through authenticated proxy - servers at managed interfaces
-Protect the
Protecting the confidentiality and integrity of transmitted information applies - to internal and external networks as well as any system components that can - transmit information, including servers, notebook computers, desktop computers, - mobile devices, printers, copiers, scanners, facsimile machines, and radios. - Unprotected communication paths are exposed to the possibility of interception - and modification. Protecting the confidentiality and integrity of information - can be accomplished by physical or logical means. Physical protection can be - achieved by using protected distribution systems. A protected distribution - system is a wireline or fiber-optics telecommunications system that includes - terminals and adequate electromagnetic, acoustical, electrical, and physical - controls to permit its use for the unencrypted transmission of classified - information. Logical protection can be achieved by employing encryption - techniques.
-Organizations that rely on commercial providers who offer transmission services - as commodity services rather than as fully dedicated services may find it - difficult to obtain the necessary assurances regarding the implementation of - needed controls for transmission confidentiality and integrity. In such - situations, organizations determine what types of confidentiality or integrity - services are available in standard, commercial telecommunications service - packages. If it is not feasible to obtain the necessary controls and assurances - of control effectiveness through appropriate contracting vehicles, organizations - can implement appropriate compensating controls.
-the
System and communications protection policy
-procedures addressing transmission confidentiality and integrity
-system design documentation
-system configuration settings and associated documentation
-system audit records
-system security plan
-other relevant documents or records
-System/network administrators
-organizational personnel with information security responsibilities
-system developer
-Mechanisms supporting and/or implementing transmission confidentiality and/or - integrity
-Implement cryptographic mechanisms to
Encryption protects information from unauthorized disclosure and modification - during transmission. Cryptographic mechanisms that protect the - confidentiality and integrity of information during transmission include TLS - and IPSec. Cryptographic mechanisms used to protect information integrity - include cryptographic hash functions that have applications in digital - signatures, checksums, and message authentication codes.
-cryptographic mechanisms are implemented to
System and communications protection policy
-procedures addressing transmission confidentiality and integrity
-system design documentation
-system configuration settings and associated documentation
-system audit records
-system security plan
-other relevant documents or records
-System/network administrators
-organizational personnel with information security responsibilities
-system developer
-Cryptographic mechanisms supporting and/or implementing transmission - confidentiality and/or integrity
-mechanisms supporting and/or implementing alternative physical safeguards
-organizational processes for defining and implementing alternative - physical safeguards
-a time period of inactivity after which the system terminates a network - connection associated with a communication session is defined;
-Terminate the network connection associated with a communications session at the
- end of the session or after
Network disconnect applies to internal and external networks. Terminating network - connections associated with specific communications sessions includes - de-allocating TCP/IP address or port pairs at the operating system level and - de-allocating the networking assignments at the application level if multiple - application sessions are using a single operating system-level network - connection. Periods of inactivity may be established by organizations and - include time periods by type of network access or for specific network accesses.
-the network connection associated with a communication session is terminated at
- the end of the session or after
System and communications protection policy
-procedures addressing network disconnect
-system design documentation
-security plan
-system configuration settings and associated documentation
-system audit records
-system security plan
-other relevant documents or records
-System/network administrators
-organizational personnel with information security responsibilities
-system developer
-Mechanisms supporting and/or implementing a network disconnect capability
-requirements for key generation, distribution, storage, access, and - destruction are defined;
-Establish and manage cryptographic keys when cryptography is employed within the
- system in accordance with the following key management requirements:
Cryptographic key management and establishment can be performed using manual - procedures or automated mechanisms with supporting manual procedures. - Organizations define key management requirements in accordance with applicable - laws, executive orders, directives, regulations, policies, standards, and - guidelines and specify appropriate options, parameters, and levels. - Organizations manage trust stores to ensure that only approved trust anchors are - part of such trust stores. This includes certificates with visibility external - to organizational systems and certificates related to the internal operations of - systems. NIST CMVP and NIST CAVP provide - additional information on validated cryptographic modules and algorithms that - can be used in cryptographic key management and establishment.
-cryptographic keys are established when cryptography is employed within the
- system in accordance with
cryptographic keys are managed when cryptography is employed within the
- system in accordance with
System and communications protection policy
-procedures addressing cryptographic key establishment and management
-system design documentation
-cryptographic mechanisms
-system configuration settings and associated documentation
-system audit records
-system security plan
-other relevant documents or records
-System/network administrators
-organizational personnel with information security responsibilities
-organizational personnel with responsibilities for cryptographic key - establishment and/or management
-Mechanisms supporting and/or implementing cryptographic key establishment and - management
-cryptographic uses are defined;
-types of cryptography for each specified cryptographic use are defined;
-Determine the
Implement the following types of cryptography required for each specified
- cryptographic use:
Cryptography can be employed to support a variety of security solutions, - including the protection of classified information and controlled unclassified - information, the provision and implementation of digital signatures, and the - enforcement of information separation when authorized individuals have the - necessary clearances but lack the necessary formal access approvals. - Cryptography can also be used to support random number and hash generation. - Generally applicable cryptographic standards include FIPS-validated cryptography - and NSA-approved cryptography. For example, organizations that need to protect - classified information may specify the use of NSA-approved cryptography. - Organizations that need to provision and implement digital signatures may - specify the use of FIPS-validated cryptography. Cryptography is implemented in - accordance with applicable laws, executive orders, directives, regulations, - policies, standards, and guidelines.
-System and communications protection policy
-procedures addressing cryptographic protection
-system design documentation
-system configuration settings and associated documentation
-cryptographic module validation certificates
-list of FIPS-validated cryptographic modules
-system audit records
-system security plan
-other relevant documents or records
-System/network administrators
-organizational personnel with information security responsibilities
-system developer
-organizational personnel with responsibilities for cryptographic protection
-Mechanisms supporting and/or implementing cryptographic protection
-exceptions where remote activation is to be allowed are defined;
-Prohibit remote activation of collaborative computing devices and
- applications with the following exceptions:
Provide an explicit indication of use to users physically present at the - devices.
-Collaborative computing devices and applications include remote meeting devices - and applications, networked white boards, cameras, and microphones. The explicit - indication of use includes signals to users when collaborative computing devices - and applications are activated.
-remote activation of collaborative computing devices and applications is
- prohibited except
an explicit indication of use is provided to users physically present at the - devices.
- -System and communications protection policy
-procedures addressing collaborative computing
-access control policy and procedures
-system design documentation
-system configuration settings and associated documentation
-system audit records
-system security plan
-other relevant documents or records
-System/network administrators
-organizational personnel with information security responsibilities
-system developer
-organizational personnel with responsibilities for managing collaborative - computing devices
-Mechanisms supporting and/or implementing the management of remote activation - of collaborative computing devices
-mechanisms providing an indication of use of collaborative computing devices
-a certificate policy for issuing public key certificates is defined;
-Issue public key certificates under an
Include only approved trust anchors in trust stores or certificate stores - managed by the organization.
-Public key infrastructure (PKI) certificates are certificates with visibility - external to organizational systems and certificates related to the internal - operations of systems, such as application-specific time services. In - cryptographic systems with a hierarchical structure, a trust anchor is an - authoritative source (i.e., a certificate authority) for which trust is assumed - and not derived. A root certificate for a PKI system is an example of a trust - anchor. A trust store or certificate store maintains a list of trusted root - certificates.
-public key certificates are issued under
only approved trust anchors are included in trust stores or certificate - stores managed by the organization.
- -System and communications protection policy
-procedures addressing public key infrastructure certificates
-public key certificate policy or policies
-public key issuing process
-system security plan
-other relevant documents or records
-System/network administrators
-organizational personnel with information security responsibilities
-organizational personnel with responsibilities for issuing public key - certificates
-service providers
-Mechanisms supporting and/or implementing the management of public key - infrastructure certificates
-Define acceptable and unacceptable mobile code and mobile code technologies; - and
-Authorize, monitor, and control the use of mobile code within the system.
-Mobile code includes any program, application, or content that can be transmitted - across a network (e.g., embedded in an email, document, or website) and executed - on a remote system. Decisions regarding the use of mobile code within - organizational systems are based on the potential for the code to cause damage - to the systems if used maliciously. Mobile code technologies include Java - applets, JavaScript, HTML5, WebGL, and VBScript. Usage restrictions and - implementation guidelines apply to both the selection and use of mobile code - installed on servers and mobile code downloaded and executed on individual - workstations and devices, including notebook computers and smart phones. Mobile - code policy and procedures address specific actions taken to prevent the - development, acquisition, and introduction of unacceptable mobile code within - organizational systems, including requiring mobile code to be digitally signed - by a trusted source.
-acceptable mobile code is defined;
- -unacceptable mobile code is defined;
- -acceptable mobile code technologies are defined;
- -unacceptable mobile code technologies are defined;
- -the use of mobile code is authorized within the system;
- -the use of mobile code is monitored within the system;
- -the use of mobile code is controlled within the system.
- -System and communications protection policy
-procedures addressing mobile code
-mobile code implementation policy and procedures
-list of acceptable mobile code and mobile code technologies
-list of unacceptable mobile code and mobile technologies
-authorization records
-system monitoring records
-system audit records
-system security plan
-other relevant documents or records
-System/network administrators
-organizational personnel with information security responsibilities
-organizational personnel with responsibilities for managing mobile code
-Organizational process for authorizing, monitoring, and controlling mobile - code
-mechanisms supporting and/or implementing the management of mobile code
-mechanisms supporting and/or implementing the monitoring of mobile code
-Provide additional data origin authentication and integrity verification - artifacts along with the authoritative name resolution data the system - returns in response to external name/address resolution queries; and
-Provide the means to indicate the security status of child zones and (if the - child supports secure resolution services) to enable verification of a chain - of trust among parent and child domains, when operating as part of a - distributed, hierarchical namespace.
-Providing authoritative source information enables external clients, including - remote Internet clients, to obtain origin authentication and integrity - verification assurances for the host/service name to network address resolution - information obtained through the service. Systems that provide name and address - resolution services include domain name system (DNS) servers. Additional - artifacts include DNS Security Extensions (DNSSEC) digital signatures and - cryptographic keys. Authoritative data includes DNS resource records. The means - for indicating the security status of child zones include the use of delegation - signer resource records in the DNS. Systems that use technologies other than the - DNS to map between host and service names and network addresses provide other - means to assure the authenticity and integrity of response data.
-additional data origin authentication is provided along with the - authoritative name resolution data that the system returns in response - to external name/address resolution queries;
- -integrity verification artifacts are provided along with the - authoritative name resolution data that the system returns in response - to external name/address resolution queries;
- -the means to indicate the security status of child zones (and if the - child supports secure resolution services) is provided when operating as - part of a distributed, hierarchical namespace;
- -the means to enable verification of a chain of trust among parent and - child domains when operating as part of a distributed, hierarchical - namespace is provided.
- -System and communications protection policy
-procedures addressing secure name/address resolution services (authoritative - source)
-system design documentation
-system configuration settings and associated documentation
-system security plan
-other relevant documents or records
-System/network administrators
-organizational personnel with information security responsibilities
-organizational personnel with responsibilities for managing DNS
-Mechanisms supporting and/or implementing secure name/address resolution - services
-Request and perform data origin authentication and data integrity verification on - the name/address resolution responses the system receives from authoritative - sources.
-Each client of name resolution services either performs this validation on its - own or has authenticated channels to trusted validation providers. Systems that - provide name and address resolution services for local clients include recursive - resolving or caching domain name system (DNS) servers. DNS client resolvers - either perform validation of DNSSEC signatures, or clients use authenticated - channels to recursive resolvers that perform such validations. Systems that use - technologies other than the DNS to map between host and service names and - network addresses provide some other means to enable clients to verify the - authenticity and integrity of response data.
-data origin authentication is requested for the name/address resolution - responses that the system receives from authoritative sources;
- -data origin authentication is performed on the name/address resolution - responses that the system receives from authoritative sources;
- -data integrity verification is requested for the name/address resolution - responses that the system receives from authoritative sources;
- -data integrity verification is performed on the name/address resolution - responses that the system receives from authoritative sources.
- -System and communications protection policy
-procedures addressing secure name/address resolution services (recursive or - caching resolver)
-system design documentation
-system configuration settings and associated documentation
-system audit records
-system security plan
-other relevant documents or records
-System/network administrators
-organizational personnel with information security responsibilities
-organizational personnel with responsibilities for managing DNS
-Mechanisms supporting and/or implementing data origin authentication and data - integrity verification for name/address resolution services
-Ensure the systems that collectively provide name/address resolution service for - an organization are fault-tolerant and implement internal and external role - separation.
-Systems that provide name and address resolution services include domain name - system (DNS) servers. To eliminate single points of failure in systems and - enhance redundancy, organizations employ at least two authoritative domain name - system servers—one configured as the primary server and the other configured as - the secondary server. Additionally, organizations typically deploy the servers - in two geographically separated network subnetworks (i.e., not located in the - same physical facility). For role separation, DNS servers with internal roles - only process name and address resolution requests from within organizations - (i.e., from internal clients). DNS servers with external roles only process name - and address resolution information requests from clients external to - organizations (i.e., on external networks, including the Internet). - Organizations specify clients that can access authoritative DNS servers in - certain roles (e.g., by address ranges and explicit lists).
-the systems that collectively provide name/address resolution services for an - organization are fault-tolerant;
- -the systems that collectively provide name/address resolution services for an - organization implement internal role separation;
- -the systems that collectively provide name/address resolution services for an - organization implement external role separation.
- -System and communications protection policy
-procedures addressing architecture and provisioning for name/address - resolution services
-access control policy and procedures
-system design documentation
-assessment results from independent testing organizations
-system configuration settings and associated documentation
-system audit records
-system security plan
-other relevant documents or records
-System/network administrators
-organizational personnel with information security responsibilities
-organizational personnel with responsibilities for managing DNS
-Mechanisms supporting and/or implementing name/address resolution services - for fault tolerance and role separation
-Protect the authenticity of communications sessions.
-Protecting session authenticity addresses communications protection at the
- session level, not at the packet level. Such protection establishes grounds for
- confidence at both ends of communications sessions in the ongoing identities of
- other parties and the validity of transmitted information. Authenticity
- protection includes protecting against man-in-the-middle
attacks, session
- hijacking, and the insertion of false information into sessions.
the authenticity of communication sessions is protected.
- -System and communications protection policy
-procedures addressing session authenticity
-system design documentation
-system configuration settings and associated documentation
-system audit records
-system security plan
-other relevant documents or records
-System/network administrators
-organizational personnel with information security responsibilities
-Mechanisms supporting and/or implementing session authenticity
-information at rest requiring protection is defined;
-Protect the
Information at rest refers to the state of information when it is not in process - or in transit and is located on system components. Such components include - internal or external hard disk drives, storage area network devices, or - databases. However, the focus of protecting information at rest is not on the - type of storage device or frequency of access but rather on the state of the - information. Information at rest addresses the confidentiality and integrity of - information and covers user information and system information. System-related - information that requires protection includes configurations or rule sets for - firewalls, intrusion detection and prevention systems, filtering routers, and - authentication information. Organizations may employ different mechanisms to - achieve confidentiality and integrity protections, including the use of - cryptographic mechanisms and file share scanning. Integrity protection can be - achieved, for example, by implementing write-once-read-many (WORM) technologies. - When adequate protection of information at rest cannot otherwise be achieved, - organizations may employ other controls, including frequent scanning to identify - malicious code at rest and secure offline storage in lieu of online storage.
-the
System and communications protection policy
-procedures addressing the protection of information at rest
-system design documentation
-system configuration settings and associated documentation
-cryptographic mechanisms and associated configuration documentation
-list of information at rest requiring confidentiality and integrity - protections
-system security plan
-other relevant documents or records
-System/network administrators
-organizational personnel with information security responsibilities
-system developer
-Mechanisms supporting and/or implementing confidentiality and integrity - protections for information at rest
-information requiring cryptographic protection is defined;
-system components or media requiring cryptographic protection is/are - defined;
-Implement cryptographic mechanisms to prevent unauthorized disclosure and
- modification of the following information at rest on
The selection of cryptographic mechanisms is based on the need to protect the - confidentiality and integrity of organizational information. The strength of - mechanism is commensurate with the security category or classification of - the information. Organizations have the flexibility to encrypt information - on system components or media or encrypt data structures, including files, - records, or fields.
-cryptographic mechanisms are implemented to prevent unauthorized
- disclosure of
cryptographic mechanisms are implemented to prevent unauthorized
- modification of
System and communications protection policy
-procedures addressing the protection of information at rest
-system design documentation
-system configuration settings and associated documentation
-cryptographic mechanisms and associated configuration documentation
-system audit records
-system security plan
-other relevant documents or records
-System/network administrators
-organizational personnel with information security responsibilities
-system developer
-Cryptographic mechanisms implementing confidentiality and integrity - protections for information at rest
-Maintain a separate execution domain for each executing system process.
-Systems can maintain separate execution domains for each executing process by - assigning each process a separate address space. Each system process has a - distinct 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. Maintaining separate execution domains - for executing processes can be achieved, for example, by implementing separate - address spaces. Process isolation technologies, including sandboxing or - virtualization, logically separate software and firmware from other software, - firmware, and data. Process isolation helps limit the access of potentially - untrusted software to other system resources. The capability to maintain - separate execution domains is available in commercial operating systems that - employ multi-state processor technologies.
-a separate execution domain is maintained for each executing system process.
- -System design documentation
-system architecture
-independent verification and validation documentation
-testing and evaluation documentation
-other relevant documents or records
-System developers/integrators
-system security architect
-Mechanisms supporting and/or implementing separate execution domains for each - executing process
-personnel or roles to whom the system and information integrity policy is to - be disseminated is/are defined;
-personnel or roles to whom the system and information integrity procedures - are to be disseminated is/are defined;
-an official to manage the system and information integrity policy and - procedures is defined;
-the frequency at which the current system and information integrity policy is - reviewed and updated is defined;
-events that would require the current system and information integrity policy - to be reviewed and updated are defined;
-the frequency at which the current system and information integrity - procedures are reviewed and updated is defined;
-events that would require the system and information integrity procedures to - be reviewed and updated are defined;
-Develop, document, and disseminate to
Addresses purpose, scope, roles, responsibilities, management - commitment, coordination among organizational entities, and - compliance; and
-Is consistent with applicable laws, executive orders, directives, - regulations, policies, standards, and guidelines; and
-Procedures to facilitate the implementation of the system and information - integrity policy and the associated system and information integrity - controls;
-Designate an
Review and update the current system and information integrity:
-Policy
Procedures
System and information integrity policy and procedures address the controls in - the SI family that are implemented within systems and organizations. The risk - management strategy is an important factor in establishing such policies and - procedures. Policies and procedures contribute to security and privacy - assurance. Therefore, it is important that security and privacy programs - collaborate on the development of system and information integrity policy and - procedures. Security and privacy program policies and procedures at the - organization level are preferable, in general, and may obviate the need for - mission- or system-specific policies and procedures. The policy can be included - as part of the general security and privacy policy or be represented by multiple - policies that reflect the complex nature of organizations. Procedures can be - established for security and privacy programs, for mission or business - processes, and for systems, if needed. Procedures describe how the policies or - controls are implemented and can be directed at the individual or role that is - the object of the procedure. Procedures can be documented in system security and - privacy plans or in one or more separate documents. Events that may precipitate - an update to system and information integrity policy and procedures include - assessment or audit findings, security incidents or breaches, or changes in - applicable laws, executive orders, directives, regulations, policies, standards, - and guidelines. Simply restating controls does not constitute an organizational - policy or procedure.
-a system and information integrity policy is developed and documented;
- -the system and information integrity policy is disseminated to
system and information integrity procedures to facilitate the - implementation of the system and information integrity policy and - associated system and information integrity controls are developed and - documented;
- -the system and information integrity procedures are disseminated to
the
the
the
the
the
the
the
the
the
the current system and information integrity policy is reviewed and
- updated
the current system and information integrity policy is reviewed and
- updated following
the current system and information integrity procedures are reviewed
- and updated
the current system and information integrity procedures are reviewed
- and updated following
System and information integrity policy
-system and information integrity procedures
-system security plan
-privacy plan
-other relevant documents or records
-Organizational personnel with system and information integrity - responsibilities
-organizational personnel with information security and privacy - responsibilities
-time period within which to install security-relevant software updates after - the release of the updates is defined;
-Identify, report, and correct system flaws;
-Test software and firmware updates related to flaw remediation for - effectiveness and potential side effects before installation;
-Install security-relevant software and firmware updates within
Incorporate flaw remediation into the organizational configuration management - process.
-The need to remediate system flaws applies to all types of software and firmware. - Organizations identify systems affected by software flaws, including potential - vulnerabilities resulting from those flaws, and report this information to - designated organizational personnel with information security and privacy - responsibilities. Security-relevant updates include patches, service packs, and - malicious code signatures. Organizations also address flaws discovered during - assessments, continuous monitoring, incident response activities, and system - error handling. By incorporating flaw remediation into configuration management - processes, required remediation actions can be tracked and verified.
-Organization-defined time periods for updating security-relevant software and - firmware may vary based on a variety of risk factors, including the security - category of the system, the criticality of the update (i.e., severity of the - vulnerability related to the discovered flaw), the organizational risk - tolerance, the mission supported by the system, or the threat environment. Some - types of flaw remediation may require more testing than other types. - Organizations determine the type of testing needed for the specific type of flaw - remediation activity under consideration and the types of changes that are to be - configuration-managed. In some situations, organizations may determine that the - testing of software or firmware updates is not necessary or practical, such as - when implementing simple malicious code signature updates. In testing decisions, - organizations consider whether security-relevant software or firmware updates - are obtained from authorized sources with appropriate digital signatures.
-system flaws are identified;
- -system flaws are reported;
- -system flaws are corrected;
- -software updates related to flaw remediation are tested for effectiveness - before installation;
- -software updates related to flaw remediation are tested for potential - side effects before installation;
- -firmware updates related to flaw remediation are tested for effectiveness - before installation;
- -firmware updates related to flaw remediation are tested for potential - side effects before installation;
- -security-relevant software updates are installed within
security-relevant firmware updates are installed within
flaw remediation is incorporated into the organizational configuration - management process.
- -System and information integrity policy
-system and information integrity procedures
-procedures addressing flaw remediation
-procedures addressing configuration management
-list of flaws and vulnerabilities potentially affecting the system
-list of recent security flaw remediation actions performed on the system - (e.g., list of installed patches, service packs, hot fixes, and other - software updates to correct system flaws)
-test results from the installation of software and firmware updates to - correct system flaws
-installation/change control records for security-relevant software and - firmware updates
-system security plan
-privacy plan
-other relevant documents or records
-System/network administrators
-organizational personnel with information security and privacy - responsibilities
-organizational personnel responsible for installing, configuring, and/or - maintaining the system
-organizational personnel responsible for flaw remediation
-organizational personnel with configuration management responsibilities
-Organizational processes for identifying, reporting, and correcting system - flaws
-organizational process for installing software and firmware updates
-mechanisms supporting and/or implementing the reporting and correcting of - system flaws
-mechanisms supporting and/or implementing testing software and firmware - updates
-automated mechanisms to determine if applicable security-relevant - software and firmware updates are installed on system components are - defined;
-the frequency at which to determine if applicable security-relevant - software and firmware updates are installed on system components is - defined;
-Determine if system components have applicable security-relevant software and
- firmware updates installed using
Automated mechanisms can track and determine the status of known flaws for - system components.
-system components have applicable security-relevant software and firmware
- updates installed
System and information integrity policy
-system and information integrity procedures
-procedures addressing flaw remediation
-automated mechanisms supporting centralized management of flaw - remediation
-system design documentation
-system configuration settings and associated documentation
-system audit records
-system security plan
-other relevant documents or records
-System/network administrators
-organizational personnel with information security responsibilities
-organizational personnel installing, configuring, and/or maintaining the - system
-organizational personnel responsible for flaw remediation
-Automated mechanisms used to determine the state of system components - with regard to flaw remediation
-the frequency at which malicious code protection mechanisms perform scans is - defined;
-action to be taken in response to malicious code detection are defined (if - selected);
-personnel or roles to be alerted when malicious code is detected is/are - defined;
-Implement
Automatically update malicious code protection mechanisms as new releases are - available in accordance with organizational configuration management policy - and procedures;
-Configure malicious code protection mechanisms to:
-Perform periodic scans of the system
Address the receipt of false positives during malicious code detection and - eradication and the resulting potential impact on the availability of the - system.
-System entry and exit points include firewalls, remote access servers, - workstations, electronic mail servers, web servers, proxy servers, notebook - computers, and mobile devices. Malicious code includes viruses, worms, Trojan - horses, and spyware. Malicious code can also be encoded in various formats - contained within compressed or hidden files or hidden in files using techniques - such as steganography. Malicious code can be inserted into systems in a variety - of ways, including by electronic mail, the world-wide web, and portable storage - devices. Malicious code insertions occur through the exploitation of system - vulnerabilities. A variety of technologies and methods exist to limit or - eliminate the effects of malicious code.
-Malicious code protection mechanisms include both signature- and - nonsignature-based technologies. Nonsignature-based detection mechanisms include - artificial intelligence techniques that use heuristics to detect, analyze, and - describe the characteristics or behavior of malicious code and to provide - controls against such code for which signatures do not yet exist or for which - existing signatures may not be effective. Malicious code for which active - signatures do not yet exist or may be ineffective includes polymorphic malicious - code (i.e., code that changes signatures when it replicates). Nonsignature-based - mechanisms also include reputation-based technologies. In addition to the above - technologies, pervasive configuration management, comprehensive software - integrity controls, and anti-exploitation software may be effective in - preventing the execution of unauthorized code. Malicious code may be present in - commercial off-the-shelf software as well as custom-built software and could - include logic bombs, backdoors, and other types of attacks that could affect - organizational mission and business functions.
-In situations where malicious code cannot be detected by detection methods or - technologies, organizations rely on other types of controls, including secure - coding practices, configuration management and control, trusted procurement - processes, and monitoring practices to ensure that software does not perform - functions other than the functions intended. Organizations may determine that, - in response to the detection of malicious code, different actions may be - warranted. For example, organizations can define actions in response to - malicious code detection during periodic scans, the detection of malicious - downloads, or the detection of maliciousness when attempting to open or execute - files.
-malicious code protection mechanisms are updated automatically as new - releases are available in accordance with organizational configuration - management policy and procedures;
- -malicious code protection mechanisms are configured to perform
- periodic scans of the system
malicious code protection mechanisms are configured to perform
- real-time scans of files from external sources at
malicious code protection mechanisms are configured to
malicious code protection mechanisms are configured to send alerts to
the receipt of false positives during malicious code detection and - eradication and the resulting potential impact on the availability of the - system are addressed.
- -System and information integrity policy
-system and information integrity procedures
-configuration management policy and procedures
-procedures addressing malicious code protection
-malicious code protection mechanisms
-records of malicious code protection updates
-system design documentation
-system configuration settings and associated documentation
-scan results from malicious code protection mechanisms
-record of actions initiated by malicious code protection mechanisms in - response to malicious code detection
-system audit records
-system security plan
-other relevant documents or records
-System/network administrators
-organizational personnel with information security responsibilities
-organizational personnel installing, configuring, and/or maintaining the - system
-organizational personnel responsible for malicious code protection
-organizational personnel with configuration management responsibilities
-Organizational processes for employing, updating, and configuring malicious - code protection mechanisms
-organizational processes for addressing false positives and resulting - potential impacts
-mechanisms supporting and/or implementing, employing, updating, and - configuring malicious code protection mechanisms
-mechanisms supporting and/or implementing malicious code scanning and - subsequent actions
-monitoring objectives to detect attacks and indicators of potential attacks - on the system are defined;
-techniques and methods used to identify unauthorized use of the system are - defined;
-system monitoring information to be provided to personnel or roles is - defined;
-personnel or roles to whom system monitoring information is to be provided - is/are defined;
-a frequency for providing system monitoring to personnel or roles is defined - (if selected);
-Monitor the system to detect:
-Attacks and indicators of potential attacks in accordance with the
- following monitoring objectives:
Unauthorized local, network, and remote connections;
-Identify unauthorized use of the system through the following techniques and
- methods:
Invoke internal monitoring capabilities or deploy monitoring devices:
-Strategically within the system to collect organization-determined - essential information; and
-At ad hoc locations within the system to track specific types of - transactions of interest to the organization;
-Analyze detected events and anomalies;
-Adjust the level of system monitoring activity when there is a change in risk - to organizational operations and assets, individuals, other organizations, - or the Nation;
-Obtain legal opinion regarding system monitoring activities; and
-Provide
System monitoring includes external and internal monitoring. External monitoring - includes the observation of events occurring at external interfaces to the - system. Internal monitoring includes the observation of events occurring within - the system. Organizations monitor systems by observing audit activities in real - time or by observing other system aspects such as access patterns, - characteristics of access, and other actions. The monitoring objectives guide - and inform the determination of the events. System monitoring capabilities are - achieved through a variety of tools and techniques, including intrusion - detection and prevention systems, malicious code protection software, scanning - tools, audit record monitoring software, and network monitoring software.
-Depending on the security architecture, the distribution and configuration of - monitoring devices may impact throughput at key internal and external boundaries - as well as at other locations across a network due to the introduction of - network throughput latency. If throughput management is needed, such devices are - strategically located and deployed as part of an established organization-wide - security architecture. Strategic locations for monitoring devices include - selected perimeter locations and near key servers and server farms that support - critical applications. Monitoring devices are typically employed at the managed - interfaces associated with controls SC-7 and AC-17 . The information collected is a function of the - organizational monitoring objectives and the capability of systems to support - such objectives. Specific types of transactions of interest include Hypertext - Transfer Protocol (HTTP) traffic that bypasses HTTP proxies. System monitoring - is an integral part of organizational continuous monitoring and incident - response programs, and output from system monitoring serves as input to those - programs. System monitoring requirements, including the need for specific types - of system monitoring, may be referenced in other controls (e.g., AC-2g, - AC-2(7), - AC-2(12)(a), AC-17(1), - AU-13, - AU-13(1), - AU-13(2), CM-3f, CM-6d, MA-3a, MA-4a, - SC-5(3)(b), SC-7a, - SC-7(24)(b), SC-18b, - SC-43b ). Adjustments to levels of system monitoring are based on law - enforcement information, intelligence information, or other sources of - information. The legality of system monitoring activities is based on applicable - laws, executive orders, directives, regulations, policies, standards, and - guidelines.
-the system is monitored to detect attacks and indicators of potential
- attacks in accordance with
the system is monitored to detect unauthorized local connections;
- -the system is monitored to detect unauthorized network connections;
- -the system is monitored to detect unauthorized remote connections;
- -unauthorized use of the system is identified through
internal monitoring capabilities are invoked or monitoring devices are - deployed strategically within the system to collect - organization-determined essential information;
- -internal monitoring capabilities are invoked or monitoring devices are - deployed at ad hoc locations within the system to track specific types - of transactions of interest to the organization;
- -detected events are analyzed;
- -detected anomalies are analyzed;
- -the level of system monitoring activity is adjusted when there is a change in - risk to organizational operations and assets, individuals, other - organizations, or the Nation;
- -a legal opinion regarding system monitoring activities is obtained;
- -System and information integrity policy
-system and information integrity procedures
-procedures addressing system monitoring tools and techniques
-continuous monitoring strategy
-facility diagram/layout
-system design documentation
-system monitoring tools and techniques documentation
-locations within the system where monitoring devices are deployed
-system configuration settings and associated documentation
-system security plan
-other relevant documents or records
-System/network administrators
-organizational personnel with information security responsibilities
-organizational personnel installing, configuring, and/or maintaining the - system
-organizational personnel responsible for monitoring the system
-Organizational processes for system monitoring
-mechanisms supporting and/or implementing system monitoring capabilities
-Employ automated tools and mechanisms to support near real-time analysis of - events.
-Automated tools and mechanisms include host-based, network-based, - transport-based, or storage-based event monitoring tools and mechanisms or - security information and event management (SIEM) technologies that provide - real-time analysis of alerts and notifications generated by organizational - systems. Automated monitoring techniques can create unintended privacy risks - because automated controls may connect to external or otherwise unrelated - systems. The matching of records between these systems may create linkages - with unintended consequences. Organizations assess and document these risks - in their privacy impact assessment and make determinations that are in - alignment with their privacy program plan.
-automated tools and mechanisms are employed to support a near real-time - analysis of events.
- -System and information integrity policy
-system and information integrity procedures
-procedures addressing system monitoring tools and techniques
-system design documentation
-system monitoring tools and techniques documentation
-system configuration settings and associated documentation
-system audit records
-system security plan
-privacy plan
-privacy program plan
-privacy impact assessment
-privacy risk management documentation
-other relevant documents or records
-System/network administrators
-organizational personnel with information security and privacy - responsibilities
-organizational personnel installing, configuring, and/or maintaining the - system
-organizational personnel responsible for monitoring the system
-organizational personnel responsible for incident response/management
-Organizational processes for the near real-time analysis of events
-organizational processes for system monitoring
-mechanisms supporting and/or implementing system monitoring
-mechanisms/tools supporting and/or implementing an analysis of events
-the frequency at which to monitor inbound communications traffic for - unusual or unauthorized activities or conditions is defined;
-unusual or unauthorized activities or conditions that are to be monitored - in inbound communications traffic are defined;
-the frequency at which to monitor outbound communications traffic for - unusual or unauthorized activities or conditions is defined;
-unusual or unauthorized activities or conditions that are to be monitored - in outbound communications traffic are defined;
-Determine criteria for unusual or unauthorized activities or conditions - for inbound and outbound communications traffic;
-Monitor inbound and outbound communications traffic
Unusual or unauthorized activities or conditions related to system inbound - and outbound communications traffic includes internal traffic that indicates - the presence of malicious code or unauthorized use of legitimate code or - credentials within organizational systems or propagating among system - components, signaling to external systems, and the unauthorized exporting of - information. Evidence of malicious code or unauthorized use of legitimate - code or credentials is used to identify potentially compromised systems or - system components.
-criteria for unusual or unauthorized activities or conditions for - inbound communications traffic are defined;
- -criteria for unusual or unauthorized activities or conditions for - outbound communications traffic are defined;
- -inbound communications traffic is monitored
outbound communications traffic is monitored
System and information integrity policy
-system and information integrity procedures
-procedures addressing system monitoring tools and techniques
-system design documentation
-system monitoring tools and techniques documentation
-system configuration settings and associated documentation
-system protocols
-system audit records
-system security plan
-other relevant documents or records
-System/network administrators
-organizational personnel with information security responsibilities
-organizational personnel installing, configuring, and/or maintaining the - system
-organizational personnel responsible for monitoring the system
-organizational personnel responsible for the intrusion detection system
-Organizational processes for intrusion detection and system monitoring
-mechanisms supporting and/or implementing intrusion detection and system - monitoring capabilities
-mechanisms supporting and/or implementing the monitoring of inbound and - outbound communications traffic
-personnel or roles to be alerted when indications of compromise or - potential compromise occur is/are defined;
-compromise indicators are defined;
-Alert
Alerts may be generated from a variety of sources, including audit records or - inputs from malicious code protection mechanisms, intrusion detection or - prevention mechanisms, or boundary protection devices such as firewalls, - gateways, and routers. Alerts can be automated and may be transmitted - telephonically, by electronic mail messages, or by text messaging. - Organizational personnel on the alert notification list can include system - administrators, mission or business owners, system owners, information - owners/stewards, senior agency information security officers, senior agency - officials for privacy, system security officers, or privacy officers. In - contrast to alerts generated by the system, alerts generated by - organizations in - SI-4(12) focus on information sources external to the system, such as - suspicious activity reports and reports on potential insider threats.
-System and information integrity policy
-system and information integrity procedures
-procedures addressing system monitoring tools and techniques
-system monitoring tools and techniques documentation
-system configuration settings and associated documentation
-list of personnel selected to receive alerts
-documentation of alerts generated based on compromise indicators
-system audit records
-system security plan
-privacy plan
-other relevant documents or records
-System/network administrators
-organizational personnel with information security and privacy - responsibilities
-system developers
-organizational personnel installing, configuring, and/or maintaining the - system
-organizational personnel responsible for monitoring the system
-organizational personnel on the system alert notification list
-organizational personnel responsible for the intrusion detection system
-Organizational processes for intrusion detection and system monitoring
-mechanisms supporting and/or implementing intrusion detection and system - monitoring capabilities
-mechanisms supporting and/or implementing alerts for compromise - indicators
-external organizations from whom system security alerts, advisories, and - directives are to be received on an ongoing basis are defined;
-personnel or roles to whom security alerts, advisories, and directives are to - be disseminated is/are defined (if selected);
-elements within the organization to whom security alerts, advisories, and - directives are to be disseminated are defined (if selected);
-external organizations to whom security alerts, advisories, and directives - are to be disseminated are defined (if selected);
-Receive system security alerts, advisories, and directives from
Generate internal security alerts, advisories, and directives as deemed - necessary;
-Disseminate security alerts, advisories, and directives to:
Implement security directives in accordance with established time frames, or - notify the issuing organization of the degree of noncompliance.
-The Cybersecurity and Infrastructure Security Agency (CISA) generates security - alerts and advisories to maintain situational awareness throughout the Federal - Government. Security directives are issued by OMB or other designated - organizations with the responsibility and authority to issue such directives. - Compliance with security directives is essential due to the critical nature of - many of these directives and the potential (immediate) adverse effects on - organizational operations and assets, individuals, other organizations, and the - Nation should the directives not be implemented in a timely manner. External - organizations include supply chain partners, external mission or business - partners, external service providers, and other peer or supporting - organizations.
-system security alerts, advisories, and directives are received from
internal security alerts, advisories, and directives are generated as deemed - necessary;
- -security alerts, advisories, and directives are disseminated to
security directives are implemented in accordance with established time - frames or if the issuing organization is notified of the degree of - noncompliance.
- -System and information integrity policy
-system and information integrity procedures
-procedures addressing security alerts, advisories, and directives
-records of security alerts and advisories
-system security plan
-other relevant documents or records
-Organizational personnel with security alert and advisory responsibilities
-organizational personnel implementing, operating, maintaining, and using the - system
-organizational personnel, organizational elements, and/or external - organizations to whom alerts, advisories, and directives are to be - disseminated
-system/network administrators
-organizational personnel with information security responsibilities
-Organizational processes for defining, receiving, generating, disseminating, - and complying with security alerts, advisories, and directives
-mechanisms supporting and/or implementing the definition, receipt, - generation, and dissemination of security alerts, advisories, and directives
-mechanisms supporting and/or implementing security directives
-software requiring integrity verification tools to be employed to detect - unauthorized changes is defined;
-firmware requiring integrity verification tools to be employed to detect - unauthorized changes is defined;
-information requiring integrity verification tools to be employed to detect - unauthorized changes is defined;
-actions to be taken when unauthorized changes to software are detected are - defined;
-actions to be taken when unauthorized changes to firmware are detected are - defined;
-actions to be taken when unauthorized changes to information are detected are - defined;
-Employ integrity verification tools to detect unauthorized changes to the
- following software, firmware, and information:
Take the following actions when unauthorized changes to the software,
- firmware, and information are detected:
Unauthorized changes to software, firmware, and information can occur due to - errors or malicious activity. Software includes operating systems (with key - internal components, such as kernels or drivers), middleware, and applications. - Firmware interfaces include Unified Extensible Firmware Interface (UEFI) and - Basic Input/Output System (BIOS). Information includes personally identifiable - information and metadata that contains security and privacy attributes - associated with information. Integrity-checking mechanisms—including parity - checks, cyclical redundancy checks, cryptographic hashes, and associated - tools—can automatically monitor the integrity of systems and hosted - applications.
-integrity verification tools are employed to detect unauthorized changes
- to
integrity verification tools are employed to detect unauthorized changes
- to
integrity verification tools are employed to detect unauthorized changes
- to
System and information integrity policy
-system and information integrity procedures
-procedures addressing software, firmware, and information integrity
-personally identifiable information processing policy
-system design documentation
-system configuration settings and associated documentation
-integrity verification tools and associated documentation
-records generated or triggered by integrity verification tools regarding - unauthorized software, firmware, and information changes
-system audit records
-system security plan
-privacy plan
-other relevant documents or records
-Organizational personnel responsible for software, firmware, and/or - information integrity
-organizational personnel with information security and privacy - responsibilities
-system/network administrators
-Software, firmware, and information integrity verification tools
-software on which an integrity check is to be performed is defined;
-transitional states or security-relevant events requiring integrity - checks (on software) are defined (if selected);
-frequency with which to perform an integrity check (on software) is - defined (if selected);
-firmware on which an integrity check is to be performed is defined;
-transitional states or security-relevant events requiring integrity - checks (on firmware) are defined (if selected);
-frequency with which to perform an integrity check (on firmware) is - defined (if selected);
-information on which an integrity check is to be performed is defined;
-transitional states or security-relevant events requiring integrity - checks (of information) are defined (if selected);
-frequency with which to perform an integrity check (of information) is - defined (if selected);
-Perform an integrity check of
Security-relevant events include the identification of new threats to which - organizational systems are susceptible and the installation of new hardware, - software, or firmware. Transitional states include system startup, restart, - shutdown, and abort.
-an integrity check of
an integrity check of
an integrity check of
System and information integrity policy
-system and information integrity procedures
-procedures addressing software, firmware, and information integrity - testing
-system design documentation
-system configuration settings and associated documentation
-integrity verification tools and associated documentation
-records of integrity scans
-system security plan
-other relevant documents or records
-Organizational personnel responsible for software, firmware, and/or - information integrity
-organizational personnel with information security responsibilities
-system/network administrators
-system developer
-Software, firmware, and information integrity verification tools
-security-relevant changes to the system are defined;
-Incorporate the detection of the following unauthorized changes into the
- organizational incident response capability:
Integrating detection and response helps to ensure that detected events are - tracked, monitored, corrected, and available for historical purposes. - Maintaining historical records is important for being able to identify and - discern adversary actions over an extended time period and for possible - legal actions. Security-relevant changes include unauthorized changes to - established configuration settings or the unauthorized elevation of system - privileges.
-the detection of
System and information integrity policy
-system and information integrity procedures
-procedures addressing software, firmware, and information integrity
-procedures addressing incident response
-system design documentation
-system configuration settings and associated documentation
-incident response records
-audit records
-system security plan
-other relevant documents or records
-Organizational personnel responsible for software, firmware, and/or - information integrity
-organizational personnel with information security responsibilities
-organizational personnel with incident response responsibilities
-Organizational processes for incorporating the detection of unauthorized - security-relevant changes into the incident response capability
-software, firmware, and information integrity verification tools
-mechanisms supporting and/or implementing the incorporation of detection - of unauthorized security-relevant changes into the incident response - capability
-Employ spam protection mechanisms at system entry and exit points to detect - and act on unsolicited messages; and
-Update spam protection mechanisms when new releases are available in - accordance with organizational configuration management policy and - procedures.
-System entry and exit points include firewalls, remote-access servers, electronic - mail servers, web servers, proxy servers, workstations, notebook computers, and - mobile devices. Spam can be transported by different means, including email, - email attachments, and web accesses. Spam protection mechanisms include - signature definitions.
-spam protection mechanisms are employed at system entry points to detect - unsolicited messages;
- -spam protection mechanisms are employed at system exit points to detect - unsolicited messages;
- -spam protection mechanisms are employed at system entry points to act on - unsolicited messages;
- -spam protection mechanisms are employed at system exit points to act on - unsolicited messages;
- -spam protection mechanisms are updated when new releases are available in - accordance with organizational configuration management policies and - procedures.
- -System and information integrity policy
-system and information integrity procedures
-configuration management policies and procedures (CM-01)
-procedures addressing spam protection
-spam protection mechanisms
-records of spam protection updates
-system design documentation
-system configuration settings and associated documentation
-system audit records
-system security plan
-other relevant documents or records
-Organizational personnel responsible for spam protection
-organizational personnel with information security responsibilities
-system/network administrators
-system developer
-Organizational processes for implementing spam protection
-mechanisms supporting and/or implementing spam protection
-the frequency at which to automatically update spam protection mechanisms - is defined;
-Automatically update spam protection mechanisms
Using automated mechanisms to update spam protection mechanisms helps to - ensure that updates occur on a regular basis and provide the latest content - and protection capabilities.
-spam protection mechanisms are automatically updated
System and information integrity policy
-system and information integrity procedures
-procedures addressing spam protection
-spam protection mechanisms
-records of spam protection updates
-system design documentation
-system configuration settings and associated documentation
-system audit records
-system security plan
-other relevant documents or records
-Organizational personnel responsible for spam protection
-organizational personnel with information security responsibilities
-system/network administrators
-system developer
-Organizational processes for spam protection
-mechanisms supporting and/or implementing automatic updates to spam - protection mechanisms
-information inputs to the system requiring validity checks are defined;
-Check the validity of the following information inputs:
Checking the valid syntax and semantics of system inputs—including character set,
- length, numerical range, and acceptable values—verifies that inputs match
- specified definitions for format and content. For example, if the organization
- specifies that numerical values between 1-100 are the only acceptable inputs for
- a field in a given application, inputs of 387,
abc,
or %K%
- are invalid inputs and are not accepted as input to the system. Valid inputs are
- likely to vary from field to field within a software application. Applications
- typically follow well-defined protocols that use structured messages (i.e.,
- commands or queries) to communicate between software modules or system
- components. Structured messages can contain raw or unstructured data
- interspersed with metadata or control information. If software applications use
- attacker-supplied inputs to construct structured messages without properly
- encoding such messages, then the attacker could insert malicious commands or
- special characters that can cause the data to be interpreted as control
- information or metadata. Consequently, the module or component that receives the
- corrupted output will perform the wrong operations or otherwise interpret the
- data incorrectly. Prescreening inputs prior to passing them to interpreters
- prevents the content from being unintentionally interpreted as commands. Input
- validation ensures accurate and correct inputs and prevents attacks such as
- cross-site scripting and a variety of injection attacks.
the validity of the
System and information integrity policy
-system and information integrity procedures
-access control policy and procedures
-separation of duties policy and procedures
-procedures addressing information input validation
-documentation for automated tools and applications to verify the validity of - information
-list of information inputs requiring validity checks
-system design documentation
-system configuration settings and associated documentation
-system audit records
-system security plan
-other relevant documents or records
-Organizational personnel responsible for information input validation
-organizational personnel with information security responsibilities
-system/network administrators
-system developer
-Mechanisms supporting and/or implementing validity checks on information - inputs
-personnel or roles to whom error messages are to be revealed is/are defined;
-Generate error messages that provide information necessary for corrective - actions without revealing information that could be exploited; and
-Reveal error messages only to
Organizations consider the structure and content of error messages. The extent to - which systems can handle error conditions is guided and informed by - organizational policy and operational requirements. Exploitable information - includes stack traces and implementation details; erroneous logon attempts with - passwords mistakenly entered as the username; mission or business information - that can be derived from, if not stated explicitly by, the information recorded; - and personally identifiable information, such as account numbers, social - security numbers, and credit card numbers. Error messages may also provide a - covert channel for transmitting information.
-error messages that provide the information necessary for corrective actions - are generated without revealing information that could be exploited;
- -error messages are revealed only to
System and information integrity policy
-system and information integrity procedures
-procedures addressing system error handling
-system design documentation
-system configuration settings and associated documentation
-documentation providing the structure and content of error messages
-system audit records
-system security plan
-other relevant documents or records
-Organizational personnel responsible for information input validation
-organizational personnel with information security responsibilities
-system/network administrators
-system developer
-Organizational processes for error handling
-automated mechanisms supporting and/or implementing error handling
-automated mechanisms supporting and/or implementing the management of error - messages
-Manage and retain information within the system and information output from the - system in accordance with applicable laws, executive orders, directives, - regulations, policies, standards, guidelines and operational requirements.
-Information management and retention requirements cover the full life cycle of - information, in some cases extending beyond system disposal. Information to be - retained may also include policies, procedures, plans, reports, data output from - control implementation, and other types of administrative information. The - National Archives and Records Administration (NARA) provides federal policy and - guidance on records retention and schedules. If organizations have a records - management office, consider coordinating with records management personnel. - Records produced from the output of implemented controls that may require - management and retention include, but are not limited to: All XX-1, AC-6(9), AT-4, AU-12 - , CA-2, CA-3, CA-5, CA-6, CA-7, - CA-8, CA-9, CM-2, - CM-3, CM-4, CM-6, - CM-8, CM-9, CM-12, - CM-13, CP-2, IR-6, - IR-8, MA-2, MA-4, - PE-2, PE-8, PE-16, - PE-17, PL-2, PL-4, - PL-7, PL-8, - PM-5, - PM-8, - PM-9, - PM-18, - PM-21, - PM-27, - PM-28, - PM-30, - PM-31, PS-2, PS-6, - PS-7, - PT-2, - PT-3, - PT-7, RA-2, RA-3, - RA-5, - RA-8, SA-4, SA-5, - SA-8, SA-10, SI-4, - SR-2, - SR-4, SR-8.
-information within the system is managed in accordance with applicable laws, - Executive Orders, directives, regulations, policies, standards, guidelines, - and operational requirements;
- -information within the system is retained in accordance with applicable laws, - Executive Orders, directives, regulations, policies, standards, guidelines, - and operational requirements;
- -information output from the system is managed in accordance with applicable - laws, Executive Orders, directives, regulations, policies, standards, - guidelines, and operational requirements;
- -information output from the system is retained in accordance with applicable - laws, Executive Orders, directives, regulations, policies, standards, - guidelines, and operational requirements.
- -System and information integrity policy
-system and information integrity procedures
-personally identifiable information processing policy
-records retention and disposition policy
-records retention and disposition procedures
-federal laws, Executive Orders, directives, policies, regulations, standards, - and operational requirements applicable to information management and - retention
-media protection policy
-media protection procedures
-audit findings
-system security plan
-privacy plan
-privacy program plan
-personally identifiable information inventory
-privacy impact assessment
-privacy risk assessment documentation
-other relevant documents or records
-Organizational personnel with information and records management, retention, - and disposition responsibilities
-organizational personnel with information security and privacy - responsibilities
-network administrators
-Organizational processes for information management, retention, and - disposition
-automated mechanisms supporting and/or implementing information management, - retention, and disposition
-controls to be implemented to protect the system memory from unauthorized - code execution are defined;
-Implement the following controls to protect the system memory from unauthorized
- code execution:
Some adversaries launch attacks with the intent of executing code in - non-executable regions of memory or in memory locations that are prohibited. - Controls employed to protect memory include data execution prevention and - address space layout randomization. Data execution prevention controls can - either be hardware-enforced or software-enforced with hardware enforcement - providing the greater strength of mechanism.
-System and information integrity policy
-system and information integrity procedures
-procedures addressing memory protection for the system
-system design documentation
-system configuration settings and associated documentation
-list of security safeguards protecting system memory from unauthorized code - execution
-system audit records
-system security plan
-other relevant documents or records
-Organizational personnel responsible for memory protection
-organizational personnel with information security responsibilities
-system/network administrators
-system developer
-Automated mechanisms supporting and/or implementing safeguards to protect the - system memory from unauthorized code execution
-personnel or roles to whom supply chain risk management policy is to be - disseminated to is/are defined;
-personnel or roles to whom supply chain risk management procedures are - disseminated to is/are defined;
-an official to manage the development, documentation, and dissemination of - the supply chain risk management policy and procedures is defined;
-the frequency at which the current supply chain risk management policy is - reviewed and updated is defined;
-events that require the current supply chain risk management policy to be - reviewed and updated are defined;
-the frequency at which the current supply chain risk management procedure is - reviewed and updated is defined;
-events that require the supply chain risk management procedures to be - reviewed and updated are defined;
-Develop, document, and disseminate to
Addresses purpose, scope, roles, responsibilities, management - commitment, coordination among organizational entities, and - compliance; and
-Is consistent with applicable laws, executive orders, directives, - regulations, policies, standards, and guidelines; and
-Procedures to facilitate the implementation of the supply chain risk - management policy and the associated supply chain risk management - controls;
-Designate an
Review and update the current supply chain risk management:
-Policy
Procedures
Supply chain risk management policy and procedures address the controls in the SR - family as well as supply chain-related controls in other families that are - implemented within systems and organizations. The risk management strategy is an - important factor in establishing such policies and procedures. Policies and - procedures contribute to security and privacy assurance. Therefore, it is - important that security and privacy programs collaborate on the development of - supply chain risk management policy and procedures. Security and privacy program - policies and procedures at the organization level are preferable, in general, - and may obviate the need for mission- or system-specific policies and - procedures. The policy can be included as part of the general security and - privacy policy or be represented by multiple policies that reflect the complex - nature of organizations. Procedures can be established for security and privacy - programs, for mission or business processes, and for systems, if needed. - Procedures describe how the policies or controls are implemented and can be - directed at the individual or role that is the object of the procedure. - Procedures can be documented in system security and privacy plans or in one or - more separate documents. Events that may precipitate an update to supply chain - risk management policy and procedures include assessment or audit findings, - security incidents or breaches, or changes in applicable laws, executive orders, - directives, regulations, policies, standards, and guidelines. Simply restating - controls does not constitute an organizational policy or procedure.
-a supply chain risk management policy is developed and documented;
- -the supply chain risk management policy is disseminated to
supply chain risk management procedures to facilitate the implementation - of the supply chain risk management policy and the associated supply - chain risk management controls are developed and documented;
- -the supply chain risk management procedures are disseminated to
the
the
the
the
the
the
the
the
the current supply chain risk management policy is reviewed and
- updated
the current supply chain risk management policy is reviewed and
- updated following
the current supply chain risk management procedures are reviewed and
- updated
the current supply chain risk management procedures are reviewed and
- updated following
Supply chain risk management policy
-supply chain risk management procedures
-system security plan
-privacy plan
-other relevant documents or records
-Organizational personnel with supply chain risk management responsibilities
-organizational personnel with information security and privacy - responsibilities
-organizational personnel with acquisition responsibilities
-organizational personnel with enterprise risk management responsibilities
-systems, system components, or system services for which a supply chain risk - management plan is developed are defined;
-the frequency at which to review and update the supply chain risk management - plan is defined;
-Develop a plan for managing supply chain risks associated with the research
- and development, design, manufacturing, acquisition, delivery, integration,
- operations and maintenance, and disposal of the following systems, system
- components or system services:
Review and update the supply chain risk management plan
Protect the supply chain risk management plan from unauthorized disclosure - and modification.
-The dependence on products, systems, and services from external providers, as - well as the nature of the relationships with those providers, present an - increasing level of risk to an organization. Threat actions that may increase - security or privacy risks include unauthorized production, the insertion or use - of counterfeits, tampering, theft, insertion of malicious software and hardware, - and poor manufacturing and development practices in the supply chain. Supply - chain risks can be endemic or systemic within a system element or component, a - system, an organization, a sector, or the Nation. Managing supply chain risk is - a complex, multifaceted undertaking that requires a coordinated effort across an - organization to build trust relationships and communicate with internal and - external stakeholders. Supply chain risk management (SCRM) activities include - identifying and assessing risks, determining appropriate risk response actions, - developing SCRM plans to document response actions, and monitoring performance - against plans. The SCRM plan (at the system-level) is implementation specific, - providing policy implementation, requirements, constraints and implications. It - can either be stand-alone, or incorporated into system security and privacy - plans. The SCRM plan addresses managing, implementation, and monitoring of SCRM - controls and the development/sustainment of systems across the SDLC to support - mission and business functions.
-Because supply chains can differ significantly across and within organizations, - SCRM plans are tailored to the individual program, organizational, and - operational contexts. Tailored SCRM plans provide the basis for determining - whether a technology, service, system component, or system is fit for purpose, - and as such, the controls need to be tailored accordingly. Tailored SCRM plans - help organizations focus their resources on the most critical mission and - business functions based on mission and business requirements and their risk - environment. Supply chain risk management plans include an expression of the - supply chain risk tolerance for the organization, acceptable supply chain risk - mitigation strategies or controls, a process for consistently evaluating and - monitoring supply chain risk, approaches for implementing and communicating the - plan, a description of and justification for supply chain risk mitigation - measures taken, and associated roles and responsibilities. Finally, supply chain - risk management plans address requirements for developing trustworthy, secure, - privacy-protective, and resilient system components and systems, including the - application of the security design principles implemented as part of life - cycle-based systems security engineering processes (see SA-8 - ).
-a plan for managing supply chain risks is developed;
- -the supply chain risk management plan addresses risks associated with the
- research and development of
the supply chain risk management plan addresses risks associated with the
- design of
the supply chain risk management plan addresses risks associated with the
- manufacturing of
the supply chain risk management plan addresses risks associated with the
- acquisition of
the supply chain risk management plan addresses risks associated with the
- delivery of
the supply chain risk management plan addresses risks associated with the
- integration of
the supply chain risk management plan addresses risks associated with the
- operation and maintenance of
the supply chain risk management plan addresses risks associated with the
- disposal of
the supply chain risk management plan is reviewed and updated
the supply chain risk management plan is protected from unauthorized - disclosure;
- -the supply chain risk management plan is protected from unauthorized - modification.
- -Supply chain risk management policy
-supply chain risk management procedures
-supply chain risk management plan
-system and services acquisition policy
-system and services acquisition procedures
-procedures addressing supply chain protection
-procedures for protecting the supply chain risk management plan from - unauthorized disclosure and modification
-system development life cycle procedures
-procedures addressing the integration of information security and privacy - requirements into the acquisition process
-acquisition documentation
-service level agreements
-acquisition contracts for the system, system component, or system service
-list of supply chain threats
-list of safeguards to be taken against supply chain threats
-system life cycle documentation
-inter-organizational agreements and procedures
-system security plan
-privacy plan
-privacy program plan
-other relevant documents or records
-Organizational personnel with acquisition responsibilities
-organizational personnel with information security and privacy - responsibilities
-organizational personnel with supply chain risk management responsibilities
-Organizational processes for defining and documenting the system development - life cycle (SDLC)
-organizational processes for identifying SDLC roles and responsibilities
-organizational processes for integrating supply chain risk management into - the SDLC
-mechanisms supporting and/or implementing the SDLC
-the personnel, roles, and responsibilities of the supply chain risk - management team are defined;
-supply chain risk management activities are defined;
-Establish a supply chain risk management team consisting of
To implement supply chain risk management plans, organizations establish a - coordinated, team-based approach to identify and assess supply chain risks - and manage these risks by using programmatic and technical mitigation - techniques. The team approach enables organizations to conduct an analysis - of their supply chain, communicate with internal and external partners or - stakeholders, and gain broad consensus regarding the appropriate resources - for SCRM. The SCRM team consists of organizational personnel with diverse - roles and responsibilities for leading and supporting SCRM activities, - including risk executive, information technology, contracting, information - security, privacy, mission or business, legal, supply chain and logistics, - acquisition, business continuity, and other relevant functions. Members of - the SCRM team are involved in various aspects of the SDLC and, collectively, - have an awareness of and provide expertise in acquisition processes, legal - practices, vulnerabilities, threats, and attack vectors, as well as an - understanding of the technical aspects and dependencies of systems. The SCRM - team can be an extension of the security and privacy risk management - processes or be included as part of an organizational risk management team.
-a supply chain risk management team consisting of
Supply chain risk management policy
-supply chain risk management procedures
-supply chain risk management team charter documentation
-supply chain risk management strategy
-supply chain risk management implementation plan
-procedures addressing supply chain protection
-system security plan
-privacy plan
-other relevant documents or records
-Organizational personnel with acquisition responsibilities
-organizational personnel with information security and privacy - responsibilities
-organizational personnel with supply chain risk management - responsibilities
-organizational personnel with enterprise risk management responsibilities
-legal counsel
-organizational personnel with business continuity responsibilities
-the system or system component requiring a process or processes to identify - and address weaknesses or deficiencies is defined;
-supply chain personnel with whom to coordinate the process or processes to - identify and address weaknesses or deficiencies in the supply chain elements - and processes is/are defined;
-supply chain controls employed to protect against supply chain risks to the - system, system component, or system service and to limit the harm or - consequences from supply chain-related events are defined;
-the document identifying the selected and implemented supply chain processes - and controls is defined (if selected);
-Establish a process or processes to identify and address weaknesses or
- deficiencies in the supply chain elements and processes of
Employ the following controls to protect against supply chain risks to the
- system, system component, or system service and to limit the harm or
- consequences from supply chain-related events:
Document the selected and implemented supply chain processes and controls in
Supply chain elements include organizations, entities, or tools employed for the - research and development, design, manufacturing, acquisition, delivery, - integration, operations and maintenance, and disposal of systems and system - components. Supply chain processes include hardware, software, and firmware - development processes; shipping and handling procedures; personnel security and - physical security programs; configuration management tools, techniques, and - measures to maintain provenance; or other programs, processes, or procedures - associated with the development, acquisition, maintenance and disposal of - systems and system components. Supply chain elements and processes may be - provided by organizations, system integrators, or external providers. Weaknesses - or deficiencies in supply chain elements or processes represent potential - vulnerabilities that can be exploited by adversaries to cause harm to the - organization and affect its ability to carry out its core missions or business - functions. Supply chain personnel are individuals with roles and - responsibilities in the supply chain.
-a process or processes is/are established to identify and address
- weaknesses or deficiencies in the supply chain elements and processes of
the process or processes to identify and address weaknesses or
- deficiencies in the supply chain elements and processes of
the selected and implemented supply chain processes and controls are
- documented in
Supply chain risk management policy
-supply chain risk management procedures
-supply chain risk management strategy
-supply chain risk management plan
-systems and critical system components inventory documentation
-system and services acquisition policy
-system and services acquisition procedures
-procedures addressing the integration of information security and privacy - requirements into the acquisition process
-solicitation documentation
-acquisition documentation (including purchase orders)
-service level agreements
-acquisition contracts for systems or services
-risk register documentation
-system security plan
-privacy plan
-other relevant documents or records
-Organizational personnel with acquisition responsibilities
-organizational personnel with information security and privacy - responsibilities
-organizational personnel with supply chain risk management responsibilities
-Organizational processes for identifying and addressing supply chain element - and process deficiencies
-acquisition strategies, contract tools, and procurement methods to protect - against, identify, and mitigate supply chain risks are defined;
-Employ the following acquisition strategies, contract tools, and procurement
- methods to protect against, identify, and mitigate supply chain risks:
The use of the acquisition process provides an important vehicle to protect the - supply chain. There are many useful tools and techniques available, including - obscuring the end use of a system or system component, using blind or filtered - buys, requiring tamper-evident packaging, or using trusted or controlled - distribution. The results from a supply chain risk assessment can guide and - inform the strategies, tools, and methods that are most applicable to the - situation. Tools and techniques may provide protections against unauthorized - production, theft, tampering, insertion of counterfeits, insertion of malicious - software or backdoors, and poor development practices throughout the system - development life cycle. Organizations also consider providing incentives for - suppliers who implement controls, promote transparency into their processes and - security and privacy practices, provide contract language that addresses the - prohibition of tainted or counterfeit components, and restrict purchases from - untrustworthy suppliers. Organizations consider providing training, education, - and awareness programs for personnel regarding supply chain risk, available - mitigation strategies, and when the programs should be employed. Methods for - reviewing and protecting development plans, documentation, and evidence are - commensurate with the security and privacy requirements of the organization. - Contracts may specify documentation protection requirements.
-Supply chain risk management policy
-supply chain risk management procedures
-supply chain risk management plan
-system and services acquisition policy
-system and services acquisition procedures
-procedures addressing supply chain protection
-procedures addressing the integration of information security and privacy - requirements into the acquisition process
-solicitation documentation
-acquisition documentation (including purchase orders)
-service level agreements
-acquisition contracts for systems, system components, or services
-documentation of training, education, and awareness programs for personnel - regarding supply chain risk
-system security plan
-privacy plan
-other relevant documents or records
-Organizational personnel with acquisition responsibilities
-organizational personnel with information security and privacy - responsibilities
-organizational personnel with supply chain risk management responsibilities
-Organizational processes for defining and employing tailored acquisition - strategies, contract tools, and procurement methods
-mechanisms supporting and/or implementing the definition and employment of - tailored acquisition strategies, contract tools, and procurement methods
-the frequency at which to assess and review the supply chain-related risks - associated with suppliers or contractors and the systems, system components, - or system services they provide is defined;
-Assess and review the supply chain-related risks associated with suppliers or
- contractors and the system, system component, or system service they provide
An assessment and review of supplier risk includes security and supply chain risk - management processes, foreign ownership, control or influence (FOCI), and the - ability of the supplier to effectively assess subordinate second-tier and - third-tier suppliers and contractors. The reviews may be conducted by the - organization or by an independent third party. The reviews consider documented - processes, documented controls, all-source intelligence, and publicly available - information related to the supplier or contractor. Organizations can use - open-source information to monitor for indications of stolen information, poor - development and quality control practices, information spillage, or - counterfeits. In some cases, it may be appropriate or required to share - assessment and review results with other organizations in accordance with any - applicable rules, policies, or inter-organizational agreements or contracts.
-the supply chain-related risks associated with suppliers or contractors and the
- systems, system components, or system services they provide are assessed and
- reviewed
Supply chain risk management policy and procedures
-supply chain risk management strategy
-supply chain risk management plan
-system and services acquisition policy
-procedures addressing supply chain protection
-procedures addressing the integration of information security requirements - into the acquisition process
-records of supplier due diligence reviews
-system security plan
-other relevant documents or records
-Organizational personnel with system and services acquisition - responsibilities
-organizational personnel with information security responsibilities
-organizational personnel with supply chain protection responsibilities
-Organizational processes for conducting supplier reviews
-mechanisms supporting and/or implementing supplier reviews
-information for which agreements and procedures are to be established are - defined (if selected);
-Establish agreements and procedures with entities involved in the supply chain
- for the system, system component, or system service for the
The establishment of agreements and procedures facilitates communications among - supply chain entities. Early notification of compromises and potential - compromises in the supply chain that can potentially adversely affect or have - adversely affected organizational systems or system components is essential for - organizations to effectively respond to such incidents. The results of - assessments or audits may include open-source information that contributed to a - decision or result and could be used to help the supply chain entity resolve a - concern or improve its processes.
-agreements and procedures are established with entities involved in the supply
- chain for the system, system components, or system service for
Supply chain risk management policy and procedures
-supply chain risk management plan
-system and services acquisition policy
-procedures addressing supply chain protection
-acquisition documentation
-service level agreements
-acquisition contracts for the system, system component, or system service
-inter-organizational agreements and procedures
-system security plan
-other relevant documents or records
-Organizational personnel with system and service acquisition responsibilities
-organizational personnel with information security responsibilities
-organizational personnel with supply chain risk management responsibilities
-Organizational processes for establishing inter-organizational agreements and - procedures with supply chain entities
-systems or system components that require inspection are defined;
-frequency at which to inspect systems or system components is defined (if - selected);
-indications of the need for an inspection of systems or system components are - defined (if selected);
-Inspect the following systems or system components
The inspection of systems or systems components for tamper resistance and - detection addresses physical and logical tampering and is applied to systems and - system components removed from organization-controlled areas. Indications of a - need for inspection include changes in packaging, specifications, factory - location, or entity in which the part is purchased, and when individuals return - from travel to high-risk locations.
-Supply chain risk management policy and procedures
-supply chain risk management plan
-system and services acquisition policy
-records of random inspections
-inspection reports/results
-assessment reports/results
-acquisition documentation
-service level agreements
-acquisition contracts for the system, system component, or system service
-inter-organizational agreements and procedures
-system security plan
-other relevant documents or records
-Organizational personnel with system and services acquisition - responsibilities
-organizational personnel with information security responsibilities
-organizational personnel with supply chain risk management responsibilities
-Organizational processes for establishing inter-organizational agreements and - procedures with supply chain entities
-organizational processes to inspect for tampering
-external reporting organizations to whom counterfeit system components are to - be reported is/are defined (if selected);
-personnel or roles to whom counterfeit system components are to be reported - is/are defined (if selected);
-Develop and implement anti-counterfeit policy and procedures that include the - means to detect and prevent counterfeit components from entering the system; - and
-Report counterfeit system components to
Sources of counterfeit components include manufacturers, developers, vendors, and - contractors. Anti-counterfeiting policies and procedures support tamper - resistance and provide a level of protection against the introduction of - malicious code. External reporting organizations include CISA.
-an anti-counterfeit policy is developed and implemented;
- -anti-counterfeit procedures are developed and implemented;
- -the anti-counterfeit procedures include the means to detect counterfeit - components entering the system;
- -the anti-counterfeit procedures include the means to prevent counterfeit - components from entering the system;
- -counterfeit system components are reported to
Supply chain risk management policy and procedures
-supply chain risk management plan
-system and services acquisition policy
-anti-counterfeit plan
-anti-counterfeit policy and procedures
-media disposal policy
-media protection policy
-incident response policy
-reports notifying developers, manufacturers, vendors, contractors, and/or - external reporting organizations of counterfeit system components
-acquisition documentation
-service level agreements
-acquisition contracts for the system, system component, or system service
-inter-organizational agreements and procedures
-records of reported counterfeit system components
-system security plan
-other relevant documents or records
-Organizational personnel with system and service acquisition responsibilities
-organizational personnel with information security responsibilities
-organizational personnel with supply chain risk management responsibilities
-organizational personnel with responsibilities for anti-counterfeit policies, - procedures, and reporting
-Organizational processes for counterfeit prevention, detection, and reporting
-mechanisms supporting and/or implementing anti-counterfeit detection, - prevention, and reporting
-personnel or roles requiring training to detect counterfeit system - components (including hardware, software, and firmware) is/are defined;
-Train
None.
-Supply chain risk management policy and procedures
-supply chain risk management plan
-system and services acquisition policy
-anti-counterfeit plan
-anti-counterfeit policy and procedures
-media disposal policy
-media protection policy
-incident response policy
-training materials addressing counterfeit system components
-training records on the detection and prevention of counterfeit - components entering the system
-system security plan
-other relevant documents or records
-Organizational personnel with information security responsibilities
-organizational personnel with supply chain risk management - responsibilities
-organizational personnel with responsibilities for anti-counterfeit - policies, procedures, and training
-Organizational processes for anti-counterfeit training
-system components requiring configuration control are defined;
-Maintain configuration control over the following system components awaiting
- service or repair and serviced or repaired components awaiting return to
- service:
None.
-configuration control over
configuration control over serviced or repaired
Supply chain risk management policy and procedures
-supply chain risk management plan
-configuration control procedures
-acquisition documentation
-service level agreements
-acquisition contracts for the system component
-inter-organizational agreements and procedures
-system security plan
-other relevant documents or records
-Organizational personnel with system and services acquisition - responsibilities
-organizational personnel with information security responsibilities
-organizational personnel with supply chain risk management - responsibilities
-Organizational processes for establishing inter-organizational agreements - and procedures with supply chain entities
-organizational configuration control processes
-data, documentation, tools, or system components to be disposed of are - defined;
-techniques and methods for disposing of data, documentation, tools, or system - components are defined;
-Dispose of
Data, documentation, tools, or system components can be disposed of at any time - during the system development life cycle (not only in the disposal or retirement - phase of the life cycle). For example, disposal can occur during research and - development, design, prototyping, or operations/maintenance and include methods - such as disk cleaning, removal of cryptographic keys, partial reuse of - components. Opportunities for compromise during disposal affect physical and - logical data, including system documentation in paper-based or digital files; - shipping and delivery documentation; memory sticks with software code; or - complete routers or servers that include permanent media, which contain - sensitive or proprietary information. Additionally, proper disposal of system - components helps to prevent such components from entering the gray market.
-Supply chain risk management policy and procedures
-supply chain risk management plan
-disposal procedures addressing supply chain protection
-media disposal policy
-media protection policy
-disposal records for system components
-documentation of the system components identified for disposal
-documentation of the disposal techniques and methods employed for system - components
-system security plan
-other relevant documents or records
-Organizational personnel with system component disposal responsibilities
-organizational personnel with information security responsibilities
-organizational personnel with supply chain protection responsibilities
-Organizational techniques and methods for system component disposal
-mechanisms supporting and/or implementing system component disposal
-Federal Acquisition Supply Chain Security Act; Rule,85 Federal - Register 54263 (September 1, 2020), pp 54263-54271.
This system acts as a link shortener for IFA employees
-This system maintains a set of user-provided links and their associated - shortlinks
-Maliciously modified links are a concern
-This section describes an attached diagram of the authorization boundary for IFA GoodRead Project's information system.
-This section describes an attached diagram of the network architecture for IFA GoodRead Project's information system.
-This section describes an attached diagram of various dataflows for application and related elements of the IFA GoodRead Project's information system.
-The developer of the application supports IFA Public Affairs Officers by administering the application and its infrastructure.
-IFA Public Affairs Officers (PAOs) in each division of the agency review public communications to citizens who are customers of the IFA. PAOs review requests from colleagues to generate and publish content that is the target of a shortlink and can unpublish shortlinks.
-The general public is free to click on shortlinks
-IFA develops, operates, and maintains the GoodRead link shortener system to
-This is the custom GoodRead application within the system.
-This is the web application framework upon which the developer writes the custom GoodRead application for the user interface and API of this system.
-This is the database for the custom GoodRead application within the system.
-This is the operating system for the web server that runs the custom GoodRead application within the system.
-This inventory item is an instance from the AwesomeCloud Awesome Compute Service (ACS) Service. It is a Linux server.
-This inventory item is an instance from the AwesomeCloud Awesome Load Balancer (ALB) Service. It is a Linux server.
-This is the control implementation for the application and infrastructure that compose to the IFA GoodRead Project's system.
-The IFA GoodRead application and infrastructure are composed as designed and implemented with lease privilege for the elements of this system.
-For the IFA GoodRead application, the custom application is designed and implemented on top of the Django Framework to enforce least privilege. The application has a role for IFA Public Affairs Officers and one for the developers for privileged permissions, respectively. Only the latter can access or change administrative and security configurations and related data.
-The Django Framework and Django REST Framework (DRF), by default, allows any user with the is_staff role attribute to access administrative functions in an application using the framework. IFA GoodRead developers have disabled this behavior, relying on the custom roles identified in the relevant section.
For the IFA GoodRead database, the system account and accredentials for the application to read and write to the system datastore has specific read and write authorization for specific tables. This database service account does not have full administrative permissions to add, modify, or delete all respective tables. For the production environment, only the IFA GoodRead developer has a dedicated account with equivalent permissions. Only local network socket access, within in the Linux server, is permitted by host firewall configuration. Remote access, privileged or unprivileged, is not allowed remotely and the system engineer must locally authenticate for access.
-For the RedHat Linux server upon which the IFA GoodRead application is deployed in this system, only the system engineer has a non-privileged user to log in remotely via the SSH protocol to perform ad-hoc inspection, monthly log review as required by policy and procedure, and emergency debugging of the system. Privileged system administration operations may only be performed with the sudo subsystem which requires a password, two-factor authentication, and has enhanced logging of all commands executed. The system engineer must log in remotely and then use sudo to elevate privileges. Remote access with the privileged account is prohibited by configuration and attempts are logged.
For this remote SSH access, least privilege is additionally enforced by allowing this access via a specific network zone in the IFA GoodRead AwesomeCloud account accessible to only the system engineer via IFA's VPN solution, which requires the system engineer use a dedicated account with their own password and two-factor authentication token.
-For cloud account and API access to reconfigure the Linux server and its load balancer, administrative access is only allowed for the system engineer via a special AwesomeCloud IAM role. The authentication and authorization for this role is controlled by an integration with the organization's single sign-on solution. This solution will only be accessible and correctly execute for them when they are on the VPN with their account with traffic forwarded to the appropriate network zone in the IFA GoodRead account in AwesomeCloud. It will not work the developer or any staff users of the application.
-An organizational official responsible for the procurement, development, integration, + modification, operation, maintenance, and disposal of a system.
+A senior official or executive with the authority to formally assume responsibility and + accountability for operating a system. The AO must grant this system an authorization to + operate.
+An organizational official responsible for carrying out the chief information officer + security responsibilities under FISMA, and serving as the primary liaison for the chief + information officer to the organization’s authorizing officials, system owners, common + control providers, and system security officers.
+An individual, group, or organization responsible for setting up and maintaining a system + or specific system elements.
+An individual or (system) process acting on behalf of an individual that is authorized to + access information and information systems to perform assigned duties.
+This title must be kept as-is to match FedRAMP Marketplace listing. This is a a + FedRAMP requirement. This official mailing address of Amazon's AWS commercial + offering for the us-east-1 is provided, as Amazon not disclose the address of + data-centers either on a region or availability zone basis.
+IaaS Service Provider.
+This person is a member of IaaS AWS.
+This person is a member of Organization Two.
+This person is the CISO responsible for securing the Leveraged IaaS.
+This person is a member of AWS.
+System ownership assigned to this person.
+Information Security responsibilities assigned to CISO
+Authorizing Official's Designated Representative role assigned to Alice Officione.
+AWS Managed Blockchain's (AMB) system administrator
+The import-profile href points to a OSCAL-based profile data model that was custom-created + specifically for this system by ATO as a Service. A back-matter + reference can be included for further details.
+Amazon Web Services (AWS) Cloud SSP that is utilized as a leveraged authorization.
+TBD: Data flow description.
+The AWS deployment of the Hyperledger Fabric v2.2.3 managed by AWS and made available as + an IaaS system.
+AWS US East/West
+The following implemented requirements are a subset of the controls implemented by this + system.
+For the sake of bravety, this SSP is not documenting all implemented controls.
+The focus is on the controls that are provided and can be inherited by the AWS Managed + Blockchain (AMB).
+TBD:
+The AMB manages access control to the infrastructure for the AWS authorized personnel.
+Consumer's responsible parties can be included in an Access Control List (ACL) used by AWS to grant access to AMB infrastructure for administrative reasons.
+Responsible parties' account management and ACL update are Consumer's responsibilities.
+The AMB manages access control to the infrastructure for the Consumer's responsible parties identified in an Access Control List (ACL)
+It is Customer's responsibility to identify the responsible parties which need access to the AMB infractrusture and their roles, and to update the ACL used by AMB to enforce access to the resources.
+TBD:
+TBD:
+TBD:
+Insert a remark if needed
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+Maintenance (MA)
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+Maintenance (MA)
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+Maintenance (MA)
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+Maintenance (MA)
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+Maintenance (MA)
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+Maintenance (MA)
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+Maintenance (MA)
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+Maintenance (MA)
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+Maintenance (MA)
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+Maintenance (MA)
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+Maintenance (MA)
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+Maintenance (MA)
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+Maintenance (MA)
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.Â
+Media Protection (MP)
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+Media Protection (MP)
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+Media Protection (MP)
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+Media Protection (MP)
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+Media Protection (MP)
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+Media Protection (MP)
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+Media Protection (MP)
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+Media Protection (MP)
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+Media Protection (MP)
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+Media Protection (MP)
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+Media Protection (MP)
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+Media Protection (MP)
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+Physical and Environmental Protection (PE)
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+Physical and Environmental Protection (PE)
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+Physical and Environmental Protection (PE)
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+Physical and Environmental Protection (PE)
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+Physical and Environmental Protection (PE)
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+Physical and Environmental Protection (PE)
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+Physical and Environmental Protection (PE)
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+Physical and Environmental Protection (PE)
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+Physical and Environmental Protection (PE)
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+Physical and Environmental Protection (PE)
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+Physical and Environmental Protection (PE)
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+Physical and Environmental Protection (PE)
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+Physical and Environmental Protection (PE)
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+Physical and Environmental Protection (PE)
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+Physical and Environmental Protection (PE)
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+Physical and Environmental Protection (PE)
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+Physical and Environmental Protection (PE)
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+Physical and Environmental Protection (PE)
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+Physical and Environmental Protection (PE)
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+Physical and Environmental Protection (PE)
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+Physical and Environmental Protection (PE)
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+Physical and Environmental Protection (PE)
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+Physical and Environmental Protection (PE)
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+Physical and Environmental Protection (PE)
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+Physical and Environmental Protection (PE)
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+Physical and Environmental Protection (PE)
+This control associated with hardware components within AWS is generally either + partially or fully inherited from the AWS physical infrastructure. For the U.S. + East, U.S. West, and GovCloud regions, this control is inherited from pre-existing + Agency Authority to Operate (ATO) or JAB provisional Authority to Operate.
+The customer organization is responsible for any part of the control that is + applicable to customer-controlled equipment and facilities, and the customer's + configurable portion of the AWS logical infrastructure, including the Operating + systems on EC2 instances and the customer's applications.
+Physical and Environmental Protection (PE)
+The individual within the organization who is ultimately accountable for everything related to the deployment, assessemnt, authorization and operations of the Blossom Member which provides the software assets leasing service (here in known as "this system").
+The individual within the service provider organization who is accountable for managing the pool of software resources made available for leasing to USG agencies.
+The License Owner role exists only within the service provider agency.
+The individual or individuals who are ultimatly accountable for reviewing the assessemnt package, discuss with the SO the findings and grant an authorization to operate (ATO) to "this system".
+The Authorizing Official is the only entity responsible for the security posture of the system that gets access to the ATO channel (chainecode). The AO signs the MOU on behalf of the agency.
+The individual accountable for assessing the security posture of the system on behalf of the system owner.
+The individual accountable for managing leased licenses (checkout, install, uninstall, return).
+The individual accountable for the deployment, configuration, testing and operations of the system on behalf of the System Owner.
+NIST ITL Computer Security Division's Secure Systems and Applications Group is + the primary CSP for this project.
+This title must be kept as-is to match FedRAMP Marketplace listing. This is a a + FedRAMP requirement. This official mailing address of Amazon's AWS commercial + offering for the us-east-1 is provided, as Amazon not disclose the address of + data-centers either on a region or availability zone basis.
+Blossom network provider.
+The party responsible to assess the security controls on behalf of the system owner.
+Manages leased liceses for the agency and is responsible to checkout, install, uninstall and return licenses to the pool for each order the agency places.
+This party has development, deployment, configuration and operations responsibilities for "this system" supporting the system owner.
+This SSP was created using a simplified version of OSCAL-based FedRAMP SSP Template + for the FedRAMP Low, Moderate, and High baselines.
+This example points to the tailored FedRAMP Moderate 800-53 rev 5 baseline, adjusted + accordingly for BloSS@M.
+TBD: Describe the purpose and functions of this system here.
+BloSS@M stores the minimally required identity and authorization metadata to + authenitcate and authorize federal users of the system.
+The NIST Privacy Office and Office of Information Systems Management + categorizes personal identity and authentication information with as + FIPS-199 Low impact for integrity concerns. + This categorization is limited to federal employees when this data is + for identification of these federal employees only.
+TBD
+TBD
+TBD
+TBD
+TBD
+TBD
+TBD:
+TBD
+This information has no base recommendation in SP 800-60 Volume 2 + Revision 1 guidance. + The Office of Information Systems Management's consulted the BloSS@M + Team and the NIST system owner, who categorized this information sharing + at FIPS-199 Moderate impact.
+This information has no base recommendation in SP 800-60 Volume 2 + Revision 1 guidance. + The Office of Information Systems Management's consulted the BloSS@M + Team and the NIST system owner, who categorized this information sharing + at FIPS-199 Moderate impact.
+This information has no base recommendation in SP 800-60 Volume 2 + Revision 1 guidance. + The Office of Information Systems Management's consulted the BloSS@M + Team and the NIST system owner, who categorized this information sharing + at FIPS-199 Moderate impact.
+TBD
+TBD
+TBD
+TBD: A holistic, top-level explanation of the system's authorization boundary.
+A diagram-specific explanation.
+A holistic, top-level explanation of the network architecture.
+A diagram-specific explanation.
+A holistic, top-level explanation of the system's data flows.
+A diagram-specific explanation.
+TBD: ssp-uuid: 73a7ca56-ac02-43b9-8664-62bcb05a7e91 will need to be added for + oscal 1.2.0.
+The leveraged authorization assembly is supposed to have a required uuid flag + instead of an optional id flag. This will be fixed in the syntax shortly.
+Use one leveraged-authorization assembly for each underlying system. (In the + legacy world, these may be general support systems.
+The link fields are optional, but preferred where known. Often, a leveraging + system's SSP author will not have access to the leveraged system's SSP, but + should have access to the leveraged system's CRM.
+The entire Blossom system as depicted in the system authorization boundary
+TBD: If the leveraged system owner provides a UUID for their system (such as in
+ an OSCAL-based CRM), it should be reflected in the inherited-uuid
+ property.
TBD: Description of Blossom inventory items 1
+FedRAMP SSP Template Section 13
+This description field is required by OSCAL.
+FedRAMP does not require any specific information here.
+AMB provides access control to the infrastracter for the entities identified below. The Consumer's responsibility is to update the ACL ith the identities authorized to access the resource.
+TBD: Describe any customer-configured requirements for satisfying this control.
+The NGAC implementation in the two chaincodes manages the access control for the Blossom business layer users and the BC Member's ATO-related accounts.
+The system has privileged and non-privileged accounts associated with the business layer and the ATO processes.
+These accounts are managed by the NGAC implementation in the chaincodes for the ATO and for the assets management (business) processes.
+The following accounts are supported for the business operations (assets management):
+The following account is supported for the ATO process (ATO attestation submission and review of other Blossom members):
+The accounts of the Blossom Member managed by the Leveraged AWS IaaS are:
+TBD: provided-uuid needs to match the one in the AWS' SSP.
+All privileged and non-privileged accounts that are granted access to the AWS infrastructure and are responsible for the Blossom member (this sysstem), are managed by the AWS IaaS (leveraged ATO system) which uses an Access Control List (ACL) for the NIST employees assigned Blossom roles.
+For all responsible parties with roles managed by the AWS IaaS system, accounts creation/deletion are requested, approved/revoked by the System Owner or the Blossom PM and are added to or delete from the ACL list.
+Assign account managers
+Require
Specify:
+Authorized users of the system
+Group and role membership
+Access authorizations (i.e., privileges) and
Require approvals by
Create, enable, modify, disable, and remove accounts in accordance with
Monitor the use of accounts;
+Notify account managers and
Notify account managers and
Authorize access to the system based on:
+A valid access authorization;
+Intended system usage;
+Review accounts for compliance with account management requirements
Establish and implement a process for changing shared or group account authenticators (if deployed) when individuals are removed from the group;
+Align account management processes with personnel termination and transfer processes.
+National Institute of Standards and Technology's Logo
+May use rlink with a relative path, or embedded as base64
+ .
FedRAMP prefers base64 for images and diagrams.
Images must be in sufficient resolution to read all detail when rendered in a + browser via HTML5.
+The primary authorization boundary diagram.
+Section 9.2, Figure 9-1 Authorization Boundary Diagram (graphic)
+This should be referenced in the + system-characteristics/authorization-boundary/diagram/link/@href flag using a + value of "#d2eb3c18-6754-4e3a-a933-03d289e3fad5"
+May use rlink with a relative path, or embedded as base64
+ .
FedRAMP prefers base64 for images and diagrams.
Images must be in sufficient resolution to read all detail when rendered in a + browser via HTML5.
+The primary network diagram.
+Section 9.4, Figure 9-2 Network Diagram (graphic)
+This should be referenced in the + system-characteristics/network-architecture/diagram/link/@href flag using a + value of "#61081e81-850b-43c1-bf43-1ecbddcb9e7f"
+May use rlink with a relative path, or embedded as base64
+ .
FedRAMP prefers base64 for images and diagrams.
Images must be in sufficient resolution to read all detail when rendered in a + browser via HTML5.
+Table 15-1 Attachments: Privacy Impact Assessment
+May use rlink with a relative path, or embedded as base64
+ .