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

Generations of security by design methods

  • 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”.

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

  • 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

Thinking further?

  • 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).

--

--

Friction generates heat — true for writing and engineering. Fluchsfriction generates writings on security engineering. Heated debates welcome! CTO@admeritia

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Sarah Fluchs

Friction generates heat — true for writing and engineering. Fluchsfriction generates writings on security engineering. Heated debates welcome! CTO@admeritia