Skip to content ↓ | Skip to navigation ↓

I have a frequent discussions with various enterprises about “connecting security to the business,” during projects to help them articulate the value of information security to the rest of the business.  One of the big challenges I come across in these efforts is lack of clarity about which infrastructure is important to the business, and why.

Many enterprises are frustrated that they don’t have an acceptable “source of truth” to rely on for this information.  Sure, many of them have a CMDB, perhaps a service catalog, or (more commonly) a spreadsheet with a list of servers and their function.  The issue?  It’s almost never accurate or up-to-date.

Right hand, meet left hand

Even when automation is brought into the picture, things aren’t perfect.  Security uses tools like vulnerability scanners that have one view of the world, while Ops often uses completely different tools for discovery, tracking, and documentation. To make matters worse, infrastructure and applications teams typically don’t interact that much so a server gets deployed and who knows what apps will end up on it?  And virtualization just compounds the problem by allowing cloning, easy deployment of servers that may not go through a formal process, and things like that.

Cracking this code is essential for maintaining a clear view of what your infrastructure does for your business.  It is also vital to help create a risk-based security management approach that everyone buys into.

Data gathering

Does this problem sound familiar?  Have you come up with a good solution?

I have some thoughts on this situation (no silver bullets, I’m afraid) but, for now, I’d like to gather information from you.  If you have practices, processes, or methods that have helped you get closer to a trustworthy, accurate source of truth for your systems?

Please share, either via the comments below, or by sending me an email at: dmelancon [at] – I’ll share any good learning from this community in future posts.