nist_satellite6.yml

policy: NIST
title: Configuration Recommendations for Satellite 6
id: nist_satellite6
version: Revision 4
source: https://www.fedramp.gov/assets/resources/documents/FedRAMP_Security_Controls_Baseline.xlsx
levels:
- id: low
- id: moderate
- id: high
controls:
- id: AC-1
  status: not applicable
  notes: |-
    Section a: (O) The organization will be responsible for developing, documenting,
    and disseminating access control policy and procedures. A successful
    control response will need to address the content of the policy (which
    must include purpose, scope, roles, responsibilities, management
    commitment, coordination, and compliance) and procedures (which must
    facilitate the implementation of the policies and associated controls).
    Section a.1: (O) The organization will be responsible for developing, documenting,
    and disseminating an access control policy that addresses purpose,
    scope, roles, responsibilities, management commitment, coordination
    among organizational entities, and compliance. A successful control
    response will need to address the content of the policy (which must
    include purpose, scope, roles, responsibilities, management commitment,
    coordination, and compliance).
    Section a.2: (O) The organization will be responsible for developing, documenting,
    and disseminating the procedures to facilitate the implementation of the
    access control policy and associated access controls. A successful
    control response will need to address the procedures (which must
    facilitate the implementation of the policies and associated controls).
    Section b: (O) The organization will be responsible for reviewing and updating the
    current access control policies and procedures. A successful control
    response will need to address the review and update process, including
    the role(s) responsible for initiating the review process, updating the
    policy and procedures, and providing approval of the updates.
    Section b.1: (O) The organization will be responsible for reviewing and updating the
    current access control policies. A successful control response will need
    to address the review and update process, including the role(s)
    responsible for initiating the review process, updating the policy, and
    providing approval of the updates.
    Section b.2: (O) The organization will be responsible for reviewing and updating the
    current access control procedures. A successful control response will
    need to address the review and update process, including the role(s)
    responsible for initiating the review process, updating the procedures,
    and providing approval of the updates.
  rules: []
  description: "The organization:\n a. Develops, documents, and disseminates to [Assignment:\
    \ organization-defined personnel or roles]:\n   1. An access control policy that\
    \ addresses purpose, scope, roles, responsibilities, management commitment, coordination\
    \ among organizational entities, and compliance; and\n   2. Procedures to facilitate\
    \ the implementation of the access control policy and associated access controls;\
    \ and\n b. Reviews and updates the current:\n   1. Access control policy [Assignment:\
    \ organization-defined frequency]; and\n   2. Access control procedures [Assignment:\
    \ organization-defined frequency].\n\nSupplemental Guidance: This control addresses\
    \ the establishment of policy and procedures for the effective implementation\
    \ of selected security controls and control enhancements in the AC family. Policy\
    \ and procedures reflect applicable federal laws, Executive Orders, directives,\
    \ regulations, policies, standards, and guidance. Security program policies and\
    \ procedures at the organization level may make the need for system-specific policies\
    \ and procedures unnecessary. The policy can be included as part of the general\
    \ information security policy for organizations or conversely, can be represented\
    \ by multiple policies reflecting the complex nature of certain organizations.\
    \ The procedures can be established for the security program in general and for\
    \ particular information systems, if needed. \n\nThe organizational risk management\
    \ strategy is a key factor in establishing policy and procedures. Related control:\
    \ PM-9.\nControl Enhancements: None.\nReferences: NIST Special Publications 800-12,\
    \ 800-100.\n\nAC-1 (b) (1) [at least annually] \nAC-1 (b) (2) [at least annually\
    \ or whenever a significant change occurs]"
  title: >-
    AC-1 - ACCESS CONTROL POLICY AND PROCEDURES
  levels:
  - high
  - moderate
  - low
- id: AC-2
  status: not applicable
  notes: |-
    Section a: (O) The organization will be responsible for identifying and selecting
    the types of accounts required to support the organizations application.
    Examples of account types include individual, shared, group, system,
    guest/anonymous, emergency, developer/manufacturer/vendor, temporary,
    and service. A successful control response will need to address the
    specific requirements fulfulled by each account type in use.
    Section b: (O) The organization will be responsible for assigning account managers,
    who will have responsibilities related to the creation, management, and
    removal of accounts. A successful control response will need to discuss
    how account managers are identified within the organization.
    Section c: (O) The organization will be responsible for setting conditions for
    group and role memberships. A successful control response will need to
    outline these conditions and how they are enforced.
    Section d: (O) The organization will be responsible for specifying authorized
    users, group and role memberships, and privileges for each account. A
    successful control response will need to addess the process by which
    authorized users are specified and privilege levels are determined.
    Section e: (O) The organization will be responsible for requiring approval by
    designated personnel or roles prior to creating information system
    accounts. A successful control response will need to outline the
    personnel or roles responsible for approving information system accounts
    and the process by which those personnel or roles are notified and
    approval is granted.
    Section f: (O) The organization will be repsonsible for defining and enforcing
    procedures or conditions for the creation, management, and removal of
    information system accounts. A successful control response will outline
    the conditions for each action and the tools or procedures used to
    enforce those conditions.
    Section g: (O) The organization will be responsible for monitoring the use of
    information system accounts. This may include reviewing records of
    account management activities. A successful control response will relate
    the monitoring activities required for this control to the auditing
    activities in the AU control family.
    Section h: (O) The organization will be responsible for notifying account managers
    when triggering events occur. A successful control response will need to
    address the methods by which these triggering events are identified and
    the managers are notified.
    Section h.1: (O) The organization will be responsible for notifying account managers
    when accounts are no longer required. A successful control response will
    need to address the methods by which this triggering event is identified
    and the managers are notified.
    Section h.2: (O) The organization will be responsible for notifying account managers
    when when users are terminated. A successful control response will need
    to address the methods by which this triggering event is identified and
    the managers are notified.
    Section h.3: (O) The organization will be responsible for notifying account managers
    when when system usage or need-to-know changes. A successful control
    response will need to address the methods by which this triggering event
    is identified and the managers are notified.
    Section i: (O) The organization will be responsible for authorizing access to the
    organizations information system based on a valid access authorization.
    A successful control response will need to address ensuring that all
    accounts are granted access based on a valid authorization.
    Section i.1: (O) The organization will be responsible for authorizing access to the
    organizations application. A successful control response will need to
    address ensuring that all accounts are granted access based on a valid
    authorization.
    Section i.2: (O) The organization will be responsible for authorizing access to the
    organizations application based on . A successful control response will
    need to address ensuring that all accounts are granted access based on a
    valid authorization for a specific intended usage.
    Section i.3: (O) The organization will be responsible for authorizing access to the
    organizations application. A successful control response will need to
    address ensuring that all accounts are granted access based on a valid
    authorization for a specific intended usage.
    Section j: (O) The organization will be responsible for reviewing accounts for
    compliance with account management requirements at the specified
    frequency. A successful control response will need to address the
    process used to review accounts, the means by which compliance is
    verified, and the process for remediation of any accounts found not to
    be in compliance.
    Section k: (O) The organization will be responsible for reissing shared/group
    account credentials when individuals are removed from the group. A
    successful control response will need to discuss how a triggering event
    is notified, what the process and timeframe for reissuing credentials
    is, and how the process is enforced.
  rules: []
  description: |-
    The organization:
     a. Identifies and selects the following types of information system accounts to support organizational missions/business functions: [Assignment: organization-defined information system account types];
     b. Assigns account managers for information system accounts;
     c. Establishes conditions for group and role membership;
     d. Specifies authorized users of the information system, group and role membership, and access authorizations (i.e., privileges) and other attributes (as required) for each account;
     e. Requires approvals by [Assignment: organization-defined personnel or roles] for requests to create information system accounts;
     f. Creates, enables, modifies, disables, and removes information system accounts in accordance with [Assignment: organization-defined procedures or conditions];
     g. Monitors the use of, information system accounts;
     h. Notifies account managers:
       1. When accounts are no longer required;
       2. When users are terminated or transferred; and
       3. When individual information system usage or need-to-know changes;
     i. Authorizes access to the information system based on:
       1. A valid access authorization;
       2. Intended system usage; and
       3. Other attributes as required by the organization or associated missions/business functions;
     j. Reviews accounts for compliance with account management requirements [Assignment: organization-defined frequency]; and
     k. Establishes a process for reissuing shared/group account credentials (if deployed) when individuals are removed from the group.
    Supplemental Guidance: Information system account types include individual, shared, group, system, guest/anonymous, emergency, developer/manufacturer/vendor, temporary, and service. Some of the account management requirements listed above can be implemented by organizational information systems. The identification of authorized users of the information system and the specification of access privileges reflects the requirements in other security controls in the security plan. Users requiring administrative privileges on information system accounts receive additional scrutiny by appropriate organizational personnel (e.g., system owner, mission/business owner, or chief information security officer) responsible for approving such accounts and privileged access. Organizations may choose to define access privileges or other attributes by account, by type of account, or a combination of both. Other attributes required for authorizing access include, for example, restrictions on time-of-day, day-of-week, and point-of-origin. In defining other account attributes, organizations consider system-related requirements (e.g., scheduled maintenance, system upgrades) and mission/business requirements, (e.g., time zone differences, customer requirements, remote access to support travel requirements). Failure to consider these factors could affect information system availability. Temporary and emergency accounts are accounts intended for short-term use. Organizations establish temporary accounts as a 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 (e.g., local logon accounts used for special tasks defined by organizations or when network resources are unavailable). Such accounts remain available and are not subject to automatic disabling or removal dates. Conditions for disabling or deactivating accounts include, for example: (i) when shared/group, emergency, or temporary accounts are no longer required; or (ii) when individuals are transferred or terminated. Some types of information system accounts may require specialized training. Related controls: AC-3, AC-4, AC-5, AC-6, AC-10, AC-17, AC-19, AC-20, AU-9, IA-2, IA-4, IA-5, IA-8, CM-5, CM-6, CM-11, MA-3, MA-4, MA-5, PL-4, SC-13.

    References: None.


    AC-2 (j) [monthly for privileged accessed, every six (6) months for non-privileged access]
  title: >-
    AC-2 - ACCOUNT MANAGEMENT
  levels:
  - high
  - moderate
  - low
- id: AC-2(1)
  status: not applicable
  notes: |-
    (O) The organization will be responsible for employing automated
    mechanisms to support account management activities. A successful
    control response will need to address all automated mechanisms used for
    account management.
  rules: []
  description: |-
    The organization employs automated mechanisms to support the management of information system accounts.

    Supplemental Guidance: The use of automated mechanisms can include, for example: using email or text messaging to automatically notify account managers when users are terminated or transferred; using the information system to monitor account usage; and using telephonic notification to report atypical system account usage.
  title: >-
    AC-2(1) - ACCOUNT MANAGEMENT | AUTOMATED SYSTEM ACCOUNT MANAGEMENT
  levels:
  - high
  - moderate
- id: AC-2(2)
  status: pending
  notes: |-
    (S) The information system will be responsible for automatically
    removing or disabling emergency and temporary accounts within the
    required timeframe. A successful control response will need to address
    all of the procedures and mechanisms involved in disabling these
    accounts.
  rules: []
  description: "The information system automatically [Selection: removes; disables]\
    \ temporary and emergency accounts after [Assignment: organization-defined time\
    \ period for each type of account].\n\nSupplemental Guidance: This control enhancement\
    \ requires the removal of both temporary and emergency accounts automatically\
    \ after a predefined period of time has elapsed, rather than at the convenience\
    \ of the systems administrator.\n\nAC-2 (2) [Selection: disables] \n[Assignment:\
    \ 24 hours from last use]"
  title: >-
    AC-2(2) - ACCOUNT MANAGEMENT | REMOVAL OF TEMPORARY / EMERGENCY ACCOUNTS
  levels:
  - high
  - moderate
- id: AC-2(3)
  status: pending
  notes: |-
    (S) The information system will be responsible for automatically
    disabling user accounts after the specified period of inactivity. A
    successful control response will need to address all automated
    mechanisms involved in disabling inactive accounts.
  rules: []
  description: |-
    The information system automatically disables inactive accounts after [Assignment: organization-defined time period].

    AC-2 (3) [35 days for user accounts]
    AC-2 (3) Requirement: The service provider defines the time period for non-user accounts (e.g., accounts associated with devices).  The time periods are approved and accepted by the JAB/AO. Where user management is a function of the service, reports of activity of consumer users shall be made available.
  title: >-
    AC-2(3) - ACCOUNT MANAGEMENT | DISABLE INACTIVE ACCOUNTS
  levels:
  - high
  - moderate
- id: AC-2(4)
  status: pending
  notes: |-
    (S) The information system will be responsible for audting changes to
    accounts and integrity of accounts to improve situational awareness. A
    successful control response Automatically auditing account creation,
    modification, enabling, disabling, and removal actions, and notifying
    appropriate individuals is outside the scope of Red Hat Advanced Cluster
    Management for Kubernetes.
  rules: []
  description: |-
    The information system automatically audits account creation, modification, enabling, disabling, and removal actions, and notifies [Assignment: organization-defined personnel or roles].

    Supplemental Guidance: Related controls: AU-2, AU-12.

    AC-2 (4) [organization and/or service provider system owner]
  title: >-
    AC-2(4) - ACCOUNT MANAGEMENT | AUTOMATED AUDIT ACTIONS
  levels:
  - high
  - moderate
- id: AC-2(5)
  status: pending
  notes: |-
    (O|S) The organization will be responsible for requiring that users logout
    when an organization-defined time-period of expected inactivity or
    description of when to log out. A successful control response will
    define account timeout and conditions when users shall log out. This
    control is expected to be addressed at the organizational level for
    policy guidance, and at the information system level for implimentation.
  rules: []
  description: |-
    The organization requires that users log out when [Assignment: organization-defined time-period of expected inactivity or description of when to log out].

    Supplemental Guidance: Related control: SC-23.

    AC-2 (5) [inactivity is anticipated to exceed Fifteen (15) minutes]
    AC-2 (5) Guidance: Should use a shorter timeframe than AC-12.
  title: >-
    AC-2(5) - ACCOUNT MANAGEMENT | INACTIVITY LOGOUT
  levels:
  - high
  - moderate
- id: AC-2(6)
  status: pending
  notes: |-
    (S) The information system will be responsible for implementing dynamic
    privilege management capabilities for account management. A successful
    control response will detail the mechanisms and processes used for
    dynamic privilege management.
  rules: []
- id: AC-2(7)
  status: not applicable
  notes: |-
    Section a: (O) The organization will be responsible for establishing and
    administering privileged accounts in accordance with a role-based access
    (RBAC) scheme. A successful control response will need to address the
    types of users or rules that receive privileged access as well as the
    organization of the RBAC scheme.
    Section b: (O) The organization will be responsible for monitoring privileged role
    assignments. A successful control response will need to address the
    process by which role assignments are reviewed for continued
    appropriateness.
    Section c: (O) The organization will be responsible for defining and executing
    actions to take when privileged role assignments are no longer
    appropriate. A successful control response will need to address the
    criteria for determining whether assignments are no longer appropriate,
    the actions to be taken, and the roles or personnel responsible for
    taking those actions.
  rules: []
  description: |-
    The organization:
    (a) Establishes and administers privileged user accounts in accordance with a role-based access scheme that organizes allowed information system access and privileges into roles;
    (b) Monitors privileged role assignments; and
    (c) Takes [Assignment: organization-defined actions] when privileged role assignments are no longer appropriate.

    Supplemental Guidance: Privileged roles are organization-defined roles assigned to individuals that allow those individuals to perform certain security-relevant functions that ordinary users are not authorized to perform. These privileged roles include, for example, key management, account management, network and system administration, database administration, and web administration.

    AC-2 (7) (c) [disables/revokes access within a organization-specified timeframe]
  title: >-
    AC-2(7) - ACCOUNT MANAGEMENT | ROLE-BASED SCHEMES
  levels:
  - high
  - moderate
- id: AC-2(8)
  status: pending
  notes: |-
    (S) The information system will be responsible for creating system
    accounts dynamically. A successful control response will need to address
    the mechanisms used to create accounts dynamically.
  rules: []
- id: AC-2(9)
  status: not applicable
  notes: |-
    The customer will be responsible for defining and enforcing
    conditions for the use of shared group accounts. A successful control
    response will need to address the specific need for the existing of
    a shared or group account versus multiple individual accounts, as well
    as the process for reviewing membership of shared or group accounts to
    verify that all individuals with access still require that access.
  rules: []
  description: |-
    The organization only permits the use of shared/group accounts that meet [Assignment: organization-defined conditions for establishing shared/group accounts].

    AC-2 (9) [organization-defined need with justification statement that explains why such accounts are necessary]
    AC-2 (9) Required if shared/group accounts are deployed
  title: >-
    AC-2(9) - ACCOUNT MANAGEMENT | RESTRICTIONS ON USE OF SHARED GROUPS / ACCOUNTS
  levels:
  - high
  - moderate
- id: AC-2(12)
  status: pending
  notes: |-
    Section a: The organization will be responsible for monitoring information system
    accounts for atypical use. A successful control response will relate
    the monitoring activities required for this control to the auditing
    activities in the AU control family, and will discuss the criteria
    for atypical use.
    Section b: The organization will be responsible for reporting atypical use of
    information system accounts. A successful control response will
    discuss the personnel or roles that must be notified and the process
    for notification.
  rules: []
  description: |-
    The organization:
     (a) Monitors information system accounts for [Assignment: organization-defined atypical use]; and
     (b) Reports atypical usage of information system accounts to [Assignment: organization-defined personnel or roles].

    Supplemental Guidance: Atypical usage includes, for example, accessing information systems at certain times of the day and from locations that are not consistent with the normal usage patterns of individuals working in organizations. Related control: CA-7.

    AC-2 (12) (b)[at a minimum, the ISSO and/or similar role within the organization]
    AC-2 (12)(a) Guidance: Required for privileged accounts.
    AC-2 (12)(b) Guidance: Required for privileged accounts.
  title: >-
    AC-2(12) - ACCOUNT MANAGEMENT | ACCOUNT MONITORING / ATYPICAL USAGE
  levels:
  - high
  - moderate
- id: AC-2(13)
  status: pending
  notes: |-
    The organization will be responsible for disabling accounts of users
    posing a significant risk within an organizational-defined time
    period of discovery of the risk. A successful control response defines
    the time period and the processes to disable the account(s).
  rules: []
  description: |-
    The organization disables accounts of users posing a significant risk within [Assignment: organization-defined time period] of discovery of the risk.

    Supplemental Guidance: Users posing a significant risk to organizations include individuals for whom reliable evidence or intelligence indicates either the intention to use authorized access to information systems to cause harm or through whom adversaries will cause harm. Harm includes potential adverse impacts to organizational operations and assets, individuals, other organizations, or the Nation. Close coordination between authorizing officials, information system administrators, and human resource managers is essential in order for timely execution of this control enhancement. Related control: PS-4.


    AC-2 (13) [one (1) hour]
  title: >-
    AC-2(13) - ACCOUNT MANAGEMENT | DISABLE ACCOUNTS FOR HIGH-RISK INDIVIDUALS
  levels:
  - high
- id: AC-5
  status: pending
  notes: |-
    Section a: The customer will be responsible for defining separation of duties
    between individuals so as to reduce the risk of insider threat without
    collusion. A successful control response will need to consider the
    possible actions a malicious insider could take to undermine the
    security of the system, and delineate how duties are separated to
    prevent or reduce the likelihood of those actions.
    Section b: The customer will be responsible for documenting separation of duties.
    A successful control response will need to address the location of this
    documentation and the process for reviewing it if necessary.
    Section c: The customer will be responsible for defining access authorizations
    to support separation of duties, for example by using Role Based
    Access Control. A successful control response will need to address
    policy and technical enforcement of separation of duties.
  rules: []
  description: "The organization:\n a. Separates [Assignment: organization-defined\
    \ duties of individuals];\n b. Documents separation of duties of individuals;\
    \ and\n c. Defines information system access authorizations to support separation\
    \ of duties.\n\nSupplemental Guidance:  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, for example: (i)\
    \ dividing mission functions and information system support functions among different\
    \ individuals and/or roles; (ii) conducting information system support functions\
    \ with different individuals (e.g., system management, programming, configuration\
    \ management, quality assurance and testing, and network security); and (iii)\
    \ ensuring security personnel administering access control functions do not also\
    \ administer audit functions. Related controls: AC-3, AC-6, PE-3, PE-4, PS-2.\n\
    \nControl Enhancements:  None.\n\nReferences: None.\n\n \nAC-5 Guidance: CSPs\
    \ have the option to provide a separation of duties matrix as an attachment to\
    \ the SSP."
  title: >-
    AC-5 - SEPARATION OF DUTIES
  levels:
  - high
  - moderate
- id: AC-6
  status: pending
  notes: |-
    The customer will be responsible for following least-privilege
    principles when granting authorized access. A successful control
    response will need to address the use of business requirements
    to determine the level of access required to perform each job function,
    and how that is related to the role-based access control scheme used
    within the system.
  rules: []
  description: |-
    The organization employs the principle of least privilege, allowing only authorized accesses for users (or processes acting on behalf of users) which are necessary to accomplish assigned tasks in accordance with organizational missions and business functions.

    Supplemental Guidance:  Organizations employ least privilege for specific duties and information systems. The principle of least privilege is also applied to information system processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions/business functions. Organizations consider the creation of additional processes, roles, and information system accounts as necessary, to achieve least privilege. Organizations also apply least privilege to the development, implementation, and operation of organizational information systems. Related controls: AC-2, AC-3, AC-5, CM-6, CM-7, PL-2.

    References: None.
  title: >-
    AC-6 - LEAST PRIVILEGE
  levels:
  - high
  - moderate
- id: AC-6(1)
  status: pending
  notes: |-
    The customer will be responsible for defining key security functions
    and security-relevant information, and for explicitly authorizing
    access to those functions and information. A successful control response
    will need to address the criteria used to determine which functions
    and information require explicit access authorization.
  rules: []
  description: |-
    The organization explicitly authorizes access to [Assignment: organization-defined security functions (deployed in hardware, software, and firmware) and security-relevant information].

    Supplemental Guidance:  Security functions include, for example, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters. Security-relevant information includes, for example, filtering rules for routers/firewalls, cryptographic key management information, configuration parameters for security services, and access control lists. Explicitly authorized personnel include, for example, security administrators, system and network administrators, system security officers, system maintenance personnel, system programmers, and other privileged users. Related controls: AC-17, AC-18, AC-19.

    AC-6 (1) [all functions not publicly accessible and all security-relevant information not publicly available]
  title: >-
    AC-6(1) - LEAST PRIVILEGE | AUTHORIZE ACCESS TO SECURITY FUNCTIONS
  levels:
  - high
  - moderate
- id: AC-6(5)
  status: pending
  notes: |-
    The customer will be responsible for defining specific personnel
    or roles who require privileged access, and restricting privileged
    access to those personnel or roles. A successful response will need
    to address the job functions or responsibilities for which
    privileged access is required.
  rules: []
  description: |-
    The organization restricts privileged accounts on the information system to [Assignment:
    organization-defined personnel or roles].

    Supplemental Guidance:  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 having access to privileged information/functions. Organizations may differentiate in the application of this control enhancement between allowed privileges for local accounts and for domain accounts provided organizations retain the ability to control information system configurations for key security parameters and as otherwise necessary to sufficiently mitigate risk. Related control: CM-6.
  title: >-
    AC-6(5) - LEAST PRIVILEGE | PRIVILEGED ACCOUNTS
  levels:
  - high
  - moderate
- id: AC-14
  status: pending
  notes: |-
    Section a: The customer will be responsible for identifying user actions that can
    be performed on the information system without identification or
    authentication consistent with missions/business functions. A
    successful control response will identify such actions.
  rules: []
  description: "The organization:\n a. Identifies [Assignment: organization-defined\
    \ user actions] that can be performed on the information system without identification\
    \ or authentication consistent with organizational missions/business functions;\
    \ and\n b. Documents and provides supporting rationale in the security plan for\
    \ the information system, user actions not requiring identification or authentication.\n\
    \nSupplemental Guidance:  This control addresses situations in which organizations\
    \ determine that no identification or authentication is required in organizational\
    \ information systems. Organizations may allow a limited number of user actions\
    \ without identification or authentication including, for example, when individuals\
    \ access public websites or other publicly accessible federal information systems,\
    \ when individuals use mobile phones to receive calls, or when facsimiles are\
    \ received. Organizations also identify actions that normally require identification\
    \ or authentication but may under certain circumstances (e.g., emergencies), 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.\
    \ This control 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 information systems\
    \ without identification and authentication and thus, the values for assignment\
    \ statements can be none. Related controls: CP-2, IA-2.\n\nControl Enhancements:\
    \  None.\n\n(1)   PERMITTED ACTIONS WITHOUT IDENTIFICATION OR AUTHENTICATION |\
    \ NECESSARY USES\n[Withdrawn: Incorporated into AC-14]. \n\nReferences:  None."
  title: >-
    AC-14 - PERMITTED ACTIONS WITHOUT IDENTIFICATION OR

    AUTHENTICATION
  levels:
  - high
  - moderate
  - low
- id: AC-17
  status: pending
  notes: |-
    Section a: The customer will be responsible for establishing and documenting
    usage restrictions, configuration and connection requirements, and
    implementation guidance for access to the customer application
    (note that in a cloud environment, all user access will be remote
    access).
    Section b: The customer will be responsible for authorizing remote access before
    allowing such connections. Due to the nature of the cloud environment,
    a successful control response will need to indicate that authorizing
    remote access is equivalent to authorizing any access, and relate this
    control to AC-2.
  rules: []
  description: |-
    The organization:
     a. Establishes and documents usage restrictions, configuration/connection requirements, and implementation guidance for each type of remote access allowed; and
     b. Authorizes remote access to the information system prior to allowing such connections.

    Supplemental Guidance:  Remote access is access to organizational information systems by users (or processes acting on behalf of users) communicating through external networks (e.g., the Internet). Remote access methods include, for example, dial-up, broadband, and wireless. Organizations often employ encrypted virtual private networks (VPNs) to enhance confidentiality and integrity over remote connections. The use of encrypted VPNs does not make the access non-remote; however, the use of VPNs, when adequately provisioned with appropriate security controls (e.g., employing appropriate encryption techniques for confidentiality and integrity protection) may provide sufficient assurance to the organization that it can effectively treat such connections as internal networks. Still, VPN connections traverse external networks, and the encrypted VPN does not enhance the availability of remote connections. Also, VPNs with encrypted tunnels can affect the organizational capability to adequately monitor network communications traffic for malicious code. Remote access controls apply to information systems other than public web servers or systems designed for public access. This control addresses authorization prior to allowing remote access without specifying the formats for such authorization. While organizations may use interconnection security agreements to authorize remote access connections, such agreements are not required by this control. Enforcing access restrictions for remote connections is addressed in AC-3. Related controls: AC-2, AC-3, AC-18, AC-19, AC-20, CA-3, CA-7, CM-8, IA-2, IA-3, IA-8, MA-4, PE-17, PL-4, SC-10, SI-4.

    References: NIST Special Publications 800-46, 800-77, 800-113, 800-114, 800-121.
  title: >-
    AC-17 - REMOTE ACCESS
  levels:
  - high
  - moderate
  - low
- id: AC-17(4)
  status: pending
  notes: |-
    Section a: The customer will be responsible for authoring the execution of
    privileged commands and access to security-relevant information via
    remote access. Due to the nature of the cloud environment, a
    successful control response will need to indicate that authorizing
    these activities over remote access is equivalent to authorizing them
    at all, and refer to AC-2.
    Section b: The customer will be responsible for authorizing the execution of
    privileged commands and access to security-relevant information via
    remote access. Due to the nature of the cloud environment, a successful
    control response will need to indicate that authorizing these activities
    over remote access is equivalent to authorizing them at all, and refer
    to AC-2.
  rules: []
  description: |-
    The organization:
     (a)   Authorizes the execution of privileged commands and access to security-relevant information via remote access only for [Assignment: organization-defined needs]; and
     (b)   Documents the rationale for such access in the security plan for the information system.

    Supplemental Guidance:  Related control: AC-6.
  title: >-
    AC-17(4) - REMOTE ACCESS | PRIVILEGED COMMANDS / ACCESS
  levels:
  - high
  - moderate
- id: AC-18
  status: pending
  notes: |-
    Section a: Given the data center focus of the infrastructure running OpenShift,
    it is likely this control is not applicable. A successful response
    will document if wireless connectivity is enabled, and if so,
    how usage and connection requirements were created.
    Section b: A successful control response will document how connections are
    authorized prior to recieving full connectivity to the wireless
    network. This is frequently accomplished via WEP2 and other
    encrption and/or passphrase requirements.
  rules: []
  description: |-
    The organization:
     a. Establishes usage restrictions, configuration/connection requirements, and implementation guidance for wireless access; and
     b. Authorizes wireless access to the information system prior to allowing such connections.

    Supplemental Guidance:  Wireless technologies include, for example, microwave, packet radio (UHF/VHF), 802.11x, and Bluetooth. Wireless networks use authentication protocols (e.g., EAP/TLS, PEAP), which provide credential protection and mutual authentication. Related controls: AC-2, AC-3, AC-17, AC-19, CA-3, CA-7, CM-8, IA-2, IA-3, IA-8, PL-4, SI-4.

    References: NIST Special Publications 800-48, 800-94, 800-97.
  title: >-
    AC-18 - WIRELESS ACCESS
  levels:
  - high
  - moderate
  - low
- id: AC-19
  status: pending
  notes: |-
    Section a: A successful control response will document how, if wireless
    connectivity is permitted, end-user devices are organizationally
    managed (configurations, connections, and applications).
    Section b: A successful control response will document how, if wireless
    connectivity is permitted, mobile devices are authorized to
    connect to organizational networks (e.g. MDM).
  rules: []
  description: |-
    The organization:
     a. Establishes usage restrictions, configuration requirements, connection requirements, and implementation guidance for organization-controlled mobile devices; and
     b. Authorizes the connection of mobile devices to organizational information systems.

    Supplemental Guidance:  A mobile device is a computing device that: (i) has a small form factor such that it can easily be carried by a single individual; (ii) is designed to operate without a physical connection (e.g., wirelessly transmit or receive information); (iii) possesses local, non- removable or removable data storage; and (iv) includes a self-contained power source. Mobile devices 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, E-readers, and tablets. Mobile devices are typically associated with a single individual and the device is usually in close proximity to the individual; however, the degree of proximity can vary depending upon on the form factor and size of the device. The processing, storage, and transmission capability of the mobile device may be comparable to or merely a subset of desktop systems, depending upon the nature and intended purpose of the device. Due to the large variety of mobile devices with different technical characteristics and capabilities, organizational restrictions may vary for the different classes/types of such devices. Usage restrictions and specific implementation guidance for mobile devices include, for example, configuration management, device identification and authentication, implementation of mandatory protective software (e.g., malicious code detection, firewall), 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 (e.g., wireless, infrared). Organizations are cautioned that the need to provide adequate security for mobile devices goes beyond the requirements in this control. Many safeguards and countermeasures for mobile devices are reflected in other security controls in the catalog allocated in the initial control baselines as starting points for the development of security plans and overlays using the tailoring process. There may also be some degree of overlap in the requirements articulated by the security controls within the different families of controls. AC-20 addresses mobile devices that are not organization-controlled. Related controls: AC-3, AC-7, AC-18, AC-20, CA-9, CM-2, IA-2, IA-3, MP-2, MP-4, MP-5, PL-4, SC-7, SC-43, SI-3, SI-4.

    References: OMB Memorandum 06-16; NIST Special Publications 800-114, 800-124, 800-164.
  title: >-
    AC-19 - ACCESS CONTROL FOR MOBILE DEVICES
  levels:
  - high
  - moderate
  - low
- id: AC-19(5)
  status: pending
  notes: |-
    A successful control response will document how either full-device
    encryption on mobile devices is being used. This is only applicable
    if mobile is within scope of your security package.
  rules: []
  description: |-
    The organization employs [Selection: full-device encryption; container encryption] to protect the confidentiality and integrity of information on [Assignment: organization-defined mobile devices].

    Supplemental Guidance:  Container-based encryption provides a more fine-grained approach to the encryption of data/information on mobile devices, including for example, encrypting selected data structures such as files, records, or fields. Related controls: MP-5, SC-13, SC-28.

    References:  OMB Memorandum 06-16; NIST Special Publications 800-114, 800-124, 800-164.
  title: >-
    AC-19(5) - ACCESS CONTROL FOR MOBILE DEVICES | FULL DEVICE / CONTAINER-BASED ENCRYPTION
  levels:
  - high
  - moderate
- id: AC-20
  status: pending
  notes: |-
    Section a: The organization will be responsible for establishing terms and conditions
    allowing authorized individuals to access the organization application
    from external information sysetms. A successful control response will
    need to outline the terms and conditions and the external information
    systems to which those terms and conditions apply.
    Section b: The organization will be responsible for establishing terms and conditions
    allowing authorized individuals to process, store, or transmit
    customer-controlled information using external information systems. A
    successful control response will need to outline the terms and
    conditions and the external information systems to which those terms
    and conditions apply.
  rules: []
  description: |-
    The organization establishes terms and conditions, consistent with any trust relationships established with other organizations owning, operating, and/or maintaining external information systems, allowing authorized individuals to:
     a. Access the information system from external information systems; and
     b. Process, store, or transmit organization-controlled information using external information systems.

    Supplemental Guidance:  External information systems are information systems or components of information systems that are outside of the authorization boundary established by organizations and for which organizations typically have no direct supervision and authority over the application of required security controls or the assessment of control effectiveness. External information systems include, for example: (i) personally owned information systems/devices (e.g., notebook computers, smart phones, tablets, personal digital assistants); (ii) privately owned computing and communications devices resident in commercial or public facilities (e.g., hotels, train stations, convention centers, shopping malls, or airports); (iii) information systems owned or controlled by nonfederal governmental organizations; and (iv) federal information systems that are not owned by, operated by, or under the direct supervision and authority of organizations. This control also addresses the use of external information systems for the processing, storage, or transmission of
    organizational information, including, for example, accessing cloud services (e.g., infrastructure as a service, platform as a service, or software as a service) from organizational information systems.

    For some external information systems (i.e., information systems operated by other federal agencies, including organizations subordinate to those agencies), 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. Information systems within these organizations
    would not be considered external. These situations occur when, for example, there are pre-existing sharing/trust agreements (either implicit or explicit) established between federal agencies or organizations subordinate to those agencies, or when such trust agreements are specified by applicable laws, Executive Orders, directives, or policies. Authorized individuals include, for example, organizational personnel, contractors, or other individuals with authorized access to organizational information systems and over which organizations have the authority to impose rules of behavior with regard to system access. Restrictions that organizations impose on authorized individuals need not be uniform, as those restrictions may vary depending upon the
    trust relationships between organizations. Therefore, organizations may choose to impose different security restrictions on contractors than on state, local, or tribal governments.

    This control does not apply to the use of external information systems to access public interfaces to organizational information systems (e.g., individuals accessing federal information through www.usa.gov). Organizations establish terms and conditions for the use of external information systems in accordance with organizational security policies and procedures. Terms and conditions address as a minimum: types of applications that can be accessed on organizational information systems from external information systems; and the highest security category of information that can be processed, stored, or transmitted on external information systems. If terms and conditions with the owners of external information systems cannot be established, organizations may impose restrictions on organizational personnel using those external systems. Related controls: AC-3, AC-17, AC-19, CA-3, PL-4, SA-9.

    References: FIPS Publication 199.
  title: >-
    AC-20 - USE OF EXTERNAL INFORMATION SYSTEMS
  levels:
  - high
  - moderate
  - low
