Responsible for Protecting CUI? Learn About Updated NIST Guidance

Very excited to bring to a hot topic across the security profession, which is CUI. Controlled and classified information has been around bantered about in policy for a long time. We’re going to get to a little bit more of that, but newly released kind of guidelines and frameworks, give more clarity, especially around the IT side of what CUI is, how to frame it, and very important for companies across the intelligence community, national security space, even companies who aren’t in that space. How do we protect all this information that we have access to? So very excited to have Victoria Pillitteri, who is the manager of the security engineering and risk management group at the National Institutes of Standard and Technology. Thank you so much, Victoria, for being on the show today.

Thank you so much for having me.

We’re talking about controlled unclassified information. I kind of want to start at the baseline folks. If they’re listening to a security clearance and security podcast, maybe they’ve heard of CUI in some capacity. I know it existed in executive order since 2010. Can you kind of give the genesis origin story, CUI born into being executive order and then now where we are at today and the policy changes related to CUI?

Absolutely. CUI, first and foremost is controlled unclassified information. It’s unclassified information that requires protection as identified in law regulation or some kind of government-wide policy. And the primary role in that is the National Archives and Records Administration. So through that executive order and law that you mentioned, it gave NARA responsibilities as the executive agent and their information security office. The IU is the organization within NARA that implements it. So obviously I can’t speak on behalf of another federal agency, but NARA is the organization that identifies what CUI is on behalf of the US government.

And then within that, so this nist, the framework and policies that you create, what exactly are you governing within this CUI ecosystem?

Well, NIST’s role is unique because we develop the standards and guidelines that are used by both federal agencies and voluntarily by the private sector. We like to describe NIST as aggressively. So we are just the scientists and engineers that do the research and develop the standards and guidelines. We have no role in enforcement, we have no role in implementation. So you know that NIST is really working on giving you the best technical advice without policing anything on the other side.

Okay. So talk a little bit about that technical advice. I know again, you’ve released some things. Who should be reading that? Who should be flagging those reports and updates that come out and what kind of information should they come to NIST for?

Well, in the world of CUI, the NIST has developed a set of security requirements to protect CUI for both federal agencies and non-federal organizations. So really anyone that’s in the whole federal ecosystem should be paying attention through the federal acquisition regulation for the civilian agencies and the defense Federal acquisition regulation supplement, the DFARS for the DOD, basically anyone that does business with the US government and is storing, transmitting or processing this CUI needs to protect it at a minimum level of moderate confidentiality. And NIST sets those standards or requirements or those guidelines, call it what you will for that set of requirements to protect.

I get to host these shows because I am going to ask the dumb questions. So when it comes to CI, if somebody’s listening to this, well, how do I know if I have CUI? Is there ambiguity there in terms of folks knowing what they need to protect or maybe having, because again, when you have these new policies, well what if I have IT systems or things, how do I know what is actually CUI within the ecosystem of what I’m protecting?

So there are no such things as stupid questions. This is actually one of the common questions that gets turned over to nist, but it’s up to the federal agency if you’re a non-federal organization to mark that CUI and let you know that you have CUI and it needs to be protected.

And so then that kind of ties into the markup and things like that. So NIST, your typical kind of the IT framework that’s not marking up the documentation, but DCSA and other agencies obviously and federal agencies have a role to play in that. I know DCSA has this critical function on their side for when it comes to working across the defense industrial base on their CUI programs. Does NIST work with DCSA or other agencies or is there partnering that’s at play there?

Formally and informally, we do work across all of the USG. Our role, again, is very scoped. We don’t oversee other agencies. We don’t tell agencies how they need to implement the requirements or evaluate them on the other side. And we definitely don’t do that for private sector, but we develop these standards and guidelines. We issue them as part of our development process. We work with all stakeholders, whether you are a small company of one or two people to a large federal agency such as DOD, to make sure that we hear the feedback that we get from our multiple drafts that we issue before we go final. We do a lot of engagement. We do one-on-ones, we do conferences, we do speaking engagements. We work with both staff and leadership to make sure that folks understand the intent of our security requirements, the intent of our guidance, and hear that feedback and incorporate it in as appropriate for the scope to make sure whatever we issue equally makes everyone upset, but ultimately is the best set of guidance that we can provide at the time. Now in this world of cybersecurity, we know the only constant is change. So just because we issued something a year ago, two years ago doesn’t mean that with the constant change in the threat landscape, the constant change in risks. This is why NIST guidance continues to evolve and we will periodically or frequently update the suite of guidelines to really address what’s out there today. Yeah,

