Cyber attacks on Industrial Control Systems (ICS) are on the rise, with an aggressive shift towards process control networks with connectivity around enterprise internet and the cloud. The landmark attack on Safety Instrumented System (SIS) through TRITON malware, for example, has once again shown ambiguity in the security of the ICS environment, which is becoming increasingly complex and difficult to decipher as almost all systems have IP-based interfaces and computation automation.
In the last few years, a number of specialised companies have been providing well-defined support in this area. However, overall, there is limited industry expertise around ICS IT and cybersecurity. As a result, most vendors and organizations use generic security methodologies, resulting in a more reactive approach.
Mitigation techniques shouldn’t just focus on the perimeter, which means deploying more and more new technologies. Instead, organizations need to follow an intelligence-driven security framework or phased approach.
To achieve the state of so-called ‘Cyber Swing’ (like ‘Swing’ in rowing – that state of near perfection when all rowers are in harmony with no wasted energy) within an ICS environment, organizations need an incremental strategy in the following three key areas to help them reach a stage of security maturity and to pre-empt advanced attacks.
1. Requirement Analysis
Requirement analysis is about developing a responsibility assignment matrix (RACI model) around domains (including people) to develop a layer of accountability and consultation. The mandatory mapping of the complete network (from layer 0-5) is crucial. This will create visibility and allow organizations to critically evaluate the network around air gap, partitioned/flat, protocol/service and systems assessment. Most organizations come across the following blind spots during analysis:
- Remote connectivity: If the discovery highlights that the network has permanent remote connectivity then it should be very tightly configured and monitored. All management/change control should be vetted and verified by multiple personnel to ensure that the network is secure. Organizations must ensure encryption prior to transferring any data between the internet/IT network and ICS network.
- Patch management: Downloading new firmware should be scrutinized closely; MD5s should be verified against a predefined supplier list from the vendors. Segregating Human-Machine Interfaces (HMIs) will help prevent direct incursion and reduce the human vulnerability element from the attack surface.
- Network topology: Most ICS environments have a flat network topology, which is difficult to monitor. The recommendation is to re-design the network architecture, zoning the network and creating monitored choke points with appropriate controls that can be used to both block and detect suspicious traffic occurring between the zones.
2. Intelligence Collection and Storage
There is no shortage of threat intelligence; in fact, there is so much intelligence available, it can be difficult for organizations to decide what is relevant to their specific environment and circumstances. In other words, how do I decide who is attacking me and how do I define their footprint?
‘Actionable Intelligence’ is the output of collected information, leading to a set of data that, once analysed, can be used in the defence and contextualization of events on the network.
ICS organizations will need to define the parameters of their intelligence for the purposes of:
- Business and risk alignment: This is about understanding the mission, scope and authority needed to mitigate risk.
- Visibility: Define the visibility required to achieve mission readiness.
- Content: Build enablement for detection — including use cases, situational awareness, and baseline.
- Applied intelligence and analytics: Analyze, attribute and predict the threat to refocus the mission.
3. Incident Response
There are two areas where we are failing within ICS environments: having a preventive mind-set, and ‘analysis paralysis’ syndrome. In the first instance, we should be able to understand the attack telemetry by creating end-to-end visibility through appropriate tools and procedures. In the second, organizations need to accept that they will be breached and move towards more proactive analysis that enables them to integrate a single normalised platform to detect the behavioral classification of cyber criminals.
To develop a proactive incident response (IR) strategy, contacts must be agreed for various scenarios, including third parties, such as government officials, ICS-Cert, and support groups, which have been pre-established to assist during critical incidents on the ICS network.
Tools used to collect and analyze data from all ICS assets should be carefully tested and confirmed to provide the level of detail required. These tools should be documented and stored in an ICS-IR pack ready for deployment when an incident occurs. The IR pack may need to be stored onsite for engineers to access as required to support an incident.
Any critical processes must be tested, analyzed and updated on a regular basis in order to ensure all personnel involved are fully prepared and capable of quickly, efficiently and safely achieving the required objectives.
It may not be possible to perform these exercises on the ICS infrastructure directly, however table-top and ‘blue team’ exercises provide a virtual environment to ensure all processes are followed successfully and identify potential issues that may occur during a real-world incident.
During response, containment and remediation, all details should flow through to the content creation and intelligence teams, in order to develop rapid detection content and to research additional indicators of compromise (IOCs) and Tactics, Techniques & Procedures (TTPs) for the analyst to monitor for additional assets or threats that have not yet been identified.
The first response during an incident should be to determine the impact of the threat. If the threat is deemed to be neutral or mitigated, the containment phase can be skipped and the remediation phase invoked. If the threat is realised, or imminent, the criticality of the incident should be confirmed and the ASOC manager made aware of the situation. An ICS engineer should be contacted to help collect data for quick analysis, and a containment plan put in place.
Once an incident is contained, the recovery can be postponed until the next scheduled maintenance window when the clean up of the asset is conducted in line with the usual maintenance activities.
In some cases, the maintenance window may need to be brought forward to remediate the asset immediately. This activity would require ‘business as usual’ processes to be expedited so remediation can be undertaken outside of the scheduled maintenance window. Evidence of why the remediation activity is required immediately should be provided in order for a business risk decision to be made.
Unlike traditional incident response, forensic analysis must take place following containment and remediation. Full forensic analysis should be conducted to determine how the breach occurred and uncover previously unknown vulnerabilities to enable a plan to be developed to further strengthen and protect the network.
A full and detailed analysis report should be produced at the end of the forensic analysis phase, which will identify any previously undetected indicators and allow assets to be fully remediated, intelligence databases to be updated, and content management to update the detection content for future threats.
In summary, the processes outlined above are only small steps towards the development of a comprehensive proactive mitigation process for an ICS environment. Organizations need to avoid working in siloes or creating a ‘not in my backyard’ mentality so that a holistic process can be developed. There is no such thing as an isolated security incident; instead there is a need to develop robust threat intelligence capabilities based on tactics, techniques and procedures.