- id: AC-20(1)
  status: pending
  notes: |-
    Section a: The organization will be responsible for verifying the implementation of
    required security controls on external information systems used to
    access the organization application. A successful control response will
    need to address how this verification occurs (e.g. through an
    independent assessment).
    Section b: If part (a) is not possible, then the organization will be responsible
    for establishing and retaining approved information system connection
    or processing agreements with the external entity hosting the external
    information system used to access the organization application.
  rules: []
  description: "The organization permits authorized individuals to use an external\
    \ information system to access the information system or to process, store, or\
    \ transmit organization-controlled information only when the organization:\n (a)\
    \   Verifies the implementation of required security controls on the external\
    \ system as specified in the organization\u2019s information security policy and\
    \ security plan; or\n (b)   Retains approved information system connection or\
    \ processing agreements with the organizational entity hosting the external information\
    \ system.\n\nSupplemental Guidance:  This control enhancement recognizes that\
    \ there are circumstances where individuals using external information systems\
    \ (e.g., contractors, coalition partners) need to access organizational information\
    \ systems. In those situations, organizations need confidence that the external\
    \ information systems contain the necessary security safeguards (i.e., security\
    \ controls), so as not to compromise, damage, or otherwise harm organizational\
    \ information systems. Verification that the required security controls have been\
    \ implemented can be achieved, for example, by third-party, independent assessments,\
    \ attestations, or other means, depending on the confidence level required by\
    \ organizations. Related control: CA-2."
  title: >-
    AC-20(1) - USE OF EXTERNAL INFORMATION SYSTEMS | LIMITS ON AUTHORIZED USE
  levels:
  - high
  - moderate
- id: AC-20(2)
  status: pending
  notes: |-
    The organization will be responsible for restricting or prohibiting the
    use of customer-controlled portable storage devices on external
    information systems. If such use is not prohibited, a successful
    control repsonse will need to address specific restrictions on how
    or under what conditions such use may occur.
  rules: []
  description: |-
    The organization [Selection: restricts; prohibits] the use of organization-controlled portable storage devices by authorized individuals on external information systems.

    Supplemental Guidance:  Limits on the use of organization-controlled portable storage devices in external information systems include, for example, complete prohibition of the use of such devices or restrictions on how the devices may be used and under what conditions the devices may be used.
  title: >-
    AC-20(2) - USE OF EXTERNAL INFORMATION SYSTEMS | PORTABLE STORAGE DEVICES
  levels:
  - high
  - moderate
- id: AC-21
  status: pending
  notes: |-
    Section a: The organization will be responsible for determining when authorized users
    are required to use discretion as to whether to share information. A
    successful control response will need to address the circumstances
    where user direction (rather than automatic access enforcement) is
    required.
    Section b: The organization will be responsible for defining and employing automated
    mechanisms or manual processes to assist users in making information
    sharing decisions.
  rules: []
  description: "The organization:\na. Facilitates information sharing by enabling\
    \ authorized users to determine whether access authorizations assigned to the\
    \ sharing partner match the access restrictions on the information for [Assignment:\
    \ organization-defined information sharing circumstances where user discretion\
    \ is required]; and\nb. Employs [Assignment: organization-defined automated mechanisms\
    \ or manual processes] to assist users in making information sharing/collaboration\
    \ decisions.\n\_\nSupplemental Guidance:\_This control applies to information\
    \ that may be restricted in some manner (e.g., privileged medical information,\
    \ contract-sensitive information, proprietary information, personally identifiable\
    \ information, classified information related to special access programs or compartments)\
    \ based on some formal or administrative determination. Depending on the particular\
    \ information-sharing 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/compartment. Related control: AC-3.\n\
    \nReferences: None."
  title: >-
    AC-21 - INFORMATION SHARING
  levels:
  - high
  - moderate
- id: AC-22
  status: pending
  notes: |-
    Section a: The organization will be responsible for designating individuals
    authorized to post information publicly. A successful control response
    will need to address the specific business requirements or job functions
    that justify such access.
    Section b: The organization will be responsible for trianing designated authorized
    individuals to prevent disclosure of nonpublic information. A
    successful control response will need to outline the training
    provided.
    Section c: The organization will be responsible for reviewing information prior to
    public posting to ensure that nonpublic information is not included. A
    successful control response will need to address the roles or personnel
    responsible for this review and the process for signoff.
    Section d: The organization will be responsible for reviewing publicly available
    information at the reqired frequency and removing nonpublic information
    when discovered. A successful control response will need to address the
    roles or personnel responsible for the review, the process used to
    review publicly available information, and the process for removal of
    nonpublic information.
  rules: []
  description: |-
    The organization:
     a. Designates individuals authorized to post information onto a publicly accessible information system;
     b. Trains authorized individuals to ensure that publicly accessible information does not contain nonpublic information;
     c. Reviews the proposed content of information prior to posting onto the publicly accessible information system to ensure that nonpublic information is not included; and
     d. Reviews the content on the publicly accessible information system for nonpublic information [Assignment: organization-defined frequency] and removes such information, if discovered.

    Supplemental Guidance:  In accordance with federal laws, Executive Orders, directives, policies, regulations, standards, and/or guidance, the general public is not authorized access to nonpublic information (e.g., information protected under the Privacy Act and proprietary information). This control addresses information systems that are controlled by the organization and accessible to the general public, typically without identification or authentication. The posting of information on
    non-organization information systems is covered by organizational policy. Related controls: AC-3, AC-4, AT-2, AT-3, AU-13.

    Control Enhancements: None.

    References: None.

    AC-22 (d) [at least quarterly]
  title: >-
    AC-22 - PUBLICLY ACCESSIBLE CONTENT
  levels:
  - high
  - moderate
  - low
- id: AT-1
  status: pending
  notes: |-
    Section a: The organization will be responsible for developing, documenting, and
    disseminating Security Awareness and Training policy and procedures.
    A successful control response will need to address the content of the
    policy (which must include purpose, scope, roles, responsibilities,
    management commitment, coordination, and compliance) and procedures
    (which must facilitate the implementation of the policies and
    associated controls).
    Section b: The organization will be responsible for reviewing and updating the
    Security Awareness and Training policy every 3 years, and procedures
    annually. A successful control response will need to address the
    review and update process, including the role(s) responsible for
    initiating the review process, updating the policy and procedures,
    and providing approval of the updates.
  rules: []
  description: "The organization:\n a. Develops, documents, and disseminates to [Assignment:\
    \ organization-defined personnel or roles]:\n   1. A security awareness and training\
    \ policy that addresses purpose, scope, roles, responsibilities, management commitment,\
    \ coordination among organizational entities, and compliance; and\n   2.  Procedures\
    \ to facilitate the implementation of the security awareness and training policy\
    \ and associated security awareness and training controls; and\n b. Reviews and\
    \ updates the current:\n   1. Security awareness and training policy [Assignment:\
    \ organization-defined frequency]; and\n   2.  Security awareness and training\
    \ procedures [Assignment: organization-defined frequency].\n\nSupplemental Guidance:\
    \  This control addresses the establishment of policy and procedures for the effective\
    \ implementation of selected security controls and control enhancements in the\
    \ AT family. Policy and procedures reflect applicable federal laws, Executive\
    \ Orders, directives, regulations, policies, standards, and guidance. Security\
    \ program policies and procedures at the organization level may make the need\
    \ for system-specific policies and procedures unnecessary. The policy can be included\
    \ as part of the general information security policy for organizations or conversely,\
    \ can be represented by multiple policies reflecting the complex nature of certain\
    \ organizations. The procedures can be established for the security program in\
    \ general and for particular information systems, if needed. The organizational\
    \ risk management strategy is a key factor in establishing policy and procedures.\
    \ Related control: PM-9.\n\nControl Enhancements:  None.\n\nReferences:  NIST\
    \ Special Publications 800-12, 800-16, 800-50, 800-100.\n\nAT-1 (b) (1) [at least\
    \ annually or whenever a significant change occurs] \nAT-1 (b) (2) [at least annually\
    \ or whenever a significant change occurs]"
  title: >-
    AT-1 - SECURITY AWARENESS AND TRAINING POLICY ANDPROCEDURES
  levels:
  - high
  - moderate
  - low
- id: AT-2
  status: pending
  notes: |-
    Section a: The customer will be responsible for providing basic security
    awareness training as part of initial training. A successful control
    response will outline the content of the training and will discuss the
    process for ensuring that all users undergo the required training.
    Section b: The customer will be responsible for providing updated basic security
    awareness training as required by information system changes. A
    succesful control response will discuss the process for determining
    what information system changes require updated training, how the
    training content is updated, and how users are notified of the need for
    re-training.
    Section c: The customer will be responsible for refreshing the basic security
    awareness training annually. A successful control response will
    discuss the process for ensuring that all users undergo the required
    re-trianing.
  rules: []
  description: |-
    The organization provides basic security awareness training to information system users (including managers, senior executives, and contractors):
     a. As part of initial training for new users;
     b. When required by information system changes; and
     c. [Assignment: organization-defined frequency] thereafter.

    Supplemental Guidance:  Organizations determine the appropriate content of security awareness training and security awareness techniques based on the specific organizational requirements and the information systems to which personnel have authorized access. The content includes a basic understanding of the need for information security and user actions to maintain security and to respond to suspected security incidents. The content also addresses awareness of the need for operations security. Security awareness techniques can include, for example, displaying posters, offering supplies inscribed with security reminders, generating email advisories/notices from senior organizational officials, displaying logon screen messages, and conducting information security awareness events. Related controls: AT-3, AT-4, PL-4.

    References: C.F.R. Part 5 Subpart C (5 C.F.R. 930.301); Executive Order 13587; NIST Special Publication 800-50.

    AT-2 (c) [at least annually]
  title: >-
    AT-2 - SECURITY AWARENESS TRAINING
  levels:
  - high
  - moderate
  - low
- id: AT-2(2)
  status: pending
  notes: |-
    The organization will be responsible for including information about
    indicators of insider threat in security awareness training materials.
    A successful control response will summarize potential indicators of
    insider threat and outline the process for reporting them to appropriate
    organizational officials.
  rules: []
  description: |-
    The organization includes security awareness training on recognizing and reporting potential indicators of insider threat.

    Supplemental Guidance:  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 sexual harassment of fellow employees, workplace violence, and other serious violations of organizational policies, procedures, directives, rules, or practices. Security awareness training includes how to communicate employee and management concerns regarding potential indicators of insider threat through appropriate organizational channels in accordance with established organizational policies and procedures. Related controls: PL-4, PM-12, PS-3, PS-6.

    References:  C.F.R. Part 5 Subpart C (5 C.F.R 930.301); Executive Order 13587; NIST Special Publication 800-50.
  title: >-
    AT-2(2) - SECURITY AWARENESS | INSIDER THREAT
  levels:
  - high
  - moderate
- id: AT-3
  status: pending
  notes: |-
    Section a: The organization will be responsible for providing role-based security
    training prior to users commencing work on their system. A successful
    control response will outline the content of the training (including
    how the content varies by assigned role) and will discuss the process
    for ensuring that all users undergo the required training for their
    roles.
    Section b: The organization will be responsible for providing updated role-based
    security training as required by information system changes. A
    successful control response will discuss the process for determining
    what information system changes require updated training, how the
    training content is updated, and hw users are notified of the need
    for re-training.
    Section c: The custmoer will be responsible for refreshing role-based security
    training annually. A successful control response will discuss the
    process for ensuring that all users undergo the required re-training.
  rules: []
  description: |-
    The organization provides role-based security training to personnel with assigned security roles and responsibilities:
    a. Before authorizing access to the information system or performing assigned duties;
    b. When required by information system changes; and
    c. [Assignment: organization-defined frequency] thereafter.

    Supplemental Guidance:  Organizations determine the appropriate content of security training based on the assigned roles and responsibilities of individuals and the specific security requirements of organizations and the information systems to which personnel have authorized access. In addition, organizations provide enterprise architects, information system developers, software developers, acquisition/procurement officials, information system managers, system/network administrators, personnel conducting configuration management and auditing activities, personnel performing independent verification and validation activities, security control assessors, and other personnel having access to system-level software, adequate security-related technical training specifically tailored for their assigned duties. Comprehensive role-based training addresses management, operational, and technical roles and responsibilities covering physical, personnel, and technical safeguards and countermeasures. Such training can include for example, policies, procedures, tools, and artifacts for the organizational security roles defined. Organizations also provide the training necessary for individuals to carry out their responsibilities related to operations and
    supply chain security within the context of organizational information security programs. Role-based security training also applies to contractors providing services to federal agencies. Related controls: AT-2, AT-4, PL-4, PS-7, SA-3, SA-12, SA-16.

    References: C.F.R. Part 5 Subpart C (5 C.F.R. 930.301); NIST Special Publications 800-16, 800-50.

    AT-3 (c) [at least annually]
  title: >-
    AT-3 - ROLE-BASED SECURITY TRAINING
  levels:
  - high
  - moderate
  - low
- id: AT-4
  status: pending
  notes: |-
    Section a: The organization will be responsible for tracking successful completion
    of basic security awareness training and role-based training
    security training activities. A successful control response will discuss
    the process or system used to monitor and document completion of
    training for each user.
    Section b: The organization will be responsible for retaining training records for
    the required timeframe. A successful control response will outline the
    methods by which required retention is achieved.
  rules: []
  description: |-
    The organization:
     a. Documents and monitors individual information system security training activities including basic security awareness training and specific information system security training; and
     b. Retains individual training records for [Assignment: organization-defined time period].

    Supplemental Guidance:  Documentation for specialized training may be maintained by individual supervisors at the option of the organization. Related controls: AT-2, AT-3, PM-14.

    Control Enhancements:  None.

    References:  None.

    AT-4 (b) [five (5) years or 5 years after completion of a specific training program]
  title: >-
    AT-4 - SECURITY TRAINING RECORDS
  levels:
  - high
  - moderate
  - low
- id: AU-1
  status: pending
  notes: |-
    Section a: The organization will be responsible for developing, documenting, and
    disseminating Audit and Accountability policy and procedures. A
    successful control repsonse will need to address the content of the
    policy (which must include purpose, scope, roles, responsibilities,
    management commitment, coordination, and compliance) and procedures
    (which must facilitate the implementation of the policies and
    associated controls).
    Section b: The organization will be responsible for reviewing and updating the
    Audit and Accountability policy every 3 years, and procedures
    annually. A successful control response will need to address the
    review and update process, including the role(s) responsible
    for initiating the review process, updating the policy and
    procedures, and providing approval of the updates.
  rules: []
  description: |-
    The organization:
     a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:
       1. An audit and accountability policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and
       2.  Procedures to facilitate the implementation of the audit and accountability policy and associated audit and accountability controls; and
     b. Reviews and updates the current:
       1. Audit and accountability policy [Assignment: organization-defined frequency]; and
       2. Audit and accountability procedures [Assignment: organization-defined frequency].

    Supplemental Guidance:  This control addresses the establishment of policy and procedures for the effective implementation of selected security controls and control enhancements in the AU family. Policy and procedures reflect applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance. Security program policies and procedures at the organization level may make the need for system-specific policies and procedures unnecessary. The policy can be included as part of the general information security policy for organizations or conversely, can be represented by multiple policies reflecting the complex nature of certain organizations. The procedures can be established for the security program in general and for particular information systems, if needed. The organizational risk management strategy is a key factor in establishing policy and procedures. Related control: PM-9.

    Control Enhancements:  None.

    References:  NIST Special Publications 800-12, 800-100.

    AU-1 (b) (1) [at least annually]
    AU-1 (b) (2) [at least annually or whenever a significant change occurs]
  title: >-
    AU-1 - AUDIT AND ACCOUNTABILITY POLICY AND

    PROCEDURES
  levels:
  - high
  - moderate
  - low
- id: AU-2
  status: pending
  notes: |-
    Section a: The organization will be responsible for determining which events
    their software applications must be capable of auditing. A successful
    control response will need to address the FedRAMP-required auditable
    events listed above as well as any additional events the organization
    feels should auditable based on organization needs.
    Section b: The organization will be responsible for implementing this control. A
    successful control response will need to address coordination with all
    interested parties (such as an internal SOC or security team) and
    incorporation of their input into business requirements in order to
    determine the selection of auditable events.
    Section c: The organization will be responsible for implimenting this control. A
    successful control response will include a discussion of the decision
    process behind the selection of auditable events and a justification for
    the selected events being sufficient to support after-the-fact
    investigation.
    Section d: The customer will be responsible for selecting a subsec of the events
    listed in AU-2(a) to be audited by the system. For FedRAMP compliance,
    these events must be monitored continuously. A successful control
    response will include a discussion of the rationale for the events
    chosen.

    Note this control only identifies which events are relevant for this
    information sysem. Technical implimentation, at a information system
    component level, is documented in AU-12(a).
  rules: []
  description: |-
    The organization:
     a. Determines that the information system is capable of auditing the following events: [Assignment: organization-defined auditable events];
     b. Coordinates the security audit function with other organizational entities requiring audit- related information to enhance mutual support and to help guide the selection of auditable events;
     c. Provides a rationale for why the auditable events are deemed to be adequate to support after- the-fact investigations of security incidents; and
     d. Determines that the following events are to be audited within the information system: [Assignment: organization-defined audited events (the subset of the auditable events defined in AU-2 a.) along with the frequency of (or situation requiring) auditing for each identified event].

    Supplemental Guidance:  An event is any observable occurrence in an organizational information system. Organizations identify audit events as those events which are significant and relevant to the security of information systems and the environments in which those systems operate in order to meet specific and ongoing audit needs. Audit events can include, for example, password changes, failed logons, or failed accesses related to information systems, administrative privilege usage, PIV credential usage, or third-party credential usage. In determining the set of auditable events, organizations consider the auditing appropriate for each of the security controls to be implemented. To balance auditing requirements with other information system needs, this control also requires identifying that subset of auditable events that are audited at a given point in time. For example, organizations may determine that information systems must have the capability to log every file access both successful and unsuccessful, but not activate that capability except for specific circumstances due to the potential burden on system performance. Auditing requirements, including the need for auditable events, may be referenced in other security controls and control enhancements. Organizations also include auditable events that are required by applicable federal laws, Executive Orders, directives, policies, regulations, and standards. Audit records can be generated at various levels of abstraction, including at the packet level as information traverses the network. Selecting the appropriate level of abstraction is a critical aspect of an audit capability and can facilitate the identification of root causes to problems. Organizations consider in the definition of auditable events, the auditing necessary to cover related events such as the steps in distributed, transaction-based processes (e.g., processes that are distributed across multiple organizations) and actions that occur in service-oriented architectures. Related controls: AC-6, AC-17, AU-3, AU-12, MA-4, MP-2, MP-4, SI-4.

    References: NIST Special Publication 800-92; Web: http://idmanagement.gov.

    AU-2 (a) [successful and unsuccessful account logon events, account management events, object access, policy change, privilege functions, process tracking, and system events. For Web applications: all administrator activity, authentication checks, authorization checks, data deletions, data access, data changes, and permission changes]
    AU-2 (d) [organization-defined subset of the auditable events defined in AU-2a to be audited continually for each identified event].
    AU-2 Requirement: Coordination between service provider and consumer shall be documented and accepted by the JAB/AO.
  title: >-
    AU-2 - AUDIT EVENTS
  levels:
  - high
  - moderate
  - low
- id: AU-2(3)
  status: pending
  notes: |-
    Customers are responsible for reviewing and updating the audited
    events annually or whenever there is a change in the threat environment.
    A successful control response will outline how often events are
    reviewed.
  rules: []
  description: "The organization reviews and updates the audited events [Assignment:\
    \ organization-defined frequency].\n\nSupplemental Guidance:  Over time, the events\
    \ that organizations believe should be audited may change. Reviewing and updating\
    \ the set of audited events periodically is necessary to ensure that the current\
    \ set is still necessary and sufficient.\n\nAU-2 (3) [annually or whenever there\
    \ is a change in the threat environment] \nAU-2 (3) Guidance: Annually or whenever\
    \ changes in the threat environment are communicated to the service provider by\
    \ the JAB/AO."
  title: >-
    AU-2(3) - AUDIT EVENTS | REVIEWS AND UPDATES
  levels:
  - high
  - moderate
- id: AU-3
  status: pending
  notes: |-
    The organization is responsible for generating audit records that contain
    information that establishes what type of event occured, when the event
    occurred, where the event occured, the source of the event, the
    outcome of the event, and the identity of any individuals or subjects
    associated with the event. A successful control response will outline
    what metadata the organization requires audit records to contain.
  rules: []
  description: |-
    The information system generates audit records containing information that establishes what type of event occurred, when the event occurred, where the event occurred, the source of the event, the outcome of the event, and the identity of any individuals or subjects associated with the event.

    Supplemental Guidance:  Audit record content that may be necessary to satisfy the requirement of this control, includes, for example, time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked. Event outcomes can include indicators of event success or failure and event-specific results (e.g., the security state of the information system after the event occurred). Related controls: AU-2, AU-8, AU-12, SI-11.

    References: None.
  title: >-
    AU-3 - CONTENT OF AUDIT RECORDS
  levels:
  - high
  - moderate
  - low
- id: AU-3(1)
  status: pending
  notes: |-
    The organization is responsible ensuring that the information system
    audit records conain all of the information required to meet
    FedRAMP requirements. A successful control response will outline the
    systems audit generation, and the content that it includes.

    Note: This control defines what supplimentary data audit records must
    contain, such as full text recording of privileged commands. Metadata
    elements of audit logs are defined in AU-3. Component configuration is
    established through AU-12(c).
  rules: []
  description: |-
    The information system generates audit records containing the following additional information: [Assignment: organization-defined additional, more detailed information].

    Supplemental Guidance:  Detailed information that organizations may consider in audit records includes, for example, full text recording of privileged commands or the individual identities of group account users. Organizations consider limiting the additional audit information to only that information explicitly needed for specific audit requirements. This facilitates the use of audit trails and audit logs by not including information that could potentially be misleading or could make it more difficult to locate information of interest.

    AU-3 (1) [session, connection, transaction, or activity duration; for client-server transactions, the number of bytes received and bytes sent; additional informational messages to diagnose or identify the event; characteristics that describe or identify the object or resource being acted upon; individual identities of group account users; full-text of privileged commands]
    AU-3 (1) Guidance: For client-server transactions, the number of bytes sent and received gives bidirectional transfer information that can be helpful during an investigation or inquiry.
  title: >-
    AU-3(1) - CONTENT OF AUDIT RECORDS | ADDITIONAL AUDIT INFORMATION
  levels:
  - high
  - moderate
- id: AU-4
  status: pending
  notes: |-
    Customers are responsible for allocating audit record storage capacity
    in accordance with the organizations requirements. A successful control
    response will explain the procedures in place to ensure that audit
    storage is allocated according to meet customer requirements.
  rules: []
  description: |-
    The organization allocates audit record storage capacity in accordance with [Assignment:
    organization-defined audit record storage requirements].

    Supplemental Guidance:  Organizations consider the types of auditing to be performed and the audit processing requirements when allocating audit storage capacity. Allocating sufficient audit storage capacity reduces the likelihood of such capacity being exceeded and resulting in the potential loss or reduction of auditing capability. Related controls: AU-2, AU-5, AU-6, AU-7, AU-11, SI-4.

    References: None.
  title: >-
    AU-4 - AUDIT STORAGE CAPACITY
  levels:
  - high
  - moderate
  - low
- id: AU-6
  status: pending
  notes: |-
    Section a: Customers are responsible for review and analysis of the information
    system audit records at least weekly for indications of inappropriate
    or unusual activity. A successful control response will outline how
    often audit records are reviewed, and types of activities they are
    reviewed for.
    Section b: Customers are responsible for ensuring that audit review findings are
    reported to the appropriate personnel. A successful control response
    will outline how the audit review findings are reported.
  rules: []
  description: "The organization:\n a. Reviews and analyzes information system audit\
    \ records [Assignment: organization-defined frequency] for indications of [Assignment:\
    \ organization-defined inappropriate or unusual activity]; and\n b. Reports findings\
    \ to [Assignment: organization-defined personnel or roles].\n\nSupplemental Guidance:\
    \  Audit review, analysis, and reporting covers information security-related auditing\
    \ performed by organizations including, for example, auditing that results from\
    \ monitoring of account usage, remote access, wireless connectivity, mobile device\
    \ connection, configuration settings, system component inventory, use of maintenance\
    \ tools and nonlocal maintenance, physical access, temperature and humidity, equipment\
    \ delivery and removal, communications at the information system boundaries, use\
    \ of mobile code, and use of VoIP. Findings can be reported to organizational\
    \ entities that include, for example, incident response team, help desk, information\
    \ security group/department. If organizations are prohibited from reviewing and\
    \ analyzing audit information or unable to conduct such activities (e.g., in certain\
    \ national security applications or systems), the review/analysis may be carried\
    \ out by other organizations granted such authority. Related controls: AC-2, AC-3,\
    \ AC-6, AC-17, AT-3, AU-7, AU-16, CA-7, CM-5, CM-10, CM-11, IA-3, IA-5, IR-5,\
    \ IR-6, MA-4, MP-4, PE-3, PE-6, PE-14, PE-16, RA-5, SC-7, SC-18, SC-19, SI-3,\
    \ SI-4, SI-7.\n\nReferences: None.\n\nAU-6 (a)-1 [at least weekly] \nAU-6 Requirement:\
    \ Coordination between service provider and consumer shall be documented and accepted\
    \ by the JAB/AO. In multi-tennant environments, capability and means for providing\
    \ review, analysis, and reporting to consumer for data pertaining to consumer\
    \ shall be documented."
  title: >-
    AU-6 - AUDIT REVIEW, ANALYSIS, AND REPORTING
  levels:
  - high
  - moderate
  - low
- id: AU-6(1)
  status: pending
  notes: |-
    Customers are responsible for employing automated mechanisms to
    integrate audit, review, analysis, and reporting process to support
    organizational processes for investigation and response to suspicious
    activities. A successful control response will review the automated
    tools used for integrating review, analysis, and reporting, and how
    these tools are employed.
  rules: []
  description: |-
    The organization employs automated mechanisms to integrate audit review, analysis, and reporting processes to support organizational processes for investigation and response to suspicious activities.

    Supplemental Guidance:  Organizational processes benefiting from integrated audit review, analysis, and reporting include, for example, incident response, continuous monitoring, contingency planning, and Inspector General audits. Related controls: AU-12, PM-7.
  title: >-
    AU-6(1) - AUDIT REVIEW, ANALYSIS, AND REPORTING | PROCESS INTEGRATION
  levels:
  - high
  - moderate
- id: AU-6(3)
  status: pending
  notes: |-
    Customers are responsible for analyzing and correlating audit records
    accross different repositories to gain organiational-wide situational
    awareness. A successful control response will discuss how the organization
    correlates and analyzes audit records from different sources. This can
    include processes and tools used to meet these goals.
  rules: []
  description: |-
    The organization analyzes and correlates audit records across different repositories to gain organization-wide situational awareness.

    Supplemental Guidance:  Organization-wide situational awareness includes awareness across all three tiers of risk management (i.e., organizational, mission/business process, and information system) and supports cross-organization awareness. Related controls: AU-12, IR-4.
  title: >-
    AU-6(3) - AUDIT REVIEW, ANALYSIS, AND REPORTING | CORRELATE AUDIT REPOSITORIES
  levels:
  - high
  - moderate
- id: AU-7
  status: pending
  notes: |-
    Section a: Customers are responsible for ensuring that the information system
    provides an audit reduction and report generation capability that
    supports on demand audit review, analysis, and reporting requirements
    and after-the-fact investigations of security incidents. A successful
    control response will discuss how the information system provides
    audit reduction and report generation that supports these requirements.
    This can include a discussion of tools used to provide this capability,
    and how they are used.
  rules: []
  description: |-
    The information system provides an audit reduction and report generation capability that:
     a. Supports on-demand audit review, analysis, and reporting requirements and after-the-fact investigations of security incidents; and
     b. Does not alter the original content or time ordering of audit records.

    Supplemental Guidance:  Audit reduction is a process that manipulates collected audit information and organizes such information in a summary format that is more meaningful to analysts. Audit reduction and report generation capabilities do not always emanate from the same information system or from the same organizational entities conducting auditing activities. Audit reduction capability can include, for example, modern data mining techniques with advanced data filters to identify anomalous behavior in audit records. The report generation capability provided by the information system can generate customizable reports. Time ordering of audit records can be a significant issue if the granularity of the timestamp in the record is insufficient. Related control: AU-6.

    References: None.
  title: >-
    AU-7 - AUDIT REDUCTION AND REPORT GENERATION
  levels:
  - high
  - moderate
- id: AU-9(4)
  status: pending
  notes: |-
    Customers are required to authorize access to management of audit
    functionality to only a subset of privileged users. A successful control
    response will discuss how access to audit functionality is restricted
    to only appropriate personnel. This can include a description of who
    this functionality is restricted to, and how this is controlled.
  rules: []
  description: |-
    The organization authorizes access to management of audit functionality to only [Assignment: organization-defined subset of privileged users].

    Supplemental Guidance:  Individuals with privileged access to an information system and who are also the subject of an audit by that system, may affect the reliability of audit information by inhibiting audit activities or modifying audit records. This control enhancement requires that privileged access be further defined between audit-related privileges and other privileges, thus limiting the users with audit-related privileges. Related control: AC-5.
  title: >-
    AU-9(4) - PROTECTION OF AUDIT INFORMATION | ACCESS BY SUBSET OF PRIVILEGED USERS
  levels:
  - high
  - moderate
- id: AU-11
  status: pending
  notes: |-
    Customers are required to retain audit records for at least ninety
    days to provide support for after the fact investigations of security
    incidents and to meet regulatory and organizational information
    retention requirements. A successful control response will discuss how
    long audit records are retained.

    Audit log retention may be configured in the underlying Red Hat
    Enterprise Linux audit daemon. If using a central or 3rd party
    logging solution, this may likely need to be configured in that tool.
  rules: []
  description: "The organization retains audit records for [Assignment: organization-defined\
    \ time period consistent with records retention policy] to provide support for\
    \ after-the-fact investigations of security incidents and to meet regulatory and\
    \ organizational information retention requirements.\n\nSupplemental Guidance:\
    \  Organizations retain audit records until it is determined that they are no\
    \ longer needed for administrative, legal, audit, or other operational purposes.\
    \ This includes, for example, 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 record retention. Related controls: AU-4, AU-5, AU-9,\
    \ MP-6.\n\nReferences: None.\n\nAU-11 [at least one (1) year] \nAU-11 Requirement:\
    \ The service provider retains audit records on-line for at least ninety days\
    \ and further preserves audit records off-line for a period that is in accordance\
    \ with NARA requirements."
  title: >-
    AU-11 - AUDIT RECORD RETENTION
  levels:
  - high
  - moderate
  - low
- id: CA-1
  status: pending
  notes: |-
    Section a: The organization will be responsible for developing, documenting, and
    disseminating Security Assessment and Authorization policy and
    procedures. A successful control response will need to address the
    content of the policy (which must include purpose, scope, roles,
    responsibilities, management commitment, coordination, and compliance)
    and procedures (which must facilitate the implementation of
    the policies and associated controls).
    Section b: The organization will be responsible for reviewing and updating the
    Security Assessment and Authorization policy every 3 years, and
    procedures annually. A successful control response will need to
    address the review and update process, including the role(s)
    responsible for initiating the review process, updating the policy
    and procedures, and providing approval of the updates.
  rules: []
  description: "The organization:\n a. Develops, documents, and disseminates to [Assignment:\
    \ organization-defined personnel or roles]:\n   1. A security assessment and authorization\
    \ policy that addresses purpose, scope, roles, responsibilities, management commitment,\
    \ coordination among organizational entities, and compliance; and\n   2. Procedures\
    \ to facilitate the implementation of the security assessment and authorization\
    \ policy and associated security assessment and authorization controls; and\n\
    \ b. Reviews and updates the current:\n   1. Security assessment and authorization\
    \ policy [Assignment: organization-defined frequency]; and\n   2. Security assessment\
    \ and authorization procedures [Assignment: organization-defined frequency].\n\
    \nSupplemental Guidance: This control addresses the establishment of policy and\
    \ procedures for the effective implementation of selected security controls and\
    \ control enhancements in the CA family. Policy and procedures reflect applicable\
    \ federal laws, Executive Orders, directives, regulations, policies, standards,\
    \ and guidance. Security program policies and procedures at the organization level\
    \ may make the need for system-specific policies and procedures unnecessary. The\
    \ policy can be included as part of the general information security policy for\
    \ organizations or conversely, can be represented by multiple policies reflecting\
    \ the complex nature of certain organizations. The procedures can be established\
    \ for the security program in general and for particular information systems,\
    \ if needed. The organizational risk management strategy is a key factor in establishing\
    \ policy and procedures. Related control: PM-9.\n\nControl Enhancements:  None.\n\
    \nReferences:  NIST Special Publications 800-12, 800-37, 800-53A, 800-100.\n\n\
    CA-1 (b) (1) [at least annually] \nCA-1 (b) (2) [at least annually or whenever\
    \ a significant change occurs]"
  title: >-
    CA-1 - SECURITY ASSESSMENT AND AUTHORIZATION

    POLICY AND PROCEDURES
  levels:
  - high
  - moderate
  - low
- id: CA-2
  status: pending
  notes: |-
    Section a: The organization will be responsible for developing a Security Assessment
    Plan. A successful control response will need to address the
    involement of a FedRAMP-accredited 3PAO (see CA-2(1)), the scope
    of the assessment, and any specific requirements the organization has
    for the 3PAO.
  rules: []
  description: "The organization:\n a. Develops a security assessment plan that describes\
    \ the scope of the assessment including:\n   1. Security controls and control\
    \ enhancements under assessment;\n   2. Assessment procedures to be used to determine\
    \ security control effectiveness; and\n   3. Assessment environment, assessment\
    \ team, and assessment roles and responsibilities;\n b. Assesses the security\
    \ controls in the information system and its environment of operation [Assignment:\
    \ organization-defined frequency] to determine the extent to which the controls\
    \ are implemented correctly, operating as intended, and producing the desired\
    \ outcome with respect to meeting established security requirements;\n c. Produces\
    \ a security assessment report that documents the results of the assessment; and\n\
    \ d. Provides the results of the security control assessment to [Assignment: organization-defined\
    \ individuals or roles].\n\nSupplemental Guidance:  Organizations assess security\
    \ controls in organizational information systems and the environments in which\
    \ those systems operate as part of: (i) initial and ongoing security authorizations;\
    \ (ii) FISMA annual assessments; (iii) continuous monitoring; and (iv) system\
    \ development life cycle activities. Security assessments: (i) ensure that information\
    \ security is built into organizational information systems; (ii) identify weaknesses\
    \ and deficiencies early in the development process; (iii) provide essential information\
    \ needed to make risk-based decisions as part of security authorization processes;\
    \ and (iv) ensure compliance to vulnerability mitigation procedures. Assessments\
    \ are conducted on the implemented security controls from Appendix F (main catalog)\
    \ and Appendix G (Program Management controls) as documented in System Security\
    \ Plans and Information Security Program Plans. Organizations can use other types\
    \ of assessment activities such as vulnerability scanning and system monitoring\
    \ to maintain the security posture of information systems during the entire life\
    \ cycle. Security 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 security controls are implemented correctly,\
    \ operating as intended, and producing the desired outcome with respect to meeting\
    \ security requirements. The FISMA requirement for assessing security controls\
    \ at least annually does not require additional assessment activities to those\
    \ activities already in place in organizational security authorization processes.\
    \ Security assessment results are provided to the individuals or roles appropriate\
    \ for the types of assessments being conducted. For example, assessments conducted\
    \ in support of security authorization decisions are provided to authorizing officials\
    \ or authorizing official designated representatives.\n\nTo satisfy annual assessment\
    \ requirements, organizations can use assessment results from the following sources:\
    \ (i) initial or ongoing information system authorizations; (ii) continuous monitoring;\
    \ or (iii)  system development life cycle activities. Organizations ensure that\
    \ security assessment results are current, relevant to the determination of security\
    \ control effectiveness, and obtained with the appropriate level of assessor independence.\
    \ Existing security 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. Subsequent to initial authorizations and in accordance with OMB policy,\
    \ organizations assess security controls during continuous monitoring. Organizations\
    \ establish the frequency for ongoing security control assessments in accordance\
    \ with organizational continuous monitoring strategies. Information Assurance\
    \ Vulnerability Alerts provide useful examples of vulnerability mitigation procedures.\
    \ External audits (e.g., audits by external entities such as regulatory agencies)\
    \ are outside the scope of this control. Related controls: CA-5, CA-6, CA-7, PM-9,\
    \ RA-5, SA-11, SA-12, SI-4.\n\nReferences: Executive Order 13587; FIPS Publication\
    \ 199; NIST Special Publications 800-37, 800-39, 800-53A, 800-115, 800-137.\n\n\
    CA-2 (b) [at least annually] \nCA-2 (d) [individuals or roles to include FedRAMP\
    \ PMO]\nCA-2 Guidance: See the FedRAMP Documents page under Key Cloud Service\n\
    Provider (CSP) Documents> Annual Assessment Guidance\nhttps://www.FedRAMP.gov/documents/"
  title: >-
    CA-2 - SECURITY ASSESSMENTS
  levels:
  - high
  - moderate
  - low
