Loading...
background

FedRAMP - Medium

FedRAMP - Medium

FedRAMP - Medium

FedRAMP stands for Federal Risk and Authorization Management Program. It's a government program that helps federal agencies use cloud services securely.

Controls:

FedRAMP's Access Control (AC) ensures secure user access by enforcing authentication, authorization, least privilege, and session management to protect federal systems from unauthorized access and data breaches.

  • Policy and Procedures

    The AC-1 control under FedRAMP mandates that an organization establishes, documents, and disseminates an access control policy and associated procedures. This control is foundational and provides a framework for managing user access to systems and data, thereby ensuring security and compliance.

  • Account Management

    The AC-2 control within FedRAMP addresses the establishment, implementation, and enforcement of account management practices to support secure access. It requires organizations to identify, manage, and monitor user accounts, including those of employees, contractors, and other authorized entities. AC-2 also covers account authorization, activation, deactivation, and periodic review to prevent unauthorized access.

  • Account Management | Automated System Account Management

    The AC-2 (1) control enhancement requires organizations to implement automated mechanisms to manage system accounts. This includes creating, enabling, modifying, disabling, and removing accounts in a controlled and consistent manner. Automation helps reduce human error, improve efficiency, and strengthen security by ensuring that account management tasks are performed promptly and accurately.

  • Account Management | Automated Temporary and Emergency Account Management

    The AC-2 (2) control enhancement mandates that organizations implement automated mechanisms for the creation, monitoring, and termination of temporary and emergency accounts. These accounts are intended for short-term use, allowing for quick access in specific, time-bound scenarios, such as emergency maintenance or temporary project work. The control ensures these accounts are strictly managed and promptly deactivated to prevent unauthorized or prolonged access.

  • Account Management | Disable Accounts

    The AC-2 (3) control enhancement requires organizations to implement mechanisms for promptly disabling accounts when they are no longer needed. This control aims to ensure that only active and authorized users retain access to the system, reducing the risk of unauthorized access due to unused or forgotten accounts.

  • Account Management | Automated Audit Actions

    The AC-2 (4) control enhancement requires organizations to automate the process of auditing account management actions, including account creation, modification, deletion, and disabling. Automation of audit actions helps ensure that these critical activities are consistently logged, reviewed, and analyzed for compliance and security purposes. This control aims to strengthen accountability and reduce the likelihood of unauthorized or improperly managed account activities.

  • Account Management | Inactivity Logout

    The AC-2 (5) control enhancement requires organizations to implement automated mechanisms that log out users after a predetermined period of inactivity. This ensures that inactive sessions are terminated, preventing unauthorized access that could occur if a user leaves their session open or unattended. The goal is to minimize the window of opportunity for attackers to hijack inactive sessions and gain access to sensitive systems.

  • Account Management | Privileged User Accounts

    The AC-2 (7) control enhancement requires organizations to implement specific measures for managing privileged user accounts, which have elevated access permissions compared to regular user accounts. These privileged accounts often have broad system or administrative access, making them prime targets for malicious actors. Therefore, it’s essential to enforce strict controls, monitoring, and auditing of privileged accounts to reduce the risk of misuse or unauthorized access.

  • Account Management | Restrictions on Use of Shared and Group Accounts

    The AC-2 (9) control enhancement focuses on implementing restrictions on the use of shared and group accounts to ensure they are not misused or improperly managed. Shared and group accounts are those accounts where multiple users have access to the same credentials, which can complicate accountability and security monitoring. This control mandates that such accounts should be tightly controlled, with access limited and monitored to prevent unauthorized use.

  • Account Management | Account Monitoring for Atypical Usage

    The AC-2 (12) control enhancement requires organizations to monitor user account activity for atypical or unusual behavior that could indicate potential security incidents, such as unauthorized access, misuse, or compromised accounts. This includes monitoring account usage for actions that deviate from established baselines or expected patterns. The goal is to detect and respond to suspicious behavior promptly, reducing the risk of security breaches, data theft, or other unauthorized activities.

  • Account Management | Disable Accounts for High-risk Individuals

    The AC-2 (13) control enhancement requires organizations to disable accounts for individuals identified as high-risk, such as employees who are terminated, those under investigation, or those whose actions present a potential security threat. Disabling accounts for high-risk individuals prevents unauthorized access to sensitive systems and data, reducing the likelihood of data breaches or insider threats. This control ensures that organizations can respond swiftly to any situation where a user’s access might compromise the security of the system

  • Access Enforcement

    AC-3 requires organizations to enforce access control policies, ensuring that only authorized users, processes, or devices can access systems and resources. It involves implementing measures to enforce the appropriate level of access based on predefined access policies, ensuring that access rights are applied consistently and accurately. Access enforcement mechanisms prevent unauthorized access, misuse of data, and reduce the risk of security breaches by ensuring that the right individuals have the right level of access.

  • Information Flow Enforcement

    AC-4 requires organizations to enforce policies that regulate the flow of information within and between systems. This control ensures that information flows in accordance with defined security policies, preventing unauthorized information transmission or leakage. It encompasses mechanisms to monitor, control, and restrict the movement of information across networks, systems, or boundaries, ensuring that only authorized parties have access to specific information. Information flow enforcement is critical for protecting sensitive data and preventing data breaches, leaks, or unauthorized sharing of information.

  • Information Flow Enforcement | Physical or Logical Separation of Information Flows

    AC-4 (21) requires organizations to implement mechanisms that separate information flows either physically or logically. This subcontrol ensures that sensitive or classified information is kept segregated from other types of data, preventing unauthorized access, leakage, or unintended sharing of information. The separation of data can be achieved using physical isolation (e.g., separate networks, isolated systems) or logical separation (e.g., access control policies, firewalls, and network segmentation). The goal is to ensure that information flows are managed in such a way that unauthorized access or interception is prevented, and sensitive data is protected throughout its lifecycle.

  • Separation of Duties

    AC-5 requires organizations to implement a separation of duties (SoD) policy to ensure that no individual is assigned responsibilities that would allow them to both perform and approve critical activities. This subcontrol helps mitigate the risks of fraud, error, or malicious activities by dividing critical tasks among different individuals or systems. The goal is to ensure that key processes, such as authorizing transactions, making changes to systems, and reviewing activities, are carried out by different individuals, creating a system of checks and balances that prevents a single person from being in a position to both cause and conceal wrongdoing.

  • Least Privilege

    AC-6 requires that organizations limit users’ access rights and privileges to the minimum necessary for them to perform their job functions. The principle of least privilege (PoLP) reduces the attack surface by ensuring users only have access to the specific systems, data, and resources necessary to complete their tasks, minimizing the potential damage caused by a compromised account or malicious activity. This subcontrol also extends to administrative privileges, ensuring that these are only granted to those who absolutely need them.

  • Least Privilege | Authorize Access to Security Functions

    AC-6 (1) extends the least privilege principle to the access control over security functions. This subcontrol requires that access to security-relevant functions (e.g., configuration management, monitoring, auditing, security policies, and controls) be strictly limited to authorized users with a legitimate need to access such functions. Security functions typically require high levels of trust and oversight, so the principle of least privilege ensures that only necessary personnel have the permissions to modify, access, or control security features. By restricting access to security functions, organizations reduce the risk of malicious alterations or unauthorized changes to security controls.

  • Least Privilege | Non-privileged Access for Nonsecurity Functions

    AC-6 (2) mandates that users be granted non-privileged access to systems and data, only for non-security functions they need to perform their duties. This ensures that users are restricted from gaining unnecessary elevated access to resources and systems that do not require high-level privileges for their tasks. Nonsecurity functions are typically tasks such as using general applications or accessing databases for business purposes, where the principle of least privilege dictates that users should not be granted unnecessary or excessive permissions.

    This subcontrol applies to limiting administrative or security-related access when users perform day-to-day tasks that don't require the ability to configure security settings, manage user permissions, or access critical system functions. By restricting non-privileged users from accessing higher-level functionalities, an organization can reduce the risk of unauthorized or unintentional alterations to systems or data.

  • Least Privilege | Privileged Accounts

    AC-6 (5) focuses on the management and control of privileged accounts within an organization. Privileged accounts are those that have elevated access rights, such as system administrators, root users, or other accounts with capabilities to modify system settings, install software, access sensitive data, or perform administrative functions. This subcontrol emphasizes the need to restrict, monitor, and manage privileged accounts carefully to prevent unauthorized access and reduce the risk of misuse.

    Privileged accounts are highly valuable targets for attackers, as gaining access to them could provide the attacker with the ability to compromise systems or escalate privileges. Therefore, organizations must follow strict access control procedures to limit the creation, use, and management of privileged accounts.

  • Least Privilege | Review of User Privileges

    AC-6 (7) mandates that an organization must regularly review and validate the user privileges associated with each user account to ensure they are consistent with the principle of least privilege. This process aims to ensure that users only retain the access rights they need to perform their job functions and that any unnecessary privileges are revoked promptly.

    Periodic reviews of user privileges are critical for maintaining a secure environment, as over-privileged accounts can be targeted by attackers to gain unauthorized access. These reviews should cover all types of user accounts, including those with administrative, system, and application-level access. Regularly reviewing user privileges helps to minimize the attack surface by preventing privilege creep, where users accumulate unnecessary privileges over time due to role changes or system modifications.

  • Least Privilege | Log Use of Privileged Functions

    AC-6 (9) mandates that the use of privileged functions within systems and applications must be logged for audit and monitoring purposes. This includes actions performed by users with elevated privileges (such as administrators, root users, or system-level accounts) that have access to critical system configurations, sensitive data, or security functions. Logging these activities ensures that any use of privileged functions can be reviewed for compliance, security violations, or misuse.

    Logs should capture relevant details, including the identity of the user performing the action, the timestamp of the activity, the function being executed, and the system or resource being affected. This data is critical for detecting malicious or unauthorized activities, ensuring accountability, and supporting forensic investigations when incidents occur.

  • Least Privilege | Prohibit Non-privileged Users from Executing Privileged Functions

    AC-6 (10) requires that non-privileged users be explicitly prohibited from executing privileged functions. Privileged functions are typically actions or tasks that can significantly impact the security, configuration, or operation of systems or networks, such as system administration tasks, access to sensitive data, or the ability to configure security settings.

    This control is designed to ensure that only users with the appropriate level of authorization and privileges can perform such actions, thereby reducing the risk of accidental or intentional misuse by users who lack the necessary clearance or expertise. The goal is to prevent unauthorized users from executing commands or functions that could compromise system integrity, lead to security vulnerabilities, or disrupt critical system operations.

  • Unsuccessful Logon Attempts

    AC-7 mandates that organizations must control and respond to unsuccessful logon attempts to protect systems and data from unauthorized access. This control requires monitoring and limiting the number of consecutive unsuccessful logon attempts by users. The objective is to mitigate the risk of brute force attacks and other attempts to guess user credentials.

    This subcontrol typically involves automatic actions such as locking accounts or triggering alerts after a certain number of failed logon attempts. By enforcing these restrictions, organizations can reduce the likelihood of unauthorized users gaining access to systems through credential guessing, while also maintaining accountability for legitimate users.

  • System Use Notification

    AC-8 requires that organizations display a system use notification that informs users of the authorized use of the system and any monitoring or auditing that will occur during their session. This notification must appear at the start of a user session or when users access a system. The notification serves as a reminder that the system is monitored and that any activity may be recorded, ensuring users are aware of the organization's access policies and procedures.

    The objective of this control is to increase transparency and accountability by ensuring users are informed that their actions on the system are subject to monitoring, which helps deter inappropriate or unauthorized use.

  • Device Lock

    AC-11 requires that organizations implement a device lock mechanism to secure end-user devices by automatically locking them after a defined period of inactivity. This mechanism ensures that sensitive information on devices, such as laptops, mobile devices, or workstations, is not exposed to unauthorized access when the user is away. It helps protect against potential unauthorized access to systems, applications, or data if a device is left unattended in an unsecured location.

    The device lock typically takes the form of a screen lock, password prompt, or other access-control mechanisms that require user authentication to regain access to the device after a period of inactivity.

  • Device Lock | Pattern-hiding Displays

    AC-11 (1) requires that organizations implement pattern-hiding displays on devices to protect sensitive information from being exposed in plain sight when a device is locked or when it is not actively being used. A pattern-hiding display is a security feature that prevents sensitive information, such as user credentials, system data, or other private details, from being visible on the screen when the device is inactive or locked.

    For example, rather than displaying the last active screen, the device could either show a blank screen, a screen saver, or a placeholder, making it harder for unauthorized individuals to gather sensitive information by simply looking at the screen.

    This control is especially important in environments where users work with sensitive or classified data, and it minimizes the potential for shoulder surfing or visual data leaks in public or semi-public spaces.

  • Session Termination

    AC-12 mandates that organizations establish and enforce mechanisms to terminate sessions after a defined period of inactivity or upon request. Session termination refers to the process of ending an active user session on a system, application, or device. This helps to prevent unauthorized access to sensitive information by ensuring that sessions are properly closed when no longer in use or when they are idle for a defined period of time.

    The goal of this control is to mitigate the risks of session hijacking, unauthorized access, or inadvertent exposure of sensitive data, especially when a user walks away from a device or leaves an application running unattended.

  • Permitted Actions Without Identification or Authentication

    AC-14 specifies that an organization must define and control the actions that users or systems can perform without identification or authentication. The goal of this control is to minimize the risk of unauthorized access by ensuring that only appropriate, limited, and non-sensitive actions can be performed without a user being properly identified or authenticated.

    While identification and authentication are crucial to most system interactions, there may be cases where some actions (such as public-facing services or anonymous browsing) do not require identification or authentication. This control ensures that the actions allowed under these conditions do not compromise security or data integrity.

    For example, a user might be able to view publicly available information on a website without authentication, but they should not be able to perform any operations that modify data or access sensitive information.

  • Remote Access

    AC-17 mandates that organizations control remote access to their systems and networks, ensuring that remote access is authorized, monitored, and protected from unauthorized access. This control establishes the requirement to allow remote access only under certain conditions and to implement appropriate safeguards such as encryption, access control mechanisms, and monitoring. The goal is to protect organizational assets, sensitive data, and resources when they are accessed remotely, which is especially important for systems that are accessible from external networks.

    Organizations should ensure that remote access methods, whether through VPNs, remote desktop solutions, or other forms, are properly configured and managed to prevent unauthorized access and maintain the integrity of sensitive data.

  • Remote Access | Monitoring and Control

    AC-17 (1) requires organizations to implement continuous monitoring and control of remote access sessions. This subcontrol focuses on ensuring that remote access is not only granted under the right conditions but is also actively managed and monitored throughout its lifecycle. The organization must monitor remote sessions for unauthorized access, suspicious behavior, or any activity that may pose a risk to the system or data integrity.

    By effectively monitoring remote access, organizations can detect malicious activities, enforce security policies in real-time, and take prompt corrective actions if necessary. This is critical for safeguarding sensitive information and maintaining a secure environment when remote users are connected to the network.

  • Remote Access | Protection of Confidentiality and Integrity Using Encryption

    AC-17 (2) requires organizations to use encryption to protect the confidentiality and integrity of data during remote access sessions. This subcontrol ensures that sensitive information remains secure while transmitted over potentially insecure networks such as the internet. Encryption should be applied to both the data in transit and the communication channels themselves to mitigate the risks of data breaches, eavesdropping, and unauthorized interception.

    By using strong encryption protocols (e.g., TLS, IPSec), organizations can ensure that any sensitive data exchanged during remote sessions remains confidential, intact, and unmodified by unauthorized entities. This is essential for maintaining trust in systems accessed remotely, particularly for sensitive government or federal data.

  • Remote Access | Managed Access Control Points

    AC-17 (3) mandates that organizations must implement managed access control points for remote access. This ensures that access to the system or network through remote access is conducted in a controlled and secure manner. Managed access control points are effectively the gatekeepers that validate and monitor all incoming connections to the organization's network or systems. These points should be continuously monitored and enforced using well-defined policies that limit unauthorized access, ensure proper authentication, and provide accountability.

    By implementing managed access control points, organizations can prevent unauthorized remote connections and provide strong auditing capabilities for any remote sessions. These points also ensure that only authorized personnel can access specific resources based on defined access policies, which helps mitigate the risk of data breaches and other security incidents related to remote access.

  • Remote Access | Privileged Commands and Access

    AC-17 (4) requires organizations to implement measures to control privileged commands and access when remote access is granted. This subcontrol ensures that remote users with privileged access are subject to the same security controls as users accessing the system locally. Specifically, it mandates that privileged users cannot execute sensitive or high-impact commands from remote locations unless additional safeguards are in place, ensuring the integrity and security of systems even when accessed remotely.

    Privileged commands often allow users to perform tasks such as altering system configurations, changing access permissions, or modifying sensitive data. Unauthorized or inappropriate execution of these commands can pose significant risks, especially when accessed remotely. Therefore, this subcontrol requires organizations to enforce strong safeguards, such as monitoring, logging, and additional authentication mechanisms for privileged access, especially when such access is remote.

  • Wireless Access

    AC-18 mandates the implementation of strict controls to protect wireless access to systems. Wireless networks can present significant security vulnerabilities because they often extend beyond physical premises, making them more susceptible to unauthorized access and eavesdropping. This control requires that all wireless access to information systems is protected against unauthorized access, and that there are strict security measures in place to ensure data confidentiality, integrity, and availability when transmitted over wireless networks.

    Wireless access includes Wi-Fi, Bluetooth, and other forms of wireless communication. Organizations must control and monitor these access points to prevent unauthorized users or devices from connecting to the system. Security measures such as encryption, authentication, and network segmentation should be used to mitigate risks associated with wireless networks.

  • Wireless Access | Authentication and Encryption

    AC-18 (1) mandates that wireless access to information systems must be protected by strong authentication mechanisms and encryption to safeguard data confidentiality and integrity. Wireless networks are inherently vulnerable to eavesdropping, man-in-the-middle attacks, and unauthorized access, making encryption and robust authentication essential for maintaining the security of communications. This control ensures that any wireless connections to the system, whether for employees, contractors, or other authorized users, are adequately protected against these risks.

    By enforcing secure authentication methods and strong encryption for wireless communications, organizations can prevent unauthorized access, mitigate potential data breaches, and ensure that sensitive information transmitted over wireless channels remains secure.

  • Wireless Access | Disable Wireless Networking

    AC-18 (3) requires that wireless networking capabilities (such as Wi-Fi, Bluetooth, or other wireless technologies) be disabled on information system devices when those capabilities are not necessary for the device’s functionality or if they are not authorized. Disabling wireless networking helps minimize the risk of unauthorized access to the system or network via wireless channels. This control ensures that only devices that need wireless access to the network are capable of connecting, which reduces the attack surface for potential breaches.

    By disabling unnecessary wireless networking features, organizations can prevent unauthorized devices from gaining access through insecure or rogue wireless connections, particularly in high-security or sensitive environments.

  • Access Control for Mobile Devices

    AC-19 addresses the need to establish access control mechanisms specifically for mobile devices within an organization’s network and systems. This control ensures that mobile devices—whether personally owned or organization-provided—are properly secured and managed to prevent unauthorized access, data leakage, or potential vulnerabilities. Mobile devices, due to their portability and access to sensitive information, pose an increased risk of exposure if not adequately protected. This control includes mechanisms for ensuring proper authentication, data encryption, and compliance with organization-specific access policies for mobile device usage.

  • Access Control for Mobile Devices | Full Device or Container-based Encryption

    AC-19 (5) mandates the use of full device or container-based encryption for mobile devices that access organizational systems and data. This encryption requirement is designed to protect data on mobile devices from unauthorized access in the event of device theft, loss, or compromise. Encryption, whether at the full device level or within specific containers (e.g., apps or data files), ensures that data remains protected, even if the device is physically compromised. By enforcing encryption, organizations can maintain confidentiality and prevent unauthorized exposure of sensitive or personal data stored on mobile devices.

  • Use of External Systems

    AC-20 addresses the security and management of access to external systems. It ensures that any external systems (e.g., third-party services, cloud-based platforms, or devices not under direct control of the organization) are appropriately managed to prevent unauthorized access and ensure that security requirements are enforced. This control establishes requirements for the secure integration, monitoring, and auditing of external systems used within the organization’s environment to ensure that they do not introduce additional vulnerabilities or risks. It also requires organizations to manage the risks associated with using external systems for processing or storing sensitive or critical data

  • Use of External Systems | Limits on Authorized Use

    AC-20 (1) limits the scope of authorized use for external systems by establishing strict boundaries on when, where, and how external systems can be accessed. This subcontrol ensures that external systems are not used for unauthorized purposes and restricts their access to the minimum necessary for the performance of specific tasks. The goal is to reduce the attack surface and mitigate potential security risks by ensuring that only necessary functions are carried out on these systems and only by authorized individuals.

  • Use of External Systems | Portable Storage Devices — Restricted Use

    AC-20 (2) places restrictions on the use of portable storage devices, such as USB drives, external hard drives, and other removable media, to mitigate risks associated with data leakage, loss, or unauthorized access. The subcontrol mandates that these devices be limited to approved uses only, with clear security protocols in place to ensure their proper handling and management. Unauthorized or unapproved use of portable storage devices is strictly prohibited to maintain the confidentiality and integrity of sensitive data and to reduce the risk of introducing malware or other security threats into the system.

  • Information Sharing

    AC-21 focuses on the restrictions and policies governing the sharing of information within and outside an organization to maintain the confidentiality, integrity, and availability of data. It mandates that access to sensitive or classified information be controlled to prevent unauthorized sharing, ensuring that information sharing is in compliance with applicable laws, regulations, and policies. The control addresses both technical and administrative measures required to protect the data during sharing processes.

  • Publicly Accessible Content

    AC-22 addresses the need to manage and control publicly accessible content. It ensures that content made publicly available by an organization is properly identified, classified, and protected from unintentional exposure of sensitive information. The objective is to ensure that publicly accessible content (e.g., website content, publicly available reports, or other documents) is appropriately handled to avoid the risk of disclosing protected, confidential, or sensitive information.