Can you maybe talk about that process because I think it was sometime last year that the draft guidance was released and then what we saw released last week was the kind of finalized guidance on that. So what is that implementation guidance and then maybe if we can speak to even moving forward, what could future iterations look like? How frequently are you reevaluating what you’ve already released to see if it needs to be updated?

Well, absolutely, that’s perfect timing. So just earlier in May, the middle of May, we issued special publication 801 71 revision three, the CUI security requirements, and its corresponding assessment procedures 801 71 alpha. The alpha is for assessment rev three to update and refresh that set of foundational security requirements and assessment procedures for protecting CUI. In addition to the publications that we’ve always published as PDF documents, for those who like to print out their documents, we also issued data sets that allow users to access both the requirements, the assessment procedures through their browser, download different data formats such as Excel and JSON, and we release some supplemental materials to help implementers. One is FAQ that includes a lot of these foundational 1 0 1 questions of why did N do this or what are the major changes and how does this apply to me? So we released that FAQ, we released an analysis of changes between the old iteration, the previous iteration of these publications and the updated ones, and we also released a CUI overlay, which shows the relationship between these security requirements and the foundational publications that they are based on. If you’re a federal agency or you’re a contractor that’s using a different NIST publication, special publication 853, our security and privacy controls, you can already see that direct traceability between what you got there and how you could implement 1 71. Similarly with the analysis of changes, if you’re using the previous iteration REV two, you can see requirement by requirement the differences. We basically outlined and highlighted the major changes. So you can see where you are now versus where NIST is going with these security requirements. And the good news is you’re most of the way there,

Hey, that is good news. That’s important news. I think what we’re hearing a lot of is see why starting to show up in contract requirements for contractors. So this guidance is important and important timing because contractors are saying, Hey, we want to be compliant here. And can you also maybe speak to that because I know we get a ton of questions around both CUI and CMMC because of those implementations. So how are those two terms maybe related or how are they not related when it comes to what you’re doing? Well,

The CMMC, the Cybersecurity Maturity Model certification is from the Department of Defense. I would obviously go to them for their on the record official position, but ultimately, DOD stood up this program because they wanted to have a model to evaluate the defense industrial base when the DIB is processing, storing or transmitting DODs, CUI, and I think DOD calls it controlled technical information or controlled defense information, but ultimately it’s just their CUI. The CMMC is based on special publication 801 71 rev two, so the previous iteration of 1 71 is what CMMC is based on.

Okay. When it comes to the CUI/CMMC, all these terms, we’re seeing, again, a lot of chatter coming from industry because they’re starting to see requirements related to some of these technical requirements in their contracts. When it comes to industry and government processes, procedures are those requirements the same are the resources the government provides to help with industry compliance for CUI.

They’re very similar in federal agencies. We use the foundational publication on which 171 is based, so we use special publication 853, the security and privacy controls. The main difference between 853, those security and privacy controls, and the 171 security requirements are the 53 controls address confidentiality, integrity, and availability. The 171 security requirements were tailored down to really focus on confidentiality at the moderate impact level, which is the requirement for how CUI must be protected, hypothetically, federal agencies are going above and beyond just the 171 requirements because they’re addressing federal specific requirements. They’re addressing integrity and availability requirements related to the source controls.

It’s so interesting. Again, I always love these interviews because they have these hot topics that I know kind of from lane or one avenue, and then my wheels start to churn as we talk. I find the push for CUI super interesting. Obviously it’s kind of stressful anytime you have new requirements, people are like, oh, what does this entail? It mirrors kind of the broader personnel vetting, which we cover a lot more at ClearanceJobs,  where they’re starting to say, ‘Hey, how can we roll out continuous vetting across the entire trusted workforce,’ which over the coming year is going to include the public trust population. I don’t know if you would support this correlation, but I feel like CUI is like the public trust population related to classified information, right? Because classified is classified. CUI is unclassified. It’s kind of the same with a clearance. A clearance is a clearance. A public trust is not a clearance, but we kind of have these tiers that we’re trying to protect more information, knowing our adversaries are really searching for that information and protecting just the classified piece of it is simply not enough to get the right security posture. Throwing a crazy idea at you, but does that kind of make sense in terms of framing it, what the CUI is looking to accomplish?

