Generations of security by design methods

Some of our problems are already 30 years old

Worn out? Why, it still works!— Photo by Oziel Gómez on Unsplash

Security by design asks how we can integrate security decisions into existing engineering processes early enough to still influence important design decisions.
For the engineering process for automation systems, there is not yet a practical answer to this question. In the IDEAS project, we are trying to provide one — and in doing so, we are also digging into methods from related disciplines. Security by design is not just an OT security problem — perhaps we can learn from IT or software engineering?

If you do the work of wiping the dust off somewhat aged papers, you can come across intriguing insights — for example, in these two somewhat dated papers: Richard Baskerville (1993): Information systems security design methods: implications for information systems development und Richard Baskerville und Mikko Siponen (2001): A new paradigm for adding security into IS development methods.

Generations of security by design methods

The older paper will be 30 years old next year — let that number sink in for a moment. Baskerville divides the methods commonly used in information systems engineering for deriving security requirements at that time into three “generations”: checklist methods, mechanistic methods and logical-transformative methods. Let’s start with the first two:

• Checklist methods hardly deserve the name “method”: A list of possible solutions is given, from which you select those that apply to your systems. The individual characteristics of your own systems play almost no role.
• The mechanistic methods attempt to create more individual solutions by breaking down the system to be protected into its components — assets — and analyzing threats, resulting in a list of individual security requirements. The systems are mostly viewed in purely physical terms, and always in purely technical terms — hence the expression “mechanistic”.

Sounds familiar? Well, that’s how we still approach security today, 30 years later. Because the methods have proven themselves so well — or out of habit?
Habits should be questioned from time to time, and the paper is wonderfully well-suited to that purpose — because it explains the circumstances that have led to these habits.

According to Baskerville, the reason for checklist methods is clear: In the early days of security, the technical solution space was so limited that it was easy to list (and often implement) all possible solutions.

The role of risk analysis in the methods of the time is also interesting, because it is a direct result of this checklist approach: At some point, “implement everything” became too costly. So risk analysis was more of a cost-benefit analysis: if I have this bunch of measures — which one do I implement?
That’s a subtle but methodologically weighty difference for the question we often answer with risk analyses today: If I have this bunch of threats, for which of them do I even consider measures?

Problems of the available methods — 30 years ago as well as today

Even in 1993, Baskerville was not happy with the existing methods. He states their problems — many of them, by the way, in the 1993 text and unchanged in the 2001 text. And because the methods are so similar to our contemporary ones, so are their problems:

• Restriction of the solution space: Since the model of the system to be protected is already very concrete (physical components with specifications), so are the security solutions. They have a very limited solution space at their disposal.
• Separation from the engineering process (“development duality”): Because the mechanistic security methods require such a precise system model, they cannot get started until the system has already been specified in detail. The functional engineering process and the security engineering process therefore run separately and are consequently uncoordinated. Baskerville sees the problem not only in the limitation of the security solution space, but also in the conflicts that may arise: “if the security designer fixes “ vulnerabilities” that the functional designer purposely opened as “features.”
• No explicit link to the problem: There is often no traceable link between the security solution and the problem it is supposed to solve — and neither to the benefit the solution offers to the organization (not only to the technical system!).
  Quote: “the needs of organizations are replaced by ideal protection techniques based on the intuition of security gurus, and organizations are required to follow these as “a gift from the heaven”
• Complexity: Checklists take too little account of the individual system, but looking at each of its components individually and customizing the security solution is very time-consuming and requires a great deal of knowledge that can hardly be covered by one person or domain: Detailed knowledge about the systems to be protected (especially in automation technology, this alone can no longer be covered by one person) plus detailed knowledge about security threats and requirements.

Solution approaches: Solution-neutral models, integration into the development process

With a ten-year gap, the authors present different approaches to solve the problem they’ve identified. One is found in the third generation of methods, which I have omitted above: The logical-transformative methods are Baskerville’s 1993 proposal to solve the existing problems of the previous generations. They are based mainly on creating a more abstract model of the system worth protecting, so as to deeply understand the system under consideration instead of directly thinking in terms of concrete solutions.

In the outlook section of the first paper, Baskerville also analyzes the need to integrate security into existing development processes.

In the second paper, almost ten years later, Siponen and Baskerville expand the definition of “integrative” methods as a vision: Suchlike methods are supposed to integrate security into existing development processes, but also into a company’s goals and into its social fabric. In a sense, this is addressing all of the above problems in one solution.

However, the two also seem somewhat disillusioned: integration into the ever-changing development processes is bound to fail, they write — also because these processes are never lived in practice as they are described on paper. Instead, they propose a concept for a “meta-notation” that can be used to integrate security as a “plug-in” into all kinds of existing processes.

We now have the luxury of looking back at the solutions 30 and 20 years later. What is striking is that none of the approaches has prevailed — at least not in OT. Instead, we are still dealing with the same problems. And: We are still trying to solve them with similar approaches.

Thinking further?

What do we take away from all this, if no solutions? Probably above all food for thought. Here are three questions that you can use to think further with regard to your daily security operations:

• The “best practice” culture of always thinking directly in terms of concrete technical security solutions is still with us today. It is so ingrained in our mindset that we hardly notice it anymore. It’s taken for granted that “security requirements” are actually direct suggestions for solutions, if not products: Install antivirus. Implement a VPN. Install a firewall and intrusion detection system. What would solution-neutral formulations for this sound like?
• Security engineering does not automatically contain a risk analysis, and if it does, the purpose of the risk analysis obviously has an influence on the selection of a risk analysis method. A risk analysis is always a filter, but there is a difference in what it is intended to filter or prioritize: Impacts that are relevant to you? Systems whose security you are concerned with? Threats you want to protect against? Measures that are worth implementing? What question do you actually want to answer with your risk analysis?
• Sure, security is best considered as early as possible in the system development process. But what security engineering must look like in order to integrate it into the existing development process depends heavily on precisely that development process — which is highly individual. In your company, what would be the process into which you would have to integrate security in order to achieve “security by design”?

This article was also published in the monthly “Security Briefing for Hard Hats” (in German).