A (4:27)

Alrighty, here we go. Just to get everybody on the same page to make this extremely clear for everybody and who do SSPs apply to? System security plans apply to everyone with cyber security obligations in their defense contracts. Period. End of story. So from the DoD Assessment Methodology document itself, they provide a great overview and summary of how these are required and what they mean. If you haven't watched our Back to basic series on DFARS 7008, 7012 and all the other DFARS cybersecurity provisions and clauses, you should go read them because you should go listen to them because this is going to reference all of them in one, you know, short little paragraph here. So from the DoDAM, they say DFARS provision 2522047008 requires, among other things, that offerors represent they will implement the security requirements. In this SP 800171 in effect at the time the solicitation is issued to document implementation of NIST SP 800171, the contractor must develop, document and periodically update a system security plan that describes the system boundaries, the environments of operation, how the requirements are implemented, and the relationships or connections to other systems. The contractor must have a system security plan in place to Describe each covered contractor information system which has a specific definition. Watch the videos that we did beforehand. Since the NIST SP 800171 dud assessment scoring methodology is based on a review of a system security plan describing how the requirements are met. It is not possible to conduct an assessment if the information is not available. The absence of a system security plan would result in a finding that an assessment could not be completed due to incomplete information and non compliance with DFARS clause 252-204-7012. This is one of the specific violations, these are my words now. This is one of the specific violations that people are getting caught with during False Claims act lawsuits. The settlements for these lawsuits cost millions of dollars for large and small companies alike. And every one of them, the common thread in every one of them is either they don't have an SSP or their SSP is lagging behind what it needs to do. Cannot stress this enough. This is like the core thing underlying all of these obligations. And just, you know, needless to say, beyond that, if you don't have an SSP or if your SSP is at all questionable, you ain't getting the CMMC assessment. You're going to get false started. You're not going to qualify for the assessment, you're not going to achieve the status that you need to. So you're not going to win more DoD work. Very, very, very important document.

B (7:21)

If there's no plan, how are you executing the plan accordingly? Right. So if there's no document that's defining what you're supposed to do or how you're doing it, this is your explanation of your implementation. And if you can't explain it on a piece of paper, how are you going to explain it without.

A (7:37)

Yeah, now there's nothing that says, just very quickly, there's nothing that says an SSP has to be a physical piece of paper. Right? We can automate these things, digitize these things, we can do all this stuff. It doesn't have to be a piece of paper, but traditionally it's going to be documented in some way. A lot of people don't, don't come at us because we're like, oh, it's got to be paper.

B (7:57)

Us pre SSP guys, you know, sometimes we're a customer.

A (8:00)

Paper work on his dinosaur back before SSPs. Yeah, they had to write it down on, on scrolls or something. Anyway, you are correct, right? We're going to talk about what the word system means and what the word plan means to sort of outline the idea of SSPs and then we'll get into how they look, you know, what they specifically look like in the world of 800 171, DFAR, CMC. So what are system security plans? So system security plans in the world of DFARs, cybersecurity and CMMC are very narrow compared to the system security plans that were designed to be part of a much larger federal context which we currently would label under the umbrella of the Risk Management Framework. So this is a conversation for another day, but the long and short of it is CMMC is a version of the risk management framework. FedRAMP is a version of the Risk Management Framework. These are big contextual ideas of what the SSP is supposed to be operating inside of. This narrowing of system security plans means that for most people today, most people listening to this podcast, most defense contractors dealing with CMMC and DFAR 7012, these narrow SSPs are more like assessment outlines based on NIST SP 800 171A rather than these like broad living summary executive summary documents that they were originally intended to be. We just had a conversation with Fernando Machado after his company, a authorized C3PO finished 25 CMMC level 2 assessments and he said that the number one green flag that indicates you're probably going to do fine in your assessment is having an SSP that describes all of the items in SP 800 171A. Nowhere in the history of SSPs in the 853 RMF world do they say that they need to be specifically outlined to the assessment criteria in 853A. That's just not what they were designed to do. But that's the way that they've evolved and sort of, that's the way they kind of work now in the non federal space. Is this a good thing? Is this a bad thing? I don't really know if you can label them that way. That's just the way that it's played playing out. So.

