The importance of a strong CMDB to the security of your organization

Sean Dawson: Hello, and welcome to another episode of the Cask Distillery Podcast, where we really go through and unlock the full potential of ServiceNow with expert insights and practical strategies, only here on the Cask Distillery Podcast. And I'm your host, Sean Dawson. 

And it's my pleasure to have Mike Stolp with me, who has 29 years of deploying some of the largest and most complex IT environments in the world. He has a CISSP, he's a creative thinker—and I've worked with him personally—with 20 years of system design experience and is currently the security practice area director here at Cask. And what we're going to be talking about today is the importance of a strong CMDB to the security of your organization.

Thanks, Mike, so much for taking time out of your busy schedule to talk to us here today. Thank you so much. 

Mike Stolp: Absolutely. It's great to be here. 

Sean Dawson: Oh, good. It's going to be a great conversation. And I've got something that I always like to start out for our listeners, watchers, however, they're consuming the podcast, is talk about the basics. And one of the things that I remember being on a call with you and we were talking about CMDB and the way you went through it—it was just eloquent. And I wanted to get your view of that and talk to our listeners/watchers about a high-level overview of CMDB and what that is so people can sit around it and understand it.

Mike Stolp: Absolutely. From a security lens, right? Everybody knows who's familiar with the CMDB, that's basically your central repository for all of the IT assets and capabilities in your organization. But when you take a look at it from a security lens, what it really is is it provides you the core source of information that you can use to figure out from many aspects in terms of how to protect your organization, where your potential risks are, where your potential threats lie, managing those risks, managing those threats. And we can draw—we'll dive down a little bit deeper in each one of those.

But think about this: Think about if you owned a home and you were asked—you wanted to secure that home from anybody trying to break in and keep your family protected and so on, but you didn't know how many doors you had. You weren't quite sure how many windows you had. Maybe you're not even sure how many floors you have or what part of the street you live on. And if you don't have that information, it's impossible to protect what you don't know about. And it's all attached to that house. If you've got an open back door or a window or a side door, you can have the best alarm system in the world. But if those are—if not every entrance and exit point is covered, you've got a problem.

Sean Dawson: That's a good way to put that. Another common thing that comes up when we're talking about CMDB—and it's something that I see gets even more confusing—is how does CSDM play into that? Can you give us a high-level overview of what CSDM is and how that's related? 

Mike Stolp: Absolutely. The CSDM is, it was called the common services data model. And what it does is it provides taxonomy and ontology, right? Those are your five-dollar words for today. The taxonomy is essentially just a definition of when I say “technical service,” what do I mean by that? When I say “platform,” what is a platform? Is it a hardware platform? Is it a software platform? What are the sub platforms? Is it part of that? What is a business service? What is a consumer? What is a provider? What is a platform owner? 

All of those things need taxonomy. We need to define those so we have a common data model so that, across the organization—from IT to cyber security, to the business units—that we fully understand when we say, “This is a defined business service,” that we're always in the same definition, right?

And that way, what that does is that allows us then to basically put those into the correct domains. Currently today, there's five domains within the CSDM, and those domains allow us to categorize and then manage the information that sits within the CMDB. If you think about it, it's a data dictionary, it's a framework, and it's really critical, and it's crucial to how we categorize and identify information.

It's basically information about information, or data about data. 

Sean Dawson: Great. And you actually started leading into this. In conversations that we've had in the past, you've made a good correlation between the difference of data and information. The CMDB is basically data. But what would you say the difference is between data and the information?

Mike Stolp: That's a great point. Data is—think about it like this: Is from a—if you take a look at any metropolitan area, it's just a list of addresses when you get right down to it, right? How do you map that out? Okay. It is zip code, street number, apartment or building number. That's just a list of information. You can put it in a spreadsheet. And you can tell a lot of things from that. How many houses do we have? How many people do we have in those houses? Things of that nature. But it doesn't tell you anything. It doesn't give you information about, okay, what are the kinds of people that live there? What are the different kinds of communities? Are the houses big or small? Are they single-family units? Are they multiple-family units? 

And if you take a look at that and you apply that same concept to an IT landscape, essentially, you can have a list of IP addresses. You can have a list of, okay, we've got 9,000 servers. We've got 2,200 endpoints, laptops, desktops, so on. That's just a list of data. What the CSC or the CMDB does is it contains that information. And that's a lot of data, but it doesn't tell you anything about, okay, how many patches do I need to have? What what's been out of service? Where am I at in their life cycles? Where are my vulnerabilities are? Where are my threats are? 

With a good CMDB, which is data, you can then use that in a different tool sets within the ServiceNow platform to begin to extrapolate and say, “What information do I need to know?” “How many systems do I have that make a critical business system?” “How many servers, right? Are they mid-tier servers? Are they database servers? Are they on-prem or off-prem?” All of these things, again, with the right data, you can pull that and turn it into information. And then what you're able to do is you can act on that information. 

Acting on data is actually very difficult. We have to turn that into something we can actually use. A list of addresses in your city doesn't give you a whole lot other than a list of addresses. A list of assets in a CMDB? That just tells you that you have a lot of stuff in your CMDB. But what it doesn't do is it does not give you the information.

Now, you couple a good CMDB with a good platform that can consume that CMDB information? Guess what? That CMDB data gives you that information. And then you can start making decisions. What are my critical risks? Vulnerabilities? How do I manage them? And so on. 

Sean Dawson: That's great. Cause one of my hopes for this was leaders look at this. And, sometimes, looking at, going in, and updating or even building out your CMDB can be costly. And they don't get why you need it, and they don't understand that big picture. You're going to get so much value out of it when it's there. And moving down the line throughout the roadmap of future things, it gives you so much flexibility down the line. I love that. Thank you. 

How can an organization be sure that they have the data into the CMDB in the first place? 

Mike Stolp: One of the things you can do is you can use different sources of authority of information. You think about an IT landscape. You've got endpoints. You've got virtual platforms, right? We'll call them servers. At this point, we've got virtual appliances. You've got ingress and egress points. Each one of those will have a different source of authority. 

Just take a look at, for instance, all of your endpoints, right? One of the—in fact, we've had organizations actually go back to finance because you—think about it: Finance knows whether they understand the data or not. No knock on finance people, of course, is they can tell you how much money you spent on endpoints. How many laptops did this company or organization buy in the last two years? Okay, you take that list and then you say, “How many can I actually see? Where are they? Do I have all of them accounted for? Do I have more laptops, or do I have more endpoints connected to my environment than we've actually purchased?” That's even the worst answer, right? How many of those endpoints do you not even know about, or you didn't—you don't even know.

That is, that's the kind of thing where you say, “Okay, find the authoritative source. How many should we have?” And then you have to go to your environment and say, “Okay, how many do we have?” 

Now there's different ways to balance those two. You can use different scanning tools. You can use vulnerability management scanning tools. You can use different network scanning tools. You can also, obviously, use ServiceNow's discovery capability. You instrument that, and that thing works fantastic. It finds—it flips over all the rocks and looks under the couch cushions and all that, and it'll find what you have.

Again, authoritative sources. Balance that against your actual scans of what you find, and then see if there's a delta, and there typically is. 

Sean Dawson: When we think of CMDB, I want to also make sure we're sharing the breadth. What does the CMDB touch in the ServiceNow environment? What are all the things that it tentacles out to?

Mike Stolp: Essentially, the CMDB really is the engine of the ServiceNow platform, right? The CMDB contains all of that data about an IT environment. And it's not just hardware and software. It's a definition of business services, right? It's, basically, it's made of what's called configuration items. These configuration items can be physical, they can be logical, and conceptual. In addition to that, the CMDB also contains information about other aspects of your environment, such as your organizational structure, right? Which is—can come under an entity kind of a structure, which is part of the CMDB.

In addition to that, it has business services. It has financial information. All of that, if you think about what a very rich, robust, amateur CMDB holds, it's more than a list of stuff you own or have. It is really a broken down—when I say “broken down,” it's a really highly logical, highly disciplined set of data about your organization that, through multiple lenses—including security—you can manage your organization through that set of data in the CMDB.

Sean Dawson: We've talked about what CMDB is, how CSDM is related to it, how do you make sure you're grabbing all the stuff that needs to come into it. But what are the challenges that you see that are associated with implementing and maintaining a CMDB? 

Mike Stolp: First and foremost, there's really two fundamental challenges. One is getting the right executive sponsorship, right? Having someone at a high enough level buy into the idea that it's critical. It takes a level of effort. Sometimes it's a level of effort that's quite uncomfortable for most organizations, especially if you're starting from scratch. It just takes some time. It doesn't mean it's impossible. We have done implementations for worldwide, very, very large organizations, right? Financial institutions that operate all around the world and so on. We've seen this scale out to massive scales. That's the first challenge is just getting the organization at an executive level to buy into it.

The second challenge is putting a governance and ownership structure. Think about this: Is the CMDB is the central repository for all of the data about core data about you/your organization. The individuals or the team that owns your endpoints is almost always different than the team that owns your networking, that owns—which is different from the team that owns your third-party resources, which is different from the team that owns AWS or Azure or all of those. And you need to assign ownership of that information in the CMDB. No one—no single individual or even team of individuals—can be the authoritative source owner or data owner for all these different kinds of data. It has to be what we call a federated data ownership model. Yes, that means that other parts of the organization are going to have to get involved, and, obviously, everybody really oversubscribed, but in order to make it work, you establish that. 

Once you establish that, it absolutely becomes the source of authority for the organization as a whole—if you want to find out how many of whatever it is that you have, where it is, what it's doing, how old it is, what's its security posture, what it's costing you, what its risks are. If you have a true executive sponsorship and federated data ownership model, you'll be able to maintain that. 

Sean Dawson: That's a great answer. The final question that I'd like to pose to you, and it's open ended in the sense of, is there anything that you'd like to share with the audience—regarding CMDB and the security of the organization—is there anything that you'd like to share for those that are considering CSDM, CMDB, and security? Anything else that you'd like to share with the listeners? 

Mike Stolp: Yeah, absolutely: Is don't let the daunting task stop you from actually doing it. It's doable. Because here's the thing: You have all that out there. You have a very complex IT environment—on prem, off prem, hybrid—you've got vendors and service providers and so on. When you start looking at that and you think, okay, you've got to do all of this and just pull it all together, it is—to use the old statement that's probably overused way too much—don't try to boil the ocean. Don't. Start with what you know, right? Start with your endpoints. 

Just think about this from a security perspective. If you were able to get a picture, an accurate picture of just your endpoints, who's connecting to your network, right? On a very reliable basis, for, or even better yet, who should be connecting and who actually is, which many times is different. Imagine, just from a security perspective, what that gives you. Or better yet, even, how many platforms do we actually have in our environment? How many are we paying for? How many should we be paying for? How many are we paying for that we're not even using? All of those things just start with one thing. Start with one aspect of your IT environment and go from there. 

The second thing I'd tell you is grab a partner—somebody who does this all the time. And this sounds like self-selling, but in reality, is it is complex to do. It's certainly not impossible. It's really quite necessary if you want to be a secure, highly operational, and highly reliant environment: Grab a partner. Find somebody who can walk out and work with you on the journey. Tell you where to, what pitfalls to avoid, how to navigate it. And it's not gonna take as long as you think. It does take some effort, and it's absolutely worth it.

Sean Dawson: That's great. Great, Mike. Thanks so much again for taking time out to talk to listeners and us and spending time together. I do wanna ask the audience that, as you watch these, like and subscribe. If you have anything that you'd love to hear from us or see us talk about further, we would love to hear from you.

Comment, send us a message, email us—however you want to get a hold of us. Let us know. We would love to hear. And again, thanks a lot and take care.