Threat modeling the edge: Building security into industrial control systems
Threat modeling the edge: Building security into industrial control systems
In using threat modeling during the development phases to ensure secure code and defence mechanisms are implemented during design and development, a process known as DevSecOps, cybersecurity issues can be prevented entirely rather than being managed at a later date.
Foreword: Edge computing and cybersecurity
Increased efficiency, availability and productivity demands have provided the essential requirement to change the industrial process control infrastructure. Edge computing utilises IoT micro-powered devices to transfer critical process services, which were previously managed remotely in the cloud or data center, to within a close proximity – this helps to meet the market’s increased demand for access and speed.
However, the advantages of an edge computing infrastructure pertains to certain cybersecurity-related matters that should be addressed during the development phase. Risks can include information theft, control system network hacking, communications disruptions and even sensor data manipulation/falsification.
Recent best practices and industry acknowledgment justifies employing threat modeling during the initial stages of project development to detect security issues. This approach means that security measures and layers can then be subsequently incorporated in the edge computing infrastructure during early design and development stages, rather than making security checks later on in the process which can be time-consuming and expensive.
There are many different applications proposed for edge computing including:
- Remote monitoring of industrial plant assets
- Autonomous vehicles
- Smart grid
- In-hospital patient monitoring
- Traffic management
- Smart homes
An overview of edge computing infrastructure
The drive towards edge computing technology supports increased process manufacturing efficiency, while further reducing plant personnel contact. Edge computing employs robust low-energy consumption IoT devices to control local plant processes in an effective and efficient manner.
Edge devices receive input or send output signals from/to plant devices in one protocol (4-20mA, HART, Fieldbus etc) and output the data in another protocol format to the cloud. The data is analysed and sent at intervals to the cloud for further analysis and complex processing. The corresponding data is stored locally at the IoT devices as well as in the cloud where the critical processing is executed.
Edge computing is currently in a rapid adoption phase and generally applied in brownfield stages, whereby existing systems are met by new ones. The migration processes for brownfield projects can provide obstacles and further security risks of existing outdated/unpatched devices or software present in the existing architecture. Edge computing architecture can also be integrated or adopted in the green field stages of a project – freedom to develop without legacy systems – which gives rise to the opportunity of integrating critical security layers and countermeasures against weaknesses before the systems are installed and initialised.
Figure 1 below presents an overview of a typical edge computing architecture.
Cybersecurity-related issues – Case study: Basic edge computing industrial plant focus
A basic edge Computing model and corresponding components are analysed for threats and weaknesses using a threat modeling platform. Figure 2 shows the main architecture, this is a limited application exercise and projects may vary vastly in complexity and architecture.
The threat modeling process employs a four-step process, centred on the questions:
- What are we building?
- What could go wrong?
- What are we going to do about it?
- Did we do a good enough job?
The output of step two is typically a list of security threats, while that of step three is a list of security controls or risk acceptance decisions. In the case study, various best practices and standards have been applied during the threat modeling process to help guide steps two, three and four – including security publications by NIST, OWASP and MITRE amongst others.
Step one – Define the architecture
The first step in the process is to define the overall architecture of the system using something like a data flow diagram (DFD). This should include key components, their locations in trust zones and the data flows between them.Component name:
- Cloud storage
- IoT application
- IoT operating system
- Microservice
- S3 - Simple storage service
- VPC - Virtual Private Cloud
- Web application - Server side
Step two – Identify the threats
Table one shows the distribution of the threats corresponding to the risk level for all components in the associated case study. Results shown in the table provide an indication that even a basic architecture consists of critical and high risk issues that fundamentally must be addressed.
Table 1: No. of threats derived/risk level for all components exposed in the architecture
Select threat examples exposed during step one immediately provides an initial indication of present security gaps for remediation. Threat modeling provides a form of security auditing against predefined security use cases, threats and corresponding control actions. The threat modeling process covers different aspects of attack vectors considering best practises and known vulnerabilities. Various libraries and standards are converged and applied to the model to derive the security risks and countermeasures that should be considered and implemented in the development stage of the project cycle.
Table 2 below provides example cases related to the types of component threats returned from the threat modeling.
Note1. Control actions are limited select examples, other remediation and mitigating actions should be covered to ensure an overall secure component.
Threats presented from the model have a direct indication of critical security issues that pertain as risks to the owner’s assets. Threats include exposure of sensitive information through exploitation of vulnerabilities, unauthorised access to accounts due to lack of secure configurations.
Other threats can also affect not only the owner but also the customer, effectively having a direct impact on profits and company reputation. In the worst case scenario, complete control of the plant or denial of service attacks could be executed by a threat actor, crippling systems and potentially causing catastrophic failures of critical plant safety mechanisms.
Other types of attacks on this particular sector could include wireless signal attacks, rendering the IoT devices unresponsive or subjected to communication interruptions. Physical attacks on devices, ports, protocols and services, implying service degradation and interruption, can render a plant's critical safety functions incapaciated.
Step three – Identify control actions from the threat model
Identified control actions represent a basis for security measures to be enveloped in and around the subject application. The control actions are correlated on a step-by-step basis as the security mechanisms are implemented into the design as per each and every essential requirement. Due diligence and careful consideration of countermeasure implementation supports a secure by design application during generation stages.
Providing the appropriate corresponding cybersecurity best practises and standards have been selected, the associated control actions will cover all aspects of the essential security layers. Control actions will benefit not only the architecture but also support with the suggestions of staff training and physical security appraisals. An example is possible divulgence of sensitive information; the control action to defend against this threat would be to consider only allocating privileges via groups or roles – only allow sufficient privileges to complete the required tasks – or server-side and in-transit encryption. The control actions derived from the threat modeling justify the essential requirement to conduct the security implementation during the development cycle.
How to implement the threat model into the development cycle
According to industry standards and reputable sources, e.g. Gartner, depicted in diagram 1 below, threat modeling should be integrated into the first phase of the DevSecOps Toolchain, as early as the planning stages. Conducting dynamic threat modeling during this stage ensures an increased level of overall security per component. Negligence of threat modeling in the early stages will potentially impede the development cycle, there may be rework requirements to close security gaps, correction of any essential security issues will be compulsory and possibly result in project delays.
Threat modeling gives rise to a perfect opportunity for developers and network architects to conduct secure code design and recommended network security practises respectively, without having an expert level of cybersecurity experience or enhanced comprehension of the security requirements. Threat modeling should be implemented in the design phases of the equipment and system so that underlying security design flaws can be identified and the appropriate risk response and security controls properly planned.
Final reflection
Threat modeling is an activity aimed at supporting the development of secure systems by analysing them at the architectural level. This technique enables the user, even developers or network architects with minimal security expertise, to provide security input for the software and hardware design in the early development stages. In turn, threat modeling minimises the risk of rework to implement overlooked security issues which were not identified.
Threat modeling is not only an excellent option for software but, as proven in the aforementioned case study, it's an extremely efficient method for security gap analysis when applied to industrial plant or edge computing architecture.