B (10:30)

So I think it's more simplified for the purpose. Right, because like in that case, like writing one specifically to the assessment outline I think makes it a little bit more easier to execute for 100 everyday person.

A (10:42)

It definitely makes it easier to execute as a part of control assessments, but it's we're going to get into this idea of what were they originally designed to be and then how they're actually playing out. Doesn't mean that you got to change it doesn't mean that that's not a perfectly fine way of using them. We're just Trying to broaden everyone's understanding of what they were originally designed to do and then how they're working now. Okay, so let's talk about the theory, the intention of system security plans in this federal context. This will inform our understanding of SSPs in the non federal DFARS defense contractor CMMC context. It'll help us put in better comments for SB818. So from 853. I know, I know. I don't have to do 853. I have to do 8 under 171. 171 is derived from 853. If you want a better understanding of what's in 171, you got to read 853. So allow me to read some of my Favorite excerpts from 853 to you right now.

B (11:43)

If, if I. If we can. Right.

A (11:45)

Yeah, I believe this is from Rev3. I just like the way that it's worded. So they say security plans. Yeah, security plans. Security plans relate security requirements to a set of security controls and control enhancements. Security plans describe at a high level how the controls meet security requirements, but they do not provide detailed technical descriptions of the specific design or implementation of those controls and enhancements. Which is a little ironic because that's exactly what people want their SSPs to do these days. It's not what NIST thought they would be doing back in the day. They go on to say security plans contain sufficient information, including specification of organizationally defined parameters or ODPs, to enable a design and implementation that is unambiguously compliant with the intent of the plans and and subsequent determinations of risk to organizational operations, assets, individuals, other organizations, and the nation if the plan is implemented as intended. The security plans for individual information systems and the Organization Wide Information Security Program Plan provide complete coverage for all security controls employed in organizations. So if you hated SSPs, boy do I have good news for you. SSPs are designed to work with an entirely separate document, the Organization Wide Information Security Program Plan. Now, you don't have to have an information Security program plan for 171 DFAR CMC. You don't need to have any of that. I'm telling you this because it will help you understand the context that an SSP was designed to work in. System security plans are not only what you're planning to do, but they're also for individual systems. They are not designed to outline your entire information security program. And so this becomes a big problem if you have a very, very narrow set of requirements like 800, 171 then you have a very, very narrow idea of an SSP and you don't have an existing information security program and you try to reverse engineer a security program from this document, then it's going to seem very constrained, it's going to seem very narrow, it's going to seem like it isn't really working. And that's because it wasn't designed to work that direction. So just so you know, these were designed to work in the context of much larger organizational programs. They weren't designed to necessarily be the starting point for building a program. That doesn't mean you can't do it. It just means that a lot of people are looking for guidance on SSPs and you can't find it because it's not what NIST originally intended them to do.

B (14:43)

One, one thing that you triggered in that description right there was they're supposed to contain defined values. I wanted to ask you a question. In some of my experience, in federal experience, I would see some system security plans that would have a table of defined values where the lead in before the system security plan was this table that says account lockout, threshold, five attempts, whatever, blah, blah, and it would just lay it out in there. And then in wording obviously throughout the system security plan. Have you seen that?

A (15:11)

Yeah. I mean you can. This is another theme that we're going to talk about here. There are no specified formats for what an asset.

B (15:18)

That's what I wanted you to say.

A (15:19)

It can look like whatever you want. You can, you can put tables, you can put charts, you could do drawing and crayon. There is no specific format requirement. So that's why we're sort of seeing this evolution of SSPs in the CMMC space. The formatting is following the formatting of 171A. There is no defined formatting. That's just the way that the ecosystem has moved.

B (15:44)

So I, I don't want to throw you off your flow, but it kind of leads into my next question. That's exactly what I wanted you to say. Because one of the things that we're, you know, like there's no template available. NIST doesn't give a template. Right. That's one of the things.

A (15:55)

Right.

B (15:56)

Is there some traction to the comment that NIST isn't prescriptive and they don't tell you how to define your system and then when it comes to. That's why there's a. Of a sample.

A (16:05)

Yeah, you have an information security program because you are a rational, self interested organization concerned with cyber Security risk. So of course you have a program, of course you have a plan. You would of course have the governance over your own systems and your own data, especially if you have external requirements. NIST doesn't know what those are. There's too many of them to have that kind of context. They're just going to tell you what this thing should do in order to kind of standardize the approach. They're not going to give you a specific outline and template. That's all great and dandy for federal agencies and large organizations that have that stuff. It totally falls apart whenever you throw it into the non federal environments where companies don't have that stuff either on purpose or because they're too small or for whatever reason. And then we're left trying to reverse engineer this program and plan and outline from the thing that wasn't designed to do that. So let's just talk about these constraints on what an SSP is very quickly. There's, there's two of them. I want to highlight the idea that this is for an individual system rather than for a program and the fact that this is a plan, which I know sounds overly simple. So system security plan. So from 853 security plans, security assessment reports and plans of action and milestones, these three things are used by authorizing officials to make risk based decisions in the security authorization process for their information systems. This is the general description of how things work in the federal space these days. We would call that the RMF process. It's been called ditzcap, it's been called diacap. It's existed before fisma, it's existed after fisma. That's the general idea is that the plan for the system, the security assessment report for the system, and then the document outlining what wasn't implemented and when that will be done, get filtered up to whoever's in charge of this thing to make a decision. Can this system operate? Can it process sensitive data? Can it be connected to other systems? And yes or no, you're making a risk based decision based off of these documents. So you have a plan for what you're going to do. You implement the plan. Did you actually implement everything? Yes. No, maybe. So you filter all that up to the boss and they say, yep, sounds good. Connect. No, doesn't sound good. Go back and fix it. Right. So they say that by accepting the security plan authorizing officials agree to the security controls proposed and to meet the requirements for their organization and system. So there's some sort of authorizing official, there's some sort of decision maker in the context of this federal space and they're getting a plan from their folks and they say, yeah, sounds great, go implement this thing. Right. Obviously this seems a little bureaucratic, but that's the context that it was designed for. You don't have an authorizing official by that title in your organization, most likely, and you're not required to have that title with the way that 171 is written. But this is the context that SSPs were designed to operate in. So like we talked about, this is a plan. There are security controls that you are planning to implement. This implies that there's some sort of decision making context that exists before implementation. There's some sort of decision making contest context that exists before the system exists before the system is authorized, as the system is being designed and engineered and created and implemented. Right. All this stuff happens before that goes live. Right?

B (19:55)

Yeah. So you're providing the framework as to what we're going to do and then when it gets validated, they're validating that. That is what you have done. It is, case in point, cut and dry.

A (20:03)

Sounds like a good plan. According to my risk. Go ahead and do it. How did you do? You got pretty close. That's fine with me. Go off and do your thing or you missed the mark by too big of a degree. Don't do that anymore.

B (20:16)

So in the context here it would be this is your plan to protect cui. I think this is a great plan to protect cui. We've implemented this plan to protect cui. Now somebody from the ecosystem is going to validate that you've protected cui.

A (20:27)

Yeah, yeah. And, and we'll talk about in a little while, you know, how the assumptions around how non federal orgs operate or operated got NIST into trouble around SSPs. But. Assumptions, you say assumptions? Yeah. So, you know, just to remind everybody, you know, this context that we're talking about sounds bureaucratic, sounds contrived. It goes way, way back. Right. The Computer security Act of 1987, specifically in the said that federal organizations need security plans. They said the purpose of this act, one of the handful of things that was designed to do, is to require the establishment of security plans by all operators of federal computer systems that contain sensitive information that was in the act itself. And then from there, OMB circular A130, which if you've ever taken your CISSP, you've heard all about that document, specifically requires SSPs as a result, and it has required them as a result since the 1980s. So just to Reiterate, Federal systems were already online. Federal agencies had budgets, they had decision makers, they had autonomy over their risk making decisions. It's just that these things weren't standardized. There was just very loose guidance out there from NIST. Computer Security Act 1987 comes along, OMB A130 comes along, FISMA comes along, and these things crystallize and crystallize and get tighter and tighter into more and more of a standardized form until eventually we have what we have today, the RMF approach to what's going on. So the steps of this risk management framework have basically been the same since long before this was called the rmf. You categorize your system and your data, which is essentially, how sensitive is this stuff? To what degree do we need to protect these systems? Is it classified, unclassified, sensitive, not sensitive? Is it regulated? Not regulated, blah, blah, blah. Is this our company's internal ip? Is this very sensitive pii? You know, there's all kinds of things that would factor into how sensitive is this information? How much of an impact would it had if it were compromised? Right, so we would categorize the system. Then, okay, we know how sensitive this stuff is. What are we going to do to protect it? We either have specific requirements we have to meet, or we just have general risk that we need to address. So we need to select security controls that would address those things. The standardized catalog of 853 is this huge library of controls that you can pick from, but they're unfinished. They're in their raw form. They have to be tailored to your specific context, which is the next step. You tailor them in, you tailor them out, you tailor out certain parts of them, you fill in all the organizationally defined parameters, you scope the system, so on and so forth. And then after all this stuff is done, categorization, selection, tailoring, scoping, you document all that stuff in the plan for the system that you're doing all this for. Right? What's the plan here? Like, what are we going to do? Are we just going to, like ad hoc? Like we're just going to spend money and implement stuff and nobody knows what the plan is? How do you know when you're done? How do you know when you started? How do you know what progress you're making? You need a plan for this system. Sometimes they talk about, in the history of these SSPs, you're going to document the tailoring decisions. You're going to talk document external connections, you're going to talk about service providers, you're going to talk about compensating controls that you've implemented, because maybe, maybe you can't implement the default controls you found in the catalog. You're going to talk about what they call common or inherited controls for a long time. The description of SSPs, they said in 853 that every single security control that you have documented and put into this plan are going to be identified as either a common control you inherit entirely, a system specific control that you are entirely in charge of, or a hybrid control that you're sharing responsibility for it. Sound familiar everybody? What we hear from Fernando last week is that one of the core, most important documents you can have for success, a shared responsibility matrix, right? Turns out that when you use an MSP to satisfy the vast majority of things that you're responsible for in 800 171, you're responsible for a portion of those requirements, they're responsible for a portion of those requirements. NIST has referred to these as hybrid controls. And your SSP should indicate that, hey, we're responsible for this, they're responsible for that. We're responsible for this part, they're responsible for that part. These days we refer to that as a shared responsibility matrix. It's really just an outgrowth of what an SSP was originally. One thing that an SSP was originally designed to be able to describe. After all this is done, after we've come up with this great plan, risk informed plan, then you go off and you implement the controls. Then we assess whether they've been implemented, then we filter all those documents resulting from that up to the decision maker who makes an authorization decision. And after that's done, we're monitoring the system on a continuous basis. And around and around we go. The circle of life that we now call the rmf. You call it whatever you want to. The steps are generally always the same. So this is a plan, right? System security plans are a plan. That was the original context they were designed to operate in. However.

B (25:58)

Oh, sorry. No, go ahead.

A (26:01)

These are, these are plans, right? So go, go from there.

B (26:05)

No, that's it. That's exactly what you're saying. This is your plan, this is your intent, this is what you're supposed to do. I just had like a lot. I don't know if you saw me like halfway through when you were talking about that. I had this crazy light bulb moment. There's a system security plan, there's an ISP, there's ISP attached to it. What if, like the DoD's SSP for like CUI protection had to deal with the ingestion of multiple ISPs from, I don't know, the supply chain, which is a part of the tailoring decisions. Right. They would have to make their supply chain risk management within 53. Maybe they tailored that. I don't know. That's one of those rabbit holes, remember you were talking about before the episode. You just start talking about this and you're like, holy rabbit hole, Batman. What if it's all there? We're just not talking about it.

A (26:45)

Yeah. So as you, you should start to kind of get an. You should start to get an uneasy feeling. You're exactly right. You should start to get an uneasy feeling as you're listening to this because you're like, okay, it was designed to work in a context of a program that already existed, that was already resource. Right. This is designed to be a plan before, before we start processing sensitive data. We're aware of our external requirements. We have people thinking about this. We have decision makers that are taking responsibility for what's going on. If a little bit of foreshadowing, what happens if there wasn't a plan? What happens if you just started plugging in systems without making decisions like this? What if you start processing regulated data without thinking about the requirements? Then all of a sudden you got to go back to this, you know, very general idea of a plan and reverse engineer your way into compliance, which is super.

B (27:42)

Is that kind of what's happening?

A (27:44)

That's exactly what's happening. That's not what SSPs were designed to do. But that's the problem that we're in. Which is why we need to submit comments to the revision of SP818 being like, hey, so sorry to interrupt your revision cycle here, but could you please teach us how to start from scratch rather than assuming that we already have a well resourced program and place. Okay, just to talk about this other constraint, then we'll get into what they look like specifically in 800 171. So not only are these plans implying that they're supposed to happen before the system starts, but they're system security plans, not program level plans. So SSPs weren't designed to describe your overall information security program, just the plan for an individual system within your organization. So from revision 4 of 853, there is a section titled New Development and Legacy Systems. Please bear with me because I think this is going to explain why the assumptions in 800171 have caused people so much pain over the years. They say documenting in the security plan any significant risk management decisions in the security control selection process is imperative in order for authorizing officials, whoever your decision maker is in your company, to have the necessary information to make credible risk based decisions regarding the authorization of organizational information systems. That makes sense without such information. Without the information in the ssp, the understanding, assumptions and rationale supporting those important risk decisions will in all likelihood not be available when the state of the information systems or environments change and when the original risk decisions are revisited. Or our words here when the government shows up and starts asking questions about the decisions you made to protect their data. If you didn't have this plan in place, then when they show up to ask, hey, what was your plan? You have nothing to tell them. And as we talked about in our episodes on 7800-7012-7019-7020, that's the whole reason why we even have this podcast is because people said they had these plans and it turns out that they didn't. So 853 continues here and they say the security controls included in the security plan for the information system serve as a security specification for the organization and are expected to be incorporated into the system during the development and implementation phases of the system development life cycle. That didn't happen.

B (30:30)

Those are the first few phases of.

A (30:32)

The life that happens before. It happens before. So this is the real, this is the real kicker here.

B (30:36)

Are we benjamin buttoning the the life cycle here? Is that what happened? We're starting at the back end and then going forward.

A (30:42)

So this is the real kicker, right? I think this is the core problem that set up 171 to be the way that it is that set up CMMC to be such a problem for people. Since the information system already exists, the organization in all likelihood has completed the security categorization and security control selection processes resulting in the documentation of previously agreed upon security controls in the security plan and the implementation of those controls within the information system. So we're going way back here to 2021 to a video that I did called the fascinating history of CMMC. And back in 2018, one of the original authors of NIST SP 800171 talked about a really interesting fact of 171 when it was originally published. When 171 was originally published in 2015, system security plans were not an explicit requirement, right? How is that possible? After everything that we've just covered about the fundamental importance of SSPs, how is it that it isn't required in this set of NIST based controls? What it was is they assumed you had one. They categorized the SSP requirement as what's known as an NFO control. We did a whole episode on this. This is the, the twist of the knife for the original design of 171. They assumed that because you already had the CUI. They assumed that because you were already on contract with the government and you already had these obligations, they assumed that because your system already existed and that you were already concerned with your own sensitive information and cybersecurity of your systems, that you would have had a plan, that you would have come up with some idea of categorization of the sensitivity of your systems. Someone would have made an informed decision about protecting the system in this data, especially if you're handling someone else's regulated data with the potential for millions of dollars in fines. Surely you had a plan. Surely you didn't just plug stuff in and just willy nilly decide to do stuff. Right. Gus Cassani said initially system security plans were listed as NFO because you had to have something like that to build your system. Of course you had something like that to build your system. So we didn't want to be bureaucratic and say you have to have an SSP like we do. Then as dfars began to be implemented, we got an endless number of questions about documentation and we found it very difficult to continue to say that you had to have something like that to build your system when it wasn't really explicit in 171. And that's when we got into the trap where we said we've assumed too much. Back in our long conversations with Ron Ross, he even said they acknowledged this was a mistaken assumption. Right. People didn't have a plan when they built these systems. They didn't have a plan before they started processing regulated data. Now you have to have a plan document, otherwise you're not getting a score, you're not getting contracts, you might be getting fined millions of dollars, you might be going to prison. And so we got to take this idea of a general plan, which there are no examples, and then try to extract what it ought to look like after we've already built the system, which is extremely difficult to do coming from.

