For security, think functions — not systems

How to view your systems through security’s lens

Thought a black hoodie would make you a hacker? Far from it! You also need the right lens. [Photo by Yuan Zhe Ma on Unsplash]

What do you need to know for security?

What’s the information you ask for once you begin securing a system? What do you need to know?

  1. What’s the system’s purpose in the greater whole
    (in order to evaluate worst cases and consequences of threat scenarios)
  2. Which characteristics of the system actually serve this purpose, or in other words: Which features are fixed and which are negotiable
    (in order to find feasible ways to implement security requirements)

Don’t forget those humans

Statements like these have long become truisms:
For security, you need to take into account the human factor.
Security is a “people business”.
Security consists of people, processes, and technology.
Your biggest vulnerability is the user.

Purpose!

If we put all this together, we now have what we need to know to do security:

  1. How the system works
  2. What’s the system’s purpose
  3. Which characteristics of the system actually serve this purpose
[Photo by Cristian Aravena on Unsplash]

Sounds familiar? It is!

Functions are not a new concept for security engineering. There are quite some (security) engineering approaches working with functions:

A system can be viewed […] as a collection of functions capable of interacting with its surrounding environment.

— ISO/IEC 15288:2015

What changes once you think in functions

What happens once you really, truly, think in functions? This is probably the right time for an example, so here’s a very simple one.
Let’s assume we’re lucky and this system here is all we have to protect by our security engineering:

  1. How the system works
  2. What’s the system’s purpose
  3. Which characteristics of the system actually serve this purpose

1. You rapidly pivot between perspectives

Don’t regard thinking in functions or systems as an either-or choice. Rather, thinking in functions is a different, systematic way of looking at a system.

2. You make explicit what you don’t know

Looking at the above sketched functions, you probably realize they are very explicit on how these functions work, down to diagramming data flow. It’s normal not to know every detail of how a function works. After all, control system vendors do not always share which ports and protocols they use, or the person you would need to ask has long left the company.

3. You easily build bridges to business processes

If you ever had to implement a security management system you know that translating business processes to technology can be challenging, because of the different levels of detail and the seemingly irreconcilable viewpoints of management and engineers. That problem disappears once you connect both perspectives by using functions as your pivot point. Since you’ve already grouped your assets according to their purpose in functions, you only need to tie these functions to business processes now.

4. Threat scenarios become a matter of more logical and less creative thinking

When you’re at the point in your risk analysis where you have to determine threat scenarios, you’ll notice that you’ve already done much of the required brain-work when you have your functions handy.

5. You automatically include humans in your analysis

When it comes to threat scenarios, it’s easy to overlook human weakness. But when you properly work through your functions, how could you forget the humans? They’re a part of the function, you diagrammed them, you won’t forget about them. (Same holds true when you design security requirements and their implementation later on).

6. You reduce the number of single units you have to consider

Looking at the above examples, systematically thinking in functions seems like a lot of work. No doubt, security engineering is a lot of work — especially if you have no clue how your stuff works. Properly understanding your functions should not be a security issue, but in reality, it often is.

7. You create maintainable documentation

Because you can’t secure what you don’t know, documentation is a crucial (and painful) part of every security project. While functions do not reduce the importance of documentations, they do alleviate the painfulness of its change management, because they bring a permanent structure.

8. System experts become talkative

This may well be the most important change you’ll notice when putting on your function glasses.

Towards modelling security

Now that we’re all able — and hopefully also willing? — to view our systems through the function lens in our security engineering, we’re ready to move on to modelling them.

[Photo by Patrick Fore on Unsplash]

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