- id: CA-2(1)
  status: pending
  notes: |-
    The customer will be responsible for employing a FedRAMP-accredited
    3PAO to conduct security control assessments. In addition to performing
    the assessment, this 3PAO will assist in the development of the Security
    Assessment Plan and Security Assessment Report (see CA-2).
  rules: []
  description: "The organization employs assessors or assessment teams with [Assignment:\
    \ organization-defined level of independence] to conduct security control assessments.\n\
    \nSupplemental Guidance:  Independent assessors or assessment teams are individuals\
    \ or groups who conduct impartial assessments of organizational information systems.\
    \ Impartiality implies that assessors are free from any perceived or actual conflicts\
    \ of interest with regard to the development, operation, or management of the\
    \ organizational information systems under assessment or to the determination\
    \ of security control effectiveness. To achieve impartiality, assessors should\
    \ not: (i) create a mutual or conflicting interest with the organizations where\
    \ the assessments are being conducted; (ii) assess their own work; (iii) act as\
    \ management or employees of the organizations they are serving; or (iv) place\
    \ themselves in positions of advocacy for the organizations acquiring their services.\
    \ Independent assessments can be obtained from elements within organizations or\
    \ can 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 information systems and/or the ultimate 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.\
    \ This includes determining whether contracted security assessment services have\
    \ sufficient independence, for example, when information system owners are not\
    \ directly involved in contracting processes or cannot unduly influence the impartiality\
    \ of assessors conducting assessments. In special situations,\nfor example, when\
    \ organizations that own the information systems are small or organizational structures\
    \ require that assessments are conducted by individuals that are in the developmental,\
    \ operational, or management chain of 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. Organizations recognize\
    \ that assessments performed for purposes other than direct support to authorization\
    \ decisions are, when performed by assessors with sufficient independence, more\
    \ likely to be useable for such decisions, thereby reducing the need to\nrepeat\
    \ assessments.\n \nCA-2 (1) Requirement: For JAB Authorization, must use an accredited\
    \ 3PAO."
  title: >-
    CA-2(1) - SECURITY ASSESSMENTS | INDEPENDENT ASSESSORS
  levels:
  - high
  - moderate
  - low
- id: CA-2(2)
  status: pending
  notes: |-
    The customer will be responsible for ensuring that, at a minimum,
    vulnerability scanning is performed annually as part of the
    assessment process. A successful control response will need to address
    the minimum requirement, as well as discussing any additional testing
    performed during assessments, such as malicious user testing, insider
    threat assessment, performance/load testing, or other tests the customer
    chooses to perform.
  rules: []
  description: |-
    The organization includes as part of security control assessments, [Assignment: organization- defined frequency], [Selection: announced; unannounced], [Selection (one or more): in-depth monitoring; vulnerability scanning; malicious user testing; insider threat assessment; performance/load testing; [Assignment: organization-defined other forms of security assessment]].

    Supplemental Guidance:  Organizations can employ information system monitoring, insider threat assessments, malicious user testing, and other forms of testing (e.g., verification and validation) to improve readiness by exercising organizational capabilities and indicating current performance levels as a means of focusing actions to improve security. Organizations conduct assessment activities in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards. Authorizing officials approve the assessment methods in coordination with the organizational risk executive function. Organizations can incorporate vulnerabilities uncovered during assessments into vulnerability remediation processes. Related controls: PE-3, SI-2.

    CA-2 (2) [at least annually]
    CA-2 (2) Requirement: To include 'announced', 'vulnerability scanning'
  title: >-
    CA-2(2) - SECURITY ASSESSMENTS | SPECIALIZED ASSESSMENTS
  levels:
  - high
  - moderate
- id: CA-2(3)
  status: pending
  notes: |-
    The customer will be responsible for working with a 3PAO to assess
    the system using the methodology prescribed by FedRAMP. A successful
    control response will need to address how the assessment will be carried
    out and how the results will be documented and submitted to FedRAMP
    for approval.
  rules: []
  description: |-
    The organization accepts the results of an assessment of [Assignment: organization-defined information system] performed by [Assignment: organization-defined external organization] when the assessment meets [Assignment: organization-defined requirements].

    Supplemental Guidance:  Organizations may often rely on assessments of specific information systems by other (external) organizations. Utilizing such existing assessments (i.e., reusing existing assessment evidence) can significantly decrease the time and resources required for organizational assessments by limiting the amount of independent assessment activities that organizations need to perform. The factors that organizations may consider in determining whether to accept assessment results from external organizations can vary. Determinations for accepting assessment results can be based on, for example, past assessment experiences one organization has had with another organization, the reputation that organizations have with regard to assessments, the level of detail of supporting assessment documentation provided, or mandates imposed upon organizations by federal legislation, policies, or directives.

    CA-2 (3)-1 [any FedRAMP Accredited 3PAO]
    CA-2 (3)-1-2 [any FedRAMP Accredited 3PAO]
    CA-2 (3)-1-3 [the conditions of the JAB/AO in the FedRAMP Repository]
  title: >-
    CA-2(3) - SECURITY ASSESSMENTS | EXTERNAL ORGANIZATIONS
  levels:
  - high
  - moderate
- id: CA-3
  status: pending
  notes: |-
    Section a: The customer will be responsible for authorizing connections to
    external information systems. A successful control response will
    need to address the individuals or roles responsible for engaging with
    authorized points of contact for such external systems and the process
    for documenting and signing the conditions of the connections in
    Interconnection System Agreements.
    Section b: The customer will be responsible for documenting the details of each
    interconnection. A successful control response will need to address
    the process for verifying the interface characteristics, security
    requirements, and the nature of the information communicated; a summary
    of this information will need to be included as part of the table
    above.
    Section c: The customer will be responsible for reviewing and updating the
    Interconnection Security Agreements at the required frequency. A
    successful control response will need to discuss the initiation of the
    review process, as well as the roles or individuals responsible for
    reviewing, verifying, updating, and approving any changes to the
    documentation.
  rules: []
  description: |-
    The organization:
     a. Authorizes connections from the information system to other information systems through the use of Interconnection Security Agreements;
     b. Documents, for each interconnection, the interface characteristics, security requirements, and the nature of the information communicated; and
     c. Reviews and updates Interconnection Security Agreements [Assignment: organization-defined frequency].

    Supplemental Guidance:  This control applies to dedicated connections between information systems (i.e., system interconnections) and does not apply to transitory, user-controlled connections such as email and website browsing. Organizations carefully consider the risks that may be introduced when information systems are connected to other systems with different security requirements and security controls, both within organizations and external to organizations. Authorizing officials determine the risk associated with information system connections and the appropriate controls employed. If interconnecting systems have the same authorizing official, organizations do not need to develop Interconnection Security Agreements. Instead, organizations can describe the interface characteristics between those interconnecting systems in their respective security plans. If interconnecting systems have different authorizing officials within the same organization, organizations can either develop Interconnection Security Agreements or describe the interface characteristics between systems in the security plans for the respective systems. Organizations may also incorporate Interconnection Security Agreement information into formal contracts, especially for interconnections established between federal agencies and nonfederal (i.e., private sector) organizations. Risk considerations also include information systems sharing the same networks. For certain technologies (e.g., space, unmanned aerial vehicles, and medical devices), there may be specialized connections in place during preoperational testing. Such connections may require Interconnection Security Agreements and be subject to additional security controls.
    Related controls: AC-3, AC-4, AC-20, AU-2, AU-12, AU-16, CA-7, IA-3, SA-9, SC-7, SI-4.

    References: FIPS Publication 199; NIST Special Publication 800-47.

    CA-3 (c) [at least annually and on input from FedRAMP]
  title: >-
    CA-3 - SYSTEM INTERCONNECTIONS
  levels:
  - high
  - moderate
  - low
- id: CA-3(3)
  status: pending
  notes: |-
    The organization will be responsible for requiring unclassified,
    non-national security systems to connect to customer applications
    through a TIC. A successful control response will need to address
    whether this requirement is enforced using technical means or via
    policy considerations.
  rules: []
  description: "The organization prohibits the direct connection of an [Assignment:\
    \ organization-defined unclassified, non-national security system] to an external\
    \ network without the use of [Assignment; organization-defined boundary protection\
    \ device].\n\nSupplemental Guidance:  Organizations typically do not have control\
    \ over external networks (e.g., the Internet). Approved boundary protection devices\
    \ (e.g., routers, firewalls) mediate communications (i.e., information flows)\
    \ between unclassified non-national security systems and external networks. This\
    \ control enhancement is required for organizations processing, storing, or transmitting\
    \ Controlled Unclassified Information (CUI).\n\nCA-3 (3)-2 [Boundary Protections\
    \ which meet the Trusted Internet Connection (TIC) requirements]\nCA-3 (3) Guidance:\
    \ Refer to Appendix H \u2013 Cloud Considerations of the TIC 2.0 Reference Architecture\
    \ document."
  title: >-
    CA-3(3) - SYSTEM INTERCONNECTIONS | UNCLASSIFIED NON-NATIONAL SECURITY SYSTEM
    CONNECTIONS
  levels:
  - high
  - moderate
- id: CA-3(5)
  status: pending
  notes: |-
    The customer will be responsible for determining whether connections
    to external information systems will be governed by an
    allow-all/deny-by-exception policy or by a deny-all/allow-by-exception
    policy. A successful control response will need to address the rationale
    for the selection. In addition, the policy choice and its rationale will
    need to be included in the Architecture Briefing and in the introductory
    sections of this Security Plan.
  rules: []
  description: |-
    The organization employs [Selection: allow-all, deny-by-exception; deny-all, permit-by-exception] policy for allowing [Assignment: organization-defined information systems] to connect to external information systems.

    Supplemental Guidance:  Organizations can constrain information system connectivity to external domains (e.g., websites) by employing one of two policies with regard to such connectivity: (i) allow-all, deny by exception, also known as blacklisting (the weaker of the two policies); or (ii) deny-all, allow by exception, also known as whitelisting (the stronger of the two policies). For either policy, organizations determine what exceptions, if any, are acceptable. Related control: CM-7.

    CA-3 (5) [deny-all, permit by exception]

    [any systems]
    CA-3 (5) Guidance: For JAB Authorization, CSPs shall include details of this control in their Architecture Briefing
  title: >-
    CA-3(5) - SYSTEM INTERCONNECTIONS | RESTRICTIONS ON EXTERNAL SYSTEM CONNECTIONS
  levels:
  - high
  - moderate
- id: CA-6
  status: pending
  notes: |-
    Section a: The organization will be responsible for working with FedRAMP to designate
    an authorizing official. A successful control response will need to
    address how an appropriate authorizing official is selected.
    Section b: The organization will be responsible for recieving official authorizaiton
    from the authorizing official prior to commencing operations for
    federal customers. A successful control response will need to address
    the inputs provided to the authorizing official so that an
    accreditation decision can be made.
    Section c: The organization will be responsible for updating the accreditation
    package at the required frequency. A successful control response will
    need to address the components of the package that will be updated,
    the process for re-assessing the system in alignment with the updated
    package, and the personnel or roles responsible for managing the
    update process and engaging with FedRAMP for renewal of authorization.
  rules: []
  description: "The organization:\n a. Assigns a senior-level executive or manager\
    \ as the authorizing official for the information system;\n b. Ensures that the\
    \ authorizing official authorizes the information system for processing before\
    \ commencing operations; and\n c. Updates the security authorization [Assignment:\
    \ organization-defined frequency].\n\nSupplemental Guidance:  Security authorizations\
    \ are official management decisions, conveyed through authorization decision documents,\
    \ by senior organizational officials or executives (i.e., authorizing officials)\
    \ to authorize operation of information systems and to explicitly accept the risk\
    \ to organizational operations and assets, individuals, other organizations, and\
    \ the Nation based on the implementation of agreed-upon security controls. Authorizing\
    \ officials provide budgetary\noversight for organizational information systems\
    \ or assume responsibility for the mission/business operations supported by those\
    \ systems. The security authorization process is an inherently federal responsibility\
    \ and therefore, authorizing officials must be federal employees. Through the\
    \ security authorization process, authorizing officials assume responsibility\
    \ and are accountable for security risks associated with the operation and use\
    \ of organizational information systems. Accordingly, authorizing officials are\
    \ in positions with levels of authority commensurate with understanding and accepting\
    \ such information security-related risks. OMB policy requires that organizations\
    \ conduct ongoing authorizations of information systems by implementing continuous\
    \ monitoring programs. Continuous monitoring programs can satisfy three-year reauthorization\
    \ requirements, so separate reauthorization processes are not necessary. Through\
    \ the employment of comprehensive continuous monitoring processes, critical information\
    \ contained in authorization packages (i.e., security plans, security assessment\
    \ reports, and plans of action and milestones) is updated on an ongoing basis,\
    \ providing authorizing officials and information system owners with an up-to-date\
    \ status of the security state of organizational information systems and environments\
    \ of operation. To reduce the administrative cost of security reauthorization,\
    \ authorizing officials use the results of continuous monitoring processes to\
    \ the maximum extent possible as the basis for rendering reauthorization decisions.\
    \ Related controls: CA-2, CA-7, PM-9, PM-10.\n\nControl Enhancements:  None. \n\
    \nReferences:  OMB Circular A-130; OMB Memorandum 11-33; NIST Special Publications\
    \ 800-37, 800-137.\n\nCA-6 (c) [at least every three (3) years or when a significant\
    \ change occurs] \nCA-6 (c) Guidance: Significant change is defined in NIST Special\
    \ Publication 800-37 Revision 1, Appendix F. The service provider describes the\
    \ types of changes to the information system or the environment of operations\
    \ that would impact the risk posture. The types of changes are approved and accepted\
    \ by the JAB/AO."
  title: >-
    CA-6 - SECURITY AUTHORIZATION
  levels:
  - high
  - moderate
  - low
- id: CA-7
  status: pending
  notes: |-
    Section a: The organization will be responsible for developing a continuous
    monitoring strategy that meets the requirements. For metrics to be
    monitored, a successful control response will need to include a
    discussion of what information the organization considers important to
    monitor, as well as a rationale for that information being sufficient
    to demonstrate the ongoing security of the system.
    Section b: The organization will be responsible for developing a continuous
    monitoring strategy that meets the requirements. For frequency of
    monitoring, a successful control response will need to address the
    rationale for the selected frequency. This frequency should be
    compatible with the frequency of POA&M reporting specified in CA-5.
    Section c: The customer will be responsible for including ongoing security
    control assessments as part of the continuous monitoring program. This
    may include assessment of controls specifically found to be other than
    satisfied as part of the 3PAO assessments discussed in CA-2, as well as
    internal assessment of satisfied controls to verify continued
    effectiveness of implementation. A successful control response will
    need to address the roles or individuals responsible for testing, as
    well as the methodology used for testing.
    Section d: The customer will be responsible for monitoring the metrics defined
    in part (a) as part of continuous monitoring. A successful control
    response will need to discuss how metrics are gathered and reported,
    as well as the conditions under which monitoring will lead to changes
    or additions to related reporting, such as POA&M reporting.
    Section e: The customer will be responsible for correlating and analyzing
    security-related information gathered from multiple sources, including
    periodic assessments and continuous monitoring. A successful control
    response will need to address tools or processes used to perform
    correlation and analysis.
    Section f: The customer will be responsible for responding appropriately
    to the results of the analysis in part (e). A successful control
    response will need to discuss under what conditions each response action
    should be taken (for example, if a new vulnerability is found in the
    system, a POA&M item should be opened).
    Section g: The customer will be responsible for reporting the security status of
    the system in accordance with FedRAMP requirements at a regular
    frequency. This frequency should be compatible with the frequency of
    POA&M reporting specified in CA-5.
    Section Req. 1: The customer will be responsible for performing vulnerability scans
    of operating systems at least monthly. See also RA-5.
    Section Req. 2: The customer will be responsible for performing vulnerability scans
    of databases and web applications at least monthly. See also RA-5.
    Section Req. 3: The customer will be responsible for ensuring that an independent
    assessor performs vulnerability scans at least annually. See also
    CA-2(2).
  rules: []
  description: |-
    The organization develops a continuous monitoring strategy and implements a continuous monitoring program that includes:
     a. Establishment of [Assignment: organization-defined metrics] to be monitored;
     b. Establishment of [Assignment: organization-defined frequencies] for monitoring and [Assignment: organization-defined frequencies] for assessments supporting such monitoring;
     c. Ongoing security control assessments in accordance with the organizational continuous monitoring strategy;
     d. Ongoing security status monitoring of organization-defined metrics in accordance with the organizational continuous monitoring strategy;
     e. Correlation and analysis of security-related information generated by assessments and monitoring;
     f. Response actions to address results of the analysis of security-related information; and
     g. Reporting the security status of organization and the information system to [Assignment: organization-defined personnel or roles] [Assignment: organization-defined frequency].

    Supplemental Guidance:  Continuous monitoring programs facilitate ongoing awareness of threats, vulnerabilities, and information security to support organizational risk management decisions. The terms continuous and ongoing imply that organizations assess/analyze security controls and information security-related risks at a frequency sufficient to support organizational risk-based decisions. The results of continuous monitoring programs generate appropriate risk response actions by organizations. Continuous monitoring programs also allow organizations to maintain the security authorizations of information systems and common controls over time in highly dynamic environments of operation with changing mission/business needs, threats, vulnerabilities, and technologies. Having access to security-related information on a continuing basis through reports/dashboards gives organizational officials the capability to make more effective and timely risk management decisions, including ongoing security authorization decisions. Automation supports more frequent updates to security authorization packages, hardware/software/firmware inventories, 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 information systems. Related controls: CA-2, CA-5, CA-6, CM-3, CM-4, PM-6, PM-9, RA-5, SA-11, SA-12, SI-2, SI-4.

    References: OMB Memorandum 11-33; NIST Special Publications 800-37, 800-39, 800-53A, 800-115, 800-137; US-CERT Technical Cyber Security Alerts; DoD Information Assurance Vulnerability Alerts.

    CA-7 (g) [to meet Federal and FedRAMP requirements]
    CA-7 Requirement: Operating System Scans: at least monthly. Database and Web Application Scans: at least monthly. All scans performed by Independent Assessor: at least annually
    CA-7 Guidance: CSPs must provide evidence of closure and remediation of high vulnerabilities within the timeframe for standard POA&M updates.
    CA-7 Guidance: See the FedRAMP Documents page under Key Cloud Service
    Provider (CSP) Documents> Continuous Monitoring Strategy Guide
    https://www.FedRAMP.gov/documents/
  title: >-
    CA-7 - CONTINUOUS MONITORING
  levels:
  - high
  - moderate
  - low
- id: CA-7(1)
  status: pending
  notes: |-
    The customer will be responsible for monitoring security controls on
    an ongoing basis with the assistance of an assessment team with a
    control-defined level of independance. Note that this may be the 3PAO
    used for recurring assessments, it may be a different independent
    assessor, or it may be a team of personnel employed by the customer. A
    successful control response will need to address the nature of this team
    and the methods by which they access security controls within the
    system.
  rules: []
  description: |-
    The organization employs assessors or assessment teams with [Assignment: organization-defined level of independence] to monitor the security controls in the information system on an ongoing basis.

    Supplemental Guidance:  Organizations can maximize the value of assessments of security controls during the continuous monitoring process by requiring that such assessments be conducted by assessors or assessment teams with appropriate levels of independence based on continuous monitoring strategies. Assessor independence provides a degree of impartiality to the monitoring process. To achieve such impartiality, assessors should not: (i) create a mutual or conflicting interest with the organizations where the assessments are being conducted; (ii) assess their own work; (iii) act as management or employees of the organizations they are serving; or (iv) place themselves in advocacy positions for the organizations acquiring their services.
  title: >-
    CA-7(1) - CONTINUOUS MONITORING | INDEPENDENT ASSESSMENT
  levels:
  - high
  - moderate
- id: CA-8
  status: pending
  notes: |-
    The customer will be responsible for conducting penetration testing
    at the required frequency. A successful control response will need to
    address the systems or components tested and outline the rules of
    engagement for testing (e.g. operational personnel are/are not notified
    in advance of testing, certain components of the system are off-limits
    for this test, etc.).
  rules: []
  description: "The organization conducts penetration testing [Assignment: organization-defined\
    \ frequency] on [Assignment: organization-defined information systems or system\
    \ components].\n\nSupplemental Guidance:  Penetration testing is a specialized\
    \ type of assessment conducted on information systems or individual system components\
    \ to identify vulnerabilities that could be exploited by adversaries. Such testing\
    \ can be used to either validate vulnerabilities or determine the degree of resistance\
    \ organizational information systems have to adversaries within a set of specified\
    \ constraints (e.g., time, resources, and/or skills). Penetration testing attempts\
    \ to duplicate\nthe actions of adversaries in carrying out hostile cyber attacks\
    \ against organizations and provides a more in-depth analysis of security-related\
    \ weaknesses/deficiencies. Organizations can also use the results of vulnerability\
    \ analyses to support penetration testing activities. Penetration testing can\
    \ be conducted on the hardware, software, or firmware components of an information\
    \ system and can exercise both physical and technical security controls. A standard\
    \ method for penetration testing includes, for example: (i) pretest analysis based\
    \ on full knowledge of the target system; (ii) pretest identification of potential\
    \ vulnerabilities based on pretest analysis; and (iii) testing designed to determine\
    \ exploitability of identified vulnerabilities. All parties agree to the rules\
    \ of engagement before the commencement of penetration testing scenarios. Organizations\
    \ correlate the penetration testing rules of engagement with the tools, techniques,\
    \ and procedures that are anticipated to be employed by adversaries carrying out\
    \ attacks. Organizational risk assessments guide decisions on the level of independence\
    \ required for personnel conducting penetration testing. Related control: SA-12.\n\
    \nReferences: None.\n\nCA-8-1 [at least annually]\nGuidance: See the FedRAMP Documents\
    \ page under Key Cloud Service Provider (CSP) Documents> Penetration Test Guidance\
    \ \nhttps://www.FedRAMP.gov/documents/"
  title: >-
    CA-8 - PENETRATION TESTING
  levels:
  - high
  - moderate
- id: CA-8(1)
  status: pending
  notes: |-
    The customer will be responsible for employing an independent agent
    or team to perform penetration testing. A successful control response
    will need to address how independence is ensured.
  rules: []
  description: |-
    The organization employs an independent penetration agent or penetration team to perform penetration testing on the information system or system components.

    Supplemental Guidance:  Independent penetration agents or teams are individuals or groups who conduct impartial penetration testing of organizational information systems. Impartiality implies that penetration agents or teams are free from any perceived or actual conflicts of interest with regard to the development, operation, or management of the information systems that are the targets of the penetration testing. Supplemental guidance for CA-2 (1) provides additional information regarding independent assessments that can be applied to penetration testing. Related control: CA-2.
  title: >-
    CA-8(1) - PENETRATION TESTING | INDEPENDENT PENETRATION AGENT OR TEAM
  levels:
  - high
  - moderate
- id: CA-9
  status: pending
  notes: |-
    Section a: The customer will be responsible for authorizing connections within
    the system, such as between two types of virtual machines within the
    customer environment. A successful control response will need to address
    the individual or roles with the authorizing responsibility, as well
    as how a determination is made to allow a connection between
    components or classes of components.
    Section b: The customer will be responsible for documenting the required
    information for each internal connection. This may be documented in
    e.g. data flow diagrams or architectural diagrams. A successful control
    response will need to address the process by which this documentation
    is created.
  rules: []
  description: |-
    The organization:
     a. Authorizes internal connections of [Assignment: organization-defined information system components or classes of components] to the information system; and
     b. Documents, for each internal connection, the interface characteristics, security requirements, and the nature of the information communicated.

    Supplemental Guidance:  This control applies to connections between organizational information systems and (separate) constituent system components (i.e., intra-system connections) including, for example, system connections with mobile devices, notebook/desktop computers, printers, copiers, facsimile machines, scanners, sensors, and servers. Instead of authorizing each individual internal connection, organizations can authorize internal connections for a class of components with common characteristics and/or configurations, for example, all digital printers, scanners, and copiers with a specified processing, storage, and transmission capability or all smart phones with a specific baseline configuration. Related controls: AC-3, AC-4, AC-18, AC-19, AU-2, AU-12, CA-7, CM-2, IA-3, SC-7, SI-4.

    References: None.
  title: >-
    CA-9 - INTERNAL SYSTEM CONNECTIONS
  levels:
  - high
  - moderate
  - low
- id: CM-1
  status: pending
  notes: |-
    Section a: The organization will be responsible for developing, documenting, and
    disseminating Configuration Management policy and procedures. A
    successful control response will need to address the content of the
    policy (which must include purpose, scope, roles, responsibilities,
    management commitment, coordination, and compliance) and procedures
    (which must facilitate the implementation of the policies and
    associated controls).
    Section b: The organization will be responsible for reviewing and updating the
    Configuration Management policy every 3 years, and procedures
    annually. A successful control response will need to address
    the review and update process, including the role(s) responsible
    for initiating the review process, updaitng the policy and
    procedures, and providing approval of the updates
  rules: []
  description: |-
    The organization:
     a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:
       1. A configuration management policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and
       2. Procedures to facilitate the implementation of the configuration management policy and associated configuration management controls; and
     b. Reviews and updates the current:
       1. Configuration management policy [Assignment: organization-defined frequency]; and
       2. Configuration management procedures [Assignment: organization-defined frequency].

    Supplemental Guidance: This control addresses the establishment of policy and procedures for the effective implementation of selected security controls and control enhancements in the CM family. Policy and procedures reflect applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance. Security program policies and procedures at the organization level may make the need for system-specific policies and procedures unnecessary. The policy can be included as part of the general information security policy for organizations or conversely, can be represented by multiple policies reflecting the complex nature of certain organizations. The procedures can be established for the security program in general and for particular information systems, if needed. The organizational risk management strategy is a key factor in establishing policy and procedures. Related control: PM-9.

    Control Enhancements:  None.

    References:  NIST Special Publications 800-12, 800-100.

    CM-1 (b) (1) [at least annually]
    CM-1 (b) (2) [at least annually or whenever a significant change occurs]
  title: >-
    CM-1 - CONFIGURATION MANAGEMENT POLICY AND

    PROCEDURES
  levels:
  - high
  - moderate
  - low
- id: CM-2
  status: pending
  notes: |-
    The customer will be responsible for developing, documenting, and
    maintaining configuration control, a current baseline configuration
    of the information system. A successful control response will need to
    address the way the baseline configurations are managed and
    maintained.
  rules: []
  description: |-
    The organization develops, documents, and maintains under configuration control, a current baseline configuration of the information system.

    Supplemental Guidance:  This control establishes baseline configurations for information systems and system components including communications and connectivity-related aspects of systems. Baseline configurations are documented, formally reviewed and agreed-upon sets of specifications for information systems or configuration items within those systems. Baseline configurations serve as a basis for future builds, releases, and/or changes to information systems. Baseline configurations include information about information system components (e.g., standard software packages installed on workstations, notebook computers, servers, network components, or mobile devices; current version numbers and patch information on operating systems and applications; and configuration settings/parameters), network topology, and the logical placement of those components within the system architecture. Maintaining baseline configurations requires creating new baselines as organizational information systems change over time. Baseline configurations of information systems reflect the current enterprise architecture. Related controls: CM-3, CM-6, CM-8, CM-9, SA-10, PM-5, PM-7.

    References: NIST Special Publication 800-128.
  title: >-
    CM-2 - BASELINE CONFIGURATION
  levels:
  - high
  - moderate
  - low
- id: CM-2(1)
  status: pending
  notes: |-
    Section a: The customer will be responsible for reviewing and updating the
    baseline configuration of the information system at least annually.
    A successful control response will need to address how often the
    baseline configuration is reviewed and updated.
    Section b: The customer will be responsible for reviewing and updating the
    baseline configuration of the information system when required by the
    JAB. A successful control response will need to address updates to the
    baseline configuration when required by the JAB.
  rules: []
  description: "The organization reviews and updates the baseline configuration of\
    \ the information system: \n (a)   [Assignment: organization-defined frequency];\n\
    \ (b)   When required due to [Assignment organization-defined circumstances];\
    \ and\n (c)   As an integral part of information system component installations\
    \ and upgrades.\n\nSupplemental Guidance:  Related control: CM-5.\n\nCM-2 (1)\
    \ (a) [at least annually or when a significant change occurs]\nCM-2 (1) (b) [to\
    \ include when  directed by the JAB]\n CM-2 (1) (a) Guidance: Significant change\
    \ is defined in NIST Special Publication 800-37 Revision 1, Appendix F, page F-7."
  title: >-
    CM-2(1) - BASELINE CONFIGURATION | REVIEWS AND UPDATES
  levels:
  - high
  - moderate
