diff --git a/controls/cis_rhel8.yml b/controls/cis_rhel8.yml index e82fa314bbf..380280892db 100644 --- a/controls/cis_rhel8.yml +++ b/controls/cis_rhel8.yml @@ -26,16 +26,13 @@ controls: - l1_workstation notes: <- This is a helper rule to reload Dconf database correctly. status: automated - rules: - - dconf_db_up_to_date - - id: enable_authselect title: Enable Authselect levels: - l1_server - - l1_workstation - notes: <- We need this in all CIS versions, but the policy doesn't have any section where this - would fit better. + - l2_workstation + notes: <- We need this in all CIS versions, but the policy doesn't have any section where this would fit + better. status: automated rules: - var_authselect_profile=sssd diff --git a/controls/nist_ocp4.yml b/controls/nist_ocp4.yml index a9ef6701968..ba2d64ac2be 100644 --- a/controls/nist_ocp4.yml +++ b/controls/nist_ocp4.yml @@ -18,25 +18,23 @@ controls: Section b: AC-1(b) is an organizational control outside the scope of OpenShift configuration. 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]" + description: "The organization:\n a. Test 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: @@ -92,6 +90,7 @@ controls: References: None. + AC-2 (j) [monthly for privileged accessed, every six (6) months for non-privileged access] title: >- AC-2 - ACCOUNT MANAGEMENT @@ -148,12 +147,11 @@ controls: - kubeadmin_removed - ocp_idp_no_htpasswd - idp_is_configured - 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]" + 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: @@ -362,8 +360,8 @@ controls: remove the kubeadmin user as described in https://docs.openshift.com/container-platform/latest/authentication/remove-kubeadmin.html rules: - kubeadmin_removed - description: "The information system terminates shared/group account credentials when members leave\ - \ the group.\n\n \nAC-2 (10) Required if shared/group accounts are deployed" + description: "The information system terminates shared/group account credentials when members leave the group.\n\ + \n \nAC-2 (10) Required if shared/group accounts are deployed" title: >- AC-2(10) - ACCOUNT MANAGEMENT | SHARED / GROUP ACCOUNT CREDENTIAL TERMINATION levels: @@ -429,6 +427,7 @@ controls: 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 @@ -890,17 +889,16 @@ controls: https://docs.openshift.com/container-platform/latest/authentication/using-rbac.html 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." + \ 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\n\ + Control 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: @@ -1183,21 +1181,19 @@ controls: rules: - ocp_idp_no_htpasswd - idp_is_configured - description: "The information system:\n a. Enforces a limit of [Assignment: organization-defined\ - \ number] consecutive invalid logon attempts by a user during a [Assignment: organization-defined\ - \ time period]; and\n b. Automatically [Selection: locks the account/node for an [Assignment:\ - \ organization-defined time period]; locks the account/node until released by an administrator;\ - \ delays next logon prompt according to [Assignment: organization-defined delay algorithm]]\ - \ when the maximum number of unsuccessful attempts is exceeded.\n\nSupplemental Guidance: \ - \ This control applies regardless of whether the logon occurs via a local or network connection.\ - \ Due to the potential for denial of service, automatic lockouts initiated by information systems\ - \ are usually temporary and automatically release after a predetermined time period established\ - \ by organizations. If a delay algorithm is selected, organizations may choose to employ different\ - \ algorithms for different information system components based on the capabilities of those\ - \ components. Responses to unsuccessful logon attempts may be implemented at both the operating\ - \ system and the application levels. Related controls: AC-2, AC-9, AC-14, IA-5.\n\nReferences:\ - \ None.\n\nAC-7(a)-1 [not more than three (3)]\n \nAC-7(a)-2 [fifteen (15) minutes] \n\nAC-7(b)\ - \ [locks the account/node for a minimum of three (3) hours or until unlocked by an administrator]" + description: "The information system:\n a. Enforces a limit of [Assignment: organization-defined number] consecutive + invalid logon attempts by a user during a [Assignment: organization-defined time period]; and\n b. Automatically + [Selection: locks the account/node for an [Assignment: organization-defined time period]; locks the account/node + until released by an administrator; delays next logon prompt according to [Assignment: organization-defined + delay algorithm]] when the maximum number of unsuccessful attempts is exceeded.\n\nSupplemental Guidance:\ + \ This control applies regardless of whether the logon occurs via a local or network connection. Due + to the potential for denial of service, automatic lockouts initiated by information systems are usually + temporary and automatically release after a predetermined time period established by organizations. If + a delay algorithm is selected, organizations may choose to employ different algorithms for different information + system components based on the capabilities of those components. Responses to unsuccessful logon attempts + may be implemented at both the operating system and the application levels. Related controls: AC-2, AC-9, + AC-14, IA-5.\n\nReferences: None.\n\nAC-7(a)-1 [not more than three (3)]\n \nAC-7(a)-2 [fifteen (15) minutes]\ + \ \n\nAC-7(b) [locks the account/node for a minimum of three (3) hours or until unlocked by an administrator]" title: >- AC-7 - UNSUCCESSFUL LOGON ATTEMPTS levels: @@ -1298,40 +1294,36 @@ controls: rules: - openshift_motd_exists - banner_or_login_template_set - description: "The information system:\n a. Displays to users [Assignment: organization-defined\ - \ system use notification message or banner] before granting access to the system that provides\ - \ privacy and security notices consistent with applicable federal laws, Executive Orders, directives,\ - \ policies, regulations, standards, and guidance and states that:\n 1. Users are accessing\ - \ a U.S. Government information system;\n 2. Information system usage may be monitored, recorded,\ - \ and subject to audit;\n 3. Unauthorized use of the information system is prohibited and\ - \ subject to criminal and civil penalties; and\n 4. Use of the information system indicates\ - \ consent to monitoring and recording;\n b. Retains the notification message or banner on the\ - \ screen until users acknowledge the usage conditions and take explicit actions to log on to\ - \ or further access the information system; and \n c. For publicly accessible systems:\n \ - \ 1. Displays system use information [Assignment: organization-defined conditions], before\ - \ granting further access;\n 2. Displays references, if any, to monitoring, recording, or\ - \ auditing that are consistent with privacy accommodations for such systems that generally\ - \ prohibit those activities; and\n 3. Includes a description of the authorized uses of the\ - \ system.\n\nSupplemental Guidance: System use notifications can be implemented using messages\ - \ or warning banners displayed before individuals log in to information systems. System use\ - \ notifications are used only for access via logon interfaces with human users and are not\ - \ required when such human interfaces do not exist. Organizations consider system use notification\ - \ messages/banners displayed in multiple languages based on specific organizational needs and\ - \ the demographics of information system users. Organizations also consult with the Office\ - \ of the General Counsel for legal review and approval of warning banner content.\n\nControl\ - \ Enhancements: None.\n\nReferences: None.\n\n\nAC-8 (a) [see additional Requirements and\ - \ Guidance]\nAC-8 (c) [see additional Requirements and Guidance]\nAC-8 Requirement: The service\ - \ provider shall determine elements of the cloud environment that require the System Use Notification\ - \ control. The elements of the cloud environment that require System Use Notification are approved\ - \ and accepted by the JAB/AO. \nRequirement: The service provider shall determine how System\ - \ Use Notification is going to be verified and provide appropriate periodicity of the check.\ - \ The System Use Notification verification and periodicity are approved and accepted by the\ - \ JAB/AO.\nGuidance: If performed as part of a Configuration Baseline check, then the % of\ - \ items requiring setting that are checked and that pass (or fail) check can be provided. \n\ - Requirement: If not performed as part of a Configuration Baseline check, then there must be\ - \ documented agreement on how to provide results of verification and the necessary periodicity\ - \ of the verification by the service provider. The documented agreement on how to provide verification\ - \ of the results are approved and accepted by the JAB/AO." + description: "The information system:\n a. Displays to users [Assignment: organization-defined system use + notification message or banner] before granting access to the system that provides privacy and security + notices consistent with applicable federal laws, Executive Orders, directives, policies, regulations, + standards, and guidance and states that:\n 1. Users are accessing a U.S. Government information system;\n\ + \ 2. Information system usage may be monitored, recorded, and subject to audit;\n 3. Unauthorized + use of the information system is prohibited and subject to criminal and civil penalties; and\n 4. Use + of the information system indicates consent to monitoring and recording;\n b. Retains the notification + message or banner on the screen until users acknowledge the usage conditions and take explicit actions + to log on to or further access the information system; and \n c. For publicly accessible systems:\n \ + \ 1. Displays system use information [Assignment: organization-defined conditions], before granting further + access;\n 2. Displays references, if any, to monitoring, recording, or auditing that are consistent + with privacy accommodations for such systems that generally prohibit those activities; and\n 3. Includes + a description of the authorized uses of the system.\n\nSupplemental Guidance: System use notifications + can be implemented using messages or warning banners displayed before individuals log in to information + systems. System use notifications are used only for access via logon interfaces with human users and are + not required when such human interfaces do not exist. Organizations consider system use notification messages/banners + displayed in multiple languages based on specific organizational needs and the demographics of information + system users. Organizations also consult with the Office of the General Counsel for legal review and approval + of warning banner content.\n\nControl Enhancements: None.\n\nReferences: None.\n\n\nAC-8 (a) [see additional + Requirements and Guidance]\nAC-8 (c) [see additional Requirements and Guidance]\nAC-8 Requirement: The + service provider shall determine elements of the cloud environment that require the System Use Notification + control. The elements of the cloud environment that require System Use Notification are approved and accepted + by the JAB/AO. \nRequirement: The service provider shall determine how System Use Notification is going + to be verified and provide appropriate periodicity of the check. The System Use Notification verification + and periodicity are approved and accepted by the JAB/AO.\nGuidance: If performed as part of a Configuration + Baseline check, then the % of items requiring setting that are checked and that pass (or fail) check can + be provided. \nRequirement: If not performed as part of a Configuration Baseline check, then there must + be documented agreement on how to provide results of verification and the necessary periodicity of the + verification by the service provider. The documented agreement on how to provide verification of the results + are approved and accepted by the JAB/AO." title: >- AC-8 - SYSTEM USE NOTIFICATION levels: @@ -1394,6 +1386,7 @@ controls: References: None. + AC-10-2 [three (3) sessions for privileged access and two (2) sessions for non-privileged access] title: >- AC-10 - CONCURRENT SESSION CONTROL @@ -1449,34 +1442,32 @@ controls: - moderate - id: AC-12 status: automated - notes: "The customer will be responsible for defining events or conditions\nrequiring disconnection\ - \ (for example, user requesting logout),\nand for terminating the session when those events\ - \ or conditions\narise. Because a very common condition is to disconnect a user\nafter a certain\ - \ period of time, this control response describes\nhow to configure the internal OAuth server’s\ - \ token duration.\n\nTo meet the requirements, OpenShift must be configured\nto use centralized\ - \ authentication via an IDP. The token\nduration can be then be configured globally:\nhttps://docs.openshift.com/container-platform/latest/authentication/configuring-internal-oauth.html#oauth-configuring-internal-oauth_configuring-internal-oauth\n\ + notes: "The customer will be responsible for defining events or conditions\nrequiring disconnection (for example, + user requesting logout),\nand for terminating the session when those events or conditions\narise. Because + a very common condition is to disconnect a user\nafter a certain period of time, this control response + describes\nhow to configure the internal OAuth server’s token duration.\n\nTo meet the requirements, OpenShift + must be configured\nto use centralized authentication via an IDP. The token\nduration can be then be configured + globally:\nhttps://docs.openshift.com/container-platform/latest/authentication/configuring-internal-oauth.html#oauth-configuring-internal-oauth_configuring-internal-oauth\n\ \nOr per client:\nhttps://docs.openshift.com/container-platform/4.7/rest_api/oauth_apis/oauthclient-oauth-openshift-io-v1.html#oauthclient-oauth-openshift-io-v1\n\ - \nNote that the global configuration does not change the configuration\nof the oauthclient\ - \ objects, so for proper compliance check, both must\nbe audited.\n\nAlso note that prior to\ - \ OpenShift 4.8, changing the global oauth.config\nobject triggers a rollout of the kube-apiserver\ - \ which can take up\nto 15 minutes. You can watch the kube-apiserver rollout with\n\"oc get\ - \ co kube-apiserver\". Once the rollout finishes, the \"Progressing\"\ncolumn will say \"False\"\ - ." + \nNote that the global configuration does not change the configuration\nof the oauthclient objects, so + for proper compliance check, both must\nbe audited.\n\nAlso note that prior to OpenShift 4.8, changing + the global oauth.config\nobject triggers a rollout of the kube-apiserver which can take up\nto 15 minutes. + You can watch the kube-apiserver rollout with\n\"oc get co kube-apiserver\". Once the rollout finishes, + the \"Progressing\"\ncolumn will say \"False\"." rules: - oauth_or_oauthclient_token_maxage - description: "The information system automatically terminates a user session after [Assignment:\ - \ organization-defined conditions or trigger events requiring session disconnect].\n\nSupplemental\ - \ Guidance: This control addresses the termination of user-initiated logical sessions in contrast\ - \ to SC-10 which addresses the termination of network connections that are associated with\ - \ communications sessions (i.e., network disconnect). A logical session (for local, network,\ - \ and remote access) is initiated whenever a user (or process acting on behalf of a user) accesses\ - \ an organizational information system. Such user sessions can be terminated (and thus terminate\ - \ user access) without terminating network sessions. Session termination terminates all processes\ - \ associated with a user’s logical session except those processes that are specifically created\ - \ by the user (i.e., session owner) to continue after the session is terminated. Conditions\ - \ or trigger events requiring automatic session termination can include, for example, organization-defined\ - \ periods of user inactivity, targeted responses to certain types of incidents, time-of-day\ - \ restrictions on information system use. Related controls: SC-10, SC-23.\n\nReferences: None." + description: "The information system automatically terminates a user session after [Assignment: organization-defined + conditions or trigger events requiring session disconnect].\n\nSupplemental Guidance: This control addresses + the termination of user-initiated logical sessions in contrast to SC-10 which addresses the termination + of network connections that are associated with communications sessions (i.e., network disconnect). A + logical session (for local, network, and remote access) is initiated whenever a user (or process acting + on behalf of a user) accesses an organizational information system. Such user sessions can be terminated + (and thus terminate user access) without terminating network sessions. Session termination terminates + all processes associated with a user’s logical session except those processes that are specifically created + by the user (i.e., session owner) to continue after the session is terminated. Conditions or trigger events + requiring automatic session termination can include, for example, organization-defined periods of user + inactivity, targeted responses to certain types of incidents, time-of-day restrictions on information + system use. Related controls: SC-10, SC-23.\n\nReferences: None." title: >- AC-12 - SESSION TERMINATION levels: @@ -1529,27 +1520,25 @@ controls: system use notifications (as defined in AC-8) and login prompt. This is non-configurable behavior. 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." + 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 @@ -2004,20 +1993,19 @@ controls: agreements with organizational entities hosting the external information system is outside the scope of OpenShift configuration. 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’s 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." + 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’s 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: @@ -2067,19 +2055,17 @@ controls: information sharing/collaboration decisions is outside the scope of OpenShift configuration. 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." + 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: @@ -2184,26 +2170,25 @@ controls: Section b: This control reflects organizational procedure/policy and is not applicable to component-level configuration. 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]" + 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 AND PROCEDURES levels: @@ -2475,12 +2460,12 @@ controls: Organizational review and updates to the audited events are outside the scope of OpenShift configuration. 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." + 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: @@ -2682,15 +2667,14 @@ controls: [2] https://docs.openshift.com/container-platform/latest/monitoring/managing-alerts.html#applying-custom-alertmanager-configuration_managing-alerts rules: - alert_receiver_configured - description: "The information system provides an alert in [Assignment: organization-defined real-time\ - \ period] to [Assignment: organization-defined personnel, roles, and/or locations] when the\ - \ following audit failure events occur: [Assignment: organization-defined audit failure events\ - \ requiring real-time alerts].\n\nSupplemental Guidance: Alerts provide organizations with\ - \ urgent messages. Real-time alerts provide these messages at information technology speed\ - \ (i.e., the time from event detection to alert occurs in seconds or less).\n\nAU-5 (2)-1 [real-time]\ - \ \nAU-5 (1)-2 [service provider personnel with authority to address failed audit events] \n\ - AU-5 (1)-3 [audit failure events requiring real-time alerts, as defined by organization audit\ - \ policy]." + description: "The information system provides an alert in [Assignment: organization-defined real-time period] + to [Assignment: organization-defined personnel, roles, and/or locations] when the following audit failure + events occur: [Assignment: organization-defined audit failure events requiring real-time alerts].\n\n\ + Supplemental Guidance: Alerts provide organizations with urgent messages. Real-time alerts provide these + messages at information technology speed (i.e., the time from event detection to alert occurs in seconds + or less).\n\nAU-5 (2)-1 [real-time] \nAU-5 (1)-2 [service provider personnel with authority to address + failed audit events] \nAU-5 (1)-3 [audit failure events requiring real-time alerts, as defined by organization\ + \ audit policy]." title: >- AU-5(2) - RESPONSE TO AUDIT PROCESSING FAILURES | REAL-TIME ALERTS levels: @@ -2724,26 +2708,23 @@ controls: - audit_log_forwarding_enabled - var_openshift_audit_profile=WriteRequestBodies - audit_profile_set - 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-tenant environments, capability\ - \ and means for providing review, analysis, and reporting to consumer for data pertaining to\ - \ consumer shall be documented." + 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-tenant 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: @@ -2885,16 +2866,15 @@ controls: https://docs.openshift.com/container-platform/latest/logging/cluster-logging.html rules: [] - description: "The organization correlates information from audit records with information obtained\ - \ from monitoring physical access to further enhance the ability to identify suspicious, inappropriate,\ - \ unusual, or malevolent activity.\n\nSupplemental Guidance: The correlation of physical audit\ - \ information and audit logs from information systems may assist organizations in identifying\ - \ examples of suspicious behavior or supporting evidence of such behavior. For example, the\ - \ correlation of an individual’s identify for logical access to certain information systems\ - \ with the additional physical security information that the individual was actually present\ - \ at the facility when the logical access occurred, may prove to be useful in investigations.\n\ - \n \nAU-6 (6) Requirement: Coordination between service provider and consumer shall be documented\ - \ and accepted by the JAB/AO." + description: "The organization correlates information from audit records with information obtained from monitoring + physical access to further enhance the ability to identify suspicious, inappropriate, unusual, or malevolent + activity.\n\nSupplemental Guidance: The correlation of physical audit information and audit logs from + information systems may assist organizations in identifying examples of suspicious behavior or supporting + evidence of such behavior. For example, the correlation of an individual’s identify for logical access + to certain information systems with the additional physical security information that the individual was + actually present at the facility when the logical access occurred, may prove to be useful in investigations.\n\ + \n \nAU-6 (6) Requirement: Coordination between service provider and consumer shall be documented and + accepted by the JAB/AO." title: >- AU-6(6) - AUDIT REVIEW, ANALYSIS, AND REPORTING | CORRELATION WITH PHYSICAL MONITORING levels: @@ -3308,19 +3288,18 @@ controls: https://docs.openshift.com/container-platform/latest/logging/cluster-logging-external.html rules: - audit_log_forwarding_enabled - 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." + 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: @@ -3355,17 +3334,15 @@ controls: - audit_profile_set - directory_access_var_log_oauth_audit - directory_access_var_log_ocp_audit - description: "The information system:\n a. Provides audit record generation capability for the\ - \ auditable events defined in AU-2 a. at [Assignment: organization-defined information system\ - \ components];\n b. Allows [Assignment: organization-defined personnel or roles] to select\ - \ which auditable events are to be audited by specific components of the information system;\ - \ and\n c. Generates audit records for the events defined in AU-2 d. with the content defined\ - \ in AU-3. \n\nSupplemental Guidance: Audit records can be generated from many different information\ - \ system components. The list of audited events is the set of events for which audits are to\ - \ be generated. These events are typically a subset of all events for which the information\ - \ system is capable of generating audit records. Related controls: AC-3, AU-2, AU-3, AU-6,\ - \ AU-7.\n\nReferences: None.\n\nAU-12 (a) [all information system and network components where\ - \ audit capability is deployed/available]" + description: "The information system:\n a. Provides audit record generation capability for the auditable events + defined in AU-2 a. at [Assignment: organization-defined information system components];\n b. Allows [Assignment: + organization-defined personnel or roles] to select which auditable events are to be audited by specific + components of the information system; and\n c. Generates audit records for the events defined in AU-2 + d. with the content defined in AU-3. \n\nSupplemental Guidance: Audit records can be generated from many + different information system components. The list of audited events is the set of events for which audits + are to be generated. These events are typically a subset of all events for which the information system + is capable of generating audit records. Related controls: AC-3, AU-2, AU-3, AU-6, AU-7.\n\nReferences: + None.\n\nAU-12 (a) [all information system and network components where audit capability is deployed/available]" title: >- AU-12 - AUDIT GENERATION levels: @@ -3410,18 +3387,17 @@ controls: rules: - var_openshift_audit_profile=WriteRequestBodies - audit_profile_set - description: "The information system provides the capability for [Assignment: organization-defined\ - \ individuals or roles] to change the auditing to be performed on [Assignment: organization-defined\ - \ information system components] based on [Assignment: organization-defined selectable event\ - \ criteria] within [Assignment: organization-defined time thresholds].\n\nSupplemental Guidance:\ - \ This control enhancement enables organizations to extend or limit auditing as necessary\ - \ to meet organizational requirements. Auditing that is limited to conserve information system\ - \ resources may be extended to address certain threat situations. In addition, auditing may\ - \ be limited to a specific set of events to facilitate audit reduction, analysis, and reporting.\ - \ Organizations can establish time thresholds in which audit actions are changed, for example,\ - \ near real-time, within minutes, or within hours. Related control: AU-7.\n\nAU-12 (3) (1)\ - \ [service provider-defined individuals or roles with audit configuration responsibilities]\ - \ \nAU-12 (3) (2) [all network, data storage, and computing devices]" + description: "The information system provides the capability for [Assignment: organization-defined individuals + or roles] to change the auditing to be performed on [Assignment: organization-defined information system + components] based on [Assignment: organization-defined selectable event criteria] within [Assignment: + organization-defined time thresholds].\n\nSupplemental Guidance: This control enhancement enables organizations + to extend or limit auditing as necessary to meet organizational requirements. Auditing that is limited + to conserve information system resources may be extended to address certain threat situations. In addition, + auditing may be limited to a specific set of events to facilitate audit reduction, analysis, and reporting. + Organizations can establish time thresholds in which audit actions are changed, for example, near real-time, + within minutes, or within hours. Related control: AU-7.\n\nAU-12 (3) (1) [service provider-defined individuals + or roles with audit configuration responsibilities] \nAU-12 (3) (2) [all network, data storage, and computing + devices]" title: >- AU-12(3) - AUDIT GENERATION | CHANGES BY AUTHORIZED INDIVIDUALS levels: @@ -3521,26 +3497,24 @@ controls: authorization policy and procedures is outside the scope of OpenShift configuration guidance. 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\nCA-1 (b) (1)\ - \ [at least annually] \nCA-1 (b) (2) [at least annually or whenever a significant change occurs]" + 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\nCA-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 @@ -3564,54 +3538,48 @@ controls: Section d: Development of an organizational security assessment plan is outside the scope of OpenShift configuration guidance. 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\nProvider (CSP) Documents>\ - \ Annual Assessment Guidance\nhttps://www.FedRAMP.gov/documents/" + 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\nCA-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\nProvider (CSP) Documents> + Annual Assessment Guidance\nhttps://www.FedRAMP.gov/documents/" title: >- CA-2 - SECURITY ASSESSMENTS levels: @@ -3624,35 +3592,32 @@ controls: Employment of independent assessors or assessment teams is outside the scope of OpenShift configuration guidance. 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." + 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: @@ -3747,16 +3712,15 @@ controls: This is an organizational control outside the scope of OpenShift configuration guidance. 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 – Cloud Considerations of the\ - \ TIC 2.0 Reference Architecture document." + 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 – Cloud Considerations + of the TIC 2.0 Reference Architecture document." title: >- CA-3(3) - SYSTEM INTERCONNECTIONS | UNCLASSIFIED NON-NATIONAL SECURITY SYSTEM CONNECTIONS @@ -3824,18 +3788,17 @@ controls: https://issues.redhat.com/browse/CMP-254 rules: [] - description: "The organization:\n a. Develops a plan of action and milestones for the information\ - \ system to document the organization’s planned remedial actions to correct weaknesses or deficiencies\ - \ noted during\nthe assessment of the security controls and to reduce or eliminate known vulnerabilities\ - \ in the system; and\n b. Updates existing plan of action and milestones [Assignment: organization-defined\ - \ frequency] based on the findings from security controls assessments, security impact analyses,\ - \ and continuous monitoring activities.\n\nSupplemental Guidance: Plans of action and milestones\ - \ are key documents in security authorization packages and are subject to federal reporting\ - \ requirements established by OMB. Related controls: CA-2, CA-7, CM-4, PM-4.\n\nReferences:\ - \ OMB Memorandum 02-01; NIST Special Publication 800-37.\n\nCA-5 (b) [at least monthly]\n\ - CA-5 Requirement: POA&Ms must be provided at least monthly.\nCA-5 Guidance: See the FedRAMP\ - \ Documents page under Key Cloud Service\nProvider (CSP) Documents> Plan of Action and Milestones\ - \ (POA&M) Template Completion Guide\nhttps://www.FedRAMP.gov/documents/" + description: "The organization:\n a. Develops a plan of action and milestones for the information system to + document the organization’s planned remedial actions to correct weaknesses or deficiencies noted during\n\ + the assessment of the security controls and to reduce or eliminate known vulnerabilities in the system; + and\n b. Updates existing plan of action and milestones [Assignment: organization-defined frequency] based + on the findings from security controls assessments, security impact analyses, and continuous monitoring + activities.\n\nSupplemental Guidance: Plans of action and milestones are key documents in security authorization + packages and are subject to federal reporting requirements established by OMB. Related controls: CA-2, + CA-7, CM-4, PM-4.\n\nReferences: OMB Memorandum 02-01; NIST Special Publication 800-37.\n\nCA-5 (b) [at + least monthly]\nCA-5 Requirement: POA&Ms must be provided at least monthly.\nCA-5 Guidance: See the FedRAMP + Documents page under Key Cloud Service\nProvider (CSP) Documents> Plan of Action and Milestones (POA&M) + Template Completion Guide\nhttps://www.FedRAMP.gov/documents/" title: >- CA-5 - PLAN OF ACTION AND MILESTONES levels: @@ -3861,38 +3824,35 @@ controls: Section c: This control reflects organizational processes outside the scope of OpenShift configuration guidance. 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." + 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: @@ -3998,28 +3958,26 @@ controls: Penetration testing is outside the scope of OpenShift configuration guidance. 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/" + 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\n\ + CA-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: @@ -4213,13 +4171,12 @@ controls: https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.0/html-single/manage_applications/index#creating-and-managing-channels 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." + 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: @@ -4415,15 +4372,14 @@ controls: Section f: This control reflects organizational processes outside the scope of OpenShift configuration guidance. rules: [] - description: "The organization employs automated mechanisms to:\n (a) Document proposed changes\ - \ to the information system;\n (b) Notify [Assignment: organized-defined approval authorities]\ - \ of proposed changes to the information system and request change approval;\n (c) Highlight\ - \ proposed changes to the information system that have not been approved or disapproved by\ - \ [Assignment: organization-defined time period];\n (d) Prohibit changes to the information\ - \ system until designated approvals are received; \n (e) Document all changes to the information\ - \ system; and\n (f) Notify [Assignment: organization-defined personnel] when approved changes\ - \ to the information system are completed.\n\nCM-3 (1) (c) [organization agreed upon time\ - \ period] \nCM-3 (1) (f) [organization defined configuration management approval authorities]" + description: "The organization employs automated mechanisms to:\n (a) Document proposed changes to the information + system;\n (b) Notify [Assignment: organized-defined approval authorities] of proposed changes to the + information system and request change approval;\n (c) Highlight proposed changes to the information + system that have not been approved or disapproved by [Assignment: organization-defined time period];\n\ + \ (d) Prohibit changes to the information system until designated approvals are received; \n (e) Document + all changes to the information system; and\n (f) Notify [Assignment: organization-defined personnel] when + approved changes to the information system are completed.\n\nCM-3 (1) (c) [organization agreed upon time + period] \nCM-3 (1) (f) [organization defined configuration management approval authorities]" title: >- CM-3(1) - CONFIGURATION CHANGE CONTROL | AUTOMATED DOCUMENT / NOTIFICATION / PROHIBITION OF CHANGES @@ -5193,32 +5149,29 @@ controls: [1] https://docs.openshift.com/container-platform/4.7/networking/network_policy/about-network-policy.html rules: - configure_network_policies_namespaces - description: "The organization:\n a. Configures the information system to provide only essential\ - \ capabilities; and\n b. Prohibits or restricts the use of the following functions, ports,\ - \ protocols, and/or services: [Assignment: organization-defined prohibited or restricted functions,\ - \ ports, protocols, and/or services].\n\nSupplemental Guidance: Information systems can provide\ - \ a wide variety of functions and services. Some of the functions and services, provided by\ - \ default, may not be necessary to support essential organizational operations (e.g., key missions,\ - \ functions). Additionally, it is sometimes convenient to provide multiple services from single\ - \ information system components, but doing so increases risk over limiting the services provided\ - \ by any one component. Where feasible, organizations limit component functionality to a single\ - \ function per device (e.g., email servers or web servers, but not both). Organizations review\ - \ functions and services provided by information systems or individual components of information\ - \ systems, to determine which functions and services are candidates for elimination (e.g.,\ - \ Voice Over Internet Protocol, Instant Messaging, auto-execute, and file sharing). Organizations\ - \ consider disabling unused or unnecessary physical and logical ports/protocols (e.g., Universal\ - \ Serial Bus, File Transfer Protocol, and Hyper Text Transfer Protocol) on information systems\ - \ to prevent unauthorized connection of devices, unauthorized transfer of information, or unauthorized\ - \ tunneling. Organizations can utilize network scanning tools, intrusion detection and prevention\ - \ systems, and end-point protections such as firewalls and host-based intrusion detection systems\ - \ to identify and prevent the use of prohibited functions, ports, protocols, and services.\ - \ Related controls: AC-6, CM-2, RA-5, SA-5, SC-7.\n\nReferences: DoD Instruction 8551.01.\n\ - \nCM-7 (b) [United States Government Configuration Baseline (USGCB)] \nCM-7 (b) Requirement:\ - \ The service provider shall use the Center for Internet Security guidelines (Level 1) to establish\ - \ list of prohibited or restricted functions, ports, protocols, and/or services or establishes\ - \ its own list of prohibited or restricted functions, ports, protocols, and/or services if\ - \ USGCB is not available.\nCM-7 Guidance: Information on the USGCB checklists can be found\ - \ at: http://usgcb.nist.gov/usgcb_faq.html#usgcbfaq_usgcbfdcc.\n(Partially derived from AC-17(8).)" + description: "The organization:\n a. Configures the information system to provide only essential capabilities; + and\n b. Prohibits or restricts the use of the following functions, ports, protocols, and/or services: + [Assignment: organization-defined prohibited or restricted functions, ports, protocols, and/or services].\n\ + \nSupplemental Guidance: Information systems can provide a wide variety of functions and services. Some + of the functions and services, provided by default, may not be necessary to support essential organizational + operations (e.g., key missions, functions). Additionally, it is sometimes convenient to provide multiple + services from single information system components, but doing so increases risk over limiting the services + provided by any one component. Where feasible, organizations limit component functionality to a single + function per device (e.g., email servers or web servers, but not both). Organizations review functions + and services provided by information systems or individual components of information systems, to determine + which functions and services are candidates for elimination (e.g., Voice Over Internet Protocol, Instant + Messaging, auto-execute, and file sharing). Organizations consider disabling unused or unnecessary physical + and logical ports/protocols (e.g., Universal Serial Bus, File Transfer Protocol, and Hyper Text Transfer + Protocol) on information systems to prevent unauthorized connection of devices, unauthorized transfer + of information, or unauthorized tunneling. Organizations can utilize network scanning tools, intrusion + detection and prevention systems, and end-point protections such as firewalls and host-based intrusion + detection systems to identify and prevent the use of prohibited functions, ports, protocols, and services. + Related controls: AC-6, CM-2, RA-5, SA-5, SC-7.\n\nReferences: DoD Instruction 8551.01.\n\nCM-7 (b) [United + States Government Configuration Baseline (USGCB)] \nCM-7 (b) Requirement: The service provider shall use + the Center for Internet Security guidelines (Level 1) to establish list of prohibited or restricted functions, + ports, protocols, and/or services or establishes its own list of prohibited or restricted functions, ports, + protocols, and/or services if USGCB is not available.\nCM-7 Guidance: Information on the USGCB checklists + can be found at: http://usgcb.nist.gov/usgcb_faq.html#usgcbfaq_usgcbfdcc.\n(Partially derived from AC-17(8).)" title: >- CM-7 - LEAST FUNCTIONALITY levels: @@ -5276,13 +5229,12 @@ controls: - reject_unsigned_images_by_default - ocp_allowed_registries_for_import - ocp_allowed_registries - description: "The information system prevents program execution in accordance with [Selection (one\ - \ or more): [Assignment: organization-defined policies regarding software program usage and\ - \ restrictions]; rules authorizing the terms and conditions of software program usage].\n\n\ - Supplemental Guidance: Related controls: CM-8, PM-5.\n\n \nCM-7 (2) Guidance: This control\ - \ shall be implemented in a technical manner on the information system to only allow programs\ - \ to run that adhere to the policy (i.e. white listing). This control is not to be based off\ - \ of strictly written policy on what is allowed or not allowed to run." + description: "The information system prevents program execution in accordance with [Selection (one or more): + [Assignment: organization-defined policies regarding software program usage and restrictions]; rules authorizing + the terms and conditions of software program usage].\n\nSupplemental Guidance: Related controls: CM-8, + PM-5.\n\n \nCM-7 (2) Guidance: This control shall be implemented in a technical manner on the information + system to only allow programs to run that adhere to the policy (i.e. white listing). This control is not + to be based off of strictly written policy on what is allowed or not allowed to run." title: >- CM-7(2) - LEAST FUNCTIONALITY | PREVENT PROGRAM EXECUTION levels: @@ -5716,21 +5668,20 @@ controls: - reject_unsigned_images_by_default - ocp_allowed_registries_for_import - ocp_allowed_registries - 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 “app stores.” 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))]" + 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 “app stores.” 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\n\ + CM-11 (c) [Continuously (via CM-7 (5))]" title: >- CM-11 - USER-INSTALLED SOFTWARE levels: @@ -5981,22 +5932,20 @@ controls: with assigned roles and responsibilities at an organization-defined frequency is outside the scope of OpenShift configuration. 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]" + 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: @@ -6038,21 +5987,20 @@ controls: Section c: Organizational process to initiate corrective actions, if needed, are outside the scope of OpenShift configuration. 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\nReferences: 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." + 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\nReferences: 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: @@ -6220,26 +6168,23 @@ controls: Section c: This control reflects organizational procedures/policies, and is not applicable to the configuration of OpenShift. 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\nCP-7 (a) Requirement: The\ - \ service provider defines a time period consistent with the recovery time objectives and business\ - \ impact analysis." + 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\nCP-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: @@ -6522,9 +6467,9 @@ controls: and information integrity is an organizational control outside the scope of OpenShift configuration. rules: [] - description: "The organization tests backup information [Assignment: organization-defined frequency]\ - \ to verify media reliability and information integrity.\n \nSupplemental Guidance: Related\ - \ control: CP-4.\n\nCP-9 (1). [at least monthly]" + description: "The organization tests backup information [Assignment: organization-defined frequency] to verify + media reliability and information integrity.\n \nSupplemental Guidance: Related control: CP-4.\n\nCP-9 + (1). [at least monthly]" title: >- CP-9(1) - INFORMATION SYSTEM BACKUP | TESTING FOR RELIABILITY / INTEGRITY levels: @@ -6712,27 +6657,25 @@ controls: Section b: Review and updating an organizational-level identification and authentication policy and procedures are outside the scope of OpenShift configuration. 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]" + 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 @@ -7120,29 +7063,26 @@ controls: https://docs.openshift.com/container-platform/latest/authentication/understanding-identity-provider.html rules: [] - description: "The organization manages information system identifiers by:\n a. Receiving authorization\ - \ from [Assignment: organization-defined personnel or roles] to assign an individual, group,\ - \ role, or device identifier;\n b. Selecting an identifier that identifies an individual, group,\ - \ role, or device;\n c. Assigning the identifier to the intended individual, group, role, or\ - \ device;\n d. Preventing reuse of identifiers for [Assignment: organization-defined time period];\ - \ and\n e. Disabling the identifier after [Assignment: organization-defined time period of\ - \ inactivity].\n\nSupplemental Guidance: Common device identifiers include, for example, media\ - \ access control (MAC), Internet protocol (IP) addresses, or device-unique token identifiers.\ - \ Management of individual identifiers is not applicable to shared information system accounts\ - \ (e.g., guest and anonymous accounts). Typically, individual identifiers are the user names\ - \ of the information system accounts assigned to those individuals. In such instances, the\ - \ account management activities of AC-2 use account names provided by IA-4. This control also\ - \ addresses individual identifiers not necessarily associated with information system accounts\ - \ (e.g., identifiers used in physical security control databases accessed by badge reader systems\ - \ for access to information systems). Preventing reuse of identifiers implies preventing the\ - \ assignment of previously used individual, group, role, or device identifiers to different\ - \ individuals, groups, roles, or devices. Related controls: AC-2, IA-2, IA-3, IA-5, IA-8, SC-37.\n\ - \nReferences: FIPS Publication 201; NIST Special Publications 800-73, 800-76, 800-78.\nIA-4(a)\ - \ [at a minimum, the ISSO (or similar role within the organization)] \nIA-4 (d) [at least\ - \ two (2) years]\nIA-4 (e) [thirty-five (35) days] (See additional requirements and guidance.)\n\ - IA-4 (e) Requirement: The service provider defines the time period of inactivity for device\ - \ identifiers.\nGuidance: For DoD clouds, see DoD cloud website for specific DoD requirements\ - \ that go above and beyond FedRAMP http://iase.disa.mil/cloud_security/Pages/index.aspx." + description: "The organization manages information system identifiers by:\n a. Receiving authorization from + [Assignment: organization-defined personnel or roles] to assign an individual, group, role, or device + identifier;\n b. Selecting an identifier that identifies an individual, group, role, or device;\n c. Assigning + the identifier to the intended individual, group, role, or device;\n d. Preventing reuse of identifiers + for [Assignment: organization-defined time period]; and\n e. Disabling the identifier after [Assignment: + organization-defined time period of inactivity].\n\nSupplemental Guidance: Common device identifiers + include, for example, media access control (MAC), Internet protocol (IP) addresses, or device-unique token + identifiers. Management of individual identifiers is not applicable to shared information system accounts + (e.g., guest and anonymous accounts). Typically, individual identifiers are the user names of the information + system accounts assigned to those individuals. In such instances, the account management activities of + AC-2 use account names provided by IA-4. This control also addresses individual identifiers not necessarily + associated with information system accounts (e.g., identifiers used in physical security control databases + accessed by badge reader systems for access to information systems). Preventing reuse of identifiers implies + preventing the assignment of previously used individual, group, role, or device identifiers to different + individuals, groups, roles, or devices. Related controls: AC-2, IA-2, IA-3, IA-5, IA-8, SC-37.\n\nReferences: + FIPS Publication 201; NIST Special Publications 800-73, 800-76, 800-78.\nIA-4(a) [at a minimum, the ISSO + (or similar role within the organization)] \nIA-4 (d) [at least two (2) years]\nIA-4 (e) [thirty-five + (35) days] (See additional requirements and guidance.)\nIA-4 (e) Requirement: The service provider defines + the time period of inactivity for device identifiers.\nGuidance: For DoD clouds, see DoD cloud website + for specific DoD requirements that go above and beyond FedRAMP http://iase.disa.mil/cloud_security/Pages/index.aspx." title: >- IA-4 - IDENTIFIER MANAGEMENT levels: @@ -7295,6 +7235,8 @@ controls: References: OMB Memoranda 04-04, 11-11; FIPS Publication 201; NIST Special Publications 800-73, 800-63, 800-76, 800-78; FICAM Roadmap and Implementation Guidance + + IA-5 Requirement: Authenticators must be compliant with NIST SP 800-63-3 Digital Identity Guidelines IAL, AAL, FAL level 3. Link https://pages.nist.gov/800-63-3 title: >- IA-5 - AUTHENTICATOR MANAGEMENT @@ -7440,11 +7382,11 @@ controls: organization-defined personnel or roles is outside the scope of OpenShift configuration. rules: [] - description: "The organization requires that the registration process to receive [Assignment: organization-\ - \ defined types of and/or specific authenticators] be conducted [Selection: in person; by a\ - \ trusted third party] before [Assignment: organization-defined registration authority] with\ - \ authorization by [Assignment: organization-defined personnel or roles].\n\nIA-5 (3)-1 [All\ - \ hardware/biometric (multifactor authenticators] \nIA-5 (3)-2 [in person]" + description: "The organization requires that the registration process to receive [Assignment: organization- + defined types of and/or specific authenticators] be conducted [Selection: in person; by a trusted third + party] before [Assignment: organization-defined registration authority] with authorization by [Assignment: + organization-defined personnel or roles].\n\nIA-5 (3)-1 [All hardware/biometric (multifactor authenticators]\ + \ \nIA-5 (3)-2 [in person]" title: >- IA-5(3) - AUTHENTICATOR MANAGEMENT | IN-PERSON OR TRUSTED THIRD-PARTY REGISTRATION levels: @@ -7861,25 +7803,23 @@ controls: Section b.2: This control reflects organizational procedures/policies, and is not applicable to the configuration of OpenShift. rules: [] - description: "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined\ - \ personnel or roles]:\n 1. An incident response 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 incident response\ - \ policy and associated incident response controls; and\n b. Reviews and updates the current:\n\ - \ 1. Incident response policy [Assignment: organization-defined frequency]; and\n 2. Incident\ - \ response 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 IR 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-61, 800-83, 800-100.\n\nIR-1 (b) (1) [at\ - \ least annually] \nIR-1 (b) (2) [at least annually or whenever a significant change occurs]" + description: "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined + personnel or roles]:\n 1. An incident response 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 incident response policy and associated incident response controls; + and\n b. Reviews and updates the current:\n 1. Incident response policy [Assignment: organization-defined + frequency]; and\n 2. Incident response procedures [Assignment: organization-defined frequency].\n\n\ + Supplemental Guidance: This control addresses the establishment of policy and procedures for the effective + implementation of selected security controls and control enhancements in the IR 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-61, 800-83, 800-100.\n\nIR-1 (b) (1) [at least annually]\ + \ \nIR-1 (b) (2) [at least annually or whenever a significant change occurs]" title: >- IR-1 - INCIDENT RESPONSE POLICY AND PROCEDURES levels: @@ -7994,26 +7934,24 @@ controls: Section c: This control reflects organizational procedures/policies, and is not applicable to the configuration of OpenShift. rules: [] - description: "The organization:\na. Implements an incident handling capability for security incidents\ - \ that includes preparation, detection and analysis, containment, eradication, and recovery;\n\ - b. 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\nReferences: 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." + 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\nReferences: 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: @@ -8111,18 +8049,17 @@ controls: This control reflects organizational procedures/policies and is not applicable to OpenShift configuration. rules: [] - description: "The organization coordinates with [Assignment: organization-defined external organizations]\ - \ to correlate and share [Assignment: organization-defined incident information] to achieve\ - \ a cross- organization perspective on incident awareness and more effective incident responses.\n\ - \nSupplemental Guidance: The coordination of incident information with external organizations\ - \ including, for example, mission/business partners, military/coalition partners, customers,\ - \ and multitiered developers, can provide significant benefits. Cross-organizational coordination\ - \ with respect to incident handling can serve as an important risk management capability. This\ - \ capability allows organizations to leverage critical information from a variety of sources\ - \ to effectively respond to information security-related incidents potentially affecting the\ - \ organization’s operations, assets, and individuals.\n\nIR-4 (8) [external organizations including\ - \ consumer incident responders and network defenders and the appropriate CIRT/CERT (such as\ - \ US-CERT, DOD CERT, IC CERT)]" + description: "The organization coordinates with [Assignment: organization-defined external organizations] + to correlate and share [Assignment: organization-defined incident information] to achieve a cross- organization + perspective on incident awareness and more effective incident responses.\n\nSupplemental Guidance: The + coordination of incident information with external organizations including, for example, mission/business + partners, military/coalition partners, customers, and multitiered developers, can provide significant + benefits. Cross-organizational coordination with respect to incident handling can serve as an important + risk management capability. This capability allows organizations to leverage critical information from + a variety of sources to effectively respond to information security-related incidents potentially affecting + the organization’s operations, assets, and individuals.\n\nIR-4 (8) [external organizations including + consumer incident responders and network defenders and the appropriate CIRT/CERT (such as US-CERT, DOD + CERT, IC CERT)]" title: >- IR-4(8) - INCIDENT HANDLING | CORRELATION WITH EXTERNAL ORGANIZATIONS levels: @@ -8562,18 +8499,17 @@ controls: This control reflects organizational procedures/policies, and is not applicable to the configuration of OpenShift. 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 “ping,” “ls,” “ipconfig,” 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." + description: "The organization approves, controls, and monitors information system maintenance tools.\n\n\ + Supplemental 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 “ping,” “ls,” “ipconfig,” 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: @@ -8632,15 +8568,14 @@ controls: of the equipment from the facility is outside the scope of OpenShift configuration. 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\n\ - Supplemental 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]" + 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: @@ -9038,29 +8973,26 @@ controls: Section b: This control reflects organizational procedure/policy and is not applicable to OpenShift configuration. rules: [] - description: "The organization:\n a. Physically controls and securely stores [Assignment: organization-defined\ - \ types of digital and/or non-digital media] within [Assignment: organization-defined controlled\ - \ areas]; and\n b. Protects information system media until the media are destroyed or sanitized\ - \ using approved equipment, techniques, and procedures.\n\nSupplemental 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. Physically\ - \ controlling information system media includes, for example, conducting inventories, ensuring\ - \ procedures are in place to allow individuals to check out and return media to the media library,\ - \ and maintaining accountability for all stored media. Secure storage includes, for example,\ - \ a locked drawer, desk, or cabinet, or a controlled media library. The type of media storage\ - \ is commensurate with the security category and/or classification of the information residing\ - \ on the media. Controlled areas are areas for which organizations provide sufficient physical\ - \ and procedural safeguards to meet the requirements established for protecting information\ - \ and/or information systems. For media containing information determined by organizations\ - \ to be in the public domain, to be publicly releasable, or to have limited or no adverse impact\ - \ on organizations or individuals if accessed by other than authorized personnel, fewer safeguards\ - \ may be needed. In these situations, physical access controls provide adequate protection.\ - \ Related controls: CP-6, CP-9, MP-2, MP-7, PE-3.\n\nReferences: FIPS Publication 199; NIST\ - \ Special Publications 800-56, 800-57, 800-111.\n\nMP-4 (a)-1 [all types of digital and non-digital\ - \ media with sensitive information] \nMP-4 (a)-2 [see additional FedRAMP requirements and guidance]\n\ - MP-4 (a) Requirement: The service provider defines controlled areas within facilities where\ - \ the information and information system reside." + description: "The organization:\n a. Physically controls and securely stores [Assignment: organization-defined + types of digital and/or non-digital media] within [Assignment: organization-defined controlled areas]; + and\n b. Protects information system media until the media are destroyed or sanitized using approved equipment, + techniques, and procedures.\n\nSupplemental 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. Physically controlling information system media includes, for example, conducting + inventories, ensuring procedures are in place to allow individuals to check out and return media to the + media library, and maintaining accountability for all stored media. Secure storage includes, for example, + a locked drawer, desk, or cabinet, or a controlled media library. The type of media storage is commensurate + with the security category and/or classification of the information residing on the media. Controlled + areas are areas for which organizations provide sufficient physical and procedural safeguards to meet + the requirements established for protecting information and/or information systems. For media containing + information determined by organizations to be in the public domain, to be publicly releasable, or to have + limited or no adverse impact on organizations or individuals if accessed by other than authorized personnel, + fewer safeguards may be needed. In these situations, physical access controls provide adequate protection. + Related controls: CP-6, CP-9, MP-2, MP-7, PE-3.\n\nReferences: FIPS Publication 199; NIST Special Publications + 800-56, 800-57, 800-111.\n\nMP-4 (a)-1 [all types of digital and non-digital media with sensitive information]\ + \ \nMP-4 (a)-2 [see additional FedRAMP requirements and guidance]\nMP-4 (a) Requirement: The service provider + defines controlled areas within facilities where the information and information system reside." title: >- MP-4 - MEDIA STORAGE levels: @@ -9339,26 +9271,24 @@ controls: procedure/policy and is not applicable to component-level configuration. rules: [] - description: "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined\ - \ personnel or roles]:\n 1. A physical and environmental 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 physical\ - \ and environmental protection policy and associated physical and environmental protection\ - \ controls; and\n b. Reviews and updates the current:\n 1. Physical and environmental protection\ - \ policy [Assignment: organization-defined frequency]; and\n 2. Physical and environmental\ - \ 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 PE 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\nPE-1 (b) (1) [at least annually]\ - \ \nPE-1 (b) (2) [at least annually or whenever a significant change occurs]" + description: "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined + personnel or roles]:\n 1. A physical and environmental 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 physical and environmental protection policy + and associated physical and environmental protection controls; and\n b. Reviews and updates the current:\n\ + \ 1. Physical and environmental protection policy [Assignment: organization-defined frequency]; and\n\ + \ 2. Physical and environmental 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 PE 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\nPE-1 (b) (1) [at least annually] \nPE-1 (b) + (2) [at least annually or whenever a significant change occurs]" title: >- PE-1 - PHYSICAL AND ENVIRONMENTAL PROTECTION @@ -9400,6 +9330,7 @@ controls: References: None + PE-2 (c) [at least every ninety (90) days] title: >- PE-2 - PHYSICAL ACCESS AUTHORIZATIONS @@ -10136,48 +10067,43 @@ controls: Section e: This control reflects organizational procedures/policies, and is not applicable to the configuration of OpenShift. rules: [] - description: "The organization:\n a. Develops a security plan for the information system that:\n\ - \ 1. Is consistent with the organization’s 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]" + description: "The organization:\n a. Develops a security plan for the information system that:\n 1. Is consistent + with the organization’s 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: @@ -10298,50 +10224,45 @@ controls: Section c: This control reflects organizational procedures/policies, and is not applicable to the configuration of OpenShift. 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’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’s 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." + 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’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’s + 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: @@ -10533,25 +10454,23 @@ controls: a personnel security policy to organization-defined personnel is outside the scope of OpenShift configuration. 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]" + 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\n\ + Supplemental 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: @@ -10656,14 +10575,13 @@ controls: personnel screening criteria, are outside the scope of OpenShift configuration. 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 – as required by specific information]" + 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 – as required by specific information]" title: >- PS-3(3) - PERSONNEL SCREENING | INFORMATION WITH SPECIAL PROTECTION MEASURES levels: @@ -10743,17 +10661,16 @@ controls: an individual, is outside the scope of OpenShift configuration. rules: [] - description: "The organization employs automated mechanisms to notify [Assignment: organization-defined\ - \ personnel or roles] upon termination of an individual.\n\nSupplemental Guidance: In organizations\ - \ with a large number of employees, not all personnel who need to know about termination actions\ - \ receive the appropriate notifications—or, if such notifications are received, they may not\ - \ occur in a timely manner. Automated mechanisms\ncan be used to send automatic alerts or notifications\ - \ to specific organizational personnel or roles (e.g., management personnel, supervisors, personnel\ - \ security officers, information security officers, systems administrators, or information\ - \ technology administrators) when individuals are terminated. Such automatic alerts or notifications\ - \ can be conveyed in a variety of ways, including, for example, telephonically, via electronic\ - \ mail, via text message, or via websites.\n\nPS-4 (2) [access control personnel responsible\ - \ for disabling access to the system]" + description: "The organization employs automated mechanisms to notify [Assignment: organization-defined personnel + or roles] upon termination of an individual.\n\nSupplemental Guidance: In organizations with a large + number of employees, not all personnel who need to know about termination actions receive the appropriate + notifications—or, if such notifications are received, they may not occur in a timely manner. Automated + mechanisms\ncan be used to send automatic alerts or notifications to specific organizational personnel + or roles (e.g., management personnel, supervisors, personnel security officers, information security officers, + systems administrators, or information technology administrators) when individuals are terminated. Such + automatic alerts or notifications can be conveyed in a variety of ways, including, for example, telephonically, + via electronic mail, via text message, or via websites.\n\nPS-4 (2) [access control personnel responsible + for disabling access to the system]" title: >- PS-4(2) - PERSONNEL TERMINATION | AUTOMATED NOTIFICATION levels: @@ -10780,24 +10697,22 @@ controls: or roles within an organization-defined time period are outside the scope of OpenShift configuration. 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]" + 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: @@ -10907,26 +10822,23 @@ controls: Section e: Organizational monitoring of provider compliance is outside the scope of OpenShift configuration. 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\n\ - References: NIST Special Publication 800-35.\n\nPS-7 (d)-2 [terminations: immediately; transfers:\ - \ within twenty-four (24) hours]" + 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: @@ -10990,25 +10902,23 @@ controls: and risk assessment procedures is outside the scope of OpenShift configuration. 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]" + 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: @@ -11078,41 +10988,37 @@ controls: or other conditions that may impact the security state of the system, are outside the scope of OpenShift configuration. 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\n\ - entities). 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." + 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: @@ -11170,48 +11076,43 @@ controls: of OpenShift configuration. rules: - scansettingbinding_exists - 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.\n\ - RA-5 (e) Requirement: to include all Authorizing Officials; for JAB authorizations to include\ - \ FedRAMP" + 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/\n\ + RA-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: @@ -11305,14 +11206,13 @@ controls: Cluster Administators are able to access and run the operator for compliance and vulnerability scans. rules: - scansettingbinding_exists - 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]" + 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: @@ -11349,11 +11249,11 @@ controls: previously exploited is outside the scope of OpenShift configuration. 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." + 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\n\ + RA-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: @@ -11372,9 +11272,9 @@ controls: multi-vulnerability/multi-hop attack vectors are outside the scope of OpenShift configuration. rules: [] - description: "The organization correlates the output from vulnerability scanning tools to determine\ - \ the presence of multi-vulnerability/multi-hop attack vectors.\n\n \nRA-5 (10) Guidance: If\ - \ multiple tools are not used, this control is not applicable." + description: "The organization correlates the output from vulnerability scanning tools to determine the presence + of multi-vulnerability/multi-hop attack vectors.\n\n \nRA-5 (10) Guidance: If multiple tools are not used, + this control is not applicable." title: >- RA-5(10) - VULNERABILITY SCANNING | CORRELATE SCANNING INFORMATION levels: @@ -11460,15 +11360,14 @@ controls: information security in organizational programming and budgeting documentation are outside the scope of OpenShift configuration. 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." + 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: @@ -11790,37 +11689,33 @@ controls: Section e: This control reflects organizational procedure/policy and is not applicable to OpenShift configuration. 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)]" + 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: @@ -12027,35 +11922,32 @@ controls: Section e: Official Red Hat CVE findings can be found at: https://access.redhat.com/security/security-updates/#/cve rules: [] - description: "The organization requires the developer of the information system, system component,\ - \ or information system service to:\n a. Perform configuration management during system, component,\ - \ or service [Selection (one or more): design; development; implementation; operation];\n b.\ - \ Document, manage, and control the integrity of changes to [Assignment: organization-defined\ - \ configuration items under configuration management];\n c. Implement only organization-approved\ - \ changes to the system, component, or service;\n d. Document approved changes to the system,\ - \ component, or service and the potential security impacts of such changes; and\n e. Track\ - \ security flaws and flaw resolution within the system, component, or service and report findings\ - \ to [Assignment: organization-defined personnel].\n \nSupplemental Guidance: This control\ - \ also applies to organizations conducting internal information systems development and integration.\ - \ Organizations consider the quality and completeness of the configuration management activities\ - \ conducted by developers as evidence of applying effective security safeguards. Safeguards\ - \ include, for example, protecting from unauthorized modification or destruction, the master\ - \ copies of all material used to generate security-relevant portions of the system hardware,\ - \ software, and firmware. Maintaining the integrity of changes to the information system, information\ - \ system component, or information system service requires configuration control throughout\ - \ the system development life cycle to track authorized changes and prevent unauthorized changes.\ - \ Configuration items that are placed under configuration management (if existence/use is required\ - \ by other security controls) include: the formal model; the functional, high-level, and low-level\ - \ design specifications; other design data; implementation documentation; source code and hardware\ - \ schematics; the running version of the object code; tools for comparing new versions of security-relevant\ - \ hardware descriptions and software/firmware source code with previous versions; and test\ - \ fixtures and documentation. Depending on the mission/business needs of organizations and\ - \ the nature of the contractual relationships in place, developers may provide configuration\ - \ management support during the operations and maintenance phases of the life cycle. Related\ - \ controls: CM-3, CM-4, CM-9, SA-12, SI-2.\n\nReferences: NIST Special Publication 800-128.\n\ - \nSA-10 (a) [development, implementation, AND operation]\nSA-10 (e) Requirement: for JAB authorizations,\ - \ track security flaws and flaw resolution within the system, component, or service and report\ - \ findings to organization-defined personnel, to include FedRAMP." + description: "The organization requires the developer of the information system, system component, or information + system service to:\n a. Perform configuration management during system, component, or service [Selection + (one or more): design; development; implementation; operation];\n b. Document, manage, and control the + integrity of changes to [Assignment: organization-defined configuration items under configuration management];\n\ + \ c. Implement only organization-approved changes to the system, component, or service;\n d. Document + approved changes to the system, component, or service and the potential security impacts of such changes; + and\n e. Track security flaws and flaw resolution within the system, component, or service and report + findings to [Assignment: organization-defined personnel].\n \nSupplemental Guidance: This control also + applies to organizations conducting internal information systems development and integration. Organizations + consider the quality and completeness of the configuration management activities conducted by developers + as evidence of applying effective security safeguards. Safeguards include, for example, protecting from + unauthorized modification or destruction, the master copies of all material used to generate security-relevant + portions of the system hardware, software, and firmware. Maintaining the integrity of changes to the information + system, information system component, or information system service requires configuration control throughout + the system development life cycle to track authorized changes and prevent unauthorized changes. Configuration + items that are placed under configuration management (if existence/use is required by other security controls) + include: the formal model; the functional, high-level, and low-level design specifications; other design + data; implementation documentation; source code and hardware schematics; the running version of the object + code; tools for comparing new versions of security-relevant hardware descriptions and software/firmware + source code with previous versions; and test fixtures and documentation. Depending on the mission/business + needs of organizations and the nature of the contractual relationships in place, developers may provide + configuration management support during the operations and maintenance phases of the life cycle. Related + controls: CM-3, CM-4, CM-9, SA-12, SI-2.\n\nReferences: NIST Special Publication 800-128.\n\nSA-10 (a) + [development, implementation, AND operation]\nSA-10 (e) Requirement: for JAB authorizations, track security + flaws and flaw resolution within the system, component, or service and report findings to organization-defined + personnel, to include FedRAMP." title: >- SA-10 - DEVELOPER CONFIGURATION MANAGEMENT levels: @@ -12144,38 +12036,34 @@ controls: https://issues.redhat.com/browse/CMP-374 rules: [] - description: "The organization requires the developer of the information system, system component,\ - \ or information system service to:\n a. Create and implement a security assessment plan;\n\ - \ b. Perform [Selection (one or more): unit; integration; system; regression] testing/evaluation\ - \ at [Assignment: organization-defined depth and coverage];\n c. Produce evidence of the execution\ - \ of the security assessment plan and the results of the security testing/evaluation;\n d.\ - \ Implement a verifiable flaw remediation process; and\n e. Correct flaws identified during\ - \ security testing/evaluation.\n\nSupplemental Guidance: Developmental security testing/evaluation\ - \ occurs at all post‐design phases of the system development life cycle. Such testing/evaluation\ - \ confirms that the required security controls are implemented correctly, operating as intended,\ - \ enforcing the desired security policy, and meeting established security requirements. Security\ - \ properties of information systems may be affected by the interconnection of system components\ - \ or changes to those components. These interconnections or changes (e.g., upgrading or replacing\ - \ applications and operating systems) may adversely affect previously implemented security\ - \ controls. This control provides additional types of security testing/evaluation that developers\ - \ can conduct to reduce or eliminate potential flaws. Testing custom software applications\ - \ may require approaches such as static analysis, dynamic analysis, binary analysis, or a hybrid\ - \ of the three approaches. Developers 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. Security assessment plans provide the specific activities that developers\ - \ plan to carry out including the types of analyses, testing, evaluation, and reviews of software\ - \ and firmware components, the degree of rigor to be applied, and the types of artifacts produced\ - \ during those processes. The depth of security testing/evaluation refers to the rigor and\ - \ level of detail associated with the assessment process (e.g., black box, gray box, or white\ - \ box testing). The coverage of security testing/evaluation refers to the scope (i.e., number\ - \ and type) of the artifacts included in the assessment process. Contracts specify the acceptance\ - \ criteria for security assessment plans, flaw remediation processes, and the evidence that\ - \ the plans/processes have been diligently applied. Methods for reviewing and protecting assessment\ - \ plans, evidence, and documentation are commensurate with the security category or classification\ - \ level of the information system. Contracts may specify documentation protection requirements.\ - \ Related controls: CA-2, CM-4, SA-3, SA-4, SA-5, SI-2.\n\nReferences: ISO/IEC 15408; NIST\ - \ Special Publication 800-53A; Web: http://nvd.nist.gov, http://cwe.mitre.org, http://cve.mitre.org,\ - \ http://capec.mitre.org." + description: "The organization requires the developer of the information system, system component, or information + system service to:\n a. Create and implement a security assessment plan;\n b. Perform [Selection (one + or more): unit; integration; system; regression] testing/evaluation at [Assignment: organization-defined + depth and coverage];\n c. Produce evidence of the execution of the security assessment plan and the results + of the security testing/evaluation;\n d. Implement a verifiable flaw remediation process; and\n e. Correct + flaws identified during security testing/evaluation.\n\nSupplemental Guidance: Developmental security + testing/evaluation occurs at all post‐design phases of the system development life cycle. Such testing/evaluation + confirms that the required security controls are implemented correctly, operating as intended, enforcing + the desired security policy, and meeting established security requirements. Security properties of information + systems may be affected by the interconnection of system components or changes to those components. These + interconnections or changes (e.g., upgrading or replacing applications and operating systems) may adversely + affect previously implemented security controls. This control provides additional types of security testing/evaluation + that developers can conduct to reduce or eliminate potential flaws. Testing custom software applications + may require approaches such as static analysis, dynamic analysis, binary analysis, or a hybrid of the + three approaches. Developers 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. Security assessment + plans provide the specific activities that developers plan to carry out including the types of analyses, + testing, evaluation, and reviews of software and firmware components, the degree of rigor to be applied, + and the types of artifacts produced during those processes. The depth of security testing/evaluation refers + to the rigor and level of detail associated with the assessment process (e.g., black box, gray box, or + white box testing). The coverage of security testing/evaluation refers to the scope (i.e., number and + type) of the artifacts included in the assessment process. Contracts specify the acceptance criteria for + security assessment plans, flaw remediation processes, and the evidence that the plans/processes have + been diligently applied. Methods for reviewing and protecting assessment plans, evidence, and documentation + are commensurate with the security category or classification level of the information system. Contracts + may specify documentation protection requirements. Related controls: CA-2, CM-4, SA-3, SA-4, SA-5, SI-2.\n\ + \nReferences: ISO/IEC 15408; NIST Special Publication 800-53A; Web: http://nvd.nist.gov, http://cwe.mitre.org, + http://cve.mitre.org, http://capec.mitre.org." title: >- SA-11 - DEVELOPER SECURITY TESTING AND EVALUATION levels: @@ -12467,24 +12355,22 @@ controls: [1]https://www.redhat.com/en/topics/devops/what-is-devsecops#built-in-security [2]https://csrc.nist.gov/publications/detail/nistir/8176/final rules: [] - description: "The organization:\n a. Requires the developer of the information system, system component,\ - \ or information system service to follow a documented development process that:\n 1. Explicitly\ - \ addresses security requirements;\n 2. Identifies the standards and tools used in the development\ - \ process;\n 3. Documents the specific tool options and tool configurations used in the development\ - \ process; and\n 4. Documents, manages, and ensures the integrity of changes to the process\ - \ and/or tools used in development; and\n b. Reviews the development process, standards, tools,\ - \ and tool options/configurations [Assignment: organization-defined frequency] to determine\ - \ if the process, standards, tools, and tool options/configurations selected and employed can\ - \ satisfy [Assignment: organization- defined security requirements].\n\nSupplemental Guidance:\ - \ Development tools include, for example, programming languages and computer-aided design\ - \ (CAD) systems. Reviews of development processes can include, for example, the use of maturity\ - \ models to determine the potential effectiveness of such processes. Maintaining the integrity\ - \ of changes to tools and processes enables accurate supply chain risk assessment and mitigation,\ - \ and requires robust configuration control throughout the life cycle (including design, development,\ - \ transport, delivery, integration, and maintenance) to track authorized changes and prevent\ - \ unauthorized changes. Related controls: SA-3, SA-8.\n\nReferences: None.\n\nSA-15 (b)-1 [as\ - \ needed and as dictated by the current threat posture] \nSA-15 (b)-2 [organization and service\ - \ provider- defined security requirements]" + description: "The organization:\n a. Requires the developer of the information system, system component, or + information system service to follow a documented development process that:\n 1. Explicitly addresses + security requirements;\n 2. Identifies the standards and tools used in the development process;\n \ + \ 3. Documents the specific tool options and tool configurations used in the development process; and\n\ + \ 4. Documents, manages, and ensures the integrity of changes to the process and/or tools used in development; + and\n b. Reviews the development process, standards, tools, and tool options/configurations [Assignment: + organization-defined frequency] to determine if the process, standards, tools, and tool options/configurations + selected and employed can satisfy [Assignment: organization- defined security requirements].\n\nSupplemental + Guidance: Development tools include, for example, programming languages and computer-aided design (CAD) + systems. Reviews of development processes can include, for example, the use of maturity models to determine + the potential effectiveness of such processes. Maintaining the integrity of changes to tools and processes + enables accurate supply chain risk assessment and mitigation, and requires robust configuration control + throughout the life cycle (including design, development, transport, delivery, integration, and maintenance) + to track authorized changes and prevent unauthorized changes. Related controls: SA-3, SA-8.\n\nReferences: + None.\n\nSA-15 (b)-1 [as needed and as dictated by the current threat posture] \nSA-15 (b)-2 [organization + and service provider- defined security requirements]" title: >- SA-15 - DEVELOPMENT PROCESS, STANDARDS, AND @@ -12624,22 +12510,20 @@ controls: Jira also requires a signoff by the documentation team. rules: [] - description: "The organization requires the developer of the information system, system component,\ - \ or information system service to produce a design specification and security architecture\ - \ that:\n a. Is consistent with and supportive of the organization’s security architecture\ - \ which is established within and is an integrated part of the organization’s enterprise architecture;\n\ - \ b. Accurately and completely describes the required security functionality, and the allocation\ - \ of security controls among physical and logical components; and\n c. Expresses how individual\ - \ security functions, mechanisms, and services work together to provide required security capabilities\ - \ and a unified approach to protection.\n\nSupplemental Guidance: This control is primarily\ - \ directed at external developers, although it could also be used for internal (in-house) development.\ - \ In contrast, PL-8 is primarily directed at internal developers to help ensure that organizations\ - \ develop an information security architecture and such security architecture is integrated\ - \ or tightly coupled to the enterprise architecture. This distinction is important if/when\ - \ organizations outsource the development of information systems, information system components,\ - \ or information system services to external entities, and there is a requirement to demonstrate\ - \ consistency with the organization’s enterprise architecture and information security architecture.\ - \ Related controls: PL-8, PM-7, SA-3, SA-8.\n\nReferences: None." + description: "The organization requires the developer of the information system, system component, or information + system service to produce a design specification and security architecture that:\n a. Is consistent with + and supportive of the organization’s security architecture which is established within and is an integrated + part of the organization’s enterprise architecture;\n b. Accurately and completely describes the required + security functionality, and the allocation of security controls among physical and logical components; + and\n c. Expresses how individual security functions, mechanisms, and services work together to provide + required security capabilities and a unified approach to protection.\n\nSupplemental Guidance: This control + is primarily directed at external developers, although it could also be used for internal (in-house) development. + In contrast, PL-8 is primarily directed at internal developers to help ensure that organizations develop + an information security architecture and such security architecture is integrated or tightly coupled to + the enterprise architecture. This distinction is important if/when organizations outsource the development + of information systems, information system components, or information system services to external entities, + and there is a requirement to demonstrate consistency with the organization’s enterprise architecture + and information security architecture. Related controls: PL-8, PM-7, SA-3, SA-8.\n\nReferences: None." title: >- SA-17 - DEVELOPER SECURITY ARCHITECTURE AND DESIGN levels: @@ -12867,26 +12751,24 @@ controls: Section b: This control reflects organizational procedures/policies, and is not applicable to the configuration of OpenShift. 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]\ - \ \nSC-1 (b) (2) [at least annually or whenever a significant change occurs]" + 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] \nSC-1 + (b) (2) [at least annually or whenever a significant change occurs]" title: >- SC-1 - SYSTEM AND COMMUNICATIONS PROTECTION @@ -13332,15 +13214,14 @@ controls: is an organizational control outside the scope of OpenShift configuration and is typically handled at the network infrastructure layer. rules: [] - description: "The organization:\n (a) Implements a managed interface for each external telecommunication\ - \ service; \n (b) Establishes a traffic flow policy for each managed interface;\n (c) Protects\ - \ the confidentiality and integrity of the information being transmitted across each interface;\n\ - \ (d) Documents each exception to the traffic flow policy with a supporting mission/business\ - \ need and duration of that need; and\n (e) Reviews exceptions to the traffic flow policy\ - \ [Assignment: organization-defined frequency] and removes exceptions that are no longer supported\ - \ by an explicit mission/business need.\n\nSupplemental Guidance: Related control: SC-8.\n\ - \nSC-7 (4) (e) [at least every ninety (90) days or whenever there is a change in the threat\ - \ environment that warrants a review of the exceptions]" + description: "The organization:\n (a) Implements a managed interface for each external telecommunication + service; \n (b) Establishes a traffic flow policy for each managed interface;\n (c) Protects the confidentiality + and integrity of the information being transmitted across each interface;\n (d) Documents each exception + to the traffic flow policy with a supporting mission/business need and duration of that need; and\n (e)\ + \ Reviews exceptions to the traffic flow policy [Assignment: organization-defined frequency] and removes + exceptions that are no longer supported by an explicit mission/business need.\n\nSupplemental Guidance:\ + \ Related control: SC-8.\n\nSC-7 (4) (e) [at least every ninety (90) days or whenever there is a change + in the threat environment that warrants a review of the exceptions]" title: >- SC-7(4) - BOUNDARY PROTECTION | EXTERNAL TELECOMMUNICATIONS SERVICES levels: @@ -13569,15 +13450,14 @@ controls: a boundary protection device and is therefore not applicable to the OpenShift Platform rules: [] - description: "The information system fails securely in the event of an operational failure of a\ - \ boundary protection device.\n \nSupplemental Guidance: Fail secure is a condition achieved\ - \ by employing information system mechanisms to ensure that in the event of operational failures\ - \ of boundary protection devices at managed interfaces (e.g., routers, firewalls, guards, and\ - \ application gateways residing on protected subnetworks commonly referred to as demilitarized\ - \ zones), information systems do not enter into unsecure states where intended security properties\ - \ no longer hold. Failures of boundary protection devices cannot lead to, or cause information\ - \ external to the devices to enter the devices, nor can failures permit unauthorized information\ - \ releases. Related controls: CP-2, SC-24." + description: "The information system fails securely in the event of an operational failure of a boundary protection + device.\n \nSupplemental Guidance: Fail secure is a condition achieved by employing information system + mechanisms to ensure that in the event of operational failures of boundary protection devices at managed + interfaces (e.g., routers, firewalls, guards, and application gateways residing on protected subnetworks + commonly referred to as demilitarized zones), information systems do not enter into unsecure states where + intended security properties no longer hold. Failures of boundary protection devices cannot lead to, or + cause information external to the devices to enter the devices, nor can failures permit unauthorized information + releases. Related controls: CP-2, SC-24." title: >- SC-7(18) - BOUNDARY PROTECTION | FAIL SECURE levels: @@ -13741,17 +13621,15 @@ controls: - api_server_tls_security_profile - ingress_controller_tls_security_profile - kubelet_configure_tls_min_version - description: "The information system implements cryptographic mechanisms to [Selection (one or\ - \ more): prevent unauthorized disclosure of information; detect changes to information] during\ - \ transmission unless otherwise protected by [Assignment: organization-defined alternative\ - \ physical safeguards].\n\nSupplemental Guidance: Encrypting information for transmission protects\ - \ information from unauthorized disclosure and modification. Cryptographic mechanisms implemented\ - \ to protect information integrity include, for example, cryptographic hash functions which\ - \ have common application in digital signatures, checksums, and message authentication codes.\ - \ Alternative physical security safeguards include, for example, protected distribution systems.\ - \ Related control: SC-13.\n\nSC-8 (1)-1 [prevent unauthorized disclosure of information AND\ - \ detect changes to information] \nSC-8 (1)-2 [a hardened or alarmed carrier Protective Distribution\ - \ System (PDS)]" + description: "The information system implements cryptographic mechanisms to [Selection (one or more): prevent + unauthorized disclosure of information; detect changes to information] during transmission unless otherwise + protected by [Assignment: organization-defined alternative physical safeguards].\n\nSupplemental Guidance: + Encrypting information for transmission protects information from unauthorized disclosure and modification. + Cryptographic mechanisms implemented to protect information integrity include, for example, cryptographic + hash functions which have common application in digital signatures, checksums, and message authentication + codes. Alternative physical security safeguards include, for example, protected distribution systems. + Related control: SC-13.\n\nSC-8 (1)-1 [prevent unauthorized disclosure of information AND detect changes + to information] \nSC-8 (1)-2 [a hardened or alarmed carrier Protective Distribution System (PDS)]" title: >- SC-8(1) - TRANSMISSION CONFIDENTIALITY AND INTEGRITY | CRYPTOGRAPHIC OR ALTERNATE PHYSICAL PROTECTION @@ -13974,10 +13852,10 @@ controls: rules: - fips_mode_enabled_on_all_nodes - 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’s private key]." + 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’s private key]." title: >- SC-12(3) - CRYPTOGRAPHIC KEY ESTABLISHMENT AND MANAGEMENT | @@ -14283,24 +14161,22 @@ controls: [1] https://docs.openshift.com/container-platform/4.6/installing/installing_platform_agnostic/installing-platform-agnostic.html#installation-dns-user-infra_installing-platform-agnostic rules: [] - description: "The information system:\n a. Provides additional data origin and integrity artifacts\ - \ along with the authoritative name resolution data the system returns in response to external\ - \ name/address resolution queries; and\n b. Provides the means to indicate the security status\ - \ of child zones and (if the child supports secure resolution services) to enable verification\ - \ of a chain of trust among parent and child domains, when operating as part of a distributed,\ - \ hierarchical namespace.\n \nSupplemental Guidance: This control enables external clients\ - \ including, for example, remote Internet clients, to obtain origin authentication and integrity\ - \ verification assurances for the host/service name to network address resolution information\ - \ obtained through the service. Information systems that provide name and address resolution\ - \ services include, for example, domain name system (DNS) servers. Additional artifacts include,\ - \ for example, DNS Security (DNSSEC) digital signatures and cryptographic keys. DNS resource\ - \ records are examples of authoritative data. The means to indicate the security status of\ - \ child zones includes, for example, the use of delegation signer resource records in the DNS.\ - \ The DNS security controls reflect (and are referenced from) OMB Memorandum 08-23. Information\ - \ systems that use technologies other than the DNS to map between host/service names and network\ - \ addresses provide other means to assure the authenticity and integrity of response data.\ - \ Related controls: AU-10, SC-8, SC-12, SC-13, SC-21, SC-22. \n\nReferences: OMB Memorandum\ - \ 08-23; NIST Special Publication 800-81." + description: "The information system:\n a. Provides additional data origin and integrity artifacts along with + the authoritative name resolution data the system returns in response to external name/address resolution + queries; and\n b. Provides the means to indicate the security status of child zones and (if the child + supports secure resolution services) to enable verification of a chain of trust among parent and child + domains, when operating as part of a distributed, hierarchical namespace.\n \nSupplemental Guidance: \ + \ This control enables external clients including, for example, remote Internet clients, to obtain origin + authentication and integrity verification assurances for the host/service name to network address resolution + information obtained through the service. Information systems that provide name and address resolution + services include, for example, domain name system (DNS) servers. Additional artifacts include, for example, + DNS Security (DNSSEC) digital signatures and cryptographic keys. DNS resource records are examples of + authoritative data. The means to indicate the security status of child zones includes, for example, the + use of delegation signer resource records in the DNS. The DNS security controls reflect (and are referenced + from) OMB Memorandum 08-23. Information systems that use technologies other than the DNS to map between + host/service names and network addresses provide other means to assure the authenticity and integrity + of response data. Related controls: AU-10, SC-8, SC-12, SC-13, SC-21, SC-22. \n\nReferences: OMB Memorandum + 08-23; NIST Special Publication 800-81." title: >- SC-20 - SECURE NAME /ADDRESS RESOLUTION SERVICE @@ -14366,21 +14242,19 @@ controls: https://issues.redhat.com/browse/CMP-409 rules: [] - description: "The information systems that collectively provide name/address resolution service\ - \ for an organization are fault-tolerant and implement internal/external role separation.\n\ - \ \nSupplemental Guidance: Information systems that provide name and address resolution services\ - \ include, for example, domain name system (DNS) servers. To eliminate single points of failure\ - \ and to enhance redundancy, organizations employ at least two authoritative domain name system\ - \ servers, one configured as the primary server and the other configured as the secondary server.\ - \ Additionally, organizations typically deploy the servers in two geographically separated\ - \ network subnetworks (i.e., not located in the same physical facility). For role separation,\ - \ DNS servers with internal roles only process name and address resolution requests from within\ - \ organizations (i.e., from internal clients). DNS servers with external roles only process\ - \ name and address resolution information requests from clients external to organizations (i.e.,\ - \ on external networks including\nthe Internet). Organizations specify clients that can access\ - \ authoritative DNS servers in particular roles (e.g., by address ranges, explicit lists).\ - \ Related controls: SC-2, SC-20, SC-21, SC-24.\n\nControl Enhancements: None.\n\nReferences:\ - \ NIST Special Publication 800-81." + description: "The information systems that collectively provide name/address resolution service for an organization + are fault-tolerant and implement internal/external role separation.\n \nSupplemental Guidance: Information + systems that provide name and address resolution services include, for example, domain name system (DNS) + servers. To eliminate single points of failure and to enhance redundancy, organizations employ at least + two authoritative domain name system servers, one configured as the primary server and the other configured + as the secondary server. Additionally, organizations typically deploy the servers in two geographically + separated network subnetworks (i.e., not located in the same physical facility). For role separation, + DNS servers with internal roles only process name and address resolution requests from within organizations + (i.e., from internal clients). DNS servers with external roles only process name and address resolution + information requests from clients external to organizations (i.e., on external networks including\nthe + Internet). Organizations specify clients that can access authoritative DNS servers in particular roles + (e.g., by address ranges, explicit lists). Related controls: SC-2, SC-20, SC-21, SC-24.\n\nControl Enhancements:\ + \ None.\n\nReferences: NIST Special Publication 800-81." title: >- SC-22 - ARCHITECTURE AND PROVISIONING FOR @@ -14490,17 +14364,16 @@ controls: [1]https://docs.openshift.com/container-platform/latest/backup_and_restore/ [2]https://docs.openshift.com/container-platform/latest/authentication/managing-security-context-constraints.html rules: [] - description: "The information system fails to a [Assignment: organization-defined known-state]\ - \ for [Assignment: organization-defined types of failures] preserving [Assignment: organization-defined\ - \ system state information] in failure.\n\nSupplemental Guidance: Failure in a known state\ - \ addresses security concerns in accordance with the mission/business needs of organizations.\ - \ Failure in a known secure state helps to prevent the loss of confidentiality, integrity,\ - \ or availability of information in the event of failures of organizational information systems\ - \ or system components. Failure in a known safe state helps to prevent systems from failing\ - \ to a state that may cause injury to individuals or destruction to property. Preserving information\ - \ system state information facilitates system restart and return to the operational mode of\ - \ organizations with less disruption of mission/business processes. Related controls: CP-2,\ - \ CP- 10, CP-12, SC-7, SC-22. \n\nControl Enhancements: None. \n\nReferences: None." + description: "The information system fails to a [Assignment: organization-defined known-state] for [Assignment: + organization-defined types of failures] preserving [Assignment: organization-defined system state information] + in failure.\n\nSupplemental Guidance: Failure in a known state addresses security concerns in accordance + with the mission/business needs of organizations. Failure in a known secure state helps to prevent the + loss of confidentiality, integrity, or availability of information in the event of failures of organizational + information systems or system components. Failure in a known safe state helps to prevent systems from + failing to a state that may cause injury to individuals or destruction to property. Preserving information + system state information facilitates system restart and return to the operational mode of organizations + with less disruption of mission/business processes. Related controls: CP-2, CP- 10, CP-12, SC-7, SC-22.\ + \ \n\nControl Enhancements: None. \n\nReferences: None." title: >- SC-24 - FAIL IN KNOWN STATE levels: @@ -14906,26 +14779,24 @@ controls: Section b.2: This control reflects organizational procedures/policies, and is not applicable to the configuration of OpenShift. 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]\ - \ \nSI-1 (b) (2) [at least annually or whenever a significant change occurs]" + 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] \nSI-1 (b) + (2) [at least annually or whenever a significant change occurs]" title: >- SI-1 - SYSTEM AND INFORMATION INTEGRITY POLICY AND @@ -15103,45 +14974,40 @@ controls: and the resulting potential impact on the availability of the information system is an organizational control outside the scope of OpenShift configuration. rules: [] - description: "The organization:\n a. Employs malicious code protection mechanisms at information\ - \ system entry and exit points to detect and eradicate malicious code;\n b. Updates malicious\ - \ code protection mechanisms whenever new releases are available in accordance with organizational\ - \ configuration management policy and procedures;\n c. Configures malicious code protection\ - \ mechanisms to:\n 1. Perform periodic scans of the information system [Assignment: organization-defined\ - \ frequency] and real-time scans of files from external sources at [Selection (one or more);\ - \ endpoint; network entry/exit points] as the files are downloaded, opened, or executed in\ - \ accordance with organizational security policy; and\n 2. [Selection (one or more): block\ - \ malicious code; quarantine malicious code; send alert to administrator; [Assignment: organization-defined\ - \ action]] in response to malicious code detection; and\n d. Addresses the receipt of false\ - \ positives during malicious code detection and eradication and the resulting potential impact\ - \ on the availability of the information system.\n\nSupplemental Guidance: Information system\ - \ entry and exit points include, for example, firewalls, electronic mail servers, web servers,\ - \ proxy servers, remote-access servers, workstations, notebook computers, and mobile devices.\ - \ Malicious code includes, for example, viruses, worms, Trojan horses, and spyware. Malicious\ - \ code can also be encoded in various formats (e.g., UUENCODE, Unicode), contained within compressed\ - \ or hidden files, or hidden in files using steganography. Malicious code can be transported\ - \ by different means including, for example, web accesses, electronic mail, electronic mail\ - \ attachments, and portable storage devices. Malicious code insertions occur through the exploitation\ - \ of information system vulnerabilities. Malicious code protection mechanisms include, for\ - \ example, anti-virus signature definitions and reputation-based technologies. A variety of\ - \ technologies and methods exist to limit or eliminate the effects of malicious code. Pervasive\ - \ configuration management and comprehensive software integrity controls may be effective in\ - \ preventing execution of unauthorized code. In addition to commercial off-the-shelf software,\ - \ malicious code may also be present in custom-built software. This could include, for example,\ - \ logic bombs, back doors, and other types of cyber attacks that could affect organizational\ - \ missions/business functions. Traditional malicious code protection mechanisms cannot always\ - \ detect such code. In these situations, organizations rely instead on other safeguards including,\ - \ for example, secure coding practices, configuration management and control, trusted procurement\ - \ processes, and monitoring practices to help ensure that software does not perform functions\ - \ other than the functions intended. Organizations may determine that in response to the detection\ - \ of malicious code, different actions may be warranted. For example, organizations can define\ - \ actions in response to malicious code detection during periodic scans, actions in response\ - \ to detection of malicious downloads, and/or actions in response to detection of maliciousness\ - \ when attempting to open or execute files. Related controls: CM-3, MP-2, SA-4, SA-8, SA-12,\ - \ SA-13,\nSC-7, SC-26, SC-44, SI-2, SI-4, SI-7.\n\nReferences: NIST Special Publication 800-83.\ - \ \n\nSI-3 (c) (1)-1 [at least weekly] \nSI-3 (c) (1)-2 [to include endpoints]\nSI-3 (c) (2)\ - \ [to include blocking and quarantining malicious code and alerting administrator or defined\ - \ security personnel near-realtime]" + description: "The organization:\n a. Employs malicious code protection mechanisms at information system entry + and exit points to detect and eradicate malicious code;\n b. Updates malicious code protection mechanisms + whenever new releases are available in accordance with organizational configuration management policy + and procedures;\n c. Configures malicious code protection mechanisms to:\n 1. Perform periodic scans + of the information system [Assignment: organization-defined frequency] and real-time scans of files from + external sources at [Selection (one or more); endpoint; network entry/exit points] as the files are downloaded, + opened, or executed in accordance with organizational security policy; and\n 2. [Selection (one or more): + block malicious code; quarantine malicious code; send alert to administrator; [Assignment: organization-defined + action]] in response to malicious code detection; and\n d. Addresses the receipt of false positives during + malicious code detection and eradication and the resulting potential impact on the availability of the + information system.\n\nSupplemental Guidance: Information system entry and exit points include, for example, + firewalls, electronic mail servers, web servers, proxy servers, remote-access servers, workstations, notebook + computers, and mobile devices. Malicious code includes, for example, viruses, worms, Trojan horses, and + spyware. Malicious code can also be encoded in various formats (e.g., UUENCODE, Unicode), contained within + compressed or hidden files, or hidden in files using steganography. Malicious code can be transported + by different means including, for example, web accesses, electronic mail, electronic mail attachments, + and portable storage devices. Malicious code insertions occur through the exploitation of information + system vulnerabilities. Malicious code protection mechanisms include, for example, anti-virus signature + definitions and reputation-based technologies. A variety of technologies and methods exist to limit or + eliminate the effects of malicious code. Pervasive configuration management and comprehensive software + integrity controls may be effective in preventing execution of unauthorized code. In addition to commercial + off-the-shelf software, malicious code may also be present in custom-built software. This could include, + for example, logic bombs, back doors, and other types of cyber attacks that could affect organizational + missions/business functions. Traditional malicious code protection mechanisms cannot always detect such + code. In these situations, organizations rely instead on other safeguards including, for example, secure + coding practices, configuration management and control, trusted procurement processes, and monitoring + practices to help ensure that software does not perform functions other than the functions intended. Organizations + may determine that in response to the detection of malicious code, different actions may be warranted. + For example, organizations can define actions in response to malicious code detection during periodic + scans, actions in response to detection of malicious downloads, and/or actions in response to detection + of maliciousness when attempting to open or execute files. Related controls: CM-3, MP-2, SA-4, SA-8, SA-12, + SA-13,\nSC-7, SC-26, SC-44, SI-2, SI-4, SI-7.\n\nReferences: NIST Special Publication 800-83. \n\nSI-3 + (c) (1)-1 [at least weekly] \nSI-3 (c) (1)-2 [to include endpoints]\nSI-3 (c) (2) [to include blocking + and quarantining malicious code and alerting administrator or defined security personnel near-realtime]" title: >- SI-3 - MALICIOUS CODE PROTECTION levels: @@ -15295,49 +15161,43 @@ controls: Section g: This control reflects organizational procedures/policies, and is not applicable to the configuration of OpenShift. rules: [] - description: "The organization:\n a. Monitors the information system to detect:\n 1. Attacks\ - \ and indicators of potential attacks in accordance with [Assignment: organization- defined\ - \ monitoring objectives]; and\n 2. Unauthorized local, network, and remote connections;\n\ - \ b. Identifies unauthorized use of the information system through [Assignment: organization-\ - \ defined techniques and methods];\n c. Deploys monitoring devices: (i) strategically within\ - \ the information system to collect organization-determined essential information; and (ii)\ - \ at ad hoc locations within the system to track specific types of transactions of interest\ - \ to the organization;\n d. Protects information obtained from intrusion-monitoring tools from\ - \ unauthorized access, modification, and deletion;\n e. Heightens the level of information\ - \ system monitoring activity whenever there is an indication of increased risk to organizational\ - \ operations and assets, individuals, other organizations, or the Nation based on law enforcement\ - \ information, intelligence information, or other credible sources of information;\n f. Obtains\ - \ legal opinion with regard to information system monitoring activities in accordance with\ - \ applicable federal laws, Executive Orders, directives, policies, or regulations; and\n g.\ - \ Provides [Assignment: or ganization-defined information system monitoring information] to\ - \ [Assignment: organization-defined personnel or roles] [Selection (one or more): as needed;\ - \ [Assignment: organization-defined frequency]].\n\nSupplemental Guidance: Information system\ - \ monitoring includes external and internal monitoring. External monitoring includes the observation\ - \ of events occurring at the information system boundary (i.e., part of perimeter defense and\ - \ boundary protection). Internal monitoring includes the observation of events occurring within\ - \ the information system. Organizations can monitor information systems, for example, by observing\ - \ audit activities in real time or by observing other system aspects such as access patterns,\ - \ characteristics of access, and other actions. The monitoring objectives may guide determination\ - \ of the events. Information system monitoring capability is achieved through a variety of\ - \ tools and techniques (e.g., intrusion detection systems, intrusion prevention systems, malicious\ - \ code protection software, scanning tools, audit record monitoring software, network monitoring\ - \ software). Strategic locations for monitoring devices include, for example, selected perimeter\ - \ locations and near server farms supporting critical applications, with such devices typically\ - \ being employed at the managed interfaces associated with controls SC-7 and AC-17. Einstein\ - \ network monitoring devices from the Department of Homeland Security can also be included\ - \ as monitoring devices. The granularity of monitoring information collected is based on organizational\ - \ monitoring objectives and the capability of information systems to support such objectives.\ - \ Specific types of transactions of interest include, for example, Hyper Text Transfer Protocol\ - \ (HTTP) traffic that bypasses HTTP proxies. Information system monitoring is an integral part\ - \ of organizational continuous monitoring and incident response programs. Output from system\ - \ monitoring serves as input to continuous monitoring and incident response programs. A network\ - \ connection is any connection with a device that communicates through a network (e.g., local\ - \ area network, Internet). A remote connection is any connection with a device communicating\ - \ through an external network (e.g., the Internet). Local, network, and remote connections\ - \ can be either wired or wireless. Related controls: AC-3, AC-4, AC-8, AC-17, AU-2, AU-6, AU-7,\ - \ AU-9, AU-12, CA-7, IR-4, PE-3, RA-5, SC-7, SC-26, SC-35, SI-3, SI-7.\n\nReferences: NIST\ - \ Special Publications 800-61, 800-83, 800-92, 800-94, 800-137.\n\n \nSI-4 Guidance: See US-CERT\ - \ Incident Response Reporting Guidelines." + description: "The organization:\n a. Monitors the information system to detect:\n 1. Attacks and indicators + of potential attacks in accordance with [Assignment: organization- defined monitoring objectives]; and\n\ + \ 2. Unauthorized local, network, and remote connections;\n b. Identifies unauthorized use of the information + system through [Assignment: organization- defined techniques and methods];\n c. Deploys monitoring devices: + (i) strategically within the information system to collect organization-determined essential information; + and (ii) at ad hoc locations within the system to track specific types of transactions of interest to + the organization;\n d. Protects information obtained from intrusion-monitoring tools from unauthorized + access, modification, and deletion;\n e. Heightens the level of information system monitoring activity + whenever there is an indication of increased risk to organizational operations and assets, individuals, + other organizations, or the Nation based on law enforcement information, intelligence information, or + other credible sources of information;\n f. Obtains legal opinion with regard to information system monitoring + activities in accordance with applicable federal laws, Executive Orders, directives, policies, or regulations; + and\n g. Provides [Assignment: or ganization-defined information system monitoring information] to [Assignment: + organization-defined personnel or roles] [Selection (one or more): as needed; [Assignment: organization-defined + frequency]].\n\nSupplemental Guidance: Information system monitoring includes external and internal monitoring. + External monitoring includes the observation of events occurring at the information system boundary (i.e., + part of perimeter defense and boundary protection). Internal monitoring includes the observation of events + occurring within the information system. Organizations can monitor information systems, for example, by + observing audit activities in real time or by observing other system aspects such as access patterns, + characteristics of access, and other actions. The monitoring objectives may guide determination of the + events. Information system monitoring capability is achieved through a variety of tools and techniques + (e.g., intrusion detection systems, intrusion prevention systems, malicious code protection software, + scanning tools, audit record monitoring software, network monitoring software). Strategic locations for + monitoring devices include, for example, selected perimeter locations and near server farms supporting + critical applications, with such devices typically being employed at the managed interfaces associated + with controls SC-7 and AC-17. Einstein network monitoring devices from the Department of Homeland Security + can also be included as monitoring devices. The granularity of monitoring information collected is based + on organizational monitoring objectives and the capability of information systems to support such objectives. + Specific types of transactions of interest include, for example, Hyper Text Transfer Protocol (HTTP) traffic + that bypasses HTTP proxies. Information system monitoring is an integral part of organizational continuous + monitoring and incident response programs. Output from system monitoring serves as input to continuous + monitoring and incident response programs. A network connection is any connection with a device that communicates + through a network (e.g., local area network, Internet). A remote connection is any connection with a device + communicating through an external network (e.g., the Internet). Local, network, and remote connections + can be either wired or wireless. Related controls: AC-3, AC-4, AC-8, AC-17, AU-2, AU-6, AU-7, AU-9, AU-12, + CA-7, IR-4, PE-3, RA-5, SC-7, SC-26, SC-35, SI-3, SI-7.\n\nReferences: NIST Special Publications 800-61, + 800-83, 800-92, 800-94, 800-137.\n\n \nSI-4 Guidance: See US-CERT Incident Response Reporting Guidelines." title: >- SI-4 - INFORMATION SYSTEM MONITORING levels: @@ -15870,14 +15730,13 @@ controls: [2] https://docs.openshift.com/container-platform/4.6/security/file_integrity_operator/file-integrity-operator-configuring.html rules: - file_integrity_exists - description: "The information system performs an integrity check of [Assignment: organization-defined\ - \ software, firmware, and information] [Selection (one or more): at startup; at [Assignment:\ - \ organization-defined transitional states or security-relevant events]; [Assignment: organization-\ - \ defined frequency]].\n\nSupplemental Guidance: Security-relevant events include, for example,\ - \ the identification of a new threat to which organizational information systems are susceptible,\ - \ and the installation of new hardware, software, or firmware. Transitional states include,\ - \ for example, system startup, restart, shutdown, and abort.\n\nSI-7(1)-1 [selection to include\ - \ security relevant events] \nSI-7(1)-2 [at least monthly]" + description: "The information system performs an integrity check of [Assignment: organization-defined software, + firmware, and information] [Selection (one or more): at startup; at [Assignment: organization-defined + transitional states or security-relevant events]; [Assignment: organization- defined frequency]].\n\n\ + Supplemental Guidance: Security-relevant events include, for example, the identification of a new threat + to which organizational information systems are susceptible, and the installation of new hardware, software, + or firmware. Transitional states include, for example, system startup, restart, shutdown, and abort.\n\ + \nSI-7(1)-1 [selection to include security relevant events] \nSI-7(1)-2 [at least monthly]" title: >- SI-7(1) - SOFTWARE, FIRMWARE, AND INFORMATION INTEGRITY | INTEGRITY CHECKS levels: