Responding to an ICS incident in 4 steps
Incident response in Information Technology (IT) and Operational Technology (OT), or in Industrial Control Systems (ICS), may look very similar, but it involves different considerations and priorities.
Many organisations use their existing IT incident response capabilities in an OT environment, which may not be ideal for successful incident response and for safe, reliable operations. Understanding these gaps and closing them before an incident occurs is the key to a successful ICS incident response.
The skills required in an OT and ICS environment are also different, but they can be acquired through training: active defence and incident response, and by leveraging industry experts.
Preparation and planning
Roles, responsibilities and decision-making processes must be extremely clear when responding to OT Cyber-Physical Security incidents.
ICS incidents must take into account the potential consequences for life, safety and property that can result from both the incident itself and the response actions taken.
Successful response plans define a clear decision-making process that includes business leadership, security, operations, IT and the Incident Response Team (IRT).
When planning an Incident Response (IR), it is also important to make sure the plan has been reviewed by compliance and safety officers, because safety actions – such as shutting down certain systems or evacuation plans – may conflict with incident response objectives.
Regulatory reliability standards, notification requirements and other obligations must be carefully assessed for your specific sector to ensure you remain compliant from the initial response through to recovery.
Before an incident occurs, it is essential that organisations make an effort to identify all the assets that can interact with the ICS environment: without this fundamental understanding of which assets are present, organisations will struggle to respond quickly and restore the system.
Asset identification does not necessarily have to be an active scan of a network; it could be as simple as a physical survey of the site, a reconciliation of design drawings against the current state, or a review of traffic flow information both within the control network and across the corporate firewall.
Visibility and detection
ICS environments are generally extremely static in nature, very prescriptive in their communications, and do not have a large number of human users introducing unpredictable behaviour.
These environments are ripe for behavioural analysis, and anomaly detection is made much easier. By contrast, with IT networks it is often almost impossible to develop a well-established network baseline.
An example: once a baseline has been established, the network monitoring team should examine new communications to assess whether they are actually part of an approved change and of a new routine operation. Since ICS systems are unlikely to communicate with new external servers after installation, this is an excellent technique for detecting intrusions before the system is compromised.
Coordination and communication
While coordination with other parts of the company is important in IT incident response, it is absolutely essential when carrying out incident response in an ICS environment.
Even with excellent planning and preparation, ICS incident response actions may affect the safe and reliable operation of the system.
An example: taking away a user’s laptop to create a drive clone may be an inconvenience, but removing an operator panel to work on it may remove visibility of key processes or affect emergency response procedures.
This is why it is crucial that information flows: users must have a full understanding of the consequences of their actions, with the consent of the operations team, before taking those actions.
Incidents in ICS environments also tend to receive far more “media attention” than typical IT incidents: even a common malware infection can turn into a serious problem if it occurs in a critical facility. It is therefore also important to involve the public relations team early in the process to develop a communication plan for internal and external stakeholders.
Sharing
The ICS community is a small, close-knit group of operators, engineers and technicians. There is still a mindset of shame and concealment when it comes to reporting incidents in our ICS environments. Culturally, this is a challenge we must overcome, because intrusions at one facility may contain information on techniques and procedures that will be exploited at another facility.
It is essential that organisations share information both within and outside the sector during and after Incident Response activities.
Only by working together can we minimise the risk.