We are nearing a year since the announcement of the historic US Executive Order on Cybersecurity, which directed government agencies to improve their information security and adopt cloud and zero-trust technologies. One effect of this Executive Order has been to drive interest in the FedRAMP authorization process.
One of the strongest benefits of the FedRAMP program is the ability to reduce the effort required to obtain an authorization by inheriting controls from vendors that are already authorized. For example, utilizing a cloud-based SIEM tool such as Splunk or SumoLogic would allow a new service to inherit many of the Auditing (AU) and Access management (AC) controls. Inheriting controls does not absolve an organization of the responsibility for the control entirely, however, so caution and awareness needs to be exercised to ensure there are no surprises when it comes time to audit.
Choosing applications from which to inherit controls starts with industry standards. Using industry-standard technologies such as SAML, OpenID Connect, and OAuth2 reduces vendor lock-in and allows transparency into how the applications interact. This greatly simplifies the creation of your System Security Plan and accompanying documentation. Using standards-based technologies also reduces risk to your organization by allowing you to quickly replace subprocessors in the case there is an issue with their authorization, availability, or changing regulatory environments.
Second, you must ensure that you are using the application in a way that supports inheritance. Many vendors don’t have a FedRAMP authorization for their entire cloud environment, and so you may be required to move your instance into a regulated or other specialized environment, typically at an increased cost. This environment should come with documentation such as the Controls Implementation Summary and Customer Responsibility Matrix. The Control Implementation Summary provides a line-by-line definition of control implementation of the NIST 800-53 control set used by FedRAMP.
This document is used by your compliance team to understand the security posture of the subprocessor, and if there are responsibilities for your team to configure the application to ensure it is used in a FedRAMP-authorized manner.
The Customer Responsibility Matrix is the follow-on document that details the controls that are your responsibility to implement.
Failure to implement the controls as defined in the Customer Responsibility Matrix may result in audit findings in your inheritance, as the application is not being used in a FedRAMP-approved manner. It is worth noting that Customer Responsibility Matrices are used in other compliance programs such as PCI.
Finally, selecting vendors that can partner and scale with your growth is critical. When you are looking to uplevel your application from FedRAMP Tailored to Moderate, and eventually to High, all of the applications you are inheriting controls from must also be at that target level. Therefore, if your vendors are not aligned with your journey, you may find yourself in a position where your application needs to be refactored in order to grow. This creates cost, complexity, and negates much of the potential value of inheriting controls.
As a US Citizen and a constituent, I believe that investing in enabling our government to more quickly access shared services is investing in the ability to more effectively provide community health services, disaster assistance, and information resources, and being able to provide these capabilities in a more secure and usable way. Control inheritance is one tool we have as security and compliance professionals to work together and accelerate this investment. Whether you’re an organization that currently holds a FedRAMP, PCI, or other compliance certification, or a technology startup that is ready to help your government modernize, consider how your program can utilize control inheritance to drive change faster.
