Submit Your Question Below
Please post your IT security, audit or compliance questions here and our experts will respond with guidance.
Although it is premature to speculate on how much flexibility contractors and CSPs might have with respect to the DFARS 7012 requirement, early indications suggest that there will be little to no flexibility. The terms “meets” and “equivalent” by their very nature aren’t conducive to wiggle room. The DoD Procurement Toolbox Cybersecurity FAQ questions 110 through 117 provide commentary on the DFARS requirement concerning cloud systems, and their comments shed some light on how to interpret these terms. See, for example, the following verbiage:
- A113. Cloud systems handling CUI must “meet the same set of requirements” as a “CSP service authorized/approved by the FedRAMP program”
- A115. “The CSP meets the FedRAMP Moderate baseline security requirements”
- A116. “The CSP has to meet all of the requirements equivalent to the FedRAMP Moderate Baseline”
This language implies that word “equivalent” doesn’t really provide any wiggle room. The security requirements that must be followed is the FedRAMP moderate baseline exactly as it has been defined by the FedRAMP PMO. The word “meets” doesn’t provide much wiggle room either, since DoD clarifies that they expect “all of the requirements” to be addressed. The Rev 4 FedRAMP moderate baseline contains 325 controls, but most of those controls contains parts (e.g., a through g) and some of those parts contain subparts (e.g., a.1 and a.2). Does DoD really expect that CSPs have to address every part and sub-part of all 325 controls? That would seem to be unrealistic. Even FedRAMP authorized systems, which presumptively meet the DFARS 7012 requirement, do not full address everything. However, there is not much leeway either. Unfortunately, it’s not entirely clear at this point exactly how much flexibility there is. CSPs should expect DoD to be skeptical and risk averse. If a CSP’s security control assessment indicates that there are five high risk findings and 15 moderate risk findings, it seems unlikely that the DoD or CMMC C3PAO would consider the CSP to have meet the requirements. At the very least, CSPs should expect that even a single high risk finding, or more than very few moderate risk findings, will be treated as a red flag to be investigated further. The safest approach, of course, is to be very conservative and hope to address all but very few (e.g., less than 10) moderates a few low-risk findings.
In addition, CSPs should pay attention to the FedRAMP baseline controls that correspond to 800-171 controls that DoD has rated as potentially leading to significant risk of exploitation or exfiltration. These controls are important because DoD has indicated that systems handling CUI cannot pass a CMMC assessment unless these controls are fully implemented with no POA&Ms. It is reasonably likely that these controls will also need to be fully addressed in order to “meet” the FedRAMP moderate baseline. The FedRAMP moderate baseline is intended to provide a more rigorous standard in order to mitigate the increased risk of handling CUI in the cloud. Therefore, if full implementation of these significant-impact controls is needed to pass an assessment using the lesser standard for CMMC, it stands to reason that these controls must be fully implemented to meet the requirements of a more robust standard for FedRAMP equivalency as well. For that reason, SecureIT recommends that CSPs fully implement all FedRAMP baseline controls that correspond to 800-171 high impact controls. The significant-impact 800-171 controls are rated with a value of “5” in the Scoring Template that is included as Annex A within the NIST SP 800-171 DoD Assessment Methodology. There are forty-four 800-171 controls that are scored with a “5” value due to the significant risk of exploitation or exfiltration. These forty-four 800-171 controls can be mapped to the 800-53 controls that are part of the FedRAMP moderate baseline using Appendix D Mapping Tables within NIST SP 800-171r2. CSPs should fully meet all FedRAMP moderate baseline controls that map to one of the 800-171 controls that has been rated as a “5” by DoD’s scoring methodology.
Additional guidance on DFARS and FedRAMP Moderate Equivalency is coming via a SecureIT CMMC FAQ eBook. . Check here occasionally for details.
User laptops and mobile devices can present a difficult challenge to contractors subject to CMMC requirements. Managing those devices to meet asset management, vulnerability management, security monitoring, FIPS-validated encryption, and other compliance requirements can be technically challenging and expensive. One approach to consider is removing user endpoints from the scope of the CUI Boundary or otherwise lessen the requirements that apply to those devices. This can be achieved by implementing a virtual desktop architecture that keeps CUI off the user endpoints and therefore changes how user endpoints impact the scope or system boundary relevant to CMMC requirements. By making CUI less accessible to user endpoints, the security requirements that are applicable to those devices can be dramatically reduced or eliminated entirely.
A properly implemented virtual desktop infrastructure (VDI) can allow laptops and mobile devices to be treated as out-of-scope or customer risk-managed assets, depending on how restrictive controls are to limit virtual desktop access to local resources (e.g., clipboard, file system, printer, etc.). According to the CMMC v2.0 scoping guidance, assets that cannot handle CUI are completely out of scope for CMMC purposes. Assets (including laptops and mobile devices) that can but are not intended to handle CUI can be managed according to risk-based security policies defined by the contractor. These “Contractor Risk-managed Assets” (CRMA) do not need to comply with the full set of CMMC control requirements. Instead, contractors are only required to document the CRMAs (e.g., in the system inventory, in the system diagrams, and the system security plan) and the risk-based policies and procedures that are used to manage those assets. Of course, contractors must also manage the CRMAs according to those risk-based policies.
Additional information about the advantages of VDI to help narrow the CMMC system boundary, refer to SecureIT’s blog on “VDI for CUI.”
CMMC Level 2 , “Advanced” corresponds to contractors with CUI that doesn’t involve the highest level of sensitivity. There are four main ways that CMMC Level 2 differs from FISMA: the types of systems addressed, the control frameworks, the assessments, and the expectations for compliance.
- The types of systems addressed. FISMA is for Federal systems that are used by Government personnel or the public. If a contractor provides outsourced IT services to a Federal agency, the system is considered to be a Federal system and FISMA applies. In contrast, CMMC applies to non-Federal systems that are used internally by contractor personnel. If a contractor’s system is incidental to the delivery of a broader service to a Federal agency (e.g., services that are not primarily information processing), then the system is a non-Federal system and CMMC applies.
- The control frameworks. FISMA uses the NIST SP 800-53 control baselines for its control requirements. There are 261 controls related to confidentiality, availability, and integrity in the 800-53r4 moderate baseline, and 287 in the new 800-53r5 baseline. The CMMC Level 2 control requirements consist of 110 NIST SP 800-171 controls. The NIST 800-171 controls were summarized from the confidentiality controls in the 800-53r4 moderate baseline. NIST SP 800-171’s focus strictly on protecting the confidentiality of CUI means that controls that were relevant to availability or integrity are not included in 800-171, and therefore aren’t included in CMMC. For this reason, the CMMC Level 2 control set can be described as a subset of the FISMA control set.
- The assessments. FISMA entails independent assessments that are supposed to loosely follow the guidance in 800-53A. In practice, however, the level of detail and thoroughness of FISMA varies considerably due to no specific requirements or quality control mechanisms in place to ensure standardization of assessment processes and approaches. Furthermore, FISMA assessments are performed every year, with at least one-third of the controls assessed annually. In contrast, CMMC Level 2 allows for annual self-assessments and requires an independent assessment only for a subset of contractors that handle “prioritized” CUI that is especially sensitive or critical. For Level 2 systems that require an official, 3rd party assessment, the process is very formalized. Assessments must follow a rigorous process to ensure consistency, and multiple levels of quality assurance are in place. CMMC assessments can be performed only by highly experienced, trained, and specially accredited assessors that work under the oversight of formally accredited assessment organizations, under the oversight of the CMMC Accreditation Body (CMMC-AB). A CMMC certification will last 3 years, so DoD contractors will need to undergo a full assessment of all CMMC control practices triennially.
- Expectations for compliance. FISMA is designed to identify and disclose unmitigated risk so that the system owner can make a risk-based decision about authorizing the system for use. Accordingly, the Plan of Action and Milestones (POA&M) for FISMA simply list out the compliance gaps for the system owner’s review. Whether the risks associated with non-compliance are acceptable is completely up to the system owner’s discretion. In contrast, the DoD does not want to have to evaluate non-compliance to determine if the risk is acceptable, so there are constraints that make CMMC closer to a “pass-or-fail” framework with some While the rules around this flexibility are still being hashed out, the DoD has indicated that gaps will be accepted in a POA&M only if they impact less-significant controls, and those gaps must be resolved within 6 months. DoD has also indicated that a minimum score will be required to support a CMMC certification. Again, further details and guidance are pending.
The DoD updates to the DFARS clause in 1Q FY 2021 defined the requirement for contractors with respect to the DoD Assessment Methodology for NIST SP 800-171 compliance. (See DFARS clauses 7019 and 7020 here.) A Basic Assessment is a self-assessment performed by the contractor based on a review of the System Security Plan for their non-federal system housing CUI. Contractors have to follow the DoD assessment methodology (here) to calculate an overall compliance score for SP 800-171. According to the methodology, the contractor starts with 110 points and then subtracts 1, 3, or 5 points (depending on the criticality of each control) for each control that isn’t fully and properly implemented. The scoring mechanism does not give any credit for partially implemented controls. After a score is calculated, contractors can submit that score (and the estimated date of full compliance) to DoD via email or the SPRS system (instructions here).
According to the DFARS 7019 clause, contractors must submit an 800-171 compliance score to DoD in order to be eligible for an award. DoD has chosen to gradually introduce this requirement into contracts over FY21 – FY23.
The objective of the NIST 800-171 scoring process is to provide visibility to the DoD agencies about the level of contractor security compliance during the interim period while CMMC program is being phased in. Agencies will consider the contractor’s compliance score and the associated full remediation date as a key factor in granting an award. In addition, DoD has made each contractor responsible for ensuring the NIST 800-171 compliance of its subcontractors throughout the supply chain. Scores provide contractors visibility into the level of compliance and remediation date for potential subcontractors, and this could certainly factor into decisions concerning which firms will be granted subcontracts. This means that a bad score could impact the ability of a firm to obtain direct contracts from DoD as a prime, as well as subcontracts from further down the supply chain. In other words, a poor score (especially when combined with a less than aggressive date for achieving full compliance) may keep a contractor from getting new DoD business.
Fortunately, contractors can update their SPRS scores as often as they wish, and this suggests an approach that should be taken by any contractor with a poor score. To improve their score quickly, contractors should prioritize remediation actions that involve limited effort (e.g., “quick wins”) or that have a significant impact on the score (e.g., “big ticket items”). Prioritizing on these remediation actions often results in a contractor making significant improvement to their scores in a matter of a few months. The key is to stay focused on actions that impact the score and actually getting those remediation actions completed. As progress is made, contractors should periodically update the SPRS system (and notify relevant prime contractors) to reflect the continual improvement to their score.
Contractors can outsource IT services, but they cannot avoid accountability for those IT services being compliant with CMMC requirements. In short, any IT service provider used for processing, storing, or transmitting CUI needs to comply with all CMMC requirements. DoD and the CMMC-AB are still figuring out the terms of reciprocity for CMMC in terms of IT service providers that have other accreditations (like ISO 27001 or FedRAMP), but the particulars are not yet known. For now, CMMC Level 2 contractors can establish the compliance of their IT service providers in two ways: 1) Ensure the IT service is obtaining their own CMMC certification, which in turn allows the contractor to simply inherit controls that are the responsibility of the service provider without having to do anything else; or 2) include the IT service provider in the scope of the contractor’s CUI Boundary. This means that the IT service provider will need to provide potentially significant levels of documentation, evidence, and possibly interviews to support the contractor’s CMMC assessment. Keep in mind that if the IT service provider fails to fully implement the requisite controls, it is the contractor that is responsible for ensuring these control “gaps” are addressed or risk being denied certification.
The bottom line is that DoD contractors are on the hook to ensure that all their IT service providers meet all CMMC requirements before access is provided to CUI. Control practice AC.1.03 requires contractors to “verify … connections to and use of external information systems,” and this includes IT service providers. The requirement to “verify” those connections includes the responsibility for ensuring that all CMMC and other DFARS requirements are met if external IT service providers are used.
Besides ensuring compliance of IT service providers with CMMC control practices and maturity processes, contractors should not lose sight of other DFARS requirements that could impact the use of any third-party service providers. For example, the DFARS 7012 Safeguarding clause requires that contractors can use external cloud services for CUI only after requiring and ensuring that the cloud services meets security requirements equivalent to FedRAMP moderate and complies with additional requirements for incident handling, media protection, etc. DoD contractors that use cloud-based systems for CUI processing, storage, and/or transmission need to “require and ensure” that their cloud service providers meet these requirements. It goes without saying that security requirements equivalent to FedRAMP moderate significantly exceed the requirements for CMMC level 2 or NIST SP 800-171. However, it is important to clarify that this does not require a contractor’s CSP to achieve a full FedRAMP authorization. SecureIT can help clarify for DoD contractors or CSPs that provide services to DoD contractors how this DFARS 7012 requirement can be met. Please contact us for additional details.
The CMMC program employs progressively advanced levels, depending on the type and sensitivity of the information, to include Controlled Unclassified Information or “CUI”. Therefore, the definition of CUI is critical to the CMMC program. Many organizations treat CUI as if it were merely an abstract or conceptual description for data that is “critical” or “sensitive” information. If that were the case, identifying CUI would be subjective, making it difficult for organizations to tell if something is CUI or not. Fortunately, CUI has a specific, unambiguous definition that is concrete and objective. The official Government-wide definition of CUI is found here.
Controlled Unclassified Information (CUI) is information the Government creates or possesses, or that an entity creates or possesses for or on behalf of the Government, that a law, regulation, or Government-wide policy requires or permits an agency to handle using safeguarding or dissemination controls. However, CUI does not include classified information (see paragraph (e) of this section) or information a non-executive branch entity possesses and maintains in its own systems that did not come from, or was not created or possessed by or for, an executive branch agency or an entity acting for an agency.
This definition consists of several parts that are especially pertinent to Federal contractors:
- CUI does not include classified information, which requires much more robust controls than CUI does.
- CUI must either (1) have “come from” a Federal agency into the possession of a contractor or (2) have been “created or possessed … for” a Federal agency by a contractor acting “on behalf of the Government.” This means that CUI is not limited to information that the Government provides to the contractor. Information that is collected or produced by a contractor specifically for the performance of a service to the Federal Government might also be CUI. However, internal information that a contractor maintains in its systems that is not “from” the Government, not “for” the Government, and not “on behalf of the Government” cannot be CUI.
- CUI has safeguarding or disseminations controls defined in Federal laws, regulations, or Government-wise policies. Explicit Federal mandates are the reason CUI must be “controlled,” and those Federal legal mandates ultimately define whether information is CUI or not. If a Federal law, regulation, or Government-wide policy specifically identifies requirements for safeguarding or disseminated certain types of information, then that information is CUI. If not, then that information is not CUI.
Those three criteria are concrete, objective, and unambiguous, leaving little room for a contractor’s subjectivity or interpretation but also creating a huge problem. The volume of Federal laws and regulations is almost unimaginable. Each year, the Code of Federal Regulations grows by 60,000 – 100,000 pages. Fortunately, the National Archives and Records Administration (NARA) has done the leg work of reviewing the laws, regulations, and Government-wide policies to and compiled the results in centralized registry. The CUI registry (located here) lists all the categories of information that would be considered CUI. To identify what is CUI, organizations need to assess each of the 125 categories listed in the CUI registry and determine what information pertaining to Federal contracts corresponds to those CUI categories. Any information provided by the Government or produced by the contractor for or on behalf of the Government that matches a description of a subcategory in the CUI registry is by definition considered CUI. Information that does not match-up to a category in the CUI registry is not CUI, regardless of how “critical” or “sensitive” that information might be.
For further information, refer to SecureIT’s blog “Follow the CUI for CMMC Compliance.”
Not at all. In accordance with FISMA, the FedRAMP program is about identifying outstanding risks to allow the Federal agencies to make informed risk-based decisions about whether to use a system or not. For this reason, a CSP that doesn’t fully meet all of the requirements in the FedRAMP baseline does not per se “fail” the assessment. Any deficiencies in the controls are simply reported to Federal agencies for their evaluation.
The FedRAMP Tailored program for Low Impact SaaS CSPs is less rigid. For all other assessments, FedRAMP requires the 3PAO assessor recommend to the Federal agency (or the JAB) that the system be granted an authorization. That means that the 3PAO cannot submit the final assessment report unless they are comfortable recommending that the cloud system be authorized. In contrast, the FedRAMP template for Tailored LI-SaaS systems does not require the 3PAO assessor to recommend authorization. For LI-SaaS systems, the assessor merely reports their findings and outstanding risk for consideration by the agency’s authorizing official.
Furthermore, because the systems are low impact and don’t involve PII, agencies have more flexibility to accept risk. LI-SaaS CSPs are not required to fully implement the controls in the template and can implement alternative controls, as long as any gaps in control and the associated risks are fully disclosed by the CSP. The FedRAMP Tailored LI-SaaS Baseline Worksheet itself clarifies what the requirement to “Document and Assess” actually entails. “This does not mean that a vendor will necessarily have each control fully implemented or implemented as stated.” However, CSPs “must address how they meet (or don’t meet) the intent of the control” so that the assessor can more effectively perform an assessment. Furthermore, CSPs must also “detail any risks associated with the implementation” when documenting the controls in the template. The additional flexibility in the FedRAMP Tailored program for LI-SaaS systems means that there are no absolute requirements. However, as a practical matter, there are some controls that most agencies will insist need to be implemented, even for LI-SaaS. LI-SaaS CSPs should consider engaging a 3PAO or FedRAMP SME as an advisor to ensure that they have a solid control implementation for at least these controls.
For more information on FedRAMP Tailored, see SecureIT’s FedRAMP Tailored LI-SaaS Success Planning Guide
The US Government Configuration Baselines (USGCB) are not particularly relevant anymore. Only a handful of technologies were ever addressed, and these are out of date (e.g., Windows XP, Windows Vista, Windows 7, RHEL 5 desktop, and IE 7/8). Therefore, CSPs can safely ignore the FedRAMP-defined parameter for CM-6 (a) that requires the use of USGCB as the foundation of configuration baselines. Instead, organizations should follow the “Additional FedRAMP Requirements” and leverage the Center for Internet Security (CIS) Level 1 guidance. For system components and technologies that don’t have a CIS guide, organizations should use NIST’s National Checklist Program Repository to find another generally acceptable configuration hardening guide. Or, if needed, organizations can leverage guidance from the vendor and product user groups as a reference to define a customized list of configuration settings that meet the requirement of CM-6, namely, that the settings “reflect the most restrictive mode consistent with operational requirements.”
No, the 3PAO assessor has to perform penetration testing as part of the assessment. The pen test results, along with vulnerability scanning and control testing results, determine the findings and risk exposures that assessors identify on the Security Assessment Report (SAR) and are the basis on which the assessors recommend whether the cloud service be granted an authorization or not. Because the pen test is so important to the overall assessment, 3PAOs need to have confidence that the pen test was performed by competent and independent assessors and was adequately scoped to provide the proper coverage. Therefore, 3PAOs need to perform their own pen testing activities during the assessment process.
Furthermore, the scope of a typical penetration test will not provide adequate coverage of the attack scenarios and risks that FedRAMP requires. A FedRAMP pen test has a unique scope that corresponds to guidance provided by the FedRAMP PMO, including the following testing scenarios:
- Non-credentialed external attack on Internet-facing systems and components, including any routable IPs, URLs, and login pages that are accessible to the general public.
- Credentialed attack on the cloud system as an authorized user, including traditional OWASP testing for SaaS systems for browser-based systems, mobile transactions, and APIs.
- Tenant-to-tenant attacks within the target system, including specially crafted attacks to access data pertaining to another cloud tenant. Because cloud systems are defined by their multitenancy features, 3PAO penetration tests focus on this attack path because it specifically addresses a distinctive element of risk within cloud systems.
- Credentialed attack from the cloud system to the management system. The point of this scenario is to see if one tenant can leverage management system components as a stepping-stone to launch attacks on other tenants. Many components (e.g., backup systems, vulnerability scanning systems, AV systems, etc.) within the management system have access to multiple tenant environments and therefore could provide a stepping-stone for one tenant to reach other tenants or even all tenants.
- Attack on the content stored on a mobile device by mobile-based applications. The purpose of this scenario is to assess the risk to the system if a mobile device that is used to access the application is lost or stolen.
- Phishing attack on cloud system administrators. The intent of the phishing attack is to determine the likelihood that corporate workstations used by cloud system administrators could be compromised through social engineering.
- Simulated attack from a presumed remotely-owned corporate workstation to the cloud management system. The point of this scenario is to assess the likelihood that a breach of a corporate workstation could lead to a compromise of the cloud management system, and then ultimately the target cloud system. The assessor has to test a representative corporate workstation, but the rest of the test is usually simulated via a tabletop walkthrough with the cloud provider. The intent of this scenario is to obtain insight into the risk that an attack on a corporate asset could pivot to and therefore endanger the cloud system without conducting actual pen testing activities on the CSP’s corporate environment, which is technically out of scope for FedRAMP.
CSPs are usually surprised to learn about the last two testing scenarios because they involve corporate systems that are not within the FedRAMP authorization boundary. What may not be clear at first is that these two scenarios, when combined, represent a back-door threat to the cloud system. Adversaries that learn that Federal agencies are using a cloud system may target administrative users in the cloud provider’s corporate environment as the first step of an attack path ultimately to reach the target cloud environment. During the phishing and simulated corporate workstation scenarios, the 3PAO pen testers attempt to determine the likelihood of success that such an alternative, back-door attack path could impact the cloud system. They also identify control improvements to eliminate that back-door threat without having to engage with much of the CSP’s corporate environment. Seen in this light, those scenarios are a reasonable middle-ground approach for assessing and reducing risk to the cloud system.
Cloud providers that are seeking a FedRAMP authorization are advised to have a FedRAMP-like penetration test performed on their cloud system as part of their readiness efforts to make sure that their system can withstand the scrutiny they will face when the 3PAO performs their assessment pen test. CSPs often engage another 3PAO to perform advisory services and gap assessments (including pen testing) to enhance their chances of a successful outcome on their official assessment. Using a 3PAO pen tester ensures that the scope of the gap assessment pen test includes all of the attack scenarios outlined in the PMO’s guidance.
For several controls, i.e., SC-13 and IA-2(11), the FedRAMP-defined parameters included in the FedRAMP Moderate baseline appear to present NSA approved cryptography as an alternative to FIPS validation. NSA approved cryptography, however, generally applies to classified systems and therefore can be just as complicated as FIPS. Realistically, most CSPs don’t have an option. FIPS 140-2 validation is the standard to follow and there is really no alternative. When that is case, the FedRAMP PMO instructs CSPs to not mention the “NSA approved cryptography” alternative as part of their control descriptions within their SSP and associated policies.
CSPs should keep in mind that FIPS validated cryptography (as well as NSA approved cryptography, for that matter) is not merely about encryption algorithms and key lengths. Of course, FIPS validated cryptography uses only NIST-approved ciphers and key lengths for encryption, integrity, and key generation. (As an aside, CSPs often overlook the requirements for key generation by supporting ECDH curves that provide less than 112-bits of encryption.) In addition to encryption algorithms and key lengths, FIPS validation also concerns the underlying core encryption processes themselves that occur within the encryption modules within the system. In particular, FIPS validated cryptography means that the specific version of the specific encryption modules used by the system have been thoroughly investigated and validated at a FIPS-approved laboratory. To ensure that cryptography is FIPS validated, CSPs need to confirm that the specific versions of the cryptographic modules used in the system correspond to versions that have been FIPS validated and that that those cryptographic modules have been appropriately configured to operate in a FIPS-approved mode with only approved ciphers and key lengths. More information about FIPS validation can be found in SecureIT’s FedRAMP Tech Bulletin on FIPS 140-2 Validation.
FedRAMP has 17 controls (i.e., the -1 control for each of the 17 control families) addressing policies and procedures. The policies and procedures have to be developed, documented, disseminated to the appropriate organizational personnel or roles, and periodically reviewed and updated. Specifically, policies and procedures need to meet the following criteria:
- Policies and procedures must be documented. Informal, verbal “procedures” are not acceptable for FedRAMP.
- Policies must provide broad level directives, rules, and practices that prescribe how the organization manages and protects information.
- The content of policies must contain at least the following sections: purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance (e.g., specifying an entity to oversee and monitor compliance as well as penalties for non-compliance).
- Procedures must facilitate the implementation of the policies by providing more detailed direction about the steps that personnel must follow to accomplish security-related tasks.
- The content of procedures must also facilitate implementation of the controls that are required per the relevant FedRAMP baseline. That means procedures must define step-by-step guidance for all the tasks required by the FedRAMP controls.
- Together, the policies and procedures must clearly indicate how the CSP has defined each of the organization-defined security control parameters.
- Both policies and procedures must be disseminated to particular personnel or roles, as determined by the organization (and documented in the SSP).
- Policies must be reviewed and updated at least every three years.
- Procedures must be reviewed and updated at least annually.
Usually, policies and procedures that were developed for other compliance frameworks like SOC 2 or ISO 270001 don’t provide sufficient coverage of the FedRAMP requirements. In other words, the existing policies and procedures generally don’t address all of the FedRAMP controls as required. To be acceptable for FedRAMP, the policies and (in particular) procedures from SOC or ISO typically need to be enhanced to address control requirements that are unique to FedRAMP. Enhancing these documents to address all of the security controls for all families in the FedRAMP baseline often entails a significant level of effort.
Fortunately, FedRAMP does not have specific requirements about the format or organizational structure of the policies and procedures. CSPs can aggregate all of the required content into a single document or maintain a series of individual documents. For ease of use, CSPs often organize their policies and procedures according to the families and control references of FedRAMP, but that is not required. Organizations can adopt any organizational scheme that makes sense to them. CSPs that use alternate organization schemes may find it useful to develop a crosswalk or mapping between their policies and procedures and FedRAMP families and controls. Such mappings can be extremely helpful in ensuring that all aspects of FedRAMP are sufficiently addressed by the policies and procedures and providing a useful tool for the 3PAO to use when testing the CSP’s compliance with the -1 controls during a FedRAMP assessment.
FedRAMP encryption requirements for data transmission are specific. FedRAMP requires FIPS 140-2 validated cryptography for all transmissions that cross the boundary and for all transmissions inside the boundary that involve Federal data or sensitive metadata. In contrast, FedRAMP does not mandate specifically what types of data require encryption at rest. For controls SC-28 and SC-28(1), the type of information that is encrypted at rest is determined by an organizationally defined parameter. This means that CSPs have discretion to define exactly what types of data at rest are encrypted.
Passwords at rest must be cryptographically protected in accordance with IA-5(1) and FedRAMP will require that all sensitive data be encrypted at rest, but otherwise, CSPs in coordination with their Agencies have flexibility in terms of defining what data is encrypted at rest. However, there are some constraints on that flexibility. The CSP has to identify some data that will be encrypted at rest, and as mentioned, “sensitive data” at a minimum must be encrypted. Choosing to encrypt nothing at all is not a feasible option. The expectations of customer agencies for protecting data at rest need to be addressed. Though FedRAMP doesn’t define one-size-fits-all requirements, the CSP’s agency customers will have requirements that are tailored to the particular risk profile of the system and its data. CSPs should assume, for example, that any sensitive data that is stored within the system will require encryption at rest. CSPs should give careful thought to determine what types of data warrant encryption at rest. The FedRAMP PMO may question the CSP about any data that is not encrypted at rest, so CSPs should be prepared to explain and justify any data that is stored within the boundary in clear text. Simply asserting to the PMO that data is not sensitive is unlikely to persuade the PMO. A specific risk-based justification may be required.
The SSP must clearly describe the data (or data stores) that are encrypted at rest so that constituencies like agencies customers and the FedRAMP PMO have full visibility into the cloud system’s encryption practices. CSPs must also depict on their data flow diagram each data store within the boundary and note each store’s encryption status and whether it is leveraging FIPS 140-2 validated modules.
Encryption of data at rest can be performed at different layers of the system: the storage layer, the database layer, or the application layer. There are no specific FedRAMP requirements about how or where in the stack encryption should be implemented. However, CSPs are advised to think through the threats that encryption is intended to protect against. When PII or otherwise very sensitive data is stored in the system, encryption may be intended to protect that data from access by system administrators. In those situations, encryption at the storage or database layer may not be sufficient since data is often automatically decrypted by administrative users. Instead, data may need to be encrypted at the application layer using tenant-specific keys before it is stored to ensure that system admins and DBAs can’t access the protected information. Or, segregation of duties and access controls may need to be applied to encryption keys to prevent administrative users from being able to decrypt PII. In the absence of PII or similar highly sensitive data, there may not be a need to perform encryption at the application layer. Instead, encryption at the database or storage layer is often used to provide encryption of data because it is simpler to configure and validate. When a SaaS provider uses FedRAMP authorized IaaS or PaaS offerings like AWS, leveraging built-in encryption at rest features for RDS, S3, or EBS volumes is highly recommended as a straightforward means of meeting FedRAMP requirements. Using these services makes it possible to encrypt all data stores across the board and eliminate any question about whether all data that warrants encryption has been encrypted.
Although SC-28 and SC-28(1) give the CSP discretion to define the type of information to be encrypted to rest, the control and enhancement requirements clarify that data protection must address both confidentiality and integrity. Protecting confidentiality is straightforward, but it may not always be obvious how to prevent unauthorized modification of data to ensure integrity. In some cases, other controls may need to supplement encryption to provide integrity to data at rest. For example, it may be appropriate to maintain some off-line storage to help protect data in case it is re-encrypted with a secret key by ransomware or otherwise corrupted by malware.
Furthermore, all uses of cryptography in FedRAMP, including encryption of data at rest, must follow appropriate key generation and management practices (SC-12) and use only FIPS validated cryptography (SC-13). Refer to SecureIT’s FedRAMP Tech Bulletin on FIPS 140-2 Validation for more information.
The authorization boundary is important because it defines the system scope that must comply with FedRAMP requirements. Each of the required controls of the appropriate FedRAMP baseline must be applied to all of the components, services, and devices (hereafter referred to as just components) within the authorization boundary – including continuous monitoring and assessment by a 3PAO. Having a clear-defined boundary is critical for ensuring that a common understanding of the scope of the system is shared by all constituencies – the CSP, the authorizing official of the customer agency, and the 3PAO. Although having a properly defined boundary is critical to the FedRAMP process, CSPs have found it quite difficult. The FedRAMP PMO has indicated that defining an appropriate boundary is the most common non-technical challenge faced by CSPs seeking a FedRAMP authorization. By far the most common error is omitting components from the boundary when they should be included.
The FedRAMP PMO published draft guidance on establishing and documenting a proper boundary (see DRAFT FedRAMP Authorization Boundary Guidance). It is unclear when this guidance will be finalized. In the interim, SecureIT compiled for CSPs some guidance based on our dealings with the PMO. Please refer to our FedRAMP Tech Bulletin on the System Boundary.
Update: The PMO has removed the draft boundary guidance from their website. However, the PMO continues to enforce most of the requirements that were included in that “disappeared” draft guidance. The most important of these requirements are captured in our Tech Bulletin.
The FedRAMP tailored program is a great option for a SaaS provider to investigate because it involves a much smaller set of security requirements for cloud systems that meet certain criteria. Eligible SaaS systems must not contain personally identifiable information (PII) other than login information, cannot be hosted in an IaaS/PaaS that is not FedRAMP authorized, and must be categorized as Low impact. It’s this last criterion that is often challenging for CSPs.
When FedRAMP refers to Low impact, it has a very specific, technical meaning. That meaning is defined by a set of documents, in particular FIPS Publication 199 and NIST SP 800-60. The process that CSPs must follow is described in a SecureIT blog on “The FIPS 199 Categorization of Cloud Systems for FedRAMP.”
Ultimately, it is the Federal agency customer that determines the impact level or categorization of the system based on the data that is stored, processed, or transmitted within it. Because the data belongs to the Federal agency customer, their assessment of the impact is the only one that matters. Transparency between CSPs and their customer agencies is critical for ensuring the system is properly categorized to meet the need of those agencies. Therefore, we recommend that a CSP considering the FedRAMP Tailored LI-SaaS program discuss the system categorization level with prospective customer agencies to ensure that there is consensus regarding Low impact.
Some SaaS systems provide generic services that can accommodate a wide range of data types. For example, cloud-based content management systems like Box, Dropbox, etc. are data agnostic and could conceivably be used to store any type of data. Some CSPs might wish to obtain a Tailored authorization to get their foot in the door of FedRAMP in order to make it easier to market their products. CSPs should keep in mind that systems with LI-SaaS authorizations can only be used by agencies for low-risk use cases. The vast majority of Government data is categorized as Moderate impact, which means that this data cannot be stored within a system that only has a Low impact SaaS authorization. For this reason, CSPs that take this approach will likely need eventually to obtain a Moderate impact FedRAMP authorization to significantly expand their market within the Federal Government.
For more information on FedRAMP Tailored in general, see SecureIT’s FedRAMP Tailored LI-SaaS Success Planning Guide.
FedRAMP requires monthly vulnerability scanning at the three traditional layers (infrastructure/operating system, database, and application) of all components within the boundary. In addition, FedRAMP has issued guidance for vulnerability scanning of container technology through either scanning container images prior to deployment or utilizing security sensors deployed alongside the containers. Vulnerability scans have to meet all the RA-5 control enhancements (e.g., authenticated scans with up-to-date scanner plug-ins, all of which are enabled.).
The results of the vulnerability scans of the boundary are monitored by the authorizing officials (AOs), either the JAB or the agencies that authorized the system. The AOs receive that information from multiple sources. During FedRAMP assessments, the 3PAO assessor has to run or observe each layer of vulnerability scans. All vulnerabilities that are identified by the respective scanners are included in the results of the Security Assessment Report, which is reviewed by the AOs for the authorization. Each month during continuous monitoring, the CSPs have to submit detailed information about their vulnerabilities to their AO, including: raw vulnerability results, POA&Ms for reporting vulnerabilities that exceed their resolution timeframes, and deviation requests for downgrading the risk, closing vulnerabilities as false positives, or accepting the risk as an operational requirement.
For a very detailed discussion of FedRAMP’s requirements for vulnerability scanning, remediation, and reporting, please reference SecureIT’s FedRAMP Tech Bulletin on Vulnerability Management.