Supervisory Control and Data Acquisition (SCADA) system security

SCADA Real time industrial process control systems used to centrally monitor and control remote or local industrial equipment Frequently used in chemical plant processes, oil and gas pipelines, electrical generation and transmission equipment, manufacturing facilities, water purification and distribution infrastructure, etc. Vital components of most nation’s critical infrastructures

SCADA Systems Highly distributed Geographically separated assets Centralized data acquisition and control are critical Oil and gas pipelines Electrical power grids Railway transportation systems Field devices control local operations

Process Control System (PCS) Safety System Source: US-CERT_Chile_2007-FINALv2.ppt

IP-Based Industrial Control Systems ODVA (Rockwell) Profinet Foundation Fieldbus HSE Telvent ABB 800xA Honeywell Experion Emerson DeltaV Yokogawa VNET/IP Invensys Infusion Survalent IP to the Control Network or even Device Network

SCADA Security Perimeter Protection Firewall, IPS, VPN, AV Host IDS, Host AV DMZ Interior Security Firewall, IDS, VPN, AV Host IDS, Host AV NAC Scanning Monitoring Management

Attackers Script kiddies Hackers Organized crime Disgruntled insiders Competitors Terrorists Hactivists Eco-terrorists Nation states

Programmable Logic Controllers Computer based solid state devices Control industrial equipment and processes Regulate process flow Automobile assembly line Have physical effect

PLC Code Vulnerabilities Through SCADA Systems Sidney E. Valentine, Jr. The University of South Carolina Computer Science and Engineering The following slides are modified from the PhD defense of Dr. Sidney Valentine

Currently there are working groups that have been created for the various infrastructure sectors of water, electricity and natural gas [6, 9] US Departments of Energy and Homeland Security each have written white papers and begun initiatives to begin investigation into the problem domain of SCADA systems in general [12, 3] Related Work

”it is important to note the use of the term SCADA, as these same technologies have not been employed on many legacy non-SCADA devices such as programmable logic controllers (PLCs), electronic drives, process sensors, and other field devices.” [13] Related Work

Traditionally vendors focused on functionality and used physical security measures[7,8] An attempt was made to try to “match” physical security mechanisms online In creating our vulnerability chart, we look at types of vulnerabilities as well [12] Classification by affected technology Classification by error or mistakes Classification by enabled attack scenario Related Work

Creation of a Taxonomy of Vulnerabilities and their Severity Levels Development of models of these vulnerabilities and mitigation strategies PLC-Security Framework: Prevention, detection and removal of these vulnerabilities Proof of concept implementation Research Overview

SCADA and PLC Overview

Ladder logic overview What is ladder logic? Why is it the programming language of choice for automated control systems? SCADA and PLC Overview

Standard Relay Points (1) and (3) – NO Contact Points (2) and (4) – NC Contact Points (5) and (6) – Activation Coil SCADA and PLC Overview Standard PLC Contacts and Coils NO Contact NC Contact Activation Coil

Standard Ladder Logic Diagram SCADA and PLC Overview

Overview of PLC Hardware Configuration Types Block Rack Mount PLC CPU Input and Output Cards (or Connections) Analog or Digital DC or AC SCADA and PLC Overview

Increased risk to SCADA systems, introduces another element of risk to the PLC and all of the control elements PLC’s dictate the functionality of the process PLC programming software and SCADA control software can be housed on the same machine The newest PLC hardware devices allow for direct access to the PLC through the network SCADA and PLC Security

SCADA System Control Flow

“Prior to the Stuxnet attack (2010), it was believed any cyber attack (targeted or not) would be detected by IT security technologies..” [13] Therefore, it is imperative that a standard be implemented that would allow both novice and experience PLC programmers to verify and validate their code against a set of rules. How do we show that PLC code and be verified and validated to assist in the mitigation of current and future security risks (errors)? SCADA and PLC Security

PLC Security Framework (PLC-SF) Static Analysis Tool: Compiler Workflow

PLC Security Framework (PLC-SF)

Components: PLC Security Vulnerability Taxonomy Design Patterns Severity Chart Engines: Taxonomy Engine Design Pattern Engine Severity Engine PLC Security Framework (PLC-SF)

Attack Severity Analysis Building the Vulnerability Taxonomy Potential Exploitation of Coding Errors Modeling PLC Vulnerabilities Vulnerabilities Analysis

Each row of the Severity Chart represents a different level of security risk, within the PLC error found The error levels range from A – D, with A being the most severe and D being the least severe Each column represents the effects which can occur in the PLC and those that can occur in the SCADA system PC Attack Severity Analysis – Severity Chart

SeverityEffects in PLCEffects in SCADA APLC Code will not perform the desired tasks Will not allow for remote operation of the process BSerious hindrance to the process The process could experience intermittent process failure CAdversely effects PLC code performance. A minimal cost effect to the project, but a “quick fix” is possible Data shown on the SCADA screen is most likely false DEffects the credibility of the system, but the PLC code is operable Incorrect data could be randomly reported, cause a lack of confidence in the system

Severity Classifications: Severity Level A: Could potentially cause all, or part, of a critical process to become non- functional. Severity Level B: Could potentially cause all, or part, of a critical process to perform erratically. Severity Level C: Denote a “quick fixes” Severity Level D: Provide false or misrepresented information to the SCADA terminal. Attack Severity Analysis – Severity Chart

Purpose: To aid the process of detecting these vulnerabilities in the PLC code Intended to be extensible Created such that it can be expanded as: Future versions of PLC’s are created New errors are found Building the Vulnerability Taxonomy

Vulnerability Taxonomy: Software Based (Virtual) Errors

Software Based (Virtual) Errors: Attributes: Error Class Possible Value: Design Level Error Error Sub-Class Possible Values: Logic Errors, Duplicate Objects Installed, Unused Objects and Hidden Jumpers Building the Vulnerability Taxonomy

Logic Errors: Attributes: Sub-Class Possible Values: Placement and Element Component Errors, Scope and Linkage Errors Placement and Element Component Errors Possible Values: Beginning of Rung Functions, End of Rung Functions Building the Vulnerability Taxonomy

Potential Exploitation of Coding Errors Error TypeTaxonomy Classification Malicious User Opportunity Process Critical / NuisanceDuplicate Objects InstalledAlterations of one or more of the duplicate objects Process CriticalUnused ObjectsPre-loaded variables allow for an immediate entry point into the system Process CriticalScope and Linkage ErrorsInstallation of jump to subroutine command which would alter the intended file to file interaction Process CriticalLogic ErrorsImmediate entry point to logic level components such as timers, counters, and arithmetic operations Process Critical / NuisanceHidden JumpersWould allow for a placement point for a system bypass

State Transition Diagrams Approach: motivated by the success of using state transition diagrams to model intrusion patterns [16, 22] We create state transition diagrams to represent vulnerabilities Modeling PLC Vulnerabilities

PLC Ladder Logic: Race Condition

State Transition Analysis: Race Condition

Purpose: To provide guidance to the developer to remove the vulnerabilities detected Methodology: We have developed a set of design patterns supporting targeted best practices guidelines for the ladder logic software developer Goal: Our goal is to keep these design patterns vendor neutral, not targeting specific industry types or PLC manufacturers Allows for the adaptation of our approach by all PLC developers Supporting Correct Software Development

The Design Pattern Engine uses information received from the Vulnerability Engine to determine the vulnerability assessed and assign the necessary design pattern to mitigate the vulnerability Supporting Correct Software Development

Supporting Correct Software Development: Race Condition Example ClassificationPlacement and Element Component Errors Sub-ClassificationBeginning of Rung Elements InstanceNormally Closed Contacts, Normally Open Contacts (Timer Done Bits) ProblemIncorrect placement of a timer done bit element can cause the process involving this element to go into a race condition SolutionAs a timer is encountered in a ladder logic rung, the timer done bit will be paired with that timer and a determination will be made as to the correctness of the current placement. This will be accomplished with the Design Pattern Engine of the Static Analysis Tool ApplicationThe Vulnerability Engine, upon determination of a race condition, will relay that information to the Static Analysis Tool. The Static Analysis Tool will use the Design Pattern Engine to suggest a correct design pattern to mitigate the race condition ImpactsThe impact of this solution is the removal of the vulnerabilities ranging from severity levels A – D.

Supporting Correct Software Development: Race Condition Example

Supporting Correct Software Development: Race Condition Example

Overview Static Analysis Tool Input Static Analysis Tool Output Implementation Example Static Analysis Tool

Purpose: Detects PLC Code Vulnerabilities Recommends Mitigation Strategies Detection Methodology: The Static Analysis Tool uses the Vulnerability Taxonomy and the State Transition Diagrams Mitigation Methodology: Each vulnerability is cross-referenced with a list of design patterns Static Analysis Tool: Overview

Input: Ladder logic from an existing PLC program The PLC Code Vulnerability Taxonomy State Transition Diagrams of the vulnerabilities A list of Design Patterns The Severity Chart Static Analysis Tool: Input

Output: List of vulnerabilities Severity rankings of the vulnerabilities Associated Design Patterns Suggested ladder logic solution The level of output provided, once presented to the user, should provide a basis to make a sound decision to substantiate, as well as mitigate, the security risk determined by the vulnerability engine Static Analysis Tool: Output

Proof of Concept Implementation: Running on Windows 7 Coded in C# Screen shots are provided Static Analysis Tool: Implementation Example

Overview of Research Area: Programmable Logic Controllers (PLC) are a relatively new area of SCADA security research SCADA Systems depend on the data and control supplied by the PLC Our research has allowed us to look at the SCADA system from: The gathering point of the data The device that controls the automation process in its entirety Conclusions and Future Research

Research Intent: Provide a mechanism which would allow for the protection of PLC ladder logic code Provide protection for the SCADA system in its entirety, through the protection of its control mechanism Conclusions and Future Research

Impact This work instantiates the need to secure not only the SCADA PC’s but also the PLC’s themselves The contributions of this research are: Classification of PLC software vulnerabilities A severity ranking system Mitigation strategies A Static Analysis Tool Conclusions and Future Research