Some major breaches have seen the light of day lately, and everybody agrees that they will keep coming. I don't believe you will find any security professional respecting himself to tell you that this will stop. The reasons are many, but the most important one is the (lack of) security design. Systems, processes and services have been moving to production without security design for years. And unfortunately in many cases they still do.
In our (security) profession it is becoming common to jump on each other's throat; and the result is the public blaming of the CISO involved - like leaving them alone to take some hard steps in the middle of no man's land.
What is the CISO's job?
Nowadays most CISOs or Heads of security (or even Information or IT Security managers -the title depends on how much the company respects their top security person and how much power they have) are fighting two fights in parallel. The one is about the future: to instill practices in their company, that will facilitate security by design and security by default. The other fight applies to the future too but is driven and some times even strictly directed by legacy: to design an architecture comprised of enough and properly placed controls, that will secure the existing (and ideally will equally apply in the future) situation.
The future view
I often argue that security is a business enabler and not a business blocker. The main goal of security is to ensure that whatever is rolled out will be rolled out in a state that will keep working, without compromising the business data and operations. Easier said than done of course, because design is a very difficult thing; and it gets more difficult as the company complexity raises. The CISO's job starts at designing this process, and speaking for me personally, I will gladly take all responsibility in case my design is flawed. If that leads to a security incident not being handled appropriately, and subsequently an impact to the business being over the company's risk appetite, it's totally the CISO's fault.
The current and past view
During the design of the architecture and the processes of secure development and deployment, one must take into account how the controls that comprise this architecture will apply to what is already in place. The proper selection of controls has three drivers: defence in depth (never rely on a single control), risk management (prioritize controls depending on the risk) and control coverage / gap (don't leave gaps and don't pay twice for the same control). Again, not an easy job, and a CISO should assume all responsibility for incidents happening due to poor design.
Ok but we had an incident. Can I blame my CISO now?
During the Equifax crisis, the Equifax CISO was targeted and eventually replaced. But nobody asked if she had designed the controls properly or not. I don't know either, but from where I'm standing, her job was to select and design the controls and raise the risk visibility appropriately. Her job was not to patch the systems, this is what we have IT operations for. On the other side of the same coin, during the Wannacry crisis I wrote a blog post in which I argued that we should not blame IT for failing to patch if the processes were not there, or if IT was not adequately staffed. We should have CISOs to blame if the controls were not designed - but not necessarily if they were not implemented. It's a team effort after all.
Blame (and replace) who is to blame
But if you're still looking for someone to blame, the answer is simple: blame your security if the design is inefficient or the incident response is inefficient. But unless you have IT operations reporting to CISO (and you probably shouldn't yet), in case the problem lies in lack of implementation of the controls, blame your IT. And if your IT is not adequately staffed or have been given different priorities, blame the business functions that set these priorities. On the way there, make sure that these business functions are aware of the risk that led your CISO suggesting these controls to be implemented.
Soon I will write a blog post about responsibilities, segregation of duties and collaboration (and in the end: management) but this will have to wait for some time in the future. In the meantime, think twice before you blame the CISO of the next hacked company, and realize it's always a team effort.