It took almost 10 years, but my claim that the role of the CISO is to take the blame when something goes awry, even if only marginally attributable to information security, goes awry has at last been substantially validated.
Let’s scroll back to December 2004. I was a member of a panel of illustrious InfoSec professionals addressing the topic “How to Build an Effective Security Staff.” The discussion moved along uneventfully until one of the panel members asked the others, “What is the role of the CISO?” Without blinking an eye, I retorted, “To take the blame when something goes wrong.” At this point, other panel members roundly reprimanded me and described how important and respected their CISO roles were. Clearly Axelrod didn’t know what he was talking about … and even if it was a joke, it wasn’t funny.
Well, it wasn’t a joke. I had witnessed quite a number of cases where a breach occurred and the CISO had been fired or encouraged to find other employment, even when it really wasn’t that person’s fault.
Now let’s scroll forward to the present day. On the front page (no less) of The New York Times of July 21, 2014, Nicole Perlroth published an article “A Tough Corporate Job Asks One Question: Can You Hack It?” The article, in illustrating the unenviable position in which CISOs frequently find themselves, quotes David Jordan, CISO for Arlington County in Virginia, as saying. “We’re like sheep waiting to be slaughtered … We all know what our fate is when there’s a significant breach. This job is not for the fainthearted.”
It is sad to say that the environment and circumstances surrounding the position of CISO has been seen to worsen over the past decade and there is nothing to give one hope that it will change for the better in the short term.
While the NYT article did a great job of identifying the problems confronting today’s CISOs, it did little to suggest how we might improve the situation. In reality, most InfoSec organizations are encumbered with legacy systems and outdated technologies that do not lend themselves to easy fixes. The truth of the matter is that security has to be baked in from beginning of the software development lifecycle. Security requirements need to be expressed and formalized and management and other stakeholders must ensure that they are included throughout the life of the software.
There is a relatively small subgroup of InfoSec professionals who concern themselves with “building security in.” To familiarize yourself with the area, you should begin by reading the content on an excellent government website at https://buildsecurityin.us-cert.gov/ There is also a number of books and journals dedicated to software engineering and application security. Dr. Gary McGraw is a leading authority and thought leader in the areas which he essentially pioneered. And, of course, you may wish to read my book “Engineering Safe and Secure Software Systems” which reaches out from cybersecurity to cyber-physical systems to address the trend of combining security-critical and safety-critical systems as with the Smart Grid and the Internet of Things. And if you really want to get involved with application security, which is a good idea in and of itself, consider joining OWASP (Open Web Application Security Project) which provides a wealth of resources and the opportunity to interact with experts in the field … see https://www.owasp.org/index.php/Main_Page