Start making model-based cybersecurity decisions in 3 steps

We have to think of an engineer who knows how to actually DO security by design as a happy person

Do you also have an autocomplete in your head that, as soon as you think “security by design”, blurts out “principles”? According to Google, you’re not alone:

This is a problem. Because if all you associate with security by design is a set of lofty principles, how are you going to actually include it in your engineering? I spent quite some years studying engineering, but regardless of the engineering domain I don’t remember any professor or textbook saying: “If you follow these 10 principles, you will end up having engineered a car.”

Security by design has the unfortunate status of being an undisputed ideal everyone agrees is important, yet everyone seems to have accepted that it’s — well — an ideal, hence something that you will never achieve in reality anyway. And I blame this status at least partly on the fact that no one tells you how to do security by design so that you end up having a system that could be called “secure by design”. Instead, we leave people with the advice to embrace or bear in mind “secure design principles” like defense in depth, least privilege, zero trust, input validation, fail securely, etc.

Honestly, what are engineers supposed to do with these? Tape them above their desks or put them under their pillows and hope they diffuse into their heads and they will JUST KNOW when they follow their engineering workflow as usual.

I have been researching security by design for industrial control systems for the last three years, and at the very beginning when we analyzed the status quo, engineers repeated a statement to me that I’ve been hearing over and over for years: “We would love to consider security during design. If just someone told us how…”

Cybersecurity decision diagrams: Three steps for security by design

Here’s my attempt to help with the how. For this article, I’ll strap the procedure down to the bare minimum to keep it simple. So here’s your security by design workflow:

1. create your security decision base that contains everything that could change the way you make security decisions.
2. model your system under consideration in a cybersecurity decision model that includes architecture, function (including humans!), and explicitly marked cybersecurity decisions. Begin your cyber model as early as possible, just include only as much as you have already engineered, and iterate as you continue your usual engineering workflow.
3. make the security decisions as far as you can with the cyber model you have and based on your decision base.
4. repeat 2 and 3 until engineering is finished.

That’s all. DOING security by design boils down to two things: knowing your security decision base upfront and maintaining a cyber model with consciously made cybersecurity decisions while following your usual engineering workflow.

In the following, I’ll add a few examples to explain. The example models parts of an industrial control system (ICS), but the same three steps can be used for other systems.

1. Create your security decision base

Many security methods try to tell you that you should decide everything based on risk, but the reality is that there are many ways to make a security decision.

The four decision-making paths I find useful to consider are

1. goal-based decision-making
2. risk-based decision making
3. compliance-based decision-making
4. decision-making based on functional requirements or restrictions

Your cybersecurity decisions will likely be a mix of these four. I haven’t seen a single organization that doesn’t use all four decision-making paths simultaneously — and a surprisingly high percentage is usually made based on functional requirements. So it makes sense to reflect on all four paths when you fill your cybersecurity decision base:

Security goals specify what cybersecurity is meant to achieve for an organization / the system under consideration. These can be written using availability, integrity, and confidentiality statements (“Availability of safety PLC and alarm server”) or worded more freely (“No access to safety PLCs from outside the plant”)

High-consequence events (HCEs, also known from INL CCE / CIE) are unwanted states of the system to be protected (“Ethylene oxide plant explodes”)

Attack scenarios are scenarios that are harmful to the system under consideration and may lead to a high-consequence event (“a critical value is bridged so that the safety function is not triggered in case of an event”).

Security standards / regulations that an organization chooses or is forced to comply with (“Critical infrastructure regulation of country XY” / “ISA/IEC 62443–3–3”).

Security requirements are individual requirements from any of these standards or regulations (“SR 5.1: Network segmentation”).

Functional requirements/restrictions are requirements that define a system’s functionality as opposed to non-functional requirements that address for example security or reliability. They can restrict the solution space available for security decisions (“Signal bridging is needed for maintenance” / “The service provider can only receive files via FTP”).

2. / 3. Model your system and make your security decisions

Early stage of the engineering project

At an early engineering project stage, knowledge about desired functionality may be available, but little may be decided yet about how the function will be executed. However creating the cybersecurity decision model can and should already begin at this early stage because very fundamental cybersecurity decisions already happen here and should be made consciously.

As an example, consider this function:

Even if nothing may be known yet about network architecture or the specific hardware and software to be used, the fact that PLCs will need to be engineered is probably fixed early on, and this function can be modeled at a high level of abstraction.

Questions that can be discussed that early, even based on this very simple cyber decision model: Do we want to accept the fact that there will likely by a proprietary protocol between the engineering station and safety PLC? Do we want to attach additional security requirements like the need for authentication to the proprietary protocol? Do we want the same engineering station also to be used for non-safety PLCs? Who else beyond the engineer will interact with the engineering station? Do we want a physical key switch to be attached to the safety PLC?

Any of these questions that are answered are cybersecurity decisions, and they should be documented as such. For example, here’s the documentation for the proprietary protocol and the physical key switch:

Both decisions are marked explicitly in the drawing by petrol-blue icons, and rationales for the decisions are provided by referencing items from the cybersecurity decision base (now you know why you should have the decision base ready before you model anything). The key switch decision also shows how security decisions can result in changes to the cyber model (and consequently to the system that is being designed).

Later stage of the engineering project

At a later stage in the project, the system model will likely be more detailed. A manufacturer may have been selected for the components in or example function:

And the network architecture surrounding our example function may have been specified as well:

With this additional information now available, more security decisions come up. In the architecture, adding or removing network segments is almost always a security decision, for example the decision to add a separate COM network for interfaces between PLCs (blue) and control system components (green), which is documented below:

Also, there are many decisions to make for individual components. Examples for security decisions that are made for the HIMAX X-CPU are listed here:

And here’s an example of one of these detailed decisions — the one about an integrity checking mechanism — being made (not surprisingly, based on a functional restriction again):

The cybersecurity decision model can be changed and refined until the engineering project is finished. By the time engineering is finished, all cybersecurity decisions (marked by the red and petrol-blue-colored symbols in the drawings) should be made and documented along with a rationale that refers to the decision base.

The design phase is only a small portion of any system’s lifecycle. Cybersecurity is dynamic, and probably not all cybersecurity decisions will remain valid throughout the lifecycle. But once the cybersecurity decision model has first been created, engineers can continue to use it during operations, for example, if the system is changed in smaller re-engineering projects or if the system’s context changes, for example, if new vulnerabilities become public or new elements like newly applicable regulations are added to the decision base.

The three steps (1 — decision base, 2 — model, 3 — decide) can be applied to cybersecurity decision-making during operations just as during design.

Final note

The described workflow is the absolute minimum you need to know to get started with security by design in your engineering workflow. To make this as accessible as possible, I deliberately left out some details, for example:

• There’s more to say about the security decision base, for example, the decision-making paths that it is based upon. Also, attack scenarios can be visualized within the cyber decision model.
• There’s more to say about the question of how to identify the points in your usual engineering workflow that should trigger a re-iteration of your cybersecurity decision model — we call them cybersecurity decision points.
• There’s more to say about how you can draw your cybersecurity decision models more quickly, and how to identify and make the cybersecurity decisions in the model if you’re not a security expert.

I’ll follow up with separate articles on each of these issues.

The described work has been created during the research project “IDEAS”. All published research papers can be found here.

Sarah Fluchs

Sarah Fluchs is the CTO of admeritia, which specializes in security consulting for the process industry, manufacturing, and critical infrastructures. A process and automation engineer herself, Sarah is convinced that creating solid engineering methods that speak the language of automation engineers is key for security in automation. Her main research interest is to help automation security engineering grow up as a discipline. More specifically, this includes security and systems engineering, understanding security (and safety) as part of a broader resilience engineering, the use of human-readable models to make security engineering more intuitive and the use of machine-readable models to make it more efficient. To drive these research interests, Sarah leads the government-funded research project IDEAS (Integrated Data Models for the Engineering of Automation Security) and has taken a side-role as a scientific researcher at Helmut Schmidt University Hamburg in 2021. Sarah is an active contributor to ISA and IEC standards regarding automation security and a board member at both the ISA Standards & Practices board and the German water industry digitalization organization KDW. She writes a monthly "security briefing for hard hats" (admeritia.de/hardhats, in German) and a blog (fluchsfriction.medium.com, German and English). Also, Sarah is one of the founders and leaders of the Top 20 Secure PLC Coding Project (plc-security.com).