SCADA Sssh! Don’t Talk, Filter it

The effects of cyber-attacks against SCADA/ICS are well known, however, there is a great confusion when dealing with mitigation techniques.

The Majority are aware of the impact cyber-attacks can have on Industrial Control Systems however, the reality in terms of mitigation techniques are shrouded with confusion and a reactive approach. Recent 0-day vulnerability dubbed as ‘Panel Shock’ found in Schneider Electric’s SCADA Human Machine Interface (HMI) device panels send ripples of fear and doubts in the industry; somehow dirty linen has been exposed again.

The media generally refer to all Industrial Control Architectures as SCADA and to avoid autocratic debates with various security voice groups we will continue this trend. It is not difficult to map the behavior classification of SCADA attack patterns by observing recent campaigns such as Havex, Black Energy and Stuxnet etc. In these attacks, the malware was mostly distributed by Phishing attacks aimed at executives not on the ICS network and Watering hole attacks on ICS vendor software delivery websites.

Assessing the Threat

No golden rules exist of how to assess the threat, however, the question that is queried most is ‘where do organizations initiate to assess the threat’? Within RSA Advanced Cyber Defence Practice we follow the domains/ framework to assess and formulate responses to ICS/SCADA threats.

In our forthcoming blog with Gareth Pritchard (Advanced Cyber Defence Consultant EMEA) and Peter Tran (Snr Director Advanced Cyber Defense at RSA blog site https://blogs.rsa.com/ will be a detailed analysis on each domain.

For today’s article, I want to focus on the element of ‘filtering the white noise ‘

One of the core failures of SCADA-based organizations is their inability to filter white noise by dissecting incidents through the combination of hunting, intelligence gathering, and incident attribution. They fail to build a ‘proactive’ customized Use Case library that is required to detect specific and tailored threats targeted at the company. One of the suggested strategies could be a hunt and response strategy i.e.

1)        Develop: UseCase Development Strategy

1. Initial UseCase development. Create tailored use cases from theory, practice and experience to detect the top; imminent, perceived or previously detected threats affecting the company. For example ICS – UseCase #1 “Unusual/Unplanned OPC Scan”, ICS – UseCase#2 “Suspected C2 communication”, IDS via Emerging Threats

• i Analysts respond to the alerts generated from the new Use Cases.
• ii Intelligence teams add context and if possible attribution to the detected threats.
• iii Content Engineering teams tune use cases from analysis, attribution and context.
  • Analysts respond to the alerts generated from the tuned Use Cases.
• Engineering and Intelligence: Detect & Collect threat data to support additional UseCase development

Develop tailored metrics / reports to detect current threats based on real world network data.

i)        Report 1: Critical Anomaly

• Develop metric reports to display anomalous traffic patterns occurring on critical systems via whitelisting expected traffic and displaying the remaining traffic from these devices on a pre-developed reporting template.

• Collect log, packet and net-flow data for 30 days, analyses and condense the report data into a data analysis and metric report in order to highlight and add context to suspected suspicious traffic patterns.

• Present and discuss the findings in a meeting with the administrators and engineers of the monitored critical systems to assist in identifying the suspicious, anomalous traffic which may be used to develop additional UseCases. (Fringe benefit = Engage and seed relationships with infrastructure teams, especially those related to critical systems)

• Investigate and consolidate threat Intel from perceived anomalous traffic and create custom use cases from this data along with perceived attack scenarios.

3) Hunt: Implement Hunting Development process.

• i Hunters find new threats on the network and raise incidents for investigation.
• ii Intelligence teams add context and if possible attribution to the detected threats.
• iii Content Engineering teams create use cases from the newly acquired indicators.
• Analysts respond to the alerts generated from the new Use Cases.
• iv Intelligence teams add context and if possible attribution to the detected threats.
• v Content Engineering teams tune use cases from analysis, attribution and context.
• Analysts respond to the alerts generated from the tuned Use Cases.

4) Enhance: Review UseCase Library

Analyse reports number of times each UseCase has triggered alongside the appearance of indicators present in the logic of the UseCases. Determine if the UseCases are erroneous or no longer valid.

Submit report to the Content management team to repair erroneous UseCases and archive UseCases which are no longer useful or relevant to the SOC.

• Removal of unnecessary defunct, UseCases will assist in keeping the UseCase library current and in line with the current threat landscape and also assist production appliance optimisation and good maintenance.
• Respond: Optimize and Advance roles

• i Expand Hunting and Attribution capabilities to include dark net operations.

• ii Expand L2 analyst capabilities to include malware analysis and basic remote forensic collection and analysis of forensic images.

• iii Expand L1 analyst capabilities to triage, analysis, response and closure of low priority incidents.
• Enhance: Management reporting and Success factors

Conduct 6 monthly reviews to gage success, knowledge gaps and training requirements.

Run 6 monthly and annual reports highlighting costs saved as a direct or indirect result of breach prevention and breach disruption. Use this data to qualify funding in order to enhance and Advance the SOC via analyst training, appliance upgrades and user awareness events.

The above process is only one step towards the development of mitigation process for ICS environment. Organizations need to avoid siloes working compartment and not in my backyard mentality to develop a more robust holistic process. See RSA blog next week for framework analysis.

Suggested Reading

INDUSTRIAL CONTROL SYSTEMS (ICS) AMBIGUITY?
http://blogs.rsa.com/industrial-control-systems-blog/

About the authors:

Azeem Aleem

Director  RSA Advanced Cyber Defence Practice  EMEA

An experienced information security executive with over 15 years of practitioner experience in cyber defence technologies, security operations, counter threat intelligence, data analytics and behavioural classification of cyber criminal.

As a subject matter expert, he has made frequent appearance on regional television and radio programmes as an expert on cyber threats. A published book author and academic criminologist, he has also authored several periodical on advanced security threats in peer-reviewed journals and security magazines. He is an eminent plenary conference guest speaker both at the national and international level.

Gareth is a consultant for the Advanced Cyber Defense Services Practice – EMEA. In this capacity Gareth is responsible for professional services engagement for Global Incident response/Discovery (IR/D), breach readiness, remediation, SOC/CIRC redesign.

Gareth has over 10 years of experience in Information technology focusing on root cause analysis of infrastructure and cyber security related issues. This has led to a broad knowledge base of remediating problems and designing processes and procedures to assist in the prevention of issues arising in the future.

Gareth has studied various technologies and has a broad wealth of experience in application scripting, web design, malware analysis, big data correlation, data mining and windows / Linux technologies. This knowledge has been paramount in learning more about the current threats and tactics used by cyber criminals in the cyber security threat landscape.

[adrotate banner=”9″]

Pierluigi Paganini

(Security Affairs – SCADA, hacking)