General discussion and Q&A for RFCs related to Rev5 Updates (RFCs 0026, 0027, 0028, 0029, & 0030)

[rhoesing]

This thread should be used to ask general questions about RFCs 0026-0030. All of these RFCs are related to Rev5 so we bundled them together in one large release however broke them out into smaller RFCs to help gather comments incrementally to avoid one large RFC.

[wisecryptic]

RFC-0027, I believe that there is a mistake in the final CM-12(1) control change? the title refers to CM-12(1) but the body refers to CP-2(8)

[wisecryptic]

jtb-p made the same comment in the RFC thread
#131 (comment)

[adamlang-1kosmos]

Can new RFCs be added to the Public Notice page? https://www.fedramp.gov/notices/ It would be nice to be able to rely on that RSS feed for the initial RFCs and not just the outcomes to them.

[pete-gov]

You can use the website changelog RSS feed for updates that include when new RFCs are posted: https://www.fedramp.gov/changelog/rss.xml

(we cobbled these together pretty fast and it would make sense to have a sorta central approach, alas)

[adamlang-1kosmos]

Thanks.

Do I assume correctly that would then also grab changes to the Public Notices page and I can unsubscribe from that RSS feed then?

[pete-gov]

Do I assume correctly that would then also grab changes to the Public Notices page and I can unsubscribe from that RSS feed then?

Yes, but the updates on the changelog RSS are just like "hey there's a new public notice" whereas the public notices RSS feed will actually have the entire public notice content. :)

[wisecryptic]

RFC-0026 states: Providers implementing the Vulnerability Detection and Response Balance Improvement Release do not maintain Plans of Action & Milestones.
Where do these providers track non vulnerability findings? Is this in the RET/non-prescribed document for both 20x and rev 5?

[pete-gov]

Sorry I missed this Q in my stack - there is no such thing as a "non-vulnerability finding" - a vulnerability by definition includes assessment findings:

FedRAMP Definition of Vulnerability: Has the meaning given to "security vulnerability" in 6 USC § 650 (25), which is "any attribute of hardware, software, process, or procedure that could enable or facilitate the defeat of [...] management, operational, and technical controls used to protect against an unauthorized effort to adversely affect the confidentiality, integrity, and availability of an information system or its information." This includes gaps in Rev5 controls and 20x Key Security Indicators, software vulnerabilities, misconfigurations, exposures, weak credentials, insecure services, and all other such potential weaknesses in protection (intentional or unintentional).

The VDR has specific instructions for reporting on Vulnerability Details. These are similar in scope to what used to be a POA&M, however it also allows the cloud service provider to just straight up accept a vulnerability (definition: accepted vulnerability) and provides instructions on how to Mark Accepted Vulnerabilities.

So if there is a traditional finding where the result is that the cloud service just doesn't intend to address it for whatever reason, they would document it as an Accepted Vulnerability and it would live in their vulnerability reports forever or until they have a reason to revisit and fix it.

[cb-axon]

Am I reading RFC-026 right that if a rev5 CSP does NOT adopt VDR yet, they will be required to make available to all agency customers raw scan results of every type?

[pete-gov]

Can you point to a specific section here, RFC-0026 doesn't have anything specific about scan results. If it's a general question about making continuous monitoring materials available to all agency customers then yes, this is already required, Rev5 certified providers have to upload raw scan data to their shared folder.

edit - adding direct link to source requirement, and noting that it does have a caveat for "when required by agreements with agency customers."

[cb-axon]

"Providers MUST share vulnerability information with all agency customers and FedRAMP using one of the following two processes:

Implementing the Vulnerability Detection and Response Balance Improvement Release for Rev5 (either in Beta or Wide Release); or

Sharing Operating System, Database, Web Application, Container, and Service Configuration Scans, at least monthly; AND sharing updated Plans of Action and Milestones (POA&Ms), at least monthly; AND sharing all scans performed by an Independent Assessor, at least annually."

