On Modelling for Security Engineering

as a Submodel of the Digital Twin

1 Intro

2 Why would anyone want models for security engineering?

2.1 What is on our “sheet of paper”?

2.2 Digital and algorithmically accessible models

2.3 Digital, algorithmically accessible, and standardized models

2.4 …and this is why everyone wants digital twins

3 Modelling crash course and disclaimers

3.1 Modelling means leaving out

3.2 Meta models

3.3 How to communicate models

4 The Digital Twin

4.1 Digital twin origins

4.2 Digital twin definitions

Figure 1: Digital twin main elements and ways of interaction, based on [3]

4.3 Digital twin goals

4.4 Digital twin standardization

4.5 A Digital Twin in action: The Asset Administration Shell (AAS)

Figure 2: Asset Administration Shell visualization
Figure 3: Asset Administration Shell with potential Submodels

5 A security engineering submodel for the digital twin

5.1 What do we need to model?

Figure 4: Minimum requirements for a security engineering system model, based on Layered Blueprints security engineering procedure model [14]

5.2 Modelling systems

Figure 5: Example system
Figure 6: Asset Administration Shell model for the example system, using the submodels Bill of Materials (BOM, grey) and “communications” (Comm, orange)

5.3 Modelling functions (FC)

Figure 7: Example function in comparison to the example system
Figure 8: Asset Administration Shell model for the example function, here: submodels Bill of Materials (BOM, grey), “communications” (Comm, orange) and the function (FC) layer of the submodel “Security” (Sec.FC, blue)

5.4 Modelling risks (RI)

Figure 9: Mapping the high-consequence event to a MITRE ATT&CK® for ICS technique. The technique T0833 “Modify Control Logic” (blue cell) belongs to two different tactics (columns): “Inhibit Response Function” and “Impair Process Control” [25]
Figure 10: Example attack graph with references to MITRE ATT&CK® techniques (red) based on [24] and references to targeted system entities (blue), leading to the previously identified high-consequence event.
Figure 11: Relationship between the Digital Twin “master” model and its visualizations
Figure 12: Combined system / function and risk / requirement view: Layering the threat scenario graph on top of the function model
Figure 13: Asset Administration Shell model for the example function, here: risk (RI) layer of the submodel “Security” (Sec.RI, red)

5.5 Modelling security requirements (RE)

Figure 14: Example attack graph with elliptical, red attack nodes including MITRE ATT&CK® references and rectangular, green defense nodes including references to any security requirement framework.
Figure 15: Asset Administration Shell model for the example function, here: requirement (RE) layer of the submodel “Security” (Sec.RE, white-green)

5.6 Modelling solution implementation (IM)

Figure 16: Example implementation suggestions for the security requirements, using the risk and requirments view containing the threat scenario graph
Figure 17: Combined system / function and risk / requirement view containing information on system, function, threat scenario, security requirements and their implementation along with impacted systems.
Figure 18: System view, now containing security requirments and their implementation
Figure 19: Asset Administration Shell model for the example function, here: implementation (IM) layer of the submodel “Security” (Sec.IM, green)

6 Where can this lead? Modelling visions

6.1 Engineer-accessible security

6.2 More systematic security testing

1.3 Security at the push of a button

6.4 From security engineering to resilience engineering

6.5 Open issues

7 Thank you!


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