Root Causes 427: Mapping CLM to NIST CSF 2.0

Hosted by

Fellow

Original broadcast date

October 2, 2024

In this episode we map the contributions of Certificate Lifecycle Management into the new NIST Cybersecurity Framework 2.0.

Podcast transcript

TCTim CallanSo, Jason, we have spoken in the past about CSF 2.0, which is obviously very important. And I think what we want to talk about today is CSF 2.0 and certificate lifecycle management.

Jason SorokoLet's map certificate lifecycle management to NIST cybersecurity framework, 2.0.

TCTim CallanI love it.

Jason SorokoLet's do that. And I think there's a couple angles at which we could take it. The one I want to start with is, if any of you who are familiar with CSF 2.0 about protect and detect and identify. These are the words that you repeat over and over and over again, because this is how NIST is breaking its controls into categories. And I first wanted to show you how certificate lifecycle management actually fits into those categories. So this is more anecdotal, but very strong evidence that certificate lifecycle management and CSF 2.0 are really hand in hand.
So under the protect function, Tim, identity management and access control, Geez, that's kind of a no brainer in that CLM ensures that only authenticated and authorized devices, users and services can access network resources. So think about this as the authentication use case of using certificates. And so therefore certificate lifecycle management is ensuring that not only the life cycle of the cert itself, but also the certificate profile. So in other words, the fundamental, the guts, of all these fancy things you're doing with CSF 2.0, all the controls - think of it almost like a tree, Tim, of technologies, and all the fancy ones you saw at RSA are like the leaves of the tree. All these various controls that you can go off and buy and employ. But what's underneath all of that are going to be credentials and credentials that are being used for the purposes of authentication, strong authentication, And so unless you're using certificate lifecycle to do that, then ultimately the protect function, which is the one that gets the most air time, typically within CSF 2.0, I would say that PKI as a term, but certificate lifecycle management, being a more modern way of thinking about it, is what's truly enabling good protect function in NIST CSF 2.0. Just as a start.
So number two is again from the protect function - data security. So ultimately, the usage of certificates, like, what's a major use case? SSL. The browser to a web server. In other words, from the protect function, data in transit is being protected ultimately by a certificate. And so therefore, certificate lifecycle management is a gigantic enabler of this cybersecurity framework 2.0 basic function. Basic control. When you read CSF 2.0 you don't automatically think certificate lifecycle management, but then you realize, well, the data security part of the protect function in CSF 2.0, if you don't have certificate lifecycle management, you're not employing this. So really, you can cut this part into two pieces. Data in transit. Most data in transit is some sort of TLS-based encryption, and for data that is at rest, you're talking about potentially some sort of life cycle management system of perhaps symmetric keys or other things that you're doing encryption with. But certificates are used in many cases of encryption for data at rest as well. So therefore this entire part of CSF 2.0 maps directly back to CLM.

TCTim CallanSure. I can see that.

Jason SorokoPeople forget Tim that one of the biggest things that you get out of the signing feature of certificates is the ability to detect that data has been messed with. And so therefore people think about, okay, I need to detect. Therefore I need an IDS and IPS, and I need all these detection things. I'm sure if you saw the word detection anywhere at RSA, they're not talking about the cert. But in reality, that's fundamentally what is offering a detection.

TCTim CallanBecause there is a certain fidelity or immutability function that PKI delivers to us. That we know that these things are tamper proof because otherwise they're not going to work.

Jason SorokoThat is correct. The tamper proof nature of what you're getting with encryption.

TCTim CallanIs someone altered a signed document, or if somebody altered a signed blob of code, then the signature wouldn't match, it would fail, and that would be detection of the ruse, the subterfuge.

Jason SorokoAnd you might be thinking, Tim, anybody might be guilty of thinking it's just about a signed contract, a document that's been signed. But it goes beyond that. It's code signing. It's firmware signing for devices.
And I'll go one step further. Remember, those of you who listen to us about encryption, signing and authentication, authentication is really a special case of signing because of the signing of the challenge document. Therefore authentication really is just signing in operation.

TCTim CallanAnd if you think about it that way, you would be possibly detecting an attacker in the middle.

Jason SorokoBingo. Therefore, these are the fundamental tenants of the controls as proposed by NIST in CSF 2.0 and at the heart of it is certificate lifecycle management. So let's do another one that, Tim, and you're gonna like this one, because earlier in the Toronto sessions, we talked about visibility. Well, again, part of the detect function is security continuous monitoring.
So if you are not aware of your certificate profile - maybe you have certs running around that have a SHA-1 hash function - if you're not aware of that weakness, you are in violation of this guidance.

TCTim CallanSo visibility, and that's also then by that line of reasoning, discoverability comes into this too.

Jason SorokoSo, Tim, you've now named two of the pillars of certificate lifecycle management that are fundamental to this guidance.

