Since the explosion of the cyber wave a few months or years ago, the CISOs of this world have seen huge budgets being poured in security investments. Many have thus seen their direct budget follow the same inflation. For a population which has spent years to moan on the premise of a lack of resources, this is now time to smile.
Or maybe is it not? Because in reality, what are they going to do of their big budgets? For those may well be signs of two major misconceptions eventually unfolding as time bombs.
The first issue is already emerging in minds; it is the question of “what now?”. At a time where the market, as exemplified by the exhibitors at the recent RSA Conference, all vendors are building a bubble out of the innumerable products or solutions that they push in response to the budget inflation, one may legitimately wonder: After all those products are implemented and after all that money is thus spent, will security be fixed once and for all? What now?
“Fixed” seems of course a fair expectation from the C-Level. Set aside obscure requirements falling on their shoulders from regulations, when asked, senior management usually demonstrates a clear view of which information needs to be protected. They thus expect such a view to be naturally implemented and thus to be fixed if it has to be. And indeed in theory, there is no reason why information systems, even when ‘open’, should be insecure. Provided the technology and the system designs do not bring in more risk than is implicitly assumed by management, which is alas hardly ever the case. First to come to mind, unanticipated vulnerabilities contribute to blur the game. What is worse, never can anyone be sure that none still exist. Very often, this gap of perception by senior management between secure and leaking is the root of many failures.
“Once and for all” also sounds legitimate: on paper, a fixed system has no reason to become insecure with time. Except if change management and new projects in general can themselves be the source of new holes in the information system, which is usually the case. In other words, senior management largely invests to fix security and will wake up one day with the surprise of information systems that seem not to have improved in exposure in any way. This leads to the second misconception.
The second misconception bears on the mesh of security accountability within the company, or organization. That is, though the CISO is supposed to be in charge, reality is different. And in facts – and in due common sense – the actual responsibility for insecure systems spreads across pretty much everyone. Let’s consider why through a few basic examples.
If a new applications ends up totally hopeless regarding security, it is the sole CISO’s responsibility? Or is it the sponsor’s one for not having given any security functional requirements and for not specifying any data protection need? And then the project manager’s one for not noticing and for not caring for security policy compliance? And then the developer’s one for not asking why this application does not ask any password? Same for the testers and same for the users. You get the idea.
We could go by the same logic at all levels across the company. Network design is not thought with resilience in mind, but laziness – sorry, for ease of change. People are not removed from directories because it complicates archiving, laptops have admin rights to please those less careful, and so on. There may be exceptions, but usually, none of those small decisions are made by the CISO and none pops up to the board, so that senior management has no clue of all the little drifts which stack up to corrupt their precious information system into a source of nightmare.
In fact, the big mistake that comes with hiring a CISO is to shift everyone’s accountability off to his sole shoulders. And in fact, the more power and budget on the CISO’s desk, the less on those who are the actual players. And there is more. Even the minimum could be too much for the CISO’s agenda.
Consider a security policy. It sounds like a good idea to have one, it helps ensuring basic rules are in place. Could be – though everyone has a story to tell about how seldom compliance is fully met. Or maybe there could be another way? Maybe without a policy on passwords, it would be the sponsor’s full responsibility to ensure proper authentication? And because of that, maybe sponsors would be more likely to take this seriously?
With such a decentralized approach to security, it is easy to see that a huge central budget for security is a sign of many dysfunctional processes. In fact, the bigger the budget, the bigger the internal disorganized security processes. It is fine to invest in security, but the amount should be spread in consistence with each actor’s role.
The bottom line is that a useful CISO is not a CISO with a huge budget. But one that keeps the board aware of how much gap, if any, there is at any time between their perception of the security risk and the actual exposure – together with explanations and actionable suggestions. Such a CISO does not need a budget; the company does.