Comment: The security risk wears a tie
Too many organizations only add security as an afterthought – you have to think about security from the start, says David Fuhr.
Lately I’ve been asked more and more often where “the security” should be “hung”. The focus of interest seems to be shifting from WHAT (do we need to do to be safer) to HOW (do we do it effectively). First of all, that’s good news.
He has a weakness for risks and writing about cyber: In his main job as a security researcher at HiSolutions AG, David Fuhr rages and lets off steam in this column about current incidents and universal truths of information security. In addition to new articles, articles already printed in iX also appear here – always with a tongue-in-cheek update on the current security situation.
Just as it took, depending on the industry, a large part of the 80s (banks), 90s (other bits and pieces such as IT services of all kinds), 2000s (e-commerce) or 2010s (critical infrastructures), from the OB (people need security at all) to get to WHAT (to do), the next evolutionary step seems to be pending: From awareness (whether) to tackling (what) to thinking (how).
Sounds wrong? It is! The unsuitable organization of security is one of the main reasons why effective protection against cyber attacks and other digital injustices is progressing so slowly. While it is instinctively clear that appropriate organizational anchoring is required to bring about the many and profound changes that are necessary for cybersecurity. And yet the structure required for this is often thoughtlessly knitted on somewhere. This usually happens according to one of the following three patterns:
appendage
IT security is IT!? So the IT security officer reports to the IT manager/CISO to the CIO. Advantage: The distances are short, especially when it comes to concrete action. And budgets are quickly shifting back and forth, even if security is often not the main priority. It’s just stupid if the company is not aware of any of the important activities apart from incidents – and, worse, the security strategy is not aligned with the business.
superstructure
So maybe locating security as far “up” and far away from IT as possible, for example in enterprise risk management, in auditing or as a separate staff department? Then it sits at the table at least in certain decisive discussions and can be classified in terms of its value in relation to other corporate goals. On the other hand, emerging paper tigers have a harder time finding their way back into the infrastructure.
embedding
So the security expertise has to be spread across the individual teams? Business / engineering / production are the only ones who know what is important there. This is actually a promising approach, but has the disadvantage that there is no central control, expenses are doubled and maturity levels threaten to drift apart.
With his book “Start With Why”, the author and management consultant Simon Sinek taught us to go back with the why before the what and the how. So why would (my) organization want to deal with security? There are fundamentally two possible answers to this. First, compliance: I have to do something because contracts or laws require it. Example data protection, criticism, supplier audit. Second, risk: I would like to deal with security in order to deal with uncertainties in achieving my business goals, for example ransomware.
Depending on what I want to achieve with my work with security, different organizational models are more suitable. For a large company, it might make sense to have both a central control or governance function and decentralized security champions in relevant teams. In SMBs (on the other hand) one cannot afford to apply security to a dozen different roles. However, if the company or authority also has IT as an output in some form, there is another charming possibility:
At your service
Regardless of whether it is smart or electronic products, software or IT-based services that an organization produces – in the end it always depends on whether the (security) goals are met in the life cycle. It doesn’t matter whether the data center is encrypted or the SCADA system is infected – as long as the payment runs on time and the monitoring is uninterrupted, no critical damage has occurred. Thinking about security is therefore part of product or service management.
Ideas like “Security by Service Design” (SxSD) can help to introduce the right degree and the appropriate form of security into the production process from behind. If it turns out across three corners that we need to patch MS Office and 279 other applications for this, then so be it.
If we fully embrace the idea that security is an essential quality of what our company puts out into the world, chances are it will take root appropriately with us.