B (34:22)

Working on federal systems and then coming into the dib and working on these systems. And I've been in the diploma the 7ish years now, right? A little bit over 7. Right. It still surprises me that there's not that plan. So the assumption I get where it's coming from because people that work with these types of systems, it isn't. It's awful. Like to think that there is a system that exists that doesn't have an implementation plan in place. And like you did earlier with the like the cowboy shooting off. That's basically what it was. We're just like we're gonna shoot this can and see if this, this server with a password when it's going to be good enough to protect our cui. And now this is where we are.

A (34:59)

Listen, it is what it is, right? Should you have done it? I don't know. Is it the right thing to do, the wrong thing to do? Not for me to say. It just is the way that it is. You got to have a plan for the system if you're going to be handling the government's data. And everybody said we don't know how to document this stuff. We don't know how to document this stuff. Tell us how to document this stuff. And what answer did we get? We got the government answer of how they document document stuff. And so that's what we're stuck with. That brings us finally to what does 171 actually say? God, get to the point. We have the context of what SSPs are supposed to do. What does 171 actually say? 171 says non federal organizations describe in a system security plan how the security requirements are met or how organizations plan to meet the requirements and address known and anticipated threats. The plan describes the system boundary, the operational environment, how the requirements are implemented. That's the big one. And the relationships with or connections to other systems. That's also a big one because that's where your MSP comes in, right? These can be combined with your poem. There is no specified format. Thanks a lot nist. These people clearly need you to specify a format and give them examples. We don't have examples in 171. Rev 2 requirement 3.12.4 is the one that says document, develop, periodically update these plans. And the only way for you to know what that actually means is as we've said before, to look at NIST SP 800 171A right? This simple sentence that says develop, document, periodically update. A plan that does these things is just a sentence, right? If you really want to make sure that your plan is meeting all the things that it needs to meet, you got to look at 171A. There's items A through H in 171A. Is the plan developed? Does the system boundary show up and is it documented and described? Is the system environment of operation described and documented? Are the security Requirements identified and approved by the designated authority as non applicable are those identified? Right? That's not described in that original sentence. In 171, the method of security requirement implementation is described and documented. The relationship with or connection to other systems. The frequency of updating, you know, is it defined? Is it actually updated as it's defined? Which sort of brings us to this big question. When do we update this thing? Right? We're, we're filling in these blanks. We're outlining it according to 171A. That's all fine. When do we update it? According to the book, you would update the SSP in accordance with your continuous monitoring program. That's the NIST answer, right? Whenever there's a significant change to your system, whenever there's a newly discovered threat, or at least on, you know, whatever the period of, of your definition is for updating this plan. We can get a little more detail on this if we look at the organizationally defined parameters for 800171 Rev 3, because this is why I say ODPs still exist in 171 Rev 2, right? If you look at the end of 171A for SSPs, it says the frequency to update the system security plan is defined. Somewhere you have to specify a parameter for when you're updating and reviewing this plan. That's an ODP, right? So the ODP for Rev3 is much more explicit and they say in their list from the DoD at least every 12 months or when there are significant incidents or significant changes to your risk which are also up for you to define. So that's when you would have to update the plan and you'd have to show we have updated the plan at least, basically at least annually because, you know, significant risks, significant changes are a very open ended definition, I think.

