Q&A and Casual Discussion on Phase Two RFCs (14, 15, 16, 17, 18) #85
Replies: 11 comments 29 replies
-
|
I'd like to drop my formal comments from RFC-0014 in this channel as well. Would love to have some conversations and back and forth on some of the new KSI changes and additions: There are some interesting updates in this RFC release, please consider the following feedback: KSI-CED-01: - Update was clearly made to include all required training based on the moderate baseline, why was contingency plan training excluded? Should it be included? I know most organizations combine IR/CP training into functional and tabletop exercises but was just curious if the exclusion was an oversight or purposeful. KSI-CMT-01: - Clearly the change from “system” to “service” was very purposeful, but to me “system” seemed to be all inclusive while “service” seems to scope the KSI requirements to a subset. Is there an explanation for this very purposeful word change? Would it be possible to add the definition of “service” and “system” to the FRMR.FRD definitions? KSI-CMT-03: - The use of the word “persistent” based on the definition: “Occurring in a firm, steady way that is repeated over a long period of time” and associating it with changes creates a slight dichotomy. For “routine recurring” changes, I can see this meaning that each time one of these changes is pushed, there should be a way to demonstrate it was tested prior to production and then post deployment (i.e., impacts to configuration/security baseline based on change). I assume this is why “prior to deployment” wording was removed indicating a desire to know impacts of change as part of deployment pipelines AND on production system state. However, Adaptive, Transformative and Impact Categorization changes do not occur with a “persistent” frequency and thus requiring “persistent” automated testing and validation is open for interpretation. Is the meaning of the KSI to determine, for these types of changes, that automated testing is performed as part of the deployment pipeline and once deployed to production, whenever one of these changes occur? Essentially, is the objective of this KSI concerned with the automation around the testing of changes when they occur as opposed to any sort of automation that runs on a persistent basis to determine ongoing state of the production system? In addition, I suspect that FedRAMP stripped out the "prior to deployment" part because for many CSPs, automated testing prior to deployment is likely conducted outside of the authorized boundary (e.g., system where staging is not within boundary, so generating automated validation for this may be out of scope for them). Testing and validating prior to deployment seem like a best practice that should always be encouraged, so removing it from KSI-CMT-03 feels odd. It also seems to go against CM-3.2 that FedRAMP has mapped to this KSI; CM-3.2 mentions testing & validation of changes to the system before finalizing the implementation of the changes. When I look at some of the other controls that FedRAMP has mapped to this KSI (particularly CM-4.2 & SI-2), it seems like FedRAMP is shifting the focus of the KSI to configuration and vulnerability scanning coverage to include newly deployed components. If that is indeed the case, FedRAMP should reword the KSI to be clearer and update mapped controls accordingly. KSI-CMT-04: Suggest using the term “Regularly” as opposed to “Consistently” since there is a definition of that term in FRMR.FRD. Or, if “Consistently” is used it should be explicitly defined in that document. KSI-CNA-01: - Suggest adding the term “Machine-Based” to FRMR.FRD and explicitly defining it. This addition seems to scope the KSI requirement and it’s important to understand the definition to understand what has explicitly been scoped out of the KSI. KSI-CNA-05: The addition of "unwanted spam" in the same KSI seems a bit awkward because “denial of service” and “unwanted spam” are not necessarily related in most cases. Additionally, there are many other common cloud attacks that are not included in this KSI. FedRAMP should consider reframing this KSI so it is broader but allows CSPs to demonstrate (in an automated way) that they employ a multi-layered defense against the most common attacks. Alternatively, FedRAMP should split this into separate more specific KSIs (e.g., one specific to DDoS, another for spam). KSI-IAM-05: - To be honest, this is an incredibly vague KSI that could mean just about anything in both its prior and proposed wordings. Could the PMO explain how the wording change better fits their objective of this KSI? This explicit explanation might help to understand what specific objective the PMO would like to achieve with this KSI. KSI INR and KSI-INR-01: - The change in wording justifies a definition of “Incident Response” in FRMR.FRD. KSI-MLA-03: Given the “FedRAMP Vulnerability and Detection standard” that is now referenced in this KSI was just released this week, and how significant a change it is compared to rev 5 vulnerability management policies and procedures, I would expect most CSPs will need a transition period to fully meet those requirements. KSI-PIY-01: - A definition of “Authoritative Sources” in FRMR.FRD would provide a lot of clarification around this KSI. KSI-PIY-06: - Suggest defining “commitment to delivering a secure service” in FRMR.FRD. This KSI is terribly vague. Without some sort of explicit definition of what a true “commitment” is (e.g., a specific minimum percentage of annual budget per time period, or X amount of overall company personnel dedicated X amount of hours per time period), this KSI doesn’t do anything. I understand the argument would be: “This varies from organization to organization”. My counter argument to that is: “I agree, and thus if an organization could provide nearly anything to demonstrate compliance with KSI, there’s no quantitative value in the KSI and it should be removed from the baseline”. A potential wording update for the KSI could be: "Persistently review and harden machine-based information system resources to improve security" KSI-SVC-01: - Suggest definition of “Continuously” as its own line item in FRMR.FDR. It is currently defined under “Persistently”, but if it’s going to be used as target objectives, it needs to have its own line item. Suggest defining “opportunities to improve security” in FRMR.FDR. As with the previous PIY-06, lacking any real quantitative objective removes the validity of the KSI. KSI-SVC-03: - The removal of “all federal and sensitive” seems to be a step backwards. The focus of 20x, in my interpretation, is to protect sensitive federal data. By utilizing the term “information” here, the door has been opened to once again include all information within the system, whether or not there is a valid reason to have non-encrypted, no sensitive data. The term “by default” needs to be defined in FRMR.FRD. To me “default” represents a state of data. I could start with data that is encrypted by “default” and then run a process which changes the data’s default state. At that point, does it still need to be encrypted? KSI-SVC-04: - Suggest defining “automation” in FRMR.FDR. KSI-SVC-05: - Suggest creating an entirely new draft standard to define this KSI. Specifically, “cryptographic methods to validate the integrity of machine-based information resources”. There are just too many ways to KSI-TPR-01: - The wording change has made to this KSI is far less quantitative and thus far more difficult (if not impossible) to achieve automated, machine-readable reporting on. The previous iteration was quantitative (e.g., I can have automated look at the state of my system to identify APIs in use, and documentation to evaluate documented lists of third-party providers). The new wording introduces too many variables. If desired state is to ensure CSP is following the Minimum Assessment Standards, suggest taking the relevant sections of that standard and creating quantitative KSIs based on each relevant section. KSI-CED-03: - Suggest adding “Best Practices for delivering secure software” to FRMR.FRD. A possible suggestion here – I assume FedRAMP would like to see something more valuable than a “check the box” compliance exercise where high-level engineers are forced to take a useless LMS-based software design module on an annual basis. How about a FedRAMP Standard around certification requirements for system roles, with an understanding that maintenance of industry-recognized certifications through CPE programs is sufficient to be considered “ongoing role-based training”? KSI-IAM-07: - I interpret “list of information resources” to be the system inventory. Can the terminology be changed to something more akin to: “Document the event types that will be monitored, logged, and audited for all resources defined in the system inventory.” Also suggest defining – “event types”, “monitor”, “logging” and “auditing” in FRMR.FRD. I have concern around this KSI being too broad in nature, but explicit definitions may help scope its requirements. KSI-CNA-08: - Suggest defining “security posture” and “automated enforcement” in FRMR.FRD. This KSI opens a In addition, careful consideration needs to be taken here. In my opinion, the only way to truly implement this would be through an Agentic AI-based approach within the management plane. “Automated Enforcement” requires agents with access to tools that have been granted privileges in the environment in order to implement in a meaningful way, as the KSI is currently documented. There are true security considerations that need to be examined and better understood before those types of agents are deployed, ecosystem wide. Forcing that type of change via a KSI, may be a larger scope than will be supported in the ecosystem as part of 20x and will lead to further agency pushback. I really think some scoping and deconstruction of this KSI into its component parts is required. KSI-MLA-08: - Suggest defining “just in time access” in FRMR.FDR. Curious why this KSI has been scoped specifically to “access to log data”? Interestingly, the associated control is SI-11. Is there any further clarity that can be provided around what is meant by “log data”? Maybe defined in FRMR.FDR? KSI-SVC-08: - How does this KSI differ in objective from KSI-CMT-03? My assumption of the point of CMT-03 is to automatically test and validate changes so that you aren’t introducing negative affects into the environment. This KSI seems like a KSI-SVC-09: - See my comments on KSI-SVC-05 – There are just too many possibilities around acceptable means of “continuously validate the authenticity and integrity of communications” KSI-SVC-10 – Suggest defining “unwanted information” in FRMR.FDR. I think a lot of clarity needs to be added to this KSI? What is the objective state that is being sought? I feel like this is targeted at some sort of very specific scenario. In its current iteration, I can’t figure out what “removing unwanted information” actually means? Is this a “data sanitization” process? Is this tied to some sort of desired action in the system (e.g., removal of databases, objects in object stores, etc.) and thus tied to some sort of expected log entry? |
Beta Was this translation helpful? Give feedback.
-
|
Why the emphasis on machine-based in the new KSIs? |
Beta Was this translation helpful? Give feedback.
-
|
I agree with @jdettweiler's comments on KSI-CED-03. A good standard that engineers can reference will be useful to ensure that "best practices in delivering secure software" are covered in whatever training meets the requirement's intent. But overall, I feel as if it's not a strong control but more of an HR checkbox. If the intent was to have security baked in at the developer level, then maybe KSI-CED-03 has to get split more to define what is role-specific. For example, |
Beta Was this translation helpful? Give feedback.
-
|
I have a general comment on the sustainability of forthcoming guidance. As FedRAMP adds additional terms, rules, and frameworks, how are we going to keep this grokable (lets get that added to FedRAMP definitions ;) for those new to FedRAMP? I am nervous that CSPs, particularly SMBs and disruptors, will get more and more lost in the FedRAMP requirement maelstrom while experts and consultants will find more and more opportunities to bill for non-value-added work. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
In RFC 17, FRR-PVA-01 does "for each Key Security Indicator" refer to the validation level e.g.: one simple high-level summary for KSI-CNA-01, a second high-level summary for KSI-CNA-02, a third for KSI-CNA-03 or does it refer to the KSI category level e.g.: one summary for all CNA validations, a second summary for all SVC validations, etc? I assume that the summary and details on how each validation is made would be granular at the KSI validation level eg: KSI-CNA-01, -02, -03 in order to be specific to the requirement of the KSI validation but the phrase "each Key Security Indicator" makes me wonder if the summary should be at the higher level category grouping.
Thanks, |
Beta Was this translation helpful? Give feedback.
-
|
Discussions allowed for RFC 18 here as well? If so, would like to express concern about having severe penalties (CAP) on first failure, relying on emails not received/acked in time. Emails seems antithetical to our shared goals for FedRAMP 20X automation, and going straight to a suspension/CAP when dependent on an unreliable technology and human processes for adherence to a very short SLA for response is a very draconian escalation. What is the strict definition of "senior security official"? I or my ConMon team has historically answered on behalf of my org for Emergency Directives, and they are usually straightforward to answer (because almost always, we're either already aware and working on it, or have zero impact - can't remember one where the ED is where we first heard about a vuln). Is this really saying that I now will need to always have those routed to a senior security official like a CVP? It's unclear whether they will be able to in turn delegate to me to ack and address? Do we really feel that email is "reliable" if we are trying to ensure "Federal agencies will have a reliable way to contact security teams at cloud service providers"? A small nitpick, but also seems fair to ask for: Is FedRAMP committing to an SLA for acknowledging and implementing submitted changes to the "their FedRAMP Security Inbox by emailing info@fedramp.gov with the name and FedRAMP ID of the cloud service offering and the updated email address"? Who are "all necessary parties (other than FedRAMP)" that we will now be committed to ack and address? If a random contractor at an org with a .gov or .mil email (legit or faked) asks us any question related to FedRAMP or security, the way this reads now is that we're required to route it to a senior security official, cannot use any spam filters (because that might result in not addressing without human review), and every single one needs to be addressed within 1 business day -- or we are immediately suspended for a minimum of 30 days and publicly placed on a Corrective Action Plan... on the very first failure, and/or for any/all emails sent to that mailbox...? This seems super severe, TBH. At a bare minimum, it needs to be not all emails sent to that box, but only ones that are clearly called out as an "urgent security notification" in some pre-agreed upon fashion. I'm not sure that different standards should be applied based on impact level (an emergency directive comes with clear timelines to respond within its own language - if it's a big deal, it's a big deal for all CSPs, not a tiered big deal). I get and appreciate that FedRAMP found a hygiene issue of not having up to date contacts, and it should be addressed by the associated parties, and reasonable processes in place to keep such severe drift from happening again (such as the quarterly testing). Respectfully, and casually, :) |
Beta Was this translation helpful? Give feedback.
-
|
RFC 18 We get a lot sales spam to these inboxes that are publicly posted as companies know they are monitored by security/compliance staff. While if someone abuses these mailboxes, we just block that entire company’s domain from sending future emails it is still an annoyance. I’m sure other CSPs are dealing with the same thing. |
Beta Was this translation helpful? Give feedback.
-
|
RFC-0018 |
Beta Was this translation helpful? Give feedback.
-
|
RFC 17: FRR-PVA-AA-10 |
Beta Was this translation helpful? Give feedback.
-
|
in the RFC-0016 comments, #87, someone commented that FedRAMP would make the 20x authorizations and be the ultimate authorizing entity. I believe this is framed wrong. My understanding is that FedRAMP would list CSPs with no initial agency as authorized, but that each agency still need to issue an ATO and, even with the presumption of adequacy, need to continually review and approve use. is there a clarifying document on this? |
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.
-
The primary purpose of public comment is for FedRAMP to receive information and opinions by giving "interested persons an opportunity to participate in the rule making through submission of written data, views, or arguments" (per the Administrative Procedures Act). FedRAMP does not respond to questions in public comments and they are the most difficult form of public comment to consider because the commenter's view, argument, or opinion can only be inferred.
This thread can be used for casual discussion about active RFCs outside of the formal public comment process.
FedRAMP may participate and occasionally respond to questions in this discussion if it does not appear to be influencing public comment.
This thread is for the five 20x Phase Two RFCs released in September, 2025:
Cheers!
Beta Was this translation helpful? Give feedback.
All reactions