With cybersecurity becoming a boardroom topic, Security by Design (and Privacy by Design) is gaining more attention by the day. That may however not be enough to stay safe and move ahead of the competition at the same time.
My team and I at innogy have done a lot of work recently on bringing cybersecurity and Security-by-Design principles into our projects and initiatives within the innogy Group. Our aim has been to shift from a gatekeeper, “Ministry of No” approach that only checks security compliance at the end of a project, to a project partner that supports from the beginning of the solution design. This not only provides more secure products, but also decreases the overall time-to-market, reduces lifecycle costs, and results in happier project managers and stakeholders. More on that in another post that I have planned for the near future.
We are happy to see that increasingly projects are approaching us early in their development cycles and the number of projects where we are having to step in at the last minute to prevent significant security problems is going down. So far, so good. But is it enough?
Checklists are only part of the solution
The conversations we are having with our projects today is still very much concentrated on checklists and compliance documentation. Now don’t get me wrong: I am as much of a friend of a checklist as the next person. And there are some good ones out there, like the Baseline Protection Compendium of the German Federal Office for Information Security (BSI IT-Grundschutz-Kompendium). Most of them however run into two issues:
- They are only brought into play after the solution architecture has already been designed upon
- They are limited to the threats and control objectives that were in the minds of the authors of the checklist
This is akin to be asked to provide a security and safety concept for dynamite fishing, instead of having a conversation about whether hook and rod angling or fishing with a net might not provide equally satisfactory results at a much lower risk. Even though “the explosives guy assured us that there was nothing to worry about.” 🤯 And we haven’t even started to talk about the risks of drowning in the process. But joking aside…
The answer is to take the conversation even one step further forward.
From by-Design to by-Architecture
A conversation with the business stakeholders, not just the project team, about what the overall objectives of the project are, what factors might oppose reaching those objectives, and what can be done specifically to counteract those factors, goes a long way to addressing both issues mentioned above. By ensuring that the project and cybersecurity staff involved understand the priorities of the business, a common foundation can be found on which to base the risk mitigation efforts within the project. It also ensures that the right checklists can be applied, and efforts can be concentrated on any significant risks and threats not covered by the checklists.
This agreed set of priorities leads to a much more efficient usage of resources within the projects. Not just cybersecurity resources but development resources overall. It also fosters a much greater understanding within the business stakeholders of why certain cyber controls are being implemented, because the link to the business priorities can be clearly shown, thus freeing up resources for the next challenge down the road.
It is however not just a question of understanding and selecting the right checklist. Ensuring the business objectives and the context are clear allows a discussion to be had about what is “secure enough to achieve the business objectives”. We have seen numerous times in such discussions that a checklist approach would have implemented security measures that had no mitigating effect on the identified risks. Implementing “adequate” or “sufficient” security therefore has a further benefit of reducing unnecessary security spend. That is where security then starts to pay into those business buzzwords of “lean”, “nimble”, and “agile”.
Luckily, we are not the only ones bringing this to the stage. If you look at the Secure Design Principles of the UK National Cyber Security Centre, something I strongly recommend reading, you will see this mentioned in their first principle “Establish the context before designing a system“. This is also what we aim to achieve through our “Business Context Analysis” offering within our Business-Led Unified Enterprise Security (BLUES) approach.
Get your architects talking security and your security guys talking architecture
As you can see, there is a good argument to be made for bringing security into the business and enterprise architecture discussion, even before technology designs are being thought of. So, my call out to you is to enable your security guys to be part of the architecture discussion. Also, enable your architects to think of risks, both as opportunities and threats, from the start. There are methodologies and frameworks, like BLUES, which can help. And there are some real, tangible business benefits to be reaped.
[Updated to add link to Achieving Security by Design through BLUES article]