- id: CM-3
  status: pending
  notes: |-
    Section a: The customer will be responsible for determining the types of changes
    to the information system that are configuration controlled. A
    successful control response will need to address how decisions are made
    to determine configuration controlled changes.
    Section b: The customer will be responsible for reviewing proposed configuration
    controlled changes to the information system and approving or
    disapproving changes with explicit consideration for security impact
    analysis. A successful control response will need to address how
    decisions are made to approve configuration control changes, including
    how the security impact of these changes is considered.
    Section c: The customer will be responsible for documenting configuration change
    decisions. A successful control response will need to address how
    configuration change decisions are documented. This can include, for
    example, what tools are used and what information is documented.
    Section e: The customer will be responsible for retaining records of
    configuration-controlled changes to the information system for a
    defined period. A successful control response will need to address long
    records of configuration-controlled changes are kept, and where these
    records are maintained.
    Section f: The customer will be responsible for auditing and reviewing activities
    associated with configuration-controlled changes to the information
    system for a defined period. A successful control response will need
    to ensure configuration control change activities are audited and
    reviewed. This can include tools used to track these changes and when
    these changes are reviewed.
    Section g: The customer will be responsible for coordinating and providing
    oversight for the configuration control activities through a central
    means of communicating major changes or developments that may affect
    services to the federal government. The means of communication must
    be approved and accepted by the JAB. A successful control response
    will outline how major changes or developments that affect government
    services will be coordinated and overseen.
  rules: []
  description: |-
    The organization:
     a. Determines the types of changes to the information system that are configuration-controlled;
     b. Reviews proposed configuration-controlled changes to the information system and approves or disapproves such changes with explicit consideration for security impact analyses;
     c. Documents configuration change decisions associated with the information system;
     d. Implements approved configuration-controlled changes to the information system;
     e. Retains records of configuration-controlled changes to the information system for [Assignment: organization-defined time period];
     f. Audits and reviews activities associated with configuration-controlled changes to the information system; and
     g. Coordinates and provides oversight for configuration change control activities through [Assignment: organization-defined configuration change control element (e.g., committee, board] that convenes [Selection (one or more): [Assignment: organization-defined frequency]; [Assignment: organization-defined configuration change conditions]].

    Supplemental Guidance:  Configuration change controls for organizational information systems involve the systematic proposal, justification, implementation, testing, review, and disposition of changes to the systems, including system upgrades and modifications. Configuration change control includes changes to baseline configurations for components and configuration items of information systems, changes to configuration settings for information technology products (e.g., operating systems, applications, firewalls, routers, and mobile devices), unscheduled/unauthorized changes, and changes to remediate vulnerabilities. Typical processes for managing configuration changes to information systems include, for example, Configuration Control Boards that approve proposed changes to systems. For new development information systems or systems undergoing major upgrades, organizations consider including representatives from development organizations on the Configuration Control Boards. Auditing of changes includes activities before and after changes are made to organizational information systems and the auditing activities required to implement such changes. Related controls: CM-2, CM-4, CM-5, CM-6, CM-9, SA-10, SI-2, SI-12.

    References: NIST Special Publication 800-128.

    CM-3 Requirement: The service provider establishes a central means of communicating major changes to or developments in the information system or environment of operations that may affect its services to the federal government and associated service consumers (e.g., electronic bulletin board, web status page). The means of communication are approved and accepted by the JAB/AO.
    CM-3 (e) Guidance: In accordance with record retention policies and procedures.
  title: >-
    CM-3 - CONFIGURATION CHANGE CONTROL
  levels:
  - high
  - moderate
- id: CM-5
  status: pending
  notes: |-
    The customer will be responsible for defining, documenting, approving
    and enforcing physical and logical access restrictions associated with
    changes to the information system. A successful control response will
    include how logical access associated with change control is defined,
    documented, and enforced. This should include tools used to enforce
    these restrictions, such as Active Directory, and how these personnel
    are approved for access.
  rules: []
  description: |-
    The organization defines, documents, approves, and enforces physical and logical access restrictions associated with changes to the information system.

    Supplemental Guidance:  Any changes to the hardware, software, and/or firmware components of information systems can potentially have significant effects on the overall security of the systems. Therefore, organizations permit only qualified and authorized individuals to access information systems for purposes of initiating changes, including upgrades and modifications. Organizations maintain records of access to ensure that configuration change control is implemented and to support after-the-fact actions should organizations discover any unauthorized changes. Access restrictions for change also include software libraries. Access restrictions include, for example, physical and logical access controls (see AC-3 and PE-3), workflow automation, media libraries, abstract layers (e.g., changes implemented into third-party interfaces rather than directly into information systems), and change windows (e.g., changes occur only during specified times, making unauthorized changes easy to discover). Related controls: AC-3, AC-6, PE-3.

    References: None.
  title: >-
    CM-5 - ACCESS RESTRICTIONS FOR CHANGE
  levels:
  - high
  - moderate
- id: CM-5(5)
  status: pending
  notes: |-
    Section a: The customer will be responsible for limiting privileges to change
    information system components and system related information within
    a production or operational environment. A successful control response
    will include how privileges to change the production/operation
    environment are limited. This can include defining who has access to
    these privileges, how they may be separated, and any gates they must
    go through.
    Section b: The customer will be responsible for reviewing and reevaluating
    privileges at least quarterly. A successful control response will
    include how often reviews are performed for presonnel with privileges
    to change the information system within the production environment.
  rules: []
  description: |-
    The organization:
     (a)   Limits privileges to change information system components and system-related information within a production or operational environment; and
     (b)   Reviews and reevaluates privileges [Assignment: organization-defined frequency].

    Supplemental Guidance:  In many organizations, information systems support multiple core missions/business functions. Limiting privileges to change information system components with respect to operational systems is necessary because changes to a particular information system component may have far-reaching effects on mission/business processes supported by the system where the component resides. The complex, many-to-many relationships between systems and mission/business processes are in some cases, unknown to developers. Related control: AC-2.

    CM-5 (5) (b) [at least quarterly]
  title: >-
    CM-5(5) - ACCESS RESTRICTIONS FOR CHANGE | LIMIT PRODUCTION /

    OPERATIONAL PRIVILEGES
  levels:
  - high
  - moderate
- id: CM-6
  status: pending
  notes: |-
    Section a: The customer will be responsible for establishing and documenting
    configuration settings for information technology products employed
    within the information system using FedRAMP guidance that reflects
    the most restrictive mode consistent with operational requirements. A
    successful control response will include how the customer develops
    base configurations to ensure that they are as restrictive as possible
    while still allowing the system to operate.
    Section c: The customer will be responsible for identifying, documenting, and
    approving any deviations from established configuration settings for
    components based on operational requirements. A successful control
    response will explain the process for identifying, documenting, and
    approving and deviations. This can include tools used to track any
    exceptions, and the process for identifying and approving these
    deviations.
  rules: []
  description: |-
    The organization:
     a. Establishes and documents configuration settings for information technology products employed within the information system using [Assignment: organization-defined security configuration checklists] that reflect the most restrictive mode consistent with operational requirements;
     b. Implements the configuration settings;
     c. Identifies, documents, and approves any deviations from established configuration settings for [Assignment: organization-defined information system components] based on [Assignment: organization-defined operational requirements]; and
     d. Monitors and controls changes to the configuration settings in accordance with organizational policies and procedures.

    Supplemental Guidance:  Configuration settings are the set of parameters that can be changed in hardware, software, or firmware components of the information system that affect the security posture and/or functionality of the system. Information technology products for which security- related configuration settings can be defined include, for example, mainframe computers, servers (e.g., database, electronic mail, authentication, web, proxy, file, domain name), workstations, input/output devices (e.g., scanners, copiers, and printers), network components (e.g., firewalls, routers, gateways, voice and data switches, wireless access points, network appliances, sensors), operating systems, middleware, and applications. Security-related parameters are those parameters impacting the security state of information systems including the parameters required to satisfy other security control requirements. Security-related parameters include, for example: (i) registry settings; (ii) account, file, directory permission settings; and (iii) settings for functions, ports, protocols, services, and remote connections. Organizations establish organization-wide configuration settings and subsequently derive specific settings for information systems. The established settings become part of the systems configuration baseline.

    Common secure configurations (also referred to as security configuration checklists, lockdown
    and hardening guides, security reference guides, security technical implementation guides) provide recognized, standardized, and established benchmarks that stipulate secure configuration settings for specific information technology platforms/products and instructions for configuring those information system components to meet operational requirements. Common secure configurations can be developed by a variety of organizations including, for example, information technology product developers, manufacturers, vendors, consortia, academia, industry, federal agencies, and other organizations in the public and private sectors. Common secure configurations include the United States Government Configuration Baseline (USGCB) which affects 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 (e.g., Common Configuration Enumeration) provide an effective method to uniquely identify, track, and control configuration settings. OMB establishes federal policy on configuration requirements for federal information systems. Related controls: AC-19, CM-2, CM-3, CM-7, SI-4.

    References: OMB Memoranda 07-11, 07-18, 08-22; NIST Special Publications 800-70, 800-128; Web: http://nvd.nist.gov, http://checklists.nist.gov, http://www.nsa.gov.

    CM-6 (a) [United States Government Configuration Baseline (USGCB)]
    CM-6 (a) Requirement 1: The service provider shall use the Center for Internet Security guidelines (Level 1) to establish configuration settings or establishes its own configuration settings if USGCB is not available.
    CM-6 (a) Requirement 2: The service provider shall ensure that checklists for configuration settings are Security Content Automation Protocol (SCAP) validated or SCAP compatible (if validated checklists are not available).
    CM-6 (a) Guidance: Information on the USGCB checklists can be found at: http://usgcb.nist.gov/usgcb_faq.html#usgcbfaq_usgcbfdcc
  title: >-
    CM-6 - CONFIGURATION SETTINGS
  levels:
  - high
  - moderate
  - low
- id: CM-6(1)
  status: pending
  notes: |-
    The customer will be responsible for employing automated mechanisms
    to centrally manage, apply, and verify configuration settings for
    information system components. A successful control response will
    describe any automated systems in place used to manage, apply, and
    verify configuration settings. An example of this is using Active
    Directory Group Policy Objects to manage security settings.
  rules: []
  description: |-
    The organization employs automated mechanisms to centrally manage, apply, and verify configuration settings for [Assignment: organization-defined information system components].

    Supplemental Guidance:  Related controls: CA-7, CM-4.
  title: >-
    CM-6(1) - CONFIGURATION SETTINGS | AUTOMATED CENTRAL MANAGEMENT / APPLICATION
    / VERIFICATION
  levels:
  - high
  - moderate
- id: CM-8
  status: pending
  notes: |-
    Section a: The customer will be responsible for developing and documenting an
    inventory that meets FedRAMP requirements. A successful control response
    will include a description of how the inventory is developed and
    documented. This process should ensure that the inventory accurately
    reflects the current system, includes and components, is granular enough
    to support tracking and reporting, and includes any information the
    customer has deemed necessary to achieve effective accountability.
    Section b: The customer will responsible for reviewing and updating the system
    inventory at least monthly. This may be performed in conjunction with
    continuous monitoring and POA&M tracking activities. A sucessful control
    response will need to address the personnel or roles responsible for
    updating the system inventory and the process for correcting gaps or
    discrepancies found.
  rules: []
  description: |-
    The organization:
     a. Develops and documents an inventory of information system components that:
       1. Accurately reflects the current information system;
       2. Includes all components within the authorization boundary of the information system;
       3. Is at the level of granularity deemed necessary for tracking and reporting; and
       4. Includes [Assignment: organization-defined information deemed necessary to achieve effective information system component accountability]; and
     b. Reviews and updates the information system component inventory [Assignment: organization-defined frequency].

    Supplemental Guidance:  Organizations may choose to implement centralized information system component inventories that include components from all organizational information systems. In such situations, organizations ensure that the resulting inventories include system-specific information required for proper component accountability (e.g., information system association, information system owner). Information deemed necessary for effective accountability of information system components includes, for example, hardware inventory specifications, software license information, software version numbers, component owners, and for networked components or devices, machine names and network addresses. Inventory specifications include, for example, manufacturer, device type, model, serial number, and physical location. Related controls: CM-2, CM-6, PM-5.

    References: NIST Special Publication 800-128.

    CM-8 (b) [at least monthly]
    CM-8 Requirement: must be provided at least monthly or when there is a change.
  title: >-
    CM-8 - INFORMATION SYSTEM COMPONENT INVENTORY
  levels:
  - high
  - moderate
  - low
- id: CM-8(5)
  status: pending
  notes: |-
    The customer will be responsible for verifying all components within
    the authorization boundary of the information system are not duplicated
    in other information system inventories. A successful control response
    will describe the process used to ensure that assets are not included
    in multiple system inventories.
  rules: []
  description: |-
    The organization verifies that all components within the authorization boundary of the information system are not duplicated in other information system inventories.

    Supplemental Guidance:  This control enhancement addresses the potential problem of duplicate accounting of information system components in large or complex interconnected systems.
  title: >-
    CM-8(5) - INFORMATION SYSTEM COMPONENT INVENTORY | NO DUPLICATE ACCOUNTING OF
    COMPONENTS
  levels:
  - high
  - moderate
- id: CM-9
  status: pending
  notes: |-
    Section a: The customer will be responsible for developing, documenting, and
    implementing a configuration management plan that addresses roles,
    responsibilities, and configuration management processes and procedures.
    A successful control response will describe how the configuration
    management plan deals with roles, responsibilities, and processes
    and procedures.
    Section b: The customer will be responsible for developing, documenting, and
    implementing a configuration management plan that establishes a
    process for identifying configuration items throughout the
    system development life cycle and for managing the configuration of
    configuration items. A successful control response will describe how
    the configuration management plan establishes a system to track and
    manage changes to the system.
    Section c: The customer will be responsible for developing, documenting, and
    implementing a configuration management plan that defines the
    configuration items for the information system and places them
    under configuration management. A successful control response will
    describe how the configuration management plan defines configuration
    items, and the process used to manage them.
    Section d: The customer will be responsible for developing, documenting, and
    implementing a configuration management plan that protects the
    configuration management plan from unauthorized disclosure. A
    successful control response will describe how the configuration
    management plan is protected from disclosure, such as where it is
    stored, and controls in place to prevent unauthorized access.
  rules: []
  description: |-
    The organization develops, documents, and implements a configuration management plan for the information system that:
     a. Addresses roles, responsibilities, and configuration management processes and procedures;
     b. Establishes a process for identifying configuration items throughout the system development life cycle and for managing the configuration of the configuration items;
     c. Defines the configuration items for the information system and places the configuration items under configuration management; and
     d. Protects the configuration management plan from unauthorized disclosure and modification.

    Supplemental Guidance:  Configuration management plans satisfy the requirements in configuration management policies while being tailored to individual information systems. Such plans define detailed processes and procedures for how configuration management is used to support system development life cycle activities at the information system level. Configuration management plans are typically developed during the development/acquisition phase of the system development life cycle. The plans describe how to move changes through change management processes, how to update configuration settings and baselines, how to maintain information system component inventories, how to control development, test, and operational environments, and how to develop, release, and update key documents. Organizations can employ templates to help ensure consistent and timely development and implementation of configuration management plans. Such templates can represent a master configuration management plan for the organization at large with subsets of the plan implemented on a system by system basis. Configuration management approval processes include designation of key management stakeholders responsible for reviewing and approving proposed changes to information systems, and personnel that conduct security impact analyses prior to the implementation of changes to the systems. Configuration items are the information system items (hardware, software, firmware, and documentation) to be configuration-managed. As information 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. Related controls: CM-2, CM-3, CM-4, CM-5, CM-8, SA-10.

    References: NIST Special Publication 800-128.
  title: >-
    CM-9 - CONFIGURATION MANAGEMENT PLAN
  levels:
  - high
  - moderate
- id: CM-10
  status: pending
  notes: |-
    Section a: The customer will be responsible for using software and associated
    documentation in accordance with contract agreements and copyright laws.
    A successful control response will include a description or reference
    to the customers acceptable use policy.
    Section b: The customer will be responsible for tracking the use of software and
    associated documentation protected by quantity licenses to control
    copying and distribution. A successful control response will include
    a description of how these licenses are tracked and protected.
    Section c: The customer will be responsible for control and documentation of 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. A successful control
    response will include any controls and documentation for peer-to-peer
    technology allowed within the system. An example of this could include
    acceptable use policies in place.
  rules: []
  description: |-
    The organization:
    a. Uses software and associated documentation in accordance with contract agreements and copyright laws;
    b. Tracks the use of software and associated documentation protected by quantity licenses to control copying and distribution; and
    c. Controls and documents 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.

    Supplemental Guidance:  Software license tracking can be accomplished by manual methods (e.g., simple spreadsheets) or automated methods (e.g., specialized tracking applications) depending on organizational needs. Related controls: AC-17, CM-8, SC-7.

    References:  None.
  title: >-
    CM-10 - SOFTWARE USAGE RESTRICTIONS
  levels:
  - high
  - moderate
  - low
- id: CM-10(1)
  status: pending
  notes: |-
    The organization will be responsible for establishing any restrictions on
    the use of open source software. A successful control response will
    describe any restrictions that the organization has in place.
  rules: []
  description: |-
    The organization establishes the following restrictions on the use of open source software: [Assignment: organization-defined restrictions].

    Supplemental Guidance:  Open source software refers to software that is available in source code form. Certain software rights normally reserved for copyright holders are routinely provided under software license agreements that permit individuals to study, change, and improve the software. From a security perspective, the major advantage of open source software is that it provides organizations with the ability to examine the source code. However, there are also various licensing issues associated with open source software including, for example, the constraints on derivative use of such software.
  title: >-
    CM-10(1) - SOFTWARE USAGE RESTRICTIONS | OPEN SOURCE SOFTWARE
  levels:
  - high
  - moderate
- id: CM-11
  status: pending
  notes: |-
    Section a: The customer will be responsible for establishing policies governing
    the installation of software by users. A successful control response
    will describe policies in place that define the restrictions in place
    for installation of software by users.
  rules: []
  description: "The organization:\n a. Establishes [Assignment: organization-defined\
    \ policies] governing the installation of software by users;\n b. Enforces software\
    \ installation policies through [Assignment: organization-defined methods]; and\n\
    \ c. Monitors policy compliance at [Assignment: organization-defined frequency].\n\
    \nSupplemental Guidance:  If provided the necessary privileges, users have the\
    \ ability to install software in organizational information systems. To maintain\
    \ control over the types of software installed, organizations identify permitted\
    \ and prohibited actions regarding software installation. Permitted software installations\
    \ may include, for example, updates and security patches to existing software\
    \ and downloading applications from organization-approved \u201Capp stores.\u201D\
    \ Prohibited software installations may include, for example, software with unknown\
    \ or suspect pedigrees or software that organizations consider potentially malicious.\
    \ The policies organizations select governing user-installed software may be organization-developed\
    \ or provided by some external entity. Policy enforcement methods include procedural\
    \ methods (e.g., periodic examination of user accounts), automated methods (e.g.,\
    \ configuration settings implemented on organizational information systems), or\
    \ both. Related controls: AC-3, CM-2, CM-3, CM-5, CM-6, CM-7, PL-4.\n\nReferences:\
    \ None.\n\nCM-11 (c) [Continuously (via CM-7 (5))]"
  title: >-
    CM-11 - USER-INSTALLED SOFTWARE
  levels:
  - high
  - moderate
  - low
- id: CP-1
  status: pending
  notes: |-
    Section a: The organization will be responsible for developing, documenting, and
    disseminating Contingency Planning policy and procedures. A
    successful control response will need to address the content of the
    policy (which must include purpose, scope, roles, responsibilities,
    management commitment, coordination, and compliance) and procedures
    (which must facilitate the implementation of the policies and
    associated controls).
    Section b: The organization will be responsible for reviewing and updating the
    Contingency Planning policy every  years, and procedures annually.
    A successful response will need to address the review and update
    process, including the role(s) responsible for initiating the review
    process, updating the policy and procedures, and providing approval
    of the updates.
  rules: []
  description: |-
    The organization:
     a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:
       1. A contingency planning policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and
       2. Procedures to facilitate the implementation of the contingency planning policy and associated contingency planning controls; and
     b. Reviews and updates the current:
       1. Contingency planning policy [Assignment: organization-defined frequency]; and
       2. Contingency planning procedures [Assignment: organization-defined frequency].

    Supplemental Guidance: This control addresses the establishment of policy and procedures for the effective implementation of selected security controls and control enhancements in the CP family. Policy and procedures reflect applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance. Security program policies and procedures at the organization level may make the need for system-specific policies and procedures unnecessary. The policy can be included as part of the general information security policy for organizations or conversely, can be represented by multiple policies reflecting the complex nature of certain organizations. The procedures can be established for the security program in general and for particular information systems, if needed. The organizational risk management strategy is a key factor in establishing policy and procedures. Related control: PM-9.

    Control Enhancements:  None.

    References:  Federal Continuity Directive 1; NIST Special Publications 800-12, 800-34, 800-100.

    CP-1 (b) (1) [at least annually]
    CP-1 (b) (2) [at least annually or whenever a significant change occurs]
  title: >-
    CP-1 - CONTINGENCY PLANNING POLICY AND

    PROCEDURES
  levels:
  - high
  - moderate
  - low
- id: CP-2
  status: pending
  notes: |-
    Section a: The customer will be responsible for developing a contingency plan
    meeting the specified requirements. A successful control response will
    need to address the maintenance, recovery, and resumption of customer
    applications, as well as any reliance on infrastructure functionality
    to perform these tasks, as outlined in policy guidance from CP-1.
    Section b: The customer will be responsible for distributing the contingency plan
    to key contingency personnel. A successful control response will need
    to address identification of key personnel (by name, title, or role)
    and the means by which the customer ensures that all key personnel
    receive the contingency plan.
    Section c: The customer will be responsible for coordinating contingency planning
    activities with incident handling activities. A successful control
    response will need to address the division of responsibilities between
    contingency personnel and incident response personnel, as well as the
    means by which contingency planning activities are activated in the
    event of a security incident.
    Section d: The customer will be responsible for reviewing the contingency plan
    at the required frequency. A successful control response will need to
    outline how reviews are initiated, performed, and signed off on.
    Section e: The customer will be responsible for updating the contingency plan to
    address relevant changes as well as any problems found in the
    contingency plan. A successful control response will need to discuss
    how updates are proposed, implemented, and approved.
    Section f: The customer will be responsible for communicating changes to the
    contingency plan to key contingency personnel. A successful control
    response will need to address the means by which the
    customer ensures that all key personnel receive the updated
    contingency plan.
    Section g: The customer will be responsible for protecting the contingency plan
    from unauthorized disclosure or modification. A successful control
    response will need to address policy, procedural, and technical
    safeguards that are in place to protect the contingency plan.
  rules: []
  description: |-
    The organization:
     a. Develops a contingency plan for the information system that:
       1. Identifies essential missions and business functions and associated contingency requirements;
       2. Provides recovery objectives, restoration priorities, and metrics;
       3. Addresses contingency roles, responsibilities, assigned individuals with contact information;
       4. Addresses maintaining essential missions and business functions despite an information system disruption, compromise, or failure;
       5. Addresses eventual, full information system restoration without deterioration of the security safeguards originally planned and implemented; and
       6. Is reviewed and approved by [Assignment: organization-defined personnel or roles];
     b. Distributes copies of the contingency plan to [Assignment: organization-defined key contingency personnel (identified by name and/or by role) and organizational elements];
     c. Coordinates contingency planning activities with incident handling activities;
     d. Reviews the contingency plan for the information system [Assignment: organization-defined frequency];
     e. Updates the contingency plan to address changes to the organization, information system, or environment of operation and problems encountered during contingency plan implementation, execution, or testing;
     f. Communicates contingency plan changes to [Assignment: organization-defined key contingency personnel (identified by name and/or by role) and organizational elements]; and
     g. Protects the contingency plan from unauthorized disclosure and modification.

    Supplemental Guidance:  Contingency planning for information systems is part of an overall organizational program for achieving continuity of operations for mission/business functions. Contingency planning addresses both information system restoration and implementation of alternative mission/business processes when systems are compromised. The effectiveness of contingency planning is maximized by considering such planning throughout the phases of the system development life cycle. Performing contingency planning on hardware, software, and firmware development can be an effective means of achieving information system resiliency. Contingency plans reflect the degree of restoration required for organizational information systems since not all systems may need to fully recover to achieve the level of continuity of operations desired. Information system recovery objectives reflect applicable laws, Executive Orders, directives, policies, standards, regulations, and guidelines. In addition to information system availability, contingency plans also address other security-related events resulting in a reduction in mission and/or business effectiveness, such as malicious attacks compromising the confidentiality or integrity of information systems. Actions addressed in contingency plans include, for example, orderly/graceful degradation, information system shutdown, fallback to a manual mode, alternate information flows, and operating in modes reserved for when systems are under attack. By closely coordinating contingency planning with incident handling activities, organizations can ensure that the necessary contingency planning activities are in place and activated in the event of a security incident. Related controls: AC-14, CP-6, CP-7, CP-8, CP-9, CP-10, IR-4, IR-8, MP-2, MP-4, MP-5, PM-8, PM-11.

    References: Federal Continuity Directive 1; NIST Special Publication 800-34.

    CP-2 (d) [at least annually]
    CP-2 Requirement: For JAB authorizations the contingency lists include designated FedRAMP personnel.
  title: >-
    CP-2 - CONTINGENCY PLAN
  levels:
  - high
  - moderate
  - low
- id: CP-2(1)
  status: pending
  notes: |-
    The customer will be responsible for coordinating development of the
    contingency plan with related plans (such as business continuity plans,
    disaster recovery plans, etc.). A successful control response will need
    to address the coordination of initial development, as well as how
    updates to the contingency plan affect related plans and vice versa.
  rules: []
  description: |-
    The organization coordinates contingency plan development with organizational elements responsible for related plans.

    Supplemental Guidance:  Plans related to contingency plans for organizational information systems include, for example, Business Continuity Plans, Disaster Recovery Plans, Continuity of Operations Plans, Crisis Communications Plans, Critical Infrastructure Plans, Cyber Incident Response Plans, Insider Threat Implementation Plan, and Occupant Emergency Plans.
  title: >-
    CP-2(1) - CONTINGENCY PLAN | COORDINATE WITH RELATED PLANS
  levels:
  - high
  - moderate
- id: CP-2(2)
  status: pending
  notes: |-
    The customer will be responsible for reserving capacity for processing
    in an alternative region. A successful control response will need to
    note that capacity for necessary processing has been reserved in an
    alternate region.
  rules: []
  description: |-
    The organization conducts capacity planning so that necessary capacity for information processing, telecommunications, and environmental support exists during contingency operations.

    Supplemental Guidance:  Capacity planning is needed because different types of threats (e.g., natural disasters, targeted cyber attacks) can result in a reduction of the available processing, telecommunications, and support services originally intended to support the organizational missions/business functions. Organizations may need to anticipate degraded operations during contingency operations and factor such degradation into capacity planning.
  title: >-
    CP-2(2) - CONTINGENCY PLAN | CAPACITY PLANNING
  levels:
  - high
  - moderate
- id: CP-2(3)
  status: pending
  notes: |-
    This control is often inherited through your platform provider,
    e.g. Microsoft Azure implements this control on behalf of both PaaS
    and IaaS customers. A successful control response will indicate if this
    control is inherited through your platform provider, and if not,
    details how mission functions will be resumed.
  rules: []
  description: |-
    The organization plans for the resumption of essential missions and business functions within
    [Assignment: organization-defined time period] of contingency plan activation.

    Supplemental Guidance:  Organizations may choose to carry out the contingency planning activities in this control enhancement as part of organizational business continuity planning including, for example, as part of business impact analyses. The time period for resumption of essential missions/business functions may be dependent on the severity/extent of disruptions
    to the information system and its supporting infrastructure. Related control: PE-12.
  title: >-
    CP-2(3) - CONTINGENCY PLAN | RESUME ESSENTIAL MISSIONS / BUSINESS FUNCTIONS
  levels:
  - high
  - moderate
- id: CP-2(8)
  status: pending
  notes: |-
    The customer will be responsible for identifying critical
    functionality for which processing capacity must be reserved in an
    alternate region. A successful control response will need to discuss
    the process by wich this determination is made. Once processing
    capacity is reserved in an alternate region for this critical
    functionality, the remainder of the control may be inherited
    from your infrastruture provider.
  rules: []
  description: |-
    The organization identifies critical information system assets supporting essential missions and business functions.

    Supplemental Guidance:  Organizations may choose to carry out the contingency planning activities in this control enhancement as part of organizational business continuity planning including, for example, as part of business impact analyses. Organizations identify critical information system assets so that additional safeguards and countermeasures can be employed (above and beyond those safeguards and countermeasures routinely implemented) to help ensure that organizational missions/business functions can continue to be conducted during contingency operations. In addition, the identification of critical information assets facilitates the prioritization of organizational resources. Critical information system assets include technical and operational aspects. Technical aspects include, for example, information technology services, information system components, information technology products, and mechanisms. Operational aspects include, for example, procedures (manually executed operations) and personnel (individuals operating technical safeguards and/or executing manual procedures). Organizational program protection plans can provide assistance in identifying critical assets. Related controls: SA-14, SA-15.
  title: >-
    CP-2(8) - CONTINGENCY PLAN | IDENTIFY CRITICAL ASSETS
  levels:
  - high
  - moderate
- id: CP-3
  status: pending
  notes: |-
    The customer will be responsible for initial and refresher training
    related to contingency plan activities at the required intervals. A
    successful control response will need to outline the scope and contents
    of the training, the audience for the training, and the means by which
    training attendance is tracked and enforced.
  rules: []
  description: "The organization provides contingency training to information system\
    \ users consistent with assigned roles and responsibilities:\n a. Within [Assignment:\
    \ organization-defined time period] of assuming a contingency role or responsibility;\n\
    \ b. When required by information system changes; and\n c. [Assignment: organization-defined\
    \ frequency] thereafter.\n\nSupplemental Guidance:  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, regular users may only need to know\nwhen and\
    \ where to report for duty during contingency operations and if normal duties\
    \ are affected; system administrators may require additional training on how to\
    \ set up information systems at alternate processing and storage sites; and managers/senior\
    \ leaders 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\ncontingency-related\
    \ activities. Training for contingency roles/responsibilities reflects the specific\
    \ continuity requirements in the contingency plan. Related controls: AT-2, AT-3,\
    \ CP-2, IR-2. \n\nReferences: Federal Continuity Directive 1; NIST Special Publications\
    \ 800-16, 800-50.\n\nCP-3 (a) [ten (10) days]\nCP-3 (c) [at least annually]"
  title: >-
    CP-3 - CONTINGENCY TRAINING
  levels:
  - high
  - moderate
  - low
- id: CP-4
  status: pending
  notes: |-
    Section a: The customer will be responsible for testing of contingency plans
    related to the customer application at the required frequency. A
    successful control response will need to address the scenarios and
    exercises chosen for the test.
    Section b: The customer will be responsible for reviewing the results of
    contingency plan testing. A successful control response will need to
    discuss the roles or personnel responsible for review, as well as the
    format and content of reporting on the results.
    Section c: The customer will be responsible for initiating corrective action as
    a result of contingency plan testing. A successful control response will
    need to address the types of corrective actions taken and timeframes
    for those actions.
  rules: []
  description: "The organization:\n a. Tests the contingency plan for the information\
    \ system [Assignment: organization-defined frequency] using [Assignment: organization-defined\
    \ tests] to determine the effectiveness of the plan and the organizational readiness\
    \ to execute the plan;\n b. Reviews the contingency plan test results; and\n c.\
    \ Initiates corrective actions, if needed.\n\nSupplemental Guidance:  Methods\
    \ for testing contingency plans to determine the effectiveness of the plans and\
    \ to identify potential weaknesses in the plans include, for example, walk-through\
    \ and tabletop exercises, checklists, simulations (parallel, full interrupt),\
    \ and comprehensive exercises. Organizations conduct testing based on the continuity\
    \ requirements in contingency plans and include a determination of the effects\
    \ on organizational operations, assets, and individuals arising due to contingency\
    \ operations. Organizations have flexibility and discretion in the breadth, depth,\
    \ and timelines of corrective actions. Related controls: CP-2, CP-3, IR-3.\n\n\
    References: Federal Continuity Directive 1; FIPS Publication 199; NIST Special\
    \ Publications 800-34, 800-84.\n\nCP-4 (a)-1 [at least annually] \nCP-4 (a)-2\
    \ [functional exercises]\nCP-4 (a) Requirement: The service provider develops\
    \ test plans in accordance with NIST Special Publication 800-34 (as amended);\
    \ plans are approved by the JAB/AO prior to initiating testing."
  title: >-
    CP-4 - CONTINGENCY PLAN TESTING
  levels:
  - high
  - moderate
  - low
- id: CP-4(1)
  status: pending
  notes: |-
    The customer will be responsible for coordinating testing of the
    contingency plan with related plans (such as business continuity plans,
    disaster recovery plans, etc.). A successful control response will need
    to address ensuring that any test results relevant to related plans are
    communicated so that corrective actions may be taken as needed.
  rules: []
  description: |-
    The organization coordinates contingency plan testing with organizational elements responsible for related plans.

    Supplemental Guidance:  Plans related to contingency plans for organizational information systems include, for example, Business Continuity Plans, Disaster Recovery Plans, Continuity of Operations Plans, Crisis Communications Plans, Critical Infrastructure Plans, Cyber Incident Response Plans, and Occupant Emergency Plans. This control enhancement does not require organizations to create organizational elements to handle related plans or to align such elements with specific plans. It does require, however, that if such organizational elements are responsible for related plans, organizations should coordinate with those elements. Related controls: IR-8, PM-8.
  title: >-
    CP-4(1) - CONTINGENCY PLAN TESTING | COORDINATE WITH RELATED PLANS
  levels:
  - high
  - moderate
- id: CP-6
  status: pending
  notes: |-
    Section a: The customer will be responsible for enabling geo-replicated within
    the information system which will allow restoration from backups.
    Section b: The customer will be responsible to ensure alternate storage sites
    provide information security safeguards equivalent to the primary
    site.
  rules: []
  description: |-
    The organization:
     a. Establishes an alternate storage site including necessary agreements to permit the storage and retrieval of information system backup information; and
     b. Ensures that the alternate storage site provides information security safeguards equivalent to that of the primary site.

    Supplemental Guidance:  Alternate storage sites are sites that are geographically distinct from primary storage sites. An alternate storage site maintains duplicate copies of information and data in the event that the primary storage site is not available. Items covered by alternate storage site agreements include, for example, environmental conditions at alternate sites, access rules, physical and environmental protection requirements, and coordination of delivery/retrieval of backup
    media. Alternate storage sites reflect the requirements in contingency plans so that organizations can maintain essential missions/business functions despite disruption, compromise, or failure in organizational information systems. Related controls: CP-2, CP-7, CP-9, CP-10, MP-4.

    References: NIST Special Publication 800-34.
  title: >-
    CP-6 - ALTERNATE STORAGE SITE
  levels:
  - high
  - moderate
- id: CP-6(1)
  status: pending
  notes: |-
    The customer will be responsible for identifying an alternative
    storage site that is separated from the primary storage site to reduce
    susceptibility to the same threats.
  rules: []
  description: |-
    The organization identifies an alternate storage site that is separated from the primary storage site to reduce susceptibility to the same threats.

    Supplemental Guidance:  Threats that affect alternate storage sites are typically defined in organizational assessments of risk and include, for example, natural disasters, structural failures, hostile cyber attacks, and errors of omission/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 one particular type of threat (i.e., hostile cyber attack), the degree of separation between sites is less relevant. Related control: RA-3.
  title: >-
    CP-6(1) - ALTERNATE STORAGE SITE | SEPARATION FROM PRIMARY SITE
  levels:
  - high
  - moderate
- id: CP-6(3)
  status: pending
  notes: |-
    The customer will be responsible for identifying potential
    accessibility problems to the alternate storage site in the event of
    an area-wide disruption or disaster and outlines explicit
    mitigation actions. This control is often inherited from IaaS and PaaS
    providers.
  rules: []
  description: |-
    The organization identifies potential accessibility problems to the alternate storage site in the event of an area-wide disruption or disaster and outlines explicit mitigation actions.

    Supplemental Guidance:  Area-wide disruptions refer to those types of disruptions that are broad in geographic scope (e.g., hurricane, regional power outage) with such determinations made by organizations based on organizational assessments of risk. Explicit mitigation actions include, for example: (i) duplicating backup information at other alternate storage sites if access problems occur at originally designated alternate sites; or (ii) planning for physical access to retrieve backup information if electronic accessibility to the alternate site is disrupted. Related control: RA-3.
  title: >-
    CP-6(3) - ALTERNATE STORAGE SITE | ACCESSIBILITY
  levels:
  - high
  - moderate
- id: CP-7
  status: pending
  notes: |-
    Section a: The customer will be responsible for reserving capacity for processing
    in an alternate region. A successful control response will need to note
    that capacity for necessary processing has been reserved in an alternate
    region, and will then indicate inheritance of capacity planning from
    most IaaS providers.
    Section b: The customer will be responsible for ensuring that equipment and
    supplies required to transfer and resume operations are available
    at the alternate processing site. This control is often inherited
    from organizational processes.
    Section c: The customer will be responsible for ensuring that the alternate
    processing site provides information security safeguards equivalent
    to that of the primary site.
  rules: []
  description: "The organization:\n a. Establishes an alternate processing site including\
    \ necessary agreements to permit the transfer and resumption of [Assignment: organization-defined\
    \ information system operations] for essential missions/business functions within\
    \ [Assignment: organization-defined time period consistent with recovery time\
    \ and recovery point objectives] when the primary processing capabilities are\
    \ unavailable;\n b. Ensures that equipment and supplies required to transfer and\
    \ resume operations are available at the alternate processing site or contracts\
    \ are in place to support delivery to the site within the organization-defined\
    \ time period for transfer/resumption; and \n c. Ensures that the alternate processing\
    \ site provides information security safeguards equivalent to that of the primary\
    \ site.\n\nSupplemental Guidance:  Alternate processing sites are sites that are\
    \ geographically distinct from primary processing sites. An alternate processing\
    \ site provides processing capability in the event that the primary processing\
    \ site is not available. Items covered by alternate processing site agreements\
    \ include, for example, environmental conditions at alternate sites, access rules,\
    \ physical and environmental protection requirements, and coordination for the\
    \ transfer/assignment of personnel. Requirements are specifically allocated to\
    \ alternate processing sites that reflect the requirements in contingency plans\
    \ to maintain essential missions/business functions despite disruption, compromise,\
    \ or failure in organizational information systems. Related controls: CP-2, CP-6,\
    \ CP-8, CP-9, CP-10, MA-6.\n\nReferences: NIST Special Publication 800-34.\n\n\
    CP-7 (a) Requirement: The service provider defines a time period consistent with\
    \ the recovery time objectives and business impact analysis."
  title: >-
    CP-7 - ALTERNATE PROCESSING SITE
  levels:
  - high
  - moderate
- id: CP-7(1)
  status: pending
  notes: |-
    The customer is responsible for identifying an alternate processing
    site that is separated from the primary processing site to reduce
    susceptibility to the same threats. Per FedRAMP guidance, the service
    provider may determine what is considered a sufficient degree of
    separation between the primary and alternate processing sites, based
    on the types of threats that are of concern. This control is often
    inherited from organizational processes.
  rules: []
  description: |-
    The organization identifies an alternate processing site that is separated from the primary processing site to reduce susceptibility to the same threats.

    Supplemental Guidance:  Threats that affect alternate processing sites are typically defined in organizational assessments of risk and include, for example, natural disasters, structural failures, hostile cyber attacks, and errors of omission/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 one particular type of threat (i.e., hostile cyber attack), the degree of separation between sites is less relevant. Related control: RA-3.

    CP-7 (1) Guidance: The service provider may determine what is considered a sufficient degree of separation between the primary and alternate processing sites, based on the types of threats that are of concern. For one particular type of threat (i.e., hostile cyber attack), the degree of separation between sites will be less relevant.
  title: >-
    CP-7(1) - ALTERNATE PROCESSING SITE | SEPARATION FROM PRIMARY SITE
  levels:
  - high
  - moderate
- id: CP-7(2)
  status: pending
  notes: |-
    The customer will be responsible for identifying potential
    accessibility problems to the alternate processing site in the event of
    an area-wide disruption or disaster and outlines explicit mitigation
    actions. This control is often inherited from organizational
    processes.
  rules: []
  description: |-
    The organization identifies potential accessibility problems to the alternate processing site in the event of an area-wide disruption or disaster and outlines explicit mitigation actions.

    Supplemental Guidance:  Area-wide disruptions refer to those types of disruptions that are broad in geographic scope (e.g., hurricane, regional power outage) with such determinations made by organizations based on organizational assessments of risk. Related control: RA-3.
  title: >-
    CP-7(2) - ALTERNATE PROCESSING SITE | ACCESSIBILITY
  levels:
  - high
  - moderate
- id: CP-7(3)
  status: pending
  notes: |-
    The customer will be responsible for developing alternate processing
    site agreements that contain priority-of-service provisions in
    accordance with organizational availability requirements. This control
    is often inherited from organizational, IaaS, or PaaS providers.
  rules: []
  description: |-
    The organization develops alternate processing site agreements that contain priority-of-service provisions in accordance with organizational availability requirements (including recovery time objectives).

    Supplemental Guidance:  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 at the alternate processing site.
  title: >-
    CP-7(3) - ALTERNATE PROCESSING SITE | PRIORITY OF SERVICE
  levels:
  - high
  - moderate
- id: CP-8
  status: pending
  notes: |-
    The customer will be responsible for establishing alternate
    telecommunication services including necessary agreements to permit
    the resumption of operations. The customer must define a time period
    to resume business operations that is consistent with the business
    impact analysis. This control is often inherited from organizational,
    IaaS, or PaaS providers.
  rules: []
  description: |-
    The organization establishes alternate telecommunications services including necessary agreements to permit the resumption of [Assignment: organization-defined information system operations] for essential missions and business functions within [Assignment: organization- defined time period] when the primary telecommunications capabilities are unavailable at either the primary or alternate processing or storage sites.

    Supplemental Guidance:  This control applies to telecommunications services (data and voice) for primary and alternate processing and storage sites. Alternate telecommunications services reflect the continuity requirements in contingency plans to maintain essential missions/business functions despite the loss of primary telecommunications services. Organizations may specify different time periods for primary/alternate sites. Alternate telecommunications services include, for example, additional organizational or commercial ground-based circuits/lines or satellites in lieu of ground- based communications. Organizations consider factors such as availability, quality of service, and access when entering into alternate telecommunications agreements. Related controls: CP-2, CP-6, CP-7.

    References: NIST Special Publication 800-34; National Communications Systems Directive 3-10; Web: http://www.dhs.gov/telecommunications-service-priority-tsp.

    CP-8 Requirement: The service provider defines a time period consistent with the recovery time objectives and business impact analysis.
  title: >-
    CP-8 - TELECOMMUNICATIONS SERVICES
  levels:
  - high
  - moderate
- id: CP-8(1)
  status: pending
  notes: |-
    Section a: The custimer will be responsible for developing primary and
    alternate telecommunication service agreements that contain
    priority-of-service provisions in accordance with organiational
    availability requirements (including recovery time objectives). This
    control is often inherited from IaaS and PaaS providers.
    Section b: The customer will be responsible to request telecommunications
    service priority for all telecommunications services used for national
    security emergency preparedness in the event that the primary and/or
    alternate telecommunications services are provided by a common carrier.
    This control is often inherited from IaaS and PaaS providers.
  rules: []
  description: |-
    The organization:
     (a)   Develops primary and alternate telecommunications service agreements that contain priority- of-service provisions in accordance with organizational availability requirements (including recovery time objectives); and
     (b)   Requests Telecommunications Service Priority for all telecommunications services used for national security emergency preparedness in the event that the primary and/or alternate telecommunications services are provided by a common carrier.

    Supplemental Guidance:  Organizations consider the potential mission/business impact in situations where telecommunications service providers are servicing other organizations with similar priority-of-service provisions.
  title: >-
    CP-8(1) - TELECOMMUNICATIONS SERVICES | PRIORITY OF SERVICE PROVISIONS
  levels:
  - high
  - moderate
- id: CP-8(2)
  status: pending
  notes: |-
    The customer will be responsible for obtaining alernate
    telecommunications services to reduce the likelihood of sharing a
    single point of failure with primary telecommunications services. This
    control is often inherited from IaaS and PaaS providers.
  rules: []
  description: |-
    The organization obtains alternate telecommunications services to reduce the likelihood of sharing a single point of failure with primary telecommunications services.
  title: >-
    CP-8(2) - TELECOMMUNICATIONS SERVICES | SINGLE POINTS OF FAILURE
  levels:
  - high
  - moderate
- id: CP-10
  status: pending
  notes: |-
    The customer will be responsible for providing recovery and
    reconstitution of the information system to a known state after a
    disruption, compromise, or failure.
  rules: []
  description: |-
    The organization provides for the recovery and reconstitution of the information system to a known state after a disruption, compromise, or failure.

    Supplemental Guidance:  Recovery is executing information system contingency plan activities to restore organizational missions/business functions. Reconstitution takes place following recovery and includes activities for returning organizational information systems to fully operational states. Recovery and reconstitution operations reflect mission and business priorities, recovery point/time and reconstitution objectives, and established organizational metrics consistent with contingency plan requirements. Reconstitution includes the deactivation of any interim information system capabilities that may have been needed during recovery operations. Reconstitution also includes assessments of fully restored information system capabilities, reestablishment of continuous monitoring activities, potential information system reauthorizations, and activities to prepare the systems against future disruptions, compromises, or failures. Recovery/reconstitution capabilities employed by organizations can include both automated mechanisms and manual procedures. Related controls: CA-2, CA-6, CA-7, CP-2, CP-6, CP-7, CP-9, SC-24.

    References: Federal Continuity Directive 1; NIST Special Publication 800-34.
  title: >-
    CP-10 - INFORMATION SYSTEM RECOVERY AND

    RECONSTITUTION
  levels:
  - high
  - moderate
  - low
- id: IA-1
  status: pending
  notes: |-
    Section a: The organization will be responsible for developing, documenting, and
    disseminating Identification and Authentication policy and procedures.
    A successful control response will need to address the content of the
    policy (which must include purpose, scope, roles, responsibilities,
    management commitment, coordination, and compliance) and procedures
    (which must facilitate the implementation of the policies and
    associated controls).
    Section b: The organization will be responsible for reviewing and updating the
    Identification and Authentication policy every 3 years, and procedures
    annually. A successful control response will need to address the
    review and update process, including the role(s) responsible for
    initiating the review process, updating the policy and procedures,
    and providing approval of the updates.
  rules: []
  description: "The organization:\n a. Develops, documents, and disseminates to [Assignment:\
    \ organization-defined personnel or roles]:\n   1. An identification and authentication\
    \ policy that addresses purpose, scope, roles, responsibilities, management commitment,\
    \ coordination among organizational entities, and compliance; and\n   2. Procedures\
    \ to facilitate the implementation of the identification and authentication policy\
    \ and associated identification and authentication controls; and\n b. Reviews\
    \ and updates the current:\n   1. Identification and authentication policy [Assignment:\
    \ organization-defined frequency]; and\n   2. Identification and authentication\
    \ procedures [Assignment: organization-defined frequency].\n\nSupplemental Guidance:\
    \  This control addresses the establishment of policy and procedures for the effective\
    \ implementation of selected security controls and control enhancements in the\
    \ IA family. Policy and procedures reflect applicable federal laws, Executive\
    \ Orders, directives, regulations, policies, standards, and guidance. Security\
    \ program policies and procedures at the organization level may make the need\
    \ for system-specific policies and procedures unnecessary. The policy can be included\
    \ as part of the general information security policy for organizations or conversely,\
    \ can be represented by multiple policies reflecting the complex nature of certain\
    \ organizations. The procedures can be established for the security program in\
    \ general and for particular information systems, if needed. The organizational\
    \ risk management strategy is a key factor in establishing policy and procedures.\
    \ Related control: PM-9.\n\nControl Enhancements:  None.\n\nReferences:  FIPS\
    \ Publication 201; NIST Special Publications 800-12, 800-63, 800-73, 800-76, 800-78,\
    \ 800-100.\n\nIA-1 (b) (1) [at least annually] \nIA-1 (b) (2) [at least annually\
    \ or whenever a significant change occurs]"
  title: >-
    IA-1 - IDENTIFICATION AND AUTHENTICATION POLICY AND

    PROCEDURES
  levels:
  - high
  - moderate
  - low
- id: IR-2
  status: pending
  notes: |-
    Section a: The customer will be responsible for initial training related to
    contingency plan activities. This training will need to include
    consideration for all aspects of incident response that are the
    responsibility of the customer. A successful control response will need
    to outline the scope and contents of the training, the audience for the
    training, and the means by which training attendance is tracked and
    enforced.
    Section b: The customer will be responsible for providing retraining related to
    contingency plan activities as required by information system changes. A
    successful control response will need to address identification of
    changes that require retraining as well as notification to relevant
    parties that retraining is required and tracking/enforcement of that
    attendance.
    Section c: The customer will be responsible for refresher training related to
    contingency plan activities at the required frequency. A successful
    control response will need to address the means by which refresher
    training attendance is tracked and enforced.
  rules: []
  description: |-
    The organization provides incident response training to information system users consistent with assigned roles and responsibilities:
     a. Within [Assignment: organization-defined time period] of assuming an incident response role or responsibility;
     b. When required by information system changes; and
     c. [Assignment: organization-defined frequency] thereafter.

    Supplemental Guidance:  Incident response training provided by organizations is linked to the assigned roles and responsibilities of organizational personnel to ensure the appropriate content and level of detail is included in such training. For example, regular users may only need to know who to call or how to recognize an incident on the information system; system administrators may require additional training on how to handle/remediate incidents; and incident responders may receive more specific training on forensics, reporting, system recovery, and restoration. Incident response training includes user training in the identification and reporting of suspicious activities, both from external and internal sources. Related controls: AT-3, CP-3, IR-8.

    References: NIST Special Publications 800-16, 800-50.

    IR-2 (a) [within ten (10) days]
    IR-2 (c) [at least annually]
  title: >-
    IR-2 - INCIDENT RESPONSE TRAINING
  levels:
  - high
  - moderate
  - low
- id: IR-3
  status: pending
  notes: |-
    The customer will be responsible for testing of incident response
    plans at the required frequency. A successful control response will
    need to address the scenarios and exercise chosen for the test, as well
    as the process for documenting and reviewing test results. Test plans
    will need to be approved by the Authorizing Official prior to the test
    commencing.

    NIST Special Publication 800-61, Rev 2, Computer Security Incident
    Handling Guide, provides guidance on the development and testing
    of incident response plans.
  rules: []
  description: |-
    The organization tests the incident response capability for the information system [Assignment: organization-defined frequency] using [Assignment: organization-defined tests] to determine the incident response effectiveness and documents the results.

    Supplemental Guidance:  Organizations test incident response capabilities to determine the overall effectiveness of the capabilities and to identify potential weaknesses or deficiencies. Incident response testing includes, for example, the use of checklists, walk-through or tabletop exercises, simulations (parallel/full interrupt), and comprehensive exercises. Incident response testing can also include a determination of the effects on organizational operations (e.g., reduction in mission capabilities), organizational assets, and individuals due to incident response. Related controls: CP-4, IR-8.

    References:  NIST Special Publications 800-84, 800-115.

    IR-3-1 [at least every six (6) months, including functional at least annually]
    IR-3-2 Requirement: The service provider defines tests and/or exercises in accordance with NIST Special Publication 800-61 (as amended). Functional Testing must occur prior to testing for initial authorization. Annual functional testing may be concurrent with required penetration tests (see CA-8). The service provider provides test plans to the JAB/AO annually. Test plans are approved and accepted by the JAB/AO prior to test commencing.
  title: >-
    IR-3 - INCIDENT RESPONSE TESTING
  levels:
  - high
  - moderate
- id: IR-3(2)
  status: pending
  notes: |-
    The customer will be responsible for coordinating testing of the
    incident response plan with related plans (such as business continuity
    plans, contingency plans, etc.). A successful control response will
    need to address ensuring that any test results relevant to related
    plans are communicated so that corrective actions may be taken as
    needed.
  rules: []
  description: |-
    The organization coordinates incident response testing with organizational elements responsible for related plans.

    Supplemental Guidance:  Organizational plans related to incident response testing include, for example, Business Continuity Plans, Contingency Plans, Disaster Recovery Plans, Continuity of Operations Plans, Crisis Communications Plans, Critical Infrastructure Plans, and
    Occupant Emergency Plans.
  title: >-
    IR-3(2) - INCIDENT RESPONSE TESTING | COORDINATION WITH RELATED PLANS
  levels:
  - high
  - moderate
- id: IR-4
  status: pending
  notes: |-
    Section a: The customer will be responsible for developing incident response
    plans and testing that includes consideration for any controls that are
    the responsibility of the customer relating to shared touch points
    included in the customers authorization boundary and any customer
    applications leveraging the providers infrastructure. Incident handling
    for customer applications is the responsiblity of the customer unless
    an incident is caused by platform providers (e.g. IaaS). A successful
    control response will need to address the required steps in incident
    response (preparation, detection and analysis, containment, eradication,
    and recovery), including identifying roles or individuals responsible
    for each step.
    Section b: The customer will be responsible for incident handling activities
    with contingency plan activities. A successful control response will
    need to address communication and prioritization in the case of
    conflicts (for example, if incident analysis and containment causes
    delays in service restoration).
    Section c: The customer will be responsible for updating incident response plans,
    procedures, training and testing based on lessons learned from incident
    handling activities. A successful control response will need to address
    the personnel or roles responsible for gathering and reviewing lessons
    learned, updating plans, procedures, training, and testing, and
    reviewing and signing off on changes.
  rules: []
  description: "The organization:\na. Implements an incident handling capability for\
    \ security incidents that includes preparation, detection and analysis, containment,\
    \ eradication, and recovery;\nb. Coordinates incident handling activities with\
    \ contingency planning activities; and\nc. Incorporates lessons learned from ongoing\
    \ incident handling activities into incident response procedures, training, and\
    \ testing/exercises, and implements the resulting changes accordingly.\n\nSupplemental\
    \ Guidance:  Organizations recognize that incident response capability is dependent\
    \ on the capabilities of organizational information systems and the mission/business\
    \ processes being supported by those systems. Therefore, organizations consider\
    \ incident response as part of the definition, design, and development of mission/business\
    \ processes and information systems. Incident-related information can be obtained\
    \ from a variety of sources including, for example, audit monitoring, network\
    \ monitoring, physical access monitoring, user/administrator reports, and reported\
    \ supply chain events. Effective incident handling capability includes coordination\
    \ among many organizational entities including, for example, mission/business\
    \ owners, information system owners, authorizing officials, human resources offices,\
    \ physical and personnel security offices, legal departments, operations personnel,\
    \ procurement offices, and the risk executive (function). Related controls: AU-6,\
    \ CM-6, CP-2, CP-4, IR-2, IR-3, IR-8, PE-6, SC-5, SC-7, SI-3, SI-4, SI-7.\n\n\
    References: Executive Order 13587; NIST Special Publication 800-61.\n\n \nIR-4\
    \ Requirement: The service provider ensures that individuals conducting incident\
    \ handling meet personnel security requirements commensurate with the criticality/sensitivity\
    \ of the information being processed, stored, and transmitted by the information\
    \ system."
  title: >-
    IR-4 - INCIDENT HANDLING
  levels:
  - high
  - moderate
  - low
- id: IR-4(1)
  status: pending
  notes: |-
    The customer will be responsible for using automated mechanisms
    (such as ticketing systems and incident tracking/reporting systems) in
    support of customer incident handling activities. A successful control
    response will need to address the automated systems involved and their
    place within the overall incident handling process.
  rules: []
  description: |-
    The organization employs automated mechanisms to support the incident handling process.

    Supplemental Guidance:  Automated mechanisms supporting incident handling processes include, for example, online incident management systems.
  title: >-
    IR-4(1) - INCIDENT HANDLING | AUTOMATED INCIDENT HANDLING PROCESSES
  levels:
  - high
  - moderate
- id: IR-5
  status: pending
  notes: |-
    The customer will be responisble for tracking and documenting
    information system security incidents. A successful control response
    will need to address the tools and processes used for documentation,
    and relate these tools and processes to the automated mechanisms
    used in IR-4(1).
  rules: []
  description: |-
    The organization tracks and documents information system security incidents.

    Supplemental Guidance:  Documenting information system security incidents includes, for example, maintaining records about each incident, the status of the incident, and other pertinent information necessary for forensics, evaluating incident details, trends, and handling. Incident information can be obtained from  a variety of sources including, for example, incident reports, incident response teams, audit monitoring, network monitoring, physical access monitoring, and user/administrator reports. Related controls: AU-6, IR-8, PE-6, SC-5, SC-7, SI-3, SI-4, SI-7.

    References: NIST Special Publication 800-61.
  title: >-
    IR-5 - INCIDENT MONITORING
  levels:
  - high
  - moderate
  - low
- id: IR-6
  status: pending
  notes: |-
    Section a: The customer will be responsible for requiring personnel to report
    suspected security incidents within the required timeframes. A
    successful control response will need to address examples of events that
    personnel should report, as well as tools, mechanisms, and processes
    used for reporting.
    Section b: The customer will be responsible for reporting security incident
    information according to the FedRAMP Incident Communications Procedure.
    In cases where customer security incidents may affect the security
    status of Microsoft Azure as a whole, the customer will be responsible
    for notifying Microsoft Azure as well. A successful control response
    will need to address the individuals or roles responsible for such
    notifications.
  rules: []
  description: |-
    The organization:
     a. Requires personnel to report suspected security incidents to the organizational incident response capability within [Assignment: organization-defined time period]; and
     b. Reports security incident information to [Assignment: organization-defined authorities].

    Supplemental Guidance:  The intent of this control is to address both specific incident reporting requirements within an organization and the formal incident reporting requirements for federal agencies and their subordinate organizations. Suspected security incidents include, for example, the receipt of suspicious email communications that can potentially contain malicious code. The types of security incidents reported, the content and timeliness of the reports, and the designated reporting authorities reflect applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance. Current federal policy requires that all federal agencies (unless specifically exempted from such requirements) report security incidents to the United States Computer Emergency Readiness Team (US-CERT) within specified time frames designated in the US-CERT Concept of Operations for Federal Cyber Security Incident Handling. Related controls: IR-4, IR-5, IR-8.

    References: NIST Special Publication 800-61; Web: http://www.us-cert.gov.

    IR-6 (a) [US-CERT incident reporting timelines as specified in NIST Special Publication 800-61 (as amended)]
    IR-6 Requirement: Reports security incident information according to FedRAMP Incident Communications Procedure.
  title: >-
    IR-6 - INCIDENT REPORTING
  levels:
  - high
  - moderate
  - low
- id: IR-6(1)
  status: pending
  notes: |-
    The customer will be responsible for using automated mechanisms (such
    as ticketing systems and incident tracking/reporting systems) in support
    of the reporting of security incidents. A successful control response
    will need to address the automated systems involved and how they are
    used for reporting of incidents.
  rules: []
  description: |-
    The organization employs automated mechanisms to assist in the reporting of security incidents.

    Supplemental Guidance:  Related control: IR-7.
  title: >-
    IR-6(1) - INCIDENT REPORTING | AUTOMATED REPORTING
  levels:
  - high
  - moderate
- id: IR-7
  status: pending
  notes: |-
    The customer will be responsible for providing incident response
    resources to their users. These resources may be, for example, web
    pages, helpdesk resources, or assistanceg groups. A successful
    control response will need to outline the resources available and
    discuss how users are notified of the existence of these resources.
  rules: []
  description: |-
    The organization provides an incident response support resource, integral to the organizational incident response capability that offers advice and assistance to users of the information system for the handling and reporting of security incidents.

    Supplemental Guidance:  Incident response support resources provided by organizations include, for example, help desks, assistance groups, and access to forensics services, when required. Related controls: AT-2, IR-4, IR-6, IR-8, SA-9.
  title: >-
    IR-7 - INCIDENT RESPONSE ASSISTANCE
  levels:
  - high
  - moderate
  - low
- id: IR-7(1)
  status: pending
  notes: |-
    The customer will be responislbe for using automated mechanisms
    (such as websites or email distribution lists) to increase the
    availability of incident response support resources. A successful
    control response will need to discuss the mechanisms used and the
    information and support resources provided via each mechanism.
  rules: []
  description: |-
    The organization employs automated mechanisms to increase the availability of incident response- related information and support.

    Supplemental Guidance:  Automated mechanisms can provide a push and/or pull capability for users to obtain incident response assistance. For example, individuals might have access to a website to query the assistance capability, or conversely, the assistance capability may have the ability to proactively send information to users (general distribution or targeted) as part of increasing understanding of current response capabilities and support.
  title: >-
    IR-7(1) - INCIDENT RESPONSE ASSISTANCE | AUTOMATION SUPPORT FOR AVAILABILITY OF
    INFORMATION / SUPPORT
  levels:
  - high
  - moderate
- id: IR-7(2)
  status: pending
  notes: |-
    Section a: The customer will be responsible for establishing relationships
    between its incident response capability and external providers. In
    particular, it is the customers responsibility to provide accurate
    and current contact information to IaaS providers in order to receive
    notifications of security incidents involving the potential breach
    of customer data. Additionally, the customer is responsible to designate
    US-CERT as a notification contact. A successful control response will
    need to address these requirements as well as relationships with any
    other relevant external providers of information system protection
    capability.
    Section b: The customer will be responsible for identifying incident response
    team members to IaaS providers and any other external providers. A
    successful control response will need to discuss the means by which
    this identification is communicated.
  rules: []
  description: |-
    The organization:
     (a)   Establishes a direct, cooperative relationship between its incident response capability and external providers of information system protection capability; and
     (b)   Identifies organizational incident response team members to the external providers.

    Supplemental Guidance:  External providers of information system protection capability include, for example, the Computer Network Defense program within the U.S. Department of Defense. External providers help to protect, monitor, analyze, detect, and respond to unauthorized activity within organizational information systems and networks.
  title: >-
    IR-7(2) - INCIDENT RESPONSE ASSISTANCE | COORDINATION WITH EXTERNAL PROVIDERS
  levels:
  - high
  - moderate
- id: IR-8
  status: pending
  notes: |-
    Section a: The customer will be responsible for developing an incident response
    plan that includes consideration for any controls that are the
    responsibility of the customer relating to shared touch points inclduded
    in the customers authorization boundary and any customer applications
    leveraging the providers infrastructure. A successful control response
    will need to address how the plan meets each of the specified
    requirements, and the individuals or roles responsible for ensuring that
    the requirements are met.
    Section b: The customer will be responsible for distributing the incident
    response plan to identified internal and FedRAMP personnel. A successful
    control response will need to address the criteria for inclusion in the
    distribution list.
    Section c: The customer will be responsible for reviewing the incident response
    plan at the required frequency. A successful control response will need
    to address how the review process is initiated and the roles or
    individuals responsible for performing the review.
    Section d: The customer will be responsible for updating the incident response
    plan as appropriate. A successful control response will need to address
    the criteria for requiring an update to the incident response plan, the
    individuals or roles responsible for updating the plan, and the process
    for approval of updates.
    Section e: The customer will be responsible for communicating changes made to the
    incident response plan to the list of internal and FedRAMP personnel
    identified in IR-8(b).
    Section f: The customer will be responsible for protecting the incident response
    plan from unauthorized disclosure or modification. A successful control
    response will need to address policy, procedural, and technical
    safeguards that are in place to protect the incident response plan.
  rules: []
  description: |-
    The organization:
     a. Develops an incident response plan that:
       1. Provides the organization with a roadmap for implementing its incident response capability;
       2. Describes the structure and organization of the incident response capability;
       3. Provides a high-level approach for how the incident response capability fits into the overall organization;
       4. Meets the unique requirements of the organization, which relate to mission, size, structure, and functions;
       5. Defines reportable incidents;
       6. Provides metrics for measuring the incident response capability within the organization;
       7. Defines the resources and management support needed to effectively maintain and mature an incident response capability; and
       8. Is reviewed and approved by [Assignment: organization-defined personnel or roles];
     b. Distributes copies of the incident response plan to [Assignment: organization-defined incident response personnel (identified by name and/or by role) and organizational elements];
     c. Reviews the incident response plan [Assignment: organization-defined frequency];
     d. Updates the incident response plan to address system/organizational changes or problems encountered during plan implementation, execution, or testing;
      e. Communicates incident response plan changes to [Assignment: organization-defined incident response personnel (identified by name and/or by role) and organizational elements]; and
    f. Protects the incident response plan from unauthorized disclosure and modification.

    Supplemental Guidance:  It is important that organizations develop and implement a coordinated approach to incident response. Organizational missions, business functions, strategies, goals, and objectives for incident response help to determine the structure of incident response capabilities. As part of a comprehensive incident response capability, organizations consider the coordination and sharing of information with external organizations, including, for example, external service providers and organizations involved in the supply chain for organizational information systems. Related controls: MP-2, MP-4, MP-5.

    Control Enhancements:  None.

    References:  NIST Special Publication 800-61.

    IR-8 (b) [see additional FedRAMP Requirements and Guidance]
    IR-8 (c) [at least annually]
    IR-8 (e) [see additional FedRAMP Requirements and Guidance]
    IR-8 (b) Requirement: The service provider defines a list of incident response personnel (identified by name and/or by role) and organizational elements. The incident response list includes designated FedRAMP personnel.
    IR-8 (e) Requirement: The service provider defines a list of incident response personnel (identified by name and/or by role) and organizational elements. The incident response list includes designated FedRAMP personnel.
  title: >-
    IR-8 - INCIDENT RESPONSE PLAN
  levels:
  - high
  - moderate
  - low
- id: IR-9
  status: pending
  notes: |-
    Section a: The customer will be repsonsible for identifying the specific
    information involved in an information spill. A successful control
    response will need to address how spills are detected and the tools
    or processes used to identify the specific information involved.
    Section b: The customer will be responsible for alerting designated personnel
    using a non-contaminated method of communication. A successful control
    response will need to discuss how the personnel are designated and
    notified.
    Section c: The customer will be responsible for isolating the contaminated
    system or component. This may involved, for example, disabling
    connections to the component or shutting it down. A successful
    contorl response will need to address the types of components that
    could potentially be contaminated and the mechanism for isolating
    each type.
    Section d: The customer will be responsible for eradicating the spilled
    information from the contaminated system or component. A successful
    control response will need to address the means by which
    eradication is carried out and confirmed.
    Section e: The customer will be repsonsible for identifying other systems or
    components that may have been contaminated subsequent to the initial
    spill. A successful control response will need to outline the
    investigative process used to make this determination.
    Section f: The customer will be responsible for identifying and performing any
    additional required actions to resolve information spills. A
    successful control response will need to address how those actions
    are identified and the roles or individuals responsible for
    identifying and performing the actions.
  rules: []
  description: |-
    The organization responds to information spills by:
     a. Identifying the specific information involved in the information system contamination;
     b. Alerting [Assignment: organization-defined personnel or roles] of the information spill using a method of communication not associated with the spill;
     c. Isolating the contaminated information system or system component;
     d. Eradicating the information from the contaminated information system or component;
     e. Identifying other information systems or system components that may have been subsequently contaminated; and
     f. Performing other [Assignment: organization-defined actions].
    Supplemental Guidance: Information spillage refers to instances where either classified or sensitive information is inadvertently placed on information systems that are not authorized to process such information. Such information spills often occur when information that is initially thought to be of lower sensitivity is transmitted to an information system and then is subsequently determined to be of higher sensitivity. At that point, corrective action is required. The nature of the organizational response is generally based upon the degree of sensitivity of the spilled information (e.g., security category or classification level), the security capabilities of the information system, the specific nature of contaminated storage media, and the access authorizations (e.g., security clearances) of individuals with authorized access to the contaminated system. The methods used to communicate information about the spill after the fact do not involve methods directly associated with the actual spill to minimize the risk of further spreading the contamination before such contamination is isolated and eradicated.

    References: None.
  title: >-
    IR-9 - INFORMATION SPILLAGE RESPONSE
  levels:
  - high
  - moderate
- id: IR-9(1)
  status: pending
  notes: |-
    The customer will be responsible for identifying personnel or roles
    with responsibility for responding to information spills. This may be
    all members of the incident response team, specific members with
    specialized knowledge, or individuals or teams completely distinct from
    the incident response team. A successful control response will need to
    address the rationale for the selection.
  rules: []
  description: |-
    The organization assigns [Assignment: organization-defined personnel or roles] with responsibility for responding to information spills.
  title: >-
    IR-9(1) - INFORMATION SPILLAGE RESPONSE | RESPONSIBLE PERSONNEL
  levels:
  - high
  - moderate
- id: IR-9(2)
  status: pending
  notes: |-
    The customer will be responsible for providing information spillage
    response training on a regular basis. This may be incorporated into
    overall incident response training or may be a separate training
    course or module. A successful control response will need to outline
    the contents of the information spillage response training and address
    the frequency at which training is provided.
  rules: []
  description: |-
    The organization provides information spillage response training [Assignment: organization- defined frequency].

    IR-9 (2) [at least annually]
  title: >-
    IR-9(2) - INFORMATION SPILLAGE RESPONSE | TRAINING
  levels:
  - high
  - moderate
- id: IR-9(3)
  status: pending
  notes: |-
    The customer will be responsible for defining and implementing
    procedures to allow personnel affected by information spills to continue
    carrying out assigned tasks during the information spill response
    process. A successful contorl response will need to addres, for example,
    alternate means of connection to affected systems and changes to
    processes required to employ those alternate means.
  rules: []
  description: |-
    The organization implements [Assignment: organization-defined procedures] to ensure that organizational personnel impacted by information spills can continue to carry out assigned tasks while contaminated systems are undergoing corrective actions.

    Supplemental Guidance:  Correction actions for information systems contaminated due to information spillages may be very time-consuming. During those periods, personnel may not have access to the contaminated systems, which may potentially affect their ability to conduct organizational business.
  title: >-
    IR-9(3) - INFORMATION SPILLAGE RESPONSE | POST-SPILL OPERATIONS
  levels:
  - high
  - moderate
- id: IR-9(4)
  status: pending
  notes: |-
    The customer will be responsible for defining and employing additional
    safeguards for personnel exposed to information they were not authorized
    to access. These may include, for example, additional training,
    non-disclosure agreements, etc. A successful control response will need
    to address the nature of these safeguards and whether they are employed
    proactively (prior to information spillage incidents) or reactively
    (following information spillage incidents).
  rules: []
  description: |-
    The organization employs [Assignment: organization-defined security safeguards] for personnel exposed to information not within assigned access authorizations.

    Supplemental Guidance:  Security safeguards include, for example, making personnel exposed to spilled information aware of the federal laws, directives, policies, and/or regulations regarding the information and the restrictions imposed based on exposure to such information.
  title: >-
    IR-9(4) - INFORMATION SPILLAGE RESPONSE | EXPOSURE TO UNAUTHORIZED PERSONNEL
  levels:
  - high
  - moderate
- id: MA-1
  status: pending
  notes: |-
    Section a: The organization will be responsible for developing, documenting, and
    disseminating System Maintenance policy and procedures. A successful
    control response will need to address the content of the policy
    (which must include purpose, scope, roles, responsibilities,
    management commitments, coordination, and compliance) and procedures
    (which must facilitate the implementation of the policies and
    associated controls).
    Section b: The organization will be responsible for reviewing and updating the
    System Maintenance policy every 3 years, and procedures annually. A
    successful control response will need to address the review and
    update process, including the role(s) responsible for initiating the
    review process, updating the policy and procedures, and providing
    approval of the updates.
  rules: []
  description: |-
    The organization:
     a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:
       1. A system maintenance policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and
       2. Procedures to facilitate the implementation of the system maintenance policy and associated system maintenance controls; and
     b. Reviews and updates the current:
       1. System maintenance policy [Assignment: organization-defined frequency]; and
       2. System maintenance procedures [Assignment: organization-defined frequency].

    Supplemental Guidance:  This control addresses the establishment of policy and procedures for the effective implementation of selected security controls and control enhancements in the MA family. Policy and procedures reflect applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance. Security program policies and procedures at the organization level may make the need for system-specific policies and procedures unnecessary. The policy can be included as part of the general information security policy for organizations or conversely, can be represented by multiple policies reflecting the complex nature of certain organizations. The procedures can be established for the security program in general and for particular information systems, if needed. The organizational risk management strategy is a key factor in establishing policy and procedures. Related control: PM-9.

    Control Enhancements:  None.

    References:  NIST Special Publications 800-12, 800-100.

    MA-1 (b) (1) [at least annually]
    MA-1 (b) (2) [at least annually or whenever a significant change occurs]
  title: >-
    MA-1 - SYSTEM MAINTENANCE POLICY AND PROCEDURES
  levels:
  - high
  - moderate
  - low
- id: MA-2
  status: pending
  notes: |-
    Section c: The customer will be responsible for requiring that datacenter
    management and property asset owners explicity approve the removal
    of the information system or system components from organizational
    facilities for off-site maintenance repairs. This is frequently an
    inherited control from IaaS providers and not applicable to OpenShift
    deployments.
    Section d: The customer will be responsible for santizing equipment to remove
    all information from the associated media prior to removal from
    organizational facilities. This is frequently an inherited control
    from IaaS providers and not applicable to OpenShift deployments.
  rules: []
  description: |-
    The organization:
     a. Schedules, performs, documents, and reviews records of maintenance and repairs on information system components in accordance with manufacturer or vendor specifications and/or organizational requirements;
     b. Approves and monitors all maintenance activities, whether performed on site or remotely and whether the equipment is serviced on site or removed to another location;
     c. Requires that [Assignment: organization-defined personnel or roles] explicitly approve the removal of the information system or system components from organizational facilities for off-site maintenance or repairs;
     d. Sanitizes equipment to remove all information from associated media prior to removal from organizational facilities for off-site maintenance or repairs;
     e. Checks all potentially impacted security controls to verify that the controls are still functioning properly following maintenance or repair actions; and
     f. Includes [Assignment: organization-defined maintenance-related information] in organizational maintenance records.

    Supplemental Guidance:  This control addresses the information security aspects of the information system maintenance program and applies to all types of maintenance to any system component (including applications) conducted by any local or nonlocal entity (e.g., in-contract, warranty, in- house, software maintenance agreement). System maintenance also includes those components not directly associated with information processing and/or data/information retention such as scanners, copiers, and printers. Information necessary for creating effective maintenance records includes, for example: (i) date and time of maintenance; (ii) name of individuals or group performing the maintenance; (iii) name of escort, if necessary; (iv) a description of the maintenance performed; and (v) information system components/equipment removed or replaced (including identification numbers, if applicable). The level of detail included in maintenance records can be informed by
    the security categories of organizational information systems. Organizations consider supply chain issues associated with replacement components for information systems. Related controls: CM-3, CM-4, MA-4, MP-6, PE-16, SA-12, SI-2.

    References: None.
  title: >-
    MA-2 - CONTROLLED MAINTENANCE
  levels:
  - high
  - moderate
  - low
- id: MA-3
  status: pending
  notes: |-
    The customer will be responsible for approving, controlling, and
    monitoring information system maintenance records. A successful
    control response will document this process.
  rules: []
  description: "The organization approves, controls, and monitors information system\
    \ maintenance tools.\n\nSupplemental Guidance:  This control addresses security-related\
    \ issues associated with maintenance tools used specifically for diagnostic and\
    \ repair actions on organizational information systems. Maintenance tools can\
    \ include hardware, software, and firmware items. Maintenance tools are potential\
    \ vehicles for transporting malicious code, either intentionally or unintentionally,\
    \ into a facility and subsequently into organizational information systems. Maintenance\
    \ tools can include, for example, hardware/software diagnostic test equipment\
    \ and hardware/software packet sniffers. This control does not cover hardware/software\
    \ components that may support information system maintenance, yet are a part of\
    \ the system, for example, the software implementing \u201Cping,\u201D \u201C\
    ls,\u201D \u201Cipconfig,\u201D or the hardware and software implementing the\
    \ monitoring port of an Ethernet switch. Related controls: MA-2, MA-5, MP-6.\n\
    \nReferences: NIST Special Publication 800-88."
  title: >-
    MA-3 - MAINTENANCE TOOLS
  levels:
  - high
  - moderate
- id: MA-3(1)
  status: pending
  notes: |-
    The customer will be responsible for inspecting the maintenance
    tools carried into a facility by maintenance personnel for improper
    or unauthorized modifications. A successful control response
    will document this process.
  rules: []
  description: |-
    The organization inspects the maintenance tools carried into a facility by maintenance personnel for improper or unauthorized modifications.

    Supplemental Guidance:  If, upon inspection of maintenance tools, organizations determine that the tools have been modified in an improper/unauthorized manner or contain malicious code, the incident is handled consistent with organizational policies and procedures for incident handling. Related control: SI-7.
  title: >-
    MA-3(1) - MAINTENANCE TOOLS | INSPECT TOOLS
  levels:
  - high
  - moderate
- id: MA-3(2)
  status: pending
  notes: |-
    The customer will be responsible for checking media containing
    diagnostic and test programs for malicious code before the
    media are used in the information system. A successful control response
    documents this process.
  rules: []
  description: |-
    The organization checks media containing diagnostic and test programs for malicious code before the media are used in the information system.

    Supplemental Guidance:  If, upon inspection of media containing maintenance diagnostic and test programs, organizations determine that the media contain malicious code, the incident is handled consistent with organizational incident handling policies and procedures. Related control: SI-3.
  title: >-
    MA-3(2) - MAINTENANCE TOOLS | INSPECT MEDIA
  levels:
  - high
  - moderate
- id: MA-3(3)
  status: pending
  notes: |-
    The customer will be responsible for prevengint unauthorized removal
    of manteance equipment containing organizational information. A
    successful control response will address (a) process to verify there
    is no organizational information contained on the equipment; (b) how
    equipment is sanitized or destroyed; (c) process to retain the
    equipment within the facility; (d) process to obtain an exception
    from these processes from the information owner that explicity
    authorizes removal of equipment from the facility
  rules: []
  description: "The organization prevents the unauthorized removal of maintenance\
    \ equipment containing organizational information by:\n (a)   Verifying that there\
    \ is no organizational information contained on the equipment; \n (b)   Sanitizing\
    \ or destroying the equipment;\n (c)   Retaining the equipment within the facility;\
    \ or\n (d)   Obtaining an exemption from [Assignment: organization-defined personnel\
    \ or roles] explicitly authorizing removal of the equipment from the facility.\n\
    \nSupplemental Guidance:  Organizational information includes all information\
    \ specifically owned by organizations and information provided to organizations\
    \ in which organizations serve as information stewards.\n\nMA-3 (3) (d) [the information\
    \ owner explicitly authorizing removal of the equipment from the facility]"
  title: >-
    MA-3(3) - MAINTENANCE TOOLS | PREVENT UNAUTHORIZED REMOVAL
  levels:
  - high
  - moderate
- id: MA-4
  status: pending
  notes: |-
    Section a: The customer will be responsible for approving and monitoring
    non-local maintenance and diagnostic activities. Because of the nature
    of a cloud system, all maintenance and diagnostic activities will be
    considered non-local. Therefore, this control can largely be
    addressed by reference to acess control authorizations (see AC-2)
    and the auditing and monitoring discussions in the AU family and SI-4. A
    successful control response will need to address the personnel or roles
    who are authorized to perform maintenance and diagnostic activities,
    and how those activities are tracked.
  rules: []
  description: |-
    The organization:
     a. Approves and monitors nonlocal maintenance and diagnostic activities;
     b. Allows the use of nonlocal maintenance and diagnostic tools only as consistent with organizational policy and documented in the security plan for the information system;
     c. Employs strong authenticators in the establishment of nonlocal maintenance and diagnostic sessions;
     d. Maintains records for nonlocal maintenance and diagnostic activities; and
     e. Terminates session and network connections when nonlocal maintenance is completed.

    Supplemental Guidance:  Nonlocal maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network. Local maintenance and diagnostic activities are those activities carried out by individuals physically present at the information system or information system component and not communicating across a network connection. Authentication techniques used in the establishment of nonlocal maintenance and diagnostic sessions reflect the network access requirements in IA-2. Typically, strong authentication requires authenticators that are resistant to replay attacks and employ multifactor authentication. Strong authenticators include, for example, 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. Related controls: AC-2, AC-3, AC-6, AC-17, AU-2, AU-3, IA-2, IA-4, IA-5, IA-8, MA-2, MA-5, MP-6, PL-2, SC-7, SC-10, SC-17.

    References: FIPS Publications 140-2, 197, 201; NIST Special Publications 800-63, 800-88; CNSS Policy 15.
  title: >-
    MA-4 - NONLOCAL MAINTENANCE
  levels:
  - high
  - moderate
  - low
- id: MA-4(2)
  status: pending
  notes: |-
    The customer will be responsible for documenting the policies and
    procedures for the establishment and use of non-local maintenance
    and diagnostic connections. A successful control response will need to
    address when non-local maintenance and diagnostic connections are
    allowed, what personnel are authorized to establish and use them, and
    udner what circumstances connections must be terminated.
  rules: []
  description: |-
    The organization documents in the security plan for the information system, the policies and procedures for the establishment and use of nonlocal maintenance and diagnostic connections.
  title: >-
    MA-4(2) - NONLOCAL MAINTENANCE | DOCUMENT NONLOCAL MAINTENANCE
  levels:
  - high
  - moderate
- id: MA-5
  status: pending
  notes: |-
    Section a: The customer will be responsible for establishing a process for
    maintenance personnel authorizationa and maintains a list of authorized
    maintenance organizations/personnel. A successful control response will
    document this process and where the records are kept.
    Section b: The customer will be responsible for ensuring that non-escorted
    personnel performing maintenance on the information system have
    required access authorizations. A successful control response will
    document this process, and should involve the information owner
    signing off on this access.
    Section c: The customer will be responsible for designating organizational
    personnel with required access authorizations and technical
    competence to supervise the maintenance personnel. A successful
    control response will document the process for becoming an escore, and
    how technical competence is established.
  rules: []
  description: |-
    The organization:
     a. Establishes a process for maintenance personnel authorization and maintains a list of authorized maintenance organizations or personnel;
     b. Ensures that non-escorted personnel performing maintenance on the information system have required access authorizations; and
     c. Designates organizational personnel with required access authorizations and technical competence to supervise the maintenance activities of personnel who do not possess the required access authorizations.

    Supplemental Guidance:  This control applies to individuals performing hardware or software maintenance on organizational information systems, while PE-2 addresses physical access for individuals whose maintenance duties place them within the physical protection perimeter of the systems (e.g., custodial staff, physical plant maintenance personnel). Technical competence of supervising individuals relates to the maintenance performed on the information 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 information systems, for example, when 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. Related controls: AC-2, IA-8, MP-2, PE-2, PE-3, PE-4, RA-3.

    References: None.
  title: >-
    MA-5 - MAINTENANCE PERSONNEL
  levels:
  - high
  - moderate
  - low
- id: MA-5(1)
  status: pending
  notes: |-
    Section a: The customer will be responsible for implementing procedures for
    the use of maintenace personnel that lack appropriate security
    clearances or are not U.S. citizens. These procures must address
    (1) personnel who do not have needed access authorizations are escorted
    by those who do; optionally (2) prior to initiating maintenance or
    diagnostic activities by personnel lacking access authorizations, all
    volatile information storage components within the information system
    are santized and all nonvolatile storage media are removed or physically
    disconnected from the system and secured.
    Section b: The customer will be responsible for developing and implimenting
    alternate security safeguards in the event an information system
    component cannot be santized, removed, or disconnected from the system.
    A successful control response will document how maintenance staff
    lacking appropriate authorizations will not be able to access
    data residing on the informarion system.
  rules: []
  description: |-
    The organization:
     (a)   Implements procedures for the use of maintenance personnel that lack appropriate security clearances or are not U.S. citizens, that include the following requirements:
        (1)   Maintenance personnel who do not have needed access authorizations, clearances, or formal access approvals are escorted and supervised during the performance of maintenance and diagnostic activities on the information system by approved organizational personnel who are fully cleared, have appropriate access authorizations, and are technically qualified;
       (2)   Prior to initiating maintenance or diagnostic activities by personnel who do not have needed access authorizations, clearances or formal access approvals, all volatile information storage components within the information system are sanitized and all nonvolatile storage media are removed or physically disconnected from the system and secured; and
     (b)   Develops and implements alternate security safeguards in the event an information system component cannot be sanitized, removed, or disconnected from the system.

    Supplemental Guidance:  This control enhancement denies individuals who lack appropriate security clearances (i.e., individuals who do not possess security clearances or possess security clearances at a lower level than required) or who are not U.S. citizens, visual and
    electronic access to any classified information, Controlled Unclassified Information (CUI), or any other sensitive information contained on organizational information systems. Procedures for the use of maintenance personnel can be documented in security plans for the information systems. Related controls: MP-6, PL-2.
  title: >-
    MA-5(1) - MAINTENANCE PERSONNEL | INDIVIDUALS WITHOUT APPROPRIATE ACCESS
  levels:
  - high
  - moderate
- id: MA-6
  status: pending
  notes: |-
    The customer will be responsible for obtaining maintenance support
    and/or spare parts for critical components within a reasonable time
    to minimize production impact.
  rules: []
  description: |-
    The organization obtains maintenance support and/or spare parts for [Assignment: organization-defined information system components] within [Assignment: organization-defined time period] of failure.

    Supplemental Guidance:  Organizations specify the information 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 typically include having appropriate contracts in place. Related controls: CM-8, CP-2, CP-7, SA-14, SA-15.

    References: None.
  title: >-
    MA-6 - TIMELY MAINTENANCE
  levels:
  - high
  - moderate
- id: MP-1
  status: pending
  notes: |-
    Narrative text on how product can be configured against MP-1.

    This answer can be multi-line.
  rules: []
  description: |-
    The organization:
     a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:
       1. A media protection policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and
       2. Procedures to facilitate the implementation of the media protection policy and associated media protection controls; and
     b. Reviews and updates the current:
       1. Media protection policy [Assignment: organization-defined frequency]; and
       2. Media protection procedures [Assignment: organization-defined frequency].

    Supplemental Guidance:  This control addresses the establishment of policy and procedures for the effective implementation of selected security controls and control enhancements in the MP family. Policy and procedures reflect applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance. Security program policies and procedures at the organization level may make the need for system-specific policies and procedures unnecessary. The policy can be included as part of the general information security policy for organizations or conversely, can be represented by multiple policies reflecting the complex nature of certain organizations. The procedures can be established for the security program in general and for particular information systems, if needed. The organizational risk management strategy is a key factor in establishing policy and procedures. Related control: PM-9.

    Control Enhancements:  None.

    References:  NIST Special Publications 800-12, 800-100.

    MP-1 (b) (1) [at least annually]
    MP-1 (b) (2) [at least annually or whenever a significant change occurs]
  title: >-
    MP-1 - MEDIA PROTECTION POLICY AND PROCEDURES
  levels:
  - high
  - moderate
  - low
- id: MP-2
  status: pending
  notes: |-
    Narrative text on how product can be configured against MP-2.

    This answer can be multi-line.
  rules: []
  description: |-
    The organization restricts access to [Assignment: organization-defined types of digital and/or non-digital media] to [Assignment: organization-defined personnel or roles].

    Supplemental Guidance:   Information system media includes both digital and non-digital media. Digital media includes, for example, diskettes, magnetic tapes, external/removable hard disk drives, flash drives, compact disks, and digital video disks. Non-digital media includes, for example, paper and microfilm. Restricting non-digital media access includes, for example, denying access to patient medical records in a community hospital unless the individuals seeking access to such records are authorized healthcare providers. Restricting access to digital media includes, for example, limiting access to design specifications stored on compact disks in the media library to the project leader and the individuals on the development team. Related controls: AC-3, IA-2, MP-4, PE-2, PE-3, PL-2.

    MP-2-1 [any digital and non-digital media deemed sensitive]
  title: >-
    MP-2 - MEDIA ACCESS
  levels:
  - high
  - moderate
  - low
- id: PL-1
  status: pending
  notes: |-
    Section a: The organization will be responsible for developing, documenting, and
    disseminating Security Planning policy and procedures. A successful
    control response will need to address the content of the policy
    (which must include purpose, scope, roles, responsibilities,
    management commitment, coordination, and compliance) and proecures
    (which must facilitate the implementation of the policies and
    associated controls).
    Section b: The organization will be responsible for reviewing and updating the
    Security Planning policy every 3 years, and procedures annually. A
    successful control response will need to address the review and
    update process, including the role(s) responsible for initiating
    the review process, updating the policy and procedures, and providing
    approval of the updates.
  rules: []
  description: |-
    The organization:
     a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:
       1. A security planning policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and
       2. Procedures to facilitate the implementation of the security planning policy and associated security planning controls; and
     b. Reviews and updates the current:
       1. Security planning policy [Assignment: organization-defined frequency]; and
       2. Security planning procedures [Assignment: organization-defined frequency].

    Supplemental Guidance: This control addresses the establishment of policy and procedures for the effective implementation of selected security controls and control enhancements in the PL family. Policy and procedures reflect applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance. Security program policies and procedures at the organization level may make the need for system-specific policies and procedures unnecessary. The policy can be included as part of the general information security policy for organizations or conversely, can be represented by multiple policies reflecting the complex nature of certain organizations. The procedures can be established for the security program in general and for particular information systems, if needed. The organizational risk management strategy is a key factor in establishing policy and procedures. Related control: PM-9.

    Control Enhancements:  None.

    References:  NIST Special Publications 800-12, 800-18, 800-100.

    PL-1 (b) (1) [at least annually]
    PL-1 (b) (2) [at least annually or whenever a significant change occurs]
  title: >-
    PL-1 - SECURITY PLANNING POLICY AND PROCEDURES
  levels:
  - high
  - moderate
  - low
- id: PL-2
  status: pending
  notes: |-
    Section a: The customer will be responsible for developing a system security
    plan (this document) in accordance with the above requirements. A
    successful control response will need to address each of the
    requirements and how this document meets them.

    The customer may with to consult NIST Special Publication 800-18,
    Revision 1, Guide for Developing Security Plans for Federal Information
    Systems, which contains guidance on security planning. Portions of this
    system security plan will discuss controls inherited from infrastructure
    providers, such as Microsoft Azure, and will refer to the
    infrastructure providers SSP.
    Section b: The customer will be responsible for distributing the system security
    plan to relevant personnel and keeping those personnel informed of
    subsequent changes. A successful control response will need to address
    identifying personnel who should receive a copy of the system security
    plan, as well as ensuring all such personnel are notified
    appropriately.
    Section c: The customer will be responsible for reviewing the system security
    plan at the required frequency. A successful control response will need
    to address the initiation of the review process and the roles or
    individuals responsible for review.
    Section d: The customer will be responsible for updating the system security
    plan to address changes to the information system and its environment
    or any problems identified during implementation or security
    assessments. A successful control response will need to discuss the
    roles or individuals responsible for updating the plan, as well as
    the process for approval of any updates.
    Section e: The customer will be responsible for protecting the security plan from
    unauthorized disclosure or modification. A successful control response
    will need to address policy, procedural, and technical safeguards that
    are in place to protect the system security plan.
  rules: []
  description: "The organization:\n a. Develops a security plan for the information\
    \ system that:\n   1. Is consistent with the organization\u2019s enterprise architecture;\n\
    \   2. Explicitly defines the authorization boundary for the system;\n   3. Describes\
    \ the operational context of the information system in terms of missions and business\
    \ processes;\n   4. Provides the security categorization of the information system\
    \ including supporting rationale;\n   5. Describes the operational environment\
    \ for the information system and relationships with or connections to other information\
    \ systems;\n   6. Provides an overview of the security requirements for the system;\n\
    \   7. Identifies any relevant overlays, if applicable;\n   8. Describes the security\
    \ controls in place or planned for meeting those requirements including a rationale\
    \ for the tailoring and supplementation decisions; and\n   9. Is reviewed and\
    \ approved by the authorizing official or designated representative prior to plan\
    \ implementation;\n b. Distributes copies of the security plan and communicates\
    \ subsequent changes to the plan to [Assignment: organization-defined personnel\
    \ or roles];\n c. Reviews the security plan for the information system [Assignment:\
    \ organization-defined frequency];\n d. Updates the plan to address changes to\
    \ the information system/environment of operation or problems identified during\
    \ plan implementation or security control assessments; and\n e. Protects the security\
    \ plan from unauthorized disclosure and modification.\n\nSupplemental Guidance:\
    \  Security plans relate security requirements to a set of security controls and\
    \ control enhancements. Security plans also describe, at a high level, how the\
    \ security controls and control enhancements meet those security requirements,\
    \ but do not provide detailed, technical descriptions of the specific design or\
    \ implementation of the controls/enhancements. Security plans contain sufficient\
    \ information (including the specification of parameter values for assignment\
    \ and selection statements either explicitly or by reference) to enable a design\
    \ and implementation that is unambiguously compliant with the intent of the plans\
    \ and subsequent determinations of risk to organizational operations and assets,\
    \ individuals, other organizations, and the Nation if the plan is implemented\
    \ as intended. Organizations can also apply tailoring guidance to the security\
    \ control baselines in Appendix D and CNSS Instruction 1253 to develop overlays\
    \ for community-wide use or to address specialized requirements, technologies,\
    \ or missions/environments of operation (e.g., DoD-tactical, Federal Public Key\
    \ Infrastructure, or Federal Identity, Credential, and Access Management, space\
    \ operations). Appendix I provides guidance on developing overlays.\n\nSecurity\
    \ plans need not be single documents; the plans can be a collection of various\
    \ documents including documents that already exist. Effective security plans make\
    \ extensive use of references to policies, procedures, and additional documents\
    \ (e.g., design and implementation specifications) where more detailed information\
    \ can be obtained. This reduces the documentation requirements associated with\
    \ security programs and maintains security-related information in other established\
    \ management/operational areas related to enterprise architecture, system development\
    \ life cycle, systems engineering, and acquisition. For example, security plans\
    \ do not contain detailed contingency plan or incident response plan information\
    \ but instead provide explicitly or by reference, sufficient information to define\
    \ what needs to be accomplished by those plans. Related controls: AC-2, AC-6,\
    \ AC-14, AC-17, AC-20, CA-2, CA-3, CA-7, CM-9, CP-2, IR-8, MA-4, MA-5, MP-2, MP-4,\
    \ MP-5, PL-7, PM-1, PM-7, PM-8, PM-9, PM-11, SA-5, SA-17.\n\nReferences: NIST\
    \ Special Publication 800-18.\n\nPL-2 (c) [at least annually]"
  title: >-
    PL-2 - SYSTEM SECURITY PLAN
  levels:
  - high
  - moderate
  - low
- id: PL-2(3)
  status: pending
  notes: |-
    The customer will be responsible for planning and coordinating
    security-related activities so as to reduce the impact on other
    organizational entities. These activities may include security
    assessments, audits, maintenance, patch management, and contingency
    plan testing. A successful control response will need to address the
    process by which other organizational entities are notified of and
    consulted regarding such activities.
  rules: []
  description: |-
    The organization plans and coordinates security-related activities affecting the information system with [Assignment: organization-defined individuals or groups] before conducting such activities in order to reduce the impact on other organizational entities.

    Supplemental Guidance:  Security-related activities include, for example, security assessments, audits, hardware and software maintenance, patch management, and contingency plan testing. Advance planning and coordination includes emergency and nonemergency (i.e., planned or nonurgent unplanned) situations. The process defined by organizations to plan and coordinate security-related activities can be included in security plans for information systems or other documents, as appropriate. Related controls: CP-4, IR-4.
  title: >-
    PL-2(3) - SYSTEM SECURITY PLAN | PLAN / COORDINATE WITH OTHER ORGANIZATIONAL ENTITIES
  levels:
  - high
  - moderate
- id: PL-4
  status: pending
  notes: |-
    Section a: The customer will be responsible for defining, documenting, and
    distributing rules of behavior. A successful control response will need
    to outline the rules of behavior and discuss the process for making them
    available to users requiring access to the system.
    Section b: The customer will be repsonsible for obtaining signed acknowledgement
    of the rules of behavior from its users. A successful control response
    will need to address the process for withholding authorization until
    signatures are obtained.
    Section c: The customer will be responsible for reviewing and updating the rules
    of behavior at the required frequency. A successful control response
    will need to address the process for initiating review, as well as the
    individuals or roles for carrying out the review, managing updates, and
    approving the final version.
    Section d: The customer will be responsible for obtaining signed acknowledgement
    of the updated rules of behavior. A successful control response will
    need to address the process for removing authorization if signatures
    are not obtained in a timely manner.
  rules: []
  description: |-
    The organization:
     a. Establishes and makes readily available to individuals requiring access to the information system, the rules that describe their responsibilities and expected behavior with regard to information and information system usage;
     b. Receives a signed 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 information system;
     c. Reviews and updates the rules of behavior [Assignment: organization-defined frequency]; and d. Requires individuals who have signed a previous version of the rules of behavior to read and
    resign when the rules of behavior are revised/updated.

    Supplemental Guidance: This control enhancement applies to organizational users. Organizations consider rules of behavior based on individual user roles and responsibilities, differentiating, for example, 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, for example, individuals who simply receive data/information from federal information 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 both organizational and non-organizational users can also be established in AC-8, System Use Notification. PL-4 b. (the signed acknowledgment portion of this control) may be satisfied by the security awareness training and role-based security training programs conducted by organizations if such training includes rules of behavior. Organizations can use electronic signatures for acknowledging rules of behavior. Related controls: AC-2, AC-6, AC-8, AC-9, AC-17, AC-18, AC-19, AC-20, AT-2, AT-3, CM-11, IA-2, IA-4, IA-5, MP-7, PS-6, PS-8, SA-5.

    References: NIST Special Publication 800-18.

    PL-4 (c) [annually]
  title: >-
    PL-4 - RULES OF BEHAVIOR
  levels:
  - high
  - moderate
  - low
- id: PL-4(1)
  status: pending
  notes: |-
    The customer will be responsible for incorporating explicit
    restrictions on the use of social media/networking sites and posting
    organizational information on public websites into the rules of
    behavior. A successful control response will need to outline the
    relevant portions of the rules of behavior.
  rules: []
  description: |-
    The organization includes in the rules of behavior, explicit restrictions on the use of social media/networking sites and posting organizational information on public websites.

    Supplemental Guidance:  This control enhancement addresses rules of behavior related to the use of social media/networking sites: (i) when organizational personnel are using such sites for official duties or in the conduct of official business; (ii) when organizational information is involved in social media/networking transactions; and (iii) when personnel are accessing social media/networking sites from organizational information systems. Organizations also address specific rules that prevent unauthorized entities from obtaining and/or inferring non- public organizational information (e.g., system account information, personally identifiable information) from social media/networking sites.
  title: >-
    PL-4(1) - RULES OF BEHAVIOR | SOCIAL MEDIA AND NETWORKING RESTRICTIONS
  levels:
  - high
  - moderate
- id: PL-8
  status: pending
  notes: |-
    Section a: The customer will be responsible for developing their information
    security architecture. A successful contrl response will need to
    discuss the guiding principles used to protect confidentiality,
    integrity, and availability of system information and the dependencies
    on external services (such as Microsoft Azure). Additionally, a
    description of the information security architecture should be included
    in the introductory sections of this system security plan.
    Section b: The customer will be responsible for reviewing and updating the
    security architecture at a required frequency. A succesful control
    response will need to address the process for initiating review, as well
    as the individuals or roles responsible for carrying out the review,
    managing updates, and approving the final version.
    Section c: The customer will be responsible for incorporating changes to the
    security architecture into this system security plan as well as
    related materials. A successful control response will need to address
    the process for aligning the contents of the system security plan
    with the information security architecture, including the
    individuals or roles responsible for that alignment.
  rules: []
  description: "The organization:\n a. Develops an information security architecture\
    \ for the information system that:\n   1. Describes the overall philosophy, requirements,\
    \ and approach to be taken with regard to protecting the confidentiality, integrity,\
    \ and availability of organizational information;\n   2. Describes how the information\
    \ security architecture is integrated into and supports the enterprise architecture;\
    \ and\n   3. Describes any information security assumptions about, and dependencies\
    \ on, external services;\n b. Reviews and updates the information security architecture\
    \ [Assignment: organization-defined frequency] to reflect updates in the enterprise\
    \ architecture; and\n c. Ensures that planned information security architecture\
    \ changes are reflected in the security plan, the security Concept of Operations\
    \ (CONOPS), and organizational procurements/acquisitions.\n\nSupplemental Guidance:\
    \  This control addresses actions taken by organizations in the design and development\
    \ of information systems. The information security architecture at the individual\
    \ information system level is consistent with and complements the more global,\
    \ organization-wide information security architecture described in PM-7 that is\
    \ integral to and developed as part of the enterprise architecture. The information\
    \ security architecture includes an architectural description, the placement/allocation\
    \ of security functionality (including security controls), security-related information\
    \ for external interfaces, information being exchanged across the interfaces,\
    \ and the protection mechanisms associated with each interface. In addition, the\
    \ security architecture can include other important security-related information,\
    \ for example, user roles and access privileges assigned to each role, unique\
    \ security requirements, the types of information processed, stored, and transmitted\
    \ by the information system, restoration priorities of information and information\
    \ system services, and any other specific protection needs.\n\nIn today\u2019\
    s modern architecture, it is becoming less common for organizations to control\
    \ all information resources. There are going to be key dependencies on external\
    \ information services and service providers. Describing such dependencies in\
    \ the information security architecture is important to developing a comprehensive\
    \ mission/business protection strategy. Establishing, developing, documenting,\
    \ and maintaining under configuration control, a baseline configuration for organizational\
    \ information systems is critical to implementing and maintaining an effective\
    \ information security architecture. The development of the information security\
    \ architecture is coordinated with the Senior Agency Official for Privacy (SAOP)/Chief\
    \ Privacy Officer (CPO) to ensure that security controls needed to support privacy\
    \ requirements are identified and effectively implemented. PL-8 is primarily directed\
    \ at organizations (i.e., internally focused) to help ensure that organizations\
    \ develop an information security architecture for the information system, and\
    \ that the security architecture is integrated with or tightly coupled to the\
    \ enterprise architecture through the organization-wide information security architecture.\
    \ In contrast, SA-17 is primarily directed at external information technology\
    \ product/system developers and integrators (although SA-17 could be used internally\
    \ within organizations for in-house system development). SA-17, which is complementary\
    \ to PL-8, is selected when organizations outsource the development of information\
    \ systems or information system components to external entities, and there is\
    \ a need to demonstrate/show consistency with the organization\u2019s enterprise\
    \ architecture and information security architecture. Related controls: CM-2,\
    \ CM-6, PL-2, PM-7, SA-5, SA-17, Appendix J.\n\nReferences: None.\n\nPL-8 (b)\
    \ [at least annually or when a significant change occurs]\nPL-8 (b) Guidance:\
    \ Significant change is defined in NIST Special Publication 800-37 Revision 1,\
    \ Appendix F, page F-7."
  title: >-
    PL-8 - INFORMATION SECURITY ARCHITECTURE
  levels:
  - high
  - moderate
- id: PS-1
  status: pending
  notes: |-
    Section a: The organization will be responsible for developing, documenting, and
    disseminating Personnel Security policy and procedures. A successful
    control response will need to address the content of the policy
    (which must include purpose, scope, roles, responsibilities,
    management commitment, coordination, and compliance) and procedures
    (which must facilitate the implementation of the policies and
    associated controls).
    Section b: The organization will be responsible for reviewing and updating the
    Personnel Security policy every 3 years, and procedures annually. A
    successful control response will need to address the review and update
    process, including the role(s) responsible for initiating the review
    process, updating the policy and procedures, and providing approval
    of the updates.
  rules: []
  description: "The organization:\n a. Develops, documents, and disseminates to [Assignment:\
    \ organization-defined personnel or roles]:\n   1. A personnel security policy\
    \ that addresses purpose, scope, roles, responsibilities, management commitment,\
    \ coordination among organizational entities, and compliance; and\n   2. Procedures\
    \ to facilitate the implementation of the personnel security policy and associated\
    \ personnel security controls; and\n b. Reviews and updates the current:\n   1.\
    \ Personnel security policy [Assignment: organization-defined frequency]; and\n\
    \   2. Personnel security procedures [Assignment: organization-defined frequency].\n\
    \nSupplemental Guidance:  This control addresses the establishment of policy and\
    \ procedures for the effective implementation of selected security controls and\
    \ control enhancements in the PS family. Policy and procedures reflect applicable\
    \ federal laws, Executive Orders, directives, regulations, policies, standards,\
    \ and guidance. Security program policies and procedures at the organization level\
    \ may make the need for system-specific policies and procedures unnecessary. The\
    \ policy can be included as part of the general information security policy for\
    \ organizations or conversely, can be represented by multiple policies reflecting\
    \ the complex nature of certain organizations. The procedures can be established\
    \ for the security program in general and for particular information systems,\
    \ if needed. The organizational risk management strategy is a key factor in establishing\
    \ policy and procedures. Related control: PM-9.\n\nControl Enhancements:  None.\n\
    \nReferences:  NIST Special Publications 800-12, 800-100.\n\nPS-1 (b) (1) [at\
    \ least annually] \nPS-1 (b) (2) [at least annually or whenever a significant\
    \ change occurs]"
  title: >-
    PS-1 - PERSONNEL SECURITY POLICY AND PROCEDURES
  levels:
  - high
  - moderate
  - low
- id: PS-2
  status: pending
  notes: |-
    Section a: The customer will be responsible for assigning risk designations to
    all positions of cusomer personnel using IaaS that are consistent
    with the customers internal policies and procedures. A successful
    control response will need to address the criteria used in risk
    designation assignments (for example, specific responsibilities, access
    to certain types of data, etc.).
    Section b: The customer will be responsible for establishing screening criteria
    for individuals filling positions with access to the information
    system. A successful control response will need to address the rationale
    for each level of screening based on the responsibilities or access
    associated with each risk designation.
    Section c: The customer will be responsible for reviewing and revising risk
    designations at the required frequency. A successful control response
    will need to address the review process, including the role(s)
    responsible for initiating the review process, revising risk
    designations, and providing approval of any changes.
  rules: []
  description: |-
    The organization:
     a. Assigns a risk designation to all organizational positions;
     b. Establishes screening criteria for individuals filling those positions; and
     c. Reviews and updates position risk designations [Assignment: organization-defined frequency].

    Supplemental Guidance:  Position risk designations reflect Office of Personnel Management policy and guidance. Risk designations can guide and inform the types of authorizations individuals receive when accessing organizational information and information systems. Position screening criteria include explicit information security role appointment requirements (e.g., training, security clearances). Related controls: AT-3, PL-2, PS-3.

    Control Enhancements:  None.

    References:  5 C.F.R. 731.106(a).

    PS-2 (c) [at least annually]
  title: >-
    PS-2 - POSITION RISK DESIGNATION
  levels:
  - high
  - moderate
  - low
- id: PS-3
  status: pending
  notes: |-
    Section a: The customer will be responsible for screening individuals prior to
    authorizing access. A successful control response will need to
    demonstrate alignment of the screening as performed to the screening
    requirements established in PS-2.
    Section b: The customer will be responsible for rescreening individuals at the
    required frequency. A successful control response will need to discuss
    the process for iniating rescreening, as well as for disabling or
    removing access if rescreening is not completed in a timely manner.
  rules: []
  description: |-
    The organization:
     a. Screens individuals prior to authorizing access to the information system; and
     b. Rescreens individuals according to [Assignment: organization-defined conditions requiring rescreening and, where rescreening is so indicated, the frequency of such rescreening].

    Supplemental Guidance:  Personnel screening and rescreening activities reflect applicable federal laws, Executive Orders, directives, regulations, policies, standards, guidance, and specific criteria established for the risk designations of assigned positions. Organizations may define different rescreening conditions and frequencies for personnel accessing information systems based on types of information processed, stored, or transmitted by the systems. Related controls: AC-2, IA-4, PE-2, PS-2.

    References: 5 C.F.R. 731.106; FIPS Publications 199, 201; NIST Special Publications 800-60, 800-73, 800-76, 800-78; ICD 704.

    PS-3 (b) [for national security clearances; a reinvestigation is required during the fifth (5th) year for top secret security clearance, the tenth (10th) year for secret security clearance, and fifteenth (15th) year for confidential security clearance.

    For moderate risk law enforcement and high impact public trust level, a reinvestigation is required during the fifth (5th) year.  There is no reinvestigation for other moderate risk positions or any low risk positions]
  title: >-
    PS-3 - PERSONNEL SCREENING
  levels:
  - high
  - moderate
  - low
- id: PS-3(3)
  status: pending
  notes: |-
    The customer will be responsible for ensuring that access to
    information requiring special protection is contingent on additional
    screening as required by the specific nature of that information. A
    successful control response will need to address identifying such
    information and enforcing the additional screening prior to
    authorization of access
  rules: []
  description: "The organization ensures that individuals accessing an information\
    \ system processing, storing, or transmitting information requiring special protection:\n\
    \ (a)   Have valid access authorizations that are demonstrated by assigned official\
    \ government duties; and\n (b)   Satisfy [Assignment: organization-defined additional\
    \ personnel screening criteria].\n\nSupplemental Guidance:  Organizational information\
    \ requiring special protection includes, for example, Controlled Unclassified\
    \ Information (CUI) and Sources and Methods Information (SAMI). Personnel security\
    \ criteria include, for example, position sensitivity background screening requirements.\n\
    \nPS-3 (3) (b) [personnel screening criteria \u2013 as required by specific information]"
  title: >-
    PS-3(3) - PERSONNEL SCREENING | INFORMATION WITH SPECIAL PROTECTION MEASURES
  levels:
  - high
  - moderate
- id: PS-4
  status: pending
  notes: |-
    Section c: The customerw ill be responsible for conducting exit interviews. A
    successful control response will need to address the topics discussed
    during the interviews and the personnel responsible for conducting
    the interviews.
    Section d: The customer will be responsible for retrieving all security related,
    information system related, organizational property from terminated
    indviduals. A successful control response will need to address the
    prcess and personnel responsible for ensuring that all such property
    is retrieved.
    Section e: The customer will be responsible for retaining access to information
    and information systems formerly controlled by terminated individuals. A
    successful control response will need to address how this retention
    occures, personnel responsible for retention, and any minimum or
    maximum retention periods.
    Section f: The customer will be responsible for notifying relevant personnel
    within a defined time period after an individual is terminated. A
    successful control response will need to define the time period and
    personnel who should be notified, as well as discussing the process
    by which notification happens.
  rules: []
  description: |-
    The organization, upon termination of individual employment:
     a. Disables information system access within [Assignment: organization-defined time period];
     b. Terminates/revokes any authenticators/credentials associated with the individual;
     c. Conducts exit interviews that include a discussion of [Assignment: organization-defined information security topics];
     d. Retrieves all security-related organizational information system-related property;
     e. Retains access to organizational information and information systems formerly controlled by terminated individual; and
     f. Notifies [Assignment: organization-defined personnel or roles] within [Assignment: organization-defined time period].

    Supplemental Guidance:  Information system-related property includes, for example, 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 information system-related property. Security topics of interest at exit interviews can include, for example, reminding terminated individuals of nondisclosure agreements and potential limitations on future employment. Exit interviews may not be possible for some terminated individuals, for example, in cases related to job abandonment, illnesses, and nonavailability of supervisors. Exit interviews are important for individuals with security clearances. Timely execution of termination actions is essential for individuals terminated for cause. In certain situations, organizations consider disabling the information system accounts of individuals that are being terminated prior to the individuals being notified. Related controls: AC-2, IA-4, PE-2, PS-5, PS-6.

    References: None.

    PS-4 (a) [eight (8) hours]
  title: >-
    PS-4 - PERSONNEL TERMINATION
  levels:
  - high
  - moderate
  - low
- id: PS-5
  status: pending
  notes: |-
    Section a: The customer will be responsible for reviewing access authorizations
    for individuals when those individuals are reassigned or transferred. A
    successful control response will need to address the intiation of this
    review and individuals or roles responsible for perfoming and validating
    the results of reviews.
    Section b: The customer will be responsible for initiating reassignments or
    transfers within a customer-defined time period after the formal
    reaassignment or transfer. A successful control response will need to
    address the specific ations taken, personnel responsible for those
    actions, and timeframes for initiation of those actions.
    Section c: The customer will be responsible for modifying access authorizations
    based on the results of the review carried out in Part A. A successful
    control response will need to address the process by which
    authorizations are modified, personnel responsible for intiating the
    change, and any technical means of enforcement of the change.
    Section d: The customer will be responsible for notifying relevant personnel
    within the required timeframe after a formal reassignment or transfer. A
    successful control response will need to address the identification of
    interested personnel or roles as well as the means by which notification
    occurs.
  rules: []
  description: "The organization:\n a. Reviews and confirms ongoing operational need\
    \ for current logical and physical access authorizations to information systems/facilities\
    \ when individuals are reassigned or transferred to other positions within the\
    \ organization;\n b. Initiates [Assignment: organization-defined transfer or reassignment\
    \ actions] within [Assignment: organization-defined time period following the\
    \ formal transfer action];\n c. Modifies access authorization as needed to correspond\
    \ with any changes in operational need due to reassignment or transfer; and\n\
    \ d. Notifies [Assignment: organization-defined personnel or roles] within [Assignment:\
    \ organization-defined time period].\n\nSupplemental Guidance:  This control applies\
    \ when reassignments or transfers of individuals are permanent or of such extended\
    \ durations 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, for example: (i) returning old and issuing\
    \ new keys, identification cards, and building passes; (ii) closing information\
    \ system accounts and establishing new accounts; (iii) changing information system\
    \ access authorizations (i.e., privileges); and (iv) providing for access to official\
    \ records to which individuals had access at previous work locations and in previous\
    \ information system accounts. Related controls: AC-2, IA-4, PE-2, PS-4.\n\nControl\
    \ Enhancements:  None.\n\nReferences:  None.\n\nPS-5 (b)-2 [twenty-four (24) hours]\
    \ \nPS-5 (d)-2 [twenty-four (24) hours]"
  title: >-
    PS-5 - PERSONNEL TRANSFER
  levels:
  - high
  - moderate
  - low
- id: PS-6
  status: pending
  notes: |-
    Section a: The customer will be responsible for developing agreements for access
    to the system. A successful control response will need to outline the
    contents of access agreements and the conditions under which they
    are used.
    Section b: The customer will be responsible for reviewing and updating access
    agreements at the required frequency. A successful control response will
    need to address the initiation of the review process, the personnel or
    roles responsible for reviewing and updating the agreement, and the
    process for approval of any changes.
    Section c: The customer will be responsible for ensuring that individuals
    review and sign access agreements prior to initial access and to
    maintain access after updates. A successful control response will need
    to address the process for withholding access until after the initial
    signature is recieved, as well as for disabling or removing access if
    the access agreement changes and an individual does not re-sign it in
    a timely manner.
  rules: []
  description: |-
    The organization:
     a. Develops and documents access agreements for organizational information systems;
     b. Reviews and updates the access agreements [Assignment: organization-defined frequency]; and
     c. Ensures that individuals requiring access to organizational information and information systems:
       1. Sign appropriate access agreements prior to being granted access; and
       2. Re-sign access agreements to maintain access to organizational information systems when access agreements have been updated or [Assignment: organization-defined frequency].

    Supplemental Guidance: Access agreements include, for example, 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 information systems to which access is authorized. Organizations can use electronic signatures to acknowledge access agreements unless specifically prohibited by organizational policy. Related control: PL-4, PS-2, PS-3, PS-4, PS-8.

    References: None.

    PS-6 (b) [at least annually]
    PS-6 (c) (2) [at least annually and any time there is a change to the user's level of access]
  title: >-
    PS-6 - ACCESS AGREEMENTS
  levels:
  - high
  - moderate
  - low
- id: PS-7
  status: pending
  notes: |-
    Section a: The customer will be responsible for establishing personnel security
    requirements for third-party providers. A successful control response
    will need to outline these requirements and address the process
    for notifying third-party providers of the requirements.
    Section b: The customer will be responsible for requiring third-party providers
    to comply with the requirements established in PS-7(a). A successful
    control response will need to address the process for obtaining
    agreement to the requirements and enforcing the requirements.
    Section c: The customer will be responsible for documenting personnel security
    requirements for third-party providers. A successful control response
    will need to discuss the process for creating documentation and sharing
    it with the providers.
    Section d: The customer will be responsible for including nofication of
    terminations and transfers within the personnel security requirements. A
    successful control response will need to discuss the specific
    notification requirements, in particular the requirement for
    notification within the same day.
    Section e: The customer will be responsible for monitoring provider compliance
    with personnel security requirements. A successful control response
    will need to address personnel responsible for monitoring compliance,
    mechanisms used for monitoring, and consequences of non-compliance.
  rules: []
  description: "The organization:\n a. Establishes personnel security requirements\
    \ including security roles and responsibilities for third-party providers;\n b.\
    \ Requires third-party providers to comply with personnel security policies and\
    \ procedures established by the organization;\n c. Documents personnel security\
    \ requirements;\n d. Requires third-party providers to notify [Assignment: organization-defined\
    \ personnel or roles] of any personnel transfers or terminations of third-party\
    \ personnel who possess organizational credentials and/or badges, or who have\
    \ information system privileges within [Assignment: organization-defined time\
    \ period]; and\n e. Monitors provider compliance.\n\nSupplemental Guidance: Third-party\
    \ providers include, for example, service bureaus, contractors, and other organizations\
    \ providing information system development, information technology services, outsourced\
    \ applications, and network and security management. Organizations explicitly\
    \ include personnel security requirements in acquisition-related documents. Third-party\
    \ providers may have personnel working at organizational facilities with credentials,\
    \ badges, or information system privileges issued by organizations. Notifications\
    \ of third-party personnel changes ensure appropriate termination of privileges\
    \ and credentials. Organizations define the transfers and terminations deemed\
    \ reportable by security-related characteristics that include, for example, functions,\
    \ roles, and nature of credentials/privileges associated with individuals transferred\
    \ or terminated. \n\nRelated controls: PS-2, PS-3, PS-4, PS-5, PS-6, SA-9, SA-21.\n\
    \nControl Enhancements:  None.\n\nReferences:  NIST Special Publication 800-35.\n\
    \nPS-7 (d)-2 [terminations: immediately; transfers: within twenty-four (24) hours]"
  title: >-
    PS-7 - THIRD-PARTY PERSONNEL SECURITY
  levels:
  - high
  - moderate
  - low
- id: PS-8
  status: pending
  notes: |-
    Section a: The organization will be responsible for establishing sanctions process
    for non-compliance with policies and procedures. A successful control
    response will need to address different forms of non-compliance and
    specific measures that may be enforced for each.
    Section b: The organization will ne responsible for notifying interested personnel
    when the sanctions process is initiated. A successful control response
    will need to delineate the relevant personnel to be notified, the
    roles or individuals responsible for notification, and the information
    convayed as part of the notification (to include, at a minimum the
    indivual sanctioned and the reason for the sanction).
  rules: []
  description: |-
    The organization:
     a. Employs a formal sanctions process for individuals failing to comply with established information security policies and procedures; and
     b. Notifies [Assignment: organization-defined personnel or roles] within [Assignment: organization-defined time period] when a formal employee sanctions process is initiated, identifying the individual sanctioned and the reason for the sanction.

    Supplemental Guidance: Organizational sanctions processes reflect applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance. Sanctions processes are described in access agreements and can be included as part of general personnel policies and procedures for organizations. Organizations consult with the Office of the General Counsel regarding matters of employee sanctions. Related controls: PL-4, PS-6.

    Control Enhancements:  None.

    References:  None.

    PS-8(b)-1 [at a minimum, the ISSO and/or similar role within the organization]
  title: >-
    PS-8 - PERSONNEL SANCTIONS
  levels:
  - high
  - moderate
  - low
- id: RA-1
  status: pending
  notes: |-
    Section a: The organization will be responsible for developing, documenting, and
    disseminating Risk Assessment policy and procedures. A successful
    control response will need to address the content of the policy
    (which must include purpose, scope, roles, responsibilities,
    management commitment, coordination, and compliance) and procedures
    (which must facilitate the implimentation of the policies and
    associated controls).
    Section b: The organization will be responsible for reviewing and updating the
    Risk Assessment policy every 3 years, and procedures annually. A
    successful control repsonse will need to address the reiew and update
    process, including the role(s) repsonsible for initiating the review
    process, updating the policy and procedures, and providing approval
    of the updates.
  rules: []
  description: "The organization:\n a. Develops, documents, and disseminates to [Assignment:\
    \ organization-defined personnel or roles]:\n   1. A risk assessment policy that\
    \ addresses purpose, scope, roles, responsibilities, management commitment, coordination\
    \ among organizational entities, and compliance; and\n   2. Procedures to facilitate\
    \ the implementation of the risk assessment policy and associated risk assessment\
    \ controls; and\n b. Reviews and updates the current:\n   1. Risk assessment policy\
    \ [Assignment: organization-defined frequency]; and\n   2. Risk assessment procedures\
    \ [Assignment: organization-defined frequency].\n\nSupplemental Guidance:  This\
    \ control addresses the establishment of policy and procedures for the effective\
    \ implementation of selected security controls and control enhancements in the\
    \ RA family. Policy and procedures reflect applicable federal laws, Executive\
    \ Orders, directives, regulations, policies, standards, and guidance. Security\
    \ program policies and procedures at the organization level may make the need\
    \ for system-specific policies and procedures unnecessary. The policy can be included\
    \ as part of the general information security policy for organizations or conversely,\
    \ can be represented by multiple policies reflecting the complex nature of certain\
    \ organizations. The procedures can be established for the security program in\
    \ general and for particular information systems, if needed. The organizational\
    \ risk management strategy is a key factor in establishing policy and procedures.\
    \ Related control: PM-9.\n\nControl Enhancements:  None.\n\nReferences:  NIST\
    \ Special Publications 800-12, 800-30, 800-100.\n\nRA-1 (b) (1) [at least annually]\
    \ \nRA-1 (b) (2) [at least annually or whenever a significant change occurs]"
  title: >-
    RA-1 - RISK ASSESSMENT POLICY AND PROCEDURES
  levels:
  - high
  - moderate
  - low
- id: RA-2
  status: pending
  notes: |-
    Section a: The customer will be responsible for categorizing the customer
    system and information contained within it. A successful control
    response will need to address the applicable Federal Laws, Executive
    Orders, directives, policies, regulations, standards, and guidance, as
    well as the key stakeholders involved in the categorization decision.

    Resources related to information categorization include FIPS 199,
    Standards for Security Categorization of Federal Information and
    Information Systems, and NIST SP 800-61, Rev. 1, Guide for Mapping
    Types of Information and Inforation Systems to Security Categories.
    Section b: The customer will be responsible for documenting the security
    categorization. A successful response will need to address supporting
    rationale, including types of information considered, risk impact
    analysis, and input from stakeholders and organizational officials.
    Section c: The customer will be responsible for presneting the security
    categorization decision to the Authorizing Official or a
    designated representative for review and approval.
  rules: []
  description: |-
    The organization:
     a. Categorizes information and the information system in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance;
     b. Documents the security categorization results (including supporting rationale) in the security plan for the information system; and
     c. Ensures that the security categorization decision is reviewed and approved by the authorizing official or authorizing official designated representative.

    Supplemental Guidance:  Clearly defined authorization boundaries are a prerequisite for effective security categorization decisions. Security categories describe the potential adverse impacts to organizational operations, organizational assets, and individuals if organizational information and information systems are comprised through a loss of confidentiality, integrity, or availability. Organizations conduct the security categorization process as an organization-wide activity with the involvement of chief information officers, senior information security officers, information system owners, mission/business owners, and information owners/stewards. Organizations also consider the potential adverse impacts to other organizations and, in accordance with the USA PATRIOT Act of 2001 and Homeland Security Presidential Directives, potential national-level adverse impacts. Security categorization processes carried out by organizations facilitate the development of inventories of information assets, and along with CM-8, mappings to specific information system components where information is processed, stored, or transmitted. Related controls: CM-8, MP-4, RA-3, SC-7.

    Control Enhancements:  None.

    References:  FIPS Publication 199; NIST Special Publications 800-30, 800-39, 800-60.
  title: >-
    RA-2 - SECURITY CATEGORIZATION
  levels:
  - high
  - moderate
  - low
- id: RA-3
  status: pending
  notes: |-
    Section a: The customer will be responsible for conducting a risk assessment,
    including a review of controls inherited from infrastruture providers,
    and for those which the customer is responsible. A successful control
    response will need to address the assessment methodology and calculation
    of the likelihood and magnitude of harm that could result from
    unauthorized access, use, disclosure, disruption, or modification of
    IaaS layers, the customer application, and the information processed,
    stored, and transmitted by those systems.

    NIST SP 80-30 Rev. 1, Guide for Conducting Risk Assessments, and NIST
    SP 800-53A Rev. 4, Assessing Security and Privacy Controls in Federal
    Information Systems and Organizations: Building Effective Assessment
    Plans both provide guidance that may be used by the customer in
    developing the risk assessment methodology and performing the risk
    assessment.
    Section b: The customer will be responsible for documenting the results of the
    risk assessment in a Security Assessment Report. A successful control
    response will need to address specific requirements for the report
    (e.g., it should include controls that are considered "other than
    satisfied," potential weaknesses in control sthat meet minimum
    requirements, recommended remediation steps, and risks associated with
    the system). The customer may with to employ a 3PAO to assist with
    the initial risk assessment (see CA-2).
    Section c: The customer will be responsible for reviewing risk assessment results
    at the required frequency. A successful control response will need to
    address the personnel or roles responsible for reviewing results, as
    well as any actions taken in response to risk assessment results.
    Section d: The customer will be responsible for disseminating risk assessment
    results to customer-defined stakeholders and organizational officials. A
    successful control response will need to outline the stakeholders
    involved and the means of distribution of results.
    Section e: The customer will be responsible for updating the risk assessment
    at the required frequency of when a significant change occurs. (Note
    that "significant change" is defined in NIST 800-37 Rev 1, Appendix F).
    A successful control respinse will need to discuss examples of
    significant changes that might occur within the customer application,
    as well as the specific actions that will be taken when the risk
    assessment is updated (such as updating system security plans and
    other documentation).
  rules: []
  description: "The organization:\n a. Conducts an assessment of risk, including the\
    \ likelihood and magnitude of harm, from the unauthorized access, use, disclosure,\
    \ disruption, modification, or destruction of the information system and the information\
    \ it processes, stores, or transmits;\n b. Documents risk assessment results in\
    \ [Selection: security plan; risk assessment report; [Assignment: organization-defined\
    \ document]];\n c. Reviews risk assessment results [Assignment: organization-defined\
    \ frequency];\n d. Disseminates risk assessment results to [Assignment: organization-defined\
    \ personnel or roles]; and\n e. Updates the risk assessment [Assignment: organization-defined\
    \ frequency] or whenever there are significant changes to the information system\
    \ or environment of operation (including the identification of new threats and\
    \ vulnerabilities), or other conditions that may impact the security state of\
    \ the system.\n\nSupplemental Guidance:  Clearly defined authorization boundaries\
    \ are a prerequisite for effective risk assessments. Risk assessments take into\
    \ account threats, vulnerabilities, likelihood, and impact to organizational operations\
    \ and assets, individuals, other organizations, and the Nation based on the operation\
    \ and use of information systems. Risk assessments also take into account risk\
    \ from external parties (e.g., service providers, contractors operating information\
    \ systems on behalf of the organization, individuals accessing organizational\
    \ information systems, outsourcing\nentities). In accordance with OMB policy and\
    \ related E-authentication initiatives, authentication of public users accessing\
    \ federal information systems may also be required to protect nonpublic or privacy-related\
    \ information. As such, organizational assessments of risk also address public\
    \ access to federal information systems.\n\nRisk assessments (either formal or\
    \ informal) can be conducted at all three tiers in the risk management hierarchy\
    \ (i.e., organization level, mission/business process level, or information system\
    \ level) and at any phase in the system development life cycle. Risk assessments\
    \ can also be conducted at various steps in the Risk Management Framework, including\
    \ categorization, security control selection, security control implementation,\
    \ security control assessment, information\nsystem authorization, and security\
    \ control monitoring. RA-3 is noteworthy in that the control must be partially\
    \ implemented prior to the implementation of other controls in order to complete\
    \ the\nfirst two steps in the Risk Management Framework. Risk assessments can\
    \ play an important role in security control selection processes, particularly\
    \ during the application of tailoring guidance, which includes security control\
    \ supplementation. Related controls: RA-2, PM-9.\n\nControl Enhancements: None.\n\
    \nReferences:  OMB Memorandum 04-04; NIST Special Publication 800-30, 800-39;\
    \ Web:idmanagement.gov.\n\nRA-3 (b) [security assessment report]\n \nRA-3 (c)\
    \ [at least annually or whenever a significant change occurs]\n \nRA-3 (e) [annually]\
    \  \nRA-3 Guidance: Significant change is defined in NIST Special Publication\
    \ 800-37 Revision 1, Appendix F.\nRA-3 (d) Requirement: Include all Authorizing\
    \ Officials; for JAB authorizations to include FedRAMP."
  title: >-
    RA-3 - RISK ASSESSMENT
  levels:
  - high
  - moderate
  - low
- id: RA-5
  status: pending
  notes: |-
    Section a: The customer will be responsible for scanning for vulnerabilities
    in customer applications and databases. Additionally, IaaS customers
    using an operating system image will be responsible for scanning
    for vulnerabilities in the operating system. A successful control
    response will need to address the tools used to perform scans as well
    as the additional FedRAMP requirement for independant assessors to
    scan the system on an annual basis.
    Section b: The customer will be responsible for ensuring that vulnerability
    scanning tools use standards for enumerating components, flaws, and
    improper configurations; formatting checklists and test procedures;
    and measuring vulnerability impact. A successful control response will
    need to address how each vulnerability scanning tool in use meets these
    requirements (for example, by using Common Vulnerabilities and
    Exposures (CVE) values).
    Section c: The customer will be responsible for analyzing scan reports and
    assessment results for actionable data. A successful control response
    will need to address the roles or personnel responsible for the
    analysis, as well as criteria used in performing the analysis.
    Section e: The customer will be responsible for sharing vulnerability scan
    results and security assessment reports with customer-defined
    stakeholders. A successful control response will need to address the
    stakeholders involved and the types of information shared with
    each stakeholder.
  rules: []
  description: "The organization:\n a. Scans for vulnerabilities in the information\
    \ system and hosted applications [Assignment: organization-defined frequency and/or\
    \ randomly in accordance with organization-defined process] and when new vulnerabilities\
    \ potentially affecting the system/applications are identified and reported;\n\
    \ b. Employs vulnerability scanning tools and techniques that facilitate interoperability\
    \ among tools and automate parts of the vulnerability management process by using\
    \ standards for:\n   1. Enumerating platforms, software flaws, and improper configurations;\n\
    \   2. Formatting checklists and test procedures; and\n   3. Measuring vulnerability\
    \ impact;\n c. Analyzes vulnerability scan reports and results from security control\
    \ assessments;\n d. Remediates legitimate vulnerabilities [Assignment: organization-defined\
    \ response times], in accordance with an organizational assessment of risk; and\n\
    \ e. Shares information obtained from the vulnerability scanning process and security\
    \ control assessments with [Assignment: organization-defined personnel or roles]\
    \ to help eliminate similar vulnerabilities in other information systems (i.e.,\
    \ systemic weaknesses or deficiencies).\n\nSupplemental Guidance:  Security categorization\
    \ of information systems guides the frequency and comprehensiveness of vulnerability\
    \ scans. Organizations determine the required vulnerability scanning for all information\
    \ system components, ensuring that potential sources of vulnerabilities such as\
    \ networked printers, scanners, and copiers are not overlooked. Vulnerability\
    \ analyses for custom software applications may require additional approaches\
    \ such as static analysis, dynamic analysis, binary analysis, or a hybrid of the\
    \ three approaches. Organizations can employ these analysis approaches in a variety\
    \ of tools (e.g., web-based application scanners, static analysis tools, binary\
    \ analyzers) and in source code reviews. Vulnerability scanning includes, for\
    \ example: (i) scanning for patch levels; (ii) scanning for functions, ports,\
    \ protocols, and services that should not be accessible to users or devices; and\
    \ (iii) scanning for improperly configured or incorrectly operating information\
    \ flow control mechanisms. Organizations consider using tools that express vulnerabilities\
    \ in the Common Vulnerabilities and Exposures (CVE) naming convention and that\
    \ use the Open Vulnerability Assessment Language (OVAL) to determine/test for\
    \ the presence of vulnerabilities. Suggested sources for vulnerability information\
    \ include the Common Weakness Enumeration (CWE) listing and the National Vulnerability\
    \ Database (NVD). In addition, security control assessments such as red team exercises\
    \ provide other sources of potential vulnerabilities for which to scan. Organizations\
    \ also consider using tools that express vulnerability impact by the\n\nCommon\
    \ Vulnerability Scoring System (CVSS). Related controls: CA-2, CA-7, CM-4, CM-6,\
    \ RA-2, RA-3, SA-11, SI-2.\n\nReferences: NIST Special Publications 800-40, 800-70,\
    \ 800-115; Web: http://cwe.mitre.org, http://nvd.nist.gov.\n\nRA-5 (a) [monthly\
    \ operating system/infrastructure; monthly web applications and databases]\nRA-5\
    \ (d) [high-risk vulnerabilities mitigated within thirty (30) days from date of\
    \ discovery; moderate-risk vulnerabilities mitigated within ninety (90) days from\
    \ date of discovery; low risk vulnerabilities mitigated within one hundred and\
    \ eighty (180) days from date of discovery]\nRA-5 Guidance: See the FedRAMP Documents\
    \ page under Key Cloud Service Provider (CSP) Documents> Vulnerability Scanning\
    \ Requirements \nhttps://www.FedRAMP.gov/documents/\nRA-5 (a) Requirement: an\
    \ accredited independent assessor scans operating systems/infrastructure, web\
    \ applications, and databases once annually.\nRA-5 (e) Requirement: to include\
    \ all Authorizing Officials; for JAB authorizations to include FedRAMP"
  title: >-
    RA-5 - VULNERABILITY SCANNING
  levels:
  - high
  - moderate
  - low
- id: RA-5(1)
  status: pending
  notes: |-
    The customer will be responsible for scanning customer applications
    and customer-deployed operating system images using compliant
    vulnerability scanning tools. A successful control response will need
    to address the specific tools used and the process required to
    update the list of information system vulnerabilities to be scanned
    for each.
  rules: []
  description: |-
    The organization employs vulnerability scanning tools that include the capability to readily update the information system vulnerabilities to be scanned.

    Supplemental Guidance:  The vulnerabilities to be scanned need to be readily updated as new vulnerabilities are discovered, announced, and scanning methods developed. This updating process helps to ensure that potential vulnerabilities in the information system are identified and addressed as quickly as possible. Related controls: SI-3, SI-7.
  title: >-
    RA-5(1) - VULNERABILITY SCANNING | UPDATE TOOL CAPABILITY
  levels:
  - high
  - moderate
- id: RA-5(2)
  status: pending
  notes: |-
    The customer will be responsible for updating the list of
    vulnerabilities scanner prior to each scan. A successful control
    response will need to address the roles or personnel responsible for
    ensuring that this requirement is met, as well as the process for
    initiating a new scan if the required update does not occur.
  rules: []
  description: |-
    The organization updates the information system vulnerabilities scanned [Selection (one or more): [Assignment: organization-defined frequency]; prior to a new scan; when new vulnerabilities are identified and reported].

    Supplemental Guidance:  Related controls: SI-3, SI-5.

    RA-5 (2) [prior to a new scan]
  title: >-
    RA-5(2) - VULNERABILITY SCANNING | UPDATE BY FREQUENCY / PRIOR TO NEW SCAN / WHEN
    IDENTIFIED
  levels:
  - high
  - moderate
- id: RA-5(3)
  status: pending
  notes: |-
    The customer will be responsible for ensuring that vulnerability
    scanning tools and procedures demonstrate the breadth and depth of
    coverage. A successful control response will need to address the
    specific tools in use and discuss the reason each tool is felt to
    provide sufficient breadth and depth of coverage.
  rules: []
  description: |-
    The organization employs vulnerability scanning procedures that can identify the breadth and depth of coverage (i.e., information system components scanned and vulnerabilities checked).
  title: >-
    RA-5(3) - VULNERABILITY SCANNING | BREADTH / DEPTH OF COVERAGE
  levels:
  - high
  - moderate
- id: RA-5(5)
  status: pending
  notes: |-
    The customer will be responsible for ensuring that scans of the
    customer environment include privileged access authorizations. A
    successful control response will need to address how privileged
    access authorizations are configured, as well as how successful
    authorization is validated during the analysis of scan results.
  rules: []
  description: "The information system implements privileged access authorization\
    \ to [Assignment: organization- identified information system components] for\
    \ selected [Assignment: organization-defined vulnerability scanning activities].\n\
    \nSupplemental Guidance:  In certain situations, the nature of the vulnerability\
    \ scanning may be more intrusive or the information system component that is the\
    \ subject of the scanning may contain highly sensitive information. Privileged\
    \ access authorization to selected system components facilitates more thorough\
    \ vulnerability scanning and also protects the sensitive nature of such scanning.\n\
    \nRA-5 (5)-1 [operating systems / web applications / databases] \nRA-5 (5)-2 [all\
    \ scans]"
  title: >-
    RA-5(5) - VULNERABILITY SCANNING | PRIVILEGED ACCESS
  levels:
  - high
  - moderate
- id: RA-5(6)
  status: pending
  notes: |-
    The customer will be responsible for using automated mechanisms to
    analyze vulnerability scan results over time to determine trends. A
    successful control response will need to discuss the mechanisms in use
    and the metrics employed in scan result analysis.
  rules: []
  description: |-
    The organization employs automated mechanisms to compare the results of vulnerability scans over time to determine trends in information system vulnerabilities.

    Supplemental Guidance:  Related controls: IR-4, IR-5, SI-4.

    RA-5 (6) Guidance: include in Continuous Monitoring ISSO digest/report to JAB/AO
  title: >-
    RA-5(6) - VULNERABILITY SCANNING | AUTOMATED TREND ANALYSES
  levels:
  - high
  - moderate
- id: RA-5(8)
  status: pending
  notes: |-
    The customer will be responsible for reviewing historic audit logs to
    determine if a vulnerability identified in the information system
    has been previously exploited. A successful control response will need
    to address the criteria used in analysis of audit logs to correlate log
    data with vulnerability scan results.
  rules: []
  description: "The organization reviews historic audit logs to determine if a vulnerability\
    \ identified in the information system has been previously exploited.\n\nSupplemental\
    \ Guidance:  Related control: AU-6.\n\nRA-5 (8) Requirements: This enhancement\
    \ is required for all high vulnerability scan findings. \nGuidance: While scanning\
    \ tools may label findings as high or critical, the intent of the control is based\
    \ around NIST's definition of high vulnerability."
  title: >-
    RA-5(8) - VULNERABILITY SCANNING | REVIEW HISTORIC AUDIT LOGS
  levels:
  - high
  - moderate
- id: SA-1
  status: pending
  notes: |-
    Section a: The organization will be responsible for developing, documenting, and
    disseminating System and Services Aquisition policy and procedures. A
    successful control response will need to address the content of the
    policy (which must include purpose, scope, roles, responsibilities,
    management commitment, coordination, and compliance) and procedures
    (which must facilitate the implementation of the policies and
    associated controls).
    Section b: The organization will be responsible for reviewing and updating the Audit
    and Accountability policy every 3 years, and procedures annualy. A
    successful control response will need to address the review and update
    process, including the role(s) responsible for initiating the review
    process, updating the policy and procedures, and providing approval
    of the updates.
  rules: []
  description: |-
    The organization:
     a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:
       1. A system and services acquisition policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and
       2. Procedures to facilitate the implementation of the system and services acquisition policy and associated system and services acquisition controls; and
     b. Reviews and updates the current:
       1. System and services acquisition policy [Assignment: organization-defined frequency]; and
       2.  System and services acquisition procedures [Assignment: organization-defined frequency].

    Supplemental Guidance:  This control addresses the establishment of policy and procedures for the effective implementation of selected security controls and control enhancements in the SA family. Policy and procedures reflect applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance. Security program policies and procedures at the organization level may make the need for system-specific policies and procedures unnecessary. The policy can be included as part of the general information security policy for organizations or conversely, can be represented by multiple policies reflecting the complex nature of certain organizations. The procedures can be established for the security program in general and for particular information systems, if needed. The organizational risk management strategy is a key factor in establishing policy and procedures. Related control: PM-9.

    Control Enhancements:  None.

    References:  NIST Special Publications 800-12, 800-100.

    SA-1 (b) (1)  [at least annually]
    SA-1 (b) (2)  [at least annually or whenever a significant change occurs]
  title: >-
    SA-1 - SYSTEM AND SERVICES ACQUISITION POLICY AND

    PROCEDURES
  levels:
  - high
  - moderate
  - low
- id: SA-2
  status: pending
  notes: |-
    Section a: The customer will be responsible for determining information security
    requirements during mission/business process planning. A successful
    control response will indicate how information security has been
    integrated into mission/business planning.
    Section b: The customer will be responsible for determining, documenting, and
    allocating the resources required to protect the information system
    as part of capital planning and investment control processes. A
    successful control response will indicate how information security
    has been incorporated into financial planning processes.
    Section c: The customer will be responsible for establishing a discrete line
    item for information security in organizational programming and
    budgeting documentation. A successful control response will indicate
    how information security is a stand-alone practice within the
    organization.
  rules: []
  description: "The organization:\n a. Determines information security requirements\
    \ for the information system or information system service in mission/business\
    \ process planning;\n b. Determines, documents, and allocates the resources required\
    \ to protect the information system or information system service as part of its\
    \ capital planning and investment control process; and\n c. Establishes a discrete\
    \ line item for information security in organizational programming and budgeting\
    \ documentation.\n\nSupplemental Guidance:  Resource allocation for information\
    \ security includes funding for the initial information system or information\
    \ system service acquisition and funding for the sustainment of the system/service.\
    \ Related controls: PM-3, PM-11.\n\nControl Enhancements:  None.\n \nReferences:\
    \  NIST Special Publication 800-65."
  title: >-
    SA-2 - ALLOCATION OF RESOURCES
  levels:
  - high
  - moderate
  - low
- id: SA-3
  status: pending
  notes: |-
    Section a: The customer will be responsible for managing the information system
    using a Secure Development Lifecycle that incorporates information
    security considerations. A successful control response will indicate
    how information security requirements are part of project management
    plans.
    Section b: The customer will be responsible for defining and documenting
    information security roles and responsibilities throughout the
    system development lifecycle. A successful control response will
    indicate how information security roles are kept current during all
    stages of the information systems lifecycle.
    Section c: The customer will be responsible for identifying individuals
    that have information security roles and responsibilities. A successful
    control response will document these individuals, their
    responsibilities, and how the organization keeps current this
    information.
    Section d: The customer will be responsible for integrating the organizational
    information security risk management process into system lifecycle. A
    successful control response indicates how the organization follows the
    NIST Risk Management Framework, or an agency-specific derivative.
  rules: []
  description: |-
    The organization:
     a. Manages the information system using [Assignment: organization-defined system development life cycle] that incorporates information security considerations;
     b. Defines and documents information security roles and responsibilities throughout the system development life cycle;
     c. Identifies individuals having information security roles and responsibilities; and
     d. Integrates the organizational information security risk management process into system development life cycle activities.

    Supplemental Guidance:  A well-defined system development life cycle provides the foundation for the successful development, implementation, and operation of organizational information systems. To apply the required security controls within the system development life cycle requires a basic understanding of information security, threats, vulnerabilities, adverse impacts, and risk to critical missions/business functions. The security engineering principles in SA-8 cannot be properly applied if individuals that design, code, and test information systems and system components (including information technology products) do not understand security. Therefore, organizations include qualified personnel, for example, chief information security officers, security architects, security engineers, and information system security officers in system development life cycle activities to ensure that security requirements are incorporated into organizational information systems. It is equally important that developers include individuals on the development team that possess the requisite security expertise and skills to ensure that needed security capabilities are effectively integrated into the information system. Security awareness and training programs can help ensure that individuals having key security roles and responsibilities have the appropriate experience, skills, and expertise to conduct assigned system development life cycle activities. The effective integration of security requirements into enterprise architecture also helps to ensure that important security considerations are addressed early in the system development life cycle and that those considerations are directly related to the organizational mission/business processes. This process also facilitates the integration of the information security architecture into the enterprise architecture, consistent with organizational risk management and information security strategies. Related controls: AT-3, PM-7, SA-8.

    Control Enhancements:  None.

    References:  NIST Special Publications 800-37, 800-64.
  title: >-
    SA-3 - SYSTEM DEVELOPMENT LIFE CYCLE
  levels:
  - high
  - moderate
  - low
- id: SA-4
  status: pending
  notes: |-
    Section a: The customer will be responsible for including security functional
    requirements in acquisition contracts. A successful control response
    will need to address consideration of applicable federal laws,
    Executive Orders, directives, policies, regulations, standards,
    guidelines, and organizational mission/business needs in the creation
    of the contracts.
    Section b: The customer will be responsible for including security strength
    requirements in acquisition contracts. A successful control response
    will need to address consideration of applicable federal laws,
    Executive Orders, directives, policies, regulations, standards,
    guidelines, and organizational mission/business needs in the creation
    of the contracts.
    Section c: The customer will be responsible for including security assurance
    requirements in acquisition contracts. A successful control response
    will need to address consideration of applicable federal laws,
    Executive Orders, directives, policies, regulations, standards,
    guidelines, and organizational mission/business needs in the creation
    of the contracts.
    Section d: The customer will be responsible for including security-related
    documentation requirements in acquistion contracts. A successful control
    response will need to address consideration of applicable laws,
    Executive Orders, directives, policies, regulations, standards,
    guidelines, and organizational mission/business needs in the creation
    of the contracts.
    Section e: The customer will be responsible for including requirements for
    protecting security-related documentation in acqusition contracts. A
    successful control response will need to address consideration of
    applicable laws, Executive Orders, directives, policies, regulations,
    standards, guidelines, and organizational mission/business needs in the
    creation of the contracts.
    Section f: The customer will be responsible for including a description of the
    information system development environment and in which the system
    is intended to operate in acquisition contracts. A successful control
    response will need to address consideration of applicable federal laws,
    Executive Orders, directives, policies, regulations, standards,
    guidelines, and organizational mission/business needs in the creation
    of the contracts.
    Section g: The customer will be responsible for including acceptance criteria
    in acquisition contracts. A successful control response will need to
    address consideration of applicable federal laws, Executive Orders,
    directives, policies, regulations, standards, guidelines, and
    organizational mission/business needs in the creation of the
    contracts.
  rules: []
  description: |-
    The organization includes the following requirements, descriptions, and criteria, explicitly or by reference, in the acquisition contract for the information system, system component, or information system service in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, standards, guidelines, and organizational mission/business needs:
      a. Security functional requirements;
     b. Security strength requirements;
     c. Security assurance requirements;
     d. Security-related documentation requirements;
     e. Requirements for protecting security-related documentation;
     f. Description of the information system development environment and environment in which the system is intended to operate; and
     g. Acceptance criteria.

    Supplemental Guidance:  Information system components are discrete, identifiable information technology assets (e.g., hardware, software, or firmware) that represent the building blocks of an information system. Information system components include commercial information technology products. Security functional requirements include security capabilities, security functions, and security mechanisms. Security strength requirements associated with such capabilities, functions, and mechanisms include degree of correctness, completeness, resistance to direct attack, and resistance to tampering or bypass. Security assurance requirements include: (i) development processes, procedures, practices, and methodologies; and (ii) evidence from development and assessment activities providing grounds for confidence that the required security functionality has been implemented and the required security strength has been achieved. Security documentation requirements address all phases of the system development life cycle.

    Security functionality, assurance, and documentation requirements are expressed in terms of security controls and control enhancements that have been selected through the tailoring process. The security control tailoring process includes, for example, the specification of parameter values through the use of assignment and selection statements and the specification of platform dependencies and implementation information. Security documentation provides user and administrator guidance regarding the implementation and operation of security controls. The level of detail required in security documentation is based on the security category or classification level of the information system and the degree to which organizations depend on the stated security capability, functions, or mechanisms to meet overall risk response expectations (as defined in the organizational risk management strategy). Security requirements can also include organizationally mandated configuration settings specifying allowed functions, ports, protocols, and services. Acceptance criteria for information systems, information system components, and information system services are defined in the same manner as such criteria for any organizational acquisition or procurement. The Federal Acquisition Regulation (FAR) Section 7.103 contains information security requirements from FISMA. Related controls: CM-6, PL-2, PS-7, SA-3, SA-5, SA-8, SA-11, SA-12.

    References: HSPD-12; ISO/IEC 15408; FIPS Publications 140-2, 201; NIST Special Publications 800-23, 800-35, 800-36, 800-37, 800-64, 800-70, 800-137; Federal Acquisition Regulation; Web: http://www.niap-ccevs.org, http://fips201ep.cio.gov, http://www.acquisition.gov/far.

    SA-4 Requirement: The service provider must comply with Federal Acquisition Regulation (FAR) Subpart 7.103, and Section 889 of the John S. McCain National Defense Authorization Act (NDAA) for Fiscal Year 2019 (Pub. L. 115-232), and FAR Subpart 4.21, which implements Section 889 (as well as any added updates related to FISMA to address security concerns in the system acquisitions process).

    SA-4 Guidance: The use of Common Criteria (ISO/IEC 15408) evaluated products is strongly preferred.
    See https://www.niap-ccevs.org/Product/
  title: >-
    SA-4 - ACQUISITION PROCESS
  levels:
  - high
  - moderate
  - low
- id: SA-4(1)
  status: pending
  notes: |-
    The customer will be responsible for requiring the developer of
    the information system to provide a description of the functional
    properties of the security controls to be employed. A successful
    control response will address how this requirement is built into
    procurement language.
  rules: []
  description: |-
    The organization requires the developer of the information system, system component, or information system service to provide a description of the functional properties of the security controls to be employed.

    Supplemental Guidance:  Functional properties of security controls describe the functionality (i.e., security 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. Related control: SA-5.
  title: >-
    SA-4(1) - ACQUISITION PROCESS | FUNCTIONAL PROPERTIES OF SECURITY CONTROLS
  levels:
  - high
  - moderate
- id: SA-4(2)
  status: pending
  notes: |-
    The customer will be responsible for requiring the developer of the
    information system to provide design and implementation information
    for the security controls to be employed that includes security-relevant
    external interfaces and high-level design. This information must be
    at a level of detail sufficient for secure deployment. A successful
    control response will indicate address how this requirement is built
    into procurement language.
  rules: []
  description: |-
    The organization requires the developer of the information system, system component, or information system service to provide design and implementation information for the security controls to be employed that includes: [Selection (one or more): security-relevant external system interfaces; high-level design; low-level design; source code or hardware schematics; [Assignment: organization-defined design/implementation information]] at [Assignment: organization-defined level of detail].

    Supplemental Guidance:  Organizations may require different levels of detail in design and implementation documentation for security controls employed in organizational information systems, system components, or information system services based on mission/business requirements, requirements for trustworthiness/resiliency, and requirements for analysis and testing. Information 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 multiple subsystems and the interfaces between subsystems providing security-relevant functionality. The low-level design for the system is expressed in terms of modules with particular emphasis on software and firmware (but not excluding hardware) and the interfaces between modules providing security-relevant functionality. Source code and hardware schematics are typically referred to as the implementation representation of the information system. Related control: SA-5.

    SA-4 (2)-1 [at a minimum to include security-relevant external system interfaces; high-level design; low-level design; source code or network and data flow diagram; [organization-defined design/implementation information]]
  title: >-
    SA-4(2) - ACQUISITION PROCESS | DESIGN / IMPLEMENTATION INFORMATION FOR SECURITY
    CONTROLS
  levels:
  - high
  - moderate
- id: SA-4(8)
  status: pending
  notes: |-
    Customers are responsible for requiring the developer of
    customer-controlled software and operating systems to produce a plan
    for continuous monitoring of security control effectiveness. A
    successful control response will discuss the level of detail required
    by the customer as part of these continuous monitoring activities.
  rules: []
  description: |-
    The organization requires the developer of the information system, system component, or information system service to produce a plan for the continuous monitoring of security control effectiveness that contains [Assignment: organization-defined level of detail].

    Supplemental Guidance:  The objective of continuous monitoring plans is to determine if the complete set of planned, required, and deployed security controls within the information system, system component, or information system service continue to be effective over time based on the inevitable changes that occur. Developer continuous monitoring plans include a sufficient level of detail such that the information can be incorporated into the continuous monitoring strategies and programs implemented by organizations. Related control: CA-7.

    SA-4 (8) [at least the minimum requirement as defined in control CA-7]
    SA-4 (8) Guidance: CSP must use the same security standards regardless of where the system component or information system service is acquired.
  title: >-
    SA-4(8) - ACQUISITION PROCESS | CONTINUOUS MONITORING PLAN
  levels:
  - high
  - moderate
- id: SA-4(9)
  status: pending
  notes: |-
    Customers are responsible for requiring the developer of
    customer-controlled software and operating systems to identify required
    ports, protocols, services and functions early in the development
    process. A successful control response will address the process by
    which this requirement is enforced.
  rules: []
  description: |-
    The organization requires the developer of the information system, system component, or information system service to identify early in the system development life cycle, the functions, ports, protocols, and services intended for organizational use.

    Supplemental Guidance:  The identification of functions, ports, protocols, and services early in the system development life cycle (e.g., during the initial requirements definition and design phases) allows organizations to influence the design of the information system, information system component, or information system service. This early involvement in the life cycle helps organizations to 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 when requiring information system service providers to do so). Early identification of functions, ports, protocols, and services avoids costly retrofitting of security controls after the information system, system component, or information system service has been implemented. SA-9 describes requirements for external information system services with organizations identifying which functions, ports, protocols, and services are provided from external sources. Related controls: CM-7, SA-9.
  title: >-
    SA-4(9) - ACQUISITION PROCESS | FUNCTIONS / PORTS / PROTOCOLS / SERVICES IN USE
  levels:
  - high
  - moderate
- id: SA-4(10)
  status: pending
  notes: |-
    The customer is responsible for employing only information
    technology products on the FIPS 201-approved products list for
    Personal Identity Vertification (PIV) capability implemented within
    organizational information systems. A successful control response will
    indicate that all system components have been selected from this list,
    and if not, document waivers with appropriate organizational authorities
    signature.
  rules: []
  description: |-
    The organization employs only information technology products on the FIPS 201-approved products list for Personal Identity Verification (PIV) capability implemented within organizational information systems.

    Supplemental Guidance:  Related controls: IA-2; IA-8.
  title: >-
    SA-4(10) - ACQUISITION PROCESS | USE OF APPROVED PIV PRODUCTS
  levels:
  - high
  - moderate
- id: SA-5
  status: pending
  notes: |-
    Section a: Customers are responsible for obtaining administrator documentation
    for customer-controlled software and operating systems. A successful
    control response will address the specific content requirements
    outlined in the control
    Section b: Customers are responsible for obtaining user documentation for
    customer-controlled software and operating systems. A successful control
    response will address the specific content requirements outlined in
    the control.
    Section c: Customers are responsible for documenting attempts to obtain
    administrator and user documentation for customer-controlled software
    and operating systems if that documentation is not available. A
    successful control response will discuss the process by which attempts
    to obtain documentation are made as well as any additional actions
    taken.
    Section d: Customers are responsible for protecting administrator and user
    documentation for customer-controlled software and operating systems.
    A successful control response will discuss how the safeguards are used
    in accordance with the organizations risk management strategy.
    Section e: Customers are responsible for distributing documentation for
    customer-controlled software and operating systems to appropriate
    personnel. A successful control response will discuss the means
    of distribution and the process for designating appropraite personnel
    or roles.
  rules: []
  description: "The organization:\n a. Obtains administrator documentation for the\
    \ information system, system component, or information system service that describes:\n\
    \   1. Secure configuration, installation, and operation of the system, component,\
    \ or service;\n   2. Effective use and maintenance of security functions/mechanisms;\
    \ and\n   3. Known vulnerabilities regarding configuration and use of administrative\
    \ (i.e., privileged) functions;\n b. Obtains user documentation for the information\
    \ system, system component, or information system service that describes:\n  \
    \ 1. User-accessible security functions/mechanisms and how to effectively use\
    \ those security functions/mechanisms;\n   2. Methods for user interaction, which\
    \ enables individuals to use the system, component, or service in a more secure\
    \ manner; and\n   3. User responsibilities in maintaining the security of the\
    \ system, component, or service;\n c. Documents attempts to obtain information\
    \ system, system component, or information system service documentation when such\
    \ documentation is either unavailable or nonexistent and [Assignment: organization-defined\
    \ actions] in response;\n d. Protects documentation as required, in accordance\
    \ with the risk management strategy; and e. Distributes documentation to [Assignment:\
    \ organization-defined personnel or roles]. \n\nSupplemental Guidance:  This control\
    \ helps organizational personnel understand the implementation and operation of\
    \ security controls associated with information systems, system components, and\
    \ information system services. Organizations consider establishing specific measures\
    \ to determine the quality/completeness of the content provided. The inability\
    \ to obtain needed documentation may occur, for example, due to the age of the\
    \ information system/component or lack of support from developers and contractors.\
    \ In those situations, organizations may need to recreate selected documentation\
    \ if such documentation is essential to the effective implementation or operation\
    \ of security controls. The level of protection provided for selected information\
    \ system, component, or service documentation is commensurate with the security\
    \ category or classification of the system. For example, documentation associated\
    \ with a key DoD weapons system or command and control system would typically\
    \ require a higher level of protection than a routine administrative system. Documentation\
    \ that addresses information system vulnerabilities may also require an increased\
    \ level of protection. Secure operation of the information system, includes, for\
    \ example, initially starting the system and resuming secure system operation\
    \ after any lapse in system operation. Related controls: CM-6, CM-8, PL-2, PL-4,\
    \ PS-2, SA-3, SA-4.\n\nReferences: None.\n\nSA-5E [at a minimum, the ISSO (or\
    \ similar role within the organization)]"
  title: >-
    SA-5 - INFORMATION SYSTEM DOCUMENTATION
  levels:
  - high
  - moderate
  - low
- id: SA-8
  status: pending
  notes: |-
    Customers are responsible for embedding secure system development
    lifecycle principles in the specification, design, development,
    implementation, and modification of the system. A successful control
    response will discuss the processes followed.
  rules: []
  description: |-
    The organization applies information system security engineering principles in the specification, design, development, implementation, and modification of the information system.

    Supplemental Guidance:  Organizations apply security engineering principles primarily to new development information systems or systems undergoing major upgrades. For legacy systems, organizations apply security engineering principles to system upgrades and modifications to the extent feasible, given the current state of hardware, software, and firmware within those systems. Security engineering principles include, for example: (i) developing layered protections; (ii) establishing sound security policy, architecture, and controls as the foundation for design; (iii) incorporating security requirements into the system development life cycle; (iv) delineating physical and logical security boundaries; (v) ensuring that system developers are trained on how to build secure software; (vi) tailoring security controls to meet organizational and operational needs; (vii) performing threat modeling to identify use cases, threat agents, attack vectors, and attack patterns as well as compensating controls and design patterns needed to mitigate risk; and (viii) reducing risk to acceptable levels, thus enabling informed risk management decisions. Related controls: PM-7, SA-3, SA-4, SA-17, SC-2, SC-3.

    Control Enhancements:  None.

    References:  NIST Special Publication 800-27.
  title: >-
    SA-8 - SECURITY ENGINEERING PRINCIPLES
  levels:
  - high
  - moderate
- id: SA-9
  status: pending
  notes: |-
    Section a: Customers are responsible to require that external information systems
    comply with organiziational security requirements and FedRAMP
    Security Controls Baseline(s) if Federal information is processed or
    stored within the external system. A successful control response will
    indicate how this is enforced, procedurally and technically, for
    external information systems.
    Section b: Customers are responsible for defining and documenting government
    oversight and user roles and responsibilities regarding external
    information system services. A successful contro response will address
    the procedures for this oversight.
    Section c: Customers are responsible for employing Federal/FedRAMP Continuous
    Monitoring Requirements on external systems where Federal information
    is processed or stored, and monitor security control compliance by
    external serice providers on an ongoing basis. A successful control
    response will address the procedural and technical processes used to
    accomplish this.
  rules: []
  description: |-
    The organization:
     a. Requires that providers of external information system services comply with organizational information security requirements and employ [Assignment: organization-defined security controls] in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance;
     b. Defines and documents government oversight and user roles and responsibilities with regard to external information system services; and
     c. Employs [Assignment: organization-defined processes, methods, and techniques] to monitor security control compliance by external service providers on an ongoing basis.

    Supplemental Guidance:  External information system services are services that are implemented outside of the authorization boundaries of organizational information systems. This includes services that are used by, but not a part of, organizational information systems. FISMA and OMB policy require that organizations using external service providers that are processing, storing, or transmitting federal information or operating information systems on behalf of the federal government ensure that such providers meet the same security requirements that federal agencies are required to meet. Organizations establish relationships with external service providers in a variety of ways including, for example, through joint ventures, business partnerships, contracts, interagency agreements, lines of business arrangements, licensing agreements, and supply chain exchanges. The responsibility for managing risks from the use of external information system services remains with authorizing officials. For services external to organizations, a chain of trust requires that organizations establish and retain a level of confidence that each participating provider in the potentially complex consumer-provider relationship provides adequate protection for the services rendered. The extent and nature of this chain of trust varies based on the relationships between organizations and the external providers. Organizations document the basis for trust relationships so the relationships can be monitored over time. External information system services documentation includes government, service providers, end user security roles and responsibilities, and service-level agreements. Service-level agreements define expectations of performance for security controls, describe measurable outcomes, and identify remedies and response requirements for identified instances of noncompliance. Related controls: CA-3, IR-7, PS-7.

    References: NIST Special Publication 800-35.

    SA-9 (a) [FedRAMP Security Controls Baseline(s) if Federal information is processed or stored within the external system]
    SA-9 (c) [Federal/FedRAMP Continuous Monitoring requirements must be met for external systems where Federal information is processed or stored]
  title: >-
    SA-9 - EXTERNAL INFORMATION SYSTEM SERVICES
  levels:
  - high
  - moderate
  - low
- id: SA-9(1)
  status: pending
  notes: |-
    Section a: Customers are responsible for conducting organizational assessment
    of risk prior to the acquisition or outsourcing of dedicated
    information security services. A successful control response will
    address the process of the risk assessment and analysis of findings.
    Section b: Customers are responsible for ensuring that the aquisition or
    outsourcing of dedicated information security services is approved
    by organizational authorities. A successful control response will
    address formal approval processes.
  rules: []
  description: |-
    The organization:
     (a)   Conducts an organizational assessment of risk prior to the acquisition or outsourcing of dedicated information security services; and
     (b)   Ensures that the acquisition or outsourcing of dedicated information security services is approved by [Assignment: organization-defined personnel or roles].

    Supplemental Guidance:  Dedicated information security services include, for example, incident monitoring, analysis and response, operation of information security-related devices such as firewalls, or key management services. Related controls: CA-6, RA-3.
  title: >-
    SA-9(1) - EXTERNAL INFORMATION SYSTEMS | RISK ASSESSMENTS /

    ORGANIZATIONAL APPROVALS
  levels:
  - high
  - moderate
- id: SA-9(2)
  status: pending
  notes: |-
    Customers are responsible for requiring providers of all external
    information systems where Federal information is processed or stored
    to identify the functions, ports, protocols, and other services
    required for the use of such services. A successful control response
    will indicate this requirement in contracting language.
  rules: []
  description: |-
    The organization requires providers of [Assignment: organization-defined external information system services] to identify the functions, ports, protocols, and other services required for the use of such services.

    Supplemental Guidance:  Information from external service providers regarding the specific functions, ports, protocols, and services used in the provision of such services can be particularly useful when the need arises to understand the trade-offs involved in restricting certain functions/services or blocking certain ports/protocols. Related control: CM-7.

    SA-9 (2) [all external systems where Federal information is processed or stored]
  title: >-
    SA-9(2) - EXTERNAL INFORMATION SYSTEMS | IDENTIFICATION OF FUNCTIONS / PORTS /
    PROTOCOLS / SERVICES
  levels:
  - high
  - moderate
- id: SA-9(4)
  status: pending
  notes: |-
    Customers are responsible for employing FedRAMP security requirements
    to ensure the interests of all external systems where Federal
    information is processed or stored is consistent with and reflect
    organizational interests. A successful control response will discuss
    how FedRAMP security requirements are enforced in external systems.
  rules: []
  description: |-
    The organization employs [Assignment: organization-defined security safeguards] to ensure that the interests of [Assignment: organization-defined external service providers] are consistent with and reflect organizational interests.

    Supplemental Guidance:  As organizations increasingly use external service providers, the possibility exists that the interests of the service providers may diverge from organizational interests. In such situations, simply having the correct technical, procedural, or operational safeguards in place may not be sufficient if the service providers that implement and control those safeguards are not operating in a manner consistent with the interests of the consuming organizations. Possible actions that organizations might take to address such concerns include, for example, requiring background checks for selected service provider personnel, examining ownership records, employing only trustworthy service providers (i.e., providers with which organizations have had positive experiences), and conducting periodic/unscheduled visits to service provider facilities.

    SA-9 (4)-2 [all external systems where Federal information is processed or stored]
  title: >-
    SA-9(4) - EXTERNAL INFORMATION SYSTEMS | CONSISTENT INTERESTS OF CONSUMERS AND
    PROVIDERS
  levels:
  - high
  - moderate
- id: SA-9(5)
  status: pending
  notes: |-
    Customers are responsible for restricting the location of information
    processing, information data, and information services, to
    continental United States datacenters based on business requirements.
  rules: []
  description: |-
    The organization restricts the location of [Selection (one or more): information processing; information/data; information system services] to [Assignment: organization-defined locations] based on [Assignment: organization-defined requirements or conditions].

    Supplemental Guidance:  The location of information processing, information/data storage, or information system services that are critical to organizations can have a direct impact on the ability of those organizations to successfully execute their missions/business functions. This situation exists when external providers control the location of processing, storage or services. The criteria external providers use for the selection of processing, storage, or service locations may be different from organizational criteria. For example, organizations may want to ensure that data/information storage locations are restricted to certain locations to facilitate incident response activities (e.g., forensic analyses, after-the-fact investigations) in case of information security breaches/compromises. Such incident response activities may be adversely affected
    by the governing laws or protocols in the locations where processing and storage occur and/or the locations from which information system services emanate.

    SA-9 (5)-1 [information processing, information data, AND information services]
    SA-9 (5)-2 [U.S./U.S. Territories or geographic locations where there is U.S. jurisdiction]
    SA-9 (5)-3 [all High impact data, systems, or services]
  title: >-
    SA-9(5) - EXTERNAL INFORMATION SYSTEMS | PROCESSING, STORAGE, AND SERVICE LOCATION
  levels:
  - high
  - moderate
- id: SC-1
  status: pending
  notes: |-
    Section a: The organization will be responsible for developing, documenting, and
    disseminating System and Communications Protection policy and
    procedures. A successful control response will need to address the
    content of the policy (which must include purpose, scope, roles,
    responsibilities, management commitment, coordination, and
    compliance) and procedures (which must facilitate the implementation
    of the policies and associated controls).
    Section b: The organization will be responsible for reviewing and updating the System
    and Communications Protection policy every 3 years, and procedures
    annually. A successful control response will need to address the
    review and update process, including the role(s) responsible for
    initiating the review process, updating the policy and procedures,
    and providing approval of the updates.
  rules: []
  description: "The organization:\n a. Develops, documents, and disseminates to [Assignment:\
    \ organization-defined personnel or roles]:\n   1. A system and communications\
    \ protection policy that addresses purpose, scope, roles, responsibilities, management\
    \ commitment, coordination among organizational entities, and compliance; and\n\
    \   2. Procedures to facilitate the implementation of the system and communications\
    \ protection policy and associated system and communications protection controls;\
    \ and\n b. Reviews and updates the current:\n   1. System and communications protection\
    \ policy [Assignment: organization-defined frequency]; and\n   2. System and communications\
    \ protection procedures [Assignment: organization-defined frequency].\n\nSupplemental\
    \ Guidance:  This control addresses the establishment of policy and procedures\
    \ for the effective implementation of selected security controls and control enhancements\
    \ in the SC family. Policy and procedures reflect applicable federal laws, Executive\
    \ Orders, directives, regulations, policies, standards, and guidance. Security\
    \ program policies and procedures at the organization level may make the need\
    \ for system-specific policies and procedures unnecessary. The policy can be included\
    \ as part of the general information security policy for organizations or conversely,\
    \ can be represented by multiple policies reflecting the complex nature of certain\
    \ organizations. The procedures can be established for the security program in\
    \ general and for particular information systems, if needed. The organizational\
    \ risk management strategy is a key factor in establishing policy and procedures.\
    \ Related control: PM-9.\n\nControl Enhancements:  None.\n\nReferences:  NIST\
    \ Special Publications 800-12, 800-100.\n\nSC-1 (b) (1) [at least annually]  \n\
    SC-1 (b) (2) [at least annually or whenever a significant change occurs]"
  title: >-
    SC-1 - SYSTEM AND COMMUNICATIONS PROTECTION

    POLICY AND PROCEDURES
  levels:
  - high
  - moderate
  - low
- id: SC-5
  status: pending
  notes: |-
    The customer is responsible for protecting against or limiting
    the effects of attacks on bandwidth, attacks on transactional
    capacity, attacks on storage capacity by employing geo-replication,
    IP address blocking, network-based DDos protections. A successful
    control response will discuss how the information system is protected
    from these attacks.
  rules: []
  description: |-
    The information system protects against or limits the effects of the following types of denial of service attacks: [Assignment: organization-defined types of denial of service attacks or reference to source for such information] by employing [Assignment: organization-defined security safeguards].

    Supplemental Guidance:  A variety of technologies exist to limit, or in some cases, eliminate the effects of denial of service attacks. For example, boundary protection devices can filter certain types of packets to protect information system components on internal organizational networks from being directly affected by denial of service attacks. Employing increased capacity and bandwidth combined with service redundancy may also reduce the susceptibility to denial of service attacks. Related controls: SC-6, SC-7.

    References: None.
  title: >-
    SC-5 - DENIAL OF SERVICE PROTECTION
  levels:
  - high
  - moderate
  - low
- id: SC-12(2)
  status: pending
  notes: |-
    The customer will be responsible for producing, controlling, and
    distributing symmetric cryptographic keys (if any are used within
    the customer application) using NIST FIPS-compliant key management
    technology and proesses. A successful control response will need to
    address the processes and tools used for key generation and discuss
    the reasons they are considered compliant.
  rules: []
  description: |-
    The organization produces, controls, and distributes symmetric cryptographic keys using [Selection: NIST FIPS-compliant; NSA-approved] key management technology and processes.

    SC-12 (2) [NIST FIPS-compliant]
  title: >-
    SC-12(2) - CRYPTOGRAPHIC KEY ESTABLISHMENT AND MANAGEMENT |

    SYMMETRIC KEYS
  levels:
  - high
  - moderate
- id: SC-12(3)
  status: pending
  notes: |-
    The customer will be responsible for producign, controlling, and
    distributing asymetric cryptographic keys (if any are used within the
    customer application) using one of the specified tools or processes. A
    successful control response will need to address the process and tools
    used for key generation and discuss the reasons they are considered
    compliant.
  rules: []
  description: "The organization produces, controls, and distributes asymmetric cryptographic\
    \ keys using [Selection: NSA-approved key management technology and processes;\
    \ approved PKI Class 3 certificates or prepositioned keying material; approved\
    \ PKI Class 3 or Class 4 certificates and hardware security tokens that protect\
    \ the user\u2019s private key]."
  title: >-
    SC-12(3) - CRYPTOGRAPHIC KEY ESTABLISHMENT AND MANAGEMENT |

    ASYMMETRIC KEYS
  levels:
  - high
  - moderate
- id: SC-15
  status: pending
  notes: |-
    Section a: The customer will be responsible for prohibiting remote activation
    of any collaborative computing devices within or controlled from
    the customer application.
    Section b: The customer will be responsible for providing an explicit indication
    of use of any collaborative computing devices within or controlled
    from the customer application. A successful control response will
    need to address how this explicit indication is enabled, the form
    it takes, and the means by which activation can be verified.
    Section Req. 1: The customer will be responsible for providing easy to use
    functionality to disable any collaborative computing devices within
    or controlled from the customer application.
  rules: []
  description: |-
    The information system:
     a. Prohibits remote activation of collaborative computing devices with the following exceptions: [Assignment: organization-defined exceptions where remote activation is to be allowed]; and
     b. Provides an explicit indication of use to users physically present at the devices.

    Supplemental Guidance:  Collaborative computing devices include, for example, networked white boards, cameras, and microphones. Explicit indication of use includes, for example, signals to users when collaborative computing devices are activated. Related control: AC-21.

    References: None.

    SC-15 (a) [no exceptions]
    SC-15 Requirement: The information system provides disablement (instead of physical disconnect) of collaborative computing devices in a manner that supports ease of use.
  title: >-
    SC-15 - COLLABORATIVE COMPUTING DEVICES
  levels:
  - high
  - moderate
  - low
- id: SC-17
  status: pending
  notes: |-
    The organization will be responsible for defining and enforcing a
    policy for issuing public key certificates, or else to obtain
    public key certificates from an approved service provider. A
    successful control response will need to outline the policy and
    address the mechanism by which the policy is enforced, or else
    discuss the approved service provider and the process by which
    certificates are obtained.
  rules: []
  description: |-
    The organization issues public key certificates under an [Assignment: organization- defined certificate policy] or obtains public key certificates from an approved service provider.

    Supplemental Guidance:  For all certificates, organizations manage information system trust stores to ensure only approved trust anchors are in the trust stores. This control addresses both certificates with visibility external to organizational information systems and certificates related to the internal operations of systems, for example, application-specific time services. Related control: SC-12.

    Control Enhancements:  None.

    References:  OMB Memorandum 05-24; NIST Special Publications 800-32, 800-63.
  title: >-
    SC-17 - PUBLIC KEY INFRASTRUCTURE CERTIFICATES
  levels:
  - high
  - moderate
- id: SC-18
  status: pending
  notes: |-
    Section a: Mobile code is code that is downloaded and executed by the client
    machine, rather than on the remote host. The customer will be
    responsible for defining mobile code technologies as acceptable or
    unacceptable for use within the system.
    Section b: The customer will be responsible for defining usage restrictions
    and implementation guidance for acceptable mobile code and mobile
    code technologies.
  rules: []
  description: |-
    The organization:
     a. Defines acceptable and unacceptable mobile code and mobile code technologies;
     b. Establishes usage restrictions and implementation guidance for acceptable mobile code and mobile code technologies; and
     c. Authorizes, monitors, and controls the use of mobile code within the information system.

    Supplemental Guidance:  Decisions regarding the employment of mobile code within organizational information systems are based on the potential for the code to cause damage to the systems if used maliciously. Mobile code technologies include, for example, Java, JavaScript, ActiveX, Postscript, PDF, Shockwave movies, Flash animations, and VBScript. Usage restrictions and implementation guidance apply to both the selection and use of mobile code installed on servers and mobile code downloaded and executed on individual workstations and devices (e.g., smart phones). Mobile code policy and procedures address preventing the development, acquisition, or introduction of unacceptable mobile code within organizational information systems. Related controls: AU-2, AU-12, CM-2, CM-6, SI-3.

    References: NIST Special Publication 800-28; DoD Instruction 8552.01.
  title: >-
    SC-18 - MOBILE CODE
  levels:
  - high
  - moderate
- id: SC-19
  status: pending
  notes: |-
    Section a: The customer will be responsible for establishing usage restrictions
    and implementation guidance for the use of VoIP technologies within
    the customer application. A successful control response will need
    to address whether and how VoIP technologies are used and outline
    the conditions under which that usage is appropriate.
  rules: []
  description: |-
    The organization:
     a. Establishes usage restrictions and implementation guidance for Voice over Internet Protocol (VoIP) technologies based on the potential to cause damage to the information system if used maliciously; and
     b. Authorizes, monitors, and controls the use of VoIP within the information system.

    Supplemental Guidance:  Related controls: CM-6, SC-7, SC-15.

    References:  NIST Special Publication 800-58.
  title: >-
    SC-19 - VOICE OVER INTERNET PROTOCOL
  levels:
  - high
  - moderate
- id: SI-1
  status: pending
  notes: |-
    Section a: The organization will be responsible for developing, documenting, and
    disseminating System and Information Integrity policy and procedures. A
    successful control response will need to address the content of the
    policy (which must include purpose, scope, roles, responsibilities,
    management commitment, coordination, and compliance) and procedures
    (which must facilitate the implementation of the policies and
    associated controls).
    Section b: The organization will be responsible for reviewing and updating the
    System and Information Integrity policy every 3 years, and procedures
    annually. A successful control response will need to address the
    review and update process, including the role(s) responsible for
    initiating the review process, updating the policy and procedures,
    and providing approval of the updates.
  rules: []
  description: "The organization:\n a. Develops, documents, and disseminates to [Assignment:\
    \ organization-defined personnel or roles]:\n   1. A system and information integrity\
    \ policy that addresses purpose, scope, roles, responsibilities, management commitment,\
    \ coordination among organizational entities, and compliance; and\n   2. Procedures\
    \ to facilitate the implementation of the system and information integrity policy\
    \ and associated system and information integrity controls; and\n b. Reviews and\
    \ updates the current:\n   1. System and information integrity policy [Assignment:\
    \ organization-defined frequency]; and\n   2.  System and information integrity\
    \ procedures [Assignment: organization-defined frequency].\n\nSupplemental Guidance:\
    \  This control addresses the establishment of policy and procedures for the effective\
    \ implementation of selected security controls and control enhancements in the\
    \ SI family. Policy and procedures reflect applicable federal laws, Executive\
    \ Orders, directives, regulations, policies, standards, and guidance. Security\
    \ program policies and procedures at the organization level may make the need\
    \ for system-specific policies and procedures unnecessary. The policy can be included\
    \ as part of the general information security policy for organizations or conversely,\
    \ can be represented by multiple policies reflecting the complex nature of certain\
    \ organizations. The procedures can be established for the security program in\
    \ general and for particular information systems, if needed. The organizational\
    \ risk management strategy is a key factor in establishing policy and procedures.\
    \ Related control: PM-9.\n\nControl Enhancements:  None.\n\nReferences:  NIST\
    \ Special Publications 800-12, 800-100.\n\nSI-1 (b) (1) [at least annually] \n\
    SI-1 (b) (2) [at least annually or whenever a significant change occurs]"
  title: >-
    SI-1 - SYSTEM AND INFORMATION INTEGRITY POLICY AND

    PROCEDURES
  levels:
  - high
  - moderate
  - low
- id: SI-5
  status: pending
  notes: |-
    Section b: The organization will be responsible for generatign internal security
    alerts, advisories and directives. A successful control response will
    need to address the criteria used to determine what alerts, advisories,
    and directives are necessary, based on the specifics of the customer
    mission, software, or service.
    Section c: The organization will be responsible for disseminating security alerts,
    advisories and directives within the customer organization and to
    external organizations as necessary. A successful control response will
    need to address the personnel or roles within the organization who
    require notificiation.
  rules: []
  description: |-
    The organization:
     a. Receives information system security alerts, advisories, and directives from [Assignment: organization-defined external organizations] on an ongoing basis;
     b. Generates internal security alerts, advisories, and directives as deemed necessary;
     c. Disseminates security alerts, advisories, and directives to: [Selection (one or more): [Assignment: organization-defined personnel or roles]; [Assignment: organization-defined elements within the organization]; [Assignment: organization-defined external organizations]]; and
     d. Implements security directives in accordance with established time frames, or notifies the issuing organization of the degree of noncompliance.

    Supplemental Guidance:  The United States Computer Emergency Readiness Team (US-CERT) generates security alerts and advisories to maintain situational awareness across the federal government. Security directives are issued by OMB or other designated organizations with the responsibility and authority to issue such directives. Compliance to 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, for example, external mission/business partners, supply chain partners, external service providers, and other peer/supporting organizations. Related control: SI-2.

    References: NIST Special Publication 800-40.

    SI-5 (a) [to include US-CERT]
    SI-5 (c) [to include system security personnel and administrators with configuration/patch-management responsibilities]
  title: >-
    SI-5 - SECURITY ALERTS, ADVISORIES, AND DIRECTIVES
  levels:
  - high
  - moderate
  - low
- id: SI-8
  status: pending
  notes: |-
    Section a: The organization will be responsible for employing spam protection
    mechanisms at organizational information system entry and exit points
    to detect and take action on unsolicited messages. A successful
    control response will need to address how the organization deploys
    spam protection.
    Section b: The organization will be responsible for updating spam protection
    mechanisms when new releases are available in accordance with
    organizational configuration management policy and procedures. A
    successful control response will describe the organizations process
    to ensure spam protection mechanisms are updated.
  rules: []
  description: |-
    The organization:
     a. Employs spam protection mechanisms at information system entry and exit points to detect and take action on unsolicited messages; and
     b. Updates spam protection mechanisms when new releases are available in accordance with organizational configuration management policy and procedures.

    Supplemental Guidance:  Information system entry and exit points include, for example, firewalls, electronic mail servers, web servers, proxy servers, remote-access servers, workstations, mobile devices, and notebook/laptop computers. Spam can be transported by different means including, for example, electronic mail, electronic mail attachments, and web accesses. Spam protection mechanisms include, for example, signature definitions. Related controls: AT-2, AT-3, SC-5, SC-7, SI-3.

    References: NIST Special Publication 800-45.
  title: >-
    SI-8 - SPAM PROTECTION
  levels:
  - high
  - moderate
- id: SI-8(1)
  status: pending
  notes: |-
    The organization is responsible for centrally managing spam protection
    mechanisms. A successful control response will indicate how spam
    protection is provided as a corporate service, and when applicable,
    how spam protection content is disseminated to subordinate mail
    servers.
  rules: []
  description: |-
    The organization centrally manages spam protection mechanisms.

    Supplemental Guidance:  Central management is the organization-wide management and implementation of spam protection mechanisms. Central management includes planning, implementing, assessing, authorizing, and monitoring the organization-defined, centrally managed spam protection security controls. Related controls: AU-3, SI-2, SI-7.
  title: >-
    SI-8(1) - SPAM PROTECTION | CENTRAL MANAGEMENT
  levels:
  - high
  - moderate
- id: SI-8(2)
  status: pending
  notes: |-
    The organization is responsible for automatic updates to spam
    protection mechanisms. A successful control response will indicate
    how automatic updates are performed, both for protection mechanisms
    and filtering content.
  rules: []
  description: |-
    The information system automatically updates spam protection mechanisms.
  title: >-
    SI-8(2) - SPAM PROTECTION | AUTOMATIC UPDATES
  levels:
  - high
  - moderate