B (39:01)

And then by nature, you know, trying to backpack on your point is that when you're executing some of these things that you have to implement organically, there will be changes that will have to be made to the ssp. So for an organization to sit back and say we have a fully established program that's been implemented to the plan, we're executing all these things, but there's no changes to RSSP in the past 18 months is not realistically an expectation. I do have a question for you though. This whole thing is that there's no specified format, there's no this, it just has to contain this and has to contain that. I think that you share in the same sentiment that in some conversations that we have with people that are either capable of assessing environments or have assessed environments. Maybe a typical line that we have heard is I knew that that system was going to be in bad shape because that SSSP was only nine pages long. So how do you justify that argument when there's no specified format? And it's basically because that's the question. How do you justify it? Yeah, I'm not saying it's the bag.

A (40:02)

You'll hear this a lot when you talk to C3POs and they go, these people said they want an assessment and they handed me a four page document and said this is our system security plan. There is no specified format, minimum length or any of that. But it's one of those things where people are like, they know it when they see it, right? Like they know this isn't sufficient. It's just a random template. Think about all that stuff we just talked about forever in this episode. All the context, all the meaning, all the decisions, all the pre implementation theory about what needs to happen here is supposed to be represented by this ssp. At the very least it has to have a description of how you have satisfied the 110 requirements. In 171 there's 320 criteria to prove that that's true. And so you're probably not going to have an adequate description for all 320 of those criteria in just like two or three pages. Right? So just the sniff test doesn't really work. But to your point in the description under 171, I mean what 171 says is pretty cut and dry. It's like have this plan that describes these things. Here's all the criteria that you need to meet in order to say my SSP is good. Right. But as they, you know, don't talk about, you have to describe the implementation for all of your requirements. That's only one part of what they originally intended an SSP to be. That has become the main part of what SSPs are actually doing in the context of DFARs and CMMC. That's the part that if you look on the templates that NIST does provide, there's nothing there. Right. So in the description of 171 they say there's no prescribed format or specified level of detail for system security plans. Okay, great. So it's the single most important thing that's ever been a part of all of this context around federal cybersecurity and now non federal cybersecurity compliance. And there's not a single freaking Example, there's no specified format for any of it at all. We're off to a great start. Part. Right. They say, however, organizations ensure that the required information in 3.12.4 is conveyed in those plans. Great. They go on to say that the NIST SP800171 web page provides supplemental material for SP800171, including templates for system security plans. I'm going to tell you right now, I'm going to tell you right now. If you have not looked at the SSP template on the 171 website and you go there as we're talking, you're going to be upset. Right? You're going to be upset. It's going to ruin your day because it is not helpful. It tells you the outline of these general things that needs to be in the, in the document. Wonderful. And then it goes to the descriptions of how you have met the requirements. And there's nothing there. It's blank. Right. I am going to get on a soapbox for a second. This. For the love of God. Right. You at a minimum have been requiring a standardized format for SSPs for 20 years. The entire federal government, every single information system for 20 years in the federal government has had an SSP that inside of it includes the descriptions of how standardized security controls have been implemented. I do not accept the idea that you cannot provide us with a generic example of what that looks like. It is absurd that there are not available examples of what's going on. And I do not accept this idea that we've heard from NIST in the past that if they provide an example, people will latch on to that example and that's the only thing they're going to do. When you don't provide examples, people don't do it. Right. You have to give people example examples of what these things look like. Please, I'm begging you. I know that they exist. You can redact them. You can make them generic. You can do this. You need to do this.

B (44:12)

Yeah, I just was raising my hand in the middle of that testimony for me, just plus one to, to that dinner party, please.

A (44:21)

