Security-by-Design (SbD) is an essential component to achieving security in today’s cyber world. But the path to implementing SbD is sometimes not obvious. The Business-Led Unified Enterprise Security (BLUES) approach shows a way to do this.

Why SbD

Creating safe and secure digital products isn’t easy. The lifecycle of such a product goes through many steps. At each step of the way, errors and weaknesses can occur. This goes along the whole chain from high-level design, all the way to production.

In the last ten years a lot of work has gone into reducing defects created in coding. This has led to methods like Secure SDLC and DevSecOps. The focus is on catching defects and enabling developers to fix them. Tools like Dynamic or Static Application Security Testing (DAST or SAST) are used to help devourers on this.

More recently, emphasis has also moved to looking further to the front of the process. The idea is that correct design decisions can prevent a lot of defects before they arise. The term for this is Security by Design.

SbD at innogy

At innogy, Security by Design (SbD) has been a strong focus in the last two years. Bringing forward not only S/SDLC but also SbD methods into play has allowed us to impact over 70 projects.

Our first learning was that there are many different definitions of what SbD is. Some focus more on technology, others more on organisation and management. The definition we produced for ourselves is:

Security-by-Design is a fundamental mindset that enables the end-to-end design of fit-for-purpose solutions, considering all business relevant threats and opportunities.

Based upon this, we created our Business-Led Unified Enterprise Security (BLUES) method.

BLUES Overview

Dimensions

BLUES follows the steps of the product lifecycle, including all iterations. This makes it suitable for both waterfall and agile projects. For the sake of simplicity, the picture above shows a linear flow.

Core Elements

There are six core elements to support each product engagement. These are most effective when BLUES is already part of the Business Idea phase. When this is not the case, each element can still bring value to a project, even if it is only conducted later.

It all starts with the Business Context Analysis. This provides an understanding of what the goal of the project or product is. It also shows in what environment the product will operating. This is a crucial step to understand which opportunities and threats play a role.

We analyse the business solution concept to create an Architectural Threat Model. The amazingly simple questions we ask about the solution are:

• What are we trying to achieve?
• What can go wrong?
• What can we do to prevent this?
• How do we ensure we have done a good job?

The answers to these questions lead to a set of solution principles. We document these as part of the Mitigation Strategy Architecture. This is the foundation for prioritising activities important to achieving the project goals.

The Security Test Planning then provides a way to show successful implementation of these elements. This also helps to prove compliance with policies and regulations.

Where security tools need to be selected, Tools Evaluation Consulting ensures fit-for-purpose results. It also encourages reuse of tools and services already available. This helps to reduce production costs.

Finally, support for the integration into the company’s operations management services is provided. This Secure Operations & Management Enablement is crucial to keep the product secure while it is in operation.

Foundation Elements

The core elements operate on a foundation built for all engagements. This enables knowledge sharing between projects. It ensures that innovative ideas and experience from one project can flow into the next.

Security Concept Architecture & Technology Support helps in the creation of security concepts. The important word here is support, not creation. The aim is for the organisation to create concepts of uniform high quality. To do so, it defines how to create such concepts and what should be in them. The responsibility for creating the concepts remains with the service and product owners.

Security Patterns & Guidelines bring together the learnings from the many different engagements. They enable the projects to create secure products. They provide guidance, rather than restrictions.

Finally, Security Training & Community brings it all together. The number of cybersecurity challenges is so high that this cannot be done by a single team alone. Training creates a baseline of cybersecurity knowledge amongst the developers and architects. The Community then takes it to the next step. It enables experience sharing and for people to learn from each other. This is the most effective and crucial element to ensure a cybersecurity team can scale.

Details to come

This is the first article in a series. In the coming weeks and months, I will go into more detail of each of the elements and phases. I will of course be adding links here when they are available.

In the meantime, if you have any questions, comments, or feedback, please don’t hesitate. There is a feedback form below.