Functions of SCADA

• A SCADA system performs four functions:

• 1. Data acquisition
2. Networked data communication
3. Data presentation
4. Control
• These functions are performed by four kinds
of SCADA components:
• 1. Sensors (either digital or analog) with control
relays that directly interface with the managed
system.
• 2. Remote telemetry units (RTUs). These are
small computerized units deployed in the field at
specific sites and locations. RTUs serve as local
collection points for gathering reports from
sensors and delivering commands to control
relays.
• 3. SCADA master units. These are larger
computer consoles that serve as the central
processor for the SCADA system. Master units
provide a human interface to the system and
automatically regulate the managed system in
response to sensor inputs.
• 4. Communications network that connects the
SCADA master unit to the RTUs in the field.
• Data Acquisition
• First, the systems you need to monitor are much
more complex than just one machine with one
output. So a real-life SCADA system needs to
monitor hundreds or thousands of sensors. Some
sensors measure inputs into the system (for
example, water flowing into a reservoir), and
some sensors measure outputs (like valve
pressure as water is released from the reservoir).
Some of those sensors measure simple events
that can be detected by a straightforward on/off
switch, called a discrete input (or digital input).
• For example, in our simple model of the widget
fabricator, the switch that turns on the light
would be a discrete input. In real life, discrete
inputs are used to measure simple states, like
whether equipment is on or off, or tripwire
alarms, like a power failure at a critical facility.
Some sensors measure more complex situations
where exact measurement is important.
• These are analog sensors, which can detect
continuous changes in a voltage or current input.
Analog sensors are used to track fluid levels in
tanks, voltage levels in batteries, temperature
and other factors that can be measured in a
continuous range of input. For most analog
Data Communication

• In our simple model of the widget fabricator, the

“network” is just the wire leading from the switch
to the panel light. In real life, you want to be able
to monitor multiple systems from a central
location, so you need a communications network
to transport all the data collected from your
sensors.
• Early SCADA networks communicated over radio,
modem or dedicated serial lines. Today the trend
is to put SCADA data on Ethernet and IP over
SONET. For security reasons, SCADA data should
be kept on closed LAN/WANs without exposing
sensitive data to the open Internet. Real SCADA
systems don’t communicate with just simple
Data Presentation

• The only display element in our model SCADA

system is the light that comes on when the
switch is activated. This obviously won’t do on a
large scale — you can’t track a lightboard of a
thousand separate lights, and you don’t want to
pay someone simply to watch a lightboard, either.
• A real SCADA system reports to human operators
over a specialized computer that is variously
called a master station, an HMI (Human-Machine
Interface) or an HCI (Human-Computer
Interface). The SCADA master station has several
different functions. The master continuously
monitors all sensors and alerts the operator when
there is an “alarm” — that is, when a control
• Control
• Unfortunately, our miniature SCADA system
monitoring the widget fabricator doesn’t include
any control elements. So let’s add one. Let’s say
the human operator also has a button on his
control panel. When he presses the button, it
activates a switch on the widget fabricator that
brings more widget parts into the fabricator
• Now let’s add the full computerized control of a
SCADA master unit that controls the entire
factory. You now have a control system that
responds to inputs elsewhere in the system. If
the machines that make widget parts break
down, you can slow down or stop the widget
Supervisory Control and
Data Acquisition
(SCADA) system
security
Reading

• Nicholson et al.’ 2012. SCADA security in the light of