They even say it in the description in 800171 that NIST Special Publication 818, quote, provides guidance on developing security plans. No, it doesn't. No, it doesn't. I'm gonna say this. When they hadn't updated it since 2006, I was like, they ain't updating it. They're just putting the reference in there to say that it exists. But as it Just so happens as we're having this conversation, NIST is right now in the revision cycle for SP818 revision 2. I hope you have been listening all the way to the end of this episode. Please, please, if you want SSPs to be less painful, if you want SSPs for the first time in decades to actually have some kind of meaning besides just academic theory of what they ought to kind of sort of look like, you must submit comments to NIST by July 30th of 2025. That said, this is all great, blah blah blah. Give us examples of how control implementation descriptions should look. What have they looked like historically? What have they looked like for different kinds of systems, different kinds of technologies, different contexts, large, small, this, that federal, non federal. I know that they have access to this information. It would be extremely helpful. We will provide links to SB818 revision one, which is the current guidance, and revision two, which is the draft guidance. Please, please. If you've gotten anything from this podcast over the years, if you've extracted any value from the stuff that we've said, the explanations that we've done, I am now asking you for a favor outside of liking and subscribing. Submit comments to NIST saying give us examples of control implementation descriptions. They even say in 818 revision 2, the current draft, that this is supposed to be used, among other things, for people needing to comply with 800 171. It is the one thing that I think would be a massive benefit to the ecosystem to all the people that need to comply with 171. It would be a huge jump forward in our collective understanding of SSPs in non federal systems and federal systems. I cannot, I'm begging you, I'm literally begging you listening to this podcast. Submit comments to NIST on 818 revision 2 asking for implementation examples.

B (46:54)

Yeah, and just the other thing, the benefit that it would offer is imagine how much easier, how much smoother assessment processes would be if the document that basically is the first, you know, document that your C3PO reads from your organization as they submit it is a universally formatted document that kind of has the same gist. Instead of digging through different areas of whatever somebody's interpretation of an SSP is to make sure that they've implemented things now, you know, there should be that their freedom there. But at least if it's universal in some instance and there's an understanding, then we can say, yeah, your implementation statement isn't as broad and wide open and I have to interfere that as you've implemented it.

A (47:31)

Yeah. Now I'm not guaranteeing that this is going to work, right? Because special publications are governed by committees and they like to not be specific. And a lot of people say don't be too prescriptive. This is an example where we need them to be prescriptive. We need the prescriptive examples. Right? Please. We need a handhold. People need to know where to start. Because currently the way that it works is if you want to know what a good SSP looks like, you're going to have to pay for it. It, you're going to have to hire a consultant to help you. You're going to have to spend a ton of time trying to figure it out. You're going to have to work with people who can do it with you, do it for you. You're going to have to buy templates, you're going to have to spend time and money. NIST resources are free, but they only work if they have the information in there that you need. And so this is a massive, massive opportunity. I know that this podcast is longer than our recent podcasts, but I hope it's been helpful, right? The idea and theory of what an SSP should be, what SSPs have actually turned into for most people, and the fact that there's no guidance to help you through that process. But there potentially is. If we can all come together around the campfire and ask NIST for this one thing. In the new revision of SP818, I.

B (48:45)

Think the single most important document for every organization to know as much as they can about it deserves a little, a little bit extra time on the episode meter there, Jacob.

A (48:53)

Call me crazy, man. Call me crazy.

B (48:55)

I've called you crazy multiple times.

A (48:56)

There you go. Clearly, you know, almost an hour talking about SSPs. It's fine. It's a fascinating topic, right? When people were like, hey, could you talk about SSPs? I was like, oh yeah, easy boy. Was I wrong, right? We're always learning new things. I mean this is a, this is a world that has been evolving for decades. So what you think is a simple concept turns into a multi day rabbit hole of preparation to get through a long rant comes down to this. You got to have this document. There are no examples of the document. If you don't have the document, you're screwed. And currently the only people who could tell you what that document should look like for free are asking for your comments. So please submit your comments. We'll add the link below, let us know if this was helpful. Do you want another deep dive, different aspects of SSPs, so on and so forth. What have you seen with your SSPs? Do you know of a template that doesn't suck, that actually has information? It let us know because I haven't seen one and I would love to see some examples out of just what I've seen in my own experience. And then we'll go from there. So we'll see you next week.

B (50:02)

See you next week, folks. Sam.