A Security Engineering Tool for Automation Engineers
IDEAS project: Integrated Data Models for the Engineering of Automation Security
Automation engineers are familiar with this problem: They are often not allowed to start engineering the control system, controllers and fieldbuses until all the other trades — electrical planning, mechanics, process engineering, for example — have already made crucial decisions.
Security engineering has the same problem, only one step later: It only begins when the automation engineers have also finished, or even after the plant has been commissioned.
This is not quite what security by design looks like.
Security? That’ s what the others do…
One reason: For automation engineers, security is usually what the IT department does. The spoilsport discipline, which always comes up with unrealistic requirements (two-factor authentication? Boy, they’re constantly looking at the screen in the control room anyway!)
For manufacturers, security is what you would really like to do if the operator was willing to pay for it. For operators, it’s what you’d be so much better at if the manufacturers bothered to care a bit more.
In short: for automation engineers, security tends to be a matter for others. That can hardly be blamed on them, because in their already interdisciplinary engineering process, security is the newest participant, and also the most methodologically immature.
In terms of how security engineering should proceed methodically, there are rather too many than too few suggestions; at least in the field of risk analyses. Things get difficult, however, when it comes to the question how security information should be communicated. Circuit diagram? P&I diagram? For security, such — in other trades often graphic — thinking aids are missing. If they are available, we just use network diagrams.
But then, what exactly is security information?
Yes, it’s time for security engineering to grow up a bit, so that automation engineers can get to grips with it. What they need is a clear, systematic method, an idea of how to integrate it into their existing engineering process, and a tool that guides them through security engineering confidently and efficiently, thinking not for them but with them, and not robbing them of time to do their actual job (automation technology that works!).
What this has to do with these “integrated data models” from the IDEAS title? One step at a time. We have three steps in mind over the next three years of research:
Step 1: Implant the security engineering process into the automation engineering process
Security by design sounds good, we all agree on that. But it needs to be fleshed out a little: How does security by design work? Or: When is the earliest possible stage to in the engineering of an automated system to think about security?
The first step is to dissect the existing phases and subphases of the automation engineering process, look at what is required for each phase and what comes out of it, and examine if these results are sufficient to begin security engineering and if yes, how they can be used for security engineering. In the end, the plan is to have not only a point (or probably several points) where we can implant security engineering into the existing engineering process, but also a list of information and typical working documents that are relevant to security and that security in turn can complement.
Wait, implant? Yes, you read it correctly. Security should not just be a flanged-on appendage to the engineering process, but a natural part of it — as if security engineering had been planted into automation engineering. (And then properly watered).
Step 2: Develop an information model for security engineering
Now we have an idea how security engineering and automation engineering can merge to become automation security engineering. The list of information and typical working documents that are used from automation engineering for security and can in turn be supplemented by security is a good basis. If security didn’t want to grow up, but just reach school age, we could sit back now.
But the “big kids” don’t just have lists of information and document types, they usually have information models (here are a few examples). A picture is worth a thousand words, and an R&I diagram says more than a list of a thousand pipe lengths and pumps. And if you want to work efficiently, an information model that can be read and understood by computers says even more than a picture in ink on paper.
But whereas in automation — a result of decades of work on methods and standardization — information models exist in various degrees of maturity for almost every aspect, there has been a big black hole of nothing in security engineering up to now. The mountain of security-relevant information from automation engineering and the implanted security engineering cannot even be presented in a comprehensible way for humans, let alone for machines.
Security, however, depends on humans (yes, engineers are humans, too) understanding their systems and security properties, maintaining an overview of them, and recognizing attack opportunities before an attacker does. Our second step in the project will therefore be to let security engineering grow out of elementary school age and to develop both a human- and a machine-readable information model based on the input and output information for the implanted automation security engineering process.
Because we ultimately want to create something that is useful to automation engineers, we rely on modeling approaches that are familiar and proven for automation engineers. Good candidates are AutomationML and the digital twin in its Asset Administration Shell implementation. It’s good that we have real information model experts on board in the form of Rainer Drath and Emre Tastan from Pforzheim University and NAMUR, the User Association of Automation Technology in Process Industries.
Step 3: Build a security engineering tool for automation engineers
The last step is the reason for the legwork of the first two steps. After all, the most beautifully implanted automation security engineering process is of no use to anyone outside the academic ivory tower if it is not made usable, that is, if the process is too strenuous to live with and if no one looks at, maintains, and fills the information model. The transfer to practice will be provided in step 3 by a demonstrator for a security engineering tool that is usable by automation engineers.
So how do we find out if the tool is usable? We ask the potential users.
For the hard landing in reality — both for the engineering process from step 1 and for the tool from step 3, we have our application partners INEOS and HIMA, an operator and a manufacturer of automation technology. They will test for us whether the process and tool can withstand the daily work routine.
Finally, all three research questions in the IDEAS project are presented here at a glance:
IDEAS is funded by the German Federal Ministry of Education and Research (BMBF).
admeritia is project coordinator, Pforzheim University is research partner, INEOS and HIMA are application partners, and the User Association of Automation Technology in Process Industries (NAMUR) supports us with input from its working groups.
The project has a duration of three years (2021–2023).
Click here for the project profile (in German!) on the BMBF website.