FedRAMP's Awareness and Training (AT) ensures personnel understand security responsibilities through regular training, role-based education, and awareness programs to mitigate risks and strengthen cybersecurity posture.

  • Policy and Procedures

    AT-1 addresses the need for establishing a formal policy and procedures for training individuals on security and privacy practices within the organization. It focuses on ensuring that employees, contractors, and other relevant personnel are properly educated and aware of the risks and responsibilities related to information security. This subcontrol is critical for fostering a security-aware culture and ensuring that personnel understand how to handle sensitive information and respond to potential security threats.

  • Literacy Training and Awareness

    AT-2 requires organizations to provide literacy training and awareness for personnel to ensure they have the foundational knowledge necessary to recognize and respond to security risks. This includes general security awareness and specific training that is relevant to the individual’s role in the organization. Literacy training should include understanding the impact of security vulnerabilities, recognizing potential threats, and ensuring that employees know how to properly handle sensitive information and adhere to organizational security policies.

  • Literacy Training and Awareness | Insider Threat

    AT-2 (2) focuses on training employees to recognize and appropriately respond to potential insider threats. Insider threats involve individuals within an organization who may intentionally or unintentionally cause harm through unauthorized access to data, systems, or resources. The goal of this subcontrol is to ensure that employees are aware of the potential risks posed by insider threats, can identify suspicious behaviors, and understand the steps to report or mitigate these threats.

    This training includes understanding the warning signs of insider threats, the consequences of such threats, and the procedures for reporting any suspicious activities or security breaches. Insider threat literacy is an essential component of a comprehensive security awareness program, particularly in organizations that handle sensitive information or critical infrastructure.

  • Literacy Training and Awareness | Social Engineering and Mining

    AT-2 (3) addresses the need for training employees to recognize and defend against social engineering attacks and information mining techniques. Social engineering manipulates individuals into divulging confidential information, while information mining involves the collection of sensitive data, often through seemingly innocent means, to exploit organizational weaknesses. This subcontrol ensures that all personnel understand the risks posed by these tactics and can identify suspicious behaviors that may lead to a data breach or other security incidents.

    The goal is to educate users on how to avoid falling prey to malicious actors using tactics such as phishing, pretexting, baiting, and other deceptive methods to gather information. Employees should also be aware of how attackers may try to mine data or manipulate information for malicious purposes, often through exploiting trust or manipulating the flow of information within an organization.

  • Role-based Training

    AT-3 focuses on the requirement for role-based training to ensure employees and personnel are equipped with the appropriate knowledge and skills required to perform their duties securely. This type of training is tailored based on an individual’s specific role within the organization, addressing their unique security responsibilities and risks. By customizing the training to job functions, employees gain relevant security knowledge that directly supports their daily tasks and enhances overall organizational security posture.

  • Training Records

    AT-4 requires organizations to maintain records of security training activities to demonstrate compliance with security awareness and training requirements. These records should include information about the training courses provided, the employees who attended, the completion dates, and the results of any assessments or tests. Training records serve as a key mechanism for tracking employee participation and ensuring that all personnel are adequately trained in security policies, procedures, and potential threats. Additionally, these records help in evaluating the effectiveness of training programs and meeting regulatory compliance requirements.

