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.
-
|
Thanks for posting these up over here for discussion too Johann! FedRAMP still can't really interact with casual comments if they are exactly the same as formal public comment; we're strictly limited in participation to avoid giving any appearance that we are trying to influence public comments. This creates a deeply awkward situation and I can't propose any solutions that involve changing your public comments as then I would clearly be influencing public comment. 🤷 These rules are so weird for us too, thanks for understanding. Given that members of the public may submit multiple comments, I'll engage in a strictly limited manner for public awareness on some of the questions raised in this discussion. We will consider the full content of your public comment appropriately along with any follow up. Broadly to a few of your questions - this is Phase Two pilot. In the Phase Two pilot we are explicitly and deliberately encouraging a wide variety of approaches in order to see how effectively folks can demonstrate different things, just like Phase One. Almost any time there's a question about how to implement a KSI our default is actually to turn that around and ask the CSP the question back. Folks should really be thinking about this as an opportunity to demonstrate capabilities, not as a list of things that need to be met.
We wanted to broaden this to stop people from over-indexing on operating systems (it's a thing) and continue our gradual change from "system" to "service" - because these requirements apply to services, not systems. Something more like "log and monitor modifications to the cloud service offering" might be more clear. Also noticed we missed updating this in the primary KSI description itself, oops.
There should be a persistent process applied to different types of changes that take place at intentional and documented times in the lifecycle of the change. That may be before, during, and after a change for some changes, or only before for other changes, or done after on a regular basis for others.
This KSI as originally written was one that participants in the Phase One pilot struggled with frequently and clarifying the intent as being specific to ensuring identity and access management systems were designed with the assumption of compromise helped more folks demonstrate how they had done that. Might be worth remembering that 20x is not targeted at folks who are familiar with the federal space.
In this case "by default" is intended in the plain language meaning, i.e. do it unless you have a reason not to. In general encrypt everything. I have a hard time believing any reasonable person is going to argue that unencrypting a bunch of previously encrypted data and leaving it lying around is a secure design decision that makes sense to them. :p Regarding removal of federal information, this is part of a shift towards acknowledging that cloud service providers can't know what is federal information and what isn't - they can only know what is information their customers have put into the system, therefore should encrypt that information by default.
... I don't even with this Johann. 🤣 Too many scars over wack arguments between people! I don't anticipate needing to clarify what log data is but if that's a common thread in public comments we'll do it if we have to. We ended up defining "machine-readable" after enough people wanted to argue about it. 🧯 As to why this was added for moderate, KSI-IAM-04 is focused on accounts and services and we wanted to be very clear that access to log data itself should be managed at moderate based on the risk of sensitive information that can exist in log data.
KSI-CMT-03 doesn't prevents you from intentionally making a change that leaves behind residual issues; this is a step up that explicitly adds this requirement that we think should be managed at the service configuration level rather than the change management level because change management might not assess this. e.g. You might decide to move from one database to another and validate following KSI-CMT-03 that the new database has everything you need and the change worked great and everything is happy and everything is using the new database. KSI-SVC-08 expects you to actually turn off, stop using, and properly dispose of information in the old database. KSI-SVC-10: "What is the objective state that is being sought?" This has considerable room for improvement, yay for public comment! 😀 The intent is to ensure that cloud service providers don't retain customer data after the customer no longer wants that data to be stored by the cloud service provider. A common example of this is spillage (where someone put something they shouldn't have into a cloud service offering) but there are plenty of other circumstances at the moderate level where the government might want information removed entirely from a service offering. All of the above information shared for public awareness based on early questions raised by a public comment and do not reflect endorsement of the linked public comment or intent to influence public commenters by FedRAMP. |
Beta Was this translation helpful? Give feedback.
-
|
Appreciate the discussion on KSI-SVC-10. I think there needs to be a distinction between a spillage type event where someone puts data into a CSO that shouldn't be there (and may need to create a support ticket to resolve it) versus a typical delete in the UI (average user mis-spells something and deletes it) because otherwise this KSI potentially sets privacy against availability in a way that most CSPs don't want to support. For example there are frequently customers who "delete" data accidentally and then ask for a restore from backup to retrieve data that they deleted. If this KSI prevents a CSP from being able to provide restore from backup for customers who inadvertently delete data it may be placing privacy ahead of availability. But in the case of a recognized spillage or data oversharing with the CSP there should be a process to remove that data. I assume that's what the "if appropriate" is getting at. |
Beta Was this translation helpful? Give feedback.
-
Concur - "unwanted" is doing a big lift here, most backups would be wanted as part of the service. There's tons of room to clarify this, we were like "we'll do technical assistance to explain it" but that always comes later. The target is effectively this: If an agency customer wants data removed from your platform, you need to be able to remove that information entirely (or at least show that it will be removed automatically etc. and how). This is similar to what most private sector customers would expect but agencies have a particular need to be able to do this that means you need to know what level of demand you can meet. For backups, from a technical perspective, the worst case architecture here is making sure all customer backup data is encrypted with a unique key that just be deleted in a break glass situation; much simpler than digging through snapshots/archives/etc. |
Beta Was this translation helpful? Give feedback.
-
|
Why the emphasis on machine-based in the new KSIs? |
Beta Was this translation helpful? Give feedback.
-
|
@ethanolivertroy I think its because FedRAMP's definition of information resources is broad and includes info about "personnel, equipment, funds, etc.". Focusing the KSIs on machine-based places more focus on the system or service itself, which is probably more measurable and capable of being reported on in an automated way. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, that's exactly right! We're starting to clarify in areas where the realistic expectation is that something will only apply to machine-based information resources versus all information resources. This started out in the Vulnerability Detection and Response Standard when we realized there were times when specific requirements or recommendations should be focused or only applied to machines. So, for example, with KSI-CNA-01 you don't need to limit inbound and outbound traffic of your personnel, and KSI-SVC-01 doesn't require you to harden your office space, and KSI-SVC-04 doesn't expect you to automate your bill payment, KSI-SVC-05 doesn't require you to use cryptographic methods to verify that people at your office are the same people you hired, etc. |
Beta Was this translation helpful? Give feedback.
-
|
Perhaps there needs to be some clarifying language in the updated KSI-PIY-01, too, then, i.e., I wonder if you
[edited to rephrase from Q to comment] |
Beta Was this translation helpful? Give feedback.
-
I've added a Public Comment too: #83 (comment) |
Beta Was this translation helpful? Give feedback.
-
This is one of those where yes, I would definitely expect a secure cloud service provider to understand who their employees are at any given point, which team they are on, what role they are in, etc. Same for how they are funding different lines of business, etc. If you aren't inventorying and managing non-machine-based information resources then how can you ensure the security of your machine-based ones? (wouldn't expect a CSP to share these details with the government but would absolutely expect them to demonstrate to an assessor that they inventory them) |
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.
-
|
No one will be able to read? |
Beta Was this translation helpful? Give feedback.
-
|
The net sum information that you need to understand about FedRAMP under 20x will be a fraction of what it was before, and we'll make sure to keep things continually updated and in a clean state similar to monitoring releases vs nightly build branches in software; folks who want to pay attention to the bleeding edge can, those who don't need to shouldn't. Then I'm hoping with machine-readable docs there will be plenty of opportunity for refinement; folks will be able to generate topic-specific items, worksheets, etc. out of them by filtering for things like requirement level, impact level, who it affects, and eventually things like what part of the authorization process it applies, what team might be impacted, etc. Plus the ability to generate single documents or web-readable indexes that combine everything into one place should be of benefit. The most important thing to me is removing the idea that there is some "secret information" that you need to pay someone for because there are years and years of random cruft built up that is confusing, contradictory, partially in draft, etc. spread across hundreds of documents. FedRAMP will always be complex enough that subject matter expertise will be valuable, but it should be something like kubernetes - if you want to try to dabble with it you can, and if you want to sorta spin something small up you can, but if you want to run it at scale you probably need someone that has done it before. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the check-in. agreed that FedRAMP is inevitably complex. thanks for all your work. |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
@fortetroy, I think we'll be okay. 😅
|
Beta Was this translation helpful? Give feedback.
-
|
Figured I'd pop in to say that FedRAMP may do the assessment directly for 20x for certain prioritized critical or emerging technologies to speed up authorization time when urgency is a factor. We wrote this standard with this in mind; it might've caused a lot of confusion about FedRAMP's role in a direct assessment if all of the requirements and recommendations were written for third-party assessment organizations. |
Beta Was this translation helpful? Give feedback.
-
|
Is there any concern for this in terms of potential corruption or abuse? Example, if you know someone in an administration, you might be able to get your product listed as critical and avoid paying for an initial 3PAO assessment? Will there be strict requirements on what type of product would fall under this exception and which committee/entity would be allowed to rule on this? |
Beta Was this translation helpful? Give feedback.
-
FedRAMP prioritization is outlined in the law and re-emphasized in policy under M-24-15; prioritizations like the AI Prioritization are developed by FedRAMP in consultation with the FedRAMP Board and the CIO Council (and the GSA Office of General Counsel). |
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.
-
|
Haha yeah I think this is just because everyone (including us) tends to think of each of the #'d validations as being KSIs so things like this slip by. Maybe we need to just lean in on that and move back towards like KSI families w/ individual KSIs since that's basically what we're doing in practice. But yes, confirming the intent is summaries for each validation. And these summaries should really be able to be used as the the business goals agreed to by the engineering and compliance and executive teams rather than something built for FedRAMP. |
Beta Was this translation helpful? Give feedback.
-
|
Sounds good! Thank you for clarifying. I do the same thing by calling each KSI validation a KSI and calling the KSI categories "families" after the 800-53 style. Old habits die hard I guess |
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.
-
|
Good point! I just updated the discussion post to include RFC-0018! |
Beta Was this translation helpful? Give feedback.
-
Businesses with FedRAMP authorizations should consider urgent communication from FedRAMP to be the highest priority messages on behalf of all of their government customers; it's pretty much the one time where there is zero margin. Responding within the timeframes proposed (or alternatives based on feedback) are not that unreasonable against typical high quality SLAs for customer support.
This, like always, is up to the CSP to define and apply; you know who senior security officials in your organization with the authority to respond to messages from FedRAMP are, you know how and when to route things to a more senior official if it's appropriate, etc. Also these senior security officials don't have to be receiving all messages from the inbox, just messages originating from .gov or .mil addresses. The point is primarily that if this inbox is monitored by general customer support or similar staff that they have a process to immediately route urgent messages from FedRAMP to the proper officials.
It's the only option at the moment for FedRAMP that can scale comms to everyone.
All Necessary Parties is defined in FRR-FRD-18 as "All entities whose interests are affected directly by activity related to a specific cloud service offering in the context of a FedRAMP authorization. This always includes FedRAMP and any agency customer who is operating the cloud service offering, but may include additional parties depending on agreements made by the cloud service provider (such as consultants or third-party assessors). Potential agency customers or third-party cloud service providers should also be included in most cases but this is not a mandatory requirement under FedRAMP as ultimately the cloud service provider may choose who they wish to do business with." The CSP should know their necessary parties.
It's definitely intended to be severe - having a human acknowledge and address security communications from the government within a short time-frame is something we'd expect CSPs doing business with the government to prioritize. |
Beta Was this translation helpful? Give feedback.
-
|
@mjprager I had the same thoughts reading the standard. The trick is that there could be extremely time-sensitive communications that need to be sent, and like pete said, there is nothing besides email that is rolled out en masse. One rock and one hard spot. How does a public inbox getting anything and everything sort out this one important message? technically not just one. There may be very urgent agency emails in certain circumstances (lets say they need to check for a breach imminently). It would be good if we could key in on something in the email. Something that signals - hey, this is a do now thing. Then engineers could script it to go into an incident queue where CSPs have processes in place to handle it. I can think of keying in on a list of specialized email addresses or perhaps a combination of trusted address (CISO@state.gov) and subject or body string ('act or CAP'ed :)'. JK, don't do that one, you will get meme'd to the full extent of the law) |
Beta Was this translation helpful? Give feedback.
-
|
It seems clear that from the one side, Gov realized that a critical system was unreliable and from the other side, a sizeable portion of the CSPs aren't thinking about incident response like they should, which unfortunately mars the required trust that the FedRAMP program needs to run smoothly and efficiently. Hence a very strong reaction. I believe a side effect of rolling this out 'as is' will be the dilution of the seriousness of the CAP. Or, to maintain the CAP's importance, FedRAMP will need to show lenience in whatever cases they can, formally CAPing the clearly negligent (even then, how many are there?) On the other hand, some CSPs will probably have a poor guy wired to that inbox the first few months. For as long as the CISO can justify before another executive decides the time to monitor is waste that needs to be re-allocated. Then they will get cap'ed anyway, boohoo, the guy gets his thankless job back for another year. I'm going to propose that FedRAMP (and/or other agencies) issue a trusted list of senders that require an immediate response IF they include "Action Required: Urgent" in the body of the email. That may be over-prescriptive but the guy wired to the inbox will thank me. |
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.
-
|
It's never a good idea to assume an email address is secret or hidden, so I think we'd just expect allow listing emails from .gov and .mil domains that have the appropriate verification in place (BOD 18-01 requires agencies to have valid SPF/DMARC records). A modern service should have plenty of ways to sort the randos from the actual .gov/.mil senders. |
Beta Was this translation helpful? Give feedback.
-
|
You could also create special rules that will forward the emails sent to the security inbox to the key security personnel when the sender has a .gov/.mil account |
Beta Was this translation helpful? Give feedback.
-
|
Ya I was just curious if there was an easy way to reduce the overall spam for everyone rather than hundreds CSP dealing with it individually. Ack we can easily limit this inbox to just .gov or .mil domains however we quiet often get emails from contractors working on behalf of the government to review packages and they are using their contractor .com email domain. I am sure that is against agency policy but does happen. On the plus side, the bad sales emails written by people not understanding FedRAMP produces some good humor to laugh at internally. |
Beta Was this translation helpful? Give feedback.
-
|
lol you'd be amazed how many emails I get at pete@fedramp.gov from folks wanting to help me get FedRAMP authorization! 😆 I feel ya. |
Beta Was this translation helpful? Give feedback.
-
|
RFC-0018 |
Beta Was this translation helpful? Give feedback.
-
|
Absolutely, recommend flagging this in formal comment too! Under the Authorization Data Standard you can add whatever information you want as well. |
Beta Was this translation helpful? Give feedback.
-
|
RFC 17: FRR-PVA-AA-10 |
Beta Was this translation helpful? Give feedback.
-
It's getting a bit clumsy but the italics are for formally defined terms that are being used in the context of their formal definition:
Note this standard applies only to 20x and will not apply to Rev5, so it doesn't change the role of the assessor in the traditional process. We don't feel the need to change this for Rev5 as at least initial assessments will halt for Rev5 within the next year or two and it would take that long to change direction. For the 20x process, we want to be clear and explicit that the role of the assessor is not to determine if something meets FedRAMP requirements and should receive an authorization; their role is to ensure that FedRAMP has sufficient accurate and confirmed information to make the authorization determination. This is because both the FedRAMP Authorization Act and M-24-15 require FedRAMP itself to perform the final assessment and make that determination (especially for program authorizations).
We expect the assessor to "analyze, validate, and attest to the quality and compliance of security assessment materials provided by cloud service providers" (44 USC § 3611) - including comments on that; but we do not want them to make an overall "this passes FedRAMP requirements" type of recommendation as FedRAMP must determine that itself. A benefit of this is that it removes the extremely common complaint from CSPs that 3PAOs hold them hostage over a final recommendation while also addressing the opposite-side complaint from 3PAOs that it hurts their business to fail a CSP. It also allows us to open up dialogue between the 3PAO and CSP because there is less of a potential conflict of interest if the 3PAO is not making what appears to be a final determination about the CSPs security posture. |
Beta Was this translation helpful? Give feedback.
-
|
That makes a LOT of sense. |
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.
-
tl;dr: "FedRAMP authorization" != "Authorization to Operate" - there is absolutely no such thing as a "FedRAMP ATO" and never will be. It's such a complicated thing to explain and goes against so much historical understanding and many years of people having silly dreams about a world where a centralized FedRAMP would just do "all the things" on behalf of the federal government... The nutshell is that a FedRAMP authorization is (and always has been) an assurance that there's a package available for an agency to use, and that federal agencies do (and always have had) have the responsibility to ATO their own systems based on the materials in those packages. There is a common misunderstanding about things like a "FedRAMP ATO" resulting from the unfortunate plain-language use of the word
What does this all mean?
There's a ton of nuance here that most people don't follow and aren't able to follow because the interactions between these new laws and policies and old laws and policies are quite complicated. FedRAMP is working with OMB, the Board, and many various councils to help produce more clear materials to help agencies understand that changes to laws and policies mean that... things change. Providing formal explanations of all of this is on the to-do list. It's complicated though, especially by all the slop out there. |
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