diff --git a/_posts/2024-03-28-a-new-roadmap-for-fedramp.md b/_posts/2024-03-28-a-new-roadmap-for-fedramp.md index 825930f9..b306f1a4 100644 --- a/_posts/2024-03-28-a-new-roadmap-for-fedramp.md +++ b/_posts/2024-03-28-a-new-roadmap-for-fedramp.md @@ -25,12 +25,12 @@ While SaaS applications are used in government, and FedRAMP does have some in it

Our roadmap contains some specific initiatives we’re undertaking to make concrete progress against these goals:

1. An agile approach to change management. FedRAMP needs to enable agile software delivery of security improvements and other features. To do this, we plan to replace the “significant change request” process with an approach that does not require advance approval for each change. We’ll start by piloting a new process with interested authorized cloud providers, and use the pilot to finalize broader guidance. 2. Publish new, customer-oriented program metrics. If we are going to impact the cost of FedRAMP and how long it takes to get and stay authorized, we need a better way to measure those things, informed by what our customers are actually experiencing. Likewise, we need to refine our understanding of our agencies' customers' experience and focus on ensuring they can efficiently and securely leverage cloud services to meet their mission needs. We plan to survey customers about their experience, soon and at a regular cadence, and to update FedRAMP’s formal performance metrics based on this survey to align with customer outcomes. -3. Define FedRAMP’s core security expectations. A central challenge of FedRAMP is to accommodate varying risk tolerances across agencies, while still setting a high enough bar for its authorizations to broadly support agency reuse without additional work. We plan to make progress here by more clearly defining the outcomes we expect all types of authorizations to meet. We will also work closely with CISA to develop and deploy the best protections for and minimize the risk to the federal enterprise. By combining this with more public documentation and examples of how cloud providers meet FedRAMP’s security goals, we can also streamline the authorization process overall. +3. Define FedRAMP’s core security expectations. A central challenge of FedRAMP is to accommodate varying risk tolerances across agencies, while still setting a high enough bar for its authorizations to broadly support agency reuse without additional work. We plan to make progress here by more clearly defining the outcomes we expect all types of authorizations to meet. We will also work closely with the Cybersecurity and Infrastructure Security Agency (CISA) to develop and deploy the best protections for and minimize the risk to the federal enterprise. By combining this with more public documentation and examples of how cloud providers meet FedRAMP’s security goals, we can also streamline the authorization process overall. 4. Keeping FedRAMP policies focused on outcomes. As a security-first program, FedRAMP needs to care not only about what is required, but about how those requirements can be reasonably applied and how they work out in practice. FedRAMP will hold cloud providers to a high standard informed by how implementation best practices have evolved, and that provides the flexibility needed to stay focused on security outcomes. We’ll start with updated guidance in a few areas that we know are particular authorization pain points now (such as FIPS 140, DNSSEC, and external service integrations), and set up a regular process for understanding where to focus over time. 5. Increase the authorizing capacity of the FedRAMP ecosystem. We will work with trusted authorizing partners to align our processes and eliminate the need for extensive per-package review by the program. We will be piloting this approach with our partners at DISA who serve as the Cloud Authorizing Official for the Department of Defense. More generally, we will be supporting OMB and the FedRAMP Board in convening joint authorization groups, who we expect to be strong candidates for this streamlined approach. 6. Move to digital authorization packages. While a full migration will take time, FedRAMP needs to operate as a data-first program for its processes to scale. We will define machine readable packages, in OSCAL, and provide the guidance and tools to help our customers create and share them. Our goal is to leverage automated validation and assessment of packages, as well as system-to-system integration with our FedRAMP governance, risk, and compliance (GRC) platform to modernize and scale. We will work with interested cloud providers to pilot creating these packages and incorporating them into the authorization process in partnership with interested agencies. -There are other things we’re working on too, like exploring reciprocity with external frameworks, and partnering with our colleagues at the Cybersecurity and Infrastructure Security Agency on scaling secure configuration guides and threat sharing. Take a look at our published roadmap for more details. +There are other things we’re working on too, like exploring reciprocity with external frameworks, and partnering with our colleagues at the CISA on scaling secure configuration guides and threat sharing. Take a look at our published roadmap for more details. We’re hoping to see a number of outcomes from our efforts over time. We expect our industry providers to be able to more effectively deploy changes, and our agency partners to see more features – including security features – faster. We expect to stabilize our review “backlog”, and keep it stabilized over the long term. We expect cloud providers, agencies, and third party assessors to have a better understanding of our security requirements, leading to higher quality packages and ultimately greater trust in the FedRAMP program.