FedRAMP's Audit and Accountability (AU) requires logging, monitoring, and analyzing system activities to detect security incidents, ensure accountability, and support forensic investigations while maintaining compliance.

  • Policy and Procedures

    AU-1 requires organizations to establish, document, and implement an audit and accountability policy and associated procedures. These policies and procedures should govern the collection, retention, analysis, and protection of audit records. Audit logs help organizations to track user activities, system events, and any changes to systems that might indicate malicious behavior or improper usage. An effective audit and accountability policy ensures that logs are maintained and reviewed regularly to detect and respond to security incidents promptly.

  • Event Logging

    AU-2 mandates the creation, collection, and maintenance of event logs for system and network activities. These logs must capture a variety of security-relevant events to enable security monitoring, analysis, and post-incident investigation. Effective event logging is essential for understanding user activities, identifying security breaches, and supporting accountability. By establishing event logging practices, organizations can document important activities related to system access, data modifications, and potential incidents, ensuring compliance with regulatory and security standards.

  • Content of Audit Records

    AU-3 outlines the requirements for the content of audit records, specifying what data should be captured to ensure effective monitoring, detection, and accountability. The content of audit records is crucial for security event analysis, forensic investigations, and compliance auditing. This control requires organizations to ensure that audit records contain enough detailed information to support the identification, investigation, and response to security incidents. The data captured within these audit records must provide insights into who performed the actions, what was done, when it occurred, and where it happened, along with other relevant details.

  • Content of Audit Records | Additional Audit Information

    AU-3 (1) requires the inclusion of additional audit information that extends the basic audit record content to capture any extra details necessary for understanding, investigating, and responding to security events. This subcontrol ensures that not only are the standard audit record details captured (such as who, what, when, and where), but also any supplementary information that might be essential for a comprehensive audit trail. The additional information can include specific system attributes, resource identifiers, or context around unusual activities that are essential for audit completeness and post-incident analysis.

    The purpose of this subcontrol is to enhance the value of audit logs beyond the basics by integrating supplementary metadata or event-specific details. This can improve an organization’s ability to reconstruct the events that led to or followed a security incident, provide deeper insights during analysis, and help security personnel correlate logs from multiple sources.

  • Audit Log Storage Capacity

    AU-4 requires that organizations maintain sufficient capacity for storing audit logs, ensuring that they are retained for a predefined period, without losing critical data. This subcontrol emphasizes the importance of having enough storage resources to accommodate the volume of audit logs generated by systems and processes. Ensuring that logs are securely stored and readily accessible for analysis is a key element in meeting compliance and enhancing the ability to detect and respond to security incidents.

    Adequate audit log storage is necessary to ensure that logs can be retained for the full retention period required by policies, regulatory requirements, or business needs. This control ensures that the storage systems used for logs are scalable, have appropriate redundancy, and meet both the size and availability requirements.

  • Response to Audit Logging Process Failures

    AU-5 focuses on the organization's ability to respond effectively to audit logging process failures. This subcontrol requires the establishment of procedures for detecting, reporting, and addressing failures in the audit logging process to ensure that audit logs are continuously recorded, stored, and protected. When audit logs are unavailable or compromised, it can hinder an organization's ability to investigate security incidents, track user activity, or meet compliance requirements. Therefore, organizations must have predefined actions and mitigation steps in place to address such failures immediately.

  • Audit Record Review, Analysis, and Reporting

    AU-6 requires organizations to periodically review and analyze audit records to ensure they are being generated, collected, and retained appropriately. This control ensures that logs are systematically examined to identify anomalies, potential security incidents, or noncompliance with policies. It emphasizes the need for ongoing oversight and reporting of audit data to detect early signs of security threats, unauthorized access, or system misuse.

  • Audit Record Review, Analysis, and Reporting | Automated Process Integration

    AU-6 (1) requires organizations to integrate automated processes into their audit record review and analysis activities. Automated tools, such as Security Information and Event Management (SIEM) systems, should be used to help detect, analyze, and respond to audit log anomalies in real-time. This ensures that logs are processed efficiently, enabling faster detection of security incidents, violations of policy, or other irregular activities. Automated integration allows for continuous monitoring, reducing human error, improving response times, and enhancing the accuracy of threat identification.

  • Audit Record Review, Analysis, and Reporting | Correlate Audit Record Repositories

    AU-6 (3) requires organizations to correlate audit records from different sources and repositories to provide a comprehensive view of security-related events. By combining and cross-referencing data from multiple audit logs, organizations can improve their ability to detect and analyze potential security incidents or policy violations. This ensures that audit logs are not considered in isolation, but rather as part of a broader security context, enabling more accurate detection of complex attack patterns or systemic issues that might otherwise go undetected.

  • Audit Record Reduction and Report Generation

    AU-7 focuses on the need for organizations to reduce the volume of audit records while maintaining the integrity and usability of those records for analysis, reporting, and future reference. This subcontrol requires organizations to ensure that audit logs are filtered and summarized appropriately to facilitate easier analysis and reporting, without losing the critical data needed for incident response and compliance audits. Additionally, it addresses the generation of reports based on audit log information to support security monitoring, investigation, and compliance activities.

  • Audit Record Reduction and Report Generation | Automatic Processing

    AU-7 (1) requires the automated processing of audit records to reduce the volume of data and generate relevant audit reports. This subcontrol emphasizes the use of automated tools to aggregate, filter, and summarize audit logs, ensuring that only critical information is retained for reporting purposes. Automated processing helps streamline the management of audit logs and ensures compliance with regulatory requirements, while making audit record analysis more efficient and effective. The goal is to balance the need for comprehensive audit logs with the practicality of managing and reviewing large volumes of data.

  • Time Stamps

    AU-8 requires the use of accurate and synchronized time stamps in audit records. The time stamps are essential for the integrity and reliability of the audit trail, providing a reliable reference for when specific events occur. These time stamps must be generated by a consistent, accurate time source and must be applied to all events in the audit trail to ensure proper event sequencing and to facilitate effective forensic analysis, investigation, and reporting.

  • Protection of Audit Information

    AU-9 addresses the protection of audit information to ensure that it is not altered or deleted without authorization. This control ensures the confidentiality, integrity, and availability of audit logs and audit records. By securing audit information, organizations can ensure that audit logs can be trusted for investigative, compliance, and forensic purposes. Unauthorized access, modification, or deletion of audit information can undermine the effectiveness of the audit process, leading to loss of critical evidence in the event of a security breach or incident.

  • Protection of Audit Information | Access by Subset of Privileged Users

    AU-9 (4) requires that access to audit information be limited to a subset of privileged users who have the necessary authority and need-to-know basis to access sensitive audit logs and records. The control ensures that only those individuals with appropriate clearance can access, modify, or review audit logs, thereby protecting the integrity and confidentiality of audit information. The restriction of access helps to prevent unauthorized access, tampering, or misuse of audit logs and supports the principle of least privilege by ensuring that only essential personnel have the ability to view or interact with critical audit information.

  • Audit Record Retention

    AU-11 requires that organizations retain audit records for a defined period to support ongoing monitoring, investigations, and legal or compliance needs. The retention of audit records must ensure that they are accessible and usable when needed, while also maintaining their integrity. Organizations are required to keep these logs in a manner that ensures their availability for review by authorized personnel, during security investigations, or audits.

    This subcontrol aims to balance the retention of important audit records with the need to manage data storage and privacy concerns. Retention periods should align with regulatory requirements, organizational policies, and potential incident response needs. Logs should be stored securely and protected from tampering or unauthorized access, and the organization should have defined procedures for securely disposing of audit records once their retention period has expired.

  • Audit Record Generation

    AU-12 specifies the requirement for generating audit records that capture relevant security events and system activities. These records must contain sufficient information to support the monitoring, investigation, and analysis of activities that could impact the system’s security posture. The audit records should be generated automatically and consistently across the system and related infrastructure, ensuring they cover critical actions like user logins, configuration changes, and access to sensitive data.

    This subcontrol emphasizes that audit records should be created for key system activities that are likely to have security implications, such as unauthorized access attempts, privilege escalations, or configuration changes. Organizations must configure systems to ensure that audit logs are generated in real-time and contain enough detail to support later analysis, whether it's for troubleshooting, compliance audits, or security investigations.

