Why is an infrastructure monitoring project so risky and prone to fail while a security and regulations compliance monitoring project practically always succeeds? After all, they´re both about monitoring.

I find this question quite perplexing. In fact, I know of hundreds of failed infrastructure monitoring projects where millions of dollars/euros/pesos were burnt, with little to show in return. Most of the software ended in shelfware. You may have not heard about them, as people don’t talk too much about their failures; they prefer to turn the page and look towards the future.

On the contrary, most security projects have more or less of a happy ending. Even our competitors’. You can argue about the qualities of each one, you can discuss return on the investment, ease of maintenance, expandability, etc. But they do not end up as spectacular failures as do their IT Operations monitoring cousins. At least not that often.

Platform diversity cannot be blamed. Heterogeneity is pretty much the same for both. In fact, the aim is to cover practically the same servers, middleware, applications and network equipment. And I resist the idea that you security guys are smarter than us poor, ordinary guys. You may well be, but that isn´t the reason either.

More abundant resources? The funny thing is that most security projects end up with a much, much lower price tag than their operations project counterparts. And typically, fewer people are involved.

So let me venture a theory. These projects are successful because they do not have to follow 1900+ pages and seven kilos of ITIL guidelines, in particular, the CMDB-related gibberish.

Look ma, no CMDB! Instead of collecting thousands of attributes for every single component involved and then trying to make sense out of it, only to discover that many really relevant data is missing or is there but obsolete, they just go for the problem´s jugular and start monitoring right away.

Instead of veering off course, challenging internal culture and putting non-proven processes in place, these projects focus on their desired outcome: setting the COBIT- or ISO-recommended controls through real-time sensors and alerts, creating the adequate reporting environment to pass the audits, and that’s it. You´re done.

Now imagine the opposite. Before doing the security monitoring project, let’s spend time understanding ITIL (pick your preferred version), researching CMDB vendors, deciding which one we should marry with (and remember, there is no divorce law in place here), getting your personnel fluent on ITIL processes and principles, figuring out how to adopt and adapt the processes that could be of value, and then let’s implement those processes and supporting technology, which means that you will start mastering a federated database of endless, changing things. Then, let’s try to find out how to add the relationships between your relevant business services and processes and your thousands of isolated CMDB items. Then, let’s enroll in an ITIL refresher course, for there will be another version out by that time.

And finally, when you are done doing somersaults and the environment is stable enough (after several trials and mistakes and an ever increasing consultancy bill) and your CMDB is perfected, you can start adding your security controls. By that time, you may be retired. Or maybe, you´ve been fired or outsourced in the process. But alas, you´ve had a lot of fun! Or at least, I hope you have.

Maybe it´s just because of the staggering complexity of most traditional monitoring solutions, but I do suspect that CMDBs have a lot to do with the fact that security monitoring projects are so successful—because they are absent from them.