The service provider defines the time period of inactivity for device identifiers.
-For DoD clouds, see DoD cloud website for specific DoD requirements that go above and beyond FedRAMP https://public.cyber.mil/dccs/.
Should use a shorter timeframe than AC-12.
CSPs have the option to provide a separation of duties matrix as an attachment to the SSP.
Examples of security functions include but are not limited to: establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters, system programming, system and security administration, other privileged functions.
If not performed as part of a Configuration Baseline check, then there must be documented agreement on how to provide results of verification and the necessary periodicity of the verification by the service provider. The documented agreement on how to provide verification of the results are approved and accepted by the JAB/AO.
If performed as part of a Configuration Baseline check, then the % of items requiring setting that are checked and that pass (or fail) check can be provided.
The interrelated controls of AC-20, CA-3, and SA-9 should be differentiated as follows:
AC-20 describes system access to and from external systems.
@@ -3773,7 +3773,7 @@Coordination between service provider and consumer shall be documented and accepted by the JAB/AO.
Annually or whenever changes in the threat environment are communicated to the service provider by the JAB/AO.
For client-server transactions, the number of bytes sent and received gives bidirectional transfer information that can be helpful during an investigation or inquiry.
Note that this enhancement requires the use of cryptography which must be compliant with Federal requirements and utilize FIPS validated or NSA approved cryptography (see SC-13.)
The service provider must support Agency requirements to comply with M-21-31 (https://www.whitehouse.gov/wp-content/uploads/2021/08/M-21-31-Improving-the-Federal-Governments-Investigative-and-Remediation-Capabilities-Related-to-Cybersecurity-Incidents.pdf)
The service provider is encouraged to align with M-21-31 where possible
Reference FedRAMP Annual Assessment Guidance.
POA&Ms must be provided at least monthly.
Reference FedRAMP-POAM-Template
Significant change is defined in NIST Special Publication 800-37 Revision 2, Appendix F and according to FedRAMP Significant Change Policies and Procedures. The service provider describes the types of changes to the information system or the environment of operations that would impact the risk posture. The types of changes are approved and accepted by the JAB/AO.
CSOs with more than one agency ATO must implement a collaborative Continuous Monitoring (ConMon) approach described in the FedRAMP Guide for Multi-Agency Continuous Monitoring. This requirement applies to CSOs authorized via the Agency path as each agency customer is responsible for performing ConMon oversight. It does not apply to CSOs authorized via the JAB path because the JAB performs ConMon oversight.
FedRAMP does not provide a template for the Continuous Monitoring Plan. CSPs should reference the FedRAMP Continuous Monitoring Strategy Guide when developing the Continuous Monitoring Plan.
Reference the FedRAMP Penetration Test Guidance.
See the FedRAMP Documents page> Penetration Test Guidance
https://www.FedRAMP.gov/documents/
@@ -4811,7 +4811,7 @@Significant change is defined in NIST Special Publication 800-37 Revision 2, Appendix F.
The service provider establishes a central means of communicating major changes to or developments in the information system or environment of operations that may affect its services to the federal government and associated service consumers (e.g., electronic bulletin board, web status page). The means of communication are approved and accepted by the JAB/AO.
In accordance with record retention policies and procedures.
The service provider shall ensure that checklists for configuration settings are Security Content Automation Protocol (SCAP) validated or SCAP compatible (if validated checklists are not available).
Compliance checks are used to evaluate configuration settings and provide general insight into the overall effectiveness of configuration management activities. CSPs and 3PAOs typically combine compliance check findings into a single CM-6 finding, which is acceptable. However, for initial assessments, annual assessments, and significant change requests, FedRAMP requires a clear understanding, on a per-control basis, where risks exist. Therefore, 3PAOs must also analyze compliance check findings as part of the controls assessment. Where a direct mapping exists, the 3PAO must document additional findings per control in the corresponding SAR Risk Exposure Table (RET), which are then documented in the CSP's Plan of Action and Milestones (POA&M). This will likely result in the details of individual control findings overlapping with those in the combined CM-6 finding, which is acceptable.
During monthly continuous monitoring, new findings from CSP compliance checks may be combined into a single CM-6 POA&M item. CSPs are not required to map the findings to specific controls because controls are only assessed during initial assessments, annual assessments, and significant change requests.
@@ -5284,7 +5284,7 @@This control refers to software deployment by CSP personnel into the production environment. The control requires a policy that states conditions for deploying software. This control shall be implemented in a technical manner on the information system to only allow programs to run that adhere to the policy (i.e. allow-listing). This control is not to be based off of strictly written policy on what is allowed or not allowed to run.
FedRAMP does not provide a template for the Configuration Management Plan. However, NIST SP 800-128, Guide for Security-Focused Configuration Management of Information Systems, provides guidelines for the implementation of CM controls as well as a sample CMP outline in Appendix D of the Guide
If digital signatures/certificates are unavailable, alternative cryptographic integrity checks (hashes, self-signed certs, etc.) can be utilized.
The service provider may determine what is considered a sufficient degree of separation between the primary and alternate processing sites, based on the types of threats that are of concern. For one particular type of threat (i.e., hostile cyber attack), the degree of separation between sites will be less relevant.
Note that this enhancement requires the use of cryptography which must be compliant with Federal requirements and utilize FIPS validated or NSA approved cryptography (see SC-13.)
All uses of encrypted virtual private networks must meet all applicable Federal requirements and architecture, dataflow, and security and privacy controls must be documented, assessed, and authorized to operate.
"Phishing-resistant" authentication refers to authentication processes designed to detect and prevent disclosure of authentication secrets and outputs to a website or application masquerading as a legitimate system.
Multi-factor authentication must be phishing-resistant.
Multi-factor authentication to subsequent components in the same user domain is not required.
Multi-factor authentication must be phishing-resistant.
Multi-factor authentication to subsequent components in the same user domain is not required.
PIV=separate device. Please refer to NIST SP 800-157 Guidelines for Derived Personal Identity Verification (PIV) Credentials.
See SC-13 Guidance for more information on FIPS-validated or NSA-approved cryptography.
Include Common Access Card (CAC), i.e., the DoD technical implementation of PIV/FIPS 201/HSPD-12.
Authenticators must be compliant with NIST SP 800-63-3 Digital Identity Guidelines IAL, AAL, FAL level 3. Link https://pages.nist.gov/800-63-3
SP 800-63C Section 6.2.3 Encrypted Assertion requires that authentication assertions be encrypted when passed through third parties, such as a browser. For example, a SAML assertion can be encrypted using XML-Encryption, or an OpenID Connect ID Token can be encrypted using JSON Web Encryption (JWE).
For cases where technology doesn't allow multi-factor authentication, these rules should be enforced: must have a minimum length of 14 characters and must support all printable ASCII characters.
For emergency use accounts, these rules should be enforced: must have a minimum length of 14 characters, must support all printable ASCII characters, and passwords must be changed if used.
Note that (c) and (d) require the use of cryptography which must be compliant with Federal requirements and utilize FIPS validated or NSA approved cryptography (see SC-13).
In this context, prohibited static storage refers to any storage where unencrypted authenticators, such as passwords, persist beyond the time required to complete the access process.
If a single user authentication domain is used to access multiple systems, such as in single-sign-on, then only a single authenticator is required.
For components subject to configuration baseline(s) (such as STIG or CIS,) the time period should conform to the baseline standard.
The fixed time period cannot exceed the limits set in SP 800-63. At this writing they are:
In accordance with NIST SP 800-63A Enrollment and Identity Proofing
In accordance with NIST SP 800-63A Enrollment and Identity Proofing
Second parameter not-applicable
Equipment and procedures may be tested or validated for effectiveness
Significant change is defined in NIST Special Publication 800-37 Revision 2, Appendix F.
Significant change is defined in NIST Special Publication 800-37 Revision 2, Appendix F.
See the FedRAMP Documents page> Vulnerability Scanning Requirements https://www.FedRAMP.gov/documents/
to include all Authorizing Officials; for JAB authorizations to include FedRAMP
Informational findings from a scanner are detailed as a returned result that holds no vulnerability risk or severity and for FedRAMP does not require an entry onto the POA&M or entry onto the RET during any assessment phase.
Warning findings, on the other hand, are given a risk rating (low, moderate, high or critical) by the scanning solution and should be treated like any other finding with a risk or severity rating for tracking purposes onto either the POA&M or RET depending on when the findings originated (during assessments or during monthly continuous monitoring). If a warning is received during scanning, but further validation turns up no actual issue then this item should be categorized as a false positive. If this situation presents itself during an assessment phase (initial assessment, annual assessment or any SCR), follow guidance on how to report false positives in the Security Assessment Report (SAR). If this situation happens during monthly continuous monitoring, a deviation request will need to be submitted per the FedRAMP Vulnerability Deviation Request Form.
@@ -10287,7 +10287,7 @@The service provider must comply with Federal Acquisition Regulation (FAR) Subpart 7.103, and Section 889 of the John S. McCain National Defense Authorization Act (NDAA) for Fiscal Year 2019 (Pub. L. 115-232), and FAR Subpart 4.21, which implements Section 889 (as well as any added updates related to FISMA to address security concerns in the system acquisitions process).
The use of Common Criteria (ISO/IEC 15408) evaluated products is strongly preferred.
See https://www.niap-ccevs.org/Product/index.cfm or https://www.commoncriteriaportal.org/products/.
@@ -10967,7 +10967,7 @@SC-7 (b) should be met by subnet isolation. A subnetwork (subnet) is a physically or logically segmented section of a larger network defined at TCP/IP Layer 3, to both minimize traffic and, important for a FedRAMP Authorization, add a crucial layer of network isolation. Subnets are distinct from VLANs (Layer 2), security groups, and VPCs and are specifically required to satisfy SC-7 part b and other controls. See the FedRAMP Subnets White Paper (https://www.fedramp.gov/assets/resources/documents/FedRAMP_subnets_white_paper.pdf) for additional information.
For JAB Authorization, CSPs shall include details of this control in their Architecture Briefing
For each instance of data in transit, confidentiality AND integrity should be through cryptography as specified in SC-8 (1), physical means as specified in SC-8 (5), or in combination.
@@ -11255,7 +11255,7 @@SC-8 (5)-1 [a hardened or alarmed carrier Protective Distribution System (PDS) when outside of Controlled Access Area (CAA)]
SC-8 (5)-2 [prevent unauthorized disclosure of information AND detect changes to information]
SC-8 (5) applies when physical protection has been selected as the method to protect confidentiality and integrity. For physical protection, data in transit must be in either a Controlled Access Area (CAA), or a Hardened or alarmed PDS.
@@ -11294,16 +11294,16 @@Please ensure SSP Section 10.3 Cryptographic Modules Implemented for Data At Rest (DAR) and Data In Transit (DIT) is fully populated for reference in this control.
See M-22-09, including "Agencies encrypt all DNS requests and HTTP traffic within their environment"
SC-8 (1) applies when encryption has been selected as the method to protect confidentiality and integrity. Otherwise refer to SC-8 (5). SC-8 (1) is strongly encouraged.
Note that this enhancement requires the use of cryptography which must be compliant with Federal requirements and utilize FIPS validated or NSA approved cryptography (see SC-13.)
When leveraging encryption from the underlying IaaS/PaaS: While some IaaS/PaaS services provide encryption by default, many require encryption to be configured, and enabled by the customer. The CSP has the responsibility to verify encryption is properly configured.
See references in NIST 800-53 documentation.
Must meet applicable Federal Cryptographic Requirements. See References Section of control.
Wildcard certificates may be used internally within the system, but are not permitted for external customer access to the system.
This control applies to all use of cryptography. In addition to encryption, this includes functions such as hashing, random number generation, and key generation. Examples include the following:
The requirement for FIPS 140 validation, as well as timelines for acceptance of FIPS 140-2, and 140-3 can be found at the NIST Cryptographic Module Validation Program (CMVP).
https://csrc.nist.gov/projects/cryptographic-module-validation-program
For NSA-approved cryptography, the National Information Assurance Partnership (NIAP) oversees a national program to evaluate Commercial IT Products for Use in National Security Systems. The NIAP Product Compliant List can be found at the following location:
https://www.niap-ccevs.org/Product/index.cfm
When leveraging encryption from underlying IaaS/PaaS: While some IaaS/PaaS provide encryption by default, many require encryption to be configured, and enabled by the customer. The CSP has the responsibility to verify encryption is properly configured.
Moving to non-FIPS CM or product is acceptable when:
At a minimum, this control applies to cryptography in use for the following controls: AU-9(3), CP-9(8), IA-2(6), IA-5(1), MP-5, SC-8(1), and SC-28(1).
Authoritative DNS servers must be geolocated in accordance with SA-9 (5).
SC-20 applies to use of external authoritative DNS to access a CSO from outside the boundary.
External authoritative DNS servers may be located outside an authorized environment. Positioning these servers inside an authorized boundary is encouraged.
CSPs are recommended to self-check DNSSEC configuration through one of many available analyzers such as Sandia National Labs (https://dnsviz.net)
Internal recursive DNS servers must be located inside an authorized environment. It is typically within the boundary, or leveraged from an underlying IaaS/PaaS.
Accepting an unsigned reply is acceptable
SC-21 applies to use of internal recursive DNS to access a domain outside the boundary by a component inside the boundary.
- DNSSEC resolution to access a component inside the boundary is excluded.
@@ -11541,15 +11541,15 @@The organization supports the capability to use cryptographic mechanisms to protect information at rest.
When leveraging encryption from underlying IaaS/PaaS: While some IaaS/PaaS services provide encryption by default, many require encryption to be configured, and enabled by the customer. The CSP has the responsibility to verify encryption is properly configured.
Note that this enhancement requires the use of cryptography in accordance with SC-13.
Organizations should select a mode of protection that is targeted towards the relevant threat scenarios.
Examples:
@@ -11604,7 +11604,7 @@The service provider synchronizes the system clocks of network computers that run operating systems other than Windows to the Windows Server Domain Controller emulator or to the same time source for that server.
Synchronization of system clocks improves the accuracy of log analysis.
See US-CERT Incident Response Reporting Guidelines.
In accordance with the incident response plan.
When CSO sends email on behalf of the government as part of the business offering, Control Description should include implementation of Domain-based Message Authentication, Reporting & Conformance (DMARC) on the sending domain for outgoing messages as described in DHS Binding Operational Directive (BOD) 18-01.
https://cyber.dhs.gov/bod/18-01/
CSPs should confirm DMARC configuration (where appropriate) to ensure that policy=reject and the rua parameter includes reports@dmarc.cyber.dhs.gov. DMARC compliance should be documented in the SI-08 control implementation solution description, and list the FROM: domain(s) that will be seen by email recipients.
NSO for non-privileged users. Attestation for privileged users related to multi-factor identification and authentication.
FED - This is related to agency data and agency policy solution.
FED - This is related to agency data and agency policy solution.
NSO - All access to Cloud SaaS are via web services and/or API. The device accessed from or whether via wired or wireless connection is out of scope. Regardless of device accessed from, must utilize approved remote access methods (AC-17), secure communication with strong encryption (SC-13), key management (SC-12), and multi-factor authentication for privileged access (IA-2[1]).
NSO - All access to Cloud SaaS are via web service and/or API. The device accessed from is out of the scope. Regardless of device accessed from, must utilize approved remote access methods (AC-17), secure communication with strong encryption (SC-13), key management (SC-12), and multi-factor authentication for privileged access (IA-2 [1]).
NSO - Loss of availability of the audit data has been determined to have little or no impact to government business/mission needs.
NSO - Loss of availability of the audit data has been determined as little or no impact to government business/mission needs.
Condition: There are connection(s) to external systems. Connections (if any) shall be authorized and must: 1) Identify the interface/connection. 2) Detail what data is involved and its sensitivity. 3) Determine whether the connection is one-way or bi-directional. 4) Identify how the connection is secured.
Attestation - for compliance with FedRAMP Tailored LI-SaaS Continuous Monitoring Requirements.
Condition: There are connection(s) to external systems. Connections (if any) shall be authorized and must: 1) Identify the interface/connection. 2) Detail what data is involved and its sensitivity. 3) Determine whether the connection is one-way or bi-directional. 4) Identify how the connection is secured.
Required - Specifically include details of least functionality.
The service provider shall ensure that checklists for configuration settings are Security Content Automation Protocol (SCAP) (http://scap.nist.gov/) validated or SCAP compatible (if validated checklists are not available).
Information on the USGCB checklists can be found at: https://csrc.nist.gov/Projects/United-States-Government-Configuration-Baseline.
NSO- Not directly related to protection of the data.
NSO - Boundary is specific to SaaS environment; all access is via web services; users' machine or internal network are not contemplated. External services (SA-9), internal connection (CA-9), remote access (AC-17), and secure access (SC-12 and SC-13), and privileged authentication (IA-2[1]) are considerations.
NSO - Loss of availability of the SaaS has been determined as little or no impact to government business/mission needs.
NSO - Loss of availability of the SaaS has been determined as little or no impact to government business/mission needs.
NSO - Loss of availability of the SaaS has been determined as little or no impact to government business/mission needs.
NSO - Loss of availability of the SaaS has been determined as little or no impact to government business/mission needs.
NSO for non-privileged users. Attestation for privileged users related to multi-factor identification and authentication - specifically include description of management of service accounts.
FedRAMP requires a minimum of multi-factor authentication for all Federal privileged users, if acceptance of PIV credentials is not supported. The implementation status and details of how this control is implemented must be clearly defined by the CSP.
Condition: Must document and assess for privileged users. May attest to this control for non-privileged users. FedRAMP requires a minimum of multi-factor authentication for all Federal privileged users, if acceptance of PIV credentials is not supported. The implementation status and details of how this control is implemented must be clearly defined by the CSP.
Condition: Must document and assess for privileged users. May attest to this control for non-privileged users. FedRAMP requires a minimum of multi-factor authentication for all Federal privileged users, if acceptance of PIV credentials is not supported. The implementation status and details of how this control is implemented must be clearly defined by the CSP.
Attestation - Specifically attest to US-CERT compliance.
Condition: Control is not inherited from a FedRAMP-authorized PaaS or IaaS.
Condition: Control is not inherited from a FedRAMP-authorized PaaS or IaaS.
Condition: Control is not inherited from a FedRAMP-authorized PaaS or IaaS.
Condition: Control is not inherited from a FedRAMP-authorized PaaS or IaaS.
Condition: Control is not inherited from a FedRAMP-authorized PaaS or IaaS.
Condition: Control is not inherited from a FedRAMP-authorized PaaS or IaaS.
Condition: Control is not inherited from a FedRAMP-authorized PaaS or IaaS.
Condition: Control is not inherited from a FedRAMP-authorized PaaS or IaaS.
Condition: Control is not inherited from a FedRAMP-authorized PaaS or IaaS.
Condition: Control is not inherited from a FedRAMP-authorized PaaS or IaaS.
Condition: Control is not inherited from a FedRAMP-authorized PaaS or IaaS.
Condition: Control is not inherited from a FedRAMP-authorized PaaS or IaaS.
Condition: Control is not inherited from a FedRAMP-authorized PaaS or IaaS.
Condition: Control is not inherited from a FedRAMP-authorized PaaS or IaaS.
Attestation - Specifically stating that any third-party security personnel are treated as CSP employees.
Condition: If availability is a requirement, define protections in place as per control requirement.
Condition: If implementing need to detail how they meet it or don't meet it.
NSO - Not directly related to the security of the SaaS.
Attestation - Specifically related to US-CERT and FedRAMP communications procedures.
The service provider defines the time period of inactivity for device identifiers.
For DoD clouds, see DoD cloud website for specific DoD requirements that go above and beyond FedRAMP https://public.cyber.mil/dccs/.
Should use a shorter timeframe than AC-12.
CSPs have the option to provide a separation of duties matrix as an attachment to the SSP.
Examples of security functions include but are not limited to: establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters, system programming, system and security administration, other privileged functions.
If not performed as part of a Configuration Baseline check, then there must be documented agreement on how to provide results of verification and the necessary periodicity of the verification by the service provider. The documented agreement on how to provide verification of the results are approved and accepted by the JAB/AO.
If performed as part of a Configuration Baseline check, then the % of items requiring setting that are checked and that pass (or fail) check can be provided.
The interrelated controls of AC-20, CA-3, and SA-9 should be differentiated as follows:
AC-20 describes system access to and from external systems.
@@ -3324,7 +3324,7 @@Coordination between service provider and consumer shall be documented and accepted by the JAB/AO.
Annually or whenever changes in the threat environment are communicated to the service provider by the JAB/AO.
For client-server transactions, the number of bytes sent and received gives bidirectional transfer information that can be helpful during an investigation or inquiry.
The service provider must support Agency requirements to comply with M-21-31 (https://www.whitehouse.gov/wp-content/uploads/2021/08/M-21-31-Improving-the-Federal-Governments-Investigative-and-Remediation-Capabilities-Related-to-Cybersecurity-Incidents.pdf)
The service provider is encouraged to align with M-21-31 where possible
Reference FedRAMP Annual Assessment Guidance.
POA&Ms must be provided at least monthly.
Reference FedRAMP-POAM-Template
Significant change is defined in NIST Special Publication 800-37 Revision 2, Appendix F and according to FedRAMP Significant Change Policies and Procedures. The service provider describes the types of changes to the information system or the environment of operations that would impact the risk posture. The types of changes are approved and accepted by the JAB/AO.
CSOs with more than one agency ATO must implement a collaborative Continuous Monitoring (Con Mon) approach described in the FedRAMP Guide for Multi-Agency Continuous Monitoring. This requirement applies to CSPs authorized via the Agency path as each agency customer is responsible for performing Con Mon oversight. It does not apply to CSPs authorized via the JAB path because the JAB performs Con Mon oversight.
FedRAMP does not provide a template for the Continuous Monitoring Plan. CSPs should reference the FedRAMP Continuous Monitoring Strategy Guide when developing the Continuous Monitoring Plan.
Reference the FedRAMP Penetration Test Guidance.
See the FedRAMP Documents page> Penetration Test Guidance
https://www.FedRAMP.gov/documents/
@@ -4234,7 +4234,7 @@Significant change is defined in NIST Special Publication 800-37 Revision 2, Appendix F.
The service provider establishes a central means of communicating major changes to or developments in the information system or environment of operations that may affect its services to the federal government and associated service consumers (e.g., electronic bulletin board, web status page). The means of communication are approved and accepted by the JAB/AO.
In accordance with record retention policies and procedures.
The service provider shall ensure that checklists for configuration settings are Security Content Automation Protocol (SCAP) validated or SCAP compatible (if validated checklists are not available).
Compliance checks are used to evaluate configuration settings and provide general insight into the overall effectiveness of configuration management activities. CSPs and 3PAOs typically combine compliance check findings into a single CM-6 finding, which is acceptable. However, for initial assessments, annual assessments, and significant change requests, FedRAMP requires a clear understanding, on a per-control basis, where risks exist. Therefore, 3PAOs must also analyze compliance check findings as part of the controls assessment. Where a direct mapping exists, the 3PAO must document additional findings per control in the corresponding SAR Risk Exposure Table (RET), which are then documented in the CSP's Plan of Action and Milestones (POA&M). This will likely result in the details of individual control findings overlapping with those in the combined CM-6 finding, which is acceptable.
During monthly continuous monitoring, new findings from CSP compliance checks may be combined into a single CM-6 POA&M item. CSPs are not required to map the findings to specific controls because controls are only assessed during initial assessments, annual assessments, and significant change requests.
@@ -4589,7 +4589,7 @@This control refers to software deployment by CSP personnel into the production environment. The control requires a policy that states conditions for deploying software. This control shall be implemented in a technical manner on the information system to only allow programs to run that adhere to the policy (i.e. allow-listing). This control is not to be based off of strictly written policy on what is allowed or not allowed to run.
FedRAMP does not provide a template for the Configuration Management Plan. However, NIST SP 800-128, Guide for Security-Focused Configuration Management of Information Systems, provides guidelines for the implementation of CM controls as well as a sample CMP outline in Appendix D of the Guide
The service provider may determine what is considered a sufficient degree of separation between the primary and alternate processing sites, based on the types of threats that are of concern. For one particular type of threat (i.e., hostile cyber attack), the degree of separation between sites will be less relevant.
Note that this enhancement requires the use of cryptography which must be compliant with Federal requirements and utilize FIPS validated or NSA approved cryptography (see SC-13.)
All uses of encrypted virtual private networks must meet all applicable Federal requirements and architecture, dataflow, and security and privacy controls must be documented, assessed, and authorized to operate.
"Phishing-resistant" authentication refers to authentication processes designed to detect and prevent disclosure of authentication secrets and outputs to a website or application masquerading as a legitimate system.
Multi-factor authentication must be phishing-resistant.
Multi-factor authentication to subsequent components in the same user domain is not required.
Multi-factor authentication must be phishing-resistant.
Multi-factor authentication to subsequent components in the same user domain is not required.
PIV=separate device. Please refer to NIST SP 800-157 Guidelines for Derived Personal Identity Verification (PIV) Credentials.
See SC-13 Guidance for more information on FIPS-validated or NSA-approved cryptography.
Include Common Access Card (CAC), i.e., the DoD technical implementation of PIV/FIPS 201/HSPD-12.
Authenticators must be compliant with NIST SP 800-63-3 Digital Identity Guidelines IAL, AAL, FAL level 2. Link https://pages.nist.gov/800-63-3
SP 800-63C Section 6.2.3 Encrypted Assertion requires that authentication assertions be encrypted when passed through third parties, such as a browser. For example, a SAML assertion can be encrypted using XML-Encryption, or an OpenID Connect ID Token can be encrypted using JSON Web Encryption (JWE).
For cases where technology doesn't allow multi-factor authentication, these rules should be enforced: must have a minimum length of 14 characters and must support all printable ASCII characters.
For emergency use accounts, these rules should be enforced: must have a minimum length of 14 characters, must support all printable ASCII characters, and passwords must be changed if used.
Note that (c) and (d) require the use of cryptography which must be compliant with Federal requirements and utilize FIPS validated or NSA approved cryptography (see SC-13).
In this context, prohibited static storage refers to any storage where unencrypted authenticators, such as passwords, persist beyond the time required to complete the access process.
The fixed time period cannot exceed the limits set in SP 800-63. At this writing they are:
In accordance with NIST SP 800-63A Enrollment and Identity Proofing
In accordance with NIST SP 800-63A Enrollment and Identity Proofing
Second parameter not-applicable
Significant change is defined in NIST Special Publication 800-37 Revision 2, Appendix F.
Significant change is defined in NIST Special Publication 800-37 Revision 2, Appendix F.
See the FedRAMP Documents page> Vulnerability Scanning Requirements https://www.FedRAMP.gov/documents/
to include all Authorizing Officials; for JAB authorizations to include FedRAMP
Informational findings from a scanner are detailed as a returned result that holds no vulnerability risk or severity and for FedRAMP does not require an entry onto the POA&M or entry onto the RET during any assessment phase.
Warning findings, on the other hand, are given a risk rating (low, moderate, high or critical) by the scanning solution and should be treated like any other finding with a risk or severity rating for tracking purposes onto either the POA&M or RET depending on when the findings originated (during assessments or during monthly continuous monitoring). If a warning is received during scanning, but further validation turns up no actual issue then this item should be categorized as a false positive. If this situation presents itself during an assessment phase (initial assessment, annual assessment or any SCR), follow guidance on how to report false positives in the Security Assessment Report (SAR). If this situation happens during monthly continuous monitoring, a deviation request will need to be submitted per the FedRAMP Vulnerability Deviation Request Form.
@@ -9044,7 +9044,7 @@The service provider must comply with Federal Acquisition Regulation (FAR) Subpart 7.103, and Section 889 of the John S. McCain National Defense Authorization Act (NDAA) for Fiscal Year 2019 (Pub. L. 115-232), and FAR Subpart 4.21, which implements Section 889 (as well as any added updates related to FISMA to address security concerns in the system acquisitions process).
The use of Common Criteria (ISO/IEC 15408) evaluated products is strongly preferred.
See https://www.niap-ccevs.org/Product/index.cfm or https://www.commoncriteriaportal.org/products/.
@@ -9679,7 +9679,7 @@SC-7 (b) should be met by subnet isolation. A subnetwork (subnet) is a physically or logically segmented section of a larger network defined at TCP/IP Layer 3, to both minimize traffic and, important for a FedRAMP Authorization, add a crucial layer of network isolation. Subnets are distinct from VLANs (Layer 2), security groups, and VPCs and are specifically required to satisfy SC-7 part b and other controls. See the FedRAMP Subnets White Paper (https://www.fedramp.gov/assets/resources/documents/FedRAMP_subnets_white_paper.pdf) for additional information.
For JAB Authorization, CSPs shall include details of this control in their Architecture Briefing
For each instance of data in transit, confidentiality AND integrity should be through cryptography as specified in SC-8 (1), physical means as specified in SC-8 (5), or in combination.
@@ -9921,7 +9921,7 @@SC-8 (5)-1 [a hardened or alarmed carrier Protective Distribution System (PDS) when outside of Controlled Access Area (CAA)]
SC-8 (5)-2 [prevent unauthorized disclosure of information AND detect changes to information]
SC-8 (5) applies when physical protection has been selected as the method to protect confidentiality and integrity. For physical protection, data in transit must be in either a Controlled Access Area (CAA), or a Hardened or alarmed PDS.
@@ -9960,16 +9960,16 @@Please ensure SSP Section 10.3 Cryptographic Modules Implemented for Data At Rest (DAR) and Data In Transit (DIT) is fully populated for reference in this control.
See M-22-09, including "Agencies encrypt all DNS requests and HTTP traffic within their environment"
SC-8 (1) applies when encryption has been selected as the method to protect confidentiality and integrity. Otherwise refer to SC-8 (5). SC-8 (1) is strongly encouraged.
Note that this enhancement requires the use of cryptography which must be compliant with Federal requirements and utilize FIPS validated or NSA approved cryptography (see SC-13.)
When leveraging encryption from the underlying IaaS/PaaS: While some IaaS/PaaS services provide encryption by default, many require encryption to be configured, and enabled by the customer. The CSP has the responsibility to verify encryption is properly configured.
See references in NIST 800-53 documentation.
Must meet applicable Federal Cryptographic Requirements. See References Section of control.
Wildcard certificates may be used internally within the system, but are not permitted for external customer access to the system.
This control applies to all use of cryptography. In addition to encryption, this includes functions such as hashing, random number generation, and key generation. Examples include the following:
The requirement for FIPS 140 validation, as well as timelines for acceptance of FIPS 140-2, and 140-3 can be found at the NIST Cryptographic Module Validation Program (CMVP).
https://csrc.nist.gov/projects/cryptographic-module-validation-program
For NSA-approved cryptography, the National Information Assurance Partnership (NIAP) oversees a national program to evaluate Commercial IT Products for Use in National Security Systems. The NIAP Product Compliant List can be found at the following location:
https://www.niap-ccevs.org/Product/index.cfm
When leveraging encryption from underlying IaaS/PaaS: While some IaaS/PaaS provide encryption by default, many require encryption to be configured, and enabled by the customer. The CSP has the responsibility to verify encryption is properly configured.
Moving to non-FIPS CM or product is acceptable when:
At a minimum, this control applies to cryptography in use for the following controls: AU-9(3), CP-9(8), IA-2(6), IA-5(1), MP-5, SC-8(1), and SC-28(1).
Control Description should include how DNSSEC is implemented on authoritative DNS servers to supply valid responses to external DNSSEC requests.
SC-20 applies to use of external authoritative DNS to access a CSO from outside the boundary.
External authoritative DNS servers may be located outside an authorized environment. Positioning these servers inside an authorized boundary is encouraged.
CSPs are recommended to self-check DNSSEC configuration through one of many available analyzers such as Sandia National Labs (https://dnsviz.net)
Internal recursive DNS servers must be located inside an authorized environment. It is typically within the boundary, or leveraged from an underlying IaaS/PaaS.
Accepting an unsigned reply is acceptable
SC-21 applies to use of internal recursive DNS to access a domain outside the boundary by a component inside the boundary.
The organization supports the capability to use cryptographic mechanisms to protect information at rest.