FedRAMP's Security Assessment and Authorization (CA) ensures continuous monitoring, independent security assessments, and risk-based authorization to maintain compliance and protect federal systems from threats.

  • Policy and Procedures

    CA-1 requires organizations to develop, implement, and maintain formal policies and procedures that govern the security assessment and authorization (SA&A) process for information systems. These policies and procedures should ensure that systems undergo a comprehensive security evaluation to assess the effectiveness of security controls, manage risks, and confirm that the system is authorized for operation before it is deployed in the operational environment. The security authorization process is essential for ensuring that systems meet the necessary security standards and comply with applicable regulations.

  • Control Assessments

    CA-2 outlines the requirement for organizations to perform assessments of the security controls in place for their information systems to ensure that they are operating effectively and are in compliance with security requirements. This control mandates that organizations conduct regular assessments to verify the performance of security controls, identify vulnerabilities, and confirm that controls are functioning as intended.

    The assessment process includes reviewing technical, administrative, and physical controls within the system and ensures that those controls meet the necessary compliance and security standards. This evaluation is vital for maintaining the confidentiality, integrity, and availability of systems and data by ensuring that vulnerabilities are detected and mitigated.

  • Control Assessments | Independent Assessors

    CA-2 (1) specifies the requirement for organizations to use independent assessors to evaluate the security controls of their systems. This subcontrol ensures that security assessments are unbiased, thorough, and credible by engaging assessors who are independent of the system’s development and operation. The use of independent assessors helps to maintain objectivity, provides external validation of control effectiveness, and ensures that the results of the assessments are trusted by stakeholders.

    Independent assessors are typically external experts who are not directly involved in the day-to-day operations or implementation of the system. This ensures that the findings and recommendations are impartial and based solely on an objective evaluation of the security controls and their effectiveness in mitigating risks.

  • Control Assessments | Leveraging Results from External Organizations

    CA-2 (3) focuses on leveraging the results of security assessments conducted by external organizations, such as third-party assessors or vendors, to supplement internal security assessments. This subcontrol encourages organizations to integrate external assessments, including audit results, penetration testing reports, and vulnerability assessments, into their overall security authorization process. The objective is to enhance the depth of security reviews by considering relevant external expertise and findings to ensure comprehensive coverage of the system's security posture.

    Leveraging external assessments is particularly useful when specialized skills or resources are needed to address complex security risks that internal resources may not fully be able to evaluate. By utilizing these external findings, organizations can fill gaps in their internal assessments and obtain a broader view of potential risks, vulnerabilities, and threats.

  • Information Exchange

    CA-3 pertains to ensuring secure and controlled information exchange between the system being assessed and other entities during the security assessment and authorization process. This subcontrol focuses on the protection and proper handling of sensitive information exchanged between internal and external entities, including stakeholders, vendors, third-party auditors, and regulatory bodies.

    The objective is to establish clear, secure methods for exchanging information, such as audit logs, vulnerability assessments, and system security documentation, while ensuring compliance with applicable security requirements. Information exchanged must be protected from unauthorized access and disclosure, and its integrity must be maintained throughout the process. This subcontrol ensures that the system’s security information is managed properly and securely shared with authorized parties only.

  • Plan of Action and Milestones

    CA-5 requires the creation, maintenance, and execution of a Plan of Action and Milestones (POA&M). This plan is a key element of the security assessment and authorization process. It identifies and tracks the remediation of security weaknesses or deficiencies that were discovered during the security assessment or during routine operations. The POA&M should detail the corrective actions, assign responsibilities, set timelines, and outline the resources required to resolve the identified issues.

    This subcontrol ensures that security deficiencies are tracked and addressed in a timely and efficient manner to maintain an acceptable risk posture and ensure that systems continue to operate in compliance with FedRAMP security standards.

  • Authorization

    CA-6 refers to the process of formally authorizing an information system to operate within an organization. This authorization process involves assessing the system's security posture, determining if the system meets the required security controls, and granting approval for the system to operate. The authorization decision is based on a comprehensive evaluation of the system’s compliance with security requirements, as outlined in the System Security Plan (SSP), Security Assessment Report (SAR), and Plan of Action and Milestones (POA&M).

    The Authorization subcontrol ensures that only systems that meet the necessary security standards are authorized to operate and that the risks associated with their operation are acceptable. This process should involve senior management or designated authorizing officials who review the security documentation, the results of security assessments, and the mitigation of any identified risks before making a decision.

  • Continuous Monitoring

    CA-7 focuses on the ongoing, continuous monitoring of information systems and their security controls. It requires organizations to continuously assess the security posture of their systems after the authorization to operate (ATO) has been granted. The goal is to ensure that the system continues to meet security requirements and that any changes in the system or the environment that could affect security are identified, evaluated, and addressed in a timely manner.

    Continuous monitoring involves the ongoing collection of security data, the assessment of vulnerabilities and threats, and the application of security updates and patches. This process helps detect new security threats, ensure compliance with security requirements, and maintain the authorization status of the system.

  • Continuous Monitoring | Independent Assessment

    CA-7 (1) emphasizes the requirement for independent assessments of an organization's continuous monitoring activities. The control mandates that a third-party or internal independent assessor must review the continuous monitoring efforts regularly to ensure that they are being conducted effectively and meet the organization's security and compliance requirements. Independent assessments help to identify potential gaps, inefficiencies, or weaknesses in the monitoring process, providing an unbiased evaluation of the system's security posture.

    Independent assessments are integral in confirming that the continuous monitoring process is aligned with risk management objectives and that all necessary steps are taken to address identified vulnerabilities or incidents promptly. These assessments also help ensure that the monitoring strategy is effective and in line with current industry standards and best practices.

  • Continuous Monitoring | Risk Monitoring

    CA-7 (4) focuses on integrating risk monitoring into the continuous monitoring program. This subcontrol emphasizes the need for ongoing identification, assessment, and management of security risks as part of the organization's continuous monitoring efforts. Risk monitoring should provide the necessary data and insights to proactively address vulnerabilities, threats, and potential risks that could impact the system’s security and compliance posture. It requires the organization to have a systematic process for identifying emerging risks and adjusting security measures accordingly.

  • Penetration Testing

    CA-8 requires that penetration testing be conducted as part of the overall security assessment process to identify vulnerabilities and weaknesses in the system. Penetration testing simulates a cyberattack on the system's defenses to identify potential exploitation points that could lead to unauthorized access or data breaches. The goal is to ensure that systems can withstand sophisticated attack techniques and that vulnerabilities are remediated before being exploited in the real world.

    Penetration testing should be conducted periodically or whenever there are significant changes to the system or the threat landscape. The results of the testing should be used to improve the overall security posture and address any discovered vulnerabilities.

  • Penetration Testing | Independent Penetration Testing Agent or Team

    CA-8 (1) requires that penetration testing be conducted by an independent agent or team, separate from the development or operational teams responsible for the system. This ensures objectivity and impartiality in the assessment of the system's vulnerabilities. The independent testers are tasked with simulating realistic attack scenarios to identify potential weaknesses without prior knowledge of the internal defenses or systems, ensuring that the findings are unbiased and reflective of actual security risks.

  • Penetration Testing | Red Team Exercises

    CA-8 (2) mandates that organizations conduct Red Team exercises as part of their penetration testing efforts. A Red Team exercise is an advanced form of penetration testing where a team of ethical hackers (the "Red Team") simulates a real-world adversary’s tactics, techniques, and procedures (TTPs) to evaluate the security posture of an organization. Unlike traditional penetration tests that focus on specific vulnerabilities, Red Team exercises are comprehensive, involving multi-layered attacks that test how well an organization can detect, respond to, and mitigate actual adversarial tactics in a more realistic and dynamic environment.

    The goal of Red Team exercises is to push beyond routine vulnerability assessments and test the resilience of systems, networks, and personnel under simulated attack scenarios. The exercises often go beyond technical vulnerabilities to include social engineering, physical penetration, and insider threat simulations.

  • Internal System Connections

    CA-9 focuses on ensuring that internal system connections are properly managed, assessed, and monitored to maintain security and operational integrity. The control requires that organizations establish, manage, and review internal connections, such as those between network segments, servers, databases, or services that are within the scope of the security authorization. This ensures that these internal connections do not inadvertently introduce security vulnerabilities and that their design and configuration align with the security requirements of the organization.

    In the context of FedRAMP, CA-9 emphasizes the importance of safeguarding connections between systems or components that support the operational functions of the information system, ensuring that they adhere to the security policies and procedures set forth in the security authorization.

FedRAMP's Configuration Management (CM) ensures secure system settings, change control, and continuous monitoring to prevent unauthorized modifications, maintain integrity, and enhance security compliance.

  • Policy and Procedures

    CM-1 focuses on establishing, documenting, and maintaining policies and procedures for configuration management (CM). These policies and procedures ensure that the configuration of information systems is properly managed throughout their lifecycle, from initial design and development to decommissioning. The goal is to establish consistent and secure configuration practices that maintain the security posture of the system, minimize vulnerabilities, and comply with regulatory standards such as FedRAMP. This subcontrol also mandates regular updates and improvements to configuration management practices as part of ongoing system maintenance.

  • Baseline Configuration

    CM-2 requires the establishment, documentation, and maintenance of baseline configurations for information systems. A baseline configuration is a predefined, secure configuration of system components (hardware, software, firmware, and network devices) that serves as a reference point for the security and operational integrity of the system. This baseline must be maintained and updated regularly to ensure that it aligns with current security standards, addresses vulnerabilities, and reflects any changes in the system or its environment.

    The baseline configuration defines the minimum security controls that must be in place to protect the system. By creating and enforcing this baseline, organizations can ensure consistency, reduce security vulnerabilities, and facilitate easier audits and assessments.

  • Baseline Configuration | Automation Support for Accuracy and Currency

    CM-2 (2) focuses on using automation tools and techniques to maintain the accuracy and currency of baseline configurations. This subcontrol requires that organizations implement automated mechanisms to regularly check and update baseline configurations to ensure they reflect the most current and secure system settings. By utilizing automation, organizations can reduce the likelihood of human errors and improve the speed and consistency of updates.

    Automated support is essential for maintaining configuration integrity and ensuring that configurations remain aligned with security best practices, regulatory compliance, and organizational standards. Automation also aids in tracking and reporting changes, which is critical for auditing and monitoring purposes.

  • Baseline Configuration | Retention of Previous Configurations

    CM-2 (3) requires organizations to establish and maintain a process for retaining previous baseline configurations of systems, ensuring that older configurations are securely stored and accessible for review, comparison, and restoration purposes. Retaining historical configuration baselines is crucial for troubleshooting, recovery, forensic investigations, and ensuring accountability.

    This subcontrol helps organizations maintain an adequate configuration history, enabling them to compare current configurations with previous versions to detect unauthorized changes, vulnerabilities, or errors that may have been introduced over time. Retaining previous configurations also supports the organization’s ability to restore configurations to a known, secure state if needed.

  • Baseline Configuration | Configure Systems and Components for High-risk Areas

    CM-2 (7) requires organizations to configure systems and components in high-risk areas according to baseline configurations that specifically address the increased security needs in these areas. High-risk areas may include critical assets, sensitive data processing locations, systems exposed to higher threat levels, or components that handle privileged access or classified information. This subcontrol focuses on ensuring that these areas are configured with additional security measures to mitigate the risks associated with potential threats.

    The goal of CM-2 (7) is to reduce vulnerabilities in high-risk systems and components by enforcing stricter configuration standards and controls tailored to the heightened security requirements. Organizations should ensure that these areas are configured to minimize the attack surface, adhere to security best practices, and comply with relevant standards for protection.

  • Configuration Change Control

    CM-3 outlines the requirements for managing changes to system configurations to ensure that modifications are made in a controlled and secure manner. The goal of this control is to ensure that any changes to a system’s configuration do not inadvertently introduce vulnerabilities or negatively impact the system’s security posture. By enforcing a formal change management process, organizations can minimize risks and maintain compliance with security policies and regulatory requirements.

    This control is critical for maintaining the integrity of systems, preventing unauthorized changes, and ensuring that all changes are documented, tested, and reviewed to assess their security impact before implementation.

  • Configuration Change Control | Testing, Validation, and Documentation of Changes

    CM-3 (2) requires organizations to implement procedures for testing, validating, and thoroughly documenting all changes made to the system configurations. This process ensures that any modification made to the system is reviewed for its impact on functionality, security, and compliance with organizational policies. Changes must undergo rigorous testing to ensure they do not introduce vulnerabilities, negatively affect system performance, or cause disruptions. Additionally, proper documentation of changes helps maintain an accurate record, ensuring that all alterations are traceable and meet established security and operational standards.

  • Configuration Change Control | Security and Privacy Representatives

    CM-3 (4) emphasizes the involvement of security and privacy representatives in the configuration change control process. These representatives must be actively engaged in the review, approval, and oversight of all proposed configuration changes to ensure they align with the organization’s security and privacy policies. This subcontrol ensures that configuration changes do not inadvertently compromise security controls or violate privacy regulations, by ensuring appropriate expertise and accountability throughout the change management process.

  • Impact Analyses

    CM-4 focuses on the systematic analysis of the impact of proposed changes to an information system's configuration. This process helps ensure that changes made to the system, whether related to hardware, software, or configurations, do not unintentionally degrade system security, functionality, or performance. Impact analyses are critical for assessing potential risks, system dependencies, and the broader effects on the organization’s security posture before implementing changes.

  • Impact Analyses | Verification of Controls

    CM-4 (2) requires the verification of controls when performing impact analyses during configuration changes. This subcontrol ensures that the implementation of changes is thoroughly evaluated for their impact on existing security controls, ensuring that the necessary safeguards remain effective after changes are applied. The focus is on validating that all relevant security, privacy, and compliance controls continue to function as expected, and that the integrity of the system is maintained post-change.

  • Access Restrictions for Change

    CM-5 mandates that access to change management processes be restricted to authorized individuals. This subcontrol ensures that only personnel with the necessary permissions are allowed to implement or request changes to system configurations. It reduces the risk of unauthorized changes, which could undermine system security, create vulnerabilities, or compromise compliance with regulatory requirements.

  • Access Restrictions for Change | Automated Access Enforcement and Audit Records

    CM-5 (1) mandates that automated systems enforce access restrictions for the configuration change process and maintain detailed audit records. The goal is to ensure that only authorized users can initiate, approve, or implement changes to system configurations, while also providing a clear, auditable trail of who has accessed and modified configurations. Automated enforcement helps prevent unauthorized access and supports accountability by logging all activities related to configuration changes.

  • Access Restrictions for Change | Privilege Limitation for Production and Operation

    CM-5 (5) requires that privilege levels for users and system administrators be limited within production and operational environments to ensure that only necessary individuals have access to make changes that can affect the functioning or security of the system. This control aims to reduce the risk of unauthorized, accidental, or malicious changes in critical production environments. By limiting privileges, organizations can ensure that only authorized personnel have the ability to modify operational systems, reducing the exposure of the system to potential vulnerabilities.

  • Configuration Settings

    CM-6 addresses the necessity of managing configuration settings to ensure that systems and components are securely configured. It mandates that systems must be set to operate in a secure and consistent state, with predefined security and operational settings established and maintained. The goal of this control is to prevent systems from being deployed or used with insecure configurations that could expose the system to vulnerabilities or operational inefficiencies.

  • Configuration Settings | Automated Management, Application, and Verification

    CM-6 (1) focuses on automating the management, application, and verification of configuration settings across an organization’s systems and components. The purpose of this subcontrol is to ensure that systems are consistently and securely configured without manual intervention, which can be prone to error. By automating these processes, an organization can ensure quicker deployment, stronger security, and better compliance with established configuration baselines.

  • Least Functionality

    CM-7 focuses on ensuring that systems are configured to provide only the essential functionalities necessary for their intended operation. This principle, known as least functionality, is designed to minimize the attack surface by reducing the number of services, applications, and features running on a system. By limiting functionality, organizations decrease the potential avenues for unauthorized access, exploitation, or other security breaches.

    This subcontrol is a core component of system hardening efforts and ensures that systems are not unnecessarily exposed to risks due to unused or unneeded services or software.

  • Least Functionality | Periodic Review

    CM-7 (1) emphasizes the importance of conducting periodic reviews of system configurations to ensure that only necessary functionalities are enabled and that unnecessary services or features are disabled. This review is essential to maintaining a security posture that minimizes the attack surface by ensuring that configurations remain aligned with the principle of least functionality over time.

    The periodic review process helps identify any drift in configuration settings, whether from changes in business requirements, accidental misconfigurations, or the addition of non-essential functionality. By regularly reviewing and updating configurations, organizations can ensure that they consistently minimize unnecessary features and reduce potential vulnerabilities.

  • Least Functionality | Prevent Program Execution

    CM-7 (2) establishes the requirement to implement configurations that prevent unnecessary programs from executing on the system. The goal is to ensure that only authorized and required programs are allowed to run, thus reducing the attack surface and mitigating potential security risks. This includes prohibiting unauthorized applications or executable files from being launched within the system environment.

    Preventing unauthorized program execution is an essential aspect of the least functionality principle, as it helps ensure that systems are not burdened with unnecessary or potentially malicious programs. Such controls help safeguard the system from attacks that exploit unapproved software, reducing the risk of malware or other malicious code running on the system.

  • Least Functionality | Authorized Software — Allow-by-exception

    CM-7 (5) outlines the control for ensuring that only authorized software is allowed to run on systems, and that any exceptions to this rule are handled on a case-by-case basis. The "allow-by-exception" model means that, by default, software that has not been explicitly approved or authorized is not permitted to execute. Any exceptions must go through a formal approval process to ensure the software is necessary and secure for the environment.

    This subcontrol emphasizes minimizing the attack surface by restricting systems to known, authorized software and requiring documentation and justification for exceptions to this rule.

  • System Component Inventory

    CM-8 requires that organizations maintain an up-to-date and accurate inventory of all system components. This includes all hardware, software, and firmware elements that make up the system, as well as the relationships between them. The inventory should be comprehensive and continually updated to reflect changes in the system’s configuration and infrastructure.

    The purpose of this control is to ensure that all components of the information system are known, traceable, and can be monitored for vulnerabilities, compliance, and performance. By maintaining a complete system component inventory, organizations can improve system management, mitigate risk, and streamline security assessments

  • System Component Inventory | Updates During Installation and Removal

    CM-8 (1) requires that organizations ensure their system component inventory is updated during the installation and removal of system components. This includes both hardware and software components that are added to or removed from the system. The goal is to maintain an accurate, up-to-date inventory by reflecting these changes in real-time, helping organizations manage risks associated with system configurations and ensuring that unauthorized or untracked changes are prevented.

    The inventory update should be integrated into installation and removal procedures, with formal processes in place for verifying and documenting the status of components at each step. This ensures that any changes to the system's configuration are tracked properly and comply with the organization's change management and security policies.

  • System Component Inventory | Automated Unauthorized Component Detection

    CM-8 (3) mandates the implementation of automated systems to detect unauthorized system components. This control focuses on leveraging automated tools to continuously monitor the system component inventory for any components that are added without proper authorization or that do not match the approved configurations. The goal is to ensure that any unauthorized components, which could pose security risks, are quickly detected, reported, and removed.

    Automated unauthorized component detection tools provide continuous monitoring and flag any discrepancies in the inventory, ensuring the integrity of the system by maintaining a configuration that adheres strictly to approved standards. This is particularly crucial in environments with dynamic and complex infrastructures where changes may occur rapidly and without proper oversight.

  • Configuration Management Plan

    CM-9 requires organizations to develop, document, and maintain a Configuration Management (CM) Plan. The CM Plan outlines how configuration management will be implemented, governed, and maintained across the system lifecycle. It includes policies and procedures for managing the configurations of system components, ensuring consistent practices for tracking, managing, and controlling changes to the configuration. The goal of this plan is to establish a structured approach to configuration management, ensuring that system components are consistently configured and controlled in a manner that minimizes risk, maintains security, and supports operational effectiveness.

  • Software Usage Restrictions

    CM-10 requires organizations to establish and enforce policies and procedures for restricting the use of unauthorized or unapproved software on system components. This includes ensuring that only approved software is installed, configured, and executed on systems, in alignment with security requirements and operational needs. These restrictions help mitigate risks related to malicious software, software vulnerabilities, and non-compliance with licensing or regulatory requirements. Enforcing software usage restrictions also assists in maintaining the integrity and security of systems and helps to prevent unauthorized changes or security breaches.

  • User-installed Software

    CM-11 addresses the need for organizations to manage software installations performed by users, ensuring that any software installed by end-users is authorized, compliant, and does not introduce security risks. This control ensures that user-installed software does not compromise system integrity, data confidentiality, or security posture. It requires mechanisms to monitor, control, and restrict software installations by non-administrative users, including enforcing policies for the installation of software on systems, and auditing any installations that occur.

  • Information Location

    CM-12 requires organizations to manage and document the physical and digital locations of sensitive information within their systems and infrastructure. This control ensures that the organization maintains awareness of where critical data resides, whether on-premises, in cloud environments, or at external data centers. The ability to locate and document information locations is essential for effective data management, security, compliance, and incident response.

  • Information Location | Automated Tools to Support Information Location

    The CM-12 (1) subcontrol mandates the use of automated tools to assist organizations in managing and tracking the physical and digital locations of information across systems and infrastructure. By leveraging automation, organizations can increase the accuracy, timeliness, and consistency of information location tracking, improving the ability to enforce data security and compliance measures. This subcontrol aims to streamline processes for identifying and documenting where sensitive information is stored, processed, and transmitted.