Yeah, that’s a great analogy. Basically, you’re building up, right? You got to start somewhere and every piece of information has value. So we just need to make sure that we’re protecting it commensurate to the risk, right? And again, unclassified information probably poses less risk than classified information.

Can I speak to that? So CUI is more than just, I mean we have this broad term, but within that there’s scope and scale and all of that. So does the framework kind of address that within CUI? Some of those different elements?

In general, the different types of information and how the specifics of how individual types of information are protected is a responsibility. So examples of CUI could include privacy information, tax information, law enforcement, critical infrastructure, financial procurement, and acquisition. So it really spans the gambit. So it’s my understanding that specific types of CUI might have their own safeguarding requirements, but broadly the 171 security requirements apply broadly to all types of CUI.

And when it comes to this implementation guidance and releasing it and providing information to stakeholders, are there any key takeaways, things that we didn’t talk about today, but things you would want folks to know about this implementation guidance? Who should be reading it right now to end next steps on this CUI journey?

We’re really excited that we’ve issued this revision to the Protecting CUI series. These updated security requirements really are kind of the most modern and the most up to date, but like I said earlier, the only constant is change. So we are prepared to continue updating our portfolio to make sure that the entire series is ready to go. So most recently, we issued REV 3 of the security requirements and REV 3 of the assessment procedures and all the supplemental materials. This is for anyone that is doing business with the government that has controlled unclassified information. What’s next for us is we’re going to update the set of enhanced security requirements, 801 72 and 1 72 alpha, and we’ll go through this entire public comment and public engagement process again to make sure that we both bring the security requirements up to code up the latest version of 853 that we meet any new and emerging risks, threats and vulnerabilities, and we provide this to all of the stakeholders that are using CUI or want to be doing business with the government because it’s just necessary to protect the information at this level.

No, I think that’s useful, and I think that feedback loop is something we are seeing more and more. It used to be a lot of government policies were just always pushed out and it was like, here it is. But I think that feedback loop in mechanisms, we’re hearing more from industry that’s really important to them, and I’m hearing a lot more of that when it comes to topics like CUI and CMMC. So maybe can you speak to that? What does that public comment look like? How does industry chime into that? Are you having regular conversations with industry about some of these things that you’re releasing?

Absolutely. So this is something that is so foundational to the entire NIST process of how we do our research, develop drafts, engage with our stakeholders before we go final. We don’t issue guidance like this just overnight, willy-nilly. We want to make sure that we’re addressing a specific need. We understand the constraints, the requirements, the needs of our stakeholders, both the federal agencies that need these requirements and the non-federal organizations that have to implement them. Now, of course, obviously not everyone’s going to get everything that they want because there is still a specific scope and mission, but at the end of the day, we really want to balance what is that set of universal requirements that can apply to all that will adequately protect the information or the systems or whatever the scope is at that appropriate level. As part of this process, we did a pre-draft call for comments.

(16:59)
So before we even began the update, we reached out to folks and we were like, tell us what you like, what you don’t like, what’s working well, what’s not working well with these NIST publications? Because we really want to understand what those constraints are operationally and in the real world. Taking that feedback in written form as well as through our informal engagements, we developed the initial public draft. We put it out there for the world. Tell us your feedback on this. And something that’s very unique to NIST is we take everyone’s feedback. Whether you’re a one person organization or you’re as large as the DOD, we read and evaluate each and every comment and adjudicate it to make sure that, is it within scope? Is this something we can fix? How can we address this concern or issue? After we adjudicate all the comments, we generally issue a second public draft because we understand the impact of these publications.

(17:58)
We really want to make sure that folks have a second bite of the apple, because NIST doesn’t always get it right on the first try, and that’s why we really appreciate this public comment process. All of your comments from the user community, make our guidelines better. After the second public draft, we will adjudicate all the comments again, and then we will issue a final. So really this year, year and a half long process is I think very robust. It allows us to do a lot of engagement as we’re drafting and helps us better understand the ecosystem that our standards and guidelines live in.

Awesome. I love that. I love the partnership with industry. I love those feedback loops. So I think if there’s a takeaway here, check out n.gov, see that new implementation guidance, dig into it, and then continue the dialogue and expect more. I do see folks with NIST out and about at industry events. They are getting that feedback, which is fantastic. We appreciate that. And again, see UI all these hot topics that we’re trying to learn more about. There’s at least one place you can go from the IT side to get that CUI feedback over at nist.gov. So thank you so much, Victoria, for taking the time to chat with me today. I really appreciate it.