{"id": "nist_satellite6", "policy": "NIST", "title": "Configuration Recommendations for Satellite 6", "source": "https://www.fedramp.gov/assets/resources/documents/FedRAMP_Security_Controls_Baseline.xlsx", "definition_location": "/aptdata/openscap/scap-security-guide/controls/nist_satellite6.yml", "controls": [{"id": "AC-1", "levels": ["high", "moderate", "low"], "notes": "Section a: (O) The organization will be responsible for developing, documenting,\nand disseminating access control policy and procedures. A successful\ncontrol response will need to address the content of the policy (which\nmust include purpose, scope, roles, responsibilities, management\ncommitment, coordination, and compliance) and procedures (which must\nfacilitate the implementation of the policies and associated controls).\nSection a.1: (O) The organization will be responsible for developing, documenting,\nand disseminating an access control policy that addresses purpose,\nscope, roles, responsibilities, management commitment, coordination\namong organizational entities, and compliance. A successful control\nresponse will need to address the content of the policy (which must\ninclude purpose, scope, roles, responsibilities, management commitment,\ncoordination, and compliance).\nSection a.2: (O) The organization will be responsible for developing, documenting,\nand disseminating the procedures to facilitate the implementation of the\naccess control policy and associated access controls. A successful\ncontrol response will need to address the procedures (which must\nfacilitate the implementation of the policies and associated controls).\nSection b: (O) The organization will be responsible for reviewing and updating the\ncurrent access control policies and procedures. A successful control\nresponse will need to address the review and update process, including\nthe role(s) responsible for initiating the review process, updating the\npolicy and procedures, and providing approval of the updates.\nSection b.1: (O) The organization will be responsible for reviewing and updating the\ncurrent access control policies. A successful control response will need\nto address the review and update process, including the role(s)\nresponsible for initiating the review process, updating the policy, and\nproviding approval of the updates.\nSection b.2: (O) The organization will be responsible for reviewing and updating the\ncurrent access control procedures. A successful control response will\nneed to address the review and update process, including the role(s)\nresponsible for initiating the review process, updating the procedures,\nand providing approval of the updates.", "title": "AC-1 - ACCESS CONTROL POLICY AND PROCEDURES", "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]", "rationale": null, "automated": "no", "status": "not applicable", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "AC-2", "levels": ["high", "moderate", "low"], "notes": "Section a: (O) The organization will be responsible for identifying and selecting\nthe types of accounts required to support the organizations application.\nExamples of account types include individual, shared, group, system,\nguest/anonymous, emergency, developer/manufacturer/vendor, temporary,\nand service. A successful control response will need to address the\nspecific requirements fulfilled by each account type in use.\nSection b: (O) The organization will be responsible for assigning account managers,\nwho will have responsibilities related to the creation, management, and\nremoval of accounts. A successful control response will need to discuss\nhow account managers are identified within the organization.\nSection c: (O) The organization will be responsible for setting conditions for\ngroup and role memberships. A successful control response will need to\noutline these conditions and how they are enforced.\nSection d: (O) The organization will be responsible for specifying authorized\nusers, group and role memberships, and privileges for each account. A\nsuccessful control response will need to address the process by which\nauthorized users are specified and privilege levels are determined.\nSection e: (O) The organization will be responsible for requiring approval by\ndesignated personnel or roles prior to creating information system\naccounts. A successful control response will need to outline the\npersonnel or roles responsible for approving information system accounts\nand the process by which those personnel or roles are notified and\napproval is granted.\nSection f: (O) The organization will be responsible for defining and enforcing\nprocedures or conditions for the creation, management, and removal of\ninformation system accounts. A successful control response will outline\nthe conditions for each action and the tools or procedures used to\nenforce those conditions.\nSection g: (O) The organization will be responsible for monitoring the use of\ninformation system accounts. This may include reviewing records of\naccount management activities. A successful control response will relate\nthe monitoring activities required for this control to the auditing\nactivities in the AU control family.\nSection h: (O) The organization will be responsible for notifying account managers\nwhen triggering events occur. A successful control response will need to\naddress the methods by which these triggering events are identified and\nthe managers are notified.\nSection h.1: (O) The organization will be responsible for notifying account managers\nwhen accounts are no longer required. A successful control response will\nneed to address the methods by which this triggering event is identified\nand the managers are notified.\nSection h.2: (O) The organization will be responsible for notifying account managers\nwhen when users are terminated. A successful control response will need\nto address the methods by which this triggering event is identified and\nthe managers are notified.\nSection h.3: (O) The organization will be responsible for notifying account managers\nwhen when system usage or need-to-know changes. A successful control\nresponse will need to address the methods by which this triggering event\nis identified and the managers are notified.\nSection i: (O) The organization will be responsible for authorizing access to the\norganizations information system based on a valid access authorization.\nA successful control response will need to address ensuring that all\naccounts are granted access based on a valid authorization.\nSection i.1: (O) The organization will be responsible for authorizing access to the\norganizations application. A successful control response will need to\naddress ensuring that all accounts are granted access based on a valid\nauthorization.\nSection i.2: (O) The organization will be responsible for authorizing access to the\norganizations application based on . A successful control response will\nneed to address ensuring that all accounts are granted access based on a\nvalid authorization for a specific intended usage.\nSection i.3: (O) The organization will be responsible for authorizing access to the\norganizations application. A successful control response will need to\naddress ensuring that all accounts are granted access based on a valid\nauthorization for a specific intended usage.\nSection j: (O) The organization will be responsible for reviewing accounts for\ncompliance with account management requirements at the specified\nfrequency. A successful control response will need to address the\nprocess used to review accounts, the means by which compliance is\nverified, and the process for remediation of any accounts found not to\nbe in compliance.\nSection k: (O) The organization will be responsible for reissuing shared/group\naccount credentials when individuals are removed from the group. A\nsuccessful control response will need to discuss how a triggering event\nis notified, what the process and timeframe for reissuing credentials\nis, and how the process is enforced.", "title": "AC-2 - ACCOUNT MANAGEMENT", "description": "The organization:\n a. Identifies and selects the following types of information system accounts to support organizational missions/business functions: [Assignment: organization-defined information system account types];\n b. Assigns account managers for information system accounts;\n c. Establishes conditions for group and role membership;\n d. Specifies authorized users of the information system, group and role membership, and access authorizations (i.e., privileges) and other attributes (as required) for each account;\n e. Requires approvals by [Assignment: organization-defined personnel or roles] for requests to create information system accounts;\n f. Creates, enables, modifies, disables, and removes information system accounts in accordance with [Assignment: organization-defined procedures or conditions];\n g. Monitors the use of, information system accounts;\n h. Notifies account managers:\n   1. When accounts are no longer required;\n   2. When users are terminated or transferred; and\n   3. When individual information system usage or need-to-know changes;\n i. Authorizes access to the information system based on:\n   1. A valid access authorization;\n   2. Intended system usage; and\n   3. Other attributes as required by the organization or associated missions/business functions;\n j. Reviews accounts for compliance with account management requirements [Assignment: organization-defined frequency]; and\n k. Establishes a process for reissuing shared/group account credentials (if deployed) when individuals are removed from the group.\nSupplemental Guidance: Information system account types include individual, shared, group, system, guest/anonymous, emergency, developer/manufacturer/vendor, temporary, and service. Some of the account management requirements listed above can be implemented by organizational information systems. The identification of authorized users of the information system and the specification of access privileges reflects the requirements in other security controls in the security plan. Users requiring administrative privileges on information system accounts receive additional scrutiny by appropriate organizational personnel (e.g., system owner, mission/business owner, or chief information security officer) responsible for approving such accounts and privileged access. Organizations may choose to define access privileges or other attributes by account, by type of account, or a combination of both. Other attributes required for authorizing access include, for example, restrictions on time-of-day, day-of-week, and point-of-origin. In defining other account attributes, organizations consider system-related requirements (e.g., scheduled maintenance, system upgrades) and mission/business requirements, (e.g., time zone differences, customer requirements, remote access to support travel requirements). Failure to consider these factors could affect information system availability. Temporary and emergency accounts are accounts intended for short-term use. Organizations establish temporary accounts as a part of normal account activation procedures when there is a need for short-term accounts without the demand for immediacy in account activation. Organizations establish emergency accounts in response to crisis situations and with the need for rapid account activation. Therefore, emergency account activation may bypass normal account authorization processes. Emergency and temporary accounts are not to be confused with infrequently used accounts (e.g., local logon accounts used for special tasks defined by organizations or when network resources are unavailable). Such accounts remain available and are not subject to automatic disabling or removal dates. Conditions for disabling or deactivating accounts include, for example: (i) when shared/group, emergency, or temporary accounts are no longer required; or (ii) when individuals are transferred or terminated. Some types of information system accounts may require specialized training. Related controls: AC-3, AC-4, AC-5, AC-6, AC-10, AC-17, AC-19, AC-20, AU-9, IA-2, IA-4, IA-5, IA-8, CM-5, CM-6, CM-11, MA-3, MA-4, MA-5, PL-4, SC-13.\n\nReferences: None.\n\nAC-2 (j) [monthly for privileged accessed, every six (6) months for non-privileged access]", "rationale": null, "automated": "no", "status": "not applicable", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "AC-2(1)", "levels": ["high", "moderate"], "notes": "(O) The organization will be responsible for employing automated\nmechanisms to support account management activities. A successful\ncontrol response will need to address all automated mechanisms used for\naccount management.", "title": "AC-2(1) - ACCOUNT MANAGEMENT | AUTOMATED SYSTEM ACCOUNT MANAGEMENT", "description": "The organization employs automated mechanisms to support the management of information system accounts.\n\nSupplemental Guidance: The use of automated mechanisms can include, for example: using email or text messaging to automatically notify account managers when users are terminated or transferred; using the information system to monitor account usage; and using telephonic notification to report atypical system account usage.", "rationale": null, "automated": "no", "status": "not applicable", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "AC-2(2)", "levels": ["high", "moderate"], "notes": "(S) The information system will be responsible for automatically\nremoving or disabling emergency and temporary accounts within the\nrequired timeframe. A successful control response will need to address\nall of the procedures and mechanisms involved in disabling these\naccounts.", "title": "AC-2(2) - ACCOUNT MANAGEMENT | REMOVAL OF TEMPORARY / EMERGENCY ACCOUNTS", "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]", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "AC-2(3)", "levels": ["high", "moderate"], "notes": "(S) The information system will be responsible for automatically\ndisabling user accounts after the specified period of inactivity. A\nsuccessful control response will need to address all automated\nmechanisms involved in disabling inactive accounts.", "title": "AC-2(3) - ACCOUNT MANAGEMENT | DISABLE INACTIVE ACCOUNTS", "description": "The information system automatically disables inactive accounts after [Assignment: organization-defined time period].\n\nAC-2 (3) [35 days for user accounts]\nAC-2 (3) Requirement: The service provider defines the time period for non-user accounts (e.g., accounts associated with devices).  The time periods are approved and accepted by the JAB/AO. Where user management is a function of the service, reports of activity of consumer users shall be made available.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "AC-2(4)", "levels": ["high", "moderate"], "notes": "(S) The information system will be responsible for auditing changes to\naccounts and integrity of accounts to improve situational awareness. A\nsuccessful control response Automatically auditing account creation,\nmodification, enabling, disabling, and removal actions, and notifying\nappropriate individuals is outside the scope of Red Hat Advanced Cluster\nManagement for Kubernetes.", "title": "AC-2(4) - ACCOUNT MANAGEMENT | AUTOMATED AUDIT ACTIONS", "description": "The information system automatically audits account creation, modification, enabling, disabling, and removal actions, and notifies [Assignment: organization-defined personnel or roles].\n\nSupplemental Guidance: Related controls: AU-2, AU-12.\n\nAC-2 (4) [organization and/or service provider system owner]", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "AC-2(5)", "levels": ["high", "moderate"], "notes": "(O|S) The organization will be responsible for requiring that users logout\nwhen an organization-defined time-period of expected inactivity or\ndescription of when to log out. A successful control response will\ndefine account timeout and conditions when users shall log out. This\ncontrol is expected to be addressed at the organizational level for\npolicy guidance, and at the information system level for implementation.", "title": "AC-2(5) - ACCOUNT MANAGEMENT | INACTIVITY LOGOUT", "description": "The organization requires that users log out when [Assignment: organization-defined time-period of expected inactivity or description of when to log out].\n\nSupplemental Guidance: Related control: SC-23.\n\nAC-2 (5) [inactivity is anticipated to exceed Fifteen (15) minutes]\nAC-2 (5) Guidance: Should use a shorter timeframe than AC-12.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "AC-2(6)", "levels": ["low"], "notes": "(S) The information system will be responsible for implementing dynamic\nprivilege management capabilities for account management. A successful\ncontrol response will detail the mechanisms and processes used for\ndynamic privilege management.", "title": null, "description": null, "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "AC-2(7)", "levels": ["high", "moderate"], "notes": "Section a: (O) The organization will be responsible for establishing and\nadministering privileged accounts in accordance with a role-based access\n(RBAC) scheme. A successful control response will need to address the\ntypes of users or rules that receive privileged access as well as the\norganization of the RBAC scheme.\nSection b: (O) The organization will be responsible for monitoring privileged role\nassignments. A successful control response will need to address the\nprocess by which role assignments are reviewed for continued\nappropriateness.\nSection c: (O) The organization will be responsible for defining and executing\nactions to take when privileged role assignments are no longer\nappropriate. A successful control response will need to address the\ncriteria for determining whether assignments are no longer appropriate,\nthe actions to be taken, and the roles or personnel responsible for\ntaking those actions.", "title": "AC-2(7) - ACCOUNT MANAGEMENT | ROLE-BASED SCHEMES", "description": "The organization:\n(a) Establishes and administers privileged user accounts in accordance with a role-based access scheme that organizes allowed information system access and privileges into roles;\n(b) Monitors privileged role assignments; and\n(c) Takes [Assignment: organization-defined actions] when privileged role assignments are no longer appropriate.\n\nSupplemental Guidance: Privileged roles are organization-defined roles assigned to individuals that allow those individuals to perform certain security-relevant functions that ordinary users are not authorized to perform. These privileged roles include, for example, key management, account management, network and system administration, database administration, and web administration.\n\nAC-2 (7) (c) [disables/revokes access within a organization-specified timeframe]", "rationale": null, "automated": "no", "status": "not applicable", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "AC-2(8)", "levels": ["low"], "notes": "(S) The information system will be responsible for creating system\naccounts dynamically. A successful control response will need to address\nthe mechanisms used to create accounts dynamically.", "title": null, "description": null, "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "AC-2(9)", "levels": ["high", "moderate"], "notes": "The customer will be responsible for defining and enforcing\nconditions for the use of shared group accounts. A successful control\nresponse will need to address the specific need for the existing of\na shared or group account versus multiple individual accounts, as well\nas the process for reviewing membership of shared or group accounts to\nverify that all individuals with access still require that access.", "title": "AC-2(9) - ACCOUNT MANAGEMENT | RESTRICTIONS ON USE OF SHARED GROUPS / ACCOUNTS", "description": "The organization only permits the use of shared/group accounts that meet [Assignment: organization-defined conditions for establishing shared/group accounts].\n\nAC-2 (9) [organization-defined need with justification statement that explains why such accounts are necessary]\nAC-2 (9) Required if shared/group accounts are deployed", "rationale": null, "automated": "no", "status": "not applicable", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "AC-2(12)", "levels": ["high", "moderate"], "notes": "Section a: The organization will be responsible for monitoring information system\naccounts for atypical use. A successful control response will relate\nthe monitoring activities required for this control to the auditing\nactivities in the AU control family, and will discuss the criteria\nfor atypical use.\nSection b: The organization will be responsible for reporting atypical use of\ninformation system accounts. A successful control response will\ndiscuss the personnel or roles that must be notified and the process\nfor notification.", "title": "AC-2(12) - ACCOUNT MANAGEMENT | ACCOUNT MONITORING / ATYPICAL USAGE", "description": "The organization:\n (a) Monitors information system accounts for [Assignment: organization-defined atypical use]; and\n (b) Reports atypical usage of information system accounts to [Assignment: organization-defined personnel or roles].\n\nSupplemental Guidance: Atypical usage includes, for example, accessing information systems at certain times of the day and from locations that are not consistent with the normal usage patterns of individuals working in organizations. Related control: CA-7.\n\nAC-2 (12) (b)[at a minimum, the ISSO and/or similar role within the organization]\nAC-2 (12)(a) Guidance: Required for privileged accounts.\nAC-2 (12)(b) Guidance: Required for privileged accounts.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "AC-2(13)", "levels": ["high"], "notes": "The organization will be responsible for disabling accounts of users\nposing a significant risk within an organizational-defined time\nperiod of discovery of the risk. A successful control response defines\nthe time period and the processes to disable the account(s).", "title": "AC-2(13) - ACCOUNT MANAGEMENT | DISABLE ACCOUNTS FOR HIGH-RISK INDIVIDUALS", "description": "The organization disables accounts of users posing a significant risk within [Assignment: organization-defined time period] of discovery of the risk.\n\nSupplemental 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.\n\nAC-2 (13) [one (1) hour]", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "AC-5", "levels": ["high", "moderate"], "notes": "Section a: The customer will be responsible for defining separation of duties\nbetween individuals so as to reduce the risk of insider threat without\ncollusion. A successful control response will need to consider the\npossible actions a malicious insider could take to undermine the\nsecurity of the system, and delineate how duties are separated to\nprevent or reduce the likelihood of those actions.\nSection b: The customer will be responsible for documenting separation of duties.\nA successful control response will need to address the location of this\ndocumentation and the process for reviewing it if necessary.\nSection c: The customer will be responsible for defining access authorizations\nto support separation of duties, for example by using Role Based\nAccess Control. A successful control response will need to address\npolicy and technical enforcement of separation of duties.", "title": "AC-5 - SEPARATION OF DUTIES", "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.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "AC-6", "levels": ["high", "moderate"], "notes": "The customer will be responsible for following least-privilege\nprinciples when granting authorized access. A successful control\nresponse will need to address the use of business requirements\nto determine the level of access required to perform each job function,\nand how that is related to the role-based access control scheme used\nwithin the system.", "title": "AC-6 - LEAST PRIVILEGE", "description": "The organization employs the principle of least privilege, allowing only authorized accesses for users (or processes acting on behalf of users) which are necessary to accomplish assigned tasks in accordance with organizational missions and business functions.\n\nSupplemental Guidance:  Organizations employ least privilege for specific duties and information systems. The principle of least privilege is also applied to information system processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions/business functions. Organizations consider the creation of additional processes, roles, and information system accounts as necessary, to achieve least privilege. Organizations also apply least privilege to the development, implementation, and operation of organizational information systems. Related controls: AC-2, AC-3, AC-5, CM-6, CM-7, PL-2.\n\nReferences: None.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "AC-6(1)", "levels": ["high", "moderate"], "notes": "The customer will be responsible for defining key security functions\nand security-relevant information, and for explicitly authorizing\naccess to those functions and information. A successful control response\nwill need to address the criteria used to determine which functions\nand information require explicit access authorization.", "title": "AC-6(1) - LEAST PRIVILEGE | AUTHORIZE ACCESS TO SECURITY FUNCTIONS", "description": "The organization explicitly authorizes access to [Assignment: organization-defined security functions (deployed in hardware, software, and firmware) and security-relevant information].\n\nSupplemental Guidance:  Security functions include, for example, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters. Security-relevant information includes, for example, filtering rules for routers/firewalls, cryptographic key management information, configuration parameters for security services, and access control lists. Explicitly authorized personnel include, for example, security administrators, system and network administrators, system security officers, system maintenance personnel, system programmers, and other privileged users. Related controls: AC-17, AC-18, AC-19.\n\nAC-6 (1) [all functions not publicly accessible and all security-relevant information not publicly available]", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "AC-6(5)", "levels": ["high", "moderate"], "notes": "The customer will be responsible for defining specific personnel\nor roles who require privileged access, and restricting privileged\naccess to those personnel or roles. A successful response will need\nto address the job functions or responsibilities for which\nprivileged access is required.", "title": "AC-6(5) - LEAST PRIVILEGE | PRIVILEGED ACCOUNTS", "description": "The organization restricts privileged accounts on the information system to [Assignment:\norganization-defined personnel or roles].\n\nSupplemental Guidance:  Privileged accounts, including super user accounts, are typically described as system administrator for various types of commercial off-the-shelf operating systems. Restricting privileged accounts to specific personnel or roles prevents day-to-day users from having access to privileged information/functions. Organizations may differentiate in the application of this control enhancement between allowed privileges for local accounts and for domain accounts provided organizations retain the ability to control information system configurations for key security parameters and as otherwise necessary to sufficiently mitigate risk. Related control: CM-6.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "AC-14", "levels": ["high", "moderate", "low"], "notes": "Section a: The customer will be responsible for identifying user actions that can\nbe performed on the information system without identification or\nauthentication consistent with missions/business functions. A\nsuccessful control response will identify such actions.", "title": "AC-14 - PERMITTED ACTIONS WITHOUT IDENTIFICATION OR\nAUTHENTICATION", "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.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "AC-17", "levels": ["high", "moderate", "low"], "notes": "Section a: The customer will be responsible for establishing and documenting\nusage restrictions, configuration and connection requirements, and\nimplementation guidance for access to the customer application\n(note that in a cloud environment, all user access will be remote\naccess).\nSection b: The customer will be responsible for authorizing remote access before\nallowing such connections. Due to the nature of the cloud environment,\na successful control response will need to indicate that authorizing\nremote access is equivalent to authorizing any access, and relate this\ncontrol to AC-2.", "title": "AC-17 - REMOTE ACCESS", "description": "The organization:\n a. Establishes and documents usage restrictions, configuration/connection requirements, and implementation guidance for each type of remote access allowed; and\n b. Authorizes remote access to the information system prior to allowing such connections.\n\nSupplemental Guidance:  Remote access is access to organizational information systems by users (or processes acting on behalf of users) communicating through external networks (e.g., the Internet). Remote access methods include, for example, dial-up, broadband, and wireless. Organizations often employ encrypted virtual private networks (VPNs) to enhance confidentiality and integrity over remote connections. The use of encrypted VPNs does not make the access non-remote; however, the use of VPNs, when adequately provisioned with appropriate security controls (e.g., employing appropriate encryption techniques for confidentiality and integrity protection) may provide sufficient assurance to the organization that it can effectively treat such connections as internal networks. Still, VPN connections traverse external networks, and the encrypted VPN does not enhance the availability of remote connections. Also, VPNs with encrypted tunnels can affect the organizational capability to adequately monitor network communications traffic for malicious code. Remote access controls apply to information systems other than public web servers or systems designed for public access. This control addresses authorization prior to allowing remote access without specifying the formats for such authorization. While organizations may use interconnection security agreements to authorize remote access connections, such agreements are not required by this control. Enforcing access restrictions for remote connections is addressed in AC-3. Related controls: AC-2, AC-3, AC-18, AC-19, AC-20, CA-3, CA-7, CM-8, IA-2, IA-3, IA-8, MA-4, PE-17, PL-4, SC-10, SI-4.\n\nReferences: NIST Special Publications 800-46, 800-77, 800-113, 800-114, 800-121.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "AC-17(4)", "levels": ["high", "moderate"], "notes": "Section a: The customer will be responsible for authoring the execution of\nprivileged commands and access to security-relevant information via\nremote access. Due to the nature of the cloud environment, a\nsuccessful control response will need to indicate that authorizing\nthese activities over remote access is equivalent to authorizing them\nat all, and refer to AC-2.\nSection b: The customer will be responsible for authorizing the execution of\nprivileged commands and access to security-relevant information via\nremote access. Due to the nature of the cloud environment, a successful\ncontrol response will need to indicate that authorizing these activities\nover remote access is equivalent to authorizing them at all, and refer\nto AC-2.", "title": "AC-17(4) - REMOTE ACCESS | PRIVILEGED COMMANDS / ACCESS", "description": "The organization:\n (a)   Authorizes the execution of privileged commands and access to security-relevant information via remote access only for [Assignment: organization-defined needs]; and\n (b)   Documents the rationale for such access in the security plan for the information system.\n\nSupplemental Guidance:  Related control: AC-6.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "AC-18", "levels": ["high", "moderate", "low"], "notes": "Section a: Given the data center focus of the infrastructure running OpenShift,\nit is likely this control is not applicable. A successful response\nwill document if wireless connectivity is enabled, and if so,\nhow usage and connection requirements were created.\nSection b: A successful control response will document how connections are\nauthorized prior to receiving full connectivity to the wireless\nnetwork. This is frequently accomplished via WEP2 and other\nencryption and/or passphrase requirements.", "title": "AC-18 - WIRELESS ACCESS", "description": "The organization:\n a. Establishes usage restrictions, configuration/connection requirements, and implementation guidance for wireless access; and\n b. Authorizes wireless access to the information system prior to allowing such connections.\n\nSupplemental Guidance:  Wireless technologies include, for example, microwave, packet radio (UHF/VHF), 802.11x, and Bluetooth. Wireless networks use authentication protocols (e.g., EAP/TLS, PEAP), which provide credential protection and mutual authentication. Related controls: AC-2, AC-3, AC-17, AC-19, CA-3, CA-7, CM-8, IA-2, IA-3, IA-8, PL-4, SI-4.\n\nReferences: NIST Special Publications 800-48, 800-94, 800-97.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "AC-19", "levels": ["high", "moderate", "low"], "notes": "Section a: A successful control response will document how, if wireless\nconnectivity is permitted, end-user devices are organizationally\nmanaged (configurations, connections, and applications).\nSection b: A successful control response will document how, if wireless\nconnectivity is permitted, mobile devices are authorized to\nconnect to organizational networks (e.g. MDM).", "title": "AC-19 - ACCESS CONTROL FOR MOBILE DEVICES", "description": "The organization:\n a. Establishes usage restrictions, configuration requirements, connection requirements, and implementation guidance for organization-controlled mobile devices; and\n b. Authorizes the connection of mobile devices to organizational information systems.\n\nSupplemental Guidance:  A mobile device is a computing device that: (i) has a small form factor such that it can easily be carried by a single individual; (ii) is designed to operate without a physical connection (e.g., wirelessly transmit or receive information); (iii) possesses local, non- removable or removable data storage; and (iv) includes a self-contained power source. Mobile devices may also include voice communication capabilities, on-board sensors that allow the device to capture information, and/or built-in features for synchronizing local data with remote locations. Examples include smart phones, E-readers, and tablets. Mobile devices are typically associated with a single individual and the device is usually in close proximity to the individual; however, the degree of proximity can vary depending upon on the form factor and size of the device. The processing, storage, and transmission capability of the mobile device may be comparable to or merely a subset of desktop systems, depending upon the nature and intended purpose of the device. Due to the large variety of mobile devices with different technical characteristics and capabilities, organizational restrictions may vary for the different classes/types of such devices. Usage restrictions and specific implementation guidance for mobile devices include, for example, configuration management, device identification and authentication, implementation of mandatory protective software (e.g., malicious code detection, firewall), scanning devices for malicious code, updating virus protection software, scanning for critical software updates and patches, conducting primary operating system (and possibly other resident software) integrity checks, and disabling unnecessary hardware (e.g., wireless, infrared). Organizations are cautioned that the need to provide adequate security for mobile devices goes beyond the requirements in this control. Many safeguards and countermeasures for mobile devices are reflected in other security controls in the catalog allocated in the initial control baselines as starting points for the development of security plans and overlays using the tailoring process. There may also be some degree of overlap in the requirements articulated by the security controls within the different families of controls. AC-20 addresses mobile devices that are not organization-controlled. Related controls: AC-3, AC-7, AC-18, AC-20, CA-9, CM-2, IA-2, IA-3, MP-2, MP-4, MP-5, PL-4, SC-7, SC-43, SI-3, SI-4.\n\nReferences: OMB Memorandum 06-16; NIST Special Publications 800-114, 800-124, 800-164.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "AC-19(5)", "levels": ["high", "moderate"], "notes": "A successful control response will document how either full-device\nencryption on mobile devices is being used. This is only applicable\nif mobile is within scope of your security package.", "title": "AC-19(5) - ACCESS CONTROL FOR MOBILE DEVICES | FULL DEVICE / CONTAINER-BASED ENCRYPTION", "description": "The organization employs [Selection: full-device encryption; container encryption] to protect the confidentiality and integrity of information on [Assignment: organization-defined mobile devices].\n\nSupplemental Guidance:  Container-based encryption provides a more fine-grained approach to the encryption of data/information on mobile devices, including for example, encrypting selected data structures such as files, records, or fields. Related controls: MP-5, SC-13, SC-28.\n\nReferences:  OMB Memorandum 06-16; NIST Special Publications 800-114, 800-124, 800-164.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "AC-20", "levels": ["high", "moderate", "low"], "notes": "Section a: The organization will be responsible for establishing terms and conditions\nallowing authorized individuals to access the organization application\nfrom external information systems. A successful control response will\nneed to outline the terms and conditions and the external information\nsystems to which those terms and conditions apply.\nSection b: The organization will be responsible for establishing terms and conditions\nallowing authorized individuals to process, store, or transmit\ncustomer-controlled information using external information systems. A\nsuccessful control response will need to outline the terms and\nconditions and the external information systems to which those terms\nand conditions apply.", "title": "AC-20 - USE OF EXTERNAL INFORMATION SYSTEMS", "description": "The organization establishes terms and conditions, consistent with any trust relationships established with other organizations owning, operating, and/or maintaining external information systems, allowing authorized individuals to:\n a. Access the information system from external information systems; and\n b. Process, store, or transmit organization-controlled information using external information systems.\n\nSupplemental Guidance:  External information systems are information systems or components of information systems that are outside of the authorization boundary established by organizations and for which organizations typically have no direct supervision and authority over the application of required security controls or the assessment of control effectiveness. External information systems include, for example: (i) personally owned information systems/devices (e.g., notebook computers, smart phones, tablets, personal digital assistants); (ii) privately owned computing and communications devices resident in commercial or public facilities (e.g., hotels, train stations, convention centers, shopping malls, or airports); (iii) information systems owned or controlled by nonfederal governmental organizations; and (iv) federal information systems that are not owned by, operated by, or under the direct supervision and authority of organizations. This control also addresses the use of external information systems for the processing, storage, or transmission of\norganizational information, including, for example, accessing cloud services (e.g., infrastructure as a service, platform as a service, or software as a service) from organizational information systems.\n\nFor some external information systems (i.e., information systems operated by other federal agencies, including organizations subordinate to those agencies), the trust relationships that have been established between those organizations and the originating organization may be such, that no explicit terms and conditions are required. Information systems within these organizations\nwould not be considered external. These situations occur when, for example, there are pre-existing sharing/trust agreements (either implicit or explicit) established between federal agencies or organizations subordinate to those agencies, or when such trust agreements are specified by applicable laws, Executive Orders, directives, or policies. Authorized individuals include, for example, organizational personnel, contractors, or other individuals with authorized access to organizational information systems and over which organizations have the authority to impose rules of behavior with regard to system access. Restrictions that organizations impose on authorized individuals need not be uniform, as those restrictions may vary depending upon the\ntrust relationships between organizations. Therefore, organizations may choose to impose different security restrictions on contractors than on state, local, or tribal governments.\n\nThis control does not apply to the use of external information systems to access public interfaces to organizational information systems (e.g., individuals accessing federal information through www.usa.gov). Organizations establish terms and conditions for the use of external information systems in accordance with organizational security policies and procedures. Terms and conditions address as a minimum: types of applications that can be accessed on organizational information systems from external information systems; and the highest security category of information that can be processed, stored, or transmitted on external information systems. If terms and conditions with the owners of external information systems cannot be established, organizations may impose restrictions on organizational personnel using those external systems. Related controls: AC-3, AC-17, AC-19, CA-3, PL-4, SA-9.\n\nReferences: FIPS Publication 199.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "AC-20(1)", "levels": ["high", "moderate"], "notes": "Section a: The organization will be responsible for verifying the implementation of\nrequired security controls on external information systems used to\naccess the organization application. A successful control response will\nneed to address how this verification occurs (e.g. through an\nindependent assessment).\nSection b: If part (a) is not possible, then the organization will be responsible\nfor establishing and retaining approved information system connection\nor processing agreements with the external entity hosting the external\ninformation system used to access the organization application.", "title": "AC-20(1) - USE OF EXTERNAL INFORMATION SYSTEMS | LIMITS ON AUTHORIZED USE", "description": "The organization permits authorized individuals to use an external information system to access the information system or to process, store, or transmit organization-controlled information only when the organization:\n (a)   Verifies the implementation of required security controls on the external system as specified in the organization\u2019s information security policy and security plan; or\n (b)   Retains approved information system connection or processing agreements with the organizational entity hosting the external information system.\n\nSupplemental Guidance:  This control enhancement recognizes that there are circumstances where individuals using external information systems (e.g., contractors, coalition partners) need to access organizational information systems. In those situations, organizations need confidence that the external information systems contain the necessary security safeguards (i.e., security controls), so as not to compromise, damage, or otherwise harm organizational information systems. Verification that the required security controls have been implemented can be achieved, for example, by third-party, independent assessments, attestations, or other means, depending on the confidence level required by organizations. Related control: CA-2.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "AC-20(2)", "levels": ["high", "moderate"], "notes": "The organization will be responsible for restricting or prohibiting the\nuse of customer-controlled portable storage devices on external\ninformation systems. If such use is not prohibited, a successful\ncontrol response will need to address specific restrictions on how\nor under what conditions such use may occur.", "title": "AC-20(2) - USE OF EXTERNAL INFORMATION SYSTEMS | PORTABLE STORAGE DEVICES", "description": "The organization [Selection: restricts; prohibits] the use of organization-controlled portable storage devices by authorized individuals on external information systems.\n\nSupplemental Guidance:  Limits on the use of organization-controlled portable storage devices in external information systems include, for example, complete prohibition of the use of such devices or restrictions on how the devices may be used and under what conditions the devices may be used.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "AC-21", "levels": ["high", "moderate"], "notes": "Section a: The organization will be responsible for determining when authorized users\nare required to use discretion as to whether to share information. A\nsuccessful control response will need to address the circumstances\nwhere user direction (rather than automatic access enforcement) is\nrequired.\nSection b: The organization will be responsible for defining and employing automated\nmechanisms or manual processes to assist users in making information\nsharing decisions.", "title": "AC-21 - INFORMATION SHARING", "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\u00a0\nSupplemental Guidance:\u00a0This 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.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "AC-22", "levels": ["high", "moderate", "low"], "notes": "Section a: The organization will be responsible for designating individuals\nauthorized to post information publicly. A successful control response\nwill need to address the specific business requirements or job functions\nthat justify such access.\nSection b: The organization will be responsible for training designated authorized\nindividuals to prevent disclosure of nonpublic information. A\nsuccessful control response will need to outline the training\nprovided.\nSection c: The organization will be responsible for reviewing information prior to\npublic posting to ensure that nonpublic information is not included. A\nsuccessful control response will need to address the roles or personnel\nresponsible for this review and the process for signoff.\nSection d: The organization will be responsible for reviewing publicly available\ninformation at the required frequency and removing nonpublic information\nwhen discovered. A successful control response will need to address the\nroles or personnel responsible for the review, the process used to\nreview publicly available information, and the process for removal of\nnonpublic information.", "title": "AC-22 - PUBLICLY ACCESSIBLE CONTENT", "description": "The organization:\n a. Designates individuals authorized to post information onto a publicly accessible information system;\n b. Trains authorized individuals to ensure that publicly accessible information does not contain nonpublic information;\n c. Reviews the proposed content of information prior to posting onto the publicly accessible information system to ensure that nonpublic information is not included; and\n d. Reviews the content on the publicly accessible information system for nonpublic information [Assignment: organization-defined frequency] and removes such information, if discovered.\n\nSupplemental Guidance:  In accordance with federal laws, Executive Orders, directives, policies, regulations, standards, and/or guidance, the general public is not authorized access to nonpublic information (e.g., information protected under the Privacy Act and proprietary information). This control addresses information systems that are controlled by the organization and accessible to the general public, typically without identification or authentication. The posting of information on\nnon-organization information systems is covered by organizational policy. Related controls: AC-3, AC-4, AT-2, AT-3, AU-13.\n\nControl Enhancements: None.\n\nReferences: None.\n\nAC-22 (d) [at least quarterly]", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "AT-1", "levels": ["high", "moderate", "low"], "notes": "Section a: The organization will be responsible for developing, documenting, and\ndisseminating Security Awareness and Training policy and procedures.\nA successful control response will need to address the content of the\npolicy (which must include purpose, scope, roles, responsibilities,\nmanagement commitment, coordination, and compliance) and procedures\n(which must facilitate the implementation of the policies and\nassociated controls).\nSection b: The organization will be responsible for reviewing and updating the\nSecurity Awareness and Training policy every 3 years, and procedures\nannually. A successful control response will need to address the\nreview and update process, including the role(s) responsible for\ninitiating the review process, updating the policy and procedures,\nand providing approval of the updates.", "title": "AT-1 - SECURITY AWARENESS AND TRAINING POLICY AND PROCEDURES", "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]", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "AT-2", "levels": ["high", "moderate", "low"], "notes": "Section a: The customer will be responsible for providing basic security\nawareness training as part of initial training. A successful control\nresponse will outline the content of the training and will discuss the\nprocess for ensuring that all users undergo the required training.\nSection b: The customer will be responsible for providing updated basic security\nawareness training as required by information system changes. A\nsuccessful control response will discuss the process for determining\nwhat information system changes require updated training, how the\ntraining content is updated, and how users are notified of the need for\nre-training.\nSection c: The customer will be responsible for refreshing the basic security\nawareness training annually. A successful control response will\ndiscuss the process for ensuring that all users undergo the required\nre-training.", "title": "AT-2 - SECURITY AWARENESS TRAINING", "description": "The organization provides basic security awareness training to information system users (including managers, senior executives, and contractors):\n a. As part of initial training for new users;\n b. When required by information system changes; and\n c. [Assignment: organization-defined frequency] thereafter.\n\nSupplemental Guidance:  Organizations determine the appropriate content of security awareness training and security awareness techniques based on the specific organizational requirements and the information systems to which personnel have authorized access. The content includes a basic understanding of the need for information security and user actions to maintain security and to respond to suspected security incidents. The content also addresses awareness of the need for operations security. Security awareness techniques can include, for example, displaying posters, offering supplies inscribed with security reminders, generating email advisories/notices from senior organizational officials, displaying logon screen messages, and conducting information security awareness events. Related controls: AT-3, AT-4, PL-4.\n\nReferences: C.F.R. Part 5 Subpart C (5 C.F.R. 930.301); Executive Order 13587; NIST Special Publication 800-50.\n\nAT-2 (c) [at least annually]", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "AT-2(2)", "levels": ["high", "moderate"], "notes": "The organization will be responsible for including information about\nindicators of insider threat in security awareness training materials.\nA successful control response will summarize potential indicators of\ninsider threat and outline the process for reporting them to appropriate\norganizational officials.", "title": "AT-2(2) - SECURITY AWARENESS | INSIDER THREAT", "description": "The organization includes security awareness training on recognizing and reporting potential indicators of insider threat.\n\nSupplemental Guidance:  Potential indicators and possible precursors of insider threat can include behaviors such as inordinate, long-term job dissatisfaction, attempts to gain access to information not required for job performance, unexplained access to financial resources, bullying or sexual harassment of fellow employees, workplace violence, and other serious violations of organizational policies, procedures, directives, rules, or practices. Security awareness training includes how to communicate employee and management concerns regarding potential indicators of insider threat through appropriate organizational channels in accordance with established organizational policies and procedures. Related controls: PL-4, PM-12, PS-3, PS-6.\n\nReferences:  C.F.R. Part 5 Subpart C (5 C.F.R 930.301); Executive Order 13587; NIST Special Publication 800-50.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "AT-3", "levels": ["high", "moderate", "low"], "notes": "Section a: The organization will be responsible for providing role-based security\ntraining prior to users commencing work on their system. A successful\ncontrol response will outline the content of the training (including\nhow the content varies by assigned role) and will discuss the process\nfor ensuring that all users undergo the required training for their\nroles.\nSection b: The organization will be responsible for providing updated role-based\nsecurity training as required by information system changes. A\nsuccessful control response will discuss the process for determining\nwhat information system changes require updated training, how the\ntraining content is updated, and hw users are notified of the need\nfor re-training.\nSection c: The customer will be responsible for refreshing role-based security\ntraining annually. A successful control response will discuss the\nprocess for ensuring that all users undergo the required re-training.", "title": "AT-3 - ROLE-BASED SECURITY TRAINING", "description": "The organization provides role-based security training to personnel with assigned security roles and responsibilities:\na. Before authorizing access to the information system or performing assigned duties;\nb. When required by information system changes; and\nc. [Assignment: organization-defined frequency] thereafter.\n\nSupplemental Guidance:  Organizations determine the appropriate content of security training based on the assigned roles and responsibilities of individuals and the specific security requirements of organizations and the information systems to which personnel have authorized access. In addition, organizations provide enterprise architects, information system developers, software developers, acquisition/procurement officials, information system managers, system/network administrators, personnel conducting configuration management and auditing activities, personnel performing independent verification and validation activities, security control assessors, and other personnel having access to system-level software, adequate security-related technical training specifically tailored for their assigned duties. Comprehensive role-based training addresses management, operational, and technical roles and responsibilities covering physical, personnel, and technical safeguards and countermeasures. Such training can include for example, policies, procedures, tools, and artifacts for the organizational security roles defined. Organizations also provide the training necessary for individuals to carry out their responsibilities related to operations and\nsupply chain security within the context of organizational information security programs. Role-based security training also applies to contractors providing services to federal agencies. Related controls: AT-2, AT-4, PL-4, PS-7, SA-3, SA-12, SA-16.\n\nReferences: C.F.R. Part 5 Subpart C (5 C.F.R. 930.301); NIST Special Publications 800-16, 800-50.\n\nAT-3 (c) [at least annually]", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "AT-4", "levels": ["high", "moderate", "low"], "notes": "Section a: The organization will be responsible for tracking successful completion\nof basic security awareness training and role-based training\nsecurity training activities. A successful control response will discuss\nthe process or system used to monitor and document completion of\ntraining for each user.\nSection b: The organization will be responsible for retaining training records for\nthe required timeframe. A successful control response will outline the\nmethods by which required retention is achieved.", "title": "AT-4 - SECURITY TRAINING RECORDS", "description": "The organization:\n a. Documents and monitors individual information system security training activities including basic security awareness training and specific information system security training; and\n b. Retains individual training records for [Assignment: organization-defined time period].\n\nSupplemental Guidance:  Documentation for specialized training may be maintained by individual supervisors at the option of the organization. Related controls: AT-2, AT-3, PM-14.\n\nControl Enhancements:  None.\n\nReferences:  None.\n\nAT-4 (b) [five (5) years or 5 years after completion of a specific training program]", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "AU-1", "levels": ["high", "moderate", "low"], "notes": "Section a: The organization will be responsible for developing, documenting, and\ndisseminating Audit and Accountability policy and procedures. A\nsuccessful control response will need to address the content of the\npolicy (which must include purpose, scope, roles, responsibilities,\nmanagement commitment, coordination, and compliance) and procedures\n(which must facilitate the implementation of the policies and\nassociated controls).\nSection b: The organization will be responsible for reviewing and updating the\nAudit and Accountability policy every 3 years, and procedures\nannually. A successful control response will need to address the\nreview and update process, including the role(s) responsible\nfor initiating the review process, updating the policy and\nprocedures, and providing approval of the updates.", "title": "AU-1 - AUDIT AND ACCOUNTABILITY POLICY AND\nPROCEDURES", "description": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n   1. An audit and accountability 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 audit and accountability policy and associated audit and accountability controls; and\n b. Reviews and updates the current:\n   1. Audit and accountability policy [Assignment: organization-defined frequency]; and\n   2. Audit and accountability 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 AU family. Policy and procedures reflect applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance. Security program policies and procedures at the organization level may make the need for system-specific policies and procedures unnecessary. The policy can be included as part of the general information security policy for organizations or conversely, can be represented by multiple policies reflecting the complex nature of certain organizations. The procedures can be established for the security program in general and for particular information systems, if needed. The organizational risk management strategy is a key factor in establishing policy and procedures. Related control: PM-9.\n\nControl Enhancements:  None.\n\nReferences:  NIST Special Publications 800-12, 800-100.\n\nAU-1 (b) (1) [at least annually]\nAU-1 (b) (2) [at least annually or whenever a significant change occurs]", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "AU-2", "levels": ["high", "moderate", "low"], "notes": "Section a: The organization will be responsible for determining which events\ntheir software applications must be capable of auditing. A successful\ncontrol response will need to address the FedRAMP-required auditable\nevents listed above as well as any additional events the organization\nfeels should auditable based on organization needs.\nSection b: The organization will be responsible for implementing this control. A\nsuccessful control response will need to address coordination with all\ninterested parties (such as an internal SOC or security team) and\nincorporation of their input into business requirements in order to\ndetermine the selection of auditable events.\nSection c: The organization will be responsible for implementing this control. A\nsuccessful control response will include a discussion of the decision\nprocess behind the selection of auditable events and a justification for\nthe selected events being sufficient to support after-the-fact\ninvestigation.\nSection d: The customer will be responsible for selecting a subset of the events\nlisted in AU-2(a) to be audited by the system. For FedRAMP compliance,\nthese events must be monitored continuously. A successful control\nresponse will include a discussion of the rationale for the events\nchosen.\n\nNote this control only identifies which events are relevant for this\ninformation system. Technical implementation, at a information system\ncomponent level, is documented in AU-12(a).", "title": "AU-2 - AUDIT EVENTS", "description": "The organization:\n a. Determines that the information system is capable of auditing the following events: [Assignment: organization-defined auditable events];\n b. Coordinates the security audit function with other organizational entities requiring audit- related information to enhance mutual support and to help guide the selection of auditable events;\n c. Provides a rationale for why the auditable events are deemed to be adequate to support after- the-fact investigations of security incidents; and\n d. Determines that the following events are to be audited within the information system: [Assignment: organization-defined audited events (the subset of the auditable events defined in AU-2 a.) along with the frequency of (or situation requiring) auditing for each identified event].\n\nSupplemental Guidance:  An event is any observable occurrence in an organizational information system. Organizations identify audit events as those events which are significant and relevant to the security of information systems and the environments in which those systems operate in order to meet specific and ongoing audit needs. Audit events can include, for example, password changes, failed logons, or failed accesses related to information systems, administrative privilege usage, PIV credential usage, or third-party credential usage. In determining the set of auditable events, organizations consider the auditing appropriate for each of the security controls to be implemented. To balance auditing requirements with other information system needs, this control also requires identifying that subset of auditable events that are audited at a given point in time. For example, organizations may determine that information systems must have the capability to log every file access both successful and unsuccessful, but not activate that capability except for specific circumstances due to the potential burden on system performance. Auditing requirements, including the need for auditable events, may be referenced in other security controls and control enhancements. Organizations also include auditable events that are required by applicable federal laws, Executive Orders, directives, policies, regulations, and standards. Audit records can be generated at various levels of abstraction, including at the packet level as information traverses the network. Selecting the appropriate level of abstraction is a critical aspect of an audit capability and can facilitate the identification of root causes to problems. Organizations consider in the definition of auditable events, the auditing necessary to cover related events such as the steps in distributed, transaction-based processes (e.g., processes that are distributed across multiple organizations) and actions that occur in service-oriented architectures. Related controls: AC-6, AC-17, AU-3, AU-12, MA-4, MP-2, MP-4, SI-4.\n\nReferences: NIST Special Publication 800-92; Web: http://idmanagement.gov.\n\nAU-2 (a) [successful and unsuccessful account logon events, account management events, object access, policy change, privilege functions, process tracking, and system events. For Web applications: all administrator activity, authentication checks, authorization checks, data deletions, data access, data changes, and permission changes]\nAU-2 (d) [organization-defined subset of the auditable events defined in AU-2a to be audited continually for each identified event].\nAU-2 Requirement: Coordination between service provider and consumer shall be documented and accepted by the JAB/AO.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "AU-2(3)", "levels": ["high", "moderate"], "notes": "Customers are responsible for reviewing and updating the audited\nevents annually or whenever there is a change in the threat environment.\nA successful control response will outline how often events are\nreviewed.", "title": "AU-2(3) - AUDIT EVENTS | REVIEWS AND UPDATES", "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.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "AU-3", "levels": ["high", "moderate", "low"], "notes": "The organization is responsible for generating audit records that contain\ninformation that establishes what type of event occurred, when the event\noccurred, where the event occurred, the source of the event, the\noutcome of the event, and the identity of any individuals or subjects\nassociated with the event. A successful control response will outline\nwhat metadata the organization requires audit records to contain.", "title": "AU-3 - CONTENT OF AUDIT RECORDS", "description": "The information system generates audit records containing information that establishes what type of event occurred, when the event occurred, where the event occurred, the source of the event, the outcome of the event, and the identity of any individuals or subjects associated with the event.\n\nSupplemental Guidance:  Audit record content that may be necessary to satisfy the requirement of this control, includes, for example, time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked. Event outcomes can include indicators of event success or failure and event-specific results (e.g., the security state of the information system after the event occurred). Related controls: AU-2, AU-8, AU-12, SI-11.\n\nReferences: None.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "AU-3(1)", "levels": ["high", "moderate"], "notes": "The organization is responsible ensuring that the information system\naudit records contain all of the information required to meet\nFedRAMP requirements. A successful control response will outline the\nsystems audit generation, and the content that it includes.\n\nNote: This control defines what supplementary data audit records must\ncontain, such as full text recording of privileged commands. Metadata\nelements of audit logs are defined in AU-3. Component configuration is\nestablished through AU-12(c).", "title": "AU-3(1) - CONTENT OF AUDIT RECORDS | ADDITIONAL AUDIT INFORMATION", "description": "The information system generates audit records containing the following additional information: [Assignment: organization-defined additional, more detailed information].\n\nSupplemental Guidance:  Detailed information that organizations may consider in audit records includes, for example, full text recording of privileged commands or the individual identities of group account users. Organizations consider limiting the additional audit information to only that information explicitly needed for specific audit requirements. This facilitates the use of audit trails and audit logs by not including information that could potentially be misleading or could make it more difficult to locate information of interest.\n\nAU-3 (1) [session, connection, transaction, or activity duration; for client-server transactions, the number of bytes received and bytes sent; additional informational messages to diagnose or identify the event; characteristics that describe or identify the object or resource being acted upon; individual identities of group account users; full-text of privileged commands]\nAU-3 (1) Guidance: For client-server transactions, the number of bytes sent and received gives bidirectional transfer information that can be helpful during an investigation or inquiry.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "AU-4", "levels": ["high", "moderate", "low"], "notes": "Customers are responsible for allocating audit record storage capacity\nin accordance with the organizations requirements. A successful control\nresponse will explain the procedures in place to ensure that audit\nstorage is allocated according to meet customer requirements.", "title": "AU-4 - AUDIT STORAGE CAPACITY", "description": "The organization allocates audit record storage capacity in accordance with [Assignment:\norganization-defined audit record storage requirements].\n\nSupplemental Guidance:  Organizations consider the types of auditing to be performed and the audit processing requirements when allocating audit storage capacity. Allocating sufficient audit storage capacity reduces the likelihood of such capacity being exceeded and resulting in the potential loss or reduction of auditing capability. Related controls: AU-2, AU-5, AU-6, AU-7, AU-11, SI-4.\n\nReferences: None.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "AU-6", "levels": ["high", "moderate", "low"], "notes": "Section a: Customers are responsible for review and analysis of the information\nsystem audit records at least weekly for indications of inappropriate\nor unusual activity. A successful control response will outline how\noften audit records are reviewed, and types of activities they are\nreviewed for.\nSection b: Customers are responsible for ensuring that audit review findings are\nreported to the appropriate personnel. A successful control response\nwill outline how the audit review findings are reported.", "title": "AU-6 - AUDIT REVIEW, ANALYSIS, AND REPORTING", "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.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "AU-6(1)", "levels": ["high", "moderate"], "notes": "Customers are responsible for employing automated mechanisms to\nintegrate audit, review, analysis, and reporting process to support\norganizational processes for investigation and response to suspicious\nactivities. A successful control response will review the automated\ntools used for integrating review, analysis, and reporting, and how\nthese tools are employed.", "title": "AU-6(1) - AUDIT REVIEW, ANALYSIS, AND REPORTING | PROCESS INTEGRATION", "description": "The organization employs automated mechanisms to integrate audit review, analysis, and reporting processes to support organizational processes for investigation and response to suspicious activities.\n\nSupplemental Guidance:  Organizational processes benefiting from integrated audit review, analysis, and reporting include, for example, incident response, continuous monitoring, contingency planning, and Inspector General audits. Related controls: AU-12, PM-7.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "AU-6(3)", "levels": ["high", "moderate"], "notes": "Customers are responsible for analyzing and correlating audit records\nacross different repositories to gain organizational-wide situational\nawareness. A successful control response will discuss how the organization\ncorrelates and analyzes audit records from different sources. This can\ninclude processes and tools used to meet these goals.", "title": "AU-6(3) - AUDIT REVIEW, ANALYSIS, AND REPORTING | CORRELATE AUDIT REPOSITORIES", "description": "The organization analyzes and correlates audit records across different repositories to gain organization-wide situational awareness.\n\nSupplemental Guidance:  Organization-wide situational awareness includes awareness across all three tiers of risk management (i.e., organizational, mission/business process, and information system) and supports cross-organization awareness. Related controls: AU-12, IR-4.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "AU-7", "levels": ["high", "moderate"], "notes": "Section a: Customers are responsible for ensuring that the information system\nprovides an audit reduction and report generation capability that\nsupports on demand audit review, analysis, and reporting requirements\nand after-the-fact investigations of security incidents. A successful\ncontrol response will discuss how the information system provides\naudit reduction and report generation that supports these requirements.\nThis can include a discussion of tools used to provide this capability,\nand how they are used.", "title": "AU-7 - AUDIT REDUCTION AND REPORT GENERATION", "description": "The information system provides an audit reduction and report generation capability that:\n a. Supports on-demand audit review, analysis, and reporting requirements and after-the-fact investigations of security incidents; and\n b. Does not alter the original content or time ordering of audit records.\n\nSupplemental Guidance:  Audit reduction is a process that manipulates collected audit information and organizes such information in a summary format that is more meaningful to analysts. Audit reduction and report generation capabilities do not always emanate from the same information system or from the same organizational entities conducting auditing activities. Audit reduction capability can include, for example, modern data mining techniques with advanced data filters to identify anomalous behavior in audit records. The report generation capability provided by the information system can generate customizable reports. Time ordering of audit records can be a significant issue if the granularity of the timestamp in the record is insufficient. Related control: AU-6.\n\nReferences: None.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "AU-9(4)", "levels": ["high", "moderate"], "notes": "Customers are required to authorize access to management of audit\nfunctionality to only a subset of privileged users. A successful control\nresponse will discuss how access to audit functionality is restricted\nto only appropriate personnel. This can include a description of who\nthis functionality is restricted to, and how this is controlled.", "title": "AU-9(4) - PROTECTION OF AUDIT INFORMATION | ACCESS BY SUBSET OF PRIVILEGED USERS", "description": "The organization authorizes access to management of audit functionality to only [Assignment: organization-defined subset of privileged users].\n\nSupplemental Guidance:  Individuals with privileged access to an information system and who are also the subject of an audit by that system, may affect the reliability of audit information by inhibiting audit activities or modifying audit records. This control enhancement requires that privileged access be further defined between audit-related privileges and other privileges, thus limiting the users with audit-related privileges. Related control: AC-5.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "AU-11", "levels": ["high", "moderate", "low"], "notes": "Customers are required to retain audit records for at least ninety\ndays to provide support for after the fact investigations of security\nincidents and to meet regulatory and organizational information\nretention requirements. A successful control response will discuss how\nlong audit records are retained.\n\nAudit log retention may be configured in the underlying Red Hat\nEnterprise Linux audit daemon. If using a central or 3rd party\nlogging solution, this may likely need to be configured in that tool.", "title": "AU-11 - AUDIT RECORD RETENTION", "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.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "CA-1", "levels": ["high", "moderate", "low"], "notes": "Section a: The organization will be responsible for developing, documenting, and\ndisseminating Security Assessment and Authorization policy and\nprocedures. A successful control response will need to address the\ncontent of the policy (which must include purpose, scope, roles,\nresponsibilities, management commitment, coordination, and compliance)\nand procedures (which must facilitate the implementation of\nthe policies and associated controls).\nSection b: The organization will be responsible for reviewing and updating the\nSecurity Assessment and Authorization policy every 3 years, and\nprocedures annually. A successful control response will need to\naddress the review and update process, including the role(s)\nresponsible for initiating the review process, updating the policy\nand procedures, and providing approval of the updates.", "title": "CA-1 - SECURITY ASSESSMENT AND AUTHORIZATION\nPOLICY AND PROCEDURES", "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]", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "CA-2", "levels": ["high", "moderate", "low"], "notes": "Section a: The organization will be responsible for developing a Security Assessment\nPlan. A successful control response will need to address the\ninvolvement of a FedRAMP-accredited 3PAO (see CA-2(1)), the scope\nof the assessment, and any specific requirements the organization has\nfor the 3PAO.", "title": "CA-2 - SECURITY ASSESSMENTS", "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/", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "CA-2(1)", "levels": ["high", "moderate", "low"], "notes": "The customer will be responsible for employing a FedRAMP-accredited\n3PAO to conduct security control assessments. In addition to performing\nthe assessment, this 3PAO will assist in the development of the Security\nAssessment Plan and Security Assessment Report (see CA-2).", "title": "CA-2(1) - SECURITY ASSESSMENTS | INDEPENDENT ASSESSORS", "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.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "CA-2(2)", "levels": ["high", "moderate"], "notes": "The customer will be responsible for ensuring that, at a minimum,\nvulnerability scanning is performed annually as part of the\nassessment process. A successful control response will need to address\nthe minimum requirement, as well as discussing any additional testing\nperformed during assessments, such as malicious user testing, insider\nthreat assessment, performance/load testing, or other tests the customer\nchooses to perform.", "title": "CA-2(2) - SECURITY ASSESSMENTS | SPECIALIZED ASSESSMENTS", "description": "The organization includes as part of security control assessments, [Assignment: organization- defined frequency], [Selection: announced; unannounced], [Selection (one or more): in-depth monitoring; vulnerability scanning; malicious user testing; insider threat assessment; performance/load testing; [Assignment: organization-defined other forms of security assessment]].\n\nSupplemental Guidance:  Organizations can employ information system monitoring, insider threat assessments, malicious user testing, and other forms of testing (e.g., verification and validation) to improve readiness by exercising organizational capabilities and indicating current performance levels as a means of focusing actions to improve security. Organizations conduct assessment activities in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards. Authorizing officials approve the assessment methods in coordination with the organizational risk executive function. Organizations can incorporate vulnerabilities uncovered during assessments into vulnerability remediation processes. Related controls: PE-3, SI-2.\n\nCA-2 (2) [at least annually]\nCA-2 (2) Requirement: To include 'announced', 'vulnerability scanning'", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "CA-2(3)", "levels": ["high", "moderate"], "notes": "The customer will be responsible for working with a 3PAO to assess\nthe system using the methodology prescribed by FedRAMP. A successful\ncontrol response will need to address how the assessment will be carried\nout and how the results will be documented and submitted to FedRAMP\nfor approval.", "title": "CA-2(3) - SECURITY ASSESSMENTS | EXTERNAL ORGANIZATIONS", "description": "The organization accepts the results of an assessment of [Assignment: organization-defined information system] performed by [Assignment: organization-defined external organization] when the assessment meets [Assignment: organization-defined requirements].\n\nSupplemental Guidance:  Organizations may often rely on assessments of specific information systems by other (external) organizations. Utilizing such existing assessments (i.e., reusing existing assessment evidence) can significantly decrease the time and resources required for organizational assessments by limiting the amount of independent assessment activities that organizations need to perform. The factors that organizations may consider in determining whether to accept assessment results from external organizations can vary. Determinations for accepting assessment results can be based on, for example, past assessment experiences one organization has had with another organization, the reputation that organizations have with regard to assessments, the level of detail of supporting assessment documentation provided, or mandates imposed upon organizations by federal legislation, policies, or directives.\n\nCA-2 (3)-1 [any FedRAMP Accredited 3PAO]\nCA-2 (3)-1-2 [any FedRAMP Accredited 3PAO]\nCA-2 (3)-1-3 [the conditions of the JAB/AO in the FedRAMP Repository]", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "CA-3", "levels": ["high", "moderate", "low"], "notes": "Section a: The customer will be responsible for authorizing connections to\nexternal information systems. A successful control response will\nneed to address the individuals or roles responsible for engaging with\nauthorized points of contact for such external systems and the process\nfor documenting and signing the conditions of the connections in\nInterconnection System Agreements.\nSection b: The customer will be responsible for documenting the details of each\ninterconnection. A successful control response will need to address\nthe process for verifying the interface characteristics, security\nrequirements, and the nature of the information communicated; a summary\nof this information will need to be included as part of the table\nabove.\nSection c: The customer will be responsible for reviewing and updating the\nInterconnection Security Agreements at the required frequency. A\nsuccessful control response will need to discuss the initiation of the\nreview process, as well as the roles or individuals responsible for\nreviewing, verifying, updating, and approving any changes to the\ndocumentation.", "title": "CA-3 - SYSTEM INTERCONNECTIONS", "description": "The organization:\n a. Authorizes connections from the information system to other information systems through the use of Interconnection Security Agreements;\n b. Documents, for each interconnection, the interface characteristics, security requirements, and the nature of the information communicated; and\n c. Reviews and updates Interconnection Security Agreements [Assignment: organization-defined frequency].\n\nSupplemental Guidance:  This control applies to dedicated connections between information systems (i.e., system interconnections) and does not apply to transitory, user-controlled connections such as email and website browsing. Organizations carefully consider the risks that may be introduced when information systems are connected to other systems with different security requirements and security controls, both within organizations and external to organizations. Authorizing officials determine the risk associated with information system connections and the appropriate controls employed. If interconnecting systems have the same authorizing official, organizations do not need to develop Interconnection Security Agreements. Instead, organizations can describe the interface characteristics between those interconnecting systems in their respective security plans. If interconnecting systems have different authorizing officials within the same organization, organizations can either develop Interconnection Security Agreements or describe the interface characteristics between systems in the security plans for the respective systems. Organizations may also incorporate Interconnection Security Agreement information into formal contracts, especially for interconnections established between federal agencies and nonfederal (i.e., private sector) organizations. Risk considerations also include information systems sharing the same networks. For certain technologies (e.g., space, unmanned aerial vehicles, and medical devices), there may be specialized connections in place during preoperational testing. Such connections may require Interconnection Security Agreements and be subject to additional security controls.\nRelated controls: AC-3, AC-4, AC-20, AU-2, AU-12, AU-16, CA-7, IA-3, SA-9, SC-7, SI-4.\n\nReferences: FIPS Publication 199; NIST Special Publication 800-47.\n\nCA-3 (c) [at least annually and on input from FedRAMP]", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "CA-3(3)", "levels": ["high", "moderate"], "notes": "The organization will be responsible for requiring unclassified,\nnon-national security systems to connect to customer applications\nthrough a TIC. A successful control response will need to address\nwhether this requirement is enforced using technical means or via\npolicy considerations.", "title": "CA-3(3) - SYSTEM INTERCONNECTIONS | UNCLASSIFIED NON-NATIONAL SECURITY SYSTEM CONNECTIONS", "description": "The organization prohibits the direct connection of an [Assignment: organization-defined unclassified, non-national security system] to an external network without the use of [Assignment; organization-defined boundary protection device].\n\nSupplemental Guidance:  Organizations typically do not have control over external networks (e.g., the Internet). Approved boundary protection devices (e.g., routers, firewalls) mediate communications (i.e., information flows) between unclassified non-national security systems and external networks. This control enhancement is required for organizations processing, storing, or transmitting Controlled Unclassified Information (CUI).\n\nCA-3 (3)-2 [Boundary Protections which meet the Trusted Internet Connection (TIC) requirements]\nCA-3 (3) Guidance: Refer to Appendix H \u2013 Cloud Considerations of the TIC 2.0 Reference Architecture document.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "CA-3(5)", "levels": ["high", "moderate"], "notes": "The customer will be responsible for determining whether connections\nto external information systems will be governed by an\nallow-all/deny-by-exception policy or by a deny-all/allow-by-exception\npolicy. A successful control response will need to address the rationale\nfor the selection. In addition, the policy choice and its rationale will\nneed to be included in the Architecture Briefing and in the introductory\nsections of this Security Plan.", "title": "CA-3(5) - SYSTEM INTERCONNECTIONS | RESTRICTIONS ON EXTERNAL SYSTEM CONNECTIONS", "description": "The organization employs [Selection: allow-all, deny-by-exception; deny-all, permit-by-exception] policy for allowing [Assignment: organization-defined information systems] to connect to external information systems.\n\nSupplemental Guidance:  Organizations can constrain information system connectivity to external domains (e.g., websites) by employing one of two policies with regard to such connectivity: (i) allow-all, deny by exception, also known as blacklisting (the weaker of the two policies); or (ii) deny-all, allow by exception, also known as whitelisting (the stronger of the two policies). For either policy, organizations determine what exceptions, if any, are acceptable. Related control: CM-7.\n\nCA-3 (5) [deny-all, permit by exception]\n\n[any systems]\nCA-3 (5) Guidance: For JAB Authorization, CSPs shall include details of this control in their Architecture Briefing", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "CA-6", "levels": ["high", "moderate", "low"], "notes": "Section a: The organization will be responsible for working with FedRAMP to designate\nan authorizing official. A successful control response will need to\naddress how an appropriate authorizing official is selected.\nSection b: The organization will be responsible for receiving official authorization\nfrom the authorizing official prior to commencing operations for\nfederal customers. A successful control response will need to address\nthe inputs provided to the authorizing official so that an\naccreditation decision can be made.\nSection c: The organization will be responsible for updating the accreditation\npackage at the required frequency. A successful control response will\nneed to address the components of the package that will be updated,\nthe process for re-assessing the system in alignment with the updated\npackage, and the personnel or roles responsible for managing the\nupdate process and engaging with FedRAMP for renewal of authorization.", "title": "CA-6 - SECURITY AUTHORIZATION", "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.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "CA-7", "levels": ["high", "moderate", "low"], "notes": "Section a: The organization will be responsible for developing a continuous\nmonitoring strategy that meets the requirements. For metrics to be\nmonitored, a successful control response will need to include a\ndiscussion of what information the organization considers important to\nmonitor, as well as a rationale for that information being sufficient\nto demonstrate the ongoing security of the system.\nSection b: The organization will be responsible for developing a continuous\nmonitoring strategy that meets the requirements. For frequency of\nmonitoring, a successful control response will need to address the\nrationale for the selected frequency. This frequency should be\ncompatible with the frequency of POA&M reporting specified in CA-5.\nSection c: The customer will be responsible for including ongoing security\ncontrol assessments as part of the continuous monitoring program. This\nmay include assessment of controls specifically found to be other than\nsatisfied as part of the 3PAO assessments discussed in CA-2, as well as\ninternal assessment of satisfied controls to verify continued\neffectiveness of implementation. A successful control response will\nneed to address the roles or individuals responsible for testing, as\nwell as the methodology used for testing.\nSection d: The customer will be responsible for monitoring the metrics defined\nin part (a) as part of continuous monitoring. A successful control\nresponse will need to discuss how metrics are gathered and reported,\nas well as the conditions under which monitoring will lead to changes\nor additions to related reporting, such as POA&M reporting.\nSection e: The customer will be responsible for correlating and analyzing\nsecurity-related information gathered from multiple sources, including\nperiodic assessments and continuous monitoring. A successful control\nresponse will need to address tools or processes used to perform\ncorrelation and analysis.\nSection f: The customer will be responsible for responding appropriately\nto the results of the analysis in part (e). A successful control\nresponse will need to discuss under what conditions each response action\nshould be taken (for example, if a new vulnerability is found in the\nsystem, a POA&M item should be opened).\nSection g: The customer will be responsible for reporting the security status of\nthe system in accordance with FedRAMP requirements at a regular\nfrequency. This frequency should be compatible with the frequency of\nPOA&M reporting specified in CA-5.\nSection Req. 1: The customer will be responsible for performing vulnerability scans\nof operating systems at least monthly. See also RA-5.\nSection Req. 2: The customer will be responsible for performing vulnerability scans\nof databases and web applications at least monthly. See also RA-5.\nSection Req. 3: The customer will be responsible for ensuring that an independent\nassessor performs vulnerability scans at least annually. See also\nCA-2(2).", "title": "CA-7 - CONTINUOUS MONITORING", "description": "The organization develops a continuous monitoring strategy and implements a continuous monitoring program that includes:\n a. Establishment of [Assignment: organization-defined metrics] to be monitored;\n b. Establishment of [Assignment: organization-defined frequencies] for monitoring and [Assignment: organization-defined frequencies] for assessments supporting such monitoring;\n c. Ongoing security control assessments in accordance with the organizational continuous monitoring strategy;\n d. Ongoing security status monitoring of organization-defined metrics in accordance with the organizational continuous monitoring strategy;\n e. Correlation and analysis of security-related information generated by assessments and monitoring;\n f. Response actions to address results of the analysis of security-related information; and\n g. Reporting the security status of organization and the information system to [Assignment: organization-defined personnel or roles] [Assignment: organization-defined frequency].\n\nSupplemental Guidance:  Continuous monitoring programs facilitate ongoing awareness of threats, vulnerabilities, and information security to support organizational risk management decisions. The terms continuous and ongoing imply that organizations assess/analyze security controls and information security-related risks at a frequency sufficient to support organizational risk-based decisions. The results of continuous monitoring programs generate appropriate risk response actions by organizations. Continuous monitoring programs also allow organizations to maintain the security authorizations of information systems and common controls over time in highly dynamic environments of operation with changing mission/business needs, threats, vulnerabilities, and technologies. Having access to security-related information on a continuing basis through reports/dashboards gives organizational officials the capability to make more effective and timely risk management decisions, including ongoing security authorization decisions. Automation supports more frequent updates to security authorization packages, hardware/software/firmware inventories, and other system information. Effectiveness is further enhanced when continuous monitoring outputs are formatted to provide information that is specific, measurable, actionable, relevant, and timely. Continuous monitoring activities are scaled in accordance with the security categories of information systems. Related controls: CA-2, CA-5, CA-6, CM-3, CM-4, PM-6, PM-9, RA-5, SA-11, SA-12, SI-2, SI-4.\n\nReferences: OMB Memorandum 11-33; NIST Special Publications 800-37, 800-39, 800-53A, 800-115, 800-137; US-CERT Technical Cyber Security Alerts; DoD Information Assurance Vulnerability Alerts.\n\nCA-7 (g) [to meet Federal and FedRAMP requirements]\nCA-7 Requirement: Operating System Scans: at least monthly. Database and Web Application Scans: at least monthly. All scans performed by Independent Assessor: at least annually\nCA-7 Guidance: CSPs must provide evidence of closure and remediation of high vulnerabilities within the timeframe for standard POA&M updates.\nCA-7 Guidance: See the FedRAMP Documents page under Key Cloud Service\nProvider (CSP) Documents> Continuous Monitoring Strategy Guide\nhttps://www.FedRAMP.gov/documents/", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "CA-7(1)", "levels": ["high", "moderate"], "notes": "The customer will be responsible for monitoring security controls on\nan ongoing basis with the assistance of an assessment team with a\ncontrol-defined level of independence. Note that this may be the 3PAO\nused for recurring assessments, it may be a different independent\nassessor, or it may be a team of personnel employed by the customer. A\nsuccessful control response will need to address the nature of this team\nand the methods by which they access security controls within the\nsystem.", "title": "CA-7(1) - CONTINUOUS MONITORING | INDEPENDENT ASSESSMENT", "description": "The organization employs assessors or assessment teams with [Assignment: organization-defined level of independence] to monitor the security controls in the information system on an ongoing basis.\n\nSupplemental Guidance:  Organizations can maximize the value of assessments of security controls during the continuous monitoring process by requiring that such assessments be conducted by assessors or assessment teams with appropriate levels of independence based on continuous monitoring strategies. Assessor independence provides a degree of impartiality to the monitoring process. To achieve such impartiality, assessors should not: (i) create a mutual or conflicting interest with the organizations where the assessments are being conducted; (ii) assess their own work; (iii) act as management or employees of the organizations they are serving; or (iv) place themselves in advocacy positions for the organizations acquiring their services.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "CA-8", "levels": ["high", "moderate"], "notes": "The customer will be responsible for conducting penetration testing\nat the required frequency. A successful control response will need to\naddress the systems or components tested and outline the rules of\nengagement for testing (e.g. operational personnel are/are not notified\nin advance of testing, certain components of the system are off-limits\nfor this test, etc.).", "title": "CA-8 - PENETRATION TESTING", "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/", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "CA-8(1)", "levels": ["high", "moderate"], "notes": "The customer will be responsible for employing an independent agent\nor team to perform penetration testing. A successful control response\nwill need to address how independence is ensured.", "title": "CA-8(1) - PENETRATION TESTING | INDEPENDENT PENETRATION AGENT OR TEAM", "description": "The organization employs an independent penetration agent or penetration team to perform penetration testing on the information system or system components.\n\nSupplemental Guidance:  Independent penetration agents or teams are individuals or groups who conduct impartial penetration testing of organizational information systems. Impartiality implies that penetration agents or teams are free from any perceived or actual conflicts of interest with regard to the development, operation, or management of the information systems that are the targets of the penetration testing. Supplemental guidance for CA-2 (1) provides additional information regarding independent assessments that can be applied to penetration testing. Related control: CA-2.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "CA-9", "levels": ["high", "moderate", "low"], "notes": "Section a: The customer will be responsible for authorizing connections within\nthe system, such as between two types of virtual machines within the\ncustomer environment. A successful control response will need to address\nthe individual or roles with the authorizing responsibility, as well\nas how a determination is made to allow a connection between\ncomponents or classes of components.\nSection b: The customer will be responsible for documenting the required\ninformation for each internal connection. This may be documented in\ne.g. data flow diagrams or architectural diagrams. A successful control\nresponse will need to address the process by which this documentation\nis created.", "title": "CA-9 - INTERNAL SYSTEM CONNECTIONS", "description": "The organization:\n a. Authorizes internal connections of [Assignment: organization-defined information system components or classes of components] to the information system; and\n b. Documents, for each internal connection, the interface characteristics, security requirements, and the nature of the information communicated.\n\nSupplemental Guidance:  This control applies to connections between organizational information systems and (separate) constituent system components (i.e., intra-system connections) including, for example, system connections with mobile devices, notebook/desktop computers, printers, copiers, facsimile machines, scanners, sensors, and servers. Instead of authorizing each individual internal connection, organizations can authorize internal connections for a class of components with common characteristics and/or configurations, for example, all digital printers, scanners, and copiers with a specified processing, storage, and transmission capability or all smart phones with a specific baseline configuration. Related controls: AC-3, AC-4, AC-18, AC-19, AU-2, AU-12, CA-7, CM-2, IA-3, SC-7, SI-4.\n\nReferences: None.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "CM-1", "levels": ["high", "moderate", "low"], "notes": "Section a: The organization will be responsible for developing, documenting, and\ndisseminating Configuration Management policy and procedures. A\nsuccessful control response will need to address the content of the\npolicy (which must include purpose, scope, roles, responsibilities,\nmanagement commitment, coordination, and compliance) and procedures\n(which must facilitate the implementation of the policies and\nassociated controls).\nSection b: The organization will be responsible for reviewing and updating the\nConfiguration Management policy every 3 years, and procedures\nannually. A successful control response will need to address\nthe review and update process, including the role(s) responsible\nfor initiating the review process, updating the policy and\nprocedures, and providing approval of the updates", "title": "CM-1 - CONFIGURATION MANAGEMENT POLICY AND\nPROCEDURES", "description": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n   1. A configuration management 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 configuration management policy and associated configuration management controls; and\n b. Reviews and updates the current:\n   1. Configuration management policy [Assignment: organization-defined frequency]; and\n   2. Configuration management 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 CM family. Policy and procedures reflect applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance. Security program policies and procedures at the organization level may make the need for system-specific policies and procedures unnecessary. The policy can be included as part of the general information security policy for organizations or conversely, can be represented by multiple policies reflecting the complex nature of certain organizations. The procedures can be established for the security program in general and for particular information systems, if needed. The organizational risk management strategy is a key factor in establishing policy and procedures. Related control: PM-9.\n\nControl Enhancements:  None.\n\nReferences:  NIST Special Publications 800-12, 800-100.\n\nCM-1 (b) (1) [at least annually]\nCM-1 (b) (2) [at least annually or whenever a significant change occurs]", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "CM-2", "levels": ["high", "moderate", "low"], "notes": "The customer will be responsible for developing, documenting, and\nmaintaining configuration control, a current baseline configuration\nof the information system. A successful control response will need to\naddress the way the baseline configurations are managed and\nmaintained.", "title": "CM-2 - BASELINE CONFIGURATION", "description": "The organization develops, documents, and maintains under configuration control, a current baseline configuration of the information system.\n\nSupplemental Guidance:  This control establishes baseline configurations for information systems and system components including communications and connectivity-related aspects of systems. Baseline configurations are documented, formally reviewed and agreed-upon sets of specifications for information systems or configuration items within those systems. Baseline configurations serve as a basis for future builds, releases, and/or changes to information systems. Baseline configurations include information about information system components (e.g., standard software packages installed on workstations, notebook computers, servers, network components, or mobile devices; current version numbers and patch information on operating systems and applications; and configuration settings/parameters), network topology, and the logical placement of those components within the system architecture. Maintaining baseline configurations requires creating new baselines as organizational information systems change over time. Baseline configurations of information systems reflect the current enterprise architecture. Related controls: CM-3, CM-6, CM-8, CM-9, SA-10, PM-5, PM-7.\n\nReferences: NIST Special Publication 800-128.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "CM-2(1)", "levels": ["high", "moderate"], "notes": "Section a: The customer will be responsible for reviewing and updating the\nbaseline configuration of the information system at least annually.\nA successful control response will need to address how often the\nbaseline configuration is reviewed and updated.\nSection b: The customer will be responsible for reviewing and updating the\nbaseline configuration of the information system when required by the\nJAB. A successful control response will need to address updates to the\nbaseline configuration when required by the JAB.", "title": "CM-2(1) - BASELINE CONFIGURATION | REVIEWS AND UPDATES", "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.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "CM-3", "levels": ["high", "moderate"], "notes": "Section a: The customer will be responsible for determining the types of changes\nto the information system that are configuration controlled. A\nsuccessful control response will need to address how decisions are made\nto determine configuration controlled changes.\nSection b: The customer will be responsible for reviewing proposed configuration\ncontrolled changes to the information system and approving or\ndisapproving changes with explicit consideration for security impact\nanalysis. A successful control response will need to address how\ndecisions are made to approve configuration control changes, including\nhow the security impact of these changes is considered.\nSection c: The customer will be responsible for documenting configuration change\ndecisions. A successful control response will need to address how\nconfiguration change decisions are documented. This can include, for\nexample, what tools are used and what information is documented.\nSection e: The customer will be responsible for retaining records of\nconfiguration-controlled changes to the information system for a\ndefined period. A successful control response will need to address long\nrecords of configuration-controlled changes are kept, and where these\nrecords are maintained.\nSection f: The customer will be responsible for auditing and reviewing activities\nassociated with configuration-controlled changes to the information\nsystem for a defined period. A successful control response will need\nto ensure configuration control change activities are audited and\nreviewed. This can include tools used to track these changes and when\nthese changes are reviewed.\nSection g: The customer will be responsible for coordinating and providing\noversight for the configuration control activities through a central\nmeans of communicating major changes or developments that may affect\nservices to the federal government. The means of communication must\nbe approved and accepted by the JAB. A successful control response\nwill outline how major changes or developments that affect government\nservices will be coordinated and overseen.", "title": "CM-3 - CONFIGURATION CHANGE CONTROL", "description": "The organization:\n a. Determines the types of changes to the information system that are configuration-controlled;\n b. Reviews proposed configuration-controlled changes to the information system and approves or disapproves such changes with explicit consideration for security impact analyses;\n c. Documents configuration change decisions associated with the information system;\n d. Implements approved configuration-controlled changes to the information system;\n e. Retains records of configuration-controlled changes to the information system for [Assignment: organization-defined time period];\n f. Audits and reviews activities associated with configuration-controlled changes to the information system; and\n g. Coordinates and provides oversight for configuration change control activities through [Assignment: organization-defined configuration change control element (e.g., committee, board] that convenes [Selection (one or more): [Assignment: organization-defined frequency]; [Assignment: organization-defined configuration change conditions]].\n\nSupplemental Guidance:  Configuration change controls for organizational information systems involve the systematic proposal, justification, implementation, testing, review, and disposition of changes to the systems, including system upgrades and modifications. Configuration change control includes changes to baseline configurations for components and configuration items of information systems, changes to configuration settings for information technology products (e.g., operating systems, applications, firewalls, routers, and mobile devices), unscheduled/unauthorized changes, and changes to remediate vulnerabilities. Typical processes for managing configuration changes to information systems include, for example, Configuration Control Boards that approve proposed changes to systems. For new development information systems or systems undergoing major upgrades, organizations consider including representatives from development organizations on the Configuration Control Boards. Auditing of changes includes activities before and after changes are made to organizational information systems and the auditing activities required to implement such changes. Related controls: CM-2, CM-4, CM-5, CM-6, CM-9, SA-10, SI-2, SI-12.\n\nReferences: NIST Special Publication 800-128.\n\nCM-3 Requirement: The service provider establishes a central means of communicating major changes to or developments in the information system or environment of operations that may affect its services to the federal government and associated service consumers (e.g., electronic bulletin board, web status page). The means of communication are approved and accepted by the JAB/AO.\nCM-3 (e) Guidance: In accordance with record retention policies and procedures.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "CM-5", "levels": ["high", "moderate"], "notes": "The customer will be responsible for defining, documenting, approving\nand enforcing physical and logical access restrictions associated with\nchanges to the information system. A successful control response will\ninclude how logical access associated with change control is defined,\ndocumented, and enforced. This should include tools used to enforce\nthese restrictions, such as Active Directory, and how these personnel\nare approved for access.", "title": "CM-5 - ACCESS RESTRICTIONS FOR CHANGE", "description": "The organization defines, documents, approves, and enforces physical and logical access restrictions associated with changes to the information system.\n\nSupplemental Guidance:  Any changes to the hardware, software, and/or firmware components of information systems can potentially have significant effects on the overall security of the systems. Therefore, organizations permit only qualified and authorized individuals to access information systems for purposes of initiating changes, including upgrades and modifications. Organizations maintain records of access to ensure that configuration change control is implemented and to support after-the-fact actions should organizations discover any unauthorized changes. Access restrictions for change also include software libraries. Access restrictions include, for example, physical and logical access controls (see AC-3 and PE-3), workflow automation, media libraries, abstract layers (e.g., changes implemented into third-party interfaces rather than directly into information systems), and change windows (e.g., changes occur only during specified times, making unauthorized changes easy to discover). Related controls: AC-3, AC-6, PE-3.\n\nReferences: None.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "CM-5(5)", "levels": ["high", "moderate"], "notes": "Section a: The customer will be responsible for limiting privileges to change\ninformation system components and system related information within\na production or operational environment. A successful control response\nwill include how privileges to change the production/operation\nenvironment are limited. This can include defining who has access to\nthese privileges, how they may be separated, and any gates they must\ngo through.\nSection b: The customer will be responsible for reviewing and reevaluating\nprivileges at least quarterly. A successful control response will\ninclude how often reviews are performed for personnel with privileges\nto change the information system within the production environment.", "title": "CM-5(5) - ACCESS RESTRICTIONS FOR CHANGE | LIMIT PRODUCTION /\nOPERATIONAL PRIVILEGES", "description": "The organization:\n (a)   Limits privileges to change information system components and system-related information within a production or operational environment; and\n (b)   Reviews and reevaluates privileges [Assignment: organization-defined frequency].\n\nSupplemental Guidance:  In many organizations, information systems support multiple core missions/business functions. Limiting privileges to change information system components with respect to operational systems is necessary because changes to a particular information system component may have far-reaching effects on mission/business processes supported by the system where the component resides. The complex, many-to-many relationships between systems and mission/business processes are in some cases, unknown to developers. Related control: AC-2.\n\nCM-5 (5) (b) [at least quarterly]", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "CM-6", "levels": ["high", "moderate", "low"], "notes": "Section a: The customer will be responsible for establishing and documenting\nconfiguration settings for information technology products employed\nwithin the information system using FedRAMP guidance that reflects\nthe most restrictive mode consistent with operational requirements. A\nsuccessful control response will include how the customer develops\nbase configurations to ensure that they are as restrictive as possible\nwhile still allowing the system to operate.\nSection c: The customer will be responsible for identifying, documenting, and\napproving any deviations from established configuration settings for\ncomponents based on operational requirements. A successful control\nresponse will explain the process for identifying, documenting, and\napproving and deviations. This can include tools used to track any\nexceptions, and the process for identifying and approving these\ndeviations.", "title": "CM-6 - CONFIGURATION SETTINGS", "description": "The organization:\n a. Establishes and documents configuration settings for information technology products employed within the information system using [Assignment: organization-defined security configuration checklists] that reflect the most restrictive mode consistent with operational requirements;\n b. Implements the configuration settings;\n c. Identifies, documents, and approves any deviations from established configuration settings for [Assignment: organization-defined information system components] based on [Assignment: organization-defined operational requirements]; and\n d. Monitors and controls changes to the configuration settings in accordance with organizational policies and procedures.\n\nSupplemental Guidance:  Configuration settings are the set of parameters that can be changed in hardware, software, or firmware components of the information system that affect the security posture and/or functionality of the system. Information technology products for which security- related configuration settings can be defined include, for example, mainframe computers, servers (e.g., database, electronic mail, authentication, web, proxy, file, domain name), workstations, input/output devices (e.g., scanners, copiers, and printers), network components (e.g., firewalls, routers, gateways, voice and data switches, wireless access points, network appliances, sensors), operating systems, middleware, and applications. Security-related parameters are those parameters impacting the security state of information systems including the parameters required to satisfy other security control requirements. Security-related parameters include, for example: (i) registry settings; (ii) account, file, directory permission settings; and (iii) settings for functions, ports, protocols, services, and remote connections. Organizations establish organization-wide configuration settings and subsequently derive specific settings for information systems. The established settings become part of the systems configuration baseline.\n\nCommon secure configurations (also referred to as security configuration checklists, lockdown\nand hardening guides, security reference guides, security technical implementation guides) provide recognized, standardized, and established benchmarks that stipulate secure configuration settings for specific information technology platforms/products and instructions for configuring those information system components to meet operational requirements. Common secure configurations can be developed by a variety of organizations including, for example, information technology product developers, manufacturers, vendors, consortia, academia, industry, federal agencies, and other organizations in the public and private sectors. Common secure configurations include the United States Government Configuration Baseline (USGCB) which affects the implementation of CM-6 and other controls such as AC-19 and CM-7. The Security Content Automation Protocol (SCAP) and the defined standards within the protocol (e.g., Common Configuration Enumeration) provide an effective method to uniquely identify, track, and control configuration settings. OMB establishes federal policy on configuration requirements for federal information systems. Related controls: AC-19, CM-2, CM-3, CM-7, SI-4.\n\nReferences: OMB Memoranda 07-11, 07-18, 08-22; NIST Special Publications 800-70, 800-128; Web: http://nvd.nist.gov, http://checklists.nist.gov, http://www.nsa.gov.\n\nCM-6 (a) [United States Government Configuration Baseline (USGCB)]\nCM-6 (a) Requirement 1: The service provider shall use the Center for Internet Security guidelines (Level 1) to establish configuration settings or establishes its own configuration settings if USGCB is not available.\nCM-6 (a) Requirement 2: The service provider shall ensure that checklists for configuration settings are Security Content Automation Protocol (SCAP) validated or SCAP compatible (if validated checklists are not available).\nCM-6 (a) Guidance: Information on the USGCB checklists can be found at: http://usgcb.nist.gov/usgcb_faq.html#usgcbfaq_usgcbfdcc", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "CM-6(1)", "levels": ["high", "moderate"], "notes": "The customer will be responsible for employing automated mechanisms\nto centrally manage, apply, and verify configuration settings for\ninformation system components. A successful control response will\ndescribe any automated systems in place used to manage, apply, and\nverify configuration settings. An example of this is using Active\nDirectory Group Policy Objects to manage security settings.", "title": "CM-6(1) - CONFIGURATION SETTINGS | AUTOMATED CENTRAL MANAGEMENT / APPLICATION / VERIFICATION", "description": "The organization employs automated mechanisms to centrally manage, apply, and verify configuration settings for [Assignment: organization-defined information system components].\n\nSupplemental Guidance:  Related controls: CA-7, CM-4.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "CM-8", "levels": ["high", "moderate", "low"], "notes": "Section a: The customer will be responsible for developing and documenting an\ninventory that meets FedRAMP requirements. A successful control response\nwill include a description of how the inventory is developed and\ndocumented. This process should ensure that the inventory accurately\nreflects the current system, includes and components, is granular enough\nto support tracking and reporting, and includes any information the\ncustomer has deemed necessary to achieve effective accountability.\nSection b: The customer will responsible for reviewing and updating the system\ninventory at least monthly. This may be performed in conjunction with\ncontinuous monitoring and POA&M tracking activities. A successful control\nresponse will need to address the personnel or roles responsible for\nupdating the system inventory and the process for correcting gaps or\ndiscrepancies found.", "title": "CM-8 - INFORMATION SYSTEM COMPONENT INVENTORY", "description": "The organization:\n a. Develops and documents an inventory of information system components that:\n   1. Accurately reflects the current information system;\n   2. Includes all components within the authorization boundary of the information system;\n   3. Is at the level of granularity deemed necessary for tracking and reporting; and\n   4. Includes [Assignment: organization-defined information deemed necessary to achieve effective information system component accountability]; and\n b. Reviews and updates the information system component inventory [Assignment: organization-defined frequency].\n\nSupplemental Guidance:  Organizations may choose to implement centralized information system component inventories that include components from all organizational information systems. In such situations, organizations ensure that the resulting inventories include system-specific information required for proper component accountability (e.g., information system association, information system owner). Information deemed necessary for effective accountability of information system components includes, for example, hardware inventory specifications, software license information, software version numbers, component owners, and for networked components or devices, machine names and network addresses. Inventory specifications include, for example, manufacturer, device type, model, serial number, and physical location. Related controls: CM-2, CM-6, PM-5.\n\nReferences: NIST Special Publication 800-128.\n\nCM-8 (b) [at least monthly]\nCM-8 Requirement: must be provided at least monthly or when there is a change.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "CM-8(5)", "levels": ["high", "moderate"], "notes": "The customer will be responsible for verifying all components within\nthe authorization boundary of the information system are not duplicated\nin other information system inventories. A successful control response\nwill describe the process used to ensure that assets are not included\nin multiple system inventories.", "title": "CM-8(5) - INFORMATION SYSTEM COMPONENT INVENTORY | NO DUPLICATE ACCOUNTING OF COMPONENTS", "description": "The organization verifies that all components within the authorization boundary of the information system are not duplicated in other information system inventories.\n\nSupplemental Guidance:  This control enhancement addresses the potential problem of duplicate accounting of information system components in large or complex interconnected systems.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "CM-9", "levels": ["high", "moderate"], "notes": "Section a: The customer will be responsible for developing, documenting, and\nimplementing a configuration management plan that addresses roles,\nresponsibilities, and configuration management processes and procedures.\nA successful control response will describe how the configuration\nmanagement plan deals with roles, responsibilities, and processes\nand procedures.\nSection b: The customer will be responsible for developing, documenting, and\nimplementing a configuration management plan that establishes a\nprocess for identifying configuration items throughout the\nsystem development life cycle and for managing the configuration of\nconfiguration items. A successful control response will describe how\nthe configuration management plan establishes a system to track and\nmanage changes to the system.\nSection c: The customer will be responsible for developing, documenting, and\nimplementing a configuration management plan that defines the\nconfiguration items for the information system and places them\nunder configuration management. A successful control response will\ndescribe how the configuration management plan defines configuration\nitems, and the process used to manage them.\nSection d: The customer will be responsible for developing, documenting, and\nimplementing a configuration management plan that protects the\nconfiguration management plan from unauthorized disclosure. A\nsuccessful control response will describe how the configuration\nmanagement plan is protected from disclosure, such as where it is\nstored, and controls in place to prevent unauthorized access.", "title": "CM-9 - CONFIGURATION MANAGEMENT PLAN", "description": "The organization develops, documents, and implements a configuration management plan for the information system that:\n a. Addresses roles, responsibilities, and configuration management processes and procedures;\n b. Establishes a process for identifying configuration items throughout the system development life cycle and for managing the configuration of the configuration items;\n c. Defines the configuration items for the information system and places the configuration items under configuration management; and\n d. Protects the configuration management plan from unauthorized disclosure and modification.\n\nSupplemental Guidance:  Configuration management plans satisfy the requirements in configuration management policies while being tailored to individual information systems. Such plans define detailed processes and procedures for how configuration management is used to support system development life cycle activities at the information system level. Configuration management plans are typically developed during the development/acquisition phase of the system development life cycle. The plans describe how to move changes through change management processes, how to update configuration settings and baselines, how to maintain information system component inventories, how to control development, test, and operational environments, and how to develop, release, and update key documents. Organizations can employ templates to help ensure consistent and timely development and implementation of configuration management plans. Such templates can represent a master configuration management plan for the organization at large with subsets of the plan implemented on a system by system basis. Configuration management approval processes include designation of key management stakeholders responsible for reviewing and approving proposed changes to information systems, and personnel that conduct security impact analyses prior to the implementation of changes to the systems. Configuration items are the information system items (hardware, software, firmware, and documentation) to be configuration-managed. As information systems continue through the system development life cycle, new configuration items may be identified and some existing configuration items may no longer need to be under configuration control. Related controls: CM-2, CM-3, CM-4, CM-5, CM-8, SA-10.\n\nReferences: NIST Special Publication 800-128.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "CM-10", "levels": ["high", "moderate", "low"], "notes": "Section a: The customer will be responsible for using software and associated\ndocumentation in accordance with contract agreements and copyright laws.\nA successful control response will include a description or reference\nto the customers acceptable use policy.\nSection b: The customer will be responsible for tracking the use of software and\nassociated documentation protected by quantity licenses to control\ncopying and distribution. A successful control response will include\na description of how these licenses are tracked and protected.\nSection c: The customer will be responsible for control and documentation of the\nuse of peer-to-peer file sharing technology to ensure that this\ncapability is not used for the unauthorized distribution, display,\nperformance, or reproduction of copyrighted work. A successful control\nresponse will include any controls and documentation for peer-to-peer\ntechnology allowed within the system. An example of this could include\nacceptable use policies in place.", "title": "CM-10 - SOFTWARE USAGE RESTRICTIONS", "description": "The organization:\na. Uses software and associated documentation in accordance with contract agreements and copyright laws;\nb. Tracks the use of software and associated documentation protected by quantity licenses to control copying and distribution; and\nc. Controls and documents the use of peer-to-peer file sharing technology to ensure that this capability is not used for the unauthorized distribution, display, performance, or reproduction of copyrighted work.\n\nSupplemental Guidance:  Software license tracking can be accomplished by manual methods (e.g., simple spreadsheets) or automated methods (e.g., specialized tracking applications) depending on organizational needs. Related controls: AC-17, CM-8, SC-7.\n\nReferences:  None.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "CM-10(1)", "levels": ["high", "moderate"], "notes": "The organization will be responsible for establishing any restrictions on\nthe use of open source software. A successful control response will\ndescribe any restrictions that the organization has in place.", "title": "CM-10(1) - SOFTWARE USAGE RESTRICTIONS | OPEN SOURCE SOFTWARE", "description": "The organization establishes the following restrictions on the use of open source software: [Assignment: organization-defined restrictions].\n\nSupplemental Guidance:  Open source software refers to software that is available in source code form. Certain software rights normally reserved for copyright holders are routinely provided under software license agreements that permit individuals to study, change, and improve the software. From a security perspective, the major advantage of open source software is that it provides organizations with the ability to examine the source code. However, there are also various licensing issues associated with open source software including, for example, the constraints on derivative use of such software.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "CM-11", "levels": ["high", "moderate", "low"], "notes": "Section a: The customer will be responsible for establishing policies governing\nthe installation of software by users. A successful control response\nwill describe policies in place that define the restrictions in place\nfor installation of software by users.", "title": "CM-11 - USER-INSTALLED SOFTWARE", "description": "The organization:\n a. Establishes [Assignment: organization-defined policies] governing the installation of software by users;\n b. Enforces software installation policies through [Assignment: organization-defined methods]; and\n c. Monitors policy compliance at [Assignment: organization-defined frequency].\n\nSupplemental Guidance:  If provided the necessary privileges, users have the ability to install software in organizational information systems. To maintain control over the types of software installed, organizations identify permitted and prohibited actions regarding software installation. Permitted software installations may include, for example, updates and security patches to existing software and downloading applications from organization-approved \u201capp stores.\u201d Prohibited software installations may include, for example, software with unknown or suspect pedigrees or software that organizations consider potentially malicious. The policies organizations select governing user-installed software may be organization-developed or provided by some external entity. Policy enforcement methods include procedural methods (e.g., periodic examination of user accounts), automated methods (e.g., configuration settings implemented on organizational information systems), or both. Related controls: AC-3, CM-2, CM-3, CM-5, CM-6, CM-7, PL-4.\n\nReferences: None.\n\nCM-11 (c) [Continuously (via CM-7 (5))]", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "CP-1", "levels": ["high", "moderate", "low"], "notes": "Section a: The organization will be responsible for developing, documenting, and\ndisseminating Contingency Planning policy and procedures. A\nsuccessful control response will need to address the content of the\npolicy (which must include purpose, scope, roles, responsibilities,\nmanagement commitment, coordination, and compliance) and procedures\n(which must facilitate the implementation of the policies and\nassociated controls).\nSection b: The organization will be responsible for reviewing and updating the\nContingency Planning policy every  years, and procedures annually.\nA successful response will need to address the review and update\nprocess, including the role(s) responsible for initiating the review\nprocess, updating the policy and procedures, and providing approval\nof the updates.", "title": "CP-1 - CONTINGENCY PLANNING POLICY AND\nPROCEDURES", "description": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n   1. A contingency planning 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 contingency planning policy and associated contingency planning controls; and\n b. Reviews and updates the current:\n   1. Contingency planning policy [Assignment: organization-defined frequency]; and\n   2. Contingency planning 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 CP family. Policy and procedures reflect applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance. Security program policies and procedures at the organization level may make the need for system-specific policies and procedures unnecessary. The policy can be included as part of the general information security policy for organizations or conversely, can be represented by multiple policies reflecting the complex nature of certain organizations. The procedures can be established for the security program in general and for particular information systems, if needed. The organizational risk management strategy is a key factor in establishing policy and procedures. Related control: PM-9.\n\nControl Enhancements:  None.\n\nReferences:  Federal Continuity Directive 1; NIST Special Publications 800-12, 800-34, 800-100.\n\nCP-1 (b) (1) [at least annually]\nCP-1 (b) (2) [at least annually or whenever a significant change occurs]", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "CP-2", "levels": ["high", "moderate", "low"], "notes": "Section a: The customer will be responsible for developing a contingency plan\nmeeting the specified requirements. A successful control response will\nneed to address the maintenance, recovery, and resumption of customer\napplications, as well as any reliance on infrastructure functionality\nto perform these tasks, as outlined in policy guidance from CP-1.\nSection b: The customer will be responsible for distributing the contingency plan\nto key contingency personnel. A successful control response will need\nto address identification of key personnel (by name, title, or role)\nand the means by which the customer ensures that all key personnel\nreceive the contingency plan.\nSection c: The customer will be responsible for coordinating contingency planning\nactivities with incident handling activities. A successful control\nresponse will need to address the division of responsibilities between\ncontingency personnel and incident response personnel, as well as the\nmeans by which contingency planning activities are activated in the\nevent of a security incident.\nSection d: The customer will be responsible for reviewing the contingency plan\nat the required frequency. A successful control response will need to\noutline how reviews are initiated, performed, and signed off on.\nSection e: The customer will be responsible for updating the contingency plan to\naddress relevant changes as well as any problems found in the\ncontingency plan. A successful control response will need to discuss\nhow updates are proposed, implemented, and approved.\nSection f: The customer will be responsible for communicating changes to the\ncontingency plan to key contingency personnel. A successful control\nresponse will need to address the means by which the\ncustomer ensures that all key personnel receive the updated\ncontingency plan.\nSection g: The customer will be responsible for protecting the contingency plan\nfrom unauthorized disclosure or modification. A successful control\nresponse will need to address policy, procedural, and technical\nsafeguards that are in place to protect the contingency plan.", "title": "CP-2 - CONTINGENCY PLAN", "description": "The organization:\n a. Develops a contingency plan for the information system that:\n   1. Identifies essential missions and business functions and associated contingency requirements;\n   2. Provides recovery objectives, restoration priorities, and metrics;\n   3. Addresses contingency roles, responsibilities, assigned individuals with contact information;\n   4. Addresses maintaining essential missions and business functions despite an information system disruption, compromise, or failure;\n   5. Addresses eventual, full information system restoration without deterioration of the security safeguards originally planned and implemented; and\n   6. Is reviewed and approved by [Assignment: organization-defined personnel or roles];\n b. Distributes copies of the contingency plan to [Assignment: organization-defined key contingency personnel (identified by name and/or by role) and organizational elements];\n c. Coordinates contingency planning activities with incident handling activities;\n d. Reviews the contingency plan for the information system [Assignment: organization-defined frequency];\n e. Updates the contingency plan to address changes to the organization, information system, or environment of operation and problems encountered during contingency plan implementation, execution, or testing;\n f. Communicates contingency plan changes to [Assignment: organization-defined key contingency personnel (identified by name and/or by role) and organizational elements]; and\n g. Protects the contingency plan from unauthorized disclosure and modification.\n\nSupplemental Guidance:  Contingency planning for information systems is part of an overall organizational program for achieving continuity of operations for mission/business functions. Contingency planning addresses both information system restoration and implementation of alternative mission/business processes when systems are compromised. The effectiveness of contingency planning is maximized by considering such planning throughout the phases of the system development life cycle. Performing contingency planning on hardware, software, and firmware development can be an effective means of achieving information system resiliency. Contingency plans reflect the degree of restoration required for organizational information systems since not all systems may need to fully recover to achieve the level of continuity of operations desired. Information system recovery objectives reflect applicable laws, Executive Orders, directives, policies, standards, regulations, and guidelines. In addition to information system availability, contingency plans also address other security-related events resulting in a reduction in mission and/or business effectiveness, such as malicious attacks compromising the confidentiality or integrity of information systems. Actions addressed in contingency plans include, for example, orderly/graceful degradation, information system shutdown, fallback to a manual mode, alternate information flows, and operating in modes reserved for when systems are under attack. By closely coordinating contingency planning with incident handling activities, organizations can ensure that the necessary contingency planning activities are in place and activated in the event of a security incident. Related controls: AC-14, CP-6, CP-7, CP-8, CP-9, CP-10, IR-4, IR-8, MP-2, MP-4, MP-5, PM-8, PM-11.\n\nReferences: Federal Continuity Directive 1; NIST Special Publication 800-34.\n\nCP-2 (d) [at least annually]\nCP-2 Requirement: For JAB authorizations the contingency lists include designated FedRAMP personnel.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "CP-2(1)", "levels": ["high", "moderate"], "notes": "The customer will be responsible for coordinating development of the\ncontingency plan with related plans (such as business continuity plans,\ndisaster recovery plans, etc.). A successful control response will need\nto address the coordination of initial development, as well as how\nupdates to the contingency plan affect related plans and vice versa.", "title": "CP-2(1) - CONTINGENCY PLAN | COORDINATE WITH RELATED PLANS", "description": "The organization coordinates contingency plan development with organizational elements responsible for related plans.\n\nSupplemental Guidance:  Plans related to contingency plans for organizational information systems include, for example, Business Continuity Plans, Disaster Recovery Plans, Continuity of Operations Plans, Crisis Communications Plans, Critical Infrastructure Plans, Cyber Incident Response Plans, Insider Threat Implementation Plan, and Occupant Emergency Plans.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "CP-2(2)", "levels": ["high", "moderate"], "notes": "The customer will be responsible for reserving capacity for processing\nin an alternative region. A successful control response will need to\nnote that capacity for necessary processing has been reserved in an\nalternate region.", "title": "CP-2(2) - CONTINGENCY PLAN | CAPACITY PLANNING", "description": "The organization conducts capacity planning so that necessary capacity for information processing, telecommunications, and environmental support exists during contingency operations.\n\nSupplemental Guidance:  Capacity planning is needed because different types of threats (e.g., natural disasters, targeted cyber attacks) can result in a reduction of the available processing, telecommunications, and support services originally intended to support the organizational missions/business functions. Organizations may need to anticipate degraded operations during contingency operations and factor such degradation into capacity planning.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "CP-2(3)", "levels": ["high", "moderate"], "notes": "This control is often inherited through your platform provider,\ne.g. Microsoft Azure implements this control on behalf of both PaaS\nand IaaS customers. A successful control response will indicate if this\ncontrol is inherited through your platform provider, and if not,\ndetails how mission functions will be resumed.", "title": "CP-2(3) - CONTINGENCY PLAN | RESUME ESSENTIAL MISSIONS / BUSINESS FUNCTIONS", "description": "The organization plans for the resumption of essential missions and business functions within\n[Assignment: organization-defined time period] of contingency plan activation.\n\nSupplemental Guidance:  Organizations may choose to carry out the contingency planning activities in this control enhancement as part of organizational business continuity planning including, for example, as part of business impact analyses. The time period for resumption of essential missions/business functions may be dependent on the severity/extent of disruptions\nto the information system and its supporting infrastructure. Related control: PE-12.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "CP-2(8)", "levels": ["high", "moderate"], "notes": "The customer will be responsible for identifying critical\nfunctionality for which processing capacity must be reserved in an\nalternate region. A successful control response will need to discuss\nthe process by which this determination is made. Once processing\ncapacity is reserved in an alternate region for this critical\nfunctionality, the remainder of the control may be inherited\nfrom your infrastructure provider.", "title": "CP-2(8) - CONTINGENCY PLAN | IDENTIFY CRITICAL ASSETS", "description": "The organization identifies critical information system assets supporting essential missions and business functions.\n\nSupplemental Guidance:  Organizations may choose to carry out the contingency planning activities in this control enhancement as part of organizational business continuity planning including, for example, as part of business impact analyses. Organizations identify critical information system assets so that additional safeguards and countermeasures can be employed (above and beyond those safeguards and countermeasures routinely implemented) to help ensure that organizational missions/business functions can continue to be conducted during contingency operations. In addition, the identification of critical information assets facilitates the prioritization of organizational resources. Critical information system assets include technical and operational aspects. Technical aspects include, for example, information technology services, information system components, information technology products, and mechanisms. Operational aspects include, for example, procedures (manually executed operations) and personnel (individuals operating technical safeguards and/or executing manual procedures). Organizational program protection plans can provide assistance in identifying critical assets. Related controls: SA-14, SA-15.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "CP-3", "levels": ["high", "moderate", "low"], "notes": "The customer will be responsible for initial and refresher training\nrelated to contingency plan activities at the required intervals. A\nsuccessful control response will need to outline the scope and contents\nof the training, the audience for the training, and the means by which\ntraining attendance is tracked and enforced.", "title": "CP-3 - CONTINGENCY TRAINING", "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]", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "CP-4", "levels": ["high", "moderate", "low"], "notes": "Section a: The customer will be responsible for testing of contingency plans\nrelated to the customer application at the required frequency. A\nsuccessful control response will need to address the scenarios and\nexercises chosen for the test.\nSection b: The customer will be responsible for reviewing the results of\ncontingency plan testing. A successful control response will need to\ndiscuss the roles or personnel responsible for review, as well as the\nformat and content of reporting on the results.\nSection c: The customer will be responsible for initiating corrective action as\na result of contingency plan testing. A successful control response will\nneed to address the types of corrective actions taken and timeframes\nfor those actions.", "title": "CP-4 - CONTINGENCY PLAN 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.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "CP-4(1)", "levels": ["high", "moderate"], "notes": "The customer will be responsible for coordinating testing of the\ncontingency plan with related plans (such as business continuity plans,\ndisaster recovery plans, etc.). A successful control response will need\nto address ensuring that any test results relevant to related plans are\ncommunicated so that corrective actions may be taken as needed.", "title": "CP-4(1) - CONTINGENCY PLAN TESTING | COORDINATE WITH RELATED PLANS", "description": "The organization coordinates contingency plan testing with organizational elements responsible for related plans.\n\nSupplemental Guidance:  Plans related to contingency plans for organizational information systems include, for example, Business Continuity Plans, Disaster Recovery Plans, Continuity of Operations Plans, Crisis Communications Plans, Critical Infrastructure Plans, Cyber Incident Response Plans, and Occupant Emergency Plans. This control enhancement does not require organizations to create organizational elements to handle related plans or to align such elements with specific plans. It does require, however, that if such organizational elements are responsible for related plans, organizations should coordinate with those elements. Related controls: IR-8, PM-8.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "CP-6", "levels": ["high", "moderate"], "notes": "Section a: The customer will be responsible for enabling geo-replicated within\nthe information system which will allow restoration from backups.\nSection b: The customer will be responsible to ensure alternate storage sites\nprovide information security safeguards equivalent to the primary\nsite.", "title": "CP-6 - ALTERNATE STORAGE SITE", "description": "The organization:\n a. Establishes an alternate storage site including necessary agreements to permit the storage and retrieval of information system backup information; and\n b. Ensures that the alternate storage site provides information security safeguards equivalent to that of the primary site.\n\nSupplemental Guidance:  Alternate storage sites are sites that are geographically distinct from primary storage sites. An alternate storage site maintains duplicate copies of information and data in the event that the primary storage site is not available. Items covered by alternate storage site agreements include, for example, environmental conditions at alternate sites, access rules, physical and environmental protection requirements, and coordination of delivery/retrieval of backup\nmedia. Alternate storage sites reflect the requirements in contingency plans so that organizations can maintain essential missions/business functions despite disruption, compromise, or failure in organizational information systems. Related controls: CP-2, CP-7, CP-9, CP-10, MP-4.\n\nReferences: NIST Special Publication 800-34.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "CP-6(1)", "levels": ["high", "moderate"], "notes": "The customer will be responsible for identifying an alternative\nstorage site that is separated from the primary storage site to reduce\nsusceptibility to the same threats.", "title": "CP-6(1) - ALTERNATE STORAGE SITE | SEPARATION FROM PRIMARY SITE", "description": "The organization identifies an alternate storage site that is separated from the primary storage site to reduce susceptibility to the same threats.\n\nSupplemental Guidance:  Threats that affect alternate storage sites are typically defined in organizational assessments of risk and include, for example, natural disasters, structural failures, hostile cyber attacks, and errors of omission/commission. Organizations determine what is considered a sufficient degree of separation between primary and alternate storage sites based on the types of threats that are of concern. For one particular type of threat (i.e., hostile cyber attack), the degree of separation between sites is less relevant. Related control: RA-3.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "CP-6(3)", "levels": ["high", "moderate"], "notes": "The customer will be responsible for identifying potential\naccessibility problems to the alternate storage site in the event of\nan area-wide disruption or disaster and outlines explicit\nmitigation actions. This control is often inherited from IaaS and PaaS\nproviders.", "title": "CP-6(3) - ALTERNATE STORAGE SITE | ACCESSIBILITY", "description": "The organization identifies potential accessibility problems to the alternate storage site in the event of an area-wide disruption or disaster and outlines explicit mitigation actions.\n\nSupplemental Guidance:  Area-wide disruptions refer to those types of disruptions that are broad in geographic scope (e.g., hurricane, regional power outage) with such determinations made by organizations based on organizational assessments of risk. Explicit mitigation actions include, for example: (i) duplicating backup information at other alternate storage sites if access problems occur at originally designated alternate sites; or (ii) planning for physical access to retrieve backup information if electronic accessibility to the alternate site is disrupted. Related control: RA-3.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "CP-7", "levels": ["high", "moderate"], "notes": "Section a: The customer will be responsible for reserving capacity for processing\nin an alternate region. A successful control response will need to note\nthat capacity for necessary processing has been reserved in an alternate\nregion, and will then indicate inheritance of capacity planning from\nmost IaaS providers.\nSection b: The customer will be responsible for ensuring that equipment and\nsupplies required to transfer and resume operations are available\nat the alternate processing site. This control is often inherited\nfrom organizational processes.\nSection c: The customer will be responsible for ensuring that the alternate\nprocessing site provides information security safeguards equivalent\nto that of the primary site.", "title": "CP-7 - ALTERNATE PROCESSING SITE", "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.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "CP-7(1)", "levels": ["high", "moderate"], "notes": "The customer is responsible for identifying an alternate processing\nsite that is separated from the primary processing site to reduce\nsusceptibility to the same threats. Per FedRAMP guidance, the service\nprovider may determine what is considered a sufficient degree of\nseparation between the primary and alternate processing sites, based\non the types of threats that are of concern. This control is often\ninherited from organizational processes.", "title": "CP-7(1) - ALTERNATE PROCESSING SITE | SEPARATION FROM PRIMARY SITE", "description": "The organization identifies an alternate processing site that is separated from the primary processing site to reduce susceptibility to the same threats.\n\nSupplemental Guidance:  Threats that affect alternate processing sites are typically defined in organizational assessments of risk and include, for example, natural disasters, structural failures, hostile cyber attacks, and errors of omission/commission. Organizations determine what is considered a sufficient degree of separation between primary and alternate processing sites based on the types of threats that are of concern. For one particular type of threat (i.e., hostile cyber attack), the degree of separation between sites is less relevant. Related control: RA-3.\n\nCP-7 (1) Guidance: The service provider may determine what is considered a sufficient degree of separation between the primary and alternate processing sites, based on the types of threats that are of concern. For one particular type of threat (i.e., hostile cyber attack), the degree of separation between sites will be less relevant.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "CP-7(2)", "levels": ["high", "moderate"], "notes": "The customer will be responsible for identifying potential\naccessibility problems to the alternate processing site in the event of\nan area-wide disruption or disaster and outlines explicit mitigation\nactions. This control is often inherited from organizational\nprocesses.", "title": "CP-7(2) - ALTERNATE PROCESSING SITE | ACCESSIBILITY", "description": "The organization identifies potential accessibility problems to the alternate processing site in the event of an area-wide disruption or disaster and outlines explicit mitigation actions.\n\nSupplemental Guidance:  Area-wide disruptions refer to those types of disruptions that are broad in geographic scope (e.g., hurricane, regional power outage) with such determinations made by organizations based on organizational assessments of risk. Related control: RA-3.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "CP-7(3)", "levels": ["high", "moderate"], "notes": "The customer will be responsible for developing alternate processing\nsite agreements that contain priority-of-service provisions in\naccordance with organizational availability requirements. This control\nis often inherited from organizational, IaaS, or PaaS providers.", "title": "CP-7(3) - ALTERNATE PROCESSING SITE | PRIORITY OF SERVICE", "description": "The organization develops alternate processing site agreements that contain priority-of-service provisions in accordance with organizational availability requirements (including recovery time objectives).\n\nSupplemental Guidance:  Priority-of-service agreements refer to negotiated agreements with service providers that ensure that organizations receive priority treatment consistent with their availability requirements and the availability of information resources at the alternate processing site.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "CP-8", "levels": ["high", "moderate"], "notes": "The customer will be responsible for establishing alternate\ntelecommunication services including necessary agreements to permit\nthe resumption of operations. The customer must define a time period\nto resume business operations that is consistent with the business\nimpact analysis. This control is often inherited from organizational,\nIaaS, or PaaS providers.", "title": "CP-8 - TELECOMMUNICATIONS SERVICES", "description": "The organization establishes alternate telecommunications services including necessary agreements to permit the resumption of [Assignment: organization-defined information system operations] for essential missions and business functions within [Assignment: organization- defined time period] when the primary telecommunications capabilities are unavailable at either the primary or alternate processing or storage sites.\n\nSupplemental Guidance:  This control applies to telecommunications services (data and voice) for primary and alternate processing and storage sites. Alternate telecommunications services reflect the continuity requirements in contingency plans to maintain essential missions/business functions despite the loss of primary telecommunications services. Organizations may specify different time periods for primary/alternate sites. Alternate telecommunications services include, for example, additional organizational or commercial ground-based circuits/lines or satellites in lieu of ground- based communications. Organizations consider factors such as availability, quality of service, and access when entering into alternate telecommunications agreements. Related controls: CP-2, CP-6, CP-7.\n\nReferences: NIST Special Publication 800-34; National Communications Systems Directive 3-10; Web: http://www.dhs.gov/telecommunications-service-priority-tsp.\n\nCP-8 Requirement: The service provider defines a time period consistent with the recovery time objectives and business impact analysis.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "CP-8(1)", "levels": ["high", "moderate"], "notes": "Section a: The customer will be responsible for developing primary and\nalternate telecommunication service agreements that contain\npriority-of-service provisions in accordance with organizational\navailability requirements (including recovery time objectives). This\ncontrol is often inherited from IaaS and PaaS providers.\nSection b: The customer will be responsible to request telecommunications\nservice priority for all telecommunications services used for national\nsecurity emergency preparedness in the event that the primary and/or\nalternate telecommunications services are provided by a common carrier.\nThis control is often inherited from IaaS and PaaS providers.", "title": "CP-8(1) - TELECOMMUNICATIONS SERVICES | PRIORITY OF SERVICE PROVISIONS", "description": "The organization:\n (a)   Develops primary and alternate telecommunications service agreements that contain priority- of-service provisions in accordance with organizational availability requirements (including recovery time objectives); and\n (b)   Requests Telecommunications Service Priority for all telecommunications services used for national security emergency preparedness in the event that the primary and/or alternate telecommunications services are provided by a common carrier.\n\nSupplemental Guidance:  Organizations consider the potential mission/business impact in situations where telecommunications service providers are servicing other organizations with similar priority-of-service provisions.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "CP-8(2)", "levels": ["high", "moderate"], "notes": "The customer will be responsible for obtaining alternate\ntelecommunications services to reduce the likelihood of sharing a\nsingle point of failure with primary telecommunications services. This\ncontrol is often inherited from IaaS and PaaS providers.", "title": "CP-8(2) - TELECOMMUNICATIONS SERVICES | SINGLE POINTS OF FAILURE", "description": "The organization obtains alternate telecommunications services to reduce the likelihood of sharing a single point of failure with primary telecommunications services.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "CP-10", "levels": ["high", "moderate", "low"], "notes": "The customer will be responsible for providing recovery and\nreconstitution of the information system to a known state after a\ndisruption, compromise, or failure.", "title": "CP-10 - INFORMATION SYSTEM RECOVERY AND\nRECONSTITUTION", "description": "The organization provides for the recovery and reconstitution of the information system to a known state after a disruption, compromise, or failure.\n\nSupplemental Guidance:  Recovery is executing information system contingency plan activities to restore organizational missions/business functions. Reconstitution takes place following recovery and includes activities for returning organizational information systems to fully operational states. Recovery and reconstitution operations reflect mission and business priorities, recovery point/time and reconstitution objectives, and established organizational metrics consistent with contingency plan requirements. Reconstitution includes the deactivation of any interim information system capabilities that may have been needed during recovery operations. Reconstitution also includes assessments of fully restored information system capabilities, reestablishment of continuous monitoring activities, potential information system reauthorizations, and activities to prepare the systems against future disruptions, compromises, or failures. Recovery/reconstitution capabilities employed by organizations can include both automated mechanisms and manual procedures. Related controls: CA-2, CA-6, CA-7, CP-2, CP-6, CP-7, CP-9, SC-24.\n\nReferences: Federal Continuity Directive 1; NIST Special Publication 800-34.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "IA-1", "levels": ["high", "moderate", "low"], "notes": "Section a: The organization will be responsible for developing, documenting, and\ndisseminating Identification and Authentication policy and procedures.\nA successful control response will need to address the content of the\npolicy (which must include purpose, scope, roles, responsibilities,\nmanagement commitment, coordination, and compliance) and procedures\n(which must facilitate the implementation of the policies and\nassociated controls).\nSection b: The organization will be responsible for reviewing and updating the\nIdentification and Authentication policy every 3 years, and procedures\nannually. A successful control response will need to address the\nreview and update process, including the role(s) responsible for\ninitiating the review process, updating the policy and procedures,\nand providing approval of the updates.", "title": "IA-1 - IDENTIFICATION AND AUTHENTICATION POLICY AND\nPROCEDURES", "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]", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "IR-2", "levels": ["high", "moderate", "low"], "notes": "Section a: The customer will be responsible for initial training related to\ncontingency plan activities. This training will need to include\nconsideration for all aspects of incident response that are the\nresponsibility of the customer. A successful control response will need\nto outline the scope and contents of the training, the audience for the\ntraining, and the means by which training attendance is tracked and\nenforced.\nSection b: The customer will be responsible for providing retraining related to\ncontingency plan activities as required by information system changes. A\nsuccessful control response will need to address identification of\nchanges that require retraining as well as notification to relevant\nparties that retraining is required and tracking/enforcement of that\nattendance.\nSection c: The customer will be responsible for refresher training related to\ncontingency plan activities at the required frequency. A successful\ncontrol response will need to address the means by which refresher\ntraining attendance is tracked and enforced.", "title": "IR-2 - INCIDENT RESPONSE TRAINING", "description": "The organization provides incident response training to information system users consistent with assigned roles and responsibilities:\n a. Within [Assignment: organization-defined time period] of assuming an incident response role or responsibility;\n b. When required by information system changes; and\n c. [Assignment: organization-defined frequency] thereafter.\n\nSupplemental Guidance:  Incident response training provided by organizations is linked to the assigned roles and responsibilities of organizational personnel to ensure the appropriate content and level of detail is included in such training. For example, regular users may only need to know who to call or how to recognize an incident on the information system; system administrators may require additional training on how to handle/remediate incidents; and incident responders may receive more specific training on forensics, reporting, system recovery, and restoration. Incident response training includes user training in the identification and reporting of suspicious activities, both from external and internal sources. Related controls: AT-3, CP-3, IR-8.\n\nReferences: NIST Special Publications 800-16, 800-50.\n\nIR-2 (a) [within ten (10) days]\nIR-2 (c) [at least annually]", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "IR-3", "levels": ["high", "moderate"], "notes": "The customer will be responsible for testing of incident response\nplans at the required frequency. A successful control response will\nneed to address the scenarios and exercise chosen for the test, as well\nas the process for documenting and reviewing test results. Test plans\nwill need to be approved by the Authorizing Official prior to the test\ncommencing.\n\nNIST Special Publication 800-61, Rev 2, Computer Security Incident\nHandling Guide, provides guidance on the development and testing\nof incident response plans.", "title": "IR-3 - INCIDENT RESPONSE TESTING", "description": "The organization tests the incident response capability for the information system [Assignment: organization-defined frequency] using [Assignment: organization-defined tests] to determine the incident response effectiveness and documents the results.\n\nSupplemental Guidance:  Organizations test incident response capabilities to determine the overall effectiveness of the capabilities and to identify potential weaknesses or deficiencies. Incident response testing includes, for example, the use of checklists, walk-through or tabletop exercises, simulations (parallel/full interrupt), and comprehensive exercises. Incident response testing can also include a determination of the effects on organizational operations (e.g., reduction in mission capabilities), organizational assets, and individuals due to incident response. Related controls: CP-4, IR-8.\n\nReferences:  NIST Special Publications 800-84, 800-115.\n\nIR-3-1 [at least every six (6) months, including functional at least annually]\nIR-3-2 Requirement: The service provider defines tests and/or exercises in accordance with NIST Special Publication 800-61 (as amended). Functional Testing must occur prior to testing for initial authorization. Annual functional testing may be concurrent with required penetration tests (see CA-8). The service provider provides test plans to the JAB/AO annually. Test plans are approved and accepted by the JAB/AO prior to test commencing.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "IR-3(2)", "levels": ["high", "moderate"], "notes": "The customer will be responsible for coordinating testing of the\nincident response plan with related plans (such as business continuity\nplans, contingency plans, etc.). A successful control response will\nneed to address ensuring that any test results relevant to related\nplans are communicated so that corrective actions may be taken as\nneeded.", "title": "IR-3(2) - INCIDENT RESPONSE TESTING | COORDINATION WITH RELATED PLANS", "description": "The organization coordinates incident response testing with organizational elements responsible for related plans.\n\nSupplemental Guidance:  Organizational plans related to incident response testing include, for example, Business Continuity Plans, Contingency Plans, Disaster Recovery Plans, Continuity of Operations Plans, Crisis Communications Plans, Critical Infrastructure Plans, and\nOccupant Emergency Plans.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "IR-4", "levels": ["high", "moderate", "low"], "notes": "Section a: The customer will be responsible for developing incident response\nplans and testing that includes consideration for any controls that are\nthe responsibility of the customer relating to shared touch points\nincluded in the customers authorization boundary and any customer\napplications leveraging the providers infrastructure. Incident handling\nfor customer applications is the responsibility of the customer unless\nan incident is caused by platform providers (e.g. IaaS). A successful\ncontrol response will need to address the required steps in incident\nresponse (preparation, detection and analysis, containment, eradication,\nand recovery), including identifying roles or individuals responsible\nfor each step.\nSection b: The customer will be responsible for incident handling activities\nwith contingency plan activities. A successful control response will\nneed to address communication and prioritization in the case of\nconflicts (for example, if incident analysis and containment causes\ndelays in service restoration).\nSection c: The customer will be responsible for updating incident response plans,\nprocedures, training and testing based on lessons learned from incident\nhandling activities. A successful control response will need to address\nthe personnel or roles responsible for gathering and reviewing lessons\nlearned, updating plans, procedures, training, and testing, and\nreviewing and signing off on changes.", "title": "IR-4 - INCIDENT HANDLING", "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.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "IR-4(1)", "levels": ["high", "moderate"], "notes": "The customer will be responsible for using automated mechanisms\n(such as ticketing systems and incident tracking/reporting systems) in\nsupport of customer incident handling activities. A successful control\nresponse will need to address the automated systems involved and their\nplace within the overall incident handling process.", "title": "IR-4(1) - INCIDENT HANDLING | AUTOMATED INCIDENT HANDLING PROCESSES", "description": "The organization employs automated mechanisms to support the incident handling process.\n\nSupplemental Guidance:  Automated mechanisms supporting incident handling processes include, for example, online incident management systems.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "IR-5", "levels": ["high", "moderate", "low"], "notes": "The customer will be responsible for tracking and documenting\ninformation system security incidents. A successful control response\nwill need to address the tools and processes used for documentation,\nand relate these tools and processes to the automated mechanisms\nused in IR-4(1).", "title": "IR-5 - INCIDENT MONITORING", "description": "The organization tracks and documents information system security incidents.\n\nSupplemental Guidance:  Documenting information system security incidents includes, for example, maintaining records about each incident, the status of the incident, and other pertinent information necessary for forensics, evaluating incident details, trends, and handling. Incident information can be obtained from  a variety of sources including, for example, incident reports, incident response teams, audit monitoring, network monitoring, physical access monitoring, and user/administrator reports. Related controls: AU-6, IR-8, PE-6, SC-5, SC-7, SI-3, SI-4, SI-7.\n\nReferences: NIST Special Publication 800-61.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "IR-6", "levels": ["high", "moderate", "low"], "notes": "Section a: The customer will be responsible for requiring personnel to report\nsuspected security incidents within the required timeframes. A\nsuccessful control response will need to address examples of events that\npersonnel should report, as well as tools, mechanisms, and processes\nused for reporting.\nSection b: The customer will be responsible for reporting security incident\ninformation according to the FedRAMP Incident Communications Procedure.\nIn cases where customer security incidents may affect the security\nstatus of Microsoft Azure as a whole, the customer will be responsible\nfor notifying Microsoft Azure as well. A successful control response\nwill need to address the individuals or roles responsible for such\nnotifications.", "title": "IR-6 - INCIDENT REPORTING", "description": "The organization:\n a. Requires personnel to report suspected security incidents to the organizational incident response capability within [Assignment: organization-defined time period]; and\n b. Reports security incident information to [Assignment: organization-defined authorities].\n\nSupplemental Guidance:  The intent of this control is to address both specific incident reporting requirements within an organization and the formal incident reporting requirements for federal agencies and their subordinate organizations. Suspected security incidents include, for example, the receipt of suspicious email communications that can potentially contain malicious code. The types of security incidents reported, the content and timeliness of the reports, and the designated reporting authorities reflect applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance. Current federal policy requires that all federal agencies (unless specifically exempted from such requirements) report security incidents to the United States Computer Emergency Readiness Team (US-CERT) within specified time frames designated in the US-CERT Concept of Operations for Federal Cyber Security Incident Handling. Related controls: IR-4, IR-5, IR-8.\n\nReferences: NIST Special Publication 800-61; Web: http://www.us-cert.gov.\n\nIR-6 (a) [US-CERT incident reporting timelines as specified in NIST Special Publication 800-61 (as amended)]\nIR-6 Requirement: Reports security incident information according to FedRAMP Incident Communications Procedure.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "IR-6(1)", "levels": ["high", "moderate"], "notes": "The customer will be responsible for using automated mechanisms (such\nas ticketing systems and incident tracking/reporting systems) in support\nof the reporting of security incidents. A successful control response\nwill need to address the automated systems involved and how they are\nused for reporting of incidents.", "title": "IR-6(1) - INCIDENT REPORTING | AUTOMATED REPORTING", "description": "The organization employs automated mechanisms to assist in the reporting of security incidents.\n\nSupplemental Guidance:  Related control: IR-7.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "IR-7", "levels": ["high", "moderate", "low"], "notes": "The customer will be responsible for providing incident response\nresources to their users. These resources may be, for example, web\npages, helpdesk resources, or assistance groups. A successful\ncontrol response will need to outline the resources available and\ndiscuss how users are notified of the existence of these resources.", "title": "IR-7 - INCIDENT RESPONSE ASSISTANCE", "description": "The organization provides an incident response support resource, integral to the organizational incident response capability that offers advice and assistance to users of the information system for the handling and reporting of security incidents.\n\nSupplemental Guidance:  Incident response support resources provided by organizations include, for example, help desks, assistance groups, and access to forensics services, when required. Related controls: AT-2, IR-4, IR-6, IR-8, SA-9.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "IR-7(1)", "levels": ["high", "moderate"], "notes": "The customer will be responsible for using automated mechanisms\n(such as websites or email distribution lists) to increase the\navailability of incident response support resources. A successful\ncontrol response will need to discuss the mechanisms used and the\ninformation and support resources provided via each mechanism.", "title": "IR-7(1) - INCIDENT RESPONSE ASSISTANCE | AUTOMATION SUPPORT FOR AVAILABILITY OF INFORMATION / SUPPORT", "description": "The organization employs automated mechanisms to increase the availability of incident response- related information and support.\n\nSupplemental Guidance:  Automated mechanisms can provide a push and/or pull capability for users to obtain incident response assistance. For example, individuals might have access to a website to query the assistance capability, or conversely, the assistance capability may have the ability to proactively send information to users (general distribution or targeted) as part of increasing understanding of current response capabilities and support.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "IR-7(2)", "levels": ["high", "moderate"], "notes": "Section a: The customer will be responsible for establishing relationships\nbetween its incident response capability and external providers. In\nparticular, it is the customers responsibility to provide accurate\nand current contact information to IaaS providers in order to receive\nnotifications of security incidents involving the potential breach\nof customer data. Additionally, the customer is responsible to designate\nUS-CERT as a notification contact. A successful control response will\nneed to address these requirements as well as relationships with any\nother relevant external providers of information system protection\ncapability.\nSection b: The customer will be responsible for identifying incident response\nteam members to IaaS providers and any other external providers. A\nsuccessful control response will need to discuss the means by which\nthis identification is communicated.", "title": "IR-7(2) - INCIDENT RESPONSE ASSISTANCE | COORDINATION WITH EXTERNAL PROVIDERS", "description": "The organization:\n (a)   Establishes a direct, cooperative relationship between its incident response capability and external providers of information system protection capability; and\n (b)   Identifies organizational incident response team members to the external providers.\n\nSupplemental Guidance:  External providers of information system protection capability include, for example, the Computer Network Defense program within the U.S. Department of Defense. External providers help to protect, monitor, analyze, detect, and respond to unauthorized activity within organizational information systems and networks.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "IR-8", "levels": ["high", "moderate", "low"], "notes": "Section a: The customer will be responsible for developing an incident response\nplan that includes consideration for any controls that are the\nresponsibility of the customer relating to shared touch points included\nin the customers authorization boundary and any customer applications\nleveraging the providers infrastructure. A successful control response\nwill need to address how the plan meets each of the specified\nrequirements, and the individuals or roles responsible for ensuring that\nthe requirements are met.\nSection b: The customer will be responsible for distributing the incident\nresponse plan to identified internal and FedRAMP personnel. A successful\ncontrol response will need to address the criteria for inclusion in the\ndistribution list.\nSection c: The customer will be responsible for reviewing the incident response\nplan at the required frequency. A successful control response will need\nto address how the review process is initiated and the roles or\nindividuals responsible for performing the review.\nSection d: The customer will be responsible for updating the incident response\nplan as appropriate. A successful control response will need to address\nthe criteria for requiring an update to the incident response plan, the\nindividuals or roles responsible for updating the plan, and the process\nfor approval of updates.\nSection e: The customer will be responsible for communicating changes made to the\nincident response plan to the list of internal and FedRAMP personnel\nidentified in IR-8(b).\nSection f: The customer will be responsible for protecting the incident response\nplan from unauthorized disclosure or modification. A successful control\nresponse will need to address policy, procedural, and technical\nsafeguards that are in place to protect the incident response plan.", "title": "IR-8 - INCIDENT RESPONSE PLAN", "description": "The organization:\n a. Develops an incident response plan that:\n   1. Provides the organization with a roadmap for implementing its incident response capability;\n   2. Describes the structure and organization of the incident response capability;\n   3. Provides a high-level approach for how the incident response capability fits into the overall organization;\n   4. Meets the unique requirements of the organization, which relate to mission, size, structure, and functions;\n   5. Defines reportable incidents;\n   6. Provides metrics for measuring the incident response capability within the organization;\n   7. Defines the resources and management support needed to effectively maintain and mature an incident response capability; and\n   8. Is reviewed and approved by [Assignment: organization-defined personnel or roles];\n b. Distributes copies of the incident response plan to [Assignment: organization-defined incident response personnel (identified by name and/or by role) and organizational elements];\n c. Reviews the incident response plan [Assignment: organization-defined frequency];\n d. Updates the incident response plan to address system/organizational changes or problems encountered during plan implementation, execution, or testing;\n  e. Communicates incident response plan changes to [Assignment: organization-defined incident response personnel (identified by name and/or by role) and organizational elements]; and\nf. Protects the incident response plan from unauthorized disclosure and modification.\n\nSupplemental Guidance:  It is important that organizations develop and implement a coordinated approach to incident response. Organizational missions, business functions, strategies, goals, and objectives for incident response help to determine the structure of incident response capabilities. As part of a comprehensive incident response capability, organizations consider the coordination and sharing of information with external organizations, including, for example, external service providers and organizations involved in the supply chain for organizational information systems. Related controls: MP-2, MP-4, MP-5.\n\nControl Enhancements:  None.\n\nReferences:  NIST Special Publication 800-61.\n\nIR-8 (b) [see additional FedRAMP Requirements and Guidance]\nIR-8 (c) [at least annually]\nIR-8 (e) [see additional FedRAMP Requirements and Guidance]\nIR-8 (b) Requirement: The service provider defines a list of incident response personnel (identified by name and/or by role) and organizational elements. The incident response list includes designated FedRAMP personnel.\nIR-8 (e) Requirement: The service provider defines a list of incident response personnel (identified by name and/or by role) and organizational elements. The incident response list includes designated FedRAMP personnel.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "IR-9", "levels": ["high", "moderate"], "notes": "Section a: The customer will be responsible for identifying the specific\ninformation involved in an information spill. A successful control\nresponse will need to address how spills are detected and the tools\nor processes used to identify the specific information involved.\nSection b: The customer will be responsible for alerting designated personnel\nusing a non-contaminated method of communication. A successful control\nresponse will need to discuss how the personnel are designated and\nnotified.\nSection c: The customer will be responsible for isolating the contaminated\nsystem or component. This may involved, for example, disabling\nconnections to the component or shutting it down. A successful\ncontrol response will need to address the types of components that\ncould potentially be contaminated and the mechanism for isolating\neach type.\nSection d: The customer will be responsible for eradicating the spilled\ninformation from the contaminated system or component. A successful\ncontrol response will need to address the means by which\neradication is carried out and confirmed.\nSection e: The customer will be responsible for identifying other systems or\ncomponents that may have been contaminated subsequent to the initial\nspill. A successful control response will need to outline the\ninvestigative process used to make this determination.\nSection f: The customer will be responsible for identifying and performing any\nadditional required actions to resolve information spills. A\nsuccessful control response will need to address how those actions\nare identified and the roles or individuals responsible for\nidentifying and performing the actions.", "title": "IR-9 - INFORMATION SPILLAGE RESPONSE", "description": "The organization responds to information spills by:\n a. Identifying the specific information involved in the information system contamination;\n b. Alerting [Assignment: organization-defined personnel or roles] of the information spill using a method of communication not associated with the spill;\n c. Isolating the contaminated information system or system component;\n d. Eradicating the information from the contaminated information system or component;\n e. Identifying other information systems or system components that may have been subsequently contaminated; and\n f. Performing other [Assignment: organization-defined actions].\nSupplemental Guidance: Information spillage refers to instances where either classified or sensitive information is inadvertently placed on information systems that are not authorized to process such information. Such information spills often occur when information that is initially thought to be of lower sensitivity is transmitted to an information system and then is subsequently determined to be of higher sensitivity. At that point, corrective action is required. The nature of the organizational response is generally based upon the degree of sensitivity of the spilled information (e.g., security category or classification level), the security capabilities of the information system, the specific nature of contaminated storage media, and the access authorizations (e.g., security clearances) of individuals with authorized access to the contaminated system. The methods used to communicate information about the spill after the fact do not involve methods directly associated with the actual spill to minimize the risk of further spreading the contamination before such contamination is isolated and eradicated.\n\nReferences: None.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "IR-9(1)", "levels": ["high", "moderate"], "notes": "The customer will be responsible for identifying personnel or roles\nwith responsibility for responding to information spills. This may be\nall members of the incident response team, specific members with\nspecialized knowledge, or individuals or teams completely distinct from\nthe incident response team. A successful control response will need to\naddress the rationale for the selection.", "title": "IR-9(1) - INFORMATION SPILLAGE RESPONSE | RESPONSIBLE PERSONNEL", "description": "The organization assigns [Assignment: organization-defined personnel or roles] with responsibility for responding to information spills.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "IR-9(2)", "levels": ["high", "moderate"], "notes": "The customer will be responsible for providing information spillage\nresponse training on a regular basis. This may be incorporated into\noverall incident response training or may be a separate training\ncourse or module. A successful control response will need to outline\nthe contents of the information spillage response training and address\nthe frequency at which training is provided.", "title": "IR-9(2) - INFORMATION SPILLAGE RESPONSE | TRAINING", "description": "The organization provides information spillage response training [Assignment: organization- defined frequency].\n\nIR-9 (2) [at least annually]", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "IR-9(3)", "levels": ["high", "moderate"], "notes": "The customer will be responsible for defining and implementing\nprocedures to allow personnel affected by information spills to continue\ncarrying out assigned tasks during the information spill response\nprocess. A successful control response will need to address, for example,\nalternate means of connection to affected systems and changes to\nprocesses required to employ those alternate means.", "title": "IR-9(3) - INFORMATION SPILLAGE RESPONSE | POST-SPILL OPERATIONS", "description": "The organization implements [Assignment: organization-defined procedures] to ensure that organizational personnel impacted by information spills can continue to carry out assigned tasks while contaminated systems are undergoing corrective actions.\n\nSupplemental Guidance:  Correction actions for information systems contaminated due to information spillages may be very time-consuming. During those periods, personnel may not have access to the contaminated systems, which may potentially affect their ability to conduct organizational business.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "IR-9(4)", "levels": ["high", "moderate"], "notes": "The customer will be responsible for defining and employing additional\nsafeguards for personnel exposed to information they were not authorized\nto access. These may include, for example, additional training,\nnon-disclosure agreements, etc. A successful control response will need\nto address the nature of these safeguards and whether they are employed\nproactively (prior to information spillage incidents) or reactively\n(following information spillage incidents).", "title": "IR-9(4) - INFORMATION SPILLAGE RESPONSE | EXPOSURE TO UNAUTHORIZED PERSONNEL", "description": "The organization employs [Assignment: organization-defined security safeguards] for personnel exposed to information not within assigned access authorizations.\n\nSupplemental Guidance:  Security safeguards include, for example, making personnel exposed to spilled information aware of the federal laws, directives, policies, and/or regulations regarding the information and the restrictions imposed based on exposure to such information.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "MA-1", "levels": ["high", "moderate", "low"], "notes": "Section a: The organization will be responsible for developing, documenting, and\ndisseminating System Maintenance policy and procedures. A successful\ncontrol response will need to address the content of the policy\n(which must include purpose, scope, roles, responsibilities,\nmanagement commitments, coordination, and compliance) and procedures\n(which must facilitate the implementation of the policies and\nassociated controls).\nSection b: The organization will be responsible for reviewing and updating the\nSystem Maintenance policy every 3 years, and procedures annually. A\nsuccessful control response will need to address the review and\nupdate process, including the role(s) responsible for initiating the\nreview process, updating the policy and procedures, and providing\napproval of the updates.", "title": "MA-1 - SYSTEM MAINTENANCE POLICY AND PROCEDURES", "description": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n   1. A system maintenance 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 maintenance policy and associated system maintenance controls; and\n b. Reviews and updates the current:\n   1. System maintenance policy [Assignment: organization-defined frequency]; and\n   2. System maintenance 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 MA family. Policy and procedures reflect applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance. Security program policies and procedures at the organization level may make the need for system-specific policies and procedures unnecessary. The policy can be included as part of the general information security policy for organizations or conversely, can be represented by multiple policies reflecting the complex nature of certain organizations. The procedures can be established for the security program in general and for particular information systems, if needed. The organizational risk management strategy is a key factor in establishing policy and procedures. Related control: PM-9.\n\nControl Enhancements:  None.\n\nReferences:  NIST Special Publications 800-12, 800-100.\n\nMA-1 (b) (1) [at least annually]\nMA-1 (b) (2) [at least annually or whenever a significant change occurs]", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "MA-2", "levels": ["high", "moderate", "low"], "notes": "Section c: The customer will be responsible for requiring that datacenter\nmanagement and property asset owners explicitly approve the removal\nof the information system or system components from organizational\nfacilities for off-site maintenance repairs. This is frequently an\ninherited control from IaaS providers and not applicable to OpenShift\ndeployments.\nSection d: The customer will be responsible for sanitizing equipment to remove\nall information from the associated media prior to removal from\norganizational facilities. This is frequently an inherited control\nfrom IaaS providers and not applicable to OpenShift deployments.", "title": "MA-2 - CONTROLLED MAINTENANCE", "description": "The organization:\n a. Schedules, performs, documents, and reviews records of maintenance and repairs on information system components in accordance with manufacturer or vendor specifications and/or organizational requirements;\n b. Approves and monitors all maintenance activities, whether performed on site or remotely and whether the equipment is serviced on site or removed to another location;\n c. Requires that [Assignment: organization-defined personnel or roles] explicitly approve the removal of the information system or system components from organizational facilities for off-site maintenance or repairs;\n d. Sanitizes equipment to remove all information from associated media prior to removal from organizational facilities for off-site maintenance or repairs;\n e. Checks all potentially impacted security controls to verify that the controls are still functioning properly following maintenance or repair actions; and\n f. Includes [Assignment: organization-defined maintenance-related information] in organizational maintenance records.\n\nSupplemental Guidance:  This control addresses the information security aspects of the information system maintenance program and applies to all types of maintenance to any system component (including applications) conducted by any local or nonlocal entity (e.g., in-contract, warranty, in- house, software maintenance agreement). System maintenance also includes those components not directly associated with information processing and/or data/information retention such as scanners, copiers, and printers. Information necessary for creating effective maintenance records includes, for example: (i) date and time of maintenance; (ii) name of individuals or group performing the maintenance; (iii) name of escort, if necessary; (iv) a description of the maintenance performed; and (v) information system components/equipment removed or replaced (including identification numbers, if applicable). The level of detail included in maintenance records can be informed by\nthe security categories of organizational information systems. Organizations consider supply chain issues associated with replacement components for information systems. Related controls: CM-3, CM-4, MA-4, MP-6, PE-16, SA-12, SI-2.\n\nReferences: None.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "MA-3", "levels": ["high", "moderate"], "notes": "The customer will be responsible for approving, controlling, and\nmonitoring information system maintenance records. A successful\ncontrol response will document this process.", "title": "MA-3 - MAINTENANCE TOOLS", "description": "The organization approves, controls, and monitors information system maintenance tools.\n\nSupplemental Guidance:  This control addresses security-related issues associated with maintenance tools used specifically for diagnostic and repair actions on organizational information systems. Maintenance tools can include hardware, software, and firmware items. Maintenance tools are potential vehicles for transporting malicious code, either intentionally or unintentionally, into a facility and subsequently into organizational information systems. Maintenance tools can include, for example, hardware/software diagnostic test equipment and hardware/software packet sniffers. This control does not cover hardware/software components that may support information system maintenance, yet are a part of the system, for example, the software implementing \u201cping,\u201d \u201cls,\u201d \u201cipconfig,\u201d or the hardware and software implementing the monitoring port of an Ethernet switch. Related controls: MA-2, MA-5, MP-6.\n\nReferences: NIST Special Publication 800-88.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "MA-3(1)", "levels": ["high", "moderate"], "notes": "The customer will be responsible for inspecting the maintenance\ntools carried into a facility by maintenance personnel for improper\nor unauthorized modifications. A successful control response\nwill document this process.", "title": "MA-3(1) - MAINTENANCE TOOLS | INSPECT TOOLS", "description": "The organization inspects the maintenance tools carried into a facility by maintenance personnel for improper or unauthorized modifications.\n\nSupplemental Guidance:  If, upon inspection of maintenance tools, organizations determine that the tools have been modified in an improper/unauthorized manner or contain malicious code, the incident is handled consistent with organizational policies and procedures for incident handling. Related control: SI-7.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "MA-3(2)", "levels": ["high", "moderate"], "notes": "The customer will be responsible for checking media containing\ndiagnostic and test programs for malicious code before the\nmedia are used in the information system. A successful control response\ndocuments this process.", "title": "MA-3(2) - MAINTENANCE TOOLS | INSPECT MEDIA", "description": "The organization checks media containing diagnostic and test programs for malicious code before the media are used in the information system.\n\nSupplemental Guidance:  If, upon inspection of media containing maintenance diagnostic and test programs, organizations determine that the media contain malicious code, the incident is handled consistent with organizational incident handling policies and procedures. Related control: SI-3.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "MA-3(3)", "levels": ["high", "moderate"], "notes": "The customer will be responsible for preventing unauthorized removal\nof maintenance equipment containing organizational information. A\nsuccessful control response will address (a) process to verify there\nis no organizational information contained on the equipment; (b) how\nequipment is sanitized or destroyed; (c) process to retain the\nequipment within the facility; (d) process to obtain an exception\nfrom these processes from the information owner that explicitly\nauthorizes removal of equipment from the facility", "title": "MA-3(3) - MAINTENANCE TOOLS | PREVENT UNAUTHORIZED REMOVAL", "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]", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "MA-4", "levels": ["high", "moderate", "low"], "notes": "Section a: The customer will be responsible for approving and monitoring\nnon-local maintenance and diagnostic activities. Because of the nature\nof a cloud system, all maintenance and diagnostic activities will be\nconsidered non-local. Therefore, this control can largely be\naddressed by reference to access control authorizations (see AC-2)\nand the auditing and monitoring discussions in the AU family and SI-4. A\nsuccessful control response will need to address the personnel or roles\nwho are authorized to perform maintenance and diagnostic activities,\nand how those activities are tracked.", "title": "MA-4 - NONLOCAL MAINTENANCE", "description": "The organization:\n a. Approves and monitors nonlocal maintenance and diagnostic activities;\n b. Allows the use of nonlocal maintenance and diagnostic tools only as consistent with organizational policy and documented in the security plan for the information system;\n c. Employs strong authenticators in the establishment of nonlocal maintenance and diagnostic sessions;\n d. Maintains records for nonlocal maintenance and diagnostic activities; and\n e. Terminates session and network connections when nonlocal maintenance is completed.\n\nSupplemental Guidance:  Nonlocal maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network. Local maintenance and diagnostic activities are those activities carried out by individuals physically present at the information system or information system component and not communicating across a network connection. Authentication techniques used in the establishment of nonlocal maintenance and diagnostic sessions reflect the network access requirements in IA-2. Typically, strong authentication requires authenticators that are resistant to replay attacks and employ multifactor authentication. Strong authenticators include, for example, PKI where certificates are stored on a token protected by a password, passphrase, or biometric.  Enforcing requirements in MA-4 is accomplished in part by other controls. Related controls: AC-2, AC-3, AC-6, AC-17, AU-2, AU-3, IA-2, IA-4, IA-5, IA-8, MA-2, MA-5, MP-6, PL-2, SC-7, SC-10, SC-17.\n\nReferences: FIPS Publications 140-2, 197, 201; NIST Special Publications 800-63, 800-88; CNSS Policy 15.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "MA-4(2)", "levels": ["high", "moderate"], "notes": "The customer will be responsible for documenting the policies and\nprocedures for the establishment and use of non-local maintenance\nand diagnostic connections. A successful control response will need to\naddress when non-local maintenance and diagnostic connections are\nallowed, what personnel are authorized to establish and use them, and\nunder what circumstances connections must be terminated.", "title": "MA-4(2) - NONLOCAL MAINTENANCE | DOCUMENT NONLOCAL MAINTENANCE", "description": "The organization documents in the security plan for the information system, the policies and procedures for the establishment and use of nonlocal maintenance and diagnostic connections.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "MA-5", "levels": ["high", "moderate", "low"], "notes": "Section a: The customer will be responsible for establishing a process for\nmaintenance personnel authorizations and maintains a list of authorized\nmaintenance organizations/personnel. A successful control response will\ndocument this process and where the records are kept.\nSection b: The customer will be responsible for ensuring that non-escorted\npersonnel performing maintenance on the information system have\nrequired access authorizations. A successful control response will\ndocument this process, and should involve the information owner\nsigning off on this access.\nSection c: The customer will be responsible for designating organizational\npersonnel with required access authorizations and technical\ncompetence to supervise the maintenance personnel. A successful\ncontrol response will document the process for becoming an escort, and\nhow technical competence is established.", "title": "MA-5 - MAINTENANCE PERSONNEL", "description": "The organization:\n a. Establishes a process for maintenance personnel authorization and maintains a list of authorized maintenance organizations or personnel;\n b. Ensures that non-escorted personnel performing maintenance on the information system have required access authorizations; and\n c. Designates organizational personnel with required access authorizations and technical competence to supervise the maintenance activities of personnel who do not possess the required access authorizations.\n\nSupplemental Guidance:  This control applies to individuals performing hardware or software maintenance on organizational information systems, while PE-2 addresses physical access for individuals whose maintenance duties place them within the physical protection perimeter of the systems (e.g., custodial staff, physical plant maintenance personnel). Technical competence of supervising individuals relates to the maintenance performed on the information systems while having required access authorizations refers to maintenance on and near the systems. Individuals not previously identified as authorized maintenance personnel, such as information technology manufacturers, vendors, systems integrators, and consultants, may require privileged access to organizational information systems, for example, when required to conduct maintenance activities with little or no notice. Based on organizational assessments of risk, organizations may issue temporary credentials to these individuals. Temporary credentials may be for one-time use or for very limited time periods. Related controls: AC-2, IA-8, MP-2, PE-2, PE-3, PE-4, RA-3.\n\nReferences: None.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "MA-5(1)", "levels": ["high", "moderate"], "notes": "Section a: The customer will be responsible for implementing procedures for\nthe use of maintenance personnel that lack appropriate security\nclearances or are not U.S. citizens. These procures must address\n(1) personnel who do not have needed access authorizations are escorted\nby those who do; optionally (2) prior to initiating maintenance or\ndiagnostic activities by personnel lacking access authorizations, all\nvolatile information storage components within the information system\nare sanitized and all nonvolatile storage media are removed or physically\ndisconnected from the system and secured.\nSection b: The customer will be responsible for developing and implementing\nalternate security safeguards in the event an information system\ncomponent cannot be sanitized, removed, or disconnected from the system.\nA successful control response will document how maintenance staff\nlacking appropriate authorizations will not be able to access\ndata residing on the information system.", "title": "MA-5(1) - MAINTENANCE PERSONNEL | INDIVIDUALS WITHOUT APPROPRIATE ACCESS", "description": "The organization:\n (a)   Implements procedures for the use of maintenance personnel that lack appropriate security clearances or are not U.S. citizens, that include the following requirements:\n    (1)   Maintenance personnel who do not have needed access authorizations, clearances, or formal access approvals are escorted and supervised during the performance of maintenance and diagnostic activities on the information system by approved organizational personnel who are fully cleared, have appropriate access authorizations, and are technically qualified;\n   (2)   Prior to initiating maintenance or diagnostic activities by personnel who do not have needed access authorizations, clearances or formal access approvals, all volatile information storage components within the information system are sanitized and all nonvolatile storage media are removed or physically disconnected from the system and secured; and\n (b)   Develops and implements alternate security safeguards in the event an information system component cannot be sanitized, removed, or disconnected from the system.\n\nSupplemental Guidance:  This control enhancement denies individuals who lack appropriate security clearances (i.e., individuals who do not possess security clearances or possess security clearances at a lower level than required) or who are not U.S. citizens, visual and\nelectronic access to any classified information, Controlled Unclassified Information (CUI), or any other sensitive information contained on organizational information systems. Procedures for the use of maintenance personnel can be documented in security plans for the information systems. Related controls: MP-6, PL-2.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "MA-6", "levels": ["high", "moderate"], "notes": "The customer will be responsible for obtaining maintenance support\nand/or spare parts for critical components within a reasonable time\nto minimize production impact.", "title": "MA-6 - TIMELY MAINTENANCE", "description": "The organization obtains maintenance support and/or spare parts for [Assignment: organization-defined information system components] within [Assignment: organization-defined time period] of failure.\n\nSupplemental Guidance:  Organizations specify the information system components that result in increased risk to organizational operations and assets, individuals, other organizations, or the Nation when the functionality provided by those components is not operational. Organizational actions to obtain maintenance support typically include having appropriate contracts in place. Related controls: CM-8, CP-2, CP-7, SA-14, SA-15.\n\nReferences: None.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "MP-1", "levels": ["high", "moderate", "low"], "notes": "Narrative text on how product can be configured against MP-1.\n\nThis answer can be multi-line.", "title": "MP-1 - MEDIA PROTECTION POLICY AND PROCEDURES", "description": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n   1. A media 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 media protection policy and associated media protection controls; and\n b. Reviews and updates the current:\n   1. Media protection policy [Assignment: organization-defined frequency]; and\n   2. Media 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 MP family. Policy and procedures reflect applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance. Security program policies and procedures at the organization level may make the need for system-specific policies and procedures unnecessary. The policy can be included as part of the general information security policy for organizations or conversely, can be represented by multiple policies reflecting the complex nature of certain organizations. The procedures can be established for the security program in general and for particular information systems, if needed. The organizational risk management strategy is a key factor in establishing policy and procedures. Related control: PM-9.\n\nControl Enhancements:  None.\n\nReferences:  NIST Special Publications 800-12, 800-100.\n\nMP-1 (b) (1) [at least annually]\nMP-1 (b) (2) [at least annually or whenever a significant change occurs]", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "MP-2", "levels": ["high", "moderate", "low"], "notes": "Narrative text on how product can be configured against MP-2.\n\nThis answer can be multi-line.", "title": "MP-2 - MEDIA ACCESS", "description": "The organization restricts access to [Assignment: organization-defined types of digital and/or non-digital media] to [Assignment: organization-defined personnel or roles].\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. Restricting non-digital media access includes, for example, denying access to patient medical records in a community hospital unless the individuals seeking access to such records are authorized healthcare providers. Restricting access to digital media includes, for example, limiting access to design specifications stored on compact disks in the media library to the project leader and the individuals on the development team. Related controls: AC-3, IA-2, MP-4, PE-2, PE-3, PL-2.\n\nMP-2-1 [any digital and non-digital media deemed sensitive]", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "PL-1", "levels": ["high", "moderate", "low"], "notes": "Section a: The organization will be responsible for developing, documenting, and\ndisseminating Security Planning policy and procedures. A successful\ncontrol response will need to address the content of the policy\n(which must include purpose, scope, roles, responsibilities,\nmanagement commitment, coordination, and compliance) and procedures\n(which must facilitate the implementation of the policies and\nassociated controls).\nSection b: The organization will be responsible for reviewing and updating the\nSecurity Planning policy every 3 years, and procedures annually. A\nsuccessful control response will need to address the review and\nupdate process, including the role(s) responsible for initiating\nthe review process, updating the policy and procedures, and providing\napproval of the updates.", "title": "PL-1 - SECURITY PLANNING POLICY AND PROCEDURES", "description": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n   1. A security planning 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 planning policy and associated security planning controls; and\n b. Reviews and updates the current:\n   1. Security planning policy [Assignment: organization-defined frequency]; and\n   2. Security planning 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 PL family. Policy and procedures reflect applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance. Security program policies and procedures at the organization level may make the need for system-specific policies and procedures unnecessary. The policy can be included as part of the general information security policy for organizations or conversely, can be represented by multiple policies reflecting the complex nature of certain organizations. The procedures can be established for the security program in general and for particular information systems, if needed. The organizational risk management strategy is a key factor in establishing policy and procedures. Related control: PM-9.\n\nControl Enhancements:  None.\n\nReferences:  NIST Special Publications 800-12, 800-18, 800-100.\n\nPL-1 (b) (1) [at least annually]\nPL-1 (b) (2) [at least annually or whenever a significant change occurs]", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "PL-2", "levels": ["high", "moderate", "low"], "notes": "Section a: The customer will be responsible for developing a system security\nplan (this document) in accordance with the above requirements. A\nsuccessful control response will need to address each of the\nrequirements and how this document meets them.\n\nThe customer may with to consult NIST Special Publication 800-18,\nRevision 1, Guide for Developing Security Plans for Federal Information\nSystems, which contains guidance on security planning. Portions of this\nsystem security plan will discuss controls inherited from infrastructure\nproviders, such as Microsoft Azure, and will refer to the\ninfrastructure providers SSP.\nSection b: The customer will be responsible for distributing the system security\nplan to relevant personnel and keeping those personnel informed of\nsubsequent changes. A successful control response will need to address\nidentifying personnel who should receive a copy of the system security\nplan, as well as ensuring all such personnel are notified\nappropriately.\nSection c: The customer will be responsible for reviewing the system security\nplan at the required frequency. A successful control response will need\nto address the initiation of the review process and the roles or\nindividuals responsible for review.\nSection d: The customer will be responsible for updating the system security\nplan to address changes to the information system and its environment\nor any problems identified during implementation or security\nassessments. A successful control response will need to discuss the\nroles or individuals responsible for updating the plan, as well as\nthe process for approval of any updates.\nSection e: The customer will be responsible for protecting the security plan from\nunauthorized disclosure or modification. A successful control response\nwill need to address policy, procedural, and technical safeguards that\nare in place to protect the system security plan.", "title": "PL-2 - SYSTEM SECURITY PLAN", "description": "The organization:\n a. Develops a security plan for the information system that:\n   1. Is consistent with the organization\u2019s enterprise architecture;\n   2. Explicitly defines the authorization boundary for the system;\n   3. Describes the operational context of the information system in terms of missions and business processes;\n   4. Provides the security categorization of the information system including supporting rationale;\n   5. Describes the operational environment for the information system and relationships with or connections to other information systems;\n   6. Provides an overview of the security requirements for the system;\n   7. Identifies any relevant overlays, if applicable;\n   8. Describes the security controls in place or planned for meeting those requirements including a rationale for the tailoring and supplementation decisions; and\n   9. Is reviewed and approved by the authorizing official or designated representative prior to plan implementation;\n b. Distributes copies of the security plan and communicates subsequent changes to the plan to [Assignment: organization-defined personnel or roles];\n c. Reviews the security plan for the information system [Assignment: organization-defined frequency];\n d. Updates the plan to address changes to the information system/environment of operation or problems identified during plan implementation or security control assessments; and\n e. Protects the security plan from unauthorized disclosure and modification.\n\nSupplemental Guidance:  Security plans relate security requirements to a set of security controls and control enhancements. Security plans also describe, at a high level, how the security controls and control enhancements meet those security requirements, but do not provide detailed, technical descriptions of the specific design or implementation of the controls/enhancements. Security plans contain sufficient information (including the specification of parameter values for assignment and selection statements either explicitly or by reference) to enable a design and implementation that is unambiguously compliant with the intent of the plans and subsequent determinations of risk to organizational operations and assets, individuals, other organizations, and the Nation if the plan is implemented as intended. Organizations can also apply tailoring guidance to the security control baselines in Appendix D and CNSS Instruction 1253 to develop overlays for community-wide use or to address specialized requirements, technologies, or missions/environments of operation (e.g., DoD-tactical, Federal Public Key Infrastructure, or Federal Identity, Credential, and Access Management, space operations). Appendix I provides guidance on developing overlays.\n\nSecurity plans need not be single documents; the plans can be a collection of various documents including documents that already exist. Effective security plans make extensive use of references to policies, procedures, and additional documents (e.g., design and implementation specifications) where more detailed information can be obtained. This reduces the documentation requirements associated with security programs and maintains security-related information in other established management/operational areas related to enterprise architecture, system development life cycle, systems engineering, and acquisition. For example, security plans do not contain detailed contingency plan or incident response plan information but instead provide explicitly or by reference, sufficient information to define what needs to be accomplished by those plans. Related controls: AC-2, AC-6, AC-14, AC-17, AC-20, CA-2, CA-3, CA-7, CM-9, CP-2, IR-8, MA-4, MA-5, MP-2, MP-4, MP-5, PL-7, PM-1, PM-7, PM-8, PM-9, PM-11, SA-5, SA-17.\n\nReferences: NIST Special Publication 800-18.\n\nPL-2 (c) [at least annually]", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "PL-2(3)", "levels": ["high", "moderate"], "notes": "The customer will be responsible for planning and coordinating\nsecurity-related activities so as to reduce the impact on other\norganizational entities. These activities may include security\nassessments, audits, maintenance, patch management, and contingency\nplan testing. A successful control response will need to address the\nprocess by which other organizational entities are notified of and\nconsulted regarding such activities.", "title": "PL-2(3) - SYSTEM SECURITY PLAN | PLAN / COORDINATE WITH OTHER ORGANIZATIONAL ENTITIES", "description": "The organization plans and coordinates security-related activities affecting the information system with [Assignment: organization-defined individuals or groups] before conducting such activities in order to reduce the impact on other organizational entities.\n\nSupplemental Guidance:  Security-related activities include, for example, security assessments, audits, hardware and software maintenance, patch management, and contingency plan testing. Advance planning and coordination includes emergency and nonemergency (i.e., planned or nonurgent unplanned) situations. The process defined by organizations to plan and coordinate security-related activities can be included in security plans for information systems or other documents, as appropriate. Related controls: CP-4, IR-4.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "PL-4", "levels": ["high", "moderate", "low"], "notes": "Section a: The customer will be responsible for defining, documenting, and\ndistributing rules of behavior. A successful control response will need\nto outline the rules of behavior and discuss the process for making them\navailable to users requiring access to the system.\nSection b: The customer will be responsible for obtaining signed acknowledgement\nof the rules of behavior from its users. A successful control response\nwill need to address the process for withholding authorization until\nsignatures are obtained.\nSection c: The customer will be responsible for reviewing and updating the rules\nof behavior at the required frequency. A successful control response\nwill need to address the process for initiating review, as well as the\nindividuals or roles for carrying out the review, managing updates, and\napproving the final version.\nSection d: The customer will be responsible for obtaining signed acknowledgement\nof the updated rules of behavior. A successful control response will\nneed to address the process for removing authorization if signatures\nare not obtained in a timely manner.", "title": "PL-4 - RULES OF BEHAVIOR", "description": "The organization:\n a. Establishes and makes readily available to individuals requiring access to the information system, the rules that describe their responsibilities and expected behavior with regard to information and information system usage;\n b. Receives a signed acknowledgment from such individuals, indicating that they have read, understand, and agree to abide by the rules of behavior, before authorizing access to information and the information system;\n c. Reviews and updates the rules of behavior [Assignment: organization-defined frequency]; and d. Requires individuals who have signed a previous version of the rules of behavior to read and\nresign when the rules of behavior are revised/updated.\n\nSupplemental Guidance: This control enhancement applies to organizational users. Organizations consider rules of behavior based on individual user roles and responsibilities, differentiating, for example, between rules that apply to privileged users and rules that apply to general users. Establishing rules of behavior for some types of non-organizational users including, for example, individuals who simply receive data/information from federal information systems, is often not feasible given the large number of such users and the limited nature of their interactions with the systems. Rules of behavior for both organizational and non-organizational users can also be established in AC-8, System Use Notification. PL-4 b. (the signed acknowledgment portion of this control) may be satisfied by the security awareness training and role-based security training programs conducted by organizations if such training includes rules of behavior. Organizations can use electronic signatures for acknowledging rules of behavior. Related controls: AC-2, AC-6, AC-8, AC-9, AC-17, AC-18, AC-19, AC-20, AT-2, AT-3, CM-11, IA-2, IA-4, IA-5, MP-7, PS-6, PS-8, SA-5.\n\nReferences: NIST Special Publication 800-18.\n\nPL-4 (c) [annually]", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "PL-4(1)", "levels": ["high", "moderate"], "notes": "The customer will be responsible for incorporating explicit\nrestrictions on the use of social media/networking sites and posting\norganizational information on public websites into the rules of\nbehavior. A successful control response will need to outline the\nrelevant portions of the rules of behavior.", "title": "PL-4(1) - RULES OF BEHAVIOR | SOCIAL MEDIA AND NETWORKING RESTRICTIONS", "description": "The organization includes in the rules of behavior, explicit restrictions on the use of social media/networking sites and posting organizational information on public websites.\n\nSupplemental Guidance:  This control enhancement addresses rules of behavior related to the use of social media/networking sites: (i) when organizational personnel are using such sites for official duties or in the conduct of official business; (ii) when organizational information is involved in social media/networking transactions; and (iii) when personnel are accessing social media/networking sites from organizational information systems. Organizations also address specific rules that prevent unauthorized entities from obtaining and/or inferring non- public organizational information (e.g., system account information, personally identifiable information) from social media/networking sites.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "PL-8", "levels": ["high", "moderate"], "notes": "Section a: The customer will be responsible for developing their information\nsecurity architecture. A successful control response will need to\ndiscuss the guiding principles used to protect confidentiality,\nintegrity, and availability of system information and the dependencies\non external services (such as Microsoft Azure). Additionally, a\ndescription of the information security architecture should be included\nin the introductory sections of this system security plan.\nSection b: The customer will be responsible for reviewing and updating the\nsecurity architecture at a required frequency. A successful control\nresponse will need to address the process for initiating review, as well\nas the individuals or roles responsible for carrying out the review,\nmanaging updates, and approving the final version.\nSection c: The customer will be responsible for incorporating changes to the\nsecurity architecture into this system security plan as well as\nrelated materials. A successful control response will need to address\nthe process for aligning the contents of the system security plan\nwith the information security architecture, including the\nindividuals or roles responsible for that alignment.", "title": "PL-8 - INFORMATION SECURITY ARCHITECTURE", "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\u2019s modern architecture, it is becoming less common for organizations to control all information resources. There are going to be key dependencies on external information services and service providers. Describing such dependencies in the information security architecture is important to developing a comprehensive mission/business protection strategy. Establishing, developing, documenting, and maintaining under configuration control, a baseline configuration for organizational information systems is critical to implementing and maintaining an effective information security architecture. The development of the information security architecture is coordinated with the Senior Agency Official for Privacy (SAOP)/Chief Privacy Officer (CPO) to ensure that security controls needed to support privacy requirements are identified and effectively implemented. PL-8 is primarily directed at organizations (i.e., internally focused) to help ensure that organizations develop an information security architecture for the information system, and that the security architecture is integrated with or tightly coupled to the enterprise architecture through the organization-wide information security architecture. In contrast, SA-17 is primarily directed at external information technology product/system developers and integrators (although SA-17 could be used internally within organizations for in-house system development). SA-17, which is complementary to PL-8, is selected when organizations outsource the development of information systems or information system components to external entities, and there is a need to demonstrate/show consistency with the organization\u2019s enterprise architecture and information security architecture. Related controls: CM-2, CM-6, PL-2, PM-7, SA-5, SA-17, Appendix J.\n\nReferences: None.\n\nPL-8 (b) [at least annually or when a significant change occurs]\nPL-8 (b) Guidance: Significant change is defined in NIST Special Publication 800-37 Revision 1, Appendix F, page F-7.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "PS-1", "levels": ["high", "moderate", "low"], "notes": "Section a: The organization will be responsible for developing, documenting, and\ndisseminating Personnel Security policy and procedures. A successful\ncontrol response will need to address the content of the policy\n(which must include purpose, scope, roles, responsibilities,\nmanagement commitment, coordination, and compliance) and procedures\n(which must facilitate the implementation of the policies and\nassociated controls).\nSection b: The organization will be responsible for reviewing and updating the\nPersonnel Security policy every 3 years, and procedures annually. A\nsuccessful control response will need to address the review and update\nprocess, including the role(s) responsible for initiating the review\nprocess, updating the policy and procedures, and providing approval\nof the updates.", "title": "PS-1 - PERSONNEL SECURITY POLICY AND PROCEDURES", "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]", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "PS-2", "levels": ["high", "moderate", "low"], "notes": "Section a: The customer will be responsible for assigning risk designations to\nall positions of customer personnel using IaaS that are consistent\nwith the customers internal policies and procedures. A successful\ncontrol response will need to address the criteria used in risk\ndesignation assignments (for example, specific responsibilities, access\nto certain types of data, etc.).\nSection b: The customer will be responsible for establishing screening criteria\nfor individuals filling positions with access to the information\nsystem. A successful control response will need to address the rationale\nfor each level of screening based on the responsibilities or access\nassociated with each risk designation.\nSection c: The customer will be responsible for reviewing and revising risk\ndesignations at the required frequency. A successful control response\nwill need to address the review process, including the role(s)\nresponsible for initiating the review process, revising risk\ndesignations, and providing approval of any changes.", "title": "PS-2 - POSITION RISK DESIGNATION", "description": "The organization:\n a. Assigns a risk designation to all organizational positions;\n b. Establishes screening criteria for individuals filling those positions; and\n c. Reviews and updates position risk designations [Assignment: organization-defined frequency].\n\nSupplemental Guidance:  Position risk designations reflect Office of Personnel Management policy and guidance. Risk designations can guide and inform the types of authorizations individuals receive when accessing organizational information and information systems. Position screening criteria include explicit information security role appointment requirements (e.g., training, security clearances). Related controls: AT-3, PL-2, PS-3.\n\nControl Enhancements:  None.\n\nReferences:  5 C.F.R. 731.106(a).\n\nPS-2 (c) [at least annually]", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "PS-3", "levels": ["high", "moderate", "low"], "notes": "Section a: The customer will be responsible for screening individuals prior to\nauthorizing access. A successful control response will need to\ndemonstrate alignment of the screening as performed to the screening\nrequirements established in PS-2.\nSection b: The customer will be responsible for rescreening individuals at the\nrequired frequency. A successful control response will need to discuss\nthe process for initiating rescreening, as well as for disabling or\nremoving access if rescreening is not completed in a timely manner.", "title": "PS-3 - PERSONNEL SCREENING", "description": "The organization:\n a. Screens individuals prior to authorizing access to the information system; and\n b. Rescreens individuals according to [Assignment: organization-defined conditions requiring rescreening and, where rescreening is so indicated, the frequency of such rescreening].\n\nSupplemental Guidance:  Personnel screening and rescreening activities reflect applicable federal laws, Executive Orders, directives, regulations, policies, standards, guidance, and specific criteria established for the risk designations of assigned positions. Organizations may define different rescreening conditions and frequencies for personnel accessing information systems based on types of information processed, stored, or transmitted by the systems. Related controls: AC-2, IA-4, PE-2, PS-2.\n\nReferences: 5 C.F.R. 731.106; FIPS Publications 199, 201; NIST Special Publications 800-60, 800-73, 800-76, 800-78; ICD 704.\n\nPS-3 (b) [for national security clearances; a reinvestigation is required during the fifth (5th) year for top secret security clearance, the tenth (10th) year for secret security clearance, and fifteenth (15th) year for confidential security clearance.\n\nFor moderate risk law enforcement and high impact public trust level, a reinvestigation is required during the fifth (5th) year.  There is no reinvestigation for other moderate risk positions or any low risk positions]", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "PS-3(3)", "levels": ["high", "moderate"], "notes": "The customer will be responsible for ensuring that access to\ninformation requiring special protection is contingent on additional\nscreening as required by the specific nature of that information. A\nsuccessful control response will need to address identifying such\ninformation and enforcing the additional screening prior to\nauthorization of access", "title": "PS-3(3) - PERSONNEL SCREENING | INFORMATION WITH SPECIAL PROTECTION MEASURES", "description": "The organization ensures that individuals accessing an information system processing, storing, or transmitting information requiring special protection:\n (a)   Have valid access authorizations that are demonstrated by assigned official government duties; and\n (b)   Satisfy [Assignment: organization-defined additional personnel screening criteria].\n\nSupplemental Guidance:  Organizational information requiring special protection includes, for example, Controlled Unclassified Information (CUI) and Sources and Methods Information (SAMI). Personnel security criteria include, for example, position sensitivity background screening requirements.\n\nPS-3 (3) (b) [personnel screening criteria \u2013 as required by specific information]", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "PS-4", "levels": ["high", "moderate", "low"], "notes": "Section c: The customer will be responsible for conducting exit interviews. A\nsuccessful control response will need to address the topics discussed\nduring the interviews and the personnel responsible for conducting\nthe interviews.\nSection d: The customer will be responsible for retrieving all security related,\ninformation system related, organizational property from terminated\nindividuals. A successful control response will need to address the\nprocess and personnel responsible for ensuring that all such property\nis retrieved.\nSection e: The customer will be responsible for retaining access to information\nand information systems formerly controlled by terminated individuals. A\nsuccessful control response will need to address how this retention\noccurs, personnel responsible for retention, and any minimum or\nmaximum retention periods.\nSection f: The customer will be responsible for notifying relevant personnel\nwithin a defined time period after an individual is terminated. A\nsuccessful control response will need to define the time period and\npersonnel who should be notified, as well as discussing the process\nby which notification happens.", "title": "PS-4 - PERSONNEL TERMINATION", "description": "The organization, upon termination of individual employment:\n a. Disables information system access within [Assignment: organization-defined time period];\n b. Terminates/revokes any authenticators/credentials associated with the individual;\n c. Conducts exit interviews that include a discussion of [Assignment: organization-defined information security topics];\n d. Retrieves all security-related organizational information system-related property;\n e. Retains access to organizational information and information systems formerly controlled by terminated individual; and\n f. Notifies [Assignment: organization-defined personnel or roles] within [Assignment: organization-defined time period].\n\nSupplemental Guidance:  Information system-related property includes, for example, hardware authentication tokens, system administration technical manuals, keys, identification cards, and building passes. Exit interviews ensure that terminated individuals understand the security constraints imposed by being former employees and that proper accountability is achieved for information system-related property. Security topics of interest at exit interviews can include, for example, reminding terminated individuals of nondisclosure agreements and potential limitations on future employment. Exit interviews may not be possible for some terminated individuals, for example, in cases related to job abandonment, illnesses, and nonavailability of supervisors. Exit interviews are important for individuals with security clearances. Timely execution of termination actions is essential for individuals terminated for cause. In certain situations, organizations consider disabling the information system accounts of individuals that are being terminated prior to the individuals being notified. Related controls: AC-2, IA-4, PE-2, PS-5, PS-6.\n\nReferences: None.\n\nPS-4 (a) [eight (8) hours]", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "PS-5", "levels": ["high", "moderate", "low"], "notes": "Section a: The customer will be responsible for reviewing access authorizations\nfor individuals when those individuals are reassigned or transferred. A\nsuccessful control response will need to address the initiation of this\nreview and individuals or roles responsible for performing and validating\nthe results of reviews.\nSection b: The customer will be responsible for initiating reassignments or\ntransfers within a customer-defined time period after the formal\nreassignment or transfer. A successful control response will need to\naddress the specific actions taken, personnel responsible for those\nactions, and timeframes for initiation of those actions.\nSection c: The customer will be responsible for modifying access authorizations\nbased on the results of the review carried out in Part A. A successful\ncontrol response will need to address the process by which\nauthorizations are modified, personnel responsible for initiating the\nchange, and any technical means of enforcement of the change.\nSection d: The customer will be responsible for notifying relevant personnel\nwithin the required timeframe after a formal reassignment or transfer. A\nsuccessful control response will need to address the identification of\ninterested personnel or roles as well as the means by which notification\noccurs.", "title": "PS-5 - PERSONNEL TRANSFER", "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]", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "PS-6", "levels": ["high", "moderate", "low"], "notes": "Section a: The customer will be responsible for developing agreements for access\nto the system. A successful control response will need to outline the\ncontents of access agreements and the conditions under which they\nare used.\nSection b: The customer will be responsible for reviewing and updating access\nagreements at the required frequency. A successful control response will\nneed to address the initiation of the review process, the personnel or\nroles responsible for reviewing and updating the agreement, and the\nprocess for approval of any changes.\nSection c: The customer will be responsible for ensuring that individuals\nreview and sign access agreements prior to initial access and to\nmaintain access after updates. A successful control response will need\nto address the process for withholding access until after the initial\nsignature is received, as well as for disabling or removing access if\nthe access agreement changes and an individual does not re-sign it in\na timely manner.", "title": "PS-6 - ACCESS AGREEMENTS", "description": "The organization:\n a. Develops and documents access agreements for organizational information systems;\n b. Reviews and updates the access agreements [Assignment: organization-defined frequency]; and\n c. Ensures that individuals requiring access to organizational information and information systems:\n   1. Sign appropriate access agreements prior to being granted access; and\n   2. Re-sign access agreements to maintain access to organizational information systems when access agreements have been updated or [Assignment: organization-defined frequency].\n\nSupplemental Guidance: Access agreements include, for example, nondisclosure agreements, acceptable use agreements, rules of behavior, and conflict-of-interest agreements. Signed access agreements include an acknowledgement that individuals have read, understand, and agree to abide by the constraints associated with organizational information systems to which access is authorized. Organizations can use electronic signatures to acknowledge access agreements unless specifically prohibited by organizational policy. Related control: PL-4, PS-2, PS-3, PS-4, PS-8.\n\nReferences: None.\n\nPS-6 (b) [at least annually]\nPS-6 (c) (2) [at least annually and any time there is a change to the user's level of access]", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "PS-7", "levels": ["high", "moderate", "low"], "notes": "Section a: The customer will be responsible for establishing personnel security\nrequirements for third-party providers. A successful control response\nwill need to outline these requirements and address the process\nfor notifying third-party providers of the requirements.\nSection b: The customer will be responsible for requiring third-party providers\nto comply with the requirements established in PS-7(a). A successful\ncontrol response will need to address the process for obtaining\nagreement to the requirements and enforcing the requirements.\nSection c: The customer will be responsible for documenting personnel security\nrequirements for third-party providers. A successful control response\nwill need to discuss the process for creating documentation and sharing\nit with the providers.\nSection d: The customer will be responsible for including notification of\nterminations and transfers within the personnel security requirements. A\nsuccessful control response will need to discuss the specific\nnotification requirements, in particular the requirement for\nnotification within the same day.\nSection e: The customer will be responsible for monitoring provider compliance\nwith personnel security requirements. A successful control response\nwill need to address personnel responsible for monitoring compliance,\nmechanisms used for monitoring, and consequences of non-compliance.", "title": "PS-7 - THIRD-PARTY PERSONNEL SECURITY", "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]", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "PS-8", "levels": ["high", "moderate", "low"], "notes": "Section a: The organization will be responsible for establishing sanctions process\nfor non-compliance with policies and procedures. A successful control\nresponse will need to address different forms of non-compliance and\nspecific measures that may be enforced for each.\nSection b: The organization will ne responsible for notifying interested personnel\nwhen the sanctions process is initiated. A successful control response\nwill need to delineate the relevant personnel to be notified, the\nroles or individuals responsible for notification, and the information\nconveyed as part of the notification (to include, at a minimum the\nindividual sanctioned and the reason for the sanction).", "title": "PS-8 - PERSONNEL SANCTIONS", "description": "The organization:\n a. Employs a formal sanctions process for individuals failing to comply with established information security policies and procedures; and\n b. Notifies [Assignment: organization-defined personnel or roles] within [Assignment: organization-defined time period] when a formal employee sanctions process is initiated, identifying the individual sanctioned and the reason for the sanction.\n\nSupplemental Guidance: Organizational sanctions processes reflect applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance. Sanctions processes are described in access agreements and can be included as part of general personnel policies and procedures for organizations. Organizations consult with the Office of the General Counsel regarding matters of employee sanctions. Related controls: PL-4, PS-6.\n\nControl Enhancements:  None.\n\nReferences:  None.\n\nPS-8(b)-1 [at a minimum, the ISSO and/or similar role within the organization]", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "RA-1", "levels": ["high", "moderate", "low"], "notes": "Section a: The organization will be responsible for developing, documenting, and\ndisseminating Risk Assessment policy and procedures. A successful\ncontrol response will need to address the content of the policy\n(which must include purpose, scope, roles, responsibilities,\nmanagement commitment, coordination, and compliance) and procedures\n(which must facilitate the implementation of the policies and\nassociated controls).\nSection b: The organization will be responsible for reviewing and updating the\nRisk Assessment policy every 3 years, and procedures annually. A\nsuccessful control response will need to address the review and update\nprocess, including the role(s) responsible for initiating the review\nprocess, updating the policy and procedures, and providing approval\nof the updates.", "title": "RA-1 - RISK ASSESSMENT POLICY AND PROCEDURES", "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]", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "RA-2", "levels": ["high", "moderate", "low"], "notes": "Section a: The customer will be responsible for categorizing the customer\nsystem and information contained within it. A successful control\nresponse will need to address the applicable Federal Laws, Executive\nOrders, directives, policies, regulations, standards, and guidance, as\nwell as the key stakeholders involved in the categorization decision.\n\nResources related to information categorization include FIPS 199,\nStandards for Security Categorization of Federal Information and\nInformation Systems, and NIST SP 800-61, Rev. 1, Guide for Mapping\nTypes of Information and Information Systems to Security Categories.\nSection b: The customer will be responsible for documenting the security\ncategorization. A successful response will need to address supporting\nrationale, including types of information considered, risk impact\nanalysis, and input from stakeholders and organizational officials.\nSection c: The customer will be responsible for presenting the security\ncategorization decision to the Authorizing Official or a\ndesignated representative for review and approval.", "title": "RA-2 - SECURITY CATEGORIZATION", "description": "The organization:\n a. Categorizes information and the information system in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance;\n b. Documents the security categorization results (including supporting rationale) in the security plan for the information system; and\n c. Ensures that the security categorization decision is reviewed and approved by the authorizing official or authorizing official designated representative.\n\nSupplemental Guidance:  Clearly defined authorization boundaries are a prerequisite for effective security categorization decisions. Security categories describe the potential adverse impacts to organizational operations, organizational assets, and individuals if organizational information and information systems are comprised through a loss of confidentiality, integrity, or availability. Organizations conduct the security categorization process as an organization-wide activity with the involvement of chief information officers, senior information security officers, information system owners, mission/business owners, and information owners/stewards. Organizations also consider the potential adverse impacts to other organizations and, in accordance with the USA PATRIOT Act of 2001 and Homeland Security Presidential Directives, potential national-level adverse impacts. Security categorization processes carried out by organizations facilitate the development of inventories of information assets, and along with CM-8, mappings to specific information system components where information is processed, stored, or transmitted. Related controls: CM-8, MP-4, RA-3, SC-7.\n\nControl Enhancements:  None.\n\nReferences:  FIPS Publication 199; NIST Special Publications 800-30, 800-39, 800-60.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "RA-3", "levels": ["high", "moderate", "low"], "notes": "Section a: The customer will be responsible for conducting a risk assessment,\nincluding a review of controls inherited from infrastructure providers,\nand for those which the customer is responsible. A successful control\nresponse will need to address the assessment methodology and calculation\nof the likelihood and magnitude of harm that could result from\nunauthorized access, use, disclosure, disruption, or modification of\nIaaS layers, the customer application, and the information processed,\nstored, and transmitted by those systems.\n\nNIST SP 80-30 Rev. 1, Guide for Conducting Risk Assessments, and NIST\nSP 800-53A Rev. 4, Assessing Security and Privacy Controls in Federal\nInformation Systems and Organizations: Building Effective Assessment\nPlans both provide guidance that may be used by the customer in\ndeveloping the risk assessment methodology and performing the risk\nassessment.\nSection b: The customer will be responsible for documenting the results of the\nrisk assessment in a Security Assessment Report. A successful control\nresponse will need to address specific requirements for the report\n(e.g., it should include controls that are considered \"other than\nsatisfied,\" potential weaknesses in controls that meet minimum\nrequirements, recommended remediation steps, and risks associated with\nthe system). The customer may with to employ a 3PAO to assist with\nthe initial risk assessment (see CA-2).\nSection c: The customer will be responsible for reviewing risk assessment results\nat the required frequency. A successful control response will need to\naddress the personnel or roles responsible for reviewing results, as\nwell as any actions taken in response to risk assessment results.\nSection d: The customer will be responsible for disseminating risk assessment\nresults to customer-defined stakeholders and organizational officials. A\nsuccessful control response will need to outline the stakeholders\ninvolved and the means of distribution of results.\nSection e: The customer will be responsible for updating the risk assessment\nat the required frequency of when a significant change occurs. (Note\nthat \"significant change\" is defined in NIST 800-37 Rev 1, Appendix F).\nA successful control response will need to discuss examples of\nsignificant changes that might occur within the customer application,\nas well as the specific actions that will be taken when the risk\nassessment is updated (such as updating system security plans and\nother documentation).", "title": "RA-3 - RISK ASSESSMENT", "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.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "RA-5", "levels": ["high", "moderate", "low"], "notes": "Section a: The customer will be responsible for scanning for vulnerabilities\nin customer applications and databases. Additionally, IaaS customers\nusing an operating system image will be responsible for scanning\nfor vulnerabilities in the operating system. A successful control\nresponse will need to address the tools used to perform scans as well\nas the additional FedRAMP requirement for independent assessors to\nscan the system on an annual basis.\nSection b: The customer will be responsible for ensuring that vulnerability\nscanning tools use standards for enumerating components, flaws, and\nimproper configurations; formatting checklists and test procedures;\nand measuring vulnerability impact. A successful control response will\nneed to address how each vulnerability scanning tool in use meets these\nrequirements (for example, by using Common Vulnerabilities and\nExposures (CVE) values).\nSection c: The customer will be responsible for analyzing scan reports and\nassessment results for actionable data. A successful control response\nwill need to address the roles or personnel responsible for the\nanalysis, as well as criteria used in performing the analysis.\nSection e: The customer will be responsible for sharing vulnerability scan\nresults and security assessment reports with customer-defined\nstakeholders. A successful control response will need to address the\nstakeholders involved and the types of information shared with\neach stakeholder.", "title": "RA-5 - VULNERABILITY SCANNING", "description": "The organization:\n a. Scans for vulnerabilities in the information system and hosted applications [Assignment: organization-defined frequency and/or randomly in accordance with organization-defined process] and when new vulnerabilities potentially affecting the system/applications are identified and reported;\n b. Employs vulnerability scanning tools and techniques that facilitate interoperability among tools and automate parts of the vulnerability management process by using standards for:\n   1. Enumerating platforms, software flaws, and improper configurations;\n   2. Formatting checklists and test procedures; and\n   3. Measuring vulnerability impact;\n c. Analyzes vulnerability scan reports and results from security control assessments;\n d. Remediates legitimate vulnerabilities [Assignment: organization-defined response times], in accordance with an organizational assessment of risk; and\n e. Shares information obtained from the vulnerability scanning process and security control assessments with [Assignment: organization-defined personnel or roles] to help eliminate similar vulnerabilities in other information systems (i.e., systemic weaknesses or deficiencies).\n\nSupplemental Guidance:  Security categorization of information systems guides the frequency and comprehensiveness of vulnerability scans. Organizations determine the required vulnerability scanning for all information system components, ensuring that potential sources of vulnerabilities such as networked printers, scanners, and copiers are not overlooked. Vulnerability analyses for custom software applications may require additional approaches such as static analysis, dynamic analysis, binary analysis, or a hybrid of the three approaches. Organizations can employ these analysis approaches in a variety of tools (e.g., web-based application scanners, static analysis tools, binary analyzers) and in source code reviews. Vulnerability scanning includes, for example: (i) scanning for patch levels; (ii) scanning for functions, ports, protocols, and services that should not be accessible to users or devices; and (iii) scanning for improperly configured or incorrectly operating information flow control mechanisms. Organizations consider using tools that express vulnerabilities in the Common Vulnerabilities and Exposures (CVE) naming convention and that use the Open Vulnerability Assessment Language (OVAL) to determine/test for the presence of vulnerabilities. Suggested sources for vulnerability information include the Common Weakness Enumeration (CWE) listing and the National Vulnerability Database (NVD). In addition, security control assessments such as red team exercises provide other sources of potential vulnerabilities for which to scan. Organizations also consider using tools that express vulnerability impact by the\n\nCommon Vulnerability Scoring System (CVSS). Related controls: CA-2, CA-7, CM-4, CM-6, RA-2, RA-3, SA-11, SI-2.\n\nReferences: NIST Special Publications 800-40, 800-70, 800-115; Web: http://cwe.mitre.org, http://nvd.nist.gov.\n\nRA-5 (a) [monthly operating system/infrastructure; monthly web applications and databases]\nRA-5 (d) [high-risk vulnerabilities mitigated within thirty (30) days from date of discovery; moderate-risk vulnerabilities mitigated within ninety (90) days from date of discovery; low risk vulnerabilities mitigated within one hundred and eighty (180) days from date of discovery]\nRA-5 Guidance: See the FedRAMP Documents page under Key Cloud Service Provider (CSP) Documents> Vulnerability Scanning Requirements \nhttps://www.FedRAMP.gov/documents/\nRA-5 (a) Requirement: an accredited independent assessor scans operating systems/infrastructure, web applications, and databases once annually.\nRA-5 (e) Requirement: to include all Authorizing Officials; for JAB authorizations to include FedRAMP", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "RA-5(1)", "levels": ["high", "moderate"], "notes": "The customer will be responsible for scanning customer applications\nand customer-deployed operating system images using compliant\nvulnerability scanning tools. A successful control response will need\nto address the specific tools used and the process required to\nupdate the list of information system vulnerabilities to be scanned\nfor each.", "title": "RA-5(1) - VULNERABILITY SCANNING | UPDATE TOOL CAPABILITY", "description": "The organization employs vulnerability scanning tools that include the capability to readily update the information system vulnerabilities to be scanned.\n\nSupplemental Guidance:  The vulnerabilities to be scanned need to be readily updated as new vulnerabilities are discovered, announced, and scanning methods developed. This updating process helps to ensure that potential vulnerabilities in the information system are identified and addressed as quickly as possible. Related controls: SI-3, SI-7.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "RA-5(2)", "levels": ["high", "moderate"], "notes": "The customer will be responsible for updating the list of\nvulnerabilities scanner prior to each scan. A successful control\nresponse will need to address the roles or personnel responsible for\nensuring that this requirement is met, as well as the process for\ninitiating a new scan if the required update does not occur.", "title": "RA-5(2) - VULNERABILITY SCANNING | UPDATE BY FREQUENCY / PRIOR TO NEW SCAN / WHEN IDENTIFIED", "description": "The organization updates the information system vulnerabilities scanned [Selection (one or more): [Assignment: organization-defined frequency]; prior to a new scan; when new vulnerabilities are identified and reported].\n\nSupplemental Guidance:  Related controls: SI-3, SI-5.\n\nRA-5 (2) [prior to a new scan]", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "RA-5(3)", "levels": ["high", "moderate"], "notes": "The customer will be responsible for ensuring that vulnerability\nscanning tools and procedures demonstrate the breadth and depth of\ncoverage. A successful control response will need to address the\nspecific tools in use and discuss the reason each tool is felt to\nprovide sufficient breadth and depth of coverage.", "title": "RA-5(3) - VULNERABILITY SCANNING | BREADTH / DEPTH OF COVERAGE", "description": "The organization employs vulnerability scanning procedures that can identify the breadth and depth of coverage (i.e., information system components scanned and vulnerabilities checked).", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "RA-5(5)", "levels": ["high", "moderate"], "notes": "The customer will be responsible for ensuring that scans of the\ncustomer environment include privileged access authorizations. A\nsuccessful control response will need to address how privileged\naccess authorizations are configured, as well as how successful\nauthorization is validated during the analysis of scan results.", "title": "RA-5(5) - VULNERABILITY SCANNING | PRIVILEGED ACCESS", "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]", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "RA-5(6)", "levels": ["high", "moderate"], "notes": "The customer will be responsible for using automated mechanisms to\nanalyze vulnerability scan results over time to determine trends. A\nsuccessful control response will need to discuss the mechanisms in use\nand the metrics employed in scan result analysis.", "title": "RA-5(6) - VULNERABILITY SCANNING | AUTOMATED TREND ANALYSES", "description": "The organization employs automated mechanisms to compare the results of vulnerability scans over time to determine trends in information system vulnerabilities.\n\nSupplemental Guidance:  Related controls: IR-4, IR-5, SI-4.\n\nRA-5 (6) Guidance: include in Continuous Monitoring ISSO digest/report to JAB/AO", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "RA-5(8)", "levels": ["high", "moderate"], "notes": "The customer will be responsible for reviewing historic audit logs to\ndetermine if a vulnerability identified in the information system\nhas been previously exploited. A successful control response will need\nto address the criteria used in analysis of audit logs to correlate log\ndata with vulnerability scan results.", "title": "RA-5(8) - VULNERABILITY SCANNING | REVIEW HISTORIC AUDIT LOGS", "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.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "SA-1", "levels": ["high", "moderate", "low"], "notes": "Section a: The organization will be responsible for developing, documenting, and\ndisseminating System and Services Acquisition policy and procedures. A\nsuccessful control response will need to address the content of the\npolicy (which must include purpose, scope, roles, responsibilities,\nmanagement commitment, coordination, and compliance) and procedures\n(which must facilitate the implementation of the policies and\nassociated controls).\nSection b: The organization will be responsible for reviewing and updating the Audit\nand Accountability policy every 3 years, and procedures annually. A\nsuccessful control response will need to address the review and update\nprocess, including the role(s) responsible for initiating the review\nprocess, updating the policy and procedures, and providing approval\nof the updates.", "title": "SA-1 - SYSTEM AND SERVICES ACQUISITION POLICY AND\nPROCEDURES", "description": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n   1. A system and services acquisition 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 services acquisition policy and associated system and services acquisition controls; and\n b. Reviews and updates the current:\n   1. System and services acquisition policy [Assignment: organization-defined frequency]; and\n   2.  System and services acquisition 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 SA family. Policy and procedures reflect applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance. Security program policies and procedures at the organization level may make the need for system-specific policies and procedures unnecessary. The policy can be included as part of the general information security policy for organizations or conversely, can be represented by multiple policies reflecting the complex nature of certain organizations. The procedures can be established for the security program in general and for particular information systems, if needed. The organizational risk management strategy is a key factor in establishing policy and procedures. Related control: PM-9.\n\nControl Enhancements:  None.\n\nReferences:  NIST Special Publications 800-12, 800-100.\n\nSA-1 (b) (1)  [at least annually]\nSA-1 (b) (2)  [at least annually or whenever a significant change occurs]", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "SA-2", "levels": ["high", "moderate", "low"], "notes": "Section a: The customer will be responsible for determining information security\nrequirements during mission/business process planning. A successful\ncontrol response will indicate how information security has been\nintegrated into mission/business planning.\nSection b: The customer will be responsible for determining, documenting, and\nallocating the resources required to protect the information system\nas part of capital planning and investment control processes. A\nsuccessful control response will indicate how information security\nhas been incorporated into financial planning processes.\nSection c: The customer will be responsible for establishing a discrete line\nitem for information security in organizational programming and\nbudgeting documentation. A successful control response will indicate\nhow information security is a stand-alone practice within the\norganization.", "title": "SA-2 - ALLOCATION OF RESOURCES", "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.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "SA-3", "levels": ["high", "moderate", "low"], "notes": "Section a: The customer will be responsible for managing the information system\nusing a Secure Development Lifecycle that incorporates information\nsecurity considerations. A successful control response will indicate\nhow information security requirements are part of project management\nplans.\nSection b: The customer will be responsible for defining and documenting\ninformation security roles and responsibilities throughout the\nsystem development lifecycle. A successful control response will\nindicate how information security roles are kept current during all\nstages of the information systems lifecycle.\nSection c: The customer will be responsible for identifying individuals\nthat have information security roles and responsibilities. A successful\ncontrol response will document these individuals, their\nresponsibilities, and how the organization keeps current this\ninformation.\nSection d: The customer will be responsible for integrating the organizational\ninformation security risk management process into system lifecycle. A\nsuccessful control response indicates how the organization follows the\nNIST Risk Management Framework, or an agency-specific derivative.", "title": "SA-3 - SYSTEM DEVELOPMENT LIFE CYCLE", "description": "The organization:\n a. Manages the information system using [Assignment: organization-defined system development life cycle] that incorporates information security considerations;\n b. Defines and documents information security roles and responsibilities throughout the system development life cycle;\n c. Identifies individuals having information security roles and responsibilities; and\n d. Integrates the organizational information security risk management process into system development life cycle activities.\n\nSupplemental Guidance:  A well-defined system development life cycle provides the foundation for the successful development, implementation, and operation of organizational information systems. To apply the required security controls within the system development life cycle requires a basic understanding of information security, threats, vulnerabilities, adverse impacts, and risk to critical missions/business functions. The security engineering principles in SA-8 cannot be properly applied if individuals that design, code, and test information systems and system components (including information technology products) do not understand security. Therefore, organizations include qualified personnel, for example, chief information security officers, security architects, security engineers, and information system security officers in system development life cycle activities to ensure that security requirements are incorporated into organizational information systems. It is equally important that developers include individuals on the development team that possess the requisite security expertise and skills to ensure that needed security capabilities are effectively integrated into the information system. Security awareness and training programs can help ensure that individuals having key security roles and responsibilities have the appropriate experience, skills, and expertise to conduct assigned system development life cycle activities. The effective integration of security requirements into enterprise architecture also helps to ensure that important security considerations are addressed early in the system development life cycle and that those considerations are directly related to the organizational mission/business processes. This process also facilitates the integration of the information security architecture into the enterprise architecture, consistent with organizational risk management and information security strategies. Related controls: AT-3, PM-7, SA-8.\n\nControl Enhancements:  None.\n\nReferences:  NIST Special Publications 800-37, 800-64.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "SA-4", "levels": ["high", "moderate", "low"], "notes": "Section a: The customer will be responsible for including security functional\nrequirements in acquisition contracts. A successful control response\nwill need to address consideration of applicable federal laws,\nExecutive Orders, directives, policies, regulations, standards,\nguidelines, and organizational mission/business needs in the creation\nof the contracts.\nSection b: The customer will be responsible for including security strength\nrequirements in acquisition contracts. A successful control response\nwill need to address consideration of applicable federal laws,\nExecutive Orders, directives, policies, regulations, standards,\nguidelines, and organizational mission/business needs in the creation\nof the contracts.\nSection c: The customer will be responsible for including security assurance\nrequirements in acquisition contracts. A successful control response\nwill need to address consideration of applicable federal laws,\nExecutive Orders, directives, policies, regulations, standards,\nguidelines, and organizational mission/business needs in the creation\nof the contracts.\nSection d: The customer will be responsible for including security-related\ndocumentation requirements in acquisition contracts. A successful control\nresponse will need to address consideration of applicable laws,\nExecutive Orders, directives, policies, regulations, standards,\nguidelines, and organizational mission/business needs in the creation\nof the contracts.\nSection e: The customer will be responsible for including requirements for\nprotecting security-related documentation in acquisition contracts. A\nsuccessful control response will need to address consideration of\napplicable laws, Executive Orders, directives, policies, regulations,\nstandards, guidelines, and organizational mission/business needs in the\ncreation of the contracts.\nSection f: The customer will be responsible for including a description of the\ninformation system development environment and in which the system\nis intended to operate in acquisition contracts. A successful control\nresponse will need to address consideration of applicable federal laws,\nExecutive Orders, directives, policies, regulations, standards,\nguidelines, and organizational mission/business needs in the creation\nof the contracts.\nSection g: The customer will be responsible for including acceptance criteria\nin acquisition contracts. A successful control response will need to\naddress consideration of applicable federal laws, Executive Orders,\ndirectives, policies, regulations, standards, guidelines, and\norganizational mission/business needs in the creation of the\ncontracts.", "title": "SA-4 - ACQUISITION PROCESS", "description": "The organization includes the following requirements, descriptions, and criteria, explicitly or by reference, in the acquisition contract for the information system, system component, or information system service in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, standards, guidelines, and organizational mission/business needs:\n  a. Security functional requirements;\n b. Security strength requirements;\n c. Security assurance requirements;\n d. Security-related documentation requirements;\n e. Requirements for protecting security-related documentation;\n f. Description of the information system development environment and environment in which the system is intended to operate; and\n g. Acceptance criteria.\n\nSupplemental Guidance:  Information system components are discrete, identifiable information technology assets (e.g., hardware, software, or firmware) that represent the building blocks of an information system. Information system components include commercial information technology products. Security functional requirements include security capabilities, security functions, and security mechanisms. Security strength requirements associated with such capabilities, functions, and mechanisms include degree of correctness, completeness, resistance to direct attack, and resistance to tampering or bypass. Security assurance requirements include: (i) development processes, procedures, practices, and methodologies; and (ii) evidence from development and assessment activities providing grounds for confidence that the required security functionality has been implemented and the required security strength has been achieved. Security documentation requirements address all phases of the system development life cycle.\n\nSecurity functionality, assurance, and documentation requirements are expressed in terms of security controls and control enhancements that have been selected through the tailoring process. The security control tailoring process includes, for example, the specification of parameter values through the use of assignment and selection statements and the specification of platform dependencies and implementation information. Security documentation provides user and administrator guidance regarding the implementation and operation of security controls. The level of detail required in security documentation is based on the security category or classification level of the information system and the degree to which organizations depend on the stated security capability, functions, or mechanisms to meet overall risk response expectations (as defined in the organizational risk management strategy). Security requirements can also include organizationally mandated configuration settings specifying allowed functions, ports, protocols, and services. Acceptance criteria for information systems, information system components, and information system services are defined in the same manner as such criteria for any organizational acquisition or procurement. The Federal Acquisition Regulation (FAR) Section 7.103 contains information security requirements from FISMA. Related controls: CM-6, PL-2, PS-7, SA-3, SA-5, SA-8, SA-11, SA-12.\n\nReferences: HSPD-12; ISO/IEC 15408; FIPS Publications 140-2, 201; NIST Special Publications 800-23, 800-35, 800-36, 800-37, 800-64, 800-70, 800-137; Federal Acquisition Regulation; Web: http://www.niap-ccevs.org, http://fips201ep.cio.gov, http://www.acquisition.gov/far.\n\nSA-4 Requirement: The service provider must comply with Federal Acquisition Regulation (FAR) Subpart 7.103, and Section 889 of the John S. McCain National Defense Authorization Act (NDAA) for Fiscal Year 2019 (Pub. L. 115-232), and FAR Subpart 4.21, which implements Section 889 (as well as any added updates related to FISMA to address security concerns in the system acquisitions process).\n\nSA-4 Guidance: The use of Common Criteria (ISO/IEC 15408) evaluated products is strongly preferred.\nSee https://www.niap-ccevs.org/Product/", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "SA-4(1)", "levels": ["high", "moderate"], "notes": "The customer will be responsible for requiring the developer of\nthe information system to provide a description of the functional\nproperties of the security controls to be employed. A successful\ncontrol response will address how this requirement is built into\nprocurement language.", "title": "SA-4(1) - ACQUISITION PROCESS | FUNCTIONAL PROPERTIES OF SECURITY CONTROLS", "description": "The organization requires the developer of the information system, system component, or information system service to provide a description of the functional properties of the security controls to be employed.\n\nSupplemental Guidance:  Functional properties of security controls describe the functionality (i.e., security capability, functions, or mechanisms) visible at the interfaces of the controls and specifically exclude functionality and data structures internal to the operation of the controls. Related control: SA-5.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "SA-4(2)", "levels": ["high", "moderate"], "notes": "The customer will be responsible for requiring the developer of the\ninformation system to provide design and implementation information\nfor the security controls to be employed that includes security-relevant\nexternal interfaces and high-level design. This information must be\nat a level of detail sufficient for secure deployment. A successful\ncontrol response will indicate address how this requirement is built\ninto procurement language.", "title": "SA-4(2) - ACQUISITION PROCESS | DESIGN / IMPLEMENTATION INFORMATION FOR SECURITY CONTROLS", "description": "The organization requires the developer of the information system, system component, or information system service to provide design and implementation information for the security controls to be employed that includes: [Selection (one or more): security-relevant external system interfaces; high-level design; low-level design; source code or hardware schematics; [Assignment: organization-defined design/implementation information]] at [Assignment: organization-defined level of detail].\n\nSupplemental Guidance:  Organizations may require different levels of detail in design and implementation documentation for security controls employed in organizational information systems, system components, or information system services based on mission/business requirements, requirements for trustworthiness/resiliency, and requirements for analysis and testing. Information systems can be partitioned into multiple subsystems. Each subsystem within the system can contain one or more modules. The high-level design for the system is expressed in terms of multiple subsystems and the interfaces between subsystems providing security-relevant functionality. The low-level design for the system is expressed in terms of modules with particular emphasis on software and firmware (but not excluding hardware) and the interfaces between modules providing security-relevant functionality. Source code and hardware schematics are typically referred to as the implementation representation of the information system. Related control: SA-5.\n\nSA-4 (2)-1 [at a minimum to include security-relevant external system interfaces; high-level design; low-level design; source code or network and data flow diagram; [organization-defined design/implementation information]]", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "SA-4(8)", "levels": ["high", "moderate"], "notes": "Customers are responsible for requiring the developer of\ncustomer-controlled software and operating systems to produce a plan\nfor continuous monitoring of security control effectiveness. A\nsuccessful control response will discuss the level of detail required\nby the customer as part of these continuous monitoring activities.", "title": "SA-4(8) - ACQUISITION PROCESS | CONTINUOUS MONITORING PLAN", "description": "The organization requires the developer of the information system, system component, or information system service to produce a plan for the continuous monitoring of security control effectiveness that contains [Assignment: organization-defined level of detail].\n\nSupplemental Guidance:  The objective of continuous monitoring plans is to determine if the complete set of planned, required, and deployed security controls within the information system, system component, or information system service continue to be effective over time based on the inevitable changes that occur. Developer continuous monitoring plans include a sufficient level of detail such that the information can be incorporated into the continuous monitoring strategies and programs implemented by organizations. Related control: CA-7.\n\nSA-4 (8) [at least the minimum requirement as defined in control CA-7]\nSA-4 (8) Guidance: CSP must use the same security standards regardless of where the system component or information system service is acquired.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "SA-4(9)", "levels": ["high", "moderate"], "notes": "Customers are responsible for requiring the developer of\ncustomer-controlled software and operating systems to identify required\nports, protocols, services and functions early in the development\nprocess. A successful control response will address the process by\nwhich this requirement is enforced.", "title": "SA-4(9) - ACQUISITION PROCESS | FUNCTIONS / PORTS / PROTOCOLS / SERVICES IN USE", "description": "The organization requires the developer of the information system, system component, or information system service to identify early in the system development life cycle, the functions, ports, protocols, and services intended for organizational use.\n\nSupplemental Guidance:  The identification of functions, ports, protocols, and services early in the system development life cycle (e.g., during the initial requirements definition and design phases) allows organizations to influence the design of the information system, information system component, or information system service. This early involvement in the life cycle helps organizations to avoid or minimize the use of functions, ports, protocols, or services that pose unnecessarily high risks and understand the trade-offs involved in blocking specific\nports, protocols, or services (or when requiring information system service providers to do so). Early identification of functions, ports, protocols, and services avoids costly retrofitting of security controls after the information system, system component, or information system service has been implemented. SA-9 describes requirements for external information system services with organizations identifying which functions, ports, protocols, and services are provided from external sources. Related controls: CM-7, SA-9.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "SA-4(10)", "levels": ["high", "moderate"], "notes": "The customer is responsible for employing only information\ntechnology products on the FIPS 201-approved products list for\nPersonal Identity Verification (PIV) capability implemented within\norganizational information systems. A successful control response will\nindicate that all system components have been selected from this list,\nand if not, document waivers with appropriate organizational authorities\nsignature.", "title": "SA-4(10) - ACQUISITION PROCESS | USE OF APPROVED PIV PRODUCTS", "description": "The organization employs only information technology products on the FIPS 201-approved products list for Personal Identity Verification (PIV) capability implemented within organizational information systems.\n\nSupplemental Guidance:  Related controls: IA-2; IA-8.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "SA-5", "levels": ["high", "moderate", "low"], "notes": "Section a: Customers are responsible for obtaining administrator documentation\nfor customer-controlled software and operating systems. A successful\ncontrol response will address the specific content requirements\noutlined in the control\nSection b: Customers are responsible for obtaining user documentation for\ncustomer-controlled software and operating systems. A successful control\nresponse will address the specific content requirements outlined in\nthe control.\nSection c: Customers are responsible for documenting attempts to obtain\nadministrator and user documentation for customer-controlled software\nand operating systems if that documentation is not available. A\nsuccessful control response will discuss the process by which attempts\nto obtain documentation are made as well as any additional actions\ntaken.\nSection d: Customers are responsible for protecting administrator and user\ndocumentation for customer-controlled software and operating systems.\nA successful control response will discuss how the safeguards are used\nin accordance with the organizations risk management strategy.\nSection e: Customers are responsible for distributing documentation for\ncustomer-controlled software and operating systems to appropriate\npersonnel. A successful control response will discuss the means\nof distribution and the process for designating appropriate personnel\nor roles.", "title": "SA-5 - INFORMATION SYSTEM DOCUMENTATION", "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)]", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "SA-8", "levels": ["high", "moderate"], "notes": "Customers are responsible for embedding secure system development\nlifecycle principles in the specification, design, development,\nimplementation, and modification of the system. A successful control\nresponse will discuss the processes followed.", "title": "SA-8 - SECURITY ENGINEERING PRINCIPLES", "description": "The organization applies information system security engineering principles in the specification, design, development, implementation, and modification of the information system.\n\nSupplemental Guidance:  Organizations apply security engineering principles primarily to new development information systems or systems undergoing major upgrades. For legacy systems, organizations apply security engineering principles to system upgrades and modifications to the extent feasible, given the current state of hardware, software, and firmware within those systems. Security engineering principles include, for example: (i) developing layered protections; (ii) establishing sound security policy, architecture, and controls as the foundation for design; (iii) incorporating security requirements into the system development life cycle; (iv) delineating physical and logical security boundaries; (v) ensuring that system developers are trained on how to build secure software; (vi) tailoring security controls to meet organizational and operational needs; (vii) performing threat modeling to identify use cases, threat agents, attack vectors, and attack patterns as well as compensating controls and design patterns needed to mitigate risk; and (viii) reducing risk to acceptable levels, thus enabling informed risk management decisions. Related controls: PM-7, SA-3, SA-4, SA-17, SC-2, SC-3.\n\nControl Enhancements:  None.\n\nReferences:  NIST Special Publication 800-27.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "SA-9", "levels": ["high", "moderate", "low"], "notes": "Section a: Customers are responsible to require that external information systems\ncomply with organizational security requirements and FedRAMP\nSecurity Controls Baseline(s) if Federal information is processed or\nstored within the external system. A successful control response will\nindicate how this is enforced, procedurally and technically, for\nexternal information systems.\nSection b: Customers are responsible for defining and documenting government\noversight and user roles and responsibilities regarding external\ninformation system services. A successful control response will address\nthe procedures for this oversight.\nSection c: Customers are responsible for employing Federal/FedRAMP Continuous\nMonitoring Requirements on external systems where Federal information\nis processed or stored, and monitor security control compliance by\nexternal service providers on an ongoing basis. A successful control\nresponse will address the procedural and technical processes used to\naccomplish this.", "title": "SA-9 - EXTERNAL INFORMATION SYSTEM SERVICES", "description": "The organization:\n a. Requires that providers of external information system services comply with organizational information security requirements and employ [Assignment: organization-defined security controls] in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance;\n b. Defines and documents government oversight and user roles and responsibilities with regard to external information system services; and\n c. Employs [Assignment: organization-defined processes, methods, and techniques] to monitor security control compliance by external service providers on an ongoing basis.\n\nSupplemental Guidance:  External information system services are services that are implemented outside of the authorization boundaries of organizational information systems. This includes services that are used by, but not a part of, organizational information systems. FISMA and OMB policy require that organizations using external service providers that are processing, storing, or transmitting federal information or operating information systems on behalf of the federal government ensure that such providers meet the same security requirements that federal agencies are required to meet. Organizations establish relationships with external service providers in a variety of ways including, for example, through joint ventures, business partnerships, contracts, interagency agreements, lines of business arrangements, licensing agreements, and supply chain exchanges. The responsibility for managing risks from the use of external information system services remains with authorizing officials. For services external to organizations, a chain of trust requires that organizations establish and retain a level of confidence that each participating provider in the potentially complex consumer-provider relationship provides adequate protection for the services rendered. The extent and nature of this chain of trust varies based on the relationships between organizations and the external providers. Organizations document the basis for trust relationships so the relationships can be monitored over time. External information system services documentation includes government, service providers, end user security roles and responsibilities, and service-level agreements. Service-level agreements define expectations of performance for security controls, describe measurable outcomes, and identify remedies and response requirements for identified instances of noncompliance. Related controls: CA-3, IR-7, PS-7.\n\nReferences: NIST Special Publication 800-35.\n\nSA-9 (a) [FedRAMP Security Controls Baseline(s) if Federal information is processed or stored within the external system]\nSA-9 (c) [Federal/FedRAMP Continuous Monitoring requirements must be met for external systems where Federal information is processed or stored]", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "SA-9(1)", "levels": ["high", "moderate"], "notes": "Section a: Customers are responsible for conducting organizational assessment\nof risk prior to the acquisition or outsourcing of dedicated\ninformation security services. A successful control response will\naddress the process of the risk assessment and analysis of findings.\nSection b: Customers are responsible for ensuring that the acquisition or\noutsourcing of dedicated information security services is approved\nby organizational authorities. A successful control response will\naddress formal approval processes.", "title": "SA-9(1) - EXTERNAL INFORMATION SYSTEMS | RISK ASSESSMENTS /\nORGANIZATIONAL APPROVALS", "description": "The organization:\n (a)   Conducts an organizational assessment of risk prior to the acquisition or outsourcing of dedicated information security services; and\n (b)   Ensures that the acquisition or outsourcing of dedicated information security services is approved by [Assignment: organization-defined personnel or roles].\n\nSupplemental Guidance:  Dedicated information security services include, for example, incident monitoring, analysis and response, operation of information security-related devices such as firewalls, or key management services. Related controls: CA-6, RA-3.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "SA-9(2)", "levels": ["high", "moderate"], "notes": "Customers are responsible for requiring providers of all external\ninformation systems where Federal information is processed or stored\nto identify the functions, ports, protocols, and other services\nrequired for the use of such services. A successful control response\nwill indicate this requirement in contracting language.", "title": "SA-9(2) - EXTERNAL INFORMATION SYSTEMS | IDENTIFICATION OF FUNCTIONS / PORTS / PROTOCOLS / SERVICES", "description": "The organization requires providers of [Assignment: organization-defined external information system services] to identify the functions, ports, protocols, and other services required for the use of such services.\n\nSupplemental Guidance:  Information from external service providers regarding the specific functions, ports, protocols, and services used in the provision of such services can be particularly useful when the need arises to understand the trade-offs involved in restricting certain functions/services or blocking certain ports/protocols. Related control: CM-7.\n\nSA-9 (2) [all external systems where Federal information is processed or stored]", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "SA-9(4)", "levels": ["high", "moderate"], "notes": "Customers are responsible for employing FedRAMP security requirements\nto ensure the interests of all external systems where Federal\ninformation is processed or stored is consistent with and reflect\norganizational interests. A successful control response will discuss\nhow FedRAMP security requirements are enforced in external systems.", "title": "SA-9(4) - EXTERNAL INFORMATION SYSTEMS | CONSISTENT INTERESTS OF CONSUMERS AND PROVIDERS", "description": "The organization employs [Assignment: organization-defined security safeguards] to ensure that the interests of [Assignment: organization-defined external service providers] are consistent with and reflect organizational interests.\n\nSupplemental Guidance:  As organizations increasingly use external service providers, the possibility exists that the interests of the service providers may diverge from organizational interests. In such situations, simply having the correct technical, procedural, or operational safeguards in place may not be sufficient if the service providers that implement and control those safeguards are not operating in a manner consistent with the interests of the consuming organizations. Possible actions that organizations might take to address such concerns include, for example, requiring background checks for selected service provider personnel, examining ownership records, employing only trustworthy service providers (i.e., providers with which organizations have had positive experiences), and conducting periodic/unscheduled visits to service provider facilities.\n\nSA-9 (4)-2 [all external systems where Federal information is processed or stored]", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "SA-9(5)", "levels": ["high", "moderate"], "notes": "Customers are responsible for restricting the location of information\nprocessing, information data, and information services, to\ncontinental United States datacenters based on business requirements.", "title": "SA-9(5) - EXTERNAL INFORMATION SYSTEMS | PROCESSING, STORAGE, AND SERVICE LOCATION", "description": "The organization restricts the location of [Selection (one or more): information processing; information/data; information system services] to [Assignment: organization-defined locations] based on [Assignment: organization-defined requirements or conditions].\n\nSupplemental Guidance:  The location of information processing, information/data storage, or information system services that are critical to organizations can have a direct impact on the ability of those organizations to successfully execute their missions/business functions. This situation exists when external providers control the location of processing, storage or services. The criteria external providers use for the selection of processing, storage, or service locations may be different from organizational criteria. For example, organizations may want to ensure that data/information storage locations are restricted to certain locations to facilitate incident response activities (e.g., forensic analyses, after-the-fact investigations) in case of information security breaches/compromises. Such incident response activities may be adversely affected\nby the governing laws or protocols in the locations where processing and storage occur and/or the locations from which information system services emanate.\n\nSA-9 (5)-1 [information processing, information data, AND information services]\nSA-9 (5)-2 [U.S./U.S. Territories or geographic locations where there is U.S. jurisdiction]\nSA-9 (5)-3 [all High impact data, systems, or services]", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "SC-1", "levels": ["high", "moderate", "low"], "notes": "Section a: The organization will be responsible for developing, documenting, and\ndisseminating System and Communications Protection policy and\nprocedures. A successful control response will need to address the\ncontent of the policy (which must include purpose, scope, roles,\nresponsibilities, management commitment, coordination, and\ncompliance) and procedures (which must facilitate the implementation\nof the policies and associated controls).\nSection b: The organization will be responsible for reviewing and updating the System\nand Communications Protection policy every 3 years, and procedures\nannually. A successful control response will need to address the\nreview and update process, including the role(s) responsible for\ninitiating the review process, updating the policy and procedures,\nand providing approval of the updates.", "title": "SC-1 - SYSTEM AND COMMUNICATIONS PROTECTION\nPOLICY AND PROCEDURES", "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]", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "SC-5", "levels": ["high", "moderate", "low"], "notes": "The customer is responsible for protecting against or limiting\nthe effects of attacks on bandwidth, attacks on transactional\ncapacity, attacks on storage capacity by employing geo-replication,\nIP address blocking, network-based DDos protections. A successful\ncontrol response will discuss how the information system is protected\nfrom these attacks.", "title": "SC-5 - DENIAL OF SERVICE PROTECTION", "description": "The information system protects against or limits the effects of the following types of denial of service attacks: [Assignment: organization-defined types of denial of service attacks or reference to source for such information] by employing [Assignment: organization-defined security safeguards].\n\nSupplemental Guidance:  A variety of technologies exist to limit, or in some cases, eliminate the effects of denial of service attacks. For example, boundary protection devices can filter certain types of packets to protect information system components on internal organizational networks from being directly affected by denial of service attacks. Employing increased capacity and bandwidth combined with service redundancy may also reduce the susceptibility to denial of service attacks. Related controls: SC-6, SC-7.\n\nReferences: None.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "SC-12(2)", "levels": ["high", "moderate"], "notes": "The customer will be responsible for producing, controlling, and\ndistributing symmetric cryptographic keys (if any are used within\nthe customer application) using NIST FIPS-compliant key management\ntechnology and processes. A successful control response will need to\naddress the processes and tools used for key generation and discuss\nthe reasons they are considered compliant.", "title": "SC-12(2) - CRYPTOGRAPHIC KEY ESTABLISHMENT AND MANAGEMENT |\nSYMMETRIC KEYS", "description": "The organization produces, controls, and distributes symmetric cryptographic keys using [Selection: NIST FIPS-compliant; NSA-approved] key management technology and processes.\n\nSC-12 (2) [NIST FIPS-compliant]", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "SC-12(3)", "levels": ["high", "moderate"], "notes": "The customer will be responsible for producing, controlling, and\ndistributing asymmetric cryptographic keys (if any are used within the\ncustomer application) using one of the specified tools or processes. A\nsuccessful control response will need to address the process and tools\nused for key generation and discuss the reasons they are considered\ncompliant.", "title": "SC-12(3) - CRYPTOGRAPHIC KEY ESTABLISHMENT AND MANAGEMENT |\nASYMMETRIC KEYS", "description": "The organization produces, controls, and distributes asymmetric cryptographic keys using [Selection: NSA-approved key management technology and processes; approved PKI Class 3 certificates or prepositioned keying material; approved PKI Class 3 or Class 4 certificates and hardware security tokens that protect the user\u2019s private key].", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "SC-15", "levels": ["high", "moderate", "low"], "notes": "Section a: The customer will be responsible for prohibiting remote activation\nof any collaborative computing devices within or controlled from\nthe customer application.\nSection b: The customer will be responsible for providing an explicit indication\nof use of any collaborative computing devices within or controlled\nfrom the customer application. A successful control response will\nneed to address how this explicit indication is enabled, the form\nit takes, and the means by which activation can be verified.\nSection Req. 1: The customer will be responsible for providing easy to use\nfunctionality to disable any collaborative computing devices within\nor controlled from the customer application.", "title": "SC-15 - COLLABORATIVE COMPUTING DEVICES", "description": "The information system:\n a. Prohibits remote activation of collaborative computing devices with the following exceptions: [Assignment: organization-defined exceptions where remote activation is to be allowed]; and\n b. Provides an explicit indication of use to users physically present at the devices.\n\nSupplemental Guidance:  Collaborative computing devices include, for example, networked white boards, cameras, and microphones. Explicit indication of use includes, for example, signals to users when collaborative computing devices are activated. Related control: AC-21.\n\nReferences: None.\n\nSC-15 (a) [no exceptions]\nSC-15 Requirement: The information system provides disablement (instead of physical disconnect) of collaborative computing devices in a manner that supports ease of use.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "SC-17", "levels": ["high", "moderate"], "notes": "The organization will be responsible for defining and enforcing a\npolicy for issuing public key certificates, or else to obtain\npublic key certificates from an approved service provider. A\nsuccessful control response will need to outline the policy and\naddress the mechanism by which the policy is enforced, or else\ndiscuss the approved service provider and the process by which\ncertificates are obtained.", "title": "SC-17 - PUBLIC KEY INFRASTRUCTURE CERTIFICATES", "description": "The organization issues public key certificates under an [Assignment: organization- defined certificate policy] or obtains public key certificates from an approved service provider.\n\nSupplemental Guidance:  For all certificates, organizations manage information system trust stores to ensure only approved trust anchors are in the trust stores. This control addresses both certificates with visibility external to organizational information systems and certificates related to the internal operations of systems, for example, application-specific time services. Related control: SC-12.\n\nControl Enhancements:  None.\n\nReferences:  OMB Memorandum 05-24; NIST Special Publications 800-32, 800-63.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "SC-18", "levels": ["high", "moderate"], "notes": "Section a: Mobile code is code that is downloaded and executed by the client\nmachine, rather than on the remote host. The customer will be\nresponsible for defining mobile code technologies as acceptable or\nunacceptable for use within the system.\nSection b: The customer will be responsible for defining usage restrictions\nand implementation guidance for acceptable mobile code and mobile\ncode technologies.", "title": "SC-18 - MOBILE CODE", "description": "The organization:\n a. Defines acceptable and unacceptable mobile code and mobile code technologies;\n b. Establishes usage restrictions and implementation guidance for acceptable mobile code and mobile code technologies; and\n c. Authorizes, monitors, and controls the use of mobile code within the information system.\n\nSupplemental Guidance:  Decisions regarding the employment of mobile code within organizational information systems are based on the potential for the code to cause damage to the systems if used maliciously. Mobile code technologies include, for example, Java, JavaScript, ActiveX, Postscript, PDF, Shockwave movies, Flash animations, and VBScript. Usage restrictions and implementation guidance apply to both the selection and use of mobile code installed on servers and mobile code downloaded and executed on individual workstations and devices (e.g., smart phones). Mobile code policy and procedures address preventing the development, acquisition, or introduction of unacceptable mobile code within organizational information systems. Related controls: AU-2, AU-12, CM-2, CM-6, SI-3.\n\nReferences: NIST Special Publication 800-28; DoD Instruction 8552.01.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "SC-19", "levels": ["high", "moderate"], "notes": "Section a: The customer will be responsible for establishing usage restrictions\nand implementation guidance for the use of VoIP technologies within\nthe customer application. A successful control response will need\nto address whether and how VoIP technologies are used and outline\nthe conditions under which that usage is appropriate.", "title": "SC-19 - VOICE OVER INTERNET PROTOCOL", "description": "The organization:\n a. Establishes usage restrictions and implementation guidance for Voice over Internet Protocol (VoIP) technologies based on the potential to cause damage to the information system if used maliciously; and\n b. Authorizes, monitors, and controls the use of VoIP within the information system.\n\nSupplemental Guidance:  Related controls: CM-6, SC-7, SC-15.\n\nReferences:  NIST Special Publication 800-58.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "SI-1", "levels": ["high", "moderate", "low"], "notes": "Section a: The organization will be responsible for developing, documenting, and\ndisseminating System and Information Integrity policy and procedures. A\nsuccessful control response will need to address the content of the\npolicy (which must include purpose, scope, roles, responsibilities,\nmanagement commitment, coordination, and compliance) and procedures\n(which must facilitate the implementation of the policies and\nassociated controls).\nSection b: The organization will be responsible for reviewing and updating the\nSystem and Information Integrity policy every 3 years, and procedures\nannually. A successful control response will need to address the\nreview and update process, including the role(s) responsible for\ninitiating the review process, updating the policy and procedures,\nand providing approval of the updates.", "title": "SI-1 - SYSTEM AND INFORMATION INTEGRITY POLICY AND\nPROCEDURES", "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]", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "SI-5", "levels": ["high", "moderate", "low"], "notes": "Section b: The organization will be responsible for generating internal security\nalerts, advisories and directives. A successful control response will\nneed to address the criteria used to determine what alerts, advisories,\nand directives are necessary, based on the specifics of the customer\nmission, software, or service.\nSection c: The organization will be responsible for disseminating security alerts,\nadvisories and directives within the customer organization and to\nexternal organizations as necessary. A successful control response will\nneed to address the personnel or roles within the organization who\nrequire notification.", "title": "SI-5 - SECURITY ALERTS, ADVISORIES, AND DIRECTIVES", "description": "The organization:\n a. Receives information system security alerts, advisories, and directives from [Assignment: organization-defined external organizations] on an ongoing basis;\n b. Generates internal security alerts, advisories, and directives as deemed necessary;\n c. Disseminates security alerts, advisories, and directives to: [Selection (one or more): [Assignment: organization-defined personnel or roles]; [Assignment: organization-defined elements within the organization]; [Assignment: organization-defined external organizations]]; and\n d. Implements security directives in accordance with established time frames, or notifies the issuing organization of the degree of noncompliance.\n\nSupplemental Guidance:  The United States Computer Emergency Readiness Team (US-CERT) generates security alerts and advisories to maintain situational awareness across the federal government. Security directives are issued by OMB or other designated organizations with the responsibility and authority to issue such directives. Compliance to security directives is essential due to the critical nature of many of these directives and the potential immediate adverse effects\non organizational operations and assets, individuals, other organizations, and the Nation should the directives not be implemented in a timely manner. External organizations include, for example, external mission/business partners, supply chain partners, external service providers, and other peer/supporting organizations. Related control: SI-2.\n\nReferences: NIST Special Publication 800-40.\n\nSI-5 (a) [to include US-CERT]\nSI-5 (c) [to include system security personnel and administrators with configuration/patch-management responsibilities]", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "SI-8", "levels": ["high", "moderate"], "notes": "Section a: The organization will be responsible for employing spam protection\nmechanisms at organizational information system entry and exit points\nto detect and take action on unsolicited messages. A successful\ncontrol response will need to address how the organization deploys\nspam protection.\nSection b: The organization will be responsible for updating spam protection\nmechanisms when new releases are available in accordance with\norganizational configuration management policy and procedures. A\nsuccessful control response will describe the organizations process\nto ensure spam protection mechanisms are updated.", "title": "SI-8 - SPAM PROTECTION", "description": "The organization:\n a. Employs spam protection mechanisms at information system entry and exit points to detect and take action on unsolicited messages; and\n b. Updates spam protection mechanisms when new releases are available in accordance with organizational configuration management policy and procedures.\n\nSupplemental Guidance:  Information system entry and exit points include, for example, firewalls, electronic mail servers, web servers, proxy servers, remote-access servers, workstations, mobile devices, and notebook/laptop computers. Spam can be transported by different means including, for example, electronic mail, electronic mail attachments, and web accesses. Spam protection mechanisms include, for example, signature definitions. Related controls: AT-2, AT-3, SC-5, SC-7, SI-3.\n\nReferences: NIST Special Publication 800-45.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "SI-8(1)", "levels": ["high", "moderate"], "notes": "The organization is responsible for centrally managing spam protection\nmechanisms. A successful control response will indicate how spam\nprotection is provided as a corporate service, and when applicable,\nhow spam protection content is disseminated to subordinate mail\nservers.", "title": "SI-8(1) - SPAM PROTECTION | CENTRAL MANAGEMENT", "description": "The organization centrally manages spam protection mechanisms.\n\nSupplemental Guidance:  Central management is the organization-wide management and implementation of spam protection mechanisms. Central management includes planning, implementing, assessing, authorizing, and monitoring the organization-defined, centrally managed spam protection security controls. Related controls: AU-3, SI-2, SI-7.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "SI-8(2)", "levels": ["high", "moderate"], "notes": "The organization is responsible for automatic updates to spam\nprotection mechanisms. A successful control response will indicate\nhow automatic updates are performed, both for protection mechanisms\nand filtering content.", "title": "SI-8(2) - SPAM PROTECTION | AUTOMATIC UPDATES", "description": "The information system automatically updates spam protection mechanisms.", "rationale": null, "automated": "no", "status": "pending", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}], "levels": [{"id": "low", "inherits_from": null}, {"id": "moderate", "inherits_from": null}, {"id": "high", "inherits_from": null}]}