FedRAMP's Contingency Planning (CP) ensures systems can recover from disruptions through backups, disaster recovery plans, and regular testing to maintain operational resilience and data integrity.

  • Policy and Procedures

    The CP-1 control requires that an organization establishes, documents, and implements contingency planning policies and procedures to ensure ongoing operations during unexpected disruptions. The purpose of this control is to set the foundation for an effective contingency planning program by defining the responsibilities, procedures, and resources needed to restore system operations and minimize impact on organizational objectives in the event of a crisis.

  • Contingency Plan

    The CP-2 control requires the organization to develop, document, and implement a contingency plan for information systems. This plan provides a roadmap for responding to potential disruptions and outlines actions necessary for restoring system operations. The contingency plan focuses on preparing for incidents, detailing recovery strategies, and minimizing the impact on essential services.

  • Contingency Plan | Coordinate with Related Plans

    CP-2 (1) requires that the organization ensures the contingency plan aligns and coordinates with related plans, including the disaster recovery plan (DRP), business continuity plan (BCP), and incident response plan (IRP). This coordination aims to unify response efforts across all recovery and continuity operations, fostering a holistic approach to incident management and reducing recovery time by avoiding plan conflicts or redundancies.

  • Contingency Plan | Resume Mission and Business Functions

    CP-2 (3) emphasizes the development and implementation of processes to promptly resume mission-critical and business functions following a disruption. This control ensures that organizations prioritize the recovery of essential services and define clear steps and resources needed to restore operations within acceptable timeframes.

  • Contingency Plan | Identify Critical Assets

    CP-2 (8) focuses on the identification of critical assets necessary for the continuation of mission and business functions during a disruption. This subcontrol ensures that an organization clearly identifies and protects its most essential systems, applications, data, and infrastructure to ensure minimal downtime and maintain functionality during emergencies or system failures.

  • Contingency Training

    CP-3 focuses on the establishment and maintenance of contingency training for organizational personnel. The objective is to ensure that all individuals who are part of the contingency planning process are equipped with the necessary knowledge and skills to effectively execute the contingency plan during an emergency or system failure. This includes training on roles and responsibilities, emergency procedures, and the recovery of critical assets.

  • Contingency Plan Testing

    CP-4 mandates the testing of contingency plans to ensure they are effective and can be executed in a real-world scenario. The goal of this control is to verify that the contingency plan meets the organization's recovery and business continuity objectives and that personnel are familiar with their roles and responsibilities in executing the plan. Testing should be done regularly to ensure that the plan is up-to-date, comprehensive, and aligned with the organization's current operational needs and threat landscape.

  • Contingency Plan Testing | Coordinate with Related Plans

    CP-4 (1) requires organizations to ensure that contingency plan testing is coordinated with related plans, such as incident response, business continuity, and disaster recovery plans. This coordination ensures that all relevant plans are aligned, that interdependencies between plans are identified, and that the organization can execute a seamless, integrated response to any disruption. The goal is to avoid fragmented responses during an incident and to ensure that each plan complements and supports the others.

  • Alternate Storage Site

    CP-6 requires organizations to establish and maintain alternate storage sites to ensure the integrity, availability, and security of critical information. These alternate storage sites provide backup locations where data, systems, and other critical resources can be securely stored and accessed during a disaster or disruptive event. The aim of this control is to prevent data loss and ensure that information can be recovered in case the primary storage location becomes inaccessible or compromised.

  • Alternate Storage Site | Separation from Primary Site

    CP-6 (1) requires organizations to ensure that their alternate storage site is physically and logically separated from the primary site to mitigate the risk of both sites being impacted by the same adverse event. This separation helps ensure that if a disaster or disruption occurs at the primary site, the alternate site remains operational and can be relied upon to maintain business continuity and system availability.

    This control emphasizes the importance of geographical and logical separation to ensure resilience and to safeguard data integrity during an incident. It helps minimize the risk of natural disasters, cyberattacks, or other incidents affecting both the primary and backup sites simultaneously.

  • Alternate Storage Site | Accessibility

    CP-6 (3) requires that organizations ensure the alternate storage site is accessible when needed for contingency purposes. This includes making certain that the necessary infrastructure, network connections, and access controls are in place to allow authorized personnel to retrieve data and restore systems from the alternate site during a disaster or disruption. Accessibility must be tested regularly to verify that the site can be operational in accordance with the organization's recovery and continuity needs.

  • Alternate Processing Site

    CP-7 requires the establishment of an alternate processing site to ensure business continuity in the event of a disruption or disaster at the primary processing site. This alternate site provides the capability to maintain operations and continue essential functions by temporarily processing critical data and workloads at an off-site location. This control ensures that processing capabilities are preserved under varying disaster recovery scenarios, minimizing operational downtime.

  • Alternate Processing Site | Separation from Primary Site

    CP-7 (1) emphasizes the requirement for the alternate processing site to be geographically separated from the primary site to mitigate the risk of a single event (e.g., a natural disaster, power outage, or cyber attack) affecting both sites. This separation ensures that if one site is compromised or rendered inoperable, the alternate site can continue operations without being impacted by the same failure, thereby enhancing overall disaster resilience.

  • Alternate Processing Site | Accessibility

    CP-7 (2) mandates that the alternate processing site must be accessible to authorized personnel and systems during a contingency event. This ensures that, in the event of a disaster or failure at the primary site, the alternate site can be used to continue critical operations without delay. Accessibility refers to both physical and logical access, ensuring that personnel can reach the site and systems can connect to it.

    The alternate processing site should be designed and equipped to handle the same operations as the primary site, and all relevant stakeholders should be able to access the site when required, using secure and authorized methods.

  • Alternate Processing Site | Priority of Service

    CP-7 (3) requires that an alternate processing site be established with clear prioritization of services to ensure that critical operations are restored first during a contingency event. This control emphasizes identifying essential business functions and ensuring that these functions are given priority for recovery over less critical services. The goal is to minimize downtime and maintain the organization’s most important operations during a disruption.

    In the context of an alternate processing site, services and resources should be prioritized based on the criticality to the organization’s mission, customer obligations, and legal requirements. Once the highest-priority services are restored, other services can be brought back online according to their business importance.

  • Telecommunications Services

    CP-8 focuses on ensuring the continuity of telecommunications services during a contingency event. This control requires that organizations have contingency plans in place to maintain essential telecommunications services when primary systems become unavailable. The objective is to ensure that critical communication channels, including voice and data communications, remain operational or are quickly restored, even during emergencies.

    Telecommunications services often form the backbone of an organization's operational infrastructure, especially in an interconnected, cloud-driven environment. If these services fail, it could disrupt business operations and prevent effective response to incidents. By securing alternate or backup telecommunications options, organizations can ensure resilience and reduce the risk of downtime during a disaster.

  • Telecommunications Services | Priority of Service Provisions

    CP-8 (1) addresses the need for organizations to ensure that critical telecommunications services are prioritized during contingency events. This subcontrol emphasizes the establishment of priority service provisions to ensure that essential communications services remain available during emergencies or disasters. During such events, telecommunication resources may become scarce or disrupted, so it’s vital to have predefined priorities for restoring services, ensuring that critical communications channels are reinstated first.

  • Telecommunications Services | Single Points of Failure

    CP-8 (2) addresses the need to identify and mitigate single points of failure (SPOFs) within telecommunications services. A single point of failure in a telecommunications system is any component that, if it fails, would cause the entire system to fail or be unavailable. This subcontrol ensures that organizations take steps to either eliminate or mitigate such risks by implementing redundancy and backup systems to ensure continuous service availability during contingencies.

  • System Backup

    CP-9 focuses on the need for organizations to implement system backups to ensure that data and critical system components can be restored in the event of a disaster, system failure, or other unexpected events. This control mandates that organizations regularly back up essential system configurations, software, and data to maintain the ability to recover from potential disruptions. The backup process must ensure that data remains available and can be restored within a predefined time frame to meet business continuity and disaster recovery objectives.

  • System Backup | Testing for Reliability and Integrity

    CP-9 (1) focuses on the need for organizations to regularly test the reliability and integrity of their system backups to ensure they are accurate, complete, and recoverable. The objective is to ensure that in the event of a system failure or disaster, the backups can be restored efficiently and without data corruption. Testing the backups helps identify potential issues before a disaster occurs, reducing the time and resources needed for recovery operations.

  • System Backup | Cryptographic Protection

    CP-9 (8) requires that system backups are protected using cryptographic methods to ensure the confidentiality, integrity, and authenticity of backup data. Cryptographic protection ensures that backup data cannot be tampered with or accessed by unauthorized individuals during storage or transfer. This control aims to safeguard sensitive information stored in backups by using encryption technologies to prevent unauthorized access, data corruption, and unauthorized modifications.

    By implementing cryptographic protection, the organization reduces the risk of data breaches, protects the integrity of backup data, and ensures that sensitive information remains secure both during storage and transit.

  • System Recovery and Reconstitution

    CP-10 focuses on ensuring that the organization has a structured approach to system recovery and reconstitution following a disruption or incident. It involves the processes, policies, and tools needed to restore the system to its operational state, ensuring minimal downtime and a quick return to business as usual. This includes not only technical recovery but also the reconstitution of systems to a functional state after an outage, cyberattack, or disaster, by utilizing backup data, previous configurations, or alternate systems.

  • System Recovery and Reconstitution | Transaction Recovery

    CP-10 (2) focuses on the recovery of transactions and transaction-related data in the event of system disruptions. Transaction recovery refers to the processes and mechanisms that ensure that all transactional data, including financial, operational, and service-related records, are accurately restored and that the integrity of transactions is maintained. This includes implementing processes to reprocess or reconcile incomplete or lost transactions and ensure that systems can return to their normal operational state without loss of critical transaction data.