TCTim CallanBecause if I don't know that my certs or my PKIs are going on, then I can't know what they're doing. And if I can't know what they're doing, I can't know that they're secure.

Jason SorokoLet's move to the next one. This now goes into the identify function of CSF 2.0. Risk assessment and risk management strategy. So, Tim, what happens if your certificate private key is compromised?

TCTim CallanWell, then it could be used to break sessions without your knowledge. Basically the encryption is forfeit.

Jason SorokoTherefore, in order to be able to be mapped fully with CSF 2.0, you need to be managing how your certificates are issued, renewed and revoked.

TCTim CallanSure.

Jason SorokoThat's a direct mapping between CLM and a fundamental piece of CSF 2.0. So this is now part two. Let's move on to what I think is the true heart of CSF 2.0, which is governance. And so policy and process integration, Tim, is a big piece of this, according to CSF 2.0.
So, therefore CLM really plays a really key role here in that from visibility to issuance, to all right, if I have a key compromise that I have detected, then I need, through CSF 2.0 a way to be able to mitigate that compromised. Therefore, if I'm not using CLM, I don't have a quick way to do revocation.

TCTim CallanAnd even also, I would say that policy and process integration, from the perspective of this is what I've decided I will deem to be acceptable for PKI, and this is not, you now have a reliable, repeatable, measurable, viewable method of ensuring that you followed these choices that you made. These policy choices.

Jason SorokoThere you go. That's real governance. And remember, CSF 2.0 is about elevating people who are in the trench, and so the person in the trench using CLM now has a way to elevate themselves into a governance program. So their workday tasks are now measurable tasks within CSF 2.0.
So, Tim, the next one here - accountability and ownership. So following from the process integration into governance, what about accountability and ownership? Who revoked? When did they revoke? When did this get issued?

TCTim CallanWhere did these certs come from? What are these certs I never heard of before, and who's going to ensure that they get renewed?

Jason SorokoTim, it's funny how if we were to ask the average person in our industry, map CLM to CSF 2.0, they’ll go, oh my God, I don't know. And then once you start peeling the onion, it's like, oh God, it's fundamental.

TCTim CallanIt’s all over it, isn’t it?

Jason SorokoIt really is all over. So it doesn't end there. Compliance and legal requirements. Therefore, things like HIPAA, GDPR, think about if you're under those kinds of regulatory environments, I know for a fact, because I've spoken to these people, they're like, encrypt. Just encrypt. Therefore, well, what are you encrypting with sticks and stones? No, it's probably gonna be a cert.

TCTim CallanAnd is that encryption going to be modern? Is that encryption going to be secure and solid? Is it going to be reliable? And how do you know all of that? You set those rules, you govern those rules. They make sure that's the case. You get reports. You confirm. You find outliers. All of that is what CLM does for you.

Jason SorokoSo therefore, oddly enough, if you ever need a value proposition for certificate lifecycle management, you need look no further than NIST cybersecurity framework, 2.0, Tim.

TCTim CallanAnd so let me now get just a little philosophical on this. I think that's really great to look at it point by point and prove that, and I think you proved it very effectively. I also think that an argument could be made that that's not at all surprising, and the reason for that is because PKI is so foundational to all of our digital processes that you ultimately can't make a framework like this that isn't absurd, that doesn't have PKI just everywhere you turn, and so that should be an expected outcome of a properly run process that gives us this document.

Jason SorokoWhat's funny is, we could have done this podcast and labeled it map Zero Trust to CLM. And it wouldn't come too much different.

TCTim CallanIt totally could. Absolutely. For sure.

Jason SorokoAnd so that's a good thing because what it means is that CSF 2.0 Zero Trust network architecture and PKI/certificate lifecycle management are inherently interwoven. And the problem is this and I love the way you put it. PKI in general is so ubiquitous that people just don't think of it. It's just there.

TCTim CallanIt’s what we always run into. It's like water.

Jason SorokoExactly. But when you really think about governance, Tim - let's do proper governance. What that means is visibility to your certs. Do you have processes around your revocation, automated processes around your revocation and all these things around renewals and discovery and formalizing these processes into a governance program? So they're not just some administrator who just knows how to do their job and makes human decisions about risk. No you can codify this. You can codify certificate lifecycle management into risk functions and processes.
And this is really what we're trying to decide here. And you're obviously right in saying, it almost seems obvious once it's said, but since this is the Toronto sessions, we're doing things real polite here. And you said the true part out loud, which is, once you look at it, it's completely obvious that you can't do CSF 2.0 without CLM.

TCTim CallanYou can't. I agree. I think you're right.

Jason SorokoThat's it.

TCTim CallanAll right. Well, thank you, Jason.

Jason SorokoThank you, Tim.

TCTim CallanThis has been Root Causes.

Stay informed with expert insights

Subscribe to Root Causes for engaging discussions on PKI, digital security, and best practices for protecting your organization's critical assets. Don’t miss an episode!