Balancing FedRAMP Rev5 against improvements to FedRAMP 20x #38
Replies: 15 comments 23 replies
-
|
It looks directionality on-point. Look forward to the details. |
Beta Was this translation helpful? Give feedback.
-
|
I agree completely. Really excited to see the details coming out of the closed beta items starting next month. Ideally, these will be very valuable as on-ramps into the 20X authorization process once the Rev. 5 auths are transitioned in the future. |
Beta Was this translation helpful? Give feedback.
-
|
I'm just getting up to speed with the latest blog posts and appreciate all the great work being done. As I'm catching up, I wanted to clarify a couple of points regarding the Cloud Service Providers (CSPs) that are eligible to participate in the upcoming Beta phase for Rev 5 improvements. Are CSPs required to be fully FedRAMP Authorized at this stage, or is a “FedRAMP Ready” designation sufficient for them to take part? Additionally, I want to confirm whether only CSPs that have an agency sponsor are eligible to participate in this Beta round, or if there’s any flexibility there. |
Beta Was this translation helpful? Give feedback.
-
|
The question around FedRAMP Ready is excellent and one I will admit we have not explicitly considered in advance. I'm inclined to say that it makes a lot of sense for FedRAMP Ready folks to participate in the Beta phases if they are interested, but I need to talk this over a bit more with my team. Same for active authorized CSPs without lead sponsors. When we post formal requirements/etc. for each Beta phase, I will make sure it's clear either way. Thank you for flagging! |
Beta Was this translation helpful? Give feedback.
-
|
As an organization maintaining several Rev5 agency authorizations, we support this path. We expect that leveraging these new streamlined processes would reduce overhead both for us as a CSP as well as all the agencies we engage with as a part of multi-agency continuous monitoring. To this end, we suggest considering giving CSPs the opportunity to self-enroll in these Rev5 Balance Releases ahead of the proposed phased rollout, provided the CSPs have agency approval documented in their continuous monitoring charters. Alternatively, we would welcome quicker adoption of the Balance Releases and would be interested in joining a closed beta phase once more information is available. |
Beta Was this translation helpful? Give feedback.
-
|
It is fantastic feedback that we should start taking Open Beta applications well in advance of finishing Closed Beta. Rolling beta applications are certainly a common play in industry. And we should certainly encourage folks to let us know if they are interested in Closed Betas in advance of their being officially open. Thanks for suggesting this! (informally, doesn't hurt to just drop us a note at rev5@fedramp.gov either way, though we're not fully set up to process that inbox yet, someone will see it) Overall, this idea is new (to FedRAMP at least) so we're going to start carefully and gauge impact/effort/risk/etc. and adjust. Six months from now there will hopefully be a bunch of 20x improvements that need to be balanced over to Rev5, so running these deliberate balance improvement tests will be a continuous effort. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you, Pete! We appreciate your work to ensure that Rev5 Balance Improvements are rolled out in a timely manner that reduces disruptions. We will certainly reach out to show interest in closed betas as future ones come up based on product fit and feasibility. |
Beta Was this translation helpful? Give feedback.
-
|
First, kudos on the proposed updates to the significant change notification process and scope interpretation technical assistance! Thinking about continuous reporting requirements (including significant change process) and recognizing providers may have multiple monthly meetings with various customers, GovRAMP is available for our member providers and federal agencies to leverage to streamline reporting in a centralized portal. This would enable providers to schedule their meetings to coincide with an established reporting frequency (i.e. no more than X days after reporting) with the added validation of the GovRAMP PMO’s review. FedRAMP team members could also be included as desired. This is entirely free for the public sector to leverage. For providers in both the FedRAMP Marketplace and GovRAMP program, a pilot could be beneficial to explore. As always, happy to discuss further. |
Beta Was this translation helpful? Give feedback.
-
GSA can't endorse or provide support that would give any non-governmental entity an unfair advantage but in general we strongly support and encourage industry stakeholders to partner up and work on shared pilots and solutions via whatever mechanisms make the most sense to them! It is much more effective than individual providers trying to figure things out on their own. 🚀 |
Beta Was this translation helpful? Give feedback.
-
|
Excellent work, team! I really appreciate the KSI approach—it clearly enhances the PMO’s ability to assess compliance and manage risk across CSPs’ SaaS and other cloud offerings. Quick clarification: As both a CSP and a 3PAO, are we correct in assuming that we must continue to manage risk and compliance in alignment with NIST 800-53 and 800-53A, and still develop the full FedRAMP package—including the SSP, SAR, test case workbooks, plans, policies, and procedures? (This also includes generating OSCAL outputs for the SSP, POA&M, and SAR.) From my understanding, the KSI framework serves as an overlay after completing the standard FedRAMP requirements, helping to streamline and summarize the package for a more efficient assessment and authorization process. Is that accurate? Follow-up question: As a GRC platform provider, should we plan to develop a KSI-compatible output that maps findings into the KSI structure to take advantage of automation and reporting efficiencies? Additionally, one of the challenges in the past has been the strict requirement to adhere to FedRAMP’s standardized templates—such as the SSP, appendices, and POA&M. Would the KSI framework provide more flexibility in how we generate and present these outputs, particularly from a GRC tooling perspective? Thanks in advance for the clarification—I'm trying to work backwards from the desired end state to determine how our FedRAMP-accredited GRC platform should evolve its workflows and reporting to align with the advancements introduced in FedRAMP 20x. Many thanks again for all the hard work going into this! |
Beta Was this translation helpful? Give feedback.
-
|
20x vs Rev5 are separate paths to authorization. The 20x process is still being developed as part of the Phase One Pilot and will ultimately build an overall package that is very different from a Rev5 package. Both paths will be open for some time, meaning a cloud service provider will be able to choose which type of path and package they wish to pursue. KSIs will not be ported back to the Rev5 based process, unlike other 20x improvements. All of FedRAMP's pilots and beta tests are designed to support innovative solutions that allow a lot more freedom than normal to develop special structures, patterns, etc., but the intent is to drive towards a more standardized solution before wide release based on what we learn. I don't think we'll ever drive back towards "fill out this spreadsheet exactly like this" but there will certainly be standard expectations. You can get a good feel for where we're going right now by digging into the other standards that we're updating as those will trickle down to Rev5. Significant Change Notifications, Continuous Reporting Standards, Storing and Sharing Authorization Data Standards, etc. are all going to benefit from new capabilities added to GRC tools. |
Beta Was this translation helpful? Give feedback.
-
|
Do you anticipate the latest RFC https://www.fedramp.gov/rfcs/0012/ (FedRAMP Continuous Vulnerability Management Standard) being added to the Rev5 Balance Improvement Tests & Releases list (above) at some point in the future? If so, can you forecast when that might come? |
Beta Was this translation helpful? Give feedback.
-
|
Yes. I need to rebalance our roadmap around that release at the end of this week, but it would probably be a closed beta starting in late September or early October (RFC closes on August 21, then I'm sure we'll need a couple weeks to finalize, then organize the closed beta). |
Beta Was this translation helpful? Give feedback.
-
|
Thanks Pete! Appreciate the transparency as always. |
Beta Was this translation helpful? Give feedback.
-
|
I unfortunately built this before RFC-0012 so will need to make some updates. |
Beta Was this translation helpful? Give feedback.
-
|
I know I'm tardy to the party, but I have a question about the "Optional" BIRs with the phrase "Providers MUST plan to address all requirements and recommendations in this process by the end of the Open Beta on May 22, 2026." I worry I am being too pedantic, but does this mean that ADS, VDR, and CCM will be Mandatory for all Rev 5 Authorized Providers after the Open Beta closes, that CSPs will need to have plans in place, or that they remain truly optional after 22 May? I also asked this question on the help desk, but thought others might benefit from this clarification as well. At least anyone as pedantic as myself. |
Beta Was this translation helpful? Give feedback.
-
|
I found the answer to my own question at 52:41 in https://www.youtube.com/watch?v=903F2Tis-14 |
Beta Was this translation helpful? Give feedback.
-
|
All of these docs are structured with an Overall Applicability section that explains if it's optional or mandatory - if it's tagged as optional then by definition any use of providers inside that only applies to people who opt-in. It would be terribly duplicative to constantly state "Providers participating in the beta" through the entire BIR. That all said, I'll do some rewording of the Effective Date(s) & Overall Applicability for Rev5 section to hopefully clarify this a bit since a lot of folks have expressed concern about the phrasing/context. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you. I know from watching the videos and reading the updates that the PMO is moving the FedRAMP process away from one based on legal-ese and towards one of reasonable understanding and risk-based decision making, but a big part of me is still trying to interpret everything in the old legal-ese. |
Beta Was this translation helpful? Give feedback.
-
|
I reworked the wording in the Optional Implementation warning on this page to say: All requirements in optional Balance Improvement Releases only apply to providers that are adopting the Balance Improvement Release. (I didn't want to do it everywhere but hopefully having it just there will be sufficient to help folks feel like FR isn't trying to sneak anything past anyone ;) |
Beta Was this translation helpful? Give feedback.
-
|
Hi @pete-gov ! Question: I hear that FR20x High will not be available for pilot entries till 2027. If that is the case, I imagine that Rev 5 is the only path to High at the moment. Can you please confirm? And is there any more information on the timing for FR High pilot opening? |
Beta Was this translation helpful? Give feedback.
-
|
Current plans for phased delivery of 20x are on the website here: https://www.fedramp.gov/20x/#phased-delivery-of-fedramp-20x Ye olde disclaimer applies x1000 to future phases. At the moment I would say we're far more focused on consolidation and adoption at Moderate than developing 20x High, so don't expect much talking about it until we're halfway through Phase 3 at least. |
Beta Was this translation helpful? Give feedback.
-
|
Okay got it, thank you! 🫡 |
Beta Was this translation helpful? Give feedback.
-
|
Hello @pete-gov I have a couple more questions for you!
|
Beta Was this translation helpful? Give feedback.
-
Calendar days. We just say days for days. If a timeline is in business days it says business days. :)
Ah, yes, the Low, Moderate, and High tabs are based on the FedRAMP authorization. The severity of the vulnerability is addressed everywhere else. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you! |
Beta Was this translation helpful? Give feedback.
-
|
I am currently completing the Significant Change Notification Participation Form and had a question regarding the "Agencies POC" field. Could you please clarify the level of detail required for this section? Specifically, are you looking for:
Additionally, a brief overview of how this contact information will be used would be greatly appreciated to ensure we adhere to our internal privacy and data-sharing policies. Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
Name of your government POC for each agency will suffice. We will not contact the agency POC unless there is some issue that has been identified. We are using the overall information to track who has transitioned to SCN. We may, in the future, add a field to marketplace to identify who has implemented which optional BIRs, but for now it is solely used for internal metrics. Hope this helps. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, Paul! |
Beta Was this translation helpful? Give feedback.
-
|
Posting our VDR BiR feedback to the FedRAMP PMO here in a public form per the suggestion of the FedRAMP PMO. Overall, the VDR standard is a significant leap forward for vulnerability management within FedRAMP and we are very supportive of this direction. We already operate a mature vulnerability automation that aligns well with the principles behind VDR but fitting that output to the standard as written was harder than expected. For smaller CSPs without comparable tooling or engineering resources, this could be a significant lift, particularly for providers running most or all their production workloads in containers, where vulnerability volume scales quickly. Feedback BLUF - The reporting requirements under VDR-RPT-VDT and VDR-RPT-AVI prescribe an excessive level of structured detail per vulnerability, most of which requires narrative human input and review. This conflicts with the BIR's stated intent of streamlining vulnerability response and enabling automated, machine-readable reporting. Two simplifications would significantly reduce provider burden, improve consistency of the resulting data, and make agency review more efficient. 1. Consolidate VDR-RPT-VDT elements 6–11 into a single "justification" field and maybe add category designation field Elements 1-5 (tracking ID, detection time/source, evaluation time, internet-reachability, exploitability) are objective, machine-derivable attributes that fit cleanly into structured fields. Elements 6–11, by contrast, require narrative human judgment and overlap with one another. Breaking these out into discrete fields drives redundant content and incentivizes box-checking over substantive risk explanation. Also it isn't something that scales well, well at least not in a way where you are going to get good quality data at large scale (aka container CVEs) A single "justification" field would efficiently capture most of the same information:
1b [this next part starts to spill over into my 2nd bit of feedback]. Then maybe add a disposition/category designation field with the following options (open to more options as needed).
This collapses six discrete fields into one structured narrative tied to a categorical disposition. It is easier for providers to maintain accurately, easier for agency reviewers to consume in a single pass. 2. Eliminate the difference in reporting between "accepted" and other reported vulnerabilities VDR-RPT-VDT and VDR-RPT-AVI define two near-identical reporting schemas that diverge only modestly, VDR-RPT-AVI drops elements 7, 8, 9, and 11 from VDR-RPT-VDT and adds an acceptance explanation. Maintaining two parallel structures introduces large process complexity for limited analytic benefit. Acceptance explanation can be the same as justification. More fundamentally: a vulnerability that has been "accepted" is still a risk to agency data. The acceptance label does not change the underlying risk posture; it only signals how the provider intends to track it going forward. The current bifurcation arguably understates risk by indicating to agencies (per the VDR-AGM-RVR note) that accepted vulnerabilities warrant less ongoing review. Recommendation: Collapse VDR-RPT-VDT and VDR-RPT-AVI into a single reporting schema covering all vulnerabilities, with the disposition field carrying the categorical signal (e.g. False Positive, Vendor Dependency, Planned Fix, and/or Accepted Risk). Agencies retain the full ability to filter and prioritize on disposition. |
Beta Was this translation helpful? Give feedback.
-
|
Overall, I think maybe you're considering this as if you're going to manually create a bunch of artisanal vulnerability reports for FR - but the purpose of these rules are to ensure that providers are using a proper vulnerability management workflow. As part of that workflow, there will be automated and/or human decisions that are made. Those decisions should be tracked. Then all you need to do in the report is output that information from your tracking system. The reporting data itself should be a trivial data export, not the location where decisions are made and tracked. Please don't track vulnerability detection and response in a spreadsheet. 🙈
Everything necessary for this report should exist in a vulnerability tracking system and be outputted based on the information a cloud service provider has already determined. There shouldn't be anything new created for this report if the VDR rules are being followed. The narratives for VDR-RPT-VDT would include an explanation if the vulnerability is likely to become overdue, which should only ever be true after human review and consideration and the explanation should already exist in any vulnerability tracking system. And, of course, any supplemental information the provider wants to provide. These only would be included if applicable. For VDR-RPT-AVI, there should be no world in which a vulnerability is accepted without reasons and documentation created by a human in a vulnerability tracking system. In general the entire point of these requirements are to remove narratives and simply provide information that has already been tracked in a cloud service provider's vulnerability tracking system.
We expect agencies, CISA, and FedRAMP itself to care mightily about being able to effectively parse this information. Having these fields buried in a narrative justification would make doing so inefficient.
This is already the case in effect. You can use a single schema to cover all vulnerabilities by leaving some fields blank for vulnerabilities that are being responded to vs vulnerabilities that have been accepted. |
Beta Was this translation helpful? Give feedback.
-
|
@pete-gov Appreciate the response, I think my original feedback wasn't as clear as it should have been. I wasn't focused on the export from the vulnerability tracking system; I was focused on the level of detail that has to be captured in the tracking system in the first place to satisfy these reporting requirements.
So my feedback is about the VDR rules themselves That's still too much per-vuln detail, particularly at container scale, which was the focus of my feedback. A medium to larger CSP can easily run 1000+ distinct containers. Even with minimal base images and aggressive stripping, you still take dependencies for things to function, and a robust container scanning process covering both OS-level and dependency vulns produces volume that grows quickly. It also gets more complex when the same CVE shows up in different contexts. Just because one team has evaluated a CVE in one container doesn't mean the evaluation transfers to a different team's product in a different container. For base image vulns you can often get a "global answer," but that's not the case for most vulns, each context needs its own review. So the suggestion isn't about reducing what gets exported; it's about simplifying the human-in-the-loop step so the resulting information is higher fidelity. Does the government really need each of these tracked as discrete structured fields, or would a single "justification" of why a vuln isn't yet remediated suffice for the narrative-judgment elements? In my experience, agencies primarily want to understand the "why", the justification for why remediation hasn't happened yet and what compensating factors are in place. The objective fields (tracking ID, detection time, reachability, etc.) absolutely should stay structured, that part of your response I fully agree with. That said, this is just one CSP's perspective. I'd be genuinely curious to hear how other medium-to-large CSPs running most of their production workloads in containers have experienced the VDR BIR. |
Beta Was this translation helpful? Give feedback.
-
You're definitely tracking all of that on your side, so you'll have all that information available - but I totally agree that reporting all of this in detail is messy and undesirable. VDR-EVA-GRV (Group Vulnerabilities) is intended to provide that middle layer to reduce cruft in reporting and is designed expressly to allow flexibility by the CSP. For containers in that situation, you would never need to scan all 1000 either - you presumably know every aspect of what is going into them on deployment based on a build setup and can establish guardrails to ensure they are not likely to drift during use. You can then entirely avoid the need to ever scan the containers by redeploying them within the monthly timeframe, or by using sampling to scan a limited number of containers. If you have 1000 unique containers then that's a design issue. ;) End result is that in most situations, regular vulnerability detection and response reporting for a 1000 container environment is likely going to be whittled down to 1-5 rows of reporting data based on grouping, and those reports will generally be very simple.
Yes, that's certainly something we expect, within grouping/sampling. You can't just ignore evaluating something because you have a lot of different somethings. ;) There are lots of ways to establish technical guardrails to reduce the effort and impact here though, and the VDR encourages that. Some re-architecture will be necessary to optimize the flexibility the VDR gives you, but we think that's going to be in your best interest in the long run. You can short-circuit a lot of evaluation via technical controls in advance, and would want to get to a place where "containers that have label X can never have an internet-reachable vulnerability" etc.
We definitely want the information to be high-fidelity for humans, and hope that extensive grouping and sampling will address a lot of that. Reviewing a vulnerability report with 10-15 rows of detailed information will be a huge improvement for customers over the current situation of thousands and thousands of individual scan issues to parse through.
Agreed! The reporting requirements serve two major purposes - the first is to provide this information to agencies as that's the most important critical stuff, which is why we want it condensed by group and sorted into simple fields. The second reason we require detailed reporting, and all of the additional fields, is for the CSP to demonstrate that they are following a complete internal process to perform Vulnerability Detection and Response and showcase the effectiveness of that process. Most customers will not be concerned with this on a day-to-day basis, but it will play a significant role in both initial authorization and annual re-authorizations. It also creates a competitive security marketplace that allows past performance metrics to be included in comparisons between vendors for the government. For example, given two similar offerings, an agency might be willing to pay more to adopt an offering that consistently demonstrates a clean, quick, and effective VDR process in their historical metrics over one that sneaks in consistently under the maximum timeframes. In short, this is one of the areas we've adapted Rev5 to align more with the tenets of 20x - the government wants to see actual performance metrics of your security program, tracked over time, for effective decision making and awareness. Rev5 does not provide this in any meaningful way, and would quickly become unusable when compared to 20x if we did not require providers to adopt some additional metrics into their reporting. |
Beta Was this translation helpful? Give feedback.
-
|
Focusing on the grouping of vulnerabilities On grouping itself: VDR-EVA-GRV makes sense in principle, but VDR-RPT-VDT and VDR-RPT-AVI then requires per-vuln "time and source of the detection" (# 2) and "time of completed evaluation" (# 3) as reporting elements, in addition to other requirements. If I group ~300 distinct container CVEs into a handful of logical groupings, those ~300 CVEs will have hit at different timestamps across different scan cycles, and evaluations will have completed at different points as different teams worked through their respective contexts. How is grouping supposed to reconcile with those time fields? Some explicit guidance, or an example of what a "grouped" row actually looks like at the schema level, would help. I know the PMO is generally reluctant to publish examples, but it isn't clear to me what you're looking for here and examples would be extremely helpful. To the direct question: do you genuinely expect ~300 distinct container CVEs to compress to fewer than 10 reporting rows under the VDR? That seems aggressive given that base-image vulns are only one of several CVE source categories; language-specific dependencies, OS packages, and application-layer issues generally don't share evaluation context across products. I want to make sure I'm not under-grouping out of habit, but I also don't want to over-group in a way that obscures real per-context risk. |
Beta Was this translation helpful? Give feedback.
-
|
Posting our VDR beta feedback here per the PMOs suggestion: SummaryParticipation in the FedRAMP Vulnerability Disclosure Report (VDR) beta provided valuable insight into the program's direction and surfaced both meaningful improvements over legacy processes and areas that would benefit from additional clarification before broad adoption. Successes and ImprovementsImproved triage through the N# severity scale. The N# vulnerability severity scale represents a meaningful improvement over the previous Deviation Request heavy Plan of Action and Milestones (POA&M) process. This was accomplished by shifting the evaluation to earlier in the process. This allows teams to concentrate attention and remediation resources on the most urgent, high-severity findings rather than spending equal effort managing a large volume of lower-priority items that had previously required individual deviation requests. Focus on automation. The tight response windows prescribed by the VDR framework make manual, ad hoc vulnerability management untenable at scale. This creates a clear incentive to invest in automated scanning and alerting workflows. Organizations that embrace this push toward automation will be better positioned for success. Areas for Clarification and GuidanceArtifact requirements are vague The beta guidance did not clearly specify which artifacts should be submitted, or in what format. This creates risk, organizations may need to produce different artifact sets tailored to individual auditor preferences or those of their Authorizing Official (AO). Where an auditor's expectations and an AO's expectations diverge, there is currently no clear mechanism to resolve that conflict, potentially resulting in duplicative or inconsistent documentation. Suggestions include having an example of a Vulnerability Index for tracking the vulnerabilities in both a machine and human readable version. While we understand that VDR offers freedom for CSPs to deliver what AOs want to see for VDR; having an example of what meets FedRAMPs expectations would help guide organizations. Additional guidance on partial remediation would reduce ambiguity. The current framework does not clearly define what constitutes a valid partial remediation. For example, whether applying a compensating control, isolating an affected component, or reducing the attack surface qualifies as progress toward closure. Explicit criteria or worked examples for partial remediation scenarios would significantly reduce this ambiguity. Further clarify SHOULD versus MUST requirements. The distinction between SHOULD and MUST requirements in the VDR framework deserves greater emphasis. In practice, stakeholders often focus on the most visible data point, such as the 4-hour response window for N5 (critical) vulnerabilities. Without fully understanding that many requirements are aspirational rather than mandatory. Clear visual or structural differentiation between MUST and SHOULD language would reduce misinterpretation and help organizations prioritize their compliance efforts accurately. |
Beta Was this translation helpful? Give feedback.
-
FedRAMP's direction is to create rules that encourage innovative private-sector driven solutions. FedRAMP is deliberately moving away from standardizing artifacts in a way that limits innovation and discourages cloud service providers from competing on customer experience. In the short term this may cause some issues because many agencies do not have access to automated GRC platforms or other capabilities that can easily translate machine-readable information into their preferred format, but all agencies are required by policy to implement such tooling. And this type of capability is simpler than ever in 2026. On the human-readable side, we strongly encourage folks to think outside the template box. You can engage design experts to work with customers and build something that provides value to everyone, factoring for your unique environment and complexity. This flexibility allows you to compete on the quality of your vulnerability detection and response presentation, instead of flattening everything and everyone into a single janky spreadsheet. Independent assessors should only be verifying and validating that you're meeting the requirements, not demanding a specific format. And while an AO's expectations may diverge, that is a simple fact of business and it gives you an opportunity to work with them to craft something better for both of you (hint: don't confuse contractors working for an AO with an AO - you should be working directly with an AO on something like this).
I think this might be a term issue that I can do a pass through for clarity. We don't use remediation and mitigation interchangeably, and don't allow for partial remediation. We consider a Fully Mitigated Vulnerability to be different from a Remediated Vulnerability. Hence statements like "Providers SHOULD partially mitigate, fully mitigate, or remediate vulnerabilities..." don't include "partial remediation" because that's actually partial mitigation. Semantics, but is intended to avoid confusion through precise language.
Our guidance should be consistent in mitigation being a step-by-step process that can have an outcome of full mitigation or remediation. Either way, partial mitigation is defined as linked above, so please let me know if that definition needs more clarity! edit: oh, I noticed that "partially mitigate" and "fully mitigate" aren't configured as alternate variants of the Partially Mitigated Vulnerability and Fully Mitigated Vulnerability definitions so they don't hit the terms array so it's not obvious these are defined while looking at the rules - will fix!
We've added a slightly more detailed Force of the Rule section in the Consolidated Rules, but have generally avoided adding too much complexity here. The intent here is to allow normal reasonable people the flexibility to make decisions that make sense in the context of their service. Vulnerability Detection and Response is a bit of an art. The limitation on MUST requirements and focus on SHOULD recommendations in the VDR is designed to ensure that cloud service providers do the right thing, the responsible and secure thing when making decisions, instead of doing the compliant thing. The timelines are a great example of that - partially mitigating something just under the wire of a timeframe might be the compliant thing, but it shows a focus on compliance over security. The right thing usually is to partially mitigate something as quickly as possible and not care what the maximum timeframe is in most cases... but there are (rare) valid situations where the right thing is to let something slide past the timeframe (active investigation, partial mitigation carries higher risk, etc.). In those cases we want to ignore the timeframes and do the right thing. Less compliance, more responsible decision making for everyone. :) |
Beta Was this translation helpful? Give feedback.
-
|
Posting our ADS beta feedback here per the PMOs suggestion: SummaryParticipation in the ADS beta has highlighted the potential for structured data sharing to modernize the FedRAMP program. However, a critical gap remains in the absence of a standardized assessment rubric for auditors. Furthermore, current guidance relies heavily on future marketplace features that do not yet exist. This creates a potential dependency risk for Cloud Service Providers (CSPs). To ensure a fair and consistent baseline, FedRAMP should emphasize common formatting standards and re-evaluate overly prescriptive "MUST" requirements, such as UEI mandates, that may not apply to all organizational structures. Successes and ImprovementsModernization & Efficiency in Data Exchange: Shifting toward a modular, structured approach allows for "write once, share many" efficiencies. This reduces the burden on CSPs who previously had to manually copy-paste control responses across multiple static documents (SSP, SAP, SAR), leading to version control errors. Enhanced Data Granularity: The ADS framework allows for specific data elements (like vulnerability metadata) to be shared without exposing the entire authorization package. This improves the security posture of the program by adhering to the principle of least privilege during the data review process. Foundation for Continuous Monitoring: By moving away from monolithic documents, the ADS beta sets the technical stage for real-time risk posture updates. This is a significant improvement over the legacy "snapshot in time" assessment model, which often becomes obsolete shortly after a signature. Areas for Clarification and GuidanceMarketplace Dependency & Non-Existent Solutions: The current beta documentation frequently references marketplace-driven solutions to solve data-sharing challenges. Relying on these non-existent products as a cornerstone for the ADS framework creates significant uncertainty. FedRAMP should provide guidance that is independent of future marketplace features so that CSPs can build reliable internal roadmaps based on current, available tooling. Establishment of an Auditor Expectation Rubric: There is a pressing need for a formal rubric detailing typical auditor expectations within the ADS framework. While a rigid template may not be required, internal consistency across the FedRAMP program is essential. Without a clear "baseline" for what constitutes a sufficient machine-readable submission, CSPs, specifically new entrants, are at a disadvantage compared to legacy products with established auditor relationships. Refining Mandatory (MUST) Requirements: The UEI Example Certain data points currently classified as "MUST" should be reconsidered to better reflect organizational realities. For example, requiring a Unique Entity Identifier (UEI) number as a mandatory field for all public-facing information may be overly prescriptive. Moving such items to a "SHOULD" category allows for the flexibility needed across diverse service and deployment models without compromising the integrity of the authorization data. Format-Agnostic Baselines (The "Common Format" Rubric): While FedRAMP should not mandate a specific format (like OSCAL), it would be highly beneficial to share which formatting styles are most commonly accepted by auditors to ensure both machine and human readability. Instead of an endorsement, FedRAMP should provide a rubric of functional requirements for data formats. This would create a baseline that allows for innovation while ensuring that whatever format a CSP chooses, it will meet the auditor’s need for automated ingestion and manual review. |
Beta Was this translation helpful? Give feedback.
-
|
Posting our VDR beta feedback here at the request of the PMO:
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
This post provides a bit more detail on our planned approach to Rev5 improvements to begin the public conversation that will continue throughout upcoming Rev5 balance improvement tests and releases. All of this is subject to change as the environment, priorities, and decisions shift; FedRAMP's standard disclaimers apply.
Note: This thread is open for discussion but is not a formal Request For Comment.
Balancing FedRAMP Rev5 against improvements to FedRAMP 20x
FedRAMP’s primary focus this year is the development of FedRAMP 20x: a modern cloud-native approach to the security assessment and authorization of cloud services used by federal agencies. This approach will open the federal market for new businesses and enable rapid adoption of emerging best-in-class commercial services by the government, but there are close to 500 cloud service providers used by the government today that are heavily invested in the traditional Rev5 approach.
The Rev5 approach will become imbalanced, unfair, and ineffective compared to 20x if Rev5 continues unchanged. A new approach prioritizing innovative solutions for incremental delivery, testing, evaluation, and improvement can take risks during development that are unacceptable for an established approach like Rev5; changes to Rev5 must be made carefully, deliberately, with intent to minimize disruption and unpredictable impacts.
Our approach to Rev5 balance improvement assumes that improvements designed for 20x should be made available for Rev5 when feasible and appropriate so Rev5 will continue to be a viable path for FedRAMP authorization while 20x is developed and expanded. As improvements are drafted for 20x, FedRAMP will consider their application for Rev5 as optional balance improvements:
Rev5 Balance Improvement Test: Limited release of optional improvements to test and evaluate the impact, effectiveness, and benefit of the improvement for Rev5. These will often be called “beta tests” for simplicity.
Rev5 Balance Improvement Release: Formal wide release of an improvement made available for all Rev5 authorized parties; such releases will typically be optional but may be required when absolutely necessary.
Minimizing impact to existing investment
In general, FedRAMP intends to minimize any required changes to Rev5 authorization (initial or ongoing) for cloud service providers. We anticipate the following approach for Rev5 Balance Improvement Tests and Releases:
In general, we expect balance improvements to be positive changes that cloud service providers choose to adopt but understand there are often business reasons to maintain the status quo.
Managing impact to agencies
Things are a bit different within the government - laws, policies, and administration priorities rule the day. Federal agencies will be impacted by changes to FedRAMP and government policy just as they always have been. FedRAMP is working closely with OMB OFCIO, the FedRAMP Board, the FedRAMP Technical Advisory Group, and the FedRAMP Agency Liaisons group to manage the impact to agencies. OMB OFCIO and the FedRAMP Board are also working with the CIO and CISO councils to support.
FedRAMP has been working to improve collaborative continuous monitoring to make it easier for all agencies to meet their statutory obligations to monitor the security of cloud services that are used in federal information systems, but many agencies and cloud service providers still rely on a single lead agency to do most of the work for continuous monitoring. If a cloud service provider is still relying on a single lead agency for continuous monitoring, FedRAMP will expect the cloud service provider to coordinate with their lead agency on their participation in Rev5 Balance Improvement Tests and Releases until they transition to full collaborative continuous monitoring.
For agencies, we anticipate the following approach for Rev5 Balance Improvement Tests and Releases:
Phased rollouts
Rev5 Balance Improvement Tests and Releases will generally be made available in a carefully phased rollout. The duration of these phases will vary by projected risk and impact, and some releases may skip some of these phases or add new phases if necessary. In general, Rev5 Balance Improvement Releases will follow these phases:
Development: An initial standard, requirement, or change is developed (including public comment) and prepared for Rev5 testing if relevant.
Closed Beta: A Balance Improvement Test will be available to limited invite-only participants based on agency needs and the risk tolerances of the CSP and lead agency to begin testing the release.
Open Beta: A Balance Improvement Test will be available to limited volunteer participants in a carefully structured environment while the release is tuned and finalized.
Wide Release: The Balance Improvement Release is made available for any cloud service provider to adopt along with a supporting framework to simplify the process based on learning and improvements made during testing.
Managing optional feature sets
The current Rev5 ecosystem for FedRAMP authorizations doesn’t have a lot of variance - everyone has pretty much met the same requirements and implemented the same things in the same way from an assessment standpoint, which makes it simple for agencies. Optional Balance Improvement Releases will make things a bit more complicated as CSPs start to pick and choose which releases they adopt and when.
FedRAMP will need to develop an approach to help stakeholders manage and leverage these different feature sets. Working with stakeholders on innovative solutions to monitor, understand, and apply different Rev5 feature sets based on Balance Improvement Releases will be a key aspect of early testing. This may start with something as simple as specific identifiers for which optional Balance Improvement Releases are adopted by the CSP in the FedRAMP Marketplace and authorization package materials.
What’s next
We’re planning out our roadmap based on current staffing and the projected impact of these improvements. The following released Standards and RFCs will form the likely basis for the next Rev5 Balance Improvement Tests & Releases:
This is just the beginning, but it will also give us plenty of opportunity to work with our stakeholders to refine and improve this approach.
Interested in participating in a closed beta?
Cloud service providers who are interested in participating in a closed beta may email rev5@fedramp.gov to discuss participation with the FedRAMP team directly.
Beta Was this translation helpful? Give feedback.
All reactions