FedRAMP's Identification and Authentication (IA) enforces secure user access through identity verification, multi-factor authentication, and credential management to prevent unauthorized access and ensure system integrity.

  • Policy and Procedures

    IA-1 establishes the requirement for developing and maintaining a formal set of policies and procedures that guide the identification and authentication of users, devices, and systems. These policies and procedures are essential to ensure that only authorized individuals, devices, and systems are granted access to organizational assets and services. The purpose is to protect the confidentiality, integrity, and availability of systems and data by preventing unauthorized access.

  • Identification and Authentication (organizational Users)

    IA-2 requires the implementation of processes and controls to uniquely identify and authenticate users within the organization. This includes ensuring that every organizational user (including employees, contractors, and third-party users) is uniquely identified and authenticated prior to gaining access to any organizational information systems. The goal is to verify the identity of users to prevent unauthorized access, which is crucial for safeguarding sensitive data and resources.

  • Identification and Authentication (organizational Users) | Multi-factor Authentication to Privileged Accounts

    IA-2 (1) mandates the implementation of multi-factor authentication (MFA) for privileged accounts in organizational systems. Privileged accounts have elevated access and control over critical systems and sensitive data, making them attractive targets for malicious actors. Multi-factor authentication adds an extra layer of security by requiring users to provide more than one form of verification (something they know, something they have, or something they are) to gain access. This control aims to reduce the likelihood of unauthorized access to privileged accounts by enhancing the authentication process beyond simple passwords.

  • Identification and Authentication (organizational Users) | Multi-factor Authentication to Non-privileged Accounts

    IA-2 (2) requires the implementation of multi-factor authentication (MFA) for non-privileged organizational accounts, ensuring that all users, regardless of their privilege level, are authenticated using more than one factor. This control is designed to protect against unauthorized access by adding an additional layer of security to the authentication process. While privileged accounts have direct access to sensitive systems and data, non-privileged accounts may still hold access to critical or personally identifiable information (PII), so the need for enhanced security is still necessary. MFA for non-privileged accounts reduces the likelihood of successful attacks such as phishing or credential theft.

  • Identification and Authentication (organizational Users) | Individual Authentication with Group Authentication

    IA-2 (5) requires organizations to implement individual authentication combined with group authentication processes for users accessing systems and services. This control is designed to ensure that both the identity of the individual user is authenticated and that users who belong to specific groups (e.g., departments, roles, or teams) are verified through a collective authentication process. This is particularly useful in environments where users access shared resources, and group membership plays a critical role in determining the access privileges and controls. By combining individual and group authentication, organizations enhance security by ensuring that both personal and group-level permissions are validated.

  • Identification and Authentication (organizational Users) | Access to Accounts —separate Device

    IA-2 (6) requires that access to accounts should be provided from separate devices, ensuring that the device used for authentication is not the same as the device used to access critical or sensitive systems. This control is particularly relevant in environments where security risks may arise from the use of compromised devices, or where there is a need to enforce strong separation between the authentication process and the access point to sensitive systems. By separating the device used for authentication from the device used for system access, the likelihood of unauthorized access due to device compromise is significantly reduced.

  • Identification and Authentication (organizational Users) | Access to Accounts — Replay Resistant

    IA-2 (8) requires that systems and applications implement mechanisms to protect against replay attacks in the authentication process. A replay attack occurs when an attacker intercepts a valid authentication message and reuses it to gain unauthorized access. To prevent this, authentication systems must ensure that credentials, tokens, or other authentication data are resistant to replay. This typically involves using time-sensitive tokens, one-time passwords (OTPs), or cryptographic nonce values that cannot be reused.

  • Identification and Authentication (organizational Users) | Acceptance of PIV Credentials

    IA-2 (12) mandates that federal information systems accept Personal Identity Verification (PIV) credentials as a means of authentication for organizational users. PIV credentials are government-issued identity credentials that incorporate multifactor authentication and are used to verify the identity of users accessing federal systems. The control ensures that federal systems accept PIV credentials for access in a manner that meets NIST standards, particularly the guidelines provided in FIPS 201-2

  • Device Identification and Authentication

    IA-3 establishes the requirement for device identification and authentication to ensure that only authorized devices are allowed to access systems and resources. This control mandates that the system must authenticate devices before allowing them to connect, ensuring that only trusted and authorized devices can interact with the organization’s network or access protected resources. It is essential for securing the network perimeter and ensuring that unauthorized devices are prevented from compromising system security.

  • Identifier Management

    IA-4 pertains to the management of identifiers used for identification and authentication processes within an organization. This control requires organizations to implement procedures to establish, maintain, and retire user identifiers in a secure and consistent manner. The purpose is to ensure that identifiers are managed across their lifecycle—from creation and maintenance to deletion—without compromising security or accountability.

  • Identifier Management | Identify User Status

    IA-4 (4) pertains to ensuring that the status of users is clearly identified and managed in the context of their identifiers. It requires organizations to implement processes to maintain accurate records of user statuses, such as whether users are active, inactive, or on leave, in order to properly manage access controls. This helps prevent unauthorized access by ensuring that only users with an active, valid status can access critical systems or data.

  • Authenticator Management

    IA-5 requires organizations to establish and maintain effective management of authenticators (e.g., passwords, PINs, cryptographic keys, biometrics, smart cards, etc.) used to verify the identity of users accessing organizational systems. The control ensures that authenticators are securely handled, protected, and regularly updated to maintain the integrity of the authentication process.

    Authenticator management includes issuing, revoking, storing, and maintaining authenticators to ensure their security and proper usage in line with the organization's access control policies.

  • Authenticator Management | Password-based Authentication

    IA-5 (1) focuses on managing password-based authentication. This subcontrol ensures that password policies are established and enforced to maintain the security of user authentication, mitigating the risks associated with weak or compromised passwords. The subcontrol requires that passwords meet certain complexity, length, and expiration criteria, and are stored securely. Furthermore, it ensures that passwords are used correctly and that secure mechanisms are in place to reset or recover passwords when necessary.

  • Authenticator Management | Public Key-based Authentication

    IA-5 (2) focuses on the management and implementation of public key-based authentication methods. Public key-based authentication is a cryptographic technique that uses a key pair (a public key and a private key) to authenticate users or devices. It is more secure than traditional password-based methods, as it is less susceptible to attacks such as brute force or phishing. This subcontrol requires that organizations use public key infrastructure (PKI) to authenticate users and devices, ensuring the integrity, confidentiality, and non-repudiation of authentication processes.

  • Authenticator Management | Protection of Authenticators

    IA-5 (6) focuses on the protection of authenticators, specifically how organizations should safeguard authentication mechanisms, such as passwords, tokens, smart cards, or biometrics. This subcontrol requires that organizations implement measures to prevent unauthorized access to authenticators and protect them from misuse, theft, or compromise. Protecting authenticators is critical to ensuring that only authorized individuals can access systems, services, or data.

    Authenticators, such as passwords and security tokens, should be stored securely and transmitted over encrypted channels to maintain their integrity. This subcontrol outlines the need for organizations to adopt protective measures to safeguard authenticators throughout their lifecycle, including during storage, transmission, and use.

  • Authenticator Management | No Embedded Unencrypted Static Authenticators

    IA-5 (7) emphasizes the prohibition of static authenticators that are embedded and unencrypted within systems or applications. Static authenticators, such as unprotected passwords, API keys, or other authentication secrets, should never be stored in plaintext or in an unprotected manner. This subcontrol aims to reduce the risk of exposing authentication credentials that could be exploited by unauthorized users or attackers.

    Embedding unencrypted static authenticators within source code, application configurations, or database files increases the likelihood of them being discovered through vulnerabilities or misconfigurations. It is critical to implement secure storage practices, such as hashing, encryption, or the use of hardware security modules (HSMs), to ensure that any stored authentication information is protected from unauthorized access.

  • Authentication Feedback

    IA-6 focuses on providing feedback to users during the authentication process to help them understand whether the provided credentials (username, password, etc.) were correct. This control requires that feedback provided by the system should not reveal sensitive information about whether the user ID or the password was incorrect. For example, error messages should not specify which part of the credential (user ID or password) is incorrect. This helps to prevent attackers from using trial and error to guess valid usernames or passwords.

  • Cryptographic Module Authentication

    IA-7 addresses the requirement for the authentication of cryptographic modules used to protect sensitive information within an organization's system. The subcontrol mandates that cryptographic modules must be properly authenticated before use to ensure their integrity, security, and that they function as intended. Cryptographic module authentication ensures that systems are not using counterfeit or unauthorized cryptographic algorithms or keys, protecting the system from unauthorized access and misuse of sensitive information.

    This control specifically applies to systems that use cryptographic modules, such as those that use encryption, decryption, key management, digital signatures, or other cryptographic operations to secure data or authenticate users and devices

  • Identification and Authentication (non-organizational Users)

    IA-8 focuses on the identification and authentication processes for non-organizational users. Non-organizational users include contractors, vendors, and third-party service providers who may access organizational systems or data but are not directly employed by the organization. This control ensures that proper procedures are in place to verify the identity of non-organizational users before granting access to sensitive information or systems. This is critical for maintaining the security of the system and ensuring that access is limited to authorized individuals only.

    Non-organizational users often access systems remotely or through external interfaces, which increases the need for secure authentication methods to prevent unauthorized access, especially if sensitive data is involved. The control outlines the requirements for authenticating these external users, ensuring that they are properly identified and that their access is appropriately managed.

  • Identification and Authentication (non-organizational Users) | Acceptance of PIV Credentials from Other Agencies

    IA-8 (1) addresses the requirement for an organization to accept Personal Identity Verification (PIV) credentials issued by other federal agencies for non-organizational users. PIV credentials are used as an authentication mechanism to establish the identity of an individual. This subcontrol ensures that non-organizational users, such as contractors or vendors, from other government agencies can securely access systems by using their PIV credentials. It helps standardize authentication practices across federal agencies, fostering interoperability while ensuring secure access to sensitive resources.

    The acceptance of PIV credentials from other agencies simplifies user management and access control by allowing individuals who already possess valid, government-issued credentials to authenticate and gain access to organizational systems without needing separate, redundant credentialing processes.

  • Identification and Authentication (non-organizational Users) | Acceptance of External Authenticators

    IA-8 (2) addresses the requirement for organizations to accept external authenticators for non-organizational users when they need to access systems and services. External authenticators are authentication mechanisms provided by trusted third-party organizations or vendors, such as external identity providers (IdPs), authentication services, or single sign-on (SSO) systems. This subcontrol ensures that external users—such as contractors, vendors, or other partners—can securely access organizational systems using external credentials that meet the organization’s security requirements.

    By accepting external authenticators, the organization can facilitate secure and efficient authentication for external parties, reducing the need for maintaining separate, organization-specific authentication systems while adhering to the security standards outlined by FedRAMP.

  • Identification and Authentication (non-organizational Users) | Use of Defined Profiles

    IA-8 (4) requires organizations to ensure that non-organizational users (e.g., contractors, vendors, partners) who are authenticated for access to organizational resources use defined profiles. These profiles provide a standardized approach to how external users authenticate and interact with organizational systems, ensuring that access is consistent, secure, and aligned with security policies.

    Defined profiles help organizations control and manage non-organizational user identities in a way that supports compliance with security requirements while limiting exposure to risks. This subcontrol ensures that external users are assigned appropriate roles and privileges, preventing excessive access and ensuring that only necessary permissions are granted based on their specific needs.

  • Re-authentication

    IA-11 requires that organizations implement re-authentication mechanisms to ensure that a user continues to have valid authentication for an ongoing session. This control is crucial to mitigate risks from session hijacking or other types of unauthorized access that may occur during long-lived sessions. Re-authentication involves requiring the user to authenticate again at specific intervals or under certain conditions, such as after a certain period of inactivity or when sensitive operations are performed.

    Re-authentication enhances the overall security posture by ensuring that an authenticated user is still authorized to perform the actions they are attempting to do, especially in environments where sessions may persist over an extended period.

  • Identity Proofing

    IA-12 requires that organizations implement identity proofing mechanisms to ensure that users, devices, or entities claiming to be part of the organization are who they say they are before they are granted access to systems or resources. Identity proofing involves verifying the claimed identity using multiple methods, such as government-issued identification, biometric data, or other secure validation methods, to prevent unauthorized access due to identity fraud or impersonation.

    This control is essential to mitigate risks associated with unauthorized access by confirming that individuals, devices, or systems are valid and authorized to access particular services or networks. Effective identity proofing methods contribute to the overall security by ensuring that only legitimate users and devices are allowed into the system.

  • Identity Proofing | Identity Evidence

    IA-12 (2) requires organizations to collect and verify identity evidence when performing identity proofing for users or devices. Identity evidence can include physical documentation such as government-issued IDs, biometric information, or other authoritative sources that confirm the identity of the individual or entity seeking access. The evidence must be sufficiently robust to ensure that the claimed identity is legitimate and prevent the use of fraudulent or compromised information.

    This subcontrol focuses on the requirement for organizations to gather verifiable and reliable identity evidence as part of the identity proofing process. This ensures the integrity of the identity verification process and minimizes the risk of unauthorized access due to false or invalid identities.

  • Identity Proofing | Identity Evidence Validation and Verification

    IA-12 (3) requires that the identity evidence provided during identity proofing be validated and verified before access is granted. This subcontrol mandates the implementation of methods to ensure that the evidence presented is both authentic and corresponds to the individual or entity requesting access. Validation and verification involve checking that the evidence is genuine, unaltered, and matches the claimed identity. This step is essential to mitigate the risks of fraud, identity theft, and unauthorized access.

    Organizations must ensure that identity evidence is not only collected but also thoroughly validated through appropriate mechanisms. Verification should include cross-checking the evidence against trusted sources, such as government databases or identity management services, to confirm the legitimacy of the submitted evidence.

  • Identity Proofing | Address Confirmation

    IA-12 (5) mandates the verification of an individual’s address as part of the identity proofing process. Address confirmation is crucial to ensure that the person seeking access to a system or resource is legitimately associated with the provided address information. This step adds an additional layer of confidence to the overall identity proofing process and helps prevent fraudulent identity claims.

    Address confirmation typically involves validating the physical address provided by the individual against trusted sources, such as public records, third-party address verification services, or government databases. This verification can be performed using a variety of methods, including sending confirmation codes to the address or reviewing official documents that link the individual to the provided address.

