Imagine you’d have a digital representation of your assets, or your critical functions, that summarized all security-relevant aspects in one model.
Not a perfect reflection at all, but perfect enough to do security engineering. Imagine you could compliance-check that representation against security frameworks. Adjust it if your assets used different protocols, had different users, or there were new known vulnerabilities. And push the “apply” button so you could transform your security configurations of choice into reality.
Imagine you’d have a digital twin for security engineering.
Almost two years ago, I introduced the concept of Layered Blueprints, a lighthouse-shaped procedure and system model for security engineering.
You may or may not remember the last slide where I said I hoped we as a community would not build lonely security engineering lighthouses of our own, but entire skylines of lighthouses we could share and discuss.
I’m excited this is atually beginning to happen. Last week, Ron Brash picked up the Layered Blueprint concept in a blog post — in the most pragmatic manner I’ve seen to date. Taking a Blueprint for an HMI as an example, he walks his readers through the different lighthouse layers and, most importantly, poses the question how a blueprint can be maintained throughout its lifecycle. Taking this idea further, a skyline of blueprints could be created by taking a new lighthouse for each asset class — HMI, PLC, engineering PC, and so on — or for each associated function — operating through an HMI, programming a PLC, and so on.
Due to his position at Verve, whose product is an ICS inventory and detection tool for OT environments, it’s natural that Ron looks for ways
- how suchlike tools can help creating blueprints
- and how the layered blueprints in turn can help these tools.
In this article, I’m adding a few thoughts to these questions, culminating in the most ambitious one: How Layered Blueprints could be transformed into a digital twin for security engineering.
Quick recap: Layered Blueprints models
In order to create common ground, here’s a quick reminder how the Layered Blueprints model works:
While walking through the security engineering procedure model on the left (from bottom to top), a system model (“blueprint”) is created and refined with each additional layer, until at the last layer, the blueprint contains all relevant information to facilitate a secure implementation.
We now take an inventory and detection tool’s perspective and see how tools can help the blueprints — and how the blueprints can make tools mightier.
Function layer: Insights on communication and usage
To stay in Ron’s HMI example, in the function layer we collect information typical communication and usage of the HMI.
This can all be done based on interviews, hoping to tickle people enough so they come up with all relevant information, but having a tool that provides hard data to work with would be a big help.
A detection tool can help creating a communication profile by providing this hard data, for instance about used protocols, established connections to other systems, user logins, or user account lists. All of this is valuable input to creating communication profiles for certain assets or certain functions. Chances are the tool-generated data points to ways of usage interviewed people don’t know about or just forgot to mention.
If you work through user logins, you can see if there’s a user group doing something you forgot thinking about. Also, questions regarding communication protocols and used ports are not always easily answered by a user or engineer, but a scanning tool can provide that insight.
In turn, any tool benefits from a blueprint model as an intuitive representation of all its “hard data”.
Risk layer: Vulnerabilities and threat intel as a source of inspiration
The risk layer is all about taking your modelled functions and communication profiles and see what could go wrong. If you have a platform in place providing vulnerability scans and / or threat intelligence — by all means make us of that information! They’re great to spark your inspiration when it comes to feasible threat scenarios.
By the way, so are penetration test results or frameworks like ATT&CK, but they’re not necessarily tied to ICS tools, so I’ll leave that for now.
At the third layer, individual requirements are developed for our example HMI, and they can (most times: should!) be formalized to fit into existing requirements framemworks — be it NIST CSF, ISO/IEC 27001, IEC 62243, or something your organization created itself.
And blueprints for your assets like your HMI, as Ron has explained in his blog post, need to be validated. For which you need clear requirements to validate against.
Using your ICS tool, you may want to prove your assets are compliant with some frameworks’ requirements — and the blueprints are an excellent collection of requirements your assets fulfill (or should fulfill, at this point). And obviously a tool can do this compliance check for you.
For the sake of the suspense curve, I’m happy this layer happens to come last. The implementation layer is where the most exciting opportunities for synergies between tools and blueprints arise, and it’s the reason I decided to write this article.
Until the implementation layer, you could argue the blueprint benefits more from a tool than vice versa. However, if you’ve come that far, the implementation layer is the tipping point where actually a tool benefits more from the blueprints.
Does your tool do configuration management? Do you aim for configuration baselines? Great. Because if you’ve validated and deployed blueprints, you also have standardized security configurations, or to quote Ron:
“Perhaps obvious, or perhaps not, as I built out that simplified process diagram, in the maintenance phase I realized that if you monitor the risks on the endpoint blueprint systems (e.g., made a live version of them even as a virtual machine), you can effectively have a security benchmark across your organization for free.”
If you actually created soft-prototypes and then prototypes for your blueprint, you have a way to apply these configurations to all assets for which that blueprint applies (all HMIs, in our example). Imagine an “apply blueprint”-button that makes sure your security configuration is the way it should be. And imagine how happy you’d be once you disover that for each security configuration, you can drill down to lower layers of the blueprint to see corresponding requirements, risks, and functions at all times.
It’s an ambitious goal, but if you get all the way to prototyping blueprints (all layers, not just the implementation layer), they are more than a document helping you structure your security engineering.
Digital Twin for Security Engineering?
As soon as your blueprint prototype hits implementation, it becomes a digital representation of the asset or function it was created for, summarizing all security-relevant information in one model.
Or, in more fancy terms:
A digital twin for security engineering.
Because to be useful for security engineering, a digital twin does not need to be a perfect reflection of the original, just of its security-relevant features. And the Layered Blueprints summarize everything security-relevant.
I’m not using “digital twin” as a buzzword here, but in its original meaning as defined by the IIC:
“A digital twin is a formal digital representation of some asset, process or system that captures attributes and behaviors of that entity suitable for communication, storage, interpretation or processing within a certain context.
The level of abstraction of a digital twin is such that it is sufficient for the requirements of the use cases for which the digital twin is designed.“
The challenge moving forward will be to create an implementation of a layered blueprint prototype which is practical, maintainable, and open enough to interface with digital twins created for other purposes than security.