FedRAMP stifles marketplace access & innovation. Here are some ways to change it.
John Janek
Chief Technologist | ex-diplomat | complex problem-solver | systems thinker
FedRAMP is one of the most divisive acronyms in the government vocabulary lately. Originally a GSA program designed to help government agencies find and utilize accredited software quickly, the program quickly became mired in the classic problem of being too successful, too bureaucratic, and too compliance focused.
From their About Us page, FedRAMP defines themselves as a way to provide cost-effective, risk-based approaches to adopting cloud services. If you've been in the security space for a few years, you know this is an admirable goal. Permission to use a product or service can take a painfully long time. In fact, nearly any line of business user in government will almost always default to using software already on hand or worse, shadow Technology, or more emergently shadow Software-as-a-Service (SaaS).
"The Federal Risk and Authorization Management Program (FedRAMP) was established in 2011 to provide a cost-effective, risk-based approach for the adoption and use of cloud services by the federal government. FedRAMP empowers agencies to use modern cloud technologies, with an emphasis on security and protection of federal information."
https://www.fedramp.gov/program-basics/
Currently, there are over 246 FedRAMP approved products. That sounds like a lot until you realize that a quick internet search suggests there are as many as seven thousand SaaS companies in 2022. At a time when people are writing about how the government is having its App Store moment, having a paltry 246 products, many of them platforms in their own right like AWS, Google Cloud, Azure, Salesforce, and ServiceNow, feels like the government is just leaving innovation on the table.
So what's the deal?
Why are there so few products available that have been certified? Despite support from Congress and government leadership, talking with industry colleagues the same themes come up over and over.
Cost and Complexity are probably the single biggest drivers of this angst. I've heard numbers as small as $200,000 and as large as $10 million (no kidding) to prep products and get them through FedRAMP. For an early stage start-up, the risk of investing that much money on a notoriously difficult customer (any U.S. Government agency) immediately flags the investment as exceptionally high risk.
There are many reasons for this. The NIST Risk Management Framework is a U.S. government compliance framework that is still struggling to fully integrate modern cloud-native and shared responsibility models. The FedRAMP process also requires third-party assessment from a very limited pool of specialized firms creating artificial scarcity for those who can actually give any product a green light for accreditation. Finally, there simply is not much in the way of guidance on how to create compliant products. I won't even get into the nuanced and hair-splitting differences around information protection and classification.
Lack of adoption and arcane buying policies is another heard pain. Despite the program being government-wide, acceptance of FedRAMP is still at the discretion of the buying agency. A government employee with a purchase card, a defined need, and SaaS product they're interested in trying most of the time cannot accomplish getting government policy-compliant access. Buying SaaS is also atypical for government agencies who are used to buying licenses on a yearly basis, not monthly, and certainly not in a just-in-time fashion. Just ask anyone in the IT org who has tried to spin up resources in less than a day. And despite plenty of similarities with buying perishable commercial supplies, the history of technology and software creates multiple barriers to advancing those modern commercial purchasing approaches. At the end of the day, this means that FedRAMP certification is only one component out of several that can prevent a sale from closing.
When you consider the cost and risk of FedRAMP certification, it doesn't make sense for a lot of vendors that the government actively wants to participate in the ecosystem. The government is leaving significant innovation, and potentially cost savings, on the table by actively encouraging a restricted, bottlenecked marketplace.
How might FedRAMP include more emerging and innovative products?
Although much of this is written from the perspective of industry, you can talk with many government technology leaders and hear a similar level of frustration with not being able to quickly access game-changing technology. Here are some things that can happen, right now, to entirely change the picture.
Reciprocity, Reciprocity, Reciprocity.
There are three approaches to reciprocity that could greatly accelerate FedRAMP marketplace availability.
领英推荐
Good: Accelerate agency to FedRAMP ATO reciprocity. If an agency has gone through the expense and time of getting a product to ATO, it should be a two week move to put that package in place on the FedRAMP marketplace. Although FedRAMP uptake at the agency level continues to accelerate, turning the ATO flow into a two-way mechanism would provide a functional hub and spoke model and greatly accelerate adoption.
Better: Accept similar commercial frameworks. A company that invests in a SOC2 review and remediation has already made a significant investment in being ready for regulated industries, large companies, and demonstrates a commitment to good practice. There is nothing magical about the NIST RMF, and although it is a very good framework there are plenty of others which are also very good. Acknowledging that satisfying compliance may come from other industry standards also follows other good practices from contract acquisitions and other models currently in place.
Best: CIO Council guarantees general reciprocity. Consider this the thrown gauntlet. Agency CIOs could obviate the need for FedRAMP all together by declaring, collaboratively, than any agency-granted ATO will be accepted by any other agency with an absolute minimum of bureaucracy. This is the ultimate trust exercise, and would be fantastic for accelerating innovative software uptake inside government. This approach would usher in a whole new era practically overnight and shift thousands of GRC roles from bureaucratic process into true partnership, monitoring, and collaborative activities.
I can't advocate for this enough. And I seriously challenge each and every member of the CIO Council to actively advocate for this change, and as a measure of good faith work with OMB to make all their ATO packages available to every other IT org in the government.
But wait, there's more
Even if reciprocity can't happen, there are so many ways that we can continue to improve and drive newer products into FedRAMP. Here are a few more ideas:
Acknowledge Certified Professionals: Professional Engineers personally accredit their work. Contracting Officers personally accredit their work. Instead of expensive C3PAO organizations that follow incredibly expensive ANSI standards, one way to allow lower-risk, emerging, and narrow use-case software might be to allow individual accreditation by a certified professional. Although certifications like CAP, CISSP, and CISA have long had industry recognition, allowing individuals with these certifications to vouchsafe products ready for secure use would also promote the idea that cybersecurity is a professional activity.
Create Other Transaction and Grant-based FedRAMP support: As identified above, cost of entry is an incredibly high barrier for entry for commercial software that the government wants and needs. One of the ways this can be offset is by creating government-wide programs to help offset costs around development, assessing, and remediating FedRAMP accredited software. The Department of Defense (DOD) as one of the JAB members could easily support this for emerging and new software. This approach would also achieve critical support for DOD's CMMC program at the same time. Grant-based efforts could be executed through the Small Business Administration for small and medium sized business, as well, ensuring that the types of companies and software the government wants most are within easy reach.
Build a collaborative (virtual) space and encourage collisionable knowledge sharing: Getting to ATO should break the bank, it shouldn't be rocket science, and it should be straight forward to understand, undertake, and show evidence of. Borrowing models from DOD's innovation sphere, FedRAMP could create an open collaborative working environment, similar to any number of active DOD-sponsored coworking spaces (SOFWerx being one of the oldest) to encourage innovation to occur alongside compliance. There are fantastic platforms like rehive designed specifically to encourage this type of interaction.
Keep it Goal Aligned
The FedRAMP program management office should set up some goal-oriented outcomes and start measuring them. We know how many SaaS products are in the market, approximately. We know the general agency strategic goals and overall administration's approach. We know where money and funding is being allocated. These inputs should be used on an annual basis to create outcome-based goals for the FedRAMP PMO to focus the conversation on how to accelerate processes that both challenge the current approaches disruptively and also continue to accelerate existing processes in a sustainable manner. This dual pronged innovation approach will guarantee continuous learning and improvement, as well as opportunities for completely disrupting the environment, maybe even in some of the ways identified here.
The time to change a program is right before it becomes a bottleneck
FedRAMP was set up for all the right reasons. The numbers prove that it is successful for larger products who can afford the cost of entry. Encouraging innovative and evolving commercial vendors to participate means the program office has to adopt both sustainment processes and disruptive experiments in order to find the right approach to creating timely methods for authorizing secure, accredited, cloud-based software for the U.S. government.
Agree? Disagree? Jump in the conversation. Getting secure, effective, products into the hands of government employees in order to deliver services to people better, faster, and more effectively has never been more important.
Cyber nerd for the US government (personal views only, not official)
2 年> The NIST Risk Management Framework is a U.S. government compliance framework that is still struggling to fully integrate modern cloud-native and shared responsibility models. What about the NIST RMF struggles with cloud-native and shared responsibility models? Do you have examples? I think part of the struggle is there is the extensible framework, as published, and what any agency or assessor vendor interprets, aka as it is applied. That bleeds into many points you make, but I see many people miss the dichotomy. In a former life, writing agency SSPs and supporting evidence, if we are talking about the high-level 800-53 requirements derived from 800-37, do not change much from on-premises data centers to Lambda functions and ECS Fargate. I had to do a lot of it for the latter, and I still do not know what people mean when they cite its struggles with cloud. Agency officials set in their way (as applied) struggle, but few read the official materials as they change or point to their (often) static interpretations from their employing agency. RMF is meant to be agnostic. You can love that or hate that, but I often find the missing nuance here confusing.
CEO @ Aquia | Chief Security Advisor @ Endor Labs | 2x Author | Veteran | Advisor
2 年John Janek ?????? This is one of the best write ups I’ve seen quickly summarizing some of the issues with FedRAMP as well as laying out some potential solutions (albeit bold in some of the recommendations). A couple thoughts. - I am not a fan of letting Cyber certified professionals provide attestations without some sort of guiding framework. There’s a vast difference among the CISSP certified, let alone all the other certifications. Couple that with the fact most cloud-native systems are complex, often beyond the competencies of non-technical assessors (this often applies even with frameworks like FedRAMP). So some standard assessment criteria is critical as well assessor impartiality. - the widespread reciprocity is promising. That said there are some realities, such as the differing rigor of ATO’s across agencies, as well as their processes and staff. That’s a lot of inherent risk, without thoroughly reviewing authorization documents and details. I discuss some of the same problems here (https://www.nextgov.com/ideas/2021/06/executive-order-hints-fedramp-alternatives/174505/)
Satellites, Cybersecurity, Supply Chain, Engineer, Leader and CxO, Entrepreneur w/ 2 exits
2 年good stuff