I’m sure you’ve been following the Terry Childs case. Mr. Childs was a sysadmin in San Francisco who decided to change a few passwords and thus locked the city out of their new wide area network. Though it is still not clear why Mr. Childs did this, he had been recently written up for poor job performance.
Among others, Matt Pollicove wrote about this and the need for trust. Matt asserts that trust is a must and I completely agree. That being said, the last two points in his post are mistaken.
First he says:
This means, making sure there’s no orphan or rogue accounts in the systems.
While this is a generally accepted good practice, it would not have necessarily helped San Francisco keep from losing their network. Privileged account management would have been far more useful. Discipline and control around how sysadmins gain access to and use root-like accounts, the bread and butter of privileged account management, would have helped avert some of San Francisco’s problems.
Second Matt says:
GRC tools will be a must in this verification.
This first thing that springs to my mind is a question: what aspect of governance, risk management, and compliance would have helped the city of San Francisco in this case? A good governance and risk identification and management process would have helped a great deal. But we have to keep in mind there is no such thing as a GRC tool; there is no such animal. In fact, GRC is starting to sound like the wonderful magical bacon animal that Homer Simpson dreams of. If pork chops, ham and bacon all come from the magical animal in the Simpsons, then privileged account management, orphan account management and provisioning all come from the magical GRC animal. Where does it end? The reality is that the industry has confused the benefits of good governance processes and risk management capabilities with automation tools that aid, but never replaces, those processes and capabilities.
Privileged account management is not and should not be considered part of the marketing fog of GRC. Does the controlled management of root-like accounts constitute good operating procedure and help reduce risk? Absolutely. But that doesn’t make privileged account management a GRC technology. Is orphan account removal a critical process from a security and risk mitigation perspective? Of course. However, that doesn’t mean the technologies to do that are GRC technologies.
Specificity of language is crucial. Telling the city of San Francisco that the solution to their problems lay within “GRC” would have done little except lengthen the time to finding what their real problems were. Our industry cannot take the easy route and lump every possible technology and procedure under the sun onto the GRC heap or else we’ll find ourselves chasing Homer’s magical bacon animal.
I agree that there can be no one tool that can address all aspects of GRC. The OCEG created a great slide that shows how software can support GRC and there are so many software needs that no one product can do everything – and they only scratched the surface. There are products that can assist in the GRC process and aid human decision making, for example in risk management software can be used as a tool to assess risk, but the software can’t know everything that is happening in the world, while a human being can take the output from software, that person’s experience shold be used to gain a better appreciation of risk.