Earlier this year the Internet was on fire. The Heartbleed vulnerability had been discovered and everyone affected was scrambling to patch their web servers. There were not many organizations that could access a system and run a report that listed all of their affected servers. There were even fewer organizations that could, within hours, automatically remediate all their servers, not to mention able to prioritize the process by business impact (this is to say that fixing a customer-facing website should be done ahead of fixing some internal test system).

This is quite odd when you consider the fact that compliance discovery and remediation are the “bread and butter” of IT security. Yet, it is all too common. IT security teams may keep inventories describing systems and their configurations, but with the rapid pace of change in your typical enterprise, how can they keep it current? Automated discovery will allow them to scan the environment, on an ongoing basis and determine compliance. But this is about as good as it gets. In most cases, IT security may know system X may be vulnerable, but even if they have automated discovery capabilities, it is rare for them to know who owns it, what is running on it and what business function it serves.

It is even more uncommon for IT security to be able to simply access the system and fix whatever issue they believe exists, without asking someone else (typically IT operations) for permission or even to do it on their behalf. Even if your team is one of the lucky ones to have full visibility and freedom of access, you still need a way to fix a large number of systems quickly because Heartbleed wasn’t the first, and it won’t be the last. The good news is that many IT operations teams already have what it takes. After all, they too discover and patch on a regular basis.

Let’s have a look at the following picture

What we see is a continuous, automated compliance and remediation cycle. If you think this looks pretty similar to ITIL’s Configuration Management, you are right. This is all it is … with a security slant.

So what is easier? What makes more sense? Implementing this for IT security in its own silo, when IT operations already has it, or modifying it so it can also help IT security do its job? Your average IT organization already has too many processes and tools, even by their own admission. So why add more?

Not doing it amounts to asking IT security to fight the bad guys with one hand tied behind its back. You may occasionally win one, but it is almost a guarantee you will lose the battle eventually.