FedRAMP's Incident Response (IR) ensures timely detection, reporting, and mitigation of security incidents through predefined procedures, continuous monitoring, and regular testing to minimize impact and enhance resilience.

  • Policy and Procedures

    IR-1 requires organizations to establish and maintain formal policies and procedures for incident response. This subcontrol ensures that an organization is prepared to manage security incidents effectively and efficiently, minimizing potential damage. These policies and procedures must define the roles, responsibilities, and actions required when an incident occurs and should guide the organization in detecting, reporting, analyzing, and responding to security incidents promptly.

    An incident response policy should cover all phases of incident management, from preparation and identification to containment, eradication, recovery, and lessons learned. Clear, documented processes ensure consistency in response efforts, provide accountability, and promote a structured approach to incident handling. The procedures should be tested regularly to ensure they are effective and align with industry standards and regulatory requirements.

  • Incident Response Training

    IR-2 requires organizations to provide ongoing training to personnel involved in incident response activities. This ensures that all individuals, including incident responders, security analysts, and other relevant personnel, are well-prepared to detect, respond to, and manage security incidents in a coordinated and efficient manner. Training should cover the roles and responsibilities of incident response, response protocols, and the technical skills necessary to mitigate and recover from incidents.

    The training should include awareness of the organization's incident response policy, procedures, tools, and communication protocols. Additionally, employees should be regularly tested through exercises and simulations to ensure they understand their roles and can respond effectively in a real incident.

  • Incident Response Testing

    IR-3 focuses on the requirement to conduct testing of the organization's incident response capability to ensure that it functions as expected during a real incident. Regular incident response testing allows the organization to assess its preparedness, identify gaps in its procedures, and refine its response strategies. Testing should cover all aspects of the response, including detection, analysis, containment, eradication, recovery, and lessons learned.

    Incident response testing can be done in various forms, such as tabletop exercises, functional exercises, and full-scale simulations. The goal is to verify that all personnel are familiar with their roles and responsibilities during an incident and that the organization can effectively handle security events while minimizing impact.

  • Incident Response Testing | Coordination with Related Plans

    IR-3 (2) focuses on ensuring that incident response testing is coordinated with other relevant organizational plans, including disaster recovery plans, business continuity plans, and continuity of operations plans. This coordination ensures that all plans align and that the organization is capable of executing an integrated response to any security or operational event.

    In practice, it means that incident response testing should not be isolated to security teams but should involve cross-functional teams to validate that organizational responses to various incidents (including IT and non-IT incidents) are synchronized, efficient, and effective. For example, if a cybersecurity incident leads to system outages, the business continuity and disaster recovery plans should be tested concurrently to ensure that critical business operations can continue or recover quickly.

  • Incident Handling

    IR-4 focuses on ensuring that an organization has defined procedures for handling incidents, including detection, reporting, assessment, response, and recovery activities. These procedures should cover both the technical and operational aspects of incident management. The goal is to provide a structured and effective approach for managing incidents, minimizing impact, and recovering from disruptions as quickly as possible.

    Incident handling includes a clear flow from the initial identification of an incident through to its resolution. Effective incident handling procedures ensure that the appropriate personnel, tools, and resources are in place to manage a variety of potential security incidents. This includes incidents such as unauthorized access attempts, data breaches, malware infections, and system outages.

  • Incident Handling | Automated Incident Handling Processes

    IR-4 (1) requires the automation of incident handling processes to improve the efficiency, consistency, and effectiveness of the response to security incidents. Automated incident handling processes involve leveraging security technologies and tools that can detect, classify, and respond to incidents in real-time, without human intervention. This can include using automated incident detection systems, alerting mechanisms, and predefined playbooks for response actions.

    Automation aims to reduce the response time, limit human error, and ensure consistent application of security policies. Additionally, it helps in scaling incident management efforts, especially during high-volume incidents, and improves the organization’s ability to respond swiftly to complex, fast-evolving threats.

  • Incident Monitoring

    IR-5 requires the implementation of procedures for continuous monitoring of incidents to ensure early detection and response. Incident monitoring involves the ongoing observation of system activities to identify potential security incidents, ensuring that anomalies or malicious activities are recognized promptly. This includes the use of automated tools to monitor network traffic, system logs, and user behavior, as well as leveraging threat intelligence feeds and other relevant data sources to identify potential threats in real time.

    An effective incident monitoring system ensures that security incidents are detected as soon as they occur, allowing for a quick response to mitigate potential damage. Additionally, continuous monitoring helps organizations to stay ahead of emerging threats by providing insights into attack patterns and trends.

  • Incident Reporting

    IR-6 mandates that organizations establish and maintain a structured process for reporting security incidents. This process should ensure timely and accurate reporting of incidents to internal and external stakeholders, such as senior management, affected individuals, regulatory bodies, and other relevant parties. The goal is to facilitate an organized and effective response to security incidents and to ensure compliance with applicable reporting requirements, including any legal or regulatory obligations.

    The incident reporting process should include clear procedures for documenting the nature, scope, and impact of an incident, as well as the response actions taken. This ensures that stakeholders are properly informed and can take appropriate action if necessary.

  • Incident Reporting | Automated Reporting

    Ensures automated mechanisms are used for incident reporting

  • Incident Reporting | Supply Chain Coordination

    Ensures incidents involving supply chain components are reported and managed

  • Incident Response Assistance

    Provides assistance for incident handling

  • Incident Response Assistance | Automation Support for Availability of Information and Support

    Uses automation to facilitate incident response

  • Incident Response Plan

    Ensures a documented plan for handling incidents

  • Information Spillage Response

    Manages incidents involving information spillage

  • Information Spillage Response | Training

    Ensures personnel are trained for spillage response

  • Information Spillage Response | Post-spill Operations

    Addresses actions after information spillage

  • Information Spillage Response | Exposure to Unauthorized Personnel

    Prevents unauthorized exposure of spilled data

FedRAMP's Maintenance (MA) ensures secure system upkeep through controlled updates, inspections, and repairs while preventing unauthorized access and maintaining operational integrity.

  • Policy and Procedures

    Establishes maintenance policies and procedures

  • Controlled Maintenance

    Ensures maintenance activities are authorized and tracked

  • Maintenance Tools

    Controls the use of maintenance tools

  • Maintenance Tools | Inspect Tools

    Ensures maintenance tools are inspected

  • Maintenance Tools | Inspect Media

    Ensures media used in maintenance is inspected

  • Maintenance Tools | Prevent Unauthorized Removal

    Prevents unauthorized removal of maintenance tools

  • Nonlocal Maintenance

    Controls maintenance performed remotely

  • Maintenance Personnel

    Controls access to maintenance personnel

  • Maintenance Personnel | Individuals Without Appropriate Access

    Prevents unauthorized individuals from performing maintenance

  • Timely Maintenance

    Ensures maintenance is performed in a timely manner

FedRAMP's Media Protection (MP) ensures secure handling, storage, and disposal of digital and physical media to prevent unauthorized access, data leaks, and information compromise.

  • Policy and Procedures

    Establishes media protection policies

  • Media Access

    Restricts access to digital and physical media.

  • Media Marking

    Requires proper labeling of media containing sensitive data.

  • Media Storage

    Ensures secure storage of sensitive media.

  • Media Transport

    Protects media during transport.

  • Media Sanitization

    Ensures proper disposal of sensitive media.

  • Media Use

    Restricts the use of removable media.

FedRAMP's Physical and Environmental Protection (PE) safeguards facilities, hardware, and data through access controls, surveillance, environmental monitoring, and disaster prevention to ensure system availability and security.

  • Policy and Procedures

    Establish, document, and disseminate physical and environmental protection policies.

  • Physical Access Authorizations

    Control access to facilities where information systems reside.

  • Physical Access Control

    Implement mechanisms to restrict physical access to information systems.

  • Access Control for Transmission

    Protect data in transit by restricting access to transmission equipment.

  • Access Control for Output Devices

    Secure printers, copiers, and other output devices handling sensitive information.

  • Monitoring Physical Access

    Implement monitoring mechanisms to detect unauthorized physical access.

  • Monitoring Physical Access | Intrusion Alarms and Surveillance Equipment

    Deploy alarms and surveillance systems to detect unauthorized entry.

  • Visitor Access Records

    Maintain logs of visitor access to secure facilities.

  • Power Equipment and Cabling

    Secure power sources and cabling to prevent tampering.

  • Emergency Shutoff

    Provide mechanisms for shutting off power in emergencies.

  • Emergency Power

    Ensure backup power sources are available for critical systems.

  • Emergency Lighting

    Ensures that emergency lighting is available in the event of power loss.

  • Fire Protection

    Establishes fire protection mechanisms for safeguarding assets.

  • Fire Protection | Detection Systems — Automatic Activation and Notification

    Requires automated fire detection and alert systems.

  • Fire Protection | Suppression Systems — Automatic Activation and Notification

    Requires automatic fire suppression mechanisms.

  • Environmental Controls

    Ensures environmental conditions are monitored and maintained.

  • Water Damage Protection

    Protects systems from water damage.

  • Delivery and Removal

    Controls asset deliveries and removals.

  • Alternate Work Site

    Establishes policies for alternate work locations.

FedRAMP's Planning (PL) ensures the development, documentation, and implementation of security policies, procedures, and system security plans to manage risks and maintain compliance.

  • Policy and Procedures

    Establishes planning policies and procedures.

  • System Security and Privacy Plans

    Develops security and privacy plans.

  • Rules of Behavior

    Defines expected behaviors for system users to prevent unauthorized activities.

  • Rules of Behavior | Social Media and External Site/application Usage Restrictions

    Specifies limitations on the use of social media and external applications for security purposes.

  • Security and Privacy Architectures

    Establishes the framework for integrating security and privacy into system architecture.

  • Baseline Selection

    Identifies and selects security control baselines based on system impact levels.

  • Baseline Tailoring

    Customizes security control baselines to align with specific system needs.

FedRAMP's Personnel Security (PS) ensures background checks, access controls, and security training to minimize insider threats and protect sensitive information.

  • Policy and Procedures

    Establishes personnel security policies and procedures.

  • Position Risk Designation

    Assigns risk levels to job positions based on security sensitivity.

  • Personnel Screening

    Conducts background checks on employees based on risk levels.

  • Personnel Screening | Information Requiring Special Protective Measures

    Requires additional screening for personnel accessing highly sensitive information.

  • Personnel Termination

    Defines procedures for revoking access upon employee termination.

  • Personnel Transfer

    Ensures access rights are updated when employees change roles.

  • Access Agreements

    Requires employees to formally acknowledge security responsibilities.

  • External Personnel Security

    Ensures security measures extend to external personnel (e.g., contractors, vendors).

  • Personnel Sanctions

    Defines disciplinary actions for non-compliance with security policies.

  • Position Descriptions

    Establishes security responsibilities in job descriptions.

FedRAMP's Risk Assessment (RA) ensures continuous identification, analysis, and mitigation of security risks through regular assessments, vulnerability scans, and threat modeling to enhance system resilience and compliance.

  • Policy and Procedures

    Defines the risk assessment policy and procedures.

  • Security Categorization

    Categorizes information and systems based on impact.

  • Risk Assessment

    Conducts regular risk assessments.

  • Risk Assessment | Supply Chain Risk Assessment

    Evaluates supply chain security risks.

  • Vulnerability Monitoring and Scanning

    Implements continuous vulnerability assessment.

  • Vulnerability Monitoring and Scanning | Update Vulnerabilities to Be Scanned

    Ensures up-to-date vulnerability scanning.

  • Vulnerability Monitoring and Scanning | Breadth and Depth of Coverage

    Expands vulnerability scanning scope.

  • Vulnerability Monitoring and Scanning | Privileged Access

    Scans privileged accounts for vulnerabilities.

  • Vulnerability Monitoring and Scanning | Public Disclosure Program

    Implements vulnerability disclosure mechanisms.

  • Risk Response

    Establishes risk response strategies.

  • Criticality Analysis

    Identifies and prioritizes critical system components.

FedRAMP's System and Services Acquisition (SA) ensures security is integrated into procurement, development, and maintenance processes by enforcing risk management, secure coding, and supply chain protections.

  • Policy and Procedures

    Establishes security policies and procedures for system and services acquisition.

  • Allocation of Resources

    Ensures that security resources are allocated to acquisition activities.

  • System Development Life Cycle

    Incorporates security into the system development lifecycle (SDLC).

  • Acquisition Process

    Ensures that security is a requirement in system and service acquisitions.

  • Acquisition Process | Functional Properties of Controls

    Functional Properties of Controls

  • Acquisition Process | Design and Implementation Information for Controls

    Design and Implementation Information for Controls

  • Acquisition Process | Functions, Ports, Protocols, and Services in Use

    Functions, Ports, Protocols, and Services in Use

  • Acquisition Process | Use of Approved PIV Products

    Use of Approved PIV Products

  • System Documentation

    Ensures that security documentation is maintained for acquired systems.

  • Security and Privacy Engineering Principles

    Integrates security engineering principles into system development and acquisition.

  • External System Services

    Ensures security oversight for external services.

  • External System Services | Risk Assessments and Organizational Approvals

    Risk Assessments and Organizational Approvals

  • External System Services | Identification of Functions, Ports, Protocols, and Services

    Identification of Functions, Ports, Protocols, and Services

  • External System Services | Processing, Storage, and Service Location

    Processing, Storage, and Service Location

  • Developer Configuration Management

    Requires secure configuration management for system development.

  • Developer Testing and Evaluation

    Ensures security testing and evaluation of developed systems.

  • Developer Testing and Evaluation | Static Code Analysis

    Static Code Analysis

  • Developer Testing and Evaluation | Threat Modeling and Vulnerability Analyses

    Threat Modeling and Vulnerability Analyses

  • Development Process, Standards, and Tools

    Defines processes, standards, and tools for secure development.

  • Development Process, Standards, and Tools | Criticality Analysis

    Requires organizations to analyze the criticality of system components.

  • Unsupported System Components

    Mandates managing unsupported or obsolete systems.

FedRAMP's System and Services Acquisition (SA) ensures security is integrated into procurement, development, and maintenance processes by enforcing risk management, secure coding, and supply chain protections.

  • Policy and Procedures

    Establishes security policies and procedures.

  • Separation of System and User Functionality

    Ensures separation between system-level and user-level functions.

  • Information in Shared System Resources

    Prevents unauthorized access to data in shared resources.

  • Denial-of-service Protection

    Implements protections against DoS attacks.

  • Boundary Protection

    Controls communications across system boundaries.

  • Boundary Protection | Access Points

    Restricts and monitors network access points.

  • Boundary Protection | External Telecommunications Services

    Ensures secure use of external telecom services.

  • Boundary Protection | Deny by Default — Allow by Exception

    Blocks all traffic unless explicitly permitted.

  • Boundary Protection | Split Tunneling for Remote Devices

    Prohibits split tunneling to prevent data leakage.

  • Boundary Protection | Route Traffic to Authenticated Proxy Servers

    Requires routing traffic through secure proxies.

  • Boundary Protection | Host-based Protection

    Requires host-based security mechanisms to protect endpoints.

  • Boundary Protection | Fail Secure

    Ensures systems default to a secure state upon failure.

  • Transmission Confidentiality and Integrity

    Protects data in transit from eavesdropping and tampering.

  • Transmission Confidentiality and Integrity | Cryptographic Protection

    Uses cryptography to secure data transmission.

  • Network Disconnect

    Ensures systems disconnect inactive sessions.

  • Cryptographic Key Establishment and Management

    Defines policies for key management.

  • Cryptographic Protection

    Ensures data protection using encryption.

  • Collaborative Computing Devices and Applications

    Implements security controls for collaboration tools.

  • Public Key Infrastructure Certificates

    Requires the use of PKI certificates for authentication.

  • Mobile Code

    Regulates the use of mobile code to prevent security risks.

  • Secure Name/address Resolution Service (authoritative Source)

    Ensures authoritative name/address resolution services protect integrity and authenticity.

  • Secure Name/address Resolution Service (recursive or Caching Resolver)

    Ensures integrity and authenticity of recursive/caching name/address resolution.

  • Architecture and Provisioning for Name/address Resolution Service

    Ensures secure design and implementation of name/address resolution services.

  • Session Authenticity

    Protects session integrity through authentication mechanisms.

  • Protection of Information at Rest

    Protects stored sensitive data from unauthorized access.

  • Protection of Information at Rest | Cryptographic Protection

    Encrypts information at rest using cryptographic methods.

  • Process Isolation

    Ensures isolation of processes to prevent unauthorized access.

  • System Time Synchronization

    Ensures accurate and synchronized system time across components.

  • System Time Synchronization | Synchronization with Authoritative Time Source

    Requires systems to sync time with a secure, authoritative source.

FedRAMP's System and Information Integrity (SI) ensures continuous monitoring, vulnerability management, and malware protection to detect, prevent, and respond to security threats, ensuring data accuracy and system reliability.

  • Policy and Procedures

    Establishes system integrity policies and procedures.

  • Flaw Remediation

    Ensures timely detection and remediation of security flaws.

  • Flaw Remediation | Automated Flaw Remediation Status

    Automates the detection and remediation of vulnerabilities.

  • Flaw Remediation | Time to Remediate Flaws and Benchmarks for Corrective Actions

    Defines timelines for vulnerability remediation.

  • Malicious Code Protection

    Protects systems against malware and other malicious code.

  • System Monitoring

    Ensures continuous monitoring of systems for security threats.

  • System Monitoring | System-wide Intrusion Detection System

    Implements IDS for organization-wide threat detection.

  • System Monitoring | Automated Tools and Mechanisms for Real-time Analysis

    Uses automated tools for real-time security event analysis.

  • System Monitoring | Inbound and Outbound Communications Traffic

    Inbound and Outbound Communications Traffic

  • System Monitoring | System-generated Alerts

    Automate alerts for suspicious activities.

  • System Monitoring | Correlate Monitoring Information

    Aggregates security logs for threat detection.

  • System Monitoring | Analyze Traffic and Covert Exfiltration

    Detects hidden data exfiltration techniques.

  • System Monitoring | Host-based Devices

    Uses host-based monitoring for security threats.

  • Security Alerts, Advisories, and Directives

    Implements alerting mechanisms for security threats.

  • Security and Privacy Function Verification

    Verifies effectiveness of security controls.

  • Software, Firmware, and Information Integrity

    Ensures integrity of software and firmware.

  • Software, Firmware, and Information Integrity | Integrity Checks

    Conducts regular software integrity verifications.

  • Software, Firmware, and Information Integrity | Integration of Detection and Response

    Integration of detection and response mechanisms to ensure software, firmware, and information integrity.

  • Spam Protection

    Protection against spam and malicious email threats.

  • Spam Protection | Automatic Updates

    Automatic updates for spam protection systems.

  • Information Input Validation

    Validation of information input to prevent unauthorized data entry.

  • Error Handling

    Handling and logging of errors to prevent information leakage.

  • Information Management and Retention

    Policy and procedures for supply chain risk management (SCRM).

  • Memory Protection

    Supply Chain Risk Management Plan.

FedRAMP's Supply Chain Risk Management (SR) ensures the identification, assessment, and mitigation of risks from external vendors and service providers to protect system integrity, confidentiality, and availability.

  • Policy and Procedures

    Implementation of supply chain controls and processes.

  • Supply Chain Risk Management Plan

    Assessments and reviews of supplier security practices.

  • Supply Chain Risk Management Plan | Establish SCRM Team

    Verification of component authenticity to prevent counterfeit products.

  • Supply Chain Controls and Processes

    Ensures the organization establishes and maintains controls for supply chain security.

  • Acquisition Strategies, Tools, and Methods

    Requires organizations to implement security-focused acquisition strategies.

  • Supplier Assessments and Reviews

    Ensures ongoing evaluation of suppliers’ security compliance.

  • Notification Agreements

    Establishes formal agreements for supply chain risk notifications.

  • Inspection of Systems or Components

    Mandates physical and logical inspections of supply chain components.

  • Component Authenticity

    Requires verification of IT component authenticity.

  • Component Authenticity | Anti-counterfeit Training

    Requires training personnel on detecting counterfeit components.

  • Component Authenticity | Configuration Control for Component Service and Repair

    Ensures security controls for servicing and repairing components.

  • Component Disposal

    Requires secure disposal of IT components.