This is Part 1 of The OT Security Dozen – a 12-part series on building an OT/ICS cybersecurity program for an industrial operations environment.
Note: You may have noticed that operational technology (OT)/industrial control system (ICS) cybersecurity awareness is a common theme across "The OT Security Dozen," and hence no exclusive part on awareness itself. The aim for this series is to raise awareness on each type of controls covered, and therefore is considered an essential/integral necessity across this 12-part series.
In recent years, especially since the pandemic, the world has seen, read, and experienced a significant rise of cyber-physical attacks exploiting vulnerabilities and process weaknesses across multiple industrial sectors. This eventually leads to downtime and breaches, impacting business operations for organizations worldwide. And, if you’ve been reading industry threat intel reports and/or predictions for 2022, the future isn’t any brighter. To make things worse, the pace of digital transformation (to 4.0 or 5.0) driven by accelerated competition and growth isn’t going to slow things down either (on the contrary, it is going to accelerate it). This eventually necessitates the need for continuous cyber risk evaluation and measurement on the OT/ICS cybersecurity side in addition to attention generally being given on the information technology (IT) side.
I have spoken to several end-user organizations over the past two years on a wide variety of cybersecurity needs, guiding them on a typical OT/ICS cybersecurity strategy. Most of them were convinced that discovering and accessing the current OT/ICS operations cybersecurity maturity state is the first step. Since the pandemic, the Asia-Pacific market (APAC) has seen an increased awareness from industrial organizations to start exploring their OT/ICS cybersecurity journey by performing such reviews/assessments. However, many still struggle to understand and/or justify the need for such.
My goal for this blog is to help end user/operator organizations (especially those in the manufacturing sector) understand the typical drivers behind such assessments, dynamics of such an exercise or project, the type of assessment options available to choose from, and typical execution methodology for an increased awareness of the process. Ultimately, the goal is to familiarize oneself with engagement and execution processes for identifying OT/ICS cybersecurity risks and maturity state for creating a strategy and roadmap for building an OT/ICS cybersecurity program for continuous improvement and measurement.
Except for a few slightly mature industrial or critical infrastructure sectors (e.g., utility/power), many manufacturers in Asia-Pacific have just only started exploring or plan on doing OT/ICS cybersecurity assessments against their plant/production control networks environments (even though many of these manufacturers are part of global operations).
There are perceived myths or objections that some of the stakeholders within an end-user/owner/operator may have (e.g., it’s risky and would impact my production environment or my operations, nothing has happened to me, why would anyone want to target my environment, etc.). There's enough attack, incident, and breach data available to overcome and address such myths. Regardless of the industrial sector you are a part of, some other common drivers or triggers for such an initiative could potentially be compliance/regulatory-driven, in response to a breach/incident, led by digital transformation projects that warrants a closer look at cybersecurity, and/or other needs around improving overall risk visibility and awareness.
Typical Drivers for OT/ICS Cybersecurity Assessments
For OT cybersecurity assessments, clients depending on their industry needs and the maturity of their environment and where they are have few assessment options (with slightly different target goals) to choose from. Some of these options are presented below.
Options for OT/ICS Cybersecurity Assessments
If your organization is embarking on this journey for the first time, you should be a bit thorough in your assessment process vs. organizations that are much more mature and have done this several times. Whichever option you choose, the best approach is the one that combines both manual means (i.e., documentation reviews, interviews, and site walkthroughs) and technical discovery (i.e., logically collecting data utilizing different technical tools/techniques) and optionally supported with scenario-driven threat analysis to get a complete validated state of your operations. Simply relying on manual methods means that you are accepting the unknown risks that are not discovered until validated via technical means/techniques.
Once you’ve selected the direction, look to see whether you have the internal skillsets within the organization to perform such an exercise. If you lack resources and/or expertise, engage a trusted and experienced third-party consultant or service provider. Define the scope of the engagement and develop selection criteria for evaluating responses from third parties.
Note: More on how to evaluate and create criteria for third party/vendor assessment selection will be covered in future blogs in this series.
A typical OT/ICS cybersecurity project lifecycle approach spans across distinct stages:
For the purpose of this blog, Phases 3 and 4 are not discussed and will be covered in future blogs. We’ll keep a focus on Stages 1 and 2 for this blog.
Assessment execution follows an iterative process while performing certain tasks, with each step having a defined goal/milestone. Typically, such an engagement, depending upon the size, complexity, and industry sector, can take anything in between a couple of weeks to even a few months. The below diagram depicts an example of an execution approach and flow:
OT/ICS Cybersecurity Assessments – Execution Approach & Flow
In terms of the technical part of such an OT/ICS cybersecurity assessment/review, some of the technical analysis techniques that we can use to achieve our assessment goals are highlighted in the figure below at a high-level (without focusing on the tools itself).
OT/ICS Cybersecurity Assessments – Tools & Techniques
In terms of tools, a combination of certain specialized open source and commercial specialized OT security and IT security tools can potentially be leveraged. The key thing to note here is that by utilizing these techniques, we can get a high-value outcome with low or no impact to OT or production environment.
At the heart of the assessment is the OT/ICS network architectural review of the in-scope plant operations. This is often labeled with different terms such as OT/ICS network, plant or process control network (PCN), industrial automation and control systems (IACS) network, or simply the production network.
When it comes to analyzing the OT/ICS network architecture reviews as part of the assessment, a common approach is to analyze the environment and its traffic flow against ISA Purdue Reference Model (PRM), which is a method of grouping technologies based on their criticality to cyber-physical process. Below is an example figure highlighting the Purdue levels.
OT/ICS Network Architecture View – Purdue Enterprise Reference Architecture (PERA)
Organizations that follow PRM segmentation choose one of the following three options:
Several environments are also working towards building their OT/ICS cloud strategy as part of their industrial internet of things (IIOT)/Industry 4.0 or digital transformation initiatives by planning to push data out of OT to cloud/middle-ware, which eventually will require an approach with both north-south and east-west traffic controls and monitoring.
A secure OT network architecture is the first level of defense; a strong perimeter between business and production control or OT network is essential, but not enough. We will need to build additional sub-perimeters inside the control network. Therefore, Level 3/4 is the most important security perimeter and Level 2/1 are most critical because they directly influence the process. Within the controls network Level 0 to Level 3, we can create sub-security zones.
The ultimate goal to be able to build a reference architecture is to identify data flows within or between different security zones and whether the traffic is required to be allowed or restricted. Building these rules will help ensure that the attack surface is greatly limited. Everything that is accessible from your less trusted zone to your more trusted zone is an attack surface. The attack surface should shrink as you go further down the PRM, as shown in the figure below:
OT/ICS Network Architecture View – Purdue Enterprise Reference Architecture (PERA)
Note: More on this will be covered in Part 3 of this blog series. I've not shown the safety zone separately, however, several enforcements need to be in place for safety systems (i.e., ideally disconnected from other networks; air gaped may be desirable). However, in most safety information system (SIS) implementation scenarios, this is not possible because safety systems sometimes need to take over control from the primary logical control to tell the controller that it has seized control of responsibility of the operations. Apply protective controls such as unidirectional gateways/data diodes and ICS/OT firewalls between the systems. SIS is the most important system and will prevent the worst-case scenario. Attackers should never be able to get to safety systems.
It is highly recommended that as you progress through the process, you should identify if the system under consideration (SUC) has a proper business/asset inventory. If none exists, it’s important to build one. For each layer or level of Purdue model, start building a list of all hardware/software or system components. Knowing the classification and criticality of assets are essential to understanding which assets are critical to the production operations and/or deals with sensitive data. This will also help in discovering risks and vulnerabilities. You can’t protect what you don’t know exists.
Note: Building such a business/asset inventory and mapping all hardware/software/systems components is also going to be an invaluable and common step, especially if your environment is planning on initiating a Digital Transformation Maturity Assessment (DTMA) as part of an Industry 4.0 transformation.
Once you have done the manual and technical discovery along with the architecture review, now it is time to start defining the current security and maturity levels and plan to define target security and maturity levels. In order to do this, you will have the option to select and/or can define your own security and maturity levels as part of the analysis for building a model-based progressive improvement plan, depending upon the ease, familiarity, and maturity of your environment. For example, if you are using standards like ISA/IEC 62443 as the basis of your assessments, it’ll provide you with different security levels (target, achieved, capability) with ISA/IEC 62443-3-3 defining five different security levels (SL) (0, 1, 2, 3, and 4), each with an increasing level of security. For identifying current and target maturity levels, Cybersecurity Capability Maturity Models (C2M2) or Capability Maturity Model Integrations (CMMI) can be utilized in conjunction with security levels to understand relevant protection levels.
After analysis is done, the report should clearly highlight the scope with SuC and any limitations at the bare minimum. Ideally, the report should be divided into:
The Presentation should provide a concise summary of the report that is easy to digest and follow.
Note: More on reporting and presentation will be covered in future blog posts.
Below is an example of an OT/ICS cyber risk strategy mapped to different project lifecycles from strategy, architecture, implementation, and run/operations phases, while certain activities are mapped to four stages of prevent, predict, detect, and respond of the adaptive security model for OT security. Note that this is not an exhaustive list and presented as an example only.
OT/ICS Cybersecurity Strategy – High Level Example
If you haven’t done so before, immediately engage an experienced independent consultant/third-party to perform an IT/OT or OT/ICS-specific cybersecurity assessment. It’s important to identify assets, vulnerabilities, and risks to OT/ICS operation environments so as to apply preventive and detective controls. Ensure enough planning or preparation is done, and the project is socialized with relevant stakeholders to get appropriate time and resource commitments.
Once the outcome from assessment and potential gaps are available, you are on your way to building a secure-by-design OT cybersecurity strategy aligned with organizational business needs:
Based on your budget and resources, the aim is to constantly be maturing the OT/ICS environment.
Understanding your current risk profile to chart your future IT/OT/IIOT cybersecurity strategy starts with OT/ICS cybersecurity assessments (risk and maturity).
OT/ICS Cybersecurity Assessments – Next Steps
A version of this article originally appeared on LinkedIn. The author will be first featuring the series on this platform and encourages everyone to follow along in the SecuringThings newsletter.
See Intro blog here. See Part 2 here. See Part 3 here. See Part 4 here.