Security Engineering Needs a P&I Diagram
Why we should finally build a system model that helps with our security engineering (and how the Layered Blueprints got their name)
Let’s do a little experiment together. Close your eyes and think about security. What do you see?
If you’re now saying “hackers in hoodies, locks, and endless chains of ones and zeroes”: That’s not what I mean.
Think about yourself securing systems. What do you see? If you could hand your fellow security engineer only one sheet of paper to help him understand where you’re at, what would be on it?
White letters on a black screen?
A CVE database?
CVSS scores?
Green-yellow-red risk matrices?
An attack tree?
Network maps with cisco symbols?
A SOC dashboard?
That question is really hard to answer for security engineering. And that’s strange, because it is much easier for other engineering disciplines.
Let’s imagine we asked the same question to engineers of other engineering domains: If you could show only one piece of paper summarizing how you solve a problem — what would be on it?
A mechanical engineer confronted with that question could answer, for example: A CAD drawing:
An electrical engineer? A circuit diagram:
A control engineer? A block diagram:
A process engineer? A piping and instrumentation (P&I) diagram:
Thinking like an engineer means thinking in models
Probably there is not the one and only answer for each engineering domain; each domain may have multiple popular models that help engineers think.
But: They all have such like models, and they are wide-spread. There is no engineer who has not come across them at school. In fact, engineers learn that if they are to solve a problem, first thing they do is to strip the problem down to a model — and for good reason. Models help to channel thinking. They de-clutter a problem from all irrelevant aspects and show the world from the perspective out of which the problem becomes the clearest.
An engineer uses a model to distill a problem and all its relevant boundary conditions in a single sheet of paper, and then she begins to work with that model, expands, molds and kneads it, until it contains a solution.
In the end, the model showcases a solution, printable onto a sheet of paper that can be handed on to a fellow engineer to help him understand problem as well as solution, and also catalyses discussions.
Procedure model vs system model
If we now begin to talk about models, we need to make at least one distinction — because there are a lots of different models which can be categorized in myriads of ways. For this text, it will suffice if we can tell apart procedure models from system models.
Procedure models structure the engineering process itself, or any process. Popular examples are the V model, the waterfall model, and of course everything “agile”. Procedure models help you stay on track. They are useful to roughly line out where you start with your engineering, and which steps to take next. They help to efficiently communicate to yourself and your fellow engineers where you’re stuck in the process right now.
We do have some process models for security engineering, although they’re rarely called like that. They mostly come in the disguise of risk analyses or systems engineering processes.
For risk analyses, there are heaps of standards outlining procedure models. Systems engineering is less wide-spread and described in NIST Special Publication 800–160 and ISO/IEC 21827:2008. Depending on their original purpose, these procedure models might cover one, many, or all steps necessary for security engineering in varying levels of detail.
To gain better orientation in the jungle of procedure models, they can be mapped to a simple method-neutral procedure model, like the one we proposed last year in Control Magazine (“Making OT Security deserve its name”). It is sketched roughly in image 5:
First (in the lighthouse: at the very bottom) the question for the security objective is answered — for which essential functions and dependencies of the system to be protected need to be understood.
In the second layer, the risk against which the system is to be protected are identified. (The first and second layer in conjunction manifest a “security problem”).
In the third layer, security requirements that meet the identified risks are defined.
Last, it is answered how these security requirements can be implemented in reality.
While they are certainly helpful, procedure models are clearly not the one sheet of paper we are looking for. They do not capture the security “facts”, they contain neither the assumptions, nor the results of your engineering, and they do not help us to model and communicate a security engineering solution. It is not that sheet of paper you would hand anyone to understand your work, just like no automotive engineer ever proudly handed a sheet of paper containing a V-model to his boss in order to show her a mind-boggling new solution.
It is rather a system model for security that we are looking for. System models are what procedure models produce “en route”. If we take our procedure model from image 5, we can imagine that for each layer of the procedure model the results get modelled into a system model. In the lowermost layer, we need a model of functions and dependencies of the system to be protected, and then we need to expand, refine, polish, knead, and mold while proceeding through the next layers until we’ve modelled a security solution.
Just how is the system model changed throughout each layer? That’s where the procedure model kicks in.
This is how the “Layered Blueprints”, the working title for image 5, got their name: At the lowermost layer a first blueprint of the system model for a certain security solution is created, and this blueprint is complemented, layer by layer, until it is four layers of blueprints. Reaching the top, the initial blueprint has been expanded, polished and kneaded to now represent a model of the designed security solution.
What’s the purpose of a P&I diagram?
So why don’t we have such a system model for security engineering? A system model that is essential enough in our discipline to be taught at engineering schools?
You would imagine that we security engineers could use such a system model quite well, because security is never an end in itself. Security engineering is only needed when other engineering domains have built something. Security engineering does not fulfill a single new functional requirement, but makes sure that the functions other engineering domains have created remain reliable — even if there are attackers that strive for the opposite.
Or, in brief: Without automation engineering, no one would need automation security engineering.
That also means that when security engineers begin their work, there is already a heap of other engineers’ work to understand, heaps of models from different domains to digest, summarize, and superimpose. The whole system to be protected needs to be understood and disassembled; its weakest link needs to be identified and fortified.
Is this the reason why building our own model is so hard for security engineers — because we need to build upon that many sources of existing models?
That may sound like a welcome excuse, but let’s not too readily accept it.
Let’s take a closer look at the domain of automation engineering. Automation engineers in a way have a problem very similar to that of security engineers: They automate a process, for example the production of a chemical or the assembly of a car — and this process is already there when automation engineers begin their engineering work.
They have neither designed it themselves, nor do they change it. They make if more effiecient through automation — but in order to do that, they first need to understand what’s there, that other engineering domains have already modelled, documented and maybe even implemented.
Or, in brief: Without process engineering, no one would need process control engineering.
So how do automation engineers tackle that problem?
They take a “sheet of paper” from process engineers on which essential information is modelled that is needed for design of a automation solution — hence the understanding of the process to be automated.
Then they begin working through their own engineering process and add, step by step, more information to the model. They model and mold and knead until the model contains their solution too.
The “sheet of paper” from process engineers normally contains a piping and instrumentation (P&I) diagram. Each chemical or process engineer knows these models, they are popular and standardized (in the ISO 10628 series). P&I diagrams contain a representation of the process that is intuitively understandable for humans by modelling product flow through pipes and all stages where the product is being manipulated (by valves, pumps, motors, reactors, heating elements, …).
Here’s a simple example:
For automation engineers, these P&I diagrams are a good basis. They can be expanded and kneaded in order for them to contain information about process automation as well. This is achieved by adding measurement and control fuctions, often called Process Control Engineering (PCE) requests.
These PCE requests are additions to the P&I diagram which facilitate the diagram being used interdisciplinarily at the interface of process engineering and automation engineering.
Much like P&I diagrams, PCE requests are standardized as well, always building upon standardized P&I diagrams.
Depending on which body of standards you observe, this could be in series ISO 3511, which is to be transferred to ISO 14617 and ISO 15519 or ANSI/ISA-5.1–2009, besides the standardization of the digital representation of measurement and control functions is standardized in IEC 62424.
Here’s the simple example created above, not with added measurement and control functions:
A P&I diagram for security — what could that look like?
Of course the problems for which P&I diagrams channel thinking are different from security engineering problems. Probably a system model for security engineering does not resemble a P&I diagram much.
So the question needs to be asked differently:
A system model for security engineering — what could that look like?
No matter how we ask the question: Let’s find out what that model looks like.
Let’s build a model that channels our thinking when solving security engineering problems; a model that helps us to express our thoughts on a certain security problem for others; a model that we can take and expand, and knead until we have a security solution — which again can be explained to others.
Let’s build a system model for security engineering, step by step.
Because it is always harder to begin creating something on a yawningly empty white page, I’ll take the first step for you in one of the oncoming texts.
Deal?
Update 2020–04–17: Further reading
- Jake Brodksy responded to this article on his blog, adding some valuable points (history and purpose of the Purdue model for example):
http://scadamag.infracritical.com/index.php/2020/04/12/diagramming-ics-security/ - A lively discussion evolved in the comment section of my LinkedIn Post sharing this article.
Leafing through it, you can follow some heated debates, and find a most interesting collection of ideas on modelling security: https://www.linkedin.com/posts/sarah-fluchs_security-engineering-needs-a-pi-diagram-activity-6655072880163864576-xv9A
