FedRAMP’s Cloud Security Assessment Process

Federal Risk and Authorization Management Program

FedRAMP’s Cloud Security Assessment Process

FedRAMP

The Federal Risk and Authorization Management Program (FedRAMP) was formed to provide standards for the authorization and assessing of cloud services and products from government and agency usage. FedRAMP provides a common standardized security model for the Federal Government which allows for more effective cloud use and better access from agencies that need information. FedRAMP is designed with the NIST framework with regard to standards of the Federal Chief Information Officers’ Council.

1) providing recommendations on the application of NIST SP 800–37 Guide for Applying the Risk Management Framework to Federal Information Systems: A Security Life Cycle Approach, and 2) providing recommendations on the application of security controls selected from NIST SP 800–53. (National Institute of Standards and Technology, 2014).

The FedRAMP security assessment process utilizes a “security risk-based model” that is based on NIST Special Publication 800–37. This is low to moderate risk set of controls. The assessment process is based on six functions that are intended to provide comprehensive risk management. These functions include:

(1) analyzing and determining the impact (sensitivity) of a system and its data; (2) selecting appropriate controls; (3) implementing and documenting such controls; (4) assessing whether they have been implemented properly; (5) authorizing the system or program (i.e., determining that the remaining level of risk after controls are applied is acceptable); and (6) monitoring and assessing the continued effectiveness of the selected controls.

While there are some tradeoffs with interoperability and privacy, these tradeoffs or risks are measured comprehensively, through the NIST framework. This risk is managed in steps three and four specifically as controls for information flow and access must be determined and implemented based on the risk assessment. However, this is a subjective area and does present some level of increased danger with regard to developing ineffective controls. For example, it is the agency's responsibility to use the NIST framework to determine the risk such as privacy or confidentiality for information. The CIO refers to these control implementations as “privacy by design” in which the NIST recommended controls are addressed with regard to the application to the specific agency (NIST, 2015).

While controls are standardized, there are aspects of the control which are dynamic and must be accounted for in the information inventory. For example, personal information is any information which is “identifiable”. This means that social security numbers or bank numbers can be linked to a specific person and that any information that is linkable to a person is considered identifiable and must be considered in the control process.

While this definition leaves considerable room for interpretation, a broad rule of thumb is that data collected from or about an individual, regardless of its sensitivity (impact level), is potentially PII for purposes of performing a PIA. See NIST SP 800–122 for further discussion of “linked” or “linkable.” Agencies should not exclude data from the risk assessment process merely because the data might be redacted, disaggregated, masked, or otherwise “de- identified” after collection (NIST, 2015).

This creates a complex system of controls which must be planned that may involve multiple cloud systems, access by third parties, and many different types of data such as photos, information, and other data that is identifiable. In order to facilitate this aspect of risk management and control, FedRAMP requires a digital privacy impact assessment (PIA) to be performed and assessed (CIO, 2012). This creates an evaluation process to mitigate privacy risks. This must be documented and disclose the type of identifiable information that is collected, maintained, shared and why this is occurring. The intended uses must be accounted for and how this use applies to specific laws, such as the E-Gov Act and the Privacy Act of 1974 (CIO, 2012). This comprehensive system of control reduces the overall subjectivity of the risk management process.

The FedRAMP security assessment process is sufficient for understanding overall system risk due to its detailed control determination process. What make the process strong is the fact that it defines identifiable information in a manner that is focused and leaves little room for subjective determinations. Moreover, the process also has strong checkpoints such as auditing and accreditation in order to approve the security framework. This also reduces the element of subjective consideration and makes the risk assessment framework strong.

FIPS 140–2 Compliance

The Federal Information Processing Standard (FIPS) Publication 140–2, (FIPS PUB 140–2) is the security standard issued by the federal government for the approval of cryptographic modules. FIPS 140–2 provides four levels of security which must be met for approval. The NIST developed FIPS 140–2 to standardize cryptography modules taking into account software and hardware needs. The protection of these modules is important because they maintain information integrity and confidence. FIPS 140–2 creates requirements for security design and implementation of the cryptographic modules which include a large area of protection including:

· cryptographic module specification;
· cryptographic module ports and interfaces;
· roles, services, and authentication;
· finite state model;
· physical security;
· operational environment;
· cryptographic key management;
· electromagnetic interference/electromagnetic compatibility (EMI/EMC);
· self-tests;
· design assurance;
· and mitigation of other attacks (NIST, 2007).

These specifications are intended to help facilitate the collection, transferring, safeguarding, and sharing of information within a network or cloud. This standardization is extremely important because modules are designed and created by the private sector and the specifications must be met as part of the FedRAMP process of risk management. The layers of FIPS 140–2 are used to determine the type of security necessary for a cloud or network system. This can be found in the Implementation Guidance for the FIPS 140–2 and the Cryptographic Module Validation Program (NIST, 2007). An example of this process of validation can be seen in the vendor approval process in which the guidance is used to determine approval by listing required elements for software modules:

1. A vendor may perform post-validation recompilations of a software or firmware module and affirm the modules continued validation compliance provided the following is maintained:

1. a) Software modules that do not require any source code modifications (e.g., changes, additions, or deletions of code) to be recompiled and ported to another operational environment must:

1. i) For Level 1 Operational Environment, a software cryptographic module will remain compliant with the FIPS 140–2 validation when operating on any general purpose computer (GPC) provided that the GPC uses the specified single user operating system/mode specified on the validation certificate, or another compatible single user operating system… (NIST, 2007)

The validation process is detailed presenting different scenarios and circumstances for approval. This validation process is important to the overall risk framework within NIST because FIPS defines the minimum standard security requirements for products and systems. This is a requirement within FedRAMP:

Validation against the FIPS 140–2 standard is required for all US federal government agencies that use cryptography-based security systems — hardware, firmware, software, or a combination — to protect sensitive but unclassified information stored digitally. (Note, however, that any business can take advantage of the FIPS 140–2 mode of operation if they desire.) Some agencies also require that the modules procured for secret systems meet the FIPS 140–2 requirements (Microsoft, 2017).

In order to be approved as a vendor such a healthcare company that interfaces with Medicare, the vendor’s systems must be compliant with FIPS 140–2. The NIST maintains a public list for the vendors and the approved cryptographic modules that have been validated. It is important to understand this because FIPS 140–2 does not specify the actual security measures but instead establishes the security standards for what the cryptography must protect. As such customers are provided the freedom to configure the security services in a manner that fits their information needs and requirements.

References

CIO. (2012). RECOMMENDATIONS FOR STANDARDIZED IMPLEMENTATION OF DIGITAL PRIVACY CONTROLS. Federal Chief Information Officers Council, Federal Chief Information Officers Council. Federal Chief Information Officers Council.

Microsoft. (2017). Federal Information Processing Standard Publication (FIPS) 140–2 Federal Information Processing Standard Publication (FIPS) 140–2. Retrieved from Microsoft Trust Center: https://www.microsoft.com/en-us/TrustCenter/Compliance/FIPS

National Institute of Standards and Technology. (2014). Framework for Improving Critical Infrastructure Cybersecurity . Washington: National Institute of Standards and Technology.

NIST. (2007). Implementation Guidance for FIPS PUB 140–2 and the Cryptographic Module Validation Program. National Institute of Standards and Technology Communications Security Establishment, NIST. NIST. NIST. (2015). FedRAMP Security Assessment Framework FedRAMP. NIST, NIST. NIST.

~Citation~

Vincent Triola. Sat, Mar 06, 2021. FedRAMP’s Cloud Security Assessment Process Retrieved from https://vincenttriola.com/blogs/ten-years-of-academic-writing/fedramp-s-cloud-security-assessment-process

Need similar articles?

Network Security | Technology