Cyber-Warfare. 2012. Computers & Security,
Volume 31, Issue 4, June 2012.,
http://www.sciencedirect.com/science/article/pii/S016740481200042
•S. McLaughlin and P. McDaniel. 2012.
SABOT: specification-based payload generation for
programmable logic controllers.
In Proceedings of the 2012 ACM conference on
Computer and communications security (CCS '12).
ACM, New York, NY, USA, 439-449.
http://dl.acm.org/citation.cfm?id=2382244
Supervisory Control And
Data Acquisition (SCADA)
• Real time industrial process control
systems to monitor and control remote or
local industrial equipment
• Vital components of most nation’s critical
infrastructures
• Risk of deliberate attacks!
SCADA Systems
• 1990: mainframe computer supervision
• 1970: general purpose operating systems
• 1990: off the shelf computing
• Highly distributed with central control
• Field devices control local operations
SCADA Components
• Corporate network segment
• Typical IT network
• SCADA network segment
• Servers and workstations to interact with field devices
• Human-machine interfaces
• Operators
• Software validation
• Field devices segment
• Programmable Logic Controllers (PLC)
• Remote Terminal Units (RTU)
• Intelligent Electronic Devices (IED)
SCADA and PLC Overview
Process Control System (PCS) Safety System

Source: www.clcert.cl/seminario/
US-CERT_Chile_2007-FINALv2.ppt
SCADA and PLC Overview
• Ladder logic overview

• What is ladder logic?

• Why is it the programming language of choice
for automated control systems?
SCADA Incidents

• Flaws and mistakes

• 1986: Chernobyl Soviet Union
• 56 direct death, 4000 related cancer death
• 1999: Whatcom Creeks Washington US pipeline
rupture
• Spilling 237,000 gallons of gasoline that ignited, 3
human life and all aquatic life
• 2003: North East Blackout of US and Canada
• Affected 55 million people, 11 death
• 2011: Fukushima Daiichi nuclear disaster Japan
• Loss of human lives, cancer, psychological distress
Who would attack SCADA?
Attackers

• Script kiddies
• Hackers
• Organized crime
• Disgruntled insiders
• Competitors
• Terrorists
• Hactivists
• Eco-terrorists
• Nation states
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
Programmable Logic
Controllers
• Computer based solid state devices
• Control industrial equipment and processes
• Regulate process flow
• Automobile assembly line
• Have physical effect
Related Work

• Security working groups for the various

infrastructure sectors of water, electricity
and natural gas

• US Departments of Energy and Homeland

Security: investigation into the
problem domain of SCADA systems
Related Work
• Traditionally vendors focused on
functionality and used physical security
measures
• An attempt was made to try to “match”
physical security mechanisms online
• Vulnerabilities:
• Classification by affected technology
• Classification by error or mistakes
• Classification by enabled attack scenario
SCADA and PLC Security
• 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

SCADA and PLC Security
• Prior to the Stuxnet attack (2010): it was believed
any cyber attack (targeted or not) would be
detected by IT security technologies
• Need: 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)?
 Application of Touchpoints
External Review
3. Penetration
Testing
6. Security Requirements 1. Code Review
(Tools)
4. Risk-Based
2. Risk Analysis Security Tests 7. Security
5. Abuse cases 2. Risk Analysis Operations

Requirement and Architecture Tests and Feedback from

Test Plans Code
Use cases and Design Test Results the Field

28
PLC Security Framework (PLC-SF)

Static Analysis Tool: Compiler Workflow

PLC Security Framework (PLC-SF)
 PLC Security Framework (PLC-SF)

• Components:
• PLC Security
Vulnerability Taxonomy
• Design Patterns
• Severity Chart

• Engines:
• Taxonomy Engine
• Design Pattern Engine
• Severity Engine
Vulnerabilities Analysis
• Attack Severity Analysis

• Building the Vulnerability Taxonomy

• Potential Exploitation of Coding Errors

• Modeling PLC Vulnerabilities

Attack Severity Analysis – Severity Chart
• 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
Severity Effects in PLC Effects in SCADA
A PLC Code will not perform Will not allow for
the desired tasks remote operation
of the process
B Serious hindrance to the The process could
process experience
intermittent
process failure
C Adversely effects PLC code Data shown on the
performance. A minimal SCADA screen is
cost effect to the project, most likely false
but a “quick fix” is possible
D Effects the credibility of the Incorrect data
system, but the PLC code is could be randomly
operable reported, cause a
lack of confidence
in the system
Attack Severity Analysis – Severity Chart
• 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.
Building the Vulnerability Taxonomy
• 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
Building the Vulnerability Taxonomy

Vulnerability Taxonomy: Software Based (Virtual) Errors

 Potential Exploitation of Coding Errors
Error Type
Process Critical / Nuisance
Process Critical
Process Critical
Process Critical
Process Critical / Nuisance
Taxonomy Malicious User
Classification Opportunity
Duplicate Objects Installed Alterations of one or more of
the duplicate objects
Unused Objects Pre-loaded variables allow for
an immediate entry point into
the system
Scope and Linkage Errors Installation of jump to
subroutine command which
would alter the intended file
to file interaction
Logic Errors Immediate entry point to
logic level components such
as timers, counters, and
arithmetic operations
Hidden Jumpers Would allow for a placement
point for a system bypass
SABOT Impact on PLC
Attacks
• Software-based exploits of SCADA
• Understanding of industrial control systems
• Specification-based Attacks againts Boolean
Operations and Timers (SABOT)
SABOT Attack

• Encode understanding of the plant’s behavior into

a specification
• SABOT downloads existing control logic from the
victim
• SABOT finds mapping between the specific
devices and the variables within the control logic
• SABOT generates malicious PLC payload