🎫 FedRAMP Day: Consolidated Rules for 2026 (June 23, 2026)

All right, we're going to get started today. Uh, thank you for all of those who came in person. Really appreciate it. Want to thank you to the liaison programs, both those who showed up in person, those who are online. Um, it looks like we have a uh a decent crowd online. Uh, so thank you for joining. Uh I want to acknowledge the ISSOs, the A&A teams, the cyber staff, federal employees, contractors who support FedRAMP and uh as well as any other our GSA colleagues who joined today. Um today's going to be not just informational um but what we really like to get out of these events is a lot of Q&A. We have uh Greg Barbashia here, FedRamp director to answer questions about uh the newest and upcoming things on FedRAMP. So, please um those of you in the room, we'll have a mic that we'll pass around during the Q&A and online there's a Q&A feature you can use uh to ask questions. Um we're really excited to do this. This is our fourth Fed Ramp day. The first one was a really big turnout a year ago at OM. The last one was a pretty big turnout at ATF. Um, this one was kind of an abbreviated Fed ramp day. We're only doing a half day. Uh, tomorrow we plan to release CR26. So, you'll learn a lot about that today. And then, um, just a awareness in September, uh, there may or may not be a a much bigger event. Uh, we'll get the word out well in advance so folks can sign up and come to that event. Um, and with that, I want to turn it over to our deputy administrator, uh, Mike Lynch, who's here today, to open us up. And, um, after that, we'll jump in to, uh, our, uh, fireside chat with Pete and Greg. Thank you. Hey, good morning and thank you. Um, really excited to be here and really excited for this program. You know, your continued engagement with Bed Ramp and the broader community is really what makes this program work and this partnership matters more now than ever as the entire government looks to ways we can use technology as a means to go faster and be more effective. You know, Fed Ramp is not just a compliance program. It's a governmentwide enabler, the foundation that allows agencies to adopt cloud technology faster, more safely, in a way that every agency can build on. Secure cloud adoption is central to how we modernize government services and delivery for across the entire public ecosystem. GSA is deeply committed to this mission, but we also have incredible partners with OM OF's CIO and many others throughout the federal government. I think to acknowledge where we are today with Fed Ramp is also to look back and say where were we and what was working, what wasn't working. In 13 years, Fed Ramp certified just over 350 cloud service providers. That certification process took on average 12 to 18 months and upon um already being certified, you would have to have an additional 4 to 12 on top of that to add on additional products and services. The team really took that challenge on and said this isn't working for what we need at the government and we need to scale. Uh I really want to acknowledge the team that worked on this. They completely rebuilt Fed Ramp and looked at the 20X team as a way to say how do we go faster and fix what's not working. Today there's roughly 525 certified cloud products on the Fed Ramp marketplace. Fed RAM 20X moves from a paperbased certification process to one built on automation, machine readable evidence and continuous ver verification. Certification timelines drop from what used to take years to now weeks for eligible services. And the security bar goes up, not down. Reuse becomes the default one certification usable by every other agency. So we stop duplicating the same work dozens of times for the same product. And we're already seeing the speed translate into results. Two years ago, initial certification decisions took 9 to 12 months. Today, our target is 30 days, and we've been meeting that target. Our goal is to get the initial determination down to one week by ensuring the certification package gives you what you actually need to make that call. The support behind it matches the ambition. The newly released um federal EOA playbook positions technology modernization as a governmentwide priority. And Fed Ramp is implicitly a part of that and a huge aspect of enabling that strategy. The resources, the policy direction and the institutional support are moving together. But what does that mean for you? It means you get better tools, fresher data to make your mission more specific. Uh make quality risk based decision-m that only you can make. Agencies are not passengers in this process. You're the ones implementing cloud services in real environments with real stakes stakeholders to to serve your mission. Fed Ramp sets the baseline. You bring the context that makes it meaningful. The work only succeeds if agencies are equipped to use the new model confidently and consistently. And that is exactly what we're here today to try and do. Now you'll hear from our pol our colleagues at OM on policy direction, Fed Ramp on the new model and pathways and SISO on the threat landscape that's shaping all of it. When you leave here today, you should know exactly where federal cloud security is heading and why. Thank you so much to the team. Thank you all for being here and u thank you for your partnership with GSA on this program. Pete and Greg, I think you're uh you're up next. I got a green light. Oh yeah, look at that. Greg Barbacha, Federal CIO. For those of you that don't know, I'm Pete Waterman, the Feder director. Greg and I also have a strange relationship because he's also >> he's also the technology transformation services director acting uh so he's my boss here at GSA when he puts on one hat usually without a suit jacket on and then he's federal CIO over at OM and I work with his team on a day-to-day basis. So, it's been really awesome having this strong relationship in a way that, you know, it doesn't feel like we're very far away from the decision-m. >> I wish somebody told me when I was in the private sector to be careful how much I complained about Fed Ramp because one day maybe I'd be in charge. >> That's [laughter] the beautiful karma. But there is something really special about having somebody that actually had dealt with it on the other side telling us what to do as opposed to somebody that's only listening to the complaints of big businesses and doesn't really understand the perspective. So today we got a few questions we're going to work through. I'm going to be reading off some of these on my phone. Um, the first thing I'm want to talk to Greg about is why from the federal CIO perspective is federant modernization important. >> We have to get new technology into the government faster. Everybody knows that. And the administration was very heavily focused in the early days about making procurement easier. And we saw the revolutionary far all the onegov deals. But if you can't deploy the technology, being able to procurement faster isn't great. So the next step in deploying technology is getting through the cyber security regime. So having as many secure cloud environments as possible allows us to deploy things. That is the crucial step in the process. So that's why this is such a big focus. One of the things that is really weird being like here at Fed Ramp is that we're like immersed in the policy and the law on a day-to-day basis. And it's easy for folks outside uh to forget that we have the Fed Authorization Act has around 19 pages of requirements for Fed Ramp. And then OMB memorandum M2415 which came out almost 2 years ago has another like 21 pages of requirements for feder that makes it we don't get to just pick and choose what we do right like we have to follow all those rules and um as we're developing 20x it's really founded on a lot of the principles directed from M2415 which is better was imposing government requirements on commercial companies It was treating every cloud service as if it had to be the most secure thing like like a military base in a lot of cases because we're lifting and shifting DoD rules. So like in general as this changes, what do you think agencies need to understand about the Fed 20X process from OM's perspective? It's our policy that we want to move forward as a whole of government enterprise. Everything being siloed adds to so much duplicity across the government. And another big problem we have is doing things that have a large amount of human subjectivity to them. That's why structuring the data is so important and it gets us to this place of reuse where we could trust and inherit controls from other places. And that's really really important. >> It's really funny. One of the things I laugh about often is that when the Feder authorization act was passed in 2022, it had a thing that basically said within a year, GSA will automate all Feder assessments for everyone. Uh, which is literally just not a thing that is possible. [laughter] So, instead, we're spending a lot of effort making sure that we have the foundation to allow some automation to take place. And the automation is a great point because if we're being honest, our cyber adversaries don't care that we have boxes checked in some sharp point folder somewhere. So we need to move past things that we could automate as quickly as possible and allow the agencies to understand the context of their missions to really decide their security outcomes. >> Yeah. I mean on that I think I'm going to go off some of the talking points for a bit and like you've you've gotten to play with some of this new stuff that is just entirely changing the game over the last six months like in a way that we got inklings that AI would be able to do some stuff a year ago but now we're like oh no like anything to share about that perspective >> yeah AI is interesting in our context because it allows you to kind of emancipate the data asset without having this whole ecosystem around it. No more echoes. >> Um, so what we're seeing with artificial intelligence is the ability to kind of go through things way faster. Obviously, that's why Fed Ramp is so focused on the environment we're deploying things into. >> Yeah, it's crazy. I think I saw a I don't know how much this was made up, but I saw a thing from OpenAI on LinkedIn that basically was tracking the number of findings of some of the partners they're working with, and it's like, congratulations, we found out how to find vulnerabilities faster, but now you have a thousand vulnerabilities you have to fix. We're going to talk a bit more about vulnerabilities and all that fun stuff uh later today. Um, so 20x has been around in pilot form. We did our first first authorizations certifications now uh 6 months ago. We've got some of the largest hottest most in- demand companies in the world coming in through this path as part of the AI prioritization initiative. OM's been like working really hard to get that deployed across uh companies or agencies. like have you been surprised at how slow that adoption has been for both like AI services and new capabilities? >> Uh surprised and disappointed and I understand it's tough. People understand the way they have done things in the past, the way they've been trained on doing things and as all of us cyber security practitioners in the room know, there's very few ways to really ruin your career in the government and a cyber security sidestep is one of them. So, I understand that trepidation, but this is the only way we're going to be able to move fast. And it that's why we're making these policies from OM to kind of let the whole federal enterprise know that it's okay to adopt a new way of doing things. >> And it really is, if you look forward a few years, like we're going to have a completely different way of doing things. Like the the approach is different, the prioritation prioritization is different. I think one of the things I heard you say early on was the idea that you should be able to deploy a cloud service or a tool for a specific task, use it for 6 months and then turn it off and walk away from it if you don't need it anymore. And that is not a muscle that we have. >> Yeah, we talk about this incubator idea. um we need a better way of going from here's a demo from a vendor that this techn is interesting to me and then the next conversation the very next conversation is the enterprise risk conversation which will take years. So we're talking a lot about how do we spin something up quickly allow people to test things on synthetic data that's relevant to their mission and then we could move into a conversation about enterprise deployment. I think that's really exciting. Yeah, better class A. This is a new certification path. It's going to uh all the rules and requirements going to be posted tomorrow. It's going to be available to the public uh I think a month from now. And that theory is is really important. We see agencies all the time wanting to use cloud services to do prototypes, demos, um, pilots, things like that, but they always still add, it's got to be Federam certified first. So, OM told us two years ago, find a way to make that happen easier. And class A is super exciting. It's going to be this like you bring your own external commercial security certifications. that's enough for an agency to make a decision for low impact stuff that's just testing. So like how do you think what does it look like for you for agencies for CIOS especially to start changing their processes to prepare for that? >> Definitely don't wait any longer than this afternoon if you haven't started already. Uh you need to start thinking about your internal processes and how to adjust them for the world of Fed RAM 20X. What's really interesting is how repeatable it is and removing the human uh subjectivity. Like I asked earlier, the best thing we can do is a process that is repeatable and when you put in the same data a thousand times, you get the same output a thousand times. And that's what allows us the confidence and the comfortability to reuse it. Part of what makes this really interesting from an AI perspective is how five years ago if you want to do automation if somebody dumped me a machine readable package that was in their own format uh it would be really hard to go through that and suck out the information that you wanted etc. Now, if you have access to any decent agentic AI pipeline, you're just like, "Here, look at this package. Tell me the 15 things in this policy that I care about and highlight all of this. Don't hallucinate anything." And it generally doesn't. >> It is is great all day. XMLs into whatever you want. >> Quite quite fun. Um, so you've been here now federal CIO days. [laughter] Do you prepare that or do you do you write that down every morning? Yeah, I I have heard that you have a calendar at OM that has like dayby day count days down. Yeah. 942 to go. >> If now that you've been here >> this morning, [laughter] >> I'm curious about two things. Same question, different timeline. Let's go back to three months after you started. If you could wave, if you could have waved a magic wand then, what would you have just like snapped and make change and then now, what would you think of that idea from back then? >> I would have put more pressure around sunsetting rev 5. I think the government works really well in crisis mode when there's a timeline and there's something you have to move towards. What's not great is when there's ambiguity about when do I need to make this change or there's uncertainty about is this ever really going to change or is this some weird pilot program that potentially goes away. Um and as we you know discuss those uh announcements today I think that would have been good to do a while ago. >> Yeah, I can definitely feel that on my side. That's always been one of the lines that's been hard to navigate is like are we going to get rid of this? What what does it look like? Um, so it's pretty clear now that we have that direction that 20X is the model going forward for Feder. Like that is for folks that don't know, Federam 20X isn't just the new type of authorization. It's actually the code name for the entire modernization process. So what we're trying to get to is where you just have a Feder certification again and that Feder certification will be a modern machine-driven automatically validated verified assessment. So, we got a few people here in the audience and untold numbers of folks on the phone. Um, with Greg here in his role as a federal CIO, curious if any of you have any questions that you'd like to ask of Greg and I'll just flag if you have questions for me, I'll do a Q&A from a Fed perspective later. I think we should keep Greg the star of the show here. >> Always cautious of hands that shoot up immediately. And >> introduce yourself and your agency, please. No, it's actually just a segue uh based on the Rev Five comment. Um, one of the uh points of confusion we have is um our agency still able to sponsor uh Rev Five um companies that want to go that route. Uh for now, >> I think that might be more of a B question. uh we will stop accepting any Rev 5 certifications on June 11, 2027. We strongly discourage like if the current advice is if you're in the process with someone, you should complete that process, especially if you have, you know, mission need, etc. Especially if they're going to come in at class D. Like, get that over the line. Get that over the line. You've got one year. If you are not already in that process, if you're just thinking about it, talking with folks, etc., send them over to the program and send them the 20x type. Like we want to have a consistent front door run by Fed Ramp that provides and ensures that we have the same reusable adequate information for everyone rather than agencies running their own processes all over the place. >> Yeah. And now's the time to start building the muscle memory. So the longer you keep accepting new Rev 5 packets, the later to the game you will be getting comfortable working with the Fed Ramp team on 20X. >> I can take a a online question if you're ready. >> Yeah. >> Okay, perfect. How should agencies handle internal policies that still require traditional Rev Five artifacts? Update your policies. Rev 5 is going away. 20X is FSMA compliant and policies are made by humans who made decisions. We need to make new decisions and change the policies. It's as simple as that. Like every other policy in the government. >> Yeah, this is one of the ones I struggle with a bit because M2415 directed agencies with a deadline of January of last year to update their policies to align with uh the modernizations that Better Amp will be making. And so to Greg's point, update your policies. Like we're going to try to support you in that. We're working with OMB a lot to try to get information out about how that can look like, but like update your policies. Stop doing the same old stuff. Okay. Uh, another question. How should agencies explain 20X to AOS, SISOS, and IG's? So I don't I I think this is a strange question. I'm just gonna Why would a SISO an IG and a CIO not understand and follow emerging technologies, modernization paths, requirements from OM, etc. Like that's that's their job. Uh if anything, I would expect it to be happening the other way around. Um, you should not have to explain FedRAMP to anyone. Fed Ramp can do that for you. OMB can do that for you. The CIO council can do that for you. Uh, so if you're running into situations where your executives are not paying attention to things that are changing in government, I'm sure OM would love to know about that. >> Yes. >> Perfect. Uh, we have another question. Um, how do we encourage small business innovation if they have a product but can't afford the Fed ramp certification? Are there pathways to assist or expedite the process if they have a viable capability? >> Good question. And we've discussed uh what possibilities could potentially exist to encourage small business. uh we understand it's a huge barrier to entry but what it gives them is entrance into the largest marketplace uh arguably for their products and the ability to iterate with the biggest customer in the world uh in new ways and that's really the cell and that's why the investment needs to be there class A certifications are designed for that use case too like come in get it test it decide if you want to use it if you want to use it pay them to get a class B pay them to get a class like companies shouldn't have to invest upfront in order for you to talk with them and prototype with them. So you got to change your policies to be using these class for that instead of saying well if you come up with $2 million of VC funding maybe we'll talk to you later. >> Hi good morning. My name is Maria Hishal. I'm with the department of commerce. You mentioned earlier about the whole of government approach and all of the you know machine readable automatable processes. I think we are where we are today with some of this disconnected disproportionate maturity across government because this appropriate the appropriations funding and the funding paths are disproportionate. Everybody gets their own funding and runs it their own way. So what is OM doing to have a whole of government approach to funding these programs so that all of government can be at the same level of maturity because automation as Pete said doesn't happen overnight. It takes technology. It takes transformation. It takes workforce and so what is OM's approach in the whole of government for you know funding and workforce to make this happen and make it a reality? Yeah, we we hope that we're sending a strong signal to the agencies that this is something that needs to be invested in. That's manifesting itself in the president's management agenda that we have uh regular meetings on with all the deputy secretaries about deploying funding that their agency gets to modernizing technology faster, more efficient technology as part of 14440 maybe if I got that executive order number right. Um, and also there's going to be uh related guidance you'll see in spring guidance for budget guidance that comes out of OM this week as well. >> I'll say on the agency side, I don't know how much everyone has experienced in the budget process, but one of the things I got to experience last time around that was really funny. Uh, M2415 told agencies that they needed to procure governance, risk, and compliance automation capabilities and needed to budget for that. And during passback, I got this weird thing from CFO that was like, they're asking us about Fedramp GRC tools and why that's not in our budget. Can you answer that? And I had to explain that's like a GS GSIT thing. That doesn't have anything to do with FedRAMP. That's like GSA has to budget for a tool that can consume the certifications that my program is overseeing. Uh so I can't answer that why that's not in a budget. But all that to say, the desk officers, the budget examiners, they have 100% cared about making sure that agencies request budget for this type of capability. Hopefully that will happen more next year. David Meyer, Department of Education. Um, just a few minutes ago, you mentioned uh I guess 20X is like NIST compliant and speaking to a lot of the Fed ramp or CSPs and and just other, you know, ISSOs who are definitely coupled with NIST right now. Um, so when you say NIST or when you say 20X is now NIST compliant, maybe just expand on that for a minute. I >> think I said FISMA compliant. >> Yeah, FISMA compliant. >> FISMA compliant. >> So there's a there's a lot here that's really frustrating when we talk about this stuff. Um, so let's talk about NIS. First of all, most of you and and most folks in government don't sit down and read NIST materials, but you should if you're in this game. Um there is massive sections of the 853 across multiple documents as well as the 800137 and all other NIST framework documents that explain repeatedly over and over and over again and you've heard me say this before at every single Fed day. Do not use controls as a checklist. That is not what they exist for. Stop doing it. Oh my god, please don't do that. That is not how risk management works. Better 20X is entirely based on the concept of capabilities. It's really important to understand you as an agency are required to follow the FSMA process as well as all of the additional patch stuff. We often say the FSMA process, but really we're talking about the OM A130 because FSMA just says do what OMB tells you. OM put out the A130 says follow these processes. That's for your information systems. That's for things you control, things you operate. You don't need to use that process to assess the security capabilities of external systems that will be leveraged as services within your federal information system. 20X is designed to give you that very clean, very rapid ability to assess the security capabilities. There are multiple chapters in the 853 and otherness documents about this approach in order to determine if they meet the requirements that you have. So this is a mind shift for how you approach using a Federant certification. In the past, most people would just look at the controls, copy and paste the information, and you would it was like, have you ever seen a meme that's like you made this, I made this? Like that's what you do with these system security plans, but you didn't make this and you don't control it and you don't own it and you can't take responsibility for the decisions that an outside business is going to make. So follow the 853, follow the risk management framework, align with the OMA130 and any of its modernized updates, but that's in your use of the system. You can still review the security of an external service via a different process that is designed to be quicker, easier, more efficient, and help you make those decisions. and also leverage the Fed Ramp team who is here to assist you in this process of doing the KSI to security control crosswalk analysis for you and helping you understand how to interpret these things. >> Good morning. Ralph Jones, Department of Treasury. So, I have a follow-up question on that. Um what is your vision about how you see Fed Ramp under 20X helping agencies to understand a a common language for security capabilities given that 853 is going away? Um how are we to make sure that we can compare cloud provider A B C on a level playing field when it comes to those capabilities? >> Great question. So you know my job is my purview is technology but everything is culture right and the reason we have a problem with interoperability across the government and reuse is because there's cultural barriers some agency got popped 10 years ago now forever I don't trust anything that comes out of that agency I know that AO or that SISO over there I don't for whatever reason trust that person so now I'm going to run this entire process again at tremendous cost to the taxpayer in in the time of civil servants So when we could move to something that all the evaluation criteria the same especially when they're machine readable that's why I keep talking about taking the human objectivity uh subjectivity rather out of that and you understand this went through the process if I put it through the process I would get the exact same output and that's how we kind of get rid of this barrier of culture um that stops us from sharing things and inheriting things. Yes, that's why he's the boss. >> Hi. When are we going to see uh OM Circular A130 updated? I think last time it was in 2016. >> Yeah, man. My life in 2016 way different. Um massive, massive undertaking, but there's a bunch of things we need to update and A130 is on my dream list. if there's certain things I want to do in my tenure as federal CIO and getting that updated is definitely one of them. It's before cloud and it's just no longer relevant. Um, and in case anybody's interested, some of the other things include working with the Hill, things like the paperwork reduction act and the privacy act are 50 years old before the modern era at all with computers and technology has outpaced the way a paperbased process protects privacy and personal data. So all these things are are something we're focused on. I would love to get A130. It's a priority and but it is a massive massive undertaking. >> You have managed to pick off some of the older things, especially the ones that set kind of like an acrosstheboard mandate, right? Like M2605 resended M2131 and said agencies need to make their own risk based decisions about how to do logging and things like that. Um how hard has that been compared to something like the A130? Is that like low lift or are they all big? >> Memos are way easier to resend. So the interesting thing with the login memo was that was had such a tie to money, right? People were able to say this is costing us tens of millions of dollars a year and we're not using this this data. So that was a bit easier. OM circular. So it's like an MMO, a circular, an executive order, right? Um, and not only is A130 so voluminous, it's it takes a lot of time because there's so many uh budget strings attached to that and getting that cleared out of the White House is a monumental undertaking. It's a monthsl long process of just getting the words changed at least because we the worst thing I tell my team we could do is sit at the White House and come up with policy in a vacuum. So this includes making sure we're engaging with this community and all the other communities that are relevant. Then taking the lessons and coalesing them down and then finally sitting down and holding the pen. Uh what I plan on doing is locking everybody in a room for 12 hours day one to at least prevent the initial all right let's have a plan for a plan for a plan. So it will be uncomfortable and the air conditioning will be off but I think we will get a better solution faster. Are you guys still emailing word documents back and forth when you work on that stuff? >> Yes, the White House. You guys think you have problems with cloud? >> We have another question online. Uh you have mentioned automation and machine readable data. Will FRAMP be publishing schema definitions to ensure the machine readable data can e can be easily imported by agencies? Yeah, I'll let you take this one. I, you know, back in the day when I think of forcing everybody into a format, I kind of hate it because people love TBM, people hate TBM, and now we're just forcing the entire government to do that. As you alluded to earlier, AI does make it easier for us to change structured data formats, but I'll let you give details. >> Yeah, so we've pivoted a little bit on this over the course of the last year. Um we're pretty my background as a technical engineer is uh in fact my first job in like the 90s was doing ETL extract transform load across data sets. So like I come from this perspective that there's no purpose in doing that. It's a waste of time. All you need is a half decent engineer and half an hour and you can fix this problem and take data from one format and put it into any other format as long as you know what you're doing. It's one of those things that just never made sense to me that we spent years arguing about a format when that was irrelevant. Um, in the 20X phase 1 pilot, we had one participant over the weekend create sub routines that would import every other 25 plus other participants packages into their format. Every single one was a different format. Like this is not that hard. This is not rocket science. You should not be worried about those kinds of things in 2026. Um, but the cool thing is that now you don't even need engineers to do that for you. You can do that yourself quite easily. Uh, so as we publish the consolidated rules for 2026, we're not publishing spreadsheets and things like that anymore. We have a big massive JSON file that has all of the information in it. And we expect people to process that information file um and and generate whatever they need for their own bespoke things. That said, we realize that this is such a consistent concern from agencies because so many of you don't have the engineering background and you don't have access today as we talked about to the tools that you need to do this effectively. Uh so we have put into the consolidated rules basic schemas for every single machine readable deliverable that will set a very highlevel way of allowing you to punch in. We still give uh agency or we still give cloud service providers freedom to make that their own and do that in different ways and add additional information and enrich that. And we want them to we want them to compete based on the quality and structure and content of the information that they provide to us and how they provide it. But we're going to give them that little tiny bit of structure so that we can adopt that quicker in the short term as we still get access to more tools that will let us not worry about that. And that's why we focused on putting the AI providers through Fed Ramp as a priority to try to get these uh this technology out as easily as possible. >> Yeah, 100%. If you like the first thing you need to be doing with these is like get yourself access to one of these AI services with a proper agentic pipeline and then start talking to your data. And I know this is like a cliche thing to say at this point, but like you can learn a lot more by doing that. One of the things that people frequently asked me was what changed between this document and this document. Can you tell me what that was? Uh I generate all of that with an agent. Now every change log tells you exactly what changed between every update of the rules. Word, you know, as needed like down to the word and it just does that in like three minutes in the background as I go about and do other things rather than me maintaining this massive document as I go through stuff. Okay, we have a hot topic for you. It is very challenging to hire top cyber security talent into the government today. What can OM do to help solve this? There are you we have so many different programs in the government to attract talent. What we have a real problem with is how to disambiguate those to the private public, right? Um, it's frustrating that often times if you want to work at an agency, the fastest way to get to the agency isn't to apply to the agency is to go to USDS or something, right? So, we have innovation fellows, we have USDS, we have, you know, you could come here and work at TTS, you can apply directly to an agency, you have the tech force, you have the cyber force that's coming. Um, I actually had a long chat yesterday with OPM about how do we tell the public what are the fastest ways to come into the government. I think there is no shortage of new and expanding interesting ways. What we have a real problem with is marketing that to the public so people understand the pathways that they have. OM I'm sorry, OPM is announcing something where they're looking at new hires. And I was talking to the staff last night and they're going to be going to college job fairs and recruiting for the government. I don't know if that's ever happened before. And they're understanding, you know, recruiting at Berkeley looks very different than recruiting at Texas A&M and how do we change the messaging to attract the right type of uh civil servant. So, I promise you that um Scott Cooper at OPM, this is all he thinks about is how to get new talent in in the government and we're deploying everything we can from a personnel perspective and a budget perspective to do that. And when you have direct hire authority, force your HR department to let you direct hire people and rise that up the chain of the command. Talk to your um OM OCIO desk officer if we could be supportive in that regard. But it exists and people need to utilize it and people are talking around it for whatever reason. And it's not harder, it's easier. So it's kind of demanding that you utilize these opportunities that exist. I'll just add if you're part of a larger department, you should be using hiring certificates and not trying to hire one cyber person into one position in one bureau. You should be at the top level creating a stack of folks. You could talk to DHS and SISA who has a lot of experience doing that and are ramping that program back up again right now as well. I'll add from a practitioner level, hiring quality security staff is like Fedra app's priority right now. It's something that we're struggling with for the same reasons as everybody else. Um, but like that that is something that every agency should be concentrating on. Put in the effort. You should have support at the top level to do this because like we need folks with a different lens. And I'm really looking forward to the Tech Force Cyber uh Cert to come through because we hired some software folks and some product folks off of the other twos. And there was there were some really talented people in there with a lot of good experience that were really really easy to bring on board. >> Yeah. And talk to people in your personal lives like let them know what's exciting about working for the government. Let them know why you chose to serve. Everybody has their day job that they have to focus on, but everybody should think of themselves as a recruiter on the side. like we're one team and the more people we have here who are passionate the more it moves the whole enterprise together. So like that part is super super important also. >> Okay, related question. How can we empower cyber security talent within an agency to impact or influence agency policy? Yeah, same with my position in the White House. Like policy should be coming from the bottom and understanding what are the blockers that need to be changed and that's what should be filtering up to informing policy at the top level. So I would encourage every practitioner to make sure like you have a responsibility to the taxpayer to tell your supervisors what you need to do your job better and more efficiently. I think it's important also, you know, as a mid-level program manager that has a little bit of experience, uh, sometimes you have to represent yourself, the leadership, and, you know, stand up in a room and say, uh, boss, that's a bad idea. Or, you know, hey, I'd love to do that, but like to do that, we got to do X, Y, and Z. Here are some other ideas, or can we have some time to look into this and come up with some other suggestions? like your bosses shouldn't always be setting direction on things like policies. You should carve out the space to do that. If you want to do that, um my biggest recommendation is if you want to start messing with policies and how agencies are doing things, befriend your office of general counsel and establish a really strong relationship with some lawyers there and talk to them a lot. And once you get the reputation as the person that talks to the lawyers and has those communications and that contact, people rely on you a little bit more. That's a little cheat code. Okay, we have one more. Um, it's it's a little lengthy. uh given that agencies are still required to comply with FISMA and NS SP853 and their use of Fed RAMP authorized services. It seems the responsibility for compliance and risk management remains with individual agencies. This can slow down the ATO process especially since agencies must still apply and tailor overlays to meet their specific requirements. The issue we are facing is limited resources. Leveraging bed ramp systems now appears to require more work than before. What steps uh is Fed Ramp taking to assist agencies and make this process more efficient? >> If it requires more work now than before, then you weren't doing your job before. Very bluntly that is the reality. As you can read the inspector council of inspector general's report, GIO reports, FedRAMP has never been responsible for your agency risk posture. Uh if you were as an agency were just handwaving away all of the necessary requirements for the implementation of a secure use of a cloud service by seeing something in the Fenerat marketplace, you're putting yourself at risk and in danger. I just want to make that really clear. Nothing has changed about agency responsibilities. You have always had exactly the same responsibilities that you have today. What Feder is trying to change is the exact opposite of uh that question. We're trying to make it easier for you to meet your responsibilities by making the information available to you in a more consumable, more efficient, more effective way so that you can actually sit down with the package. I think in a year from now we should have situations where I mean and we can do this today with some of these packages. Um but we should have sisos the literal chief information security officer sit down with a 20x package in an afternoon and make a decision. It should not be a six-month bunch of contractors looking through a thousandpage document. So that's what we're trying to do. It's the same thing for ongoing. you will have exactly the information that you need to run your risk management processes. Uh quarterly meetings, routinely recurring information on vulnerabilities, uh matching up with CISABOT 2604, etc. Uh so I just fundamentally disagree with the idea that Fed Ramp is increasing the workload for agencies. We are making your statutory workload less without changing. We're we're making the things that you have to do to meet your statutory requirements less. But your statutory requirements are what they are. Don't get hit by the IG for ignoring your requirements. And FSMA gives the authority to interpret agency risk tolerance to the agency head. And it's the responsibility of cyber security professionals to have a conversation with the agency head. It is not the intent of FISMA to force everybody to by the letter follow blindly everything in 853. I don't know how often people are having conversations with the agency heads, especially as new political appointees come in and say, you know, we understand this is the mission of the agency. I need to have a conversation about what is your risk assess acceptance and what is your risk tolerance and here's some trade-offs that would help us move a lot faster. I'm guessing we've also like we've seen a really large uptick in political CIOS and all of those agencies are moving at a speed and pace that is entirely different than the others. >> Yeah. And that's a great thing about uh what this administration did with all the political CIOS because politicals just have a different risk tolerance than career civil servants. So for those of you who have political CIOS like take advantage of the time. >> Good morning. Mark Hugh with Department of Labor. Previously, um, when we were approving a a package, we'd lock ourselves in a reading room for an hour or afternoon in GSA. We'd close our books, we'd bring everything back, we'd have a monthly conmon meeting with the the CSP. So, we don't necessarily have access to as much consistent data as we'd like. Is the expectation that the CSPs are now going to be more of an open book. We have more access to data that maybe they'd be reluctant to share previously. Yeah, I think what you're talking about there is an a kind of underlying issue that we used to have with uh the joint authorization board and uh sponsoring agencies and this is something that was deeply frustrating and so I acknowledge the previous question um was asking about you know the implication that things have changed and it's because historically like the jab would not let you look at this information like DA would not let you look at their you couldn't pull the poems you couldn't pull any of this um that was is effectively holding hostage your ability to meet your statutory requirements. That is not the case anymore across the board. You if you are using a cloud service, you have the exact same access to all information about that cloud service as any other agency. Um we've had to pick some fights. We thanks to this group uh letting us know the agency leaison groups letting us know that Amazon web services of all people was telling people that they couldn't see the command data because DA wouldn't let them. Um and we all picked a fight with them and they very quickly well in the in government terms over the course of two months they changed their tune and now they're making that information available to everyone um because we're going to take away their FedRAMP certification for it and we told them we made it clear if you don't do this you cannot have this anymore. or you were going to have problems. So yes, the expectation is increased transparency and data sharing with all customers in a way that you have real meaningful access to information. You're included on incident reports uh and that you ha you like you shouldn't be in the dark. That was terrible that that happened. >> Yeah, that's good subtext there too. The more we have reuse and adoption of 20x, the more leverage we get over the CSPs also. Any more questions in the room? I have a question. Um, I get to ask said you could ask a question. >> I get to ask Pete a lot of questions. So, this one's for you, Greg. Um, Bedum's doing a lot with the agency liaison community, practitioners. Um we hold monthly liaison meetings, agency support groups, and we're really um working directly with those at agencies who are doing authorizations. I know in your role you get to meet a lot with CIOS, SISOs, you have a couple councils. what kind of um sentiment has been thrown your way on 20X and um kind of behind the rooms things that you could share with people today from the SISO and CIO's perspectives on 20X. >> I think largely it's been cautious optimism and I think a lot of the hesitance has been around not being comfortable with the permanence and the fact that you know Rev 5 is indeed going away and you need to get on the train. Um so certainly the strategic perspective everybody likes but again we're such creatures of habit as civil servants. So there's just a little uh suspicion about you know do will this expose some sort of flaw in my team? Um like do we not have at our current levels the competence to be able to adopt a completely new way? That's why your role as liaison is so important. Everybody at your agencies are looking to you to help them understand how to interpret these things. But, you know, by and large, it's been very very positive. >> Okay. Uh, when you type in last call for questions, you get three questions. So, I'll start with the first one. Uh, this is for you, Greg. What do you attribute uh to the massive massive success of Fed Ramp? the fact that it is finally something the government has adapted to make sense in the present times and we are not forever beholdened to like I mentioned the paperwork reduction act to something that is just written down and then we have to abide by it forever and it's just such a great example of the government adapting to the world of you know cloud compute that has completely changed everything >> great thank you 20x offerings have been reused by other agencies. >> A few. But here's the thing. Every single agency is required by law to tell us when they use a Feder certification in order to uh deploy a cloud service. Uh and most of you have lost track of that. >> Criminals. >> Yeah, you're all going to go jail. Um yeah, it's actually deeply frustrating. I know of multiple agencies that are using these and I have to find out from the vendors and we reach out to them and we're like why haven't you given us the paperwork and they're like oh yeah like we'll send it over we'll get to it and like that's why there's I think no reuses shown publicly on the marketplace and I don't know what is going on with that but we are having a very hard time the amount of letters and information that we're getting has dropped way down uh so as part of the consolidated rules for 2026 we're creating new forms that should hopefully make that process easier and open it up to more people. Um, but the reminder there for all of you and your agencies is that you're supposed to be sending us atto letters uh when you use cloud services and you're supposed to be sending us at letters when you resend the use of cloud services too. And it's really frustrating sometimes uh when we find out that like an agency stopped using a cloud service 7 years ago, but we still think that they're using it. >> Yeah. Please, please, please submit those. >> Okay. Our ISOs have reported not getting consistent monthly conmon reports. The advice I was given from Fed ramp was to reach out to the cloud service provider. It's not really written as a question, but it is a question. Is that accurate? >> Um, there's a lot of different components here that interact that can get kind of confusing and I understand that. Uh so when you so fed is not an enforcement body. There's one thing that I can do to a cloud service provider. I can take away their feder certification. That's it. I can tell them I'm going to take away their federal certification and then I can take it away. Um I have no contract with them. I have no they have no legal obligation to pay attention to me. I'm not a regulator. There's nothing. um if their agency that holds a contract with them is not enforcing that contract which says that they have to meet Feder requirements then the class service fires blow us all off and I can yank their certification and you all will keep using it and you'll yell at me about like why they're not doing conmon but it is 100% the contract owner's responsibility if a business that your agency has a contract with is not upholding the agreement that it is a legal issue that should go through your procurement contracts and agreements team and should not come to Federam. If we get reports from a lot of a of uh agencies that cause service providers are doing that we will 100% reach out threaten to revoke their certification etc. But you have all of the actual power in there because you're using it and have an agreement with them. I think that's always been one of the slightly confusing things sometimes is that the compliance teams, the security teams at agencies, you know, us, we're your partner, we give you access, we talk to you, we respond to your emails, you know, we give you help. Uh so your your natural tendency is to reach out to us. Um, but it is vitally important that security teams have direct connections across your agency with your procurement folks, with your agreement folks, with your lawyers so that you can leverage those contacts correctly and properly. And a lot of that is like FedP is not going to be the big 500 pound gorilla that you want it to be because we don't have that contract. Use your contract team and make sure your contracts tell people they have to maintain federal certification of all the rules. What is Fed Ramp doing to ensure the cloud service providers abide by the binding operational directive or bods issued by DHS or SISA. So in general, binding operational directives and emergency directives from SISA apply to federal agencies and federal agency information systems. Legally, those do not apply to a system that is not operated by the federal government. And no, if you're using M365 commercial, that is not operated for the government, even though you're a customer on it. that business is not bound by that. What we do though is we provide the connective tissue that requires that business to report the status of their compliance with those in a way that can help agencies get the information they need to know if you need to uh change your risk profile on that service. In some cases that means that we say you will lose your Feder certification. my big my only big threat, right? In some cases, you'll lose your fed certification if you don't do these things. If you don't follow these Fedramp rules in order to ensure agencies um can feel like their information is protected. It's good to think of FedRamp as an assurance program. Our purpose is to make sure that you as an agency are confident and feel assured that your information is safe based on the information that that cloud service provides you. Uh so with 2604 which is the most recent bod we're going to be talking about a lot today. Super super important. Um, we have predictably upset every single cloud service provider and they are all trying to gear up and go to war with Fed Ramp right now because we told them that because of BAD 2604, we would revoke their Fedramp certification if they did not comply with the vulnerability detection and response and the vulnerability evaluation and reporting rules that meet the requirements in that BOD uh by March. and they would be put on corrective action if they didn't meet it by the same deadline that SISA gave of December 6th. And that's been really particularly fun uh because all of you as agencies, right, you're all bound by that. You have to deal with it. I had a bunch of cloud service providers basically say our agencies will never support us moving to this new method of doing vulnerabilities. Like they won't support it. And I'm like they have to. The reason I'm telling you you have to do it is because SISA told them they have to do it too. Uh so we're moving together with SISA um and like with all of you to help make that easy. Uh and my team meets with SISA all the time. SISA is on our board. SIS is here today to talk about this stuff. Um we're here to help you out and make sure the cloud service providers give you the information that we need. >> Thanks Susie. Thank you. >> Cool. Um so we are wrapping up here. Um we're going to go to a 10-minute break. Um, I want to thank Greg for being here today. I I will say something. I've been here 14 years and Greg really appreciate your transparency and accessibility because we have not sat down with a federal CIO and the Fed ramp director like this. This is really cool to see. So, thank you a lot for being here. And we'll uh be back in 15 minutes and you'll hear more from Pete and then we'll have Nicole as well as a guest from SISA uh Jay Gazzley here today. Thank you all. Cheers everyone. Hey. Hey everyone. I'm Pete. I'm the Fed director. I also am currently acting as the TTS deputy director, which means I'm Fed Ramp the Fed Ramp director's boss and a bunch of other people's boss. It's pretty busy. You know, Greg was talking about he's a federal CIO and then he's also over here at TTS. Like there's a lot of stuff going on. Um, and one of those things that we've been working really hard on here at FedRAMP, uh, that has taken us a little bit longer than we hoped is the consolidated rules for 2026. We're going to talk a bit about that today and kind of acknowledge the world that we're operating in, the life of everything, and just how difficult this is for all of us. A year ago, was it May? I think we hosted with OM at the time the very first inter agency meeting of the new administration. And I remember very well in that meeting the dichotomy of announcing that we would be modernizing Fed Ramp in alignment with uh M2415. Although we didn't talk about it too much at the time because we weren't sure what was going to happen to M2415. Um but the dichotomy of talking about that modernization and sort of the horror of many of you uh if you were there at sort of but like are you saying Fedramp isn't going to do everything for us and that we're supposed to do things for ourselves and it was a really awkward and kind of tough time I think for all of us not the least of which as we discussed earlier today you've agencies have always had the statutory respons responsibility for managing their own risk. Like that's not a bed ramp thing. That's a chapter 35 of title 44 of the US code thing that says you are responsible for that. And our job has always been to help you. And for me that was actually really interesting. I had been the federal director for about six months at that time, seven months. And I had not realized that the OM during the development of M2415 had been going out to agencies and telling them that FedRAP would do everything for you and that you didn't have to worry about it. Uh, and I wish they had backed that up with some actual authority, responsibility, and funding, but they did not. So, as discussed, the main point that we're looking for that we're looking to talk about today is kind of helping you all take a breath, understanding what's changing, understanding how that's going to affect you over the next few years, what we can do with our very limited resources. um that is both within our responsibility and authority and sometimes just bonuses that we're going to provide because we really care about this to help you transition through this period of time. Throughout all of this, I want to be really clear. In fact, I wanted to be more clear because we invited both GAO and the Council of Inspector Generals to come talk to you today. uh but both of them had conflicts and weren't able to make it. We're expecting them to come by on the next one to talk to you about all of the continuous audits they do where agencies tell them that they don't look at things or do things with their cloud services because they don't have to because FedMP does it for them and every single one of those agencies gets a corrective action plan that they have to deal with. Um we want to make sure that you have the support to do that well and to do that right following the process. So, how many people here remember M22029? I feel like this is a lie. I sure hope that you all do. Uh, but you're just too lazy to raise your hands, which is fine. Um, I think a lot about M2209 as a really interesting example of what happens when OM says everybody has to do things differently and you have to do it within like a year and then 3 years later most agencies are still like can I has funding to do this because I don't have the money to do it. Another example, one of my favorite examples actually is Homeland Security Presidential Directive 12 from like 2002 that uh directed the federal government to all use PIV cards basically and that PIV card should also protect not just facilities but information systems and you have to log in with the PIV and uh every couple of years OM will put out a new memo that's like guys we really really need to make all of our things like use PIFF to log in and then a few years later they'd be like no no no really you guys got to do it and I think there were like five or six OM memos between 2002 and 2022 that said you had to do PIV and it still wasn't done. Why am I talking about this? Because many of you will never update your policies. Many of you will never be able to be responsive to the changes in Fed Ramp. Many of you will take years to do so. And I'm not going to judge you for it. It is what it is. What we're going to focus on is working with the people that are responsive, that are able to move forward quickly, and we're going to pull by sort of force of gravity the rest of you with us. We started doing that with cloud service providers in industry. We found the early adopters that really wanted to do things differently and we got them on board. Now we have hypers scale providers that are telling me that they are making presentations to their board about the future of security and it is fed 20x. So if you think for a moment that this is a fad, it is not. We are all going to change the way that we are doing things. And I think baud 2604 is one of my favorite examples for Fedramp over a year ago started directing cloud service providers with cooperation from SISA based on a lot of expert advice from some wonderful folks at CISA uh to go about the way they did vulnerability vulnerability detection and response differently. We heard negative feedback from agencies on that. agency said, "No, I want my monthly continuous monitoring scans. If there's a CVE9, I need it fixed within 30 days." Like, what are you talking about? You can mitigate this by not having What are you talking about? This is crazy. You think they're going to fix this uh internet reachable, automatable, exploitable vulnerability in 3 days? You can't make people do that. That's insane. Um, and two weeks ago, CISA said, "No." Yeah. What they did, you guys, what they did is right. Um, and I think you're going to see that a lot more with Federam 20X. So, as we talk about the consolidated rules today, I want you to always have that in your mind that we're still, even though we're two years into this, we're still at the very, very beginning of a massive paradigm shift about how we approach assurance. And right now, Bed Ramp is focused very much on the cloud service provider aspect of that. these external private companies that you work with and how they report information to you. But throughout the rest of the government, there are many people that are working very diligently on how you as an agency should manage and operate your own information systems. And the more that you work with us, the more you will be ready as the slower government side stuff changes because it's going to be a lot of the same things because we're all following the same playbook. Okay. So, consolidated rules for 2026. What is that, Pete? You said it like 18 times. We have been changing a lot. I think you're all used to that, right? Uh, at this point, Feder has put out over 30 RFC's. We are putting out new rules all of the time. I think we just hit 17 15 notices. Uh, we're doing a lot of stuff very fast and that makes it hard for agencies to keep up. 100% understood. Right now, we have reached kind of what you might consider to be the first largest checkpoint. We have decided and finalized this is how these things will primarily work for at least the next couple of years. This is the point at which it is time to start looking at these rules and requirements and start updating your policies. Things like the jab has been gone for two years but like it is officially non-existent in any way, shape or form. uh agency sponsor for ongoing authorization no longer is a thing. Cloud service providers have a limited window and you as an agency have a limited window to continue this relationship of like I'm your special buddy. You can only work with us. Like that is unacceptable and is not allowed. People will lose their Federam certification and you'll get yelled at if you try to do that. On top of that, we're changing the way that Rev Five works. And you heard Greg, the federal CIO at OM talking about how important it is that Fed app move away from Rev 5. And that all of you as agencies figure out how to approach external commercial system use different from you build it, you run it, federal information systems. This is going to be a big shift, but that's the message and the message is really clear. Those are two different processes that need to operate under two different mechanisms. They can end in the same way. But the process of bringing that in and building that agency information system to use a cloud service can no longer be treated like I'm going to go by Google Workspace and implement it. It needs to be about following the risk management framework. What are you trying to do? what do you need to protect, what is your actual use case, where is it going, what controls do you need in place, etc. Then you select the cloud service fighter based on that. We're going to be talking about that a lot over the next few months, making this concept really simple. If it's in your system security plan, it should be because you have actual authority and responsibility for it. You should never write in your system security plan, this is what the cloud service provider told me they do for training. Right? If AT1 you don't write that for AT1 you write I'm going to review the metrics provided by the cloud service provider to ensure that they are doing their training and if they are not we will take a POA to determine whether or not we want to continue to operate this system or if you want to go after them for a contract breach or something else. But you do not copy and paste their stuff into your system security plan. You decide what's important for you to do and put that in your system security plan. That's the way it should have always worked. But uh as as I heard just a few minutes ago, Veterans spent a long time telling you, "No, just copy and paste a CIS CRM and you'll be good." Uh don't do that. That's terrible. I'm sorry that anyone ever told you to do that. So the consolidated rules for 2026 require a lot of changes for existing cloud service providers. You can see those today at preview.fed.gov/2026 and you can see them tomorrow at fedraamp.gov/2026 because we'll be moving out of preview. If you look through those, we have almost 250 rules that cloud service providers have to address to maintain Feder certification in different ways. They don't all apply to everyone, but that's a lot of rules. It's going to be a bit of a pain in the butt. We strongly recommend that you look through those. There's a complete rule set reference. There's also a bunch of narrative information in the background. Um, but I think it's really important to look through the rules. Here's the number one thing that I'm going to tell you. We've done everything we can to eliminate the entire concept of ghost rules and ghost requirements. If a cloud service provider is expected to do something, it is written down. It is clear and it uses plain language. Our plain language is intentional. Our flexibility is intentional. We do not say you must do this every two hours most of the time. We say you must do this on a persistent basis. And then there's the feder definition for persistent which says it's a recurring cycle that you always know the status of and you have documented the intent of that cycle. So someone might choose to do something every 17 years. you might think that's crazy and not want to use their cloud service if for example they say I'm going to do uh um we don't allow them to do annual assessments but like we're going to audit our personnel every 17 years to see if they're who they say they are. Benab will allow that because there are some situations where an agency might want to use a service and not care about that. low impact, not important. Maybe you deliberately want to take advantage of that lack of security. Maybe it's cheaper. That's okay. But you have to look at that. So that becomes part of your approach to systems. It's like what capabilities do you care about, right? It's like I really really care that they have good incident response, they have good vulnerability management, and that they use encryption effectively. You will have real data about those things at Rev Five. What is your incident response policy? Please attach this document to this document. What is the point of that? That's like one of the most useless things in the world. I don't even want to You shouldn't even want to see their incident response policy because it's like made up. Better 20X takes the game in a totally different direction. says, "Show me the last year of metrics about your incident response. What's actually your MTR like what did you actually do with those incidents? How many of them did you actually have documented afteraction reports? What were the results of those afteraction reports? Did they lead to a feature improvement that increased the security of your cloud service offering? What does the data look like on that? Let me see that chart. Let me punch in and get that information." You will have the ability to do that. that can quickly get overwhelming across every single capability, but it's going to be exciting and it's going to be more security for everyone. So, as we go through this, things are going to change. the way that you're going to do things is going to change. But we want you to really think of your role and the role of your teams and your co-workers as transitioning away in many cases from looking at a thing over here and then looking at a thing over there and making sure that they're the same to actually making informed securitybased analyses for what you want to happen, what you need to happen, and what you expect based on the unique environments of those cloud services. and it's going to give you access to so much more cloud services, so much more capabilities and different use cases. I'm pretty excited about the consolidated rules for 2026. Um, let's talk about a few things that are key things for everyone to understand are changing. First of all, over the course of the next year, we will be retiring new Rev 5 certifications. June 11, 2027 is an explicit target for the last day that we will do a Feder Rev 5 certification. That means if you're sponsoring, as we talked about earlier, you're sponsoring someone, you should finish that and you should get them across the line before that date. If you're in talks with someone right now about what they should do, you should tell them to go FedEmp20x, bring it to the program. Let us get you a better security package. Class D, hi. Same thing. If you're in the process, go ahead and do class D. Sponsor that. Get that done. But by the end of this year, we'll be really close to finished, if not finished, with our class D20X pilot that we intend to collaborate with some of the biggest companies in the world. Many of whom have been reaching out on the download to let us know that they want to do it, but they're like a little bit afraid and they're like, "We don't know how agencies will react." A few folks are like, "Uh, Department of War, we don't know what to do, but like we're focused on the commercial stuff. It's going to happen. So, if you think about how long it will take you as an agency to sponsor someone through class D, let's say if you started in October, it's more likely you're better off just telling them to wait for the 20X class D to get finalized out there in January, February, and then they can implement that process. Or better yet, tell them to participate in the pilot and you can get it early. So, in general, I just want to be really clear on this. This is not my decision. As you saw earlier today, this is the direction that has been given to us is that we need to stop doing Rev 5 and we need to make sure that better, more modern security packages are available as quickly as possible. And the flip side of that is that Fed Ramp has to do that first review for you. That should make your life a lot easier. Um, it's not going to make my life, our team's life a lot easier. Um, but as part of that, we're going to be engaged with continuous monitoring and with the ongoing certification of those services. So, you'll have us there as a backs stop in a way that you don't always have right now. And I'm very excited about that. Other things that are changing with Rev 5 is that collaborative continuous monitoring is shifting. We're requiring people to hold quarterly meetings with you instead of monthly meetings. Believe it or not, uh this is one of the most requested changes to the process mostly because most of you including Dissa and the Department of War hate sitting through monthly meetings talking about a spreadsheet that you can just look at without uh that meeting. So that's going to be quarterly meetings and those are intended to be clear, detailed, valuable security information to come towards you. They will be providing you with asynchronous security information on a regular basis at least monthly and in many cases more often than that. You get to choose at your own agency based on your own access to tools and capabilities whether you engage with that information more frequently or less frequently. If a cloud service provider is making their vulnerability detection and response data available on a day-to-day basis, that could get overwhelming to you if you don't have the capabilities to process that at scale. You don't have to engage with it daily. You can look at it once a month if that's still your thing. Another big change about those continuous collaborative continuous monitoring is that we're expecting them to uh take questions and things like that in advance for you as well as to make summaries and information packets about the meeting available before and after. This is one of those areas where we've kind of been like, what do you think would be cool? And we've seen everything from a crappy spreadsheet that's like here's the eight things we're going to talk about to like beautiful PDF files with inspiring backgrounds, quotes, and strategies and graphs in them. Um, we've left that open on purpose and are excited to see you get to tell people, hey, we'd like to hear more about this. We'd like to hear more about this. like tell us more about this at next quarter and see what they come up with instead of having it be a po reading. On the subject of poams with the vulnerability detection and response as well as the vulnerability evaluation and reporting requirements, everything that you're familiar with about continuous monitoring changes, the vulnerability detection and response and the VDR or the fader and the VER, they align with Ba 2604. They tell cloud service providers that they must be continuously on a frequent basis looking for vulnerabilities. They also make it clear that vulnerabilities are what the law considers to be vulnerabilities. A CVE is one of 80,000 different types of vulnerabilities and it is the one of the least important. A control gap. We're not meeting the Fed ramp rules. We're we have a flood in our basement. All of these types of things are vulnerabilities. I don't train my users. I don't have MFA enabled. These are vulnerabilities even though they will never show up on a Nessa scan. We want to be very clear that these are expected to be treated as vulnerabilities. And the same process needs to go through. If I'm not doing this Nessa scan, does that mean I it's likely that I will have a vulnerability that would mean it's likely I could get compromised? If so, you should fix that very, very fast. 30 days is nonsense. Very, very, very fast. You, as a cloud service provider, don't have to worry about anything other than consuming this information and getting the tips that they will give you about how this might affect you. This is one of my favorite things that we've added in the VER is that they have to tell you what the potential risk to your data is of a vulnerability. So, for example, if they're like, uh, there's a vulnerability that, uh, all of this data could be extracted. So, you get to then decide, should we stop putting new data into that cloud service until that's fixed? Because like we can assume that all of our current data might have been exposed, but we should take a POM for ourselves because we're responsible for it as an agency to shut off access to that system and stop putting new data into it until it's fixed so that our new data won't get extracted. That's an example of how this should work instead of you sitting back asking them for updates and them saying, "Oh, no. I'm going to take a deviation request because I'm waiting for Cisco to update this firewall and we're just gating our information out through this. Right? So, you're going to have to change that approach. You're going to have to be more involved, but they have to give you more information about how it can potentially affect you. It's no longer just a thing on a spreadsheet. It's like what action might you need to take to protect your data. I'm super excited about that. We're also changing the entire system security plan and the Feder package. There is no system security plan in a Rev 5 certification anymore. A year from now, maybe a year and a half from now, everyone will have been moved away from having a SP853based system security plan. Instead, what we want is a security decision record. We don't care what they tell us they're going to do. We want to know what they have done. The thing that is different about a cloud service in most situations is that they're an operating company that performs a thing. So, it's really important that they be telling us what they actually do. On top of that, rather than just a control implementation statement, we're requiring verification and validation. What do they do to verify that the thing that they think they're doing is actually happening and then validate? What do they do to make sure that that thing that they want to do is actually providing the outcome that they want to have. Right now, you don't have that information in um your system security plan. On top of that, there's going to be no SAPs, no security assessment plan, no security assessment report. Rather, the role of the independent assessor is to doublech checkck that verification and validation. Does it actually work? Are they actually doing the thing that they think they're doing? And is it actually having the outcome that they think it has? That should be done based on testing, realworld proof, not screenshots. So if there's a rule they say I have my firewall set to block all traffic. I use this program to monitor monitor and set that setting and I have tested it externally to make sure that I can't get through this firewall. I don't care what the screenshots of any of that says. I want to know that the assessor ran a external scan and tried to get through that firewall. That's what's important, not what the configuration is. So they need to verify it's actually blocking traffic and it's actually having the effect they want. So the assessments are going to change. What you look at is going to be a little bit different. One of the hardest things for most of us to kind of come to grips with is that for a long time we have created an imaginary world where the assessor is the person the third party assessment organization is the person providing assurance. They're the ones that are keeping the cloud service provider from doing bad things. That is nonsense. That is wrong. That is not how any of this works. The cloud service provider is solely and wholly responsible for not submitting false claims to the government. They work with the assessor to provide an independent view that helps them verify that they're doing it right and helps us feel a little bit more confident that they're doing it right and saves us from going in and having those conversations. But it will always be only the cloud service provider that is responsible. And we want to make that very clear by taking away the role of the assessor as the person that decides if it's good enough or not. That will no longer be the case for program certifications. The assessor simply provides information to us that we can use as a little bit more insight. If you haven't followed, there's been multiple multiple false claims prosecutions for companies that have lied to the government and that will continue to be a thing and we should all stop pretending that like it's our personal job to do that or it's an assessor's job. The only person that is responsible for not lying to the government is the person that is telling the government they are doing a thing. Like let's be very clear about that. Um there are a few other changes. We're going to have a certification package overview. That's basically what the system security plan is now. Uh but it's more tuned in. It's more aligned. It's designed for you to just take a quick look and go, "Okay, I know some stuff about this." In the minimum assessment scope, we have removed the requirement for the authorization boundary diagram. This is one of the stupidest things that any of us have ever done is ask a company to draw and maintain a diagram that contains every single system, service, protocol, port, data flow. No sense. Completely logical. uh that data is ephemeral. It changes frequently. What is important is that we know they have systems in place to understand what the boundary is and that they have the ability to report on that based on source of truth data at any given time and it should change for most cloud service providers today. It'll change every day. The systems in their authorization boundary will change. We want to see some cool highle diagrams. They're helpful. Um but that's an option, right? like something that makes sense, gives us an awareness of the system, but we shouldn't ever be looking at a diagram to figure out what host talks to what host and things like that. The amount of time and effort that we've all spent on authorization boundary diagrams is way too high. Um, those are the big changes that will be coming over the next year and a half. They're all staggered. There's a few that have hard deadlines. on this date, this must change. Um, there are a vast majority of these rules that are based on the next assessment after January 1st, 2027. So, if you have an assessment in August, that cloud service fire will have more time than if they have an annual assessment in March. So, you'll start to see over the next year and a half things change. That'll be frustrating, right? You'd be like, Pete, I got like some of them are like this, some of them are like that. this is complicated and it sucks and I kind of agree u but we can't really do this on like okay three years from now we're all going to agree to jump at the same time right I we have to like push people off is a terrible analogy like one at a time get them through until everyone is safe on the new thing um so bear with me remember back to M2209 remember back to HSPD12 it's going to take us years but it's going to look really different in a couple of Ryan's like, "Pete, you've been talking for too long. It's time for you to ask and do Q&A." >> So, um, we have about 10 minutes uh for Q&A here. However, after the session with Sisa and Nicole, we can also pull you back up if there's additional questions about CR26. Okay, let me do uh a couple quick hits on things really fast for Q&A. Uh first of all, we are looking we're working with the Federant board right now to change the rules for agency provided cloud service offerings. Um so that's things like USDA connect, [clears throat] login.gov, etc. Um because those cloud service offerings run a government process already, we don't think it's fair to make them run a separate federant process designed for commercial companies. So most likely that whole process will be simplified and changed for agency provided services. Uh second of all, staffing. We're in the process of trying to hire. We have not had a lot of luck with a high level of applicants. I have 15 open positions on the Feder team uh in order to get to around 40 people. I'm hoping that that's going to happen. Uh and as we get those people hired and onboarded, we'll be able to do more training, etc. Um, but I felt it when the person asked about hiring because it is hard. Finally, uh, technical advisory group. Something I just want to put out here now while I got people here together. We're going to be talking about this over the next couple of months. Um, I want to put together a different kind of technical advisory group than we had in the past. I want to put together a technical advisory group that is composed of people that on their day-today job are doing Fed ramp stuff at agencies in order to help us produce white papers, guidance, playbooks, etc. about how to do Fed Ramp stuff. Uh so keeping an ear out, that sounds like something you might be interested in contributing to and helping other agencies because you're kind of at the forefront pulling this stuff up. We need people that actually doing this on a day-to-day basis to be a part of that group and we'll be spinning that up soon. Okay, back to you Ryan. >> Oh yeah. Um, directly under the light. [laughter] Sorry about that. Um, I just want to get your take on uh the poems that you mentioned earlier and see if you can double tap that for me. uh because you mentioned that if a CSP has a vulnerability like I think you use a basement flooding example as an agency you have to open a poor to protect uh your asset now aren't you at their mercy whenever that basement flood is fixed that's when you close your poor >> no okay >> don't don't be at their mercy never be at our mercy. Um, so poems historically are weird because we basically took this process that was designed literally for you to use as an excuse to ask OM for money. Poems was like, "Hey, I got this system. It's insecure. I'm going to need money over the next couple years to fix it." Uh, so you created a plan of action and milestone. Fun fact, if you had an insecure poem in the year 2000 when this memo first came out, there was a special computer at OM where you could come and bring a floppy disc and look at it if you didn't want to mail them your list of poems. So, um, cloud service providers should not be doing poems. A poem is a plan of action and milestones. So what cloud service providers do is they're going to tell you how they're going to fix things or if they're going to fix things or not. In the case of what is most pams will become automatically an accepted weakness if they're not going to fix it in the mandatory time. Then you as a as an customer need to look at that and understand what is the impact of this cloud service provider accepting that weakness. Does that matter to me? Is this a thing I'm going to yell at them every month for the next two years and I'm not gonna do anything different? Then that doesn't matter. Why are you yelling at them every month? It's a waste of time. Stop pretending. On the other hand, does it really matter? Are they like, "Hey, we're going to make all of your data public." You probably want to do something about that. So that's where you create a poem according to your agency policies based on the actions and milestones that you would set for yourself to respond to that situation. And that could be we're going to yell at our contract people and have our contract people fight them. We're going to go to our lawyers. We're going to threaten them in court. We're going to sue them. It could be we're going to cut off all access to it. It could be we're going to refuse to expand usage and keep it at initial operating capacity and not head towards full operating capacity. Uh it could be we're going to turn it off entirely. It could be we're going to put a different type of encryption in place on our network. It could be user training. We're going to train everyone not to click the big red button that deletes all of the data. There are so many things that you can do. It is really really important that you as an agency make that determination and do those things and not just sit there every month asking them what the status of their security weakness is. Does that make sense? So one of your comments there is about the the AC control. Do we want to accept that or not? Do we think that's important for us? So if I'm looking at like right now today I look at 853 say great AC it's inherited. It's not my problem. Right? What I'm kind of hearing is I'm going to look at this AC control and say is it my problem? It's not going to be inherited. It's either going to be applied and I'm going to write down I look at their their control review goes into my GRC and it does some magic and I get a green light every day or I'm going to say you know what I don't care and it's not applicable. Is that the correct >> Yeah. I think I'm going to go off on a on a deep analogy here that I had fun with recently uh which is if NIST controls were about your clothing. So if you had the clothing family and you had like CL1 and it was like wear shoes and then you had CL1 one as an enhancement that was like they should be shoes that are appropriate to the type of activity you're going to prepare you know and like all this stuff they CL12 they should have shoelaces or some other form of securing on your feet and then you have CL2 you should wear underwear etc etc etc You should decide as a system what am I going to wear? If I'm going for a run, my control requirements will be sneakers, good shoelaces, moisture wicking socks, comfortable, supportive underwear, probably shorts depending on the temperature, etc. Right? That's your system security plan. That's what you write down. Then you go and look for a cloud service that provides those capabilities. So when you're looking at the key security indicators, what we have instead of CL1, CLO2, CL3 is we have the clothing family, the clothing theme. And we say what what are your clothing? What is your clothing? What does it do? And if you're looking at like a clothing set of capabilities that are designed for firefighters to go into a building, you sure as heck are not going to want to use that cloud service. for your run, right? That's a totally different use case. But you wouldn't know that if you hadn't started by establishing for yourself like these are my expectations of the control. This is what I need to look at. This is what this particular system is about. So there are totally times when you would not care at all about a whole swave of controls and there are times where you would care really really deeply. So we want you to write down what you are doing in those controls and what you're looking for and then assess whether or not something else can meet those controls. >> Now is that catalog and the enforcement after the fact that's part of the procurement process? It's a contracting action. >> I'm sorry, say the first part of that again. >> So the the process of documenting all my CL control that I think are important whereas underwear is not important. That whole process of of being transparent with our CSP and then after the fact saying, "Hey man, we changed our mind. We need underwear." Right. That's all that's all me through our procurement shop or contracting enforcement. Or is there a different vehicle be? >> No, I mean this is this is literally what you're required to do um as an agency by the A130 if you're going to start to do something with federal information. Uh so if you look at the NIS RMF you start by preparing then you start by selecting and then you move from there. And so this is the stage of like as a as an in your agency says we need a system that will help us use AI to more rapidly review uh procurement contracts. Then you come down and you say okay what does that look like for us? Well, it's going to have a limited number of users, so we don't have to do enterprisewide integrations. It's going to store, you know, procurement sensitive data. Um, we're going to want to protect it in these ways. We're going to want to make sure people are trained not to excfiltrate that data. Um, so that should be a standard part of your IT process before it goes to procurement. And what I would really like to see would be you building into that procurement process, you get access to 15 cloud services and you test them all out and see which one's better and you do that really fast. Quick, we're going to do one more question in the room and then if you have additional questions, write them down. We'll have time after Jay and Nicole to follow up with questions to end. We also have uh the agency leazison on group where you can ask questions all the time like over email everyone and people don't use that enough so get get in touch with us if you don't know what that is and let's use that list serve for questions. Go ahead. >> Hi um this is chair leader working with the department of commerce. So you mentioned earlier that you'll be retiring all five certifications. So does that mean all the CSP that have um that like does that mean all the uh does that affect agencies right that were using CSP that have the ref five certification do we have to go through the ATL process again >> so Fed RAM isn't changing what you as an agency need to do to meet your statutory polic and regulatory requirements like the A130, etc. We're changing how you do that when you use a cloud service. So, the requirement for you to have a system security plan and you to go through all that stuff, that's based on chapter 35 of title 44 of the US code, which primarily is commonly known as FISMA, even though there's a lot of other laws and stuff that have been in there since before and since. um that aligns with FIPS 199 FIPS 200. So FIPS 199 says you have to categorize the information that you're going to put in a system. What's the impact level if that information gets popped? FIPS 200 says you have to set a high watermark for that. That's where you create an impact level. That's not an impact level of the cloud service. That's an impact level of the protection that you need for the information you're going to use a cloud service with. Then you follow SV800137 the risk management framework to figure out what controls you need in place, how you're going to protect that information. Then you document that, run your agency stuff. The cloud service is just an external thing that you're leveraging. They follow a different process, but you still have to meet all of your requirements as mandated by all of those things. An example of this is FIPS 140 encryption which requires you as a federal agency to protect sensitive information with FIPS validated cryptographic modules. Not everything that your agency puts into a cloud service is sensitive information and in fact the vast majority of agencies constantly waiver the need to use PI's validated modules. So Fedramp doesn't require a cloud service to use FIPS validated crypto modules for everything. We require the cloud service to tell you what type of information they protect with what cryptographic modules. And then you would say all right I'm putting my sensitive information. It's of this data type. It goes into this particular service within that cloud service that has fifth validated encryption. So we're good. Uh that's kind of the disconnect there is you always have to run your agency process. Better can't take that away unfortunately. You still have to run all of that. Better wants to make it easier for you to use a cloud service while doing that. But all those rules that are on you, we didn't put on you. They've always been there. We're just trying to make the burden easier. Okay. Jay, Nicole, what's up? Come hang. [laughter] Yes, there are people online. Um, I'll let these folks introduce themselves. We're going to talk about CISOD 2604 and why it's important that you change the way you do everything. >> Great. Thank you. Hi, Jake Alay, your friendly vulnerability manager from SIZA. Oh, there we go. Hey, I'm Nicole Thompson. I'm the security director at Fed Ramp. >> Great. >> Cool. We didn't rehearse this at all. You can't tell. >> But key off something that that Pete said and he's he said the regulation is always been there and we're trying to make your life easier. So, I want to apologize. Couple years ago, SIZA put out a binding operational directive. Who knows what those are, right? We got a couple. We have two authorities. Binding operational directive, which tells us you must structurally change your cyber security programs and emergency directives, which means usually a IT vendor, which I will not call a cyber security vendor, is having a bad day and we need you to do something to fix stuff right now. Uh please see the uh recent work with Cisco on the SDWAN appliances that have been under persistent attack by nation state threat actors. Um those are emergency directors. We're talking about bots. Um back in 2015 we got the authority to say we need to structurally change things. And one of the first things we did is we told everybody to do something egregiously dumb. And I'm here to apologize. We told you to prioritize all of your vulnerabilities based on CVSS. And I mean, I've known for a long time, I used to be a CIS admin, that CVS is not a good way to prioritize things. And if we want to give a compliance human something to harp on, we can say deal with CVSS moderates and low. Even though there's no evidence that any CVSS with a any vulnerability with a score lower than CVSS 5.5 has ever been exploited. We maintain the kev. We know this to be true. Why would we tell you all to go do something about that? That seems not smart. So, um, we released a new bot and we're going to go into like this huge gant chart of like times and dates, but I want to talk about why we did this, what we're trying to drive, and importantly, some of the words we're using. Because one of the things I found about federal change management is once everybody knows the words, having the discussion is often quite easy. But if you have a difference of an opinion or a difference of understanding of what a word like exploited means or internet exposed, conversations can rightfully spin out pretty hard. So we released a bud that says you no longer have to patch everything all the time in certain amounts of time and we're going to neck it down a lot and we're going to neck it down based on risk. So, can we pop things forward one slide? Great. So, instead of talking about CVSS, we're going to talk about things that actually matter about a vulnerability. Is the vulnerability raw on the internet. That's actually a really key factor on whether or not ERC or Russia is going to exploit it. We found that very rarely do a nation state threat actor or threat actor of any type federally use a CVE internal to a network. We validated that with our own pentesting teams. Usually throwing a VM on an internal device is is pretty loud and manipulating your active directories if you're at an agency is actually really easy. We do it all day long and nobody ever detects us. We know that PRC does that too. So let's not focus on patching and let's instead focus on internal observability and hardening identity and dealing with privilege privilege escalation or we actually have a chance of doing some help. Next, Kev status. Most dangerous uh uh the most dangerous vulnerability on your network is definitely the one that's already been exploited on your neighbors. Less it's singledigit percentage for all vulnerabilities that have ever been exploited. And that is a doubling of what we have on the KEV, if not more. We have like less than 4% on the KEV. So like even if we're we're 50% blind and our standard is too high, it's still singledigit percentages. So why are we having you fix vulnerabilities that have never and will never be exploited. Um so so that was our first framing. The next framing which which I want to talk about are are the two things. one thing from CVSS that really matters and one thing that is kind of a response to what we're seeing with the capabilities of new frontier models and the first thing is is authentication required just like in a kill chain on your infrastructure we're worried uh about privilege escalation matt attack framework we're really worried about having detectability there because a bad guy can get on a device but it gets problematic when they take domain admin We are worried about a vulnerability that doesn't require any authentication. Same reason once you have the username and password on a system, you really should be focusing on other types of technical controls and observabilities. Protect your network. The other thing we're worried about is technical control. And we define this term in a moment. It's different than maybe you're familiar with, but I'm going to dig it real high level. There's either total or partial. Total is remote code execution. Partial is a denial of service. That's the the real rough terms here. We define it more in our FAQ which I'm sure somebody can find on the internet or we can put in a chat somewhere. Next slide. On to words. definitions really matter and we are trying very hard to pull away from some of the internal to our agency sloppy language we have used to articulate risk and consequence to all of our federal stakeholders. Uh I recognize that it is partially my fault. Uh, I have written some of these bods and emergency directives over the years and I have not done a good enough job scrubbing the words to make sure they all mean exactly the same thing. We find when we have these words mean all the same thing. Everybody knows what actions to take and you can task it down to a contractor. You can task it down to a GS12. You can have a thoughtful conversation with a vendor. But when people don't agree on what an asset is, it's really hard to figure out what's the de like what are you protecting? When you're having a hard time determining what does publicly exposed mean, that's also hard. By the way, there's still some dissonance between bed ramp and siza here. And we're still going to be working through it. But this is our definition uh for the purposes of SIZA. And we will commit to again continuing to work to harmonize these across the whole federal lexicon which is a hard task in and of itself. We have partial and total control denial of service rce. But then we have this one and I guarantee nobody's seen this one before because we made it up. And we didn't make it up until we realized what the problem was. And one of the problems we've had persistently across the federal enterprise and working with commercial customers is people patch stuff. Yay. But they never check see if somebody was sitting on the box. My pentesting team by our NDA authorities does this all the time to federal agencies. We frequently will exploit an externally facing deac box. We will then inform the sock, hey, we are on your box. This this needs to be patched. A network operation team, not the sock, will come and patch it, but the sock doesn't check to see if there was somebody there. We have fre we have landed on boxes in federal infrastructure and found somebody else hanging out with us, PRC, access brokers. And what we realize is we have a cultural problem in the way we've constructed our organizations that the sock the knock don't report to the same people. And so the knock charge of our operations team in charge of patching gets gets gets that patching done. But the sock doesn't know that it was exposed for a certain amount of time and doesn't have the insight necessary to do a quick check of the box. And so what we're doing is we're going to require that when you have an internet exposed known exploited vulnerability that doesn't require authentication that you check the box that was running to make sure that it doesn't have a case of SVR or PRC. Um, we anticipate drastically reducing meantime to detection uh with our federal stakeholders and hopefully lowering costs of overall incident response by routinizing this type of communication. Next slide. Here's the eye chart. I promised you a lot of fun, but it talked. So we get rid of the 30 6090 who we there is no more requirement that we are aware of in federal policy to patch via CVSS. That was our intent. We will be working with IG's and IG's to end that regime of ineffectiveness and instead we're going to say do this because we think it makes sense. Um, this chart represents everything that's publicly exposed. If you're raw on the internet, you can get pinged from yahoo.com or your home. You can touch it. If it's publicly exposed, that's what this is. Is it on the Kev? I hope everybody knows what the Kev is. Don't. It's the known exploited vulnerability catalog and the highest threshold for exploited you're ever going to find. Is it automatable? Does it require off? And you'll see that if it's not on the kev, but it is automatable. Generally, you got two weeks. You look up there and you say publicly exposed in the Kev automatable, you're looking at three days with forensic triage. three days or partial control. He got 14 days. We put all of this information on our GitHub page. We enrich the CVSS record or sorry the CVE record with all of this information. We are talking to every major vulnerability management pro uh information provider to ensure that it is also consistently there. And we have been working with continuous diagnostics and mitigation to ensure that that information is in agency dashboards. Next slide. This is where it gets fun. Line 15 and 60. Over 70% of the vulnerabilities out there. We are telling you not to patch them unless you feel like it. There's no at this time riskinformed way for me to tell you deploy a security patch on a random system deep inside your network with a CVSS score of seven. I I can't in good conscience tell you to flush your time down the toilet engaged in a silly compliance exercise for something that we have observed no risk. Now, if that vulnerability eventually joins the single-digit percentage of exploited vulnerabilities, well, it's going to be going in the Kev and then you'll have to deal with it. But we're going to automate that information to you. We're not expecting you to go out there and find out on your own or make a determination of a vulnerability is exploited. We'll put it on the kev. We'll add it to the world's information feed and your vulnerability management tools should tell you, oh, hey, this one was like on a do it whenever and now it's a do it soon situation. We expect again 60 to 70% of all vulnerabilities you upgrade the system have a nice day that's going to buy back a lot of time and we want that time used to do useful things not compliance activities. We want departments and agencies, infrastructure providers to spend that time hardening your identity stack, using that time to build better observables for privilege escalation. Things that have consistently TTPs that haven't consistently been used by our adversaries on our infrastructures and that are observable and detectable and useful. We're trying so hard to reduce the burden here and focus where it matters. Um, it's taken us six years to do it and we don't know if we've done it right. We think we've done it right, but our other commitment here is that instead of waiting 1902 was the last time we updated our guidance or our directive on how often to patch things, we're going to be looking at this at an annual basis. We're going to be taking the look a look at the data about federal intrusions and then changing the requirements accordingly with a bias towards pushing everybody to doing the most riskinformed activities which is almost never patching internal systems. I say this as the person who runs the vulnerability management program at SIZA. I sit on the CVE board and have just watched a ton of federal intrusions over the years and again I apologize for our previous directive. It was not the most wellspent time that you were spending and we really did try and get it right. We realize it's a sea change. I realize that you have questions. Nicole is the expert on how Fed ramp follows this. So I will kick it to her to talk bed ramp and then you can hit us up >> ask all your questions. Yeah. So uh Fed Ramp was actually really really excited to see this binding operational directive come out because it aligns so closely to what FedRAMP had put out in uh the Vader guidelines that had come out what in August of last year. So we've been piloting this concept for a while. We don't have a lot of um uh cloud service providers who have opted into that beta, but this is going to start pushing the needle with SIZA releasing this binding operational directive. Also, um we had originally planned in CR26 to make Vader uh mandatory I think a year from now. Um their timelines pushed that deadline up. So now the deadline is December just like theirs is. Um so we are actively pushing CSPs to start prioritizing vulnerabilities differently. Um now because FedRAMP is specifically focused on cloud services um and we are very internet reachable usually by default um our deadlines are even tighter than what SIS have put out which would make for an interesting fight about three whole days to patch. I mean there's a reason for three days, right? Like you want to make sure that an application or service stays up in a previous life. I was unfortunate enough to do be the IT operations manager for a department principal and they were going to take down the network to do a routing change while the principal was in the airplane on the way to Iran for a negotiation because IT ops thought that was a good idea. It became a three-day change. Right. Like like like the friction points are real and we want to we don't want to be the point where we're lighting up agencies. I mean you can light up CSPs all you want. They're they're for-profit companies. They should have these engineering diagrams. I don't want to light up agencies. >> Well, I think this is where our scopes differ, right? Absolutely. Because we are so focused on cloud service providers and you guys are focused on everything. Um and so our our um rules for cloud service providers, if you are a class D certified system, you have 12 hours to patch um something that is evaluated at a pain level of five. Um which means you are it's debilitating to the the federal customers that use your service. So tight deadlines. Now if you have a particular reason like the one that he just presented, you can delay that, but you need to have a good technical reason why you cannot meet that deadline and you need to explain it to your customers um that are affected by that. So, we were really excited to see this binding operational directive. Pete stole a lot of my thunder about what Vader is and does earlier. Um, so I won't belabor those points, but I think this conversation came out a few weeks ago when we came out to visit Siza over in Arlington and Jay and I just kind of nerded out about vulnerabilities for a while and we said, "Wouldn't this be fun if we did it in front of all of you for ped day?" Um, so excited to see the direction that SIS is moving. Um, excited to see that we are actually prioritizing meaningful vulnerability remediation and mitigation. um in in a way that makes way more sense for actual security impacts. Um so if you guys have questions, we're all ears. Also, I can't see anything because that projector is really bright. That's why I went right over here is because the projector was blinding me like fully. I realized I was cutting that off. Even be critical if you want to be critical of what we're doing. You you like this is the time. >> Yeah. >> A guy in a tie. >> David Meyer. Thanks for the presentation. Um I guess from the where the intersection is here between the CSPs where Pete has been saying you know the the onus is on the agencies to create the poems but you still have these patches that they have the timeline but just like how are the CSPs Nicole how are the CSPs um what's the reaction when they're hearing about this uh from you guys that their timelines and the whole way how they're doing their poems until now when Pete was talking sounded really good because they have a lot less to do but now it's like they have a lot more to do. >> Yeah. So we've gotten questions um specifically from CSPs about well Pete talked about this earlier about um well we're not sure if the agencies will let us move to Vader. We're not sure if they're going to prioritize our significant change requests to move from the old vulnerability detection processes over to the new ones. Like SIS is mandating that the agencies do it. The agencies are going to be pounding on your door asking when you're going to follow suit. Um and so because Fed Ramp guidelines are very much in alignment with what SIZA is asking of agencies, this should make your lives a lot easier. They're going to be reported in very similar ways. As long as they're compliant with VDR, they're going to be meeting the SIZABOD requirements that are placed on agencies as well. You look like you have comments. >> I'm supposed to be in this Q&A now, too. Uh, according to the agenda, I I want to make a really important point here for folks. You don't live your life talking to industry. And a lot of times some of you make the mistake of thinking industry is more cavalier about this stuff, but pretty much any halfdecent commercial cloud service provider that we talked to said if I have an exploitable vulnerability on the internet that is a incident. We are going to fix that in minutes. It is only the weird, sketchy people that sell stuff to the federal government that went, "Oh, how dare you? I should have 30 days to be able to fix that." And I think that that shows a lot about like how to some degree CISA was in the wrong place and we were in the wrong place because you I mean some of the it's crazy. These people were literally like what are you talking about? My business would be destroyed if I left this on the internet for 3 days. I would never ever ever ever ever do that. So if that's what you're worried about, like that's not where the problem is. The flip side was just like all of those weird governmentmen only folks that love the government traditional timelines of like I have 30 days to patch this and they got used to it and they didn't have actual decent security programs. Uh so those are the people that push back just like agencies. I'm sure all of you have been like how can I possibly do this in three days? >> So So a couple things. First off, you're it was I I classify them as rent seekers are the ones who have pushed back. Vendors who come back with problems, their business model is generally built on extracting a rent from a customer as opposed to adding value. A real easy understanding about the quality of your vendor is when we talk about things in terms of actual riskbased determination, if they're saying that they have problems with something, think about their business model. Second, um, you know, I understand and appreciate, especially with the complianceoriented nature of federal cyber security. There is an incredible overindexing on the existence of IG's here. I say this is somebody who responds to lots of IG reports and I see that many of them will do a 100 pages to say, you know, hey, there's $200,000 that could be re rep prioritized and we're talking about a billion dollar problem, right? We have folks who come in and say to us, hey, SIZA, you you aren't patching everything. You're right. We're not patching everything. That's a waste of time. and that checklist mentality as defenders think in checklists understandably but attackers think in graphs. We're trying to move towards the attacker mindset. We're trying to help empower every person who runs infrastructure, every person who's doing a procurement to think in terms of attack tasks and not in terms of a compliance activity. And I I I will bore you quickly with a compliance activity of me not spending time with my kid one night because I made the decision to be compliant with a cyber security policy that said I had to patch a CBSS6 on a SharePoint server and it took down the Secretary of State's communication because I was f I it was something I should not have done. I knew it was a bad decision but I was being told be compliant I had to do it. And so overnight I took down Secretary of State's Fairpoint infrastructure and there was not space as as a contractor at the time. There's not space for me to have a riskinformed decision or even communicate because the ism is over here and is willing to hold my contract out of compliance and IT ops is over there. And so like I know we say you know we all solved the problems from our earlier parts of our career. I like to maybe just learn some lessons and help all of you and your staff and your contractors and the vendors you provide that you rely on all get the learnings as well. This is one of the reasons uh why we have a lot of Fed app rules that are shoulds instead of musts. And we get feedback all like pretty much every time we do an RFC that majority of the agency feedback is all of these shoulds should be must. Uh no press button [laughter] >> including the one about mitigating kevs according to SIZA's timelines. >> Yeah, that's a should. So, and that's an example where like we say should because there might be a reason. You might like be doing active forensics and need to have that exploited vulnerability there. You there there could be so many reasons and what we'd never want is someone to say, well, I have to do this to meet this compliance requirement and so I'm going to make a decision that will make my system less secure because of this compliance requirement. So much of 20X is empowering you to make good security decisions about your particular environment with your mission case in mind. And if you are being prevented from making the best security decisions by something that's in our policy, come talk to us about it. >> I see Trevor's holding a microphone just desperate, ready. >> Thank you, Jay. This one's for you, Nicole. I'd like to hear your perspective from it as well. So Jay Jay, something you and I frequently talk about is our challenges with the economies of scale and being able to respond and recover and support the agencies in doing that. To set the tone here, what Jay and I hear all the time almost every day from our acting head of agency, even out on their public messaging is we need to be prepared to look our friends, family, neighbors in the eye and tell them we could have done better. we could have responded to these faster. Jay, could you talk a little bit about maybe give a call to action to the liaison in the room here about how they can help scale these efforts? That's a hard question because I don't know every agency and every product and every infrastructure, but you're right, scaling is hard and that's why we're having this conversation in 2026 instead of 2020 when we knew this was a problem. I knew took over this portfolio and in February 2020 I had a meeting at the software engineering institute where they did all the math. They showed me how absolutely insane we were doing the our our programs and the amount of time agencies were spent doing manual labor respond to it. They're like why does it take 2026 besides government is hard because the overall ecosystem wasn't automated. We spent five years changing the ways that CBES have their JSON format and creating mechanisms for external entities to enrich CVE data. I know this is really in the weeds for you guys and sorry if you want to glaze over. We spent years coming up with the precise and correct and repeatable analytic requirement for what a Kev actually is. Honestly, that's really hard to do. What does exploited mean is a tricky bit. And we weren't ready until we had this all done along with things like CESAF, common security advisory framework, so that vendors publish this information in machine ingestible format. VEX. Anybody can tell me what VEX is, I will buy you lunch. Besides Bronco, go ahead. None of you can. I love this. So, uh, who remembers log forj? >> Great. People remember this. This was great. This was like the worst month of my career. It was terrible because what's the denominator? How do you know? One of my colleagues was the director of product security or one of them over at a company called Intel. Heard of it? at the time, you know, the company, I don't know if they had still were like in the tail end of their acquire products instead of build products phase of their that company. They kind of went down a 10-year kind of journey. They had like 1,200 different products that had Apache in it. So they had,200 help desks getting lit up like Christmas trees, but only 150 of them had Apache installed in an exploitable condition. And so what they needed is they needed a no flag. They needed to be able to say, "Yes, this software is in my software. However, it's not exploitable. Not we're not using that part of it. But we haven't turned on that flag. We haven't like you are free to ignore it. And until we had sbombs, until we had Beck, until we had CESAP's whole set of words ready to go, we couldn't automate this. If we can't automate this, we can't afford to do the change management with all of you. We can't be prideful enough to say, "Yeah, we know what the right thing is to do, but we're going to make it harder for you." That is not okay. We have to take the time to listen to what we have consistently heard which is this job is not easy and we are resource constrained and we have to make sure that all of the backend infrastructure for the whole vulnerability ecosystem from vendor coordinated vulnerability disclosure security researcher how do you transmit the information is all squared away or we get to say we're ready to go. So that's the long answer. Is that is that what I got a thumbs up? Great. Oh, you said you wanted to hear from me, too. Um, we've talked a lot about this concept at Bed Ramp. Um, where we are empowering commercial industry to go out and innovate. Um, and when we get overly burdensome federal regulations and rules and standards about how they are required to do certain things, makes it really hard for them to innovate. makes it really hard for them to implement the new groundbreaking security whatever is coming down the pipe um because they have to do it in the government approved way if they want to sell to the government and that's not fair to private industry. So, we're seeing commercial products that are way more secure than what the government is using because the government version is stuck on the ancient government regulations that they have to meet and the commercial sector is like running away with everything. You look like you're about to say a lot. >> I am about to go there. One of the beauties of many of the products that we buy that are complianceoriented is they no longer have product managers. Many of the products that we use to secure our infrastructure no longer have, you know, new development. They're often they've been acquired by a private equity firm and then are on zombie life support seeking rent from all of us and not improving their security. There was a prominent uh SSLVPN that got absolutely destroyed by China like 600 times in the last five years that we found had code old enough to drink in every state of the union. Like who thinks that's a good idea? That code was not safe. And that code was raw the internet at many federal agencies. Now, the federal agencies that I talked to, they wanted to move to a modern solution that maybe was like not picking a vendor here, but like like Zcaler, but they were like the compliance is hard. And I'm like, my lord, you have a Chinese initial access device brought to the internet connected directly to your enterprise identity and ported into some of the most sensitive systems that exists on the planet because it's compliant. We need to change that regime. We need to allow agencies to make good risk decisions. You know, we can't do that all at SIZA. I hear, but we can also continue to take feedback about where we are not helping you do that because the status quo, it just can't stop. I'm going to add on to that going back to a question from much earlier in the day like as a reminder in that context why it's so important that agencies actually own responsibility and do proper decision-m about their use of services. It's like we have literally seen situations where an agency has deployed a commercial version of something rather than the Fed ramp version of something having no idea that they did that. We have seen situations where people agencies have deployed high now class D cloud services without requesting access to the security package and like if you're doing that you're shooting yourself in the foot. It doesn't matter that somebody else in a compliance exercise said this this has like three gold stars if you're not looking at the actual report within which could be a whole bunch of stuff that says don't use it for this don't use it for that don't use it for these things and here you went and use it for that because you didn't look at the report and make your own decision don't rely on compliance security is what's important >> this is why in a lot of 20x ksis or other rules you'll find that we don't offer like very prescriptive ways of doing things. Specifically, when we're talking about Vader, we leave it up to the CSP to decide what combination of technologies they want to use to detect the vulnerabilities in their own services. Um, bug bounties may work great for some, may not work so great for others. Um, most people should have automated vulnerability scanners of some sort. Most people should have um at least a vulnerability disclosure program up and operational. But like we're we're not even being super overly prescriptive about you must have a red team come in and test your service because >> that's my favorite. It's like, oh, you remove the requirement for a yearly penetration test? Like that's super unsecure. And I'm like, oh, what? You're only doing penetration tests once a year? That's crazy. You should be doing penetration tests of various formats like daily. So to quote Alan Freriedman for those of you who know who he is, how often before a breach does a PCI audit fail? Never. How often after a breach does a PCI audit fail? Always. Those pen tests when they're not done by truly independent infrastructure where you're not paying for it are probably not doing you the maximum amount of good. It is important to have somebody who's truly disinterested involved so that you're getting your an actual representation of what the risk is. I I just I can't foot stomp that enough. There's no way to checklist a pentest enough to prove that it's actually helping and I do this as an organization that literally runs hundreds of pentests a year. >> Yes. I had to step out of the room when you were answering questions beforehand, but did you talk about um taking away the the Fed ramp specific language in the Rev 5 controls? Why we did that? >> I don't think we talked about that. >> We should talk about that. >> Did we talk about that? You did not talk about that. >> Taking a slight detour from vulnerabilities, but >> yeah, >> I mean this it's related to vulnerability. And actually like there is a tie in here which I think is really interesting which is like the timelines and the deadlines. This is one of the things that we think is super super fascinating. If you tell someone they have three days to do something, how long will they take to do the thing? >> Three days. >> Three days >> or longer. >> That will be their policy. They will write it down. They will tell everyone. And every time they get something done in 2 days, 23 hours, and 45 minutes, they will throw a party and say, "We did a great job." And like that is one of the biggest dangers of compliance that totally sucks. So we've tried to do a few things with 20x. First of all, you don't report whether or not you did it in the time. You actually report the time. And we're going to as we get information in in a machine readable format where we can start drawing trends and things like that, we'll be able to say you can look at a cloud service and say, "Wow, these folks are patching their their kevs on average in 12 minutes from discovery, whereas these other folks are doing it in 2 days, 49 minutes, and 17 seconds. Which of those would you rather use?" Right? You need to have access to that information. We need to encourage that. Um, as part of that, yeah, go go. >> Do you accept negative numbers? No. Because seriously, all these vulnerabilities happen, right? They're not known to be kevs. Maybe you have a really good vulnerability management program and you patch all of Apache instantly and we have a Kevin Apache 3 days later. Like, how does that work? >> Yeah. I mean, think about that, right? Is like you're going to be looking at your cloud services. Let's say there's like a um boom Kevin Apache. You're going to have one cloud service that is like zero to report and you're all going to be mad and you're going to you're going to be like Fed Ramp they didn't they didn't report any like you need to yell at them and we'll go talk to them and they'll be like yeah we have a system in place that prevented that from even happening in the first place. That's so much better than the person that's like we found 800 of them and we're in the process of fixing them. This also brings up an interesting point because one of the differences between the binding operational directive and the VDRV that we have is that we don't maintain the Kev list. So we have likely exploitable vulnerabilities and you need to check to see if it could be exploitable. CSPs, well not you it should be your CSPs that are doing this, but they have access to threat intel information of their own. they have access to like are proof of concepts widely available? Um was it uh released wi along with a proof of concept and SIZA just hasn't gotten it on the KEV list yet. Um and so we include likely exploitable as a metric that we closely track um along with public reachability and all that stuff. >> Yeah. A note, we only count the exploitability like exploited as if we actually know it's exploited. Um, we get a lot of feedback from industry like, hey, why isn't this CVE on the known exploited vulnerability catalog and we say, well, show me that it was exploited. They're like, well, I saw it on Twitter. No, that doesn't work. Uh, I saw network traffic coming from C2 infrastructure. Okay, great. that is a locally exploited vulnerability that is not exploitable by a network. How would you know that over an encrypted channel, right? So like we have extremely high evidence thresholds for as many kevs as we have we have as many candidate kevs that you know either it's on Twitter and so like we understand that our KV is a trailing indicator. I we're not to pre-rime at SIZA. Um I candidly think of some of the exploitability things as being a little pre-rime and to have some 100% >> puts and takes that are involved in that. Um but that's why we have the forensic investigation, right? Because there is a concrete action that any system owner can take after they have an internet exploded cat. They can look at the box. I mean, even in the best scenario, and best I mean worst, the quickest I've seen uh a threat actor take over an agency was 40 minutes. That was one time. 40 minutes before they did a full xfill of the entire M365 infrastructure that was on a SSLVPN that was directly connected to the internet and enterprise identity. And they just piped it out. It was great. Um, but usually it takes weeks. Usually because the nation state threat actors are interested in running low and slow, they grab an initial access on one of these uh internet exposed devices and then they have to either jump through certificate into active directory or they have to do some lateral movement. And that's why we really believe that the forensic investigation is the key thing to do after you've had an internet exploited internet exposed nonexloded vulnerability. >> Yeah. And that extends past I mean one of the things that we're really focused on is expanding like vulnerabilities through to just like any weakness. Right. So, I've got a senior architect that is one of the only people in our company that has access to the safe with the recovery codes. If uh you find out that person owes money to the Russian mob, that's a vulnerability and like that's a likely exploitable vulnerability. You need to resolve that. Um, but I think at the end of the day it would be really fun to change the calculus to like is an engineer scared? If somebody is scared when they found out, they should fix it. If they're not scared, then like cool, take your time. But if it's scary, if you're like, oh no, then you should fix it. >> But that's a great point because you can't put a CVSS score on >> Russian gambling mob. >> Agencies would never fix that because There's no CVSS score for having every user in domain admin. >> Let's be clear. Most vulnerabilities that Oh, question. >> Hello. Here, I'll give you my Oh, okay. There. You don't have to save everyone. >> Being here and this whole group and this this feels like an echo chamber, right? Cyber security folks understand cyber security is important. We know that these vulnerabilities are important, right? If we had our way, if we ruled the world, these patches would be done immediately. But I'm going to go back to my desk and I'm gonna have another message from another program office, an economist, a meteorologist, a patent trademark office. They're smart people, but they're not cyber folks. And they're going to say, "I bought this product and I want to turn it on tomorrow because they have Fed ramp authorization. So why should we have to do anything more?" And what what do you mean I have vulnerabilities? You're not taking my system down to patch my system every three days. So what do I say to those folks, right? The everybody in here is going to go back to their office and say here's somebody else say I bought this thing and the product you know the sales team at this vendor says I got this Fed ramp stamp of approval and these smart people that are not fed, you know, IT people are going to say well why do I have to go through the agency risk management process? I have fed ground. So, what do I say to those folks? >> Tell them to stop being criminals and stop breaking the law. >> They've already bought it. >> I mean, like, >> but they've already bought it. >> So, you've got a few you got a few issues here uh that you're hitting up. And I think like you're going to want to start with some of the recent OM memorandums like M2610 that >> it's an IT policy, right? That's not a meteorologist facing memo. >> So, under this is where it gets complicated. Under the law, your CIO is personally responsible for that. And if somebody at another agency goes out and or at a bureau goes out and buys something, you're failing. Your CIO shop is failing their statuto responsibilities. So you need to have mechanisms in place to handle that from a legal, from a training, from a management, from an oversight. >> We have >> Fed Ramp's not going to solve that for you. I understand, but it's a challenge to Fed Ramp to stop these vendors from saying, "I have Fed Ramp authorization. This stamp means nothing more." They're saying these things, right? So, >> we yell at people all the time about that. Um, and they go to Congress and tell Congress that we're being mean to them, and we yell at Congress and tell Congress to yell at them. Uh, sales people are going to sales people. If if you're this is like um if you're not resilient to people lying to sell you things, then you're going to be taken advantage of. Um, Fedramp is very clear that this is a process to the point where like this is one of the main reasons why we renamed why we labeled Fedmp authorization as a certification because even people that knew better, people that like were in this game for years would be like, "Oh, they got a Fed Ramp atto." I'm like, "You didn't get an ATO. There's no atto." Like, what are you talking about? Like, legally, there's no ATO. Fedramp authorization is literally defined in the law as a certification from Fed Ramp that it passes some security processes. Uh so that's one of the examples of things that we're doing. Same thing with removing the low, moderate, and high. That's an agency decision about an agency information. There is no such thing as a cloud service provider that has been, you know, determined to do that because that's not how any of this works. So we are 100% constantly fighting that fight of like stop telling people that this is a magic pass to the whole government because it is not and you are hurting the government and you are hurting civil servants. Um however um Bed Ramp 20X is designed to give you that information that you need to make a quick security decision in a compact package so that when your users say like you could have a group of 10 users that would say this cloud service provider would make my life so much better at work and in an afternoon you can sit down and you can evaluate the security you can look at the trust center of that particular cloud service and say yeah for your use case that makes sense. Here are our agency controls that we have to make sure that you're using it appropriately according to our agency guidelines. But yeah, if that serves your purpose and that's going to make your life that much better, even if they only need it for 30 days, like give your users what they need. And we're trying to make it easier, faster for your end users to get what they need for you guys to make the decisions that you should be making um with this information so that you can quickly spin up cloud services and decommission them when they're no longer needed. It shouldn't be a six-month process to onboard a cloud service provider and now you feel forever attached to them because you put that much effort into getting them certified at your agency. >> Also, just to be clear, um Fed ramp, you know, people are always like Fed Ramped Fed Pedra. Uh but like the circumstances you described violated uh acquisition regulations, procurement regulations, ethics, like about 15 other rules that are far more important than Fed. Uh so like if there's a systemic problem of that happening at your department, don't talk to Fed Ramp about it. It's somebody else's problem. Uh we have five questions online. So, I'm gonna >> Well, you have five minutes, so ready, go. >> Yeah. >> Okay. I'm going to read them off in the order in which they were received. Our agency is sponsoring a system and will be initiating work on an ATO. Please let us know if there are any preliminary requirements we should be aware of as we begin this effort. >> Follow the legacy process. Get it done as quickly as possible. Pay attention to the new rules. have the cloud service understand they're going to migrate to the new rules and if you don't think you're going to get it done by June 11th maybe rethink it. >> Perfect. The challenge we are anticipating with the 20X framework's extensive flexibility is that managing compliance for a large Fed ramp portfolio such as over 250 systems individually is not going to be sustainable with current limited resources and increases operational complexity. How can Fed Ramp assist in addressing these challenges or help communicate their impact to agency leadership to support resource allocation? >> So again, as a reminder, 20X does not change the responsibilities. Uh so if you were struggling to manage 250 services before, you're going to be struggling to manage 250 services now. If somehow that struggle increased exponentially because of uh changes to the rules on the certification side then you might have been missing some statutory expectations for your management of cloud services. Now that said 250 is a lot. I would think that a program with 250 using 250 cloud services would be on the forefront of procuring testing and experimenting with automated capabilities. you'd be huing towards services that make that information available in a in a thing. You would not be downloading a bunch of packages from a SharePoint and looking at them manually once a month. >> Yeah. I I'm going to say to the poor person on the phone, first off, I'm sorry that sounds awful. And the only way that all of us are going to get out of the future is by automating ourselves out of it. the the the amount of data that I'm expected to process on a data b daily basis is completely unreasonable and I assume that's true for all of you. It's true for all of our analysts. When I was working at an agency, it was already unsustainable and that was a while ago. I cannot imagine trying to do this without a centralized automated function and that is something we should continue to have a robust federal dialogue on because any agency that isn't in a fully automated GRC situation. You're not being set up to I just I can't >> What is Fed Ram doing for you in that situation? We are publishing tomorrow a bunch of rules that will over the next year and a half require every cloud service provider to provide you information in a way that you can adjust it using automated modern tools and scale your system. That's causing billions of dollars of cloud service provider rework. It's causing people to change expertise. It's changing the way assessments work. The entire ecosystem is being shifted by this to address that specific problem to move you away from manually looking through a whole bunch of files on a monthly basis because we all know you weren't doing that because you can't with 250 of them to go through. Uh so that's what Feder is doing. We're changing the expectations for businesses to ensure that they are providing you information in a way that that can be scaled. It takes a little bit of time. I get frustrated pulling one package down from connect.gov, I can't imagine 250. >> Yeah. Hard pass. >> Yeah. >> Okay. Uh so instead of building a single baseline to evaluate CSPs for moderate or high impact levels, the vision in 20X is one build a use case to meet a need including KSIS and implementation and ongoing verification requirements you want to see in the cloud provider SDR. to check among cloud providers using the machine readable documentation to see whose SDR has what your use case requires. Is that correct? >> That is what the A130 directs you to do as you go about preparing to deploy and operate a federal information system. Document your federal information needs. Determine what controls are necessary. Tailor them as appropriate. select uh those controls and then assess systems to see if they meet those controls. >> Okay. Uh one last question. How does Fed Ramp help educate the gov workforce who are in uh EM roles vice the cyber security roles versus I think they mean the cyber security roles. For example, if a company comes with Fed ramp high, what else is needed for their agency specific ATO? How can that be streamlined at the federal level? Or is the onus on the CIO of each respective agency? I'm thinking more along the lines of how we partner on messaging. >> Yes, the onus is on the CIO of each agency to set the process for their agency that's in the law. But we want you to uh learn from each other. That's why we have the agency liaison group that is here today. And um if the person asking that question is not a part of the actual agency leaison group because we've invited a lot of different people here today. Uh you should be a part of that. Make sure that people in your CIO shop are a part of that. We have working groups where we go through actual packages. We provide we're working on as I mentioned earlier building up this technical advisory group in a different direction that will focus on providing guidance. We also have instructions templates. We have a FedP board to do all this stuff. But we're doing all of this with 30 people as well as doing all the certifications, all the reviews, writing all these policies, hosting Feder days for a whole bunch of people, uh, and coordinating all of this governmentwide. So, if we can do it with the tiny bit of effort that we have available to put into it, like a thing like today is pretty much entirely uh coordinated by chief of staff Ryan and Marcia and communications. Like they put in so much work to get here for all of us as the same time as we're doing everything else. So, this is like one of the things that I am asked constantly is why isn't Fedramp doing more for me? Fed should do more. Fed should do more. Fed should do more. I love that you want FedRAMP to do more. I would love for Feder to do more. Fed is doing everything that we possibly can and we continue to do that. But the federal government is kind of a little big and you all need to be a part of this for your own agencies and your own areas. That's why you exist. So we talk to you, you talk to your agencies. This moves outward. But don't expect a tiny program seven levels down from the administrator of GSA buried in the General Services Administration to own and control this across the entire government. And if you don't think that's possible, if you still think that's possible, look at Dissa who's actually responsible for that for the whole department of war. And even they don't try to do it for everything for the Department of War. Like let's all do this together as a community. And that is what FedRamp tries to provide. I think probably more than most other programs. We want implementation, staff level, executive level, any level. We want folks to be a part of our community to share information to come together and share best practices to have dialogues like this and build and expand across government. That's what Fed Ramp gives you. >> Yeah. We also put a ton of documentation into CR26. So under the agency's heading should have like every possible reference you could want about agency participation in the Fed process. So if something's missing from there, let us know. Um we can actively maintain it based on your comments. Uh but you should be able to use that as well uh as a reference when people at your agency come ask questions about how does my agency fit in with Fed Ramp. Yeah, that's a great point to uh to the question from commerce earlier is like take them to send them to the Fed web page that says don't do this and in fact if you want like you send us some wording we'll put up a web page that is like oh my god don't you dare go buy this Fed ramp thing without talking to your CIO like we'll put it up there >> and if you want to be on the Fedramp leazison listerve email info@fedrampgov and we will add you. Yeah. All right, we got >> We're gonna wrap up. Jay, thank you for coming from SISA. We always appreciate our partnership with SISA. >> Um, some quick next steps things on the horizon. So, we mentioned CR26 a bunch. Tomorrow we will be dropping CR26. That's our uh consolidated rule set for 2026. Um and then next week we have Man, it's really bright up here. Um >> yeah, [laughter] I don't know how you guys doing this. >> That's why we're all standing to the side. >> Um yeah. >> Okay, that's much better. Um next week we're going to have a community working group. Um so if you're interested in joining, it's on our events page. We'll have another one the following week. And really the focus of 20 of July is going to be answering questions, getting information out there. Um, CR26 has been in development for the last two months, but we're coming up to the finish line and we want to make sure there's a lot of information that you all are going to have to ingest. So, we'll be there for Q&A. >> Um, yeah, >> it's not a working group anymore. >> Community update group, which you are open to questions. It turned out we were just spending an hour talking with people and weren't doing any work. So, we rebanded them as community updates. Uh, but seriously, fedramp.govvents fedramp.gov community fedramp.gov notices fedramp.govrfcs fedramp.govblog or just fedramp.gov. We put out a ton of stuff to try to help this community. Oh, there's going to be a legacy page, too. Well, you didn't talk about that either. >> A what? >> The legacy page. >> Oh, yeah. There's soon going to be feder.gov legacy. fed.gov2026. Like, it's that's where it's at. But definitely come hang at our community update in a week or two. I won't be here because I'm going to be on my motorcycle somewhere heading towards Montana. But the crew is going to handle this. We're going to rev five and 20x every month. Community updates for each of those. That's twice a month. Agencies are absolutely welcome. Come hang. Agency leaison group once a month. Agency working group support group. Not working group support group once a month. Come hang. Agency leazison lists serve available at your convenience. Anytime you want to ask a question of the inter agency, come join. Thank you all for coming and thank you for those online who joined