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.