I read the non-VDR path as explicitly requiring raw scan results. To be clear, right now we don't typically have to share raw scan results with all agencies. Just lead agencies. Most agencies lack the capabilities to parse all of our raw scan results anyways, to the point where even the lead agency doesn't do it. Personally, I think parsing by 3PAOs during assessments is validation enough, given that agencies are not equipped to handle such information. Can you clarify if the intent with these lines is to require raw scans be shared in rev5 with all agencies, and NOT in VDR? If so, it sounds like VDR is actually a step backwards for transparency, though an improvement in disclosure safety. I'd rather see the requirement for providing monthly or continuous raw vuln scans removed entirely, and they be artifacts of 3PAO review only, and disclaimers made that csps may redact necessary information from scan results to protect the system as well (even with 3PAOs), so long as level of risk is understood well enough for assessment.

[pete-gov]

Thanks, I must be context switching too much in the small amount of time I have to pop into GitHub and pulled up the wrong RFC. Thanks for your patience and providing that.

Yes, this update to CA-7 would require sharing of scan data with all customers and FedRAMP; this is already expected, and folks upload this info to their shared folder. We've even audited it to monitor usage, but former JAB authorized services used to send that data just to FR for distribution and High impact services control access to their data in a way that FR doesn't audit it as effectively. The update isn't really intended to change requirements as much to clarify that things should work for former-JAB services the same way they work for everyone else, which is that agencies that want to see this should be able to. Even if they are never reviewed, they can be reviewed as needed. I'm aware of at least one instance where an OIG dinged an agency for not verifying integrity and accuracy of the raw scan logs on a monthly basis. Subject to change based on feedback of course.

Separately, the VDR is a more modern approach that resets the expectations for the exact reasons you've outlined and others - raw scan logs are not generally useful or used by agencies for the purpose of "double checking" or "verifying" the integrity and accuracy of decisions made by cloud service providers and they aren't necessarily of value to do that anyway. The additional transparency required by other areas of the VDR offsets the security blanket vibes of having access to raw scan data.

[cb-axon]

Also, on RFC-030 for RA-5 updates, are we not including that container scans are also required? Those are required in other fedramp documented requirements for rev5, and was a huge deal back in ~2021 when initially announced as required. In fact, any csp I've seen that does them has 90% of their reported vulns from those due to the nature of the scanning. Want to make sure I'm reading right if fedramp is okay for rev5 to stop reporting vulns from that scanner type.

[pete-gov]

Containers are a machine-based information resource! They are much easier to checksum and only do samples on tho.

[cb-axon]

Right, I agree with that, but RFC-030 specifically says "operating system/infrastructure; web applications (including APIs) and databases" for the types of scans/assets to scan.
This does NOT mention containers. Are we no longer required to do container scans for RA-5?

[pete-gov]

Ah, my bad, I checked it briefly and focused on the copy/pastes from the VDR. The original doesn't say anything about containers either, so nothing about container requirements is changing here. That said, this proposed update doesn't fold in the container scanning requirements that exist elsewhere like it should. I think that's where the confusion is created?

Also just to be super clear, RFCs don't change anything, so it's the final wording that matters... but as proposed this doesn't formally add or remove any requirements related to containers (the control text still applies).

I personally am not a fan of blanket container scanning as it's an inefficient way to go about things that often decreases the overall security posture of a system (hence the changes in the VDR), but if you think they should explicitly be included/excluded/etc. in the FR defined assignments then please let us know on the RFC.

This set of proposed changes might be overcome by events due to the changes planned in NTC-0009 either way, it's basically just bridging current requirements until July 2027.

[cb-axon]

Yeah that's where my confusion stems from. This calls out specific scanning types but not others in other guidance. Historically we've all accepted that container scans didn't get listed in RA-5 guidance just due to order of operations. If it's left out of this coming update, many csps will be hard pressed to continue being forced to do container scans without explicit inclusion in other types of scanning. The language in this RFC still allows sampling as I think container scanning should where appropriate. But like all scanning and vuln management activities, evaluation of contextualized risk is even more critical when dealing with the amounts from container scanners. But that doesn't mean it should be left out in my opinion, because it's the only tool that really finds vulnerabilities on containerized workloads. Os/infra scanning hasn't really been finding those, even when we've confirmed they're real.