What is “SCADA”?
SCADA = “Supervisory Control And Data Acquisition”
Control and monitoring systems for industrial machines
Typically very robust: physical & electrical
Often very local: Factory floor
Sometimes widely distributed: Industry plant with several
kilometres length
Sometimes very remote: Management of remote substations Power grid, pipelines, water/gas/sewage distribution, …
SCADA was previously completely different and often “electric”, not
“electronic”, i.e. relays
Today all of them are computerized, but they are still often treated
as of old: Completely separate and as long as you don’t get
physical access, nothing can happen!
More general: “ICS” = Industrial Control System
2
SCADA system diagram
▪ RTU: Remote
Terminal Unit
▪ PLC: Programmable
Logic Controller
▪ Both are “local”
devices for remote
sites. Today typically
small computer
systems
Source: Gerhard Eschelbeck 3
SCADA human-machine-interface example
http://2.bp.blogspot.com/-WvErSWD4bEI/Ti3gy3FFerI/AAAAAAAAAYU/lLk4SO0bjG4/s1600/DCS_PLC_Scada_Systems.jpg
4
SCADA installation example
http://www.miramarautomation.com/controlsystemsusa/PICTURES/RTU-CTRL_ST1.jpg
5
Large control/monitoring panel
http://electrical-engineering-portal.com/wp-content/uploads/scada-dms.jpg
6
Where is SCADA used?
Manufacturing: Controlling production lines
Individual machines, robots, transport devices; quality control
Essential services & commodities: Electricity, gas, water, oil, waste
treatment
Both for production and transmission/distribution
Critical infrastructure!
Large buildings/facilities and environmental control
Heating/ventilation/air conditioning systems (HVAC), lighting, entry
control, energy consumption …
Not typical SCADA, but home automation is quite similar!
Transportation and mass transit
Traffic signals, security checks (signals working, presence
detection etc.), tracking of “cars”, timetable information
9
SCADA operation
Typically programmed once, with “simple” software
Updates are very rare
They continuously send reports on some measured data
Mostly they autonomously control the local system, but “big”
parameter changes come from remote central control stations and
are received “rarely”
Communication bandwidth is low
Focus on: Performance, reliability, flexibility safety
Security is often non-existent
Low computing resources & bandwidth
No priority: Local communication only/own radio frequency,
physically secure, works without, proprietary protocol… Many assumptions are today/in general NOT valid any more!
10
Threats
Deliberate attacks
Insider (disgruntled employees)
Industrial espionage
Organized crime: Extortion
Unfriendly states: Electronic warfare (or harassing)
Accidental threats
Equipment failure
User error
Misdirected attacks/collateral damage
Natural phenomena
Weather, earthquakes, floods, solar activity: Communication
disruption, device damage
11
Potential security problems
Disruption of service
Locally: Just “disturb” (DoS, erroneous commands, …) it
Globally: Use a local system to bring down the network All are interconnected; issuing commands to other local systems might
not be designed, but still possible!
Process redirection: Receiving more/free resources
Process manipulation: Redirect sewage flow into freshwater pipes,
overload electricity transformers/power lines, turn off traffic control
complete collapse etc.
Manipulation of sensor data: “Save” costs, wear out systems, hide
beginning malfunctions, …
Overloading: Little reserves (CPU, memory, …) available
12
Why is security becoming a problem?
Increased interconnection: More remote sites without personnel, but
with data communication
Also increased number of entry points and paths Supervisory authorities, billing, subcontractors etc.
Connected to more systems (e.g. statistics, invoicing, …)
Off-the-shelf hardware and software instead of everything proprietary
(ICT moved into SCADA)
Own custom DB MS SQL Server
Assembler-coded system Linux base + scripts
Proprietory protocol + bus system IP + Ethernet
Compatibility: Old protocols were conceived as serial protocols
without authentication, encryption, or integrity mechanisms but are
still used/supported today
13
Why is security becoming a problem?
“Security is a cost, not an investment”
Devices cost more, additional devices, more complexity, …
Different security models (=primary goals):
ICT: CIA (Confidentiality, Integrity, Availability)
SCADA: SRA (Safety, Reliability, Availability)
Legal problems:
License and support contracts may forbid adding any code or
additional components Adding security is impossible
NDAs may prevent enforcing producers to close vulnerabilities
ICT security SW/devices are ill suited for SCADA
Different content protocols and communication mechanisms
Real time requirements of SCADA: Delay/jitter unacceptable
14
Why is security becoming a problem?
Patching is very rare/potentially complex: See later!
Wider use and in more important systems
Similar to Linux: Few end-users Few attacks
Increased capabilities of field equipment
You can reuse it for other things, reprogramming is actually
possible (no more EPROMs!), sending data is SW (=changeable,
e.g. to DoS) instead of HW
▪ Public (=shared) networks used for data transfer
▪ Standard systems can be used for contacting
▪ Attacking the system (flooding) may influence the SCADA
15
Potential security issues
Classification of problems (Target: SCADA):
Modify/disrupt sensor data flow (=outgoing) Show false values, cut off central control system
Modify/disrupt command flow (=incoming) Issue commands or prevent changes to configuration
Modify/disrupt system (=other program/“switch off”)
Snooping: Unauthorized gathering of sensor data
Delays: Communication is delayed (in-/outgoing) Itself dangerous, or to hide attacks for some time
Similar/classical problems exist regarding the central control station,
which is typically a “normal” computer system (but additional
communication channel)
16
Examples of (lacking) SCADA security
Default vendor password
For maintenance and testing
Typically identical in (at least) each device of a product line
Sometimes impossible to disable
May even allow remote connection
Additional functionality
Daemons not turned off (remains of default configuration)
Keys for signing updates are included in the update
Extract key from device/update Create your own update!
Proprietary protocol
Often same/similar as very old ones Many people now know it,
reverse engineering simple (buy two devices!)
Security disabled by default to ease installation
17
Examples of (lacking) SCADA security
Old devices: Replacing everything is expensive
Devices may be very old (but see also: Windows XP!)
Amortization over 15-20 years or longer
Other systems in the SCADA network
Example: Safety systems on SCADA network and the safety
engineers programmed the safety system from their normal
desktop computer: Get into LAN (get in safety desktop ) get
in safety system access to SCADA network!
18
Security “advantages” of SCADA systems
Often rather obscure programming language
Similarly often uncommon assembler code ( processors)
Knowledge on multiple systems required
Get into UI system (Windows), reach control server (Linux), attack
SCADA stations (Proprietary)
Network separation: While it IS possible, it might not be easy to
reach the control system
Obscurity: Few data about SCADA systems is public
Handbooks/brochures reserved for paying customers only
Specialized hardware needed for physical interfaces
Each installation is comparatively unique
If it crashes, it will reboot automatically (“watchdog timers”)
Physical security / tamper proof
19
“But the network is completely separate!”
Even if it is: Can someone add own devices into it?
Attaching cables to a bus system?
Plugging in at spare ports?
GSM: Calling the correct number + password?
Wireless communication/network?
Is it really separate?
Management and maintenance? Updates? Development?
Note: “Separate” means also: No data medium may cross the border,
i.e. installing patches through SD-Cards not separate any more,
as a virus could spread through this!
Result: No SCADA network is ever completely separate!
Minimization is still very useful and necessary!
20
Separating networks
Never allow direct connection to public networks/Internet
Introduce strong protection devices between networks
Ideally (very complex and expensive!): “Public” network, e.g. company LAN
Firewall
Intermediate system for data exchange (DMZ, data warehouse)
Firewall
Control system and local SCADA network
Firewall
Remote SCADA network:
Firewall
SCADA device(s)
Plus IDS at several locations
At each remote location
21
Patching SCADA systems
Risk of vulnerability to be patched vs risk of patch disturbing the
production?
Higher priority for perimeter defences (firewalls etc.), as these are
cheaper and less riskier to implement/update?
Does the vendor still exist/support the system?
Can the system run the patched system at all?
How to (reliably!) update 1000 remote systems while they are
actively in use to control a process?
How to test patches?
A complete duplicate system or a model of it ( communication
link simulation!) might not be available
Who may authorize/perform installation of patches?
Operator of the system, maintenance contractor, vendor?
22
Patching SCADA systems
Can the patch be installed during normal operation?
Sufficient memory, CPU, bandwidth, … for this?
How long will the “reboot” take?
Critical systems are redundant – during patching they are not First patch redundant system, then test & switch over, then install on
“main” system and go back to fully redundant
Patch management:
Which system is at which patch level?
Which patches have been tested?
Compatibility: Configuration, resources, …
De-installation of patches in case of problems
Do we have backups?
Will the system still run or is physical intervention necessary?
23
Malware example: Stuxnet
Stuxnet is one of the extremely rare malware examples for SCADA
systems
Attacks are more common, but these occur “manually”
Stuxnet is a platform-independent worm containing multiple rootkits
Original target system: Windows (hidden by rootkit)
Infects SCADA control software on them (if present)
From there moves to SCADA systems itself (rootkit) if they match
certain properties, where it activates its payload
Timeline: 6/09 (First infection), &/10 (First malware report)
Very precisely targeted at specific systems
Large Windows infection rate (6 millions? China, 30.000 Iran)
Siemens: Only 24 SCADA systems were infected
24
Stuxnet properties
Extremely complex software requiring detailed knowledge on
Windows + Siemens SCADA systems
Contained 4 zero-day exploits for Windows
Rootkit for SCADA system
Two valid certificates for driver signing (Realtek, JMicron)
Probably physically stolen; both are in one industrial complex
Specific knowledge on SCADA system at target facility needed: What
system, which configuration, program code
Including the devices controlled by it
For testing a similarly equipped facility would be needed
Estimated effort:
6 month of 5-10 core developers + management, quality control,
reconnaissance, procurement…
25
Stuxnet properties
Unusually large: Approx. 500 kB in size
Written in several programming languages: C, C++, Step7 (several
possibilities)
Works without any Internet connection: Infection, spreading and
“jump to Step7”
Last one is via a special data cable: Communication library (DLL)
is modified to enable this
Several variants (at least 3) exist, which add/remove/change some
functionality
26
Stuxnet spreading
Initial infection takes place via a USB device (memory stick, external
harddisk, …)
Opening the directory in icon view is sufficient, no further
interaction is necessary Vulnerability in processing .LNK files (Win XP – Win 7)
Previous version used a different method (Autorun.inf vuln.)
Two hidden files are copied to the system and one is installed as
driver-filter for the file system
Ensures survivability of reboots and acts as rootkit So these files will not be visible on disk/USB devices
These files are digitally signed, or this would not work
If no admin rights are present, it uses exploits to elevate itself to
admin before continuing
Also stops, if later than 24.6.2012 Self-termination!
27
Stuxnet spreading
Installs itself in running processes (no reboot needed)
Which one it is depends on running the antivirus program It might install even in the AV process itself!
If some AV programs are present and later than a specific date,
infection is stopped (to risky/detectable)
It uses special techniques when loading itself as a DLL to
circumvent behavioural blocking
Contacts all other Windows servers in the LAN to infect them (if they
not already are) via RPC/Print spooler
Also used to update existing infections to latest version
Infects all removable drives to spread out further
Propagates through network shares as well
Uses the current user and WMI to copy & execute itself
28
Stuxnet spreading
If a server with the WinCC (Siemens development environment for
Step7 system) database is found, the default hardcoded vendor
password is used to inject itself into the remote database
When WinCC is run, the database is cleaned and the payload
written to a DLL (via in intermediate CAB file)
The DLL is converted into a stored procedure and run whenever
the DB is started Infection of local system
29
Stuxnet reporting back
After it has installed itself, it will check whether internet access is
possible, by trying Windows Update or MSN
If not Continue with other tasks
Contacts Command&Control servers
www.mypremierfutbol.com, www.todaysfutbol.com
It uploads configuration information and checks for updates
Encryption: XOR with a static 31 byte long key
Whatever code is sent, is injected into a process and run Backdoor or update functionality!
30
Stuxnet infecting
It infects all (with restrictions) Step7 projects
To ensure the DLL is loaded whenever the project is loaded in the
development/management environment
DLL is used for communication between WinCC and SCADA system
Allows injecting code into the SCADA system and hiding it when
retrieving/inspecting code there
Delegates to the original DLL after inspection/modification
Three different infection sequences exist, two very similar, the
third seems to be incomplete and for a different CPU
Infection takes place only if it is a specific model with a specific CPU
and certain static parameters (configuration of connected devices)
31
Stuxnet on SCADA
Also it must contain the subroutine “FC1869” (communication with
Profibus devices) and contains at least one communication module
CP-342-5
Then copies code to SCADA system and ensures it is run
A CP-342-5 device is used to create variable frequencies for
controlling the rotation speed of electric motors
Malware activity only, if the drives are from two specific vendors!
The frequency must be between 807 and 1210 Hz Which is VERY high for such devices (capable of >600 Hz USA
export regulated as usable for Uranium enrichment!)
No hiding on the device itself – connection through uninfected
management system will show it (cryptically!)
32
Stuxnet: System configuration required
http://www.symantec.com/connect/blogs/stuxnet-breakthrough
Must be from
Vacon or Fararo
Paya
33
Stuxnet payload
With random delays (13 days to 3 month) it begins activity
It modifies the actual frequency for short intervals
(1410 2 Hz 1064 Hz 1410), but reports correct frequency Each step works only briefly: 15/50 minutes
This is done with 27 days between the individual steps
(Probable) aim: Destroying centrifuges for uranium enrichment
Fragile: 10% loss/year during normal operation seems common
1064 Hz = Nominal speed ( 334 m/sec wall speed of centrifuge)
Through directly sending control commands to the interface
Stuxnet sends/listens on global comm. bus First SCADA device to
elapse long wait time activates all simultaneously
34
Summary
SCADA systems are not a primary attack target today:
Too few systems
Each of them is different
Making money from them is complex and dangerous
But:
Terrorism (from state to disgruntled ex-employees)
Targeted attacks for information stealing
Getting in through SCADA as “backdoor” into normal LAN Connect at some remote station, get through the command center,
reach the internal network, and install malware there
SCADA security will become more important
Especially during development: From no/little security to full
security similar to “normal” computers today
35
Potential future research directions
IDS/IPS might be useful: SCADA systems possess very regular
communication patterns – everything out of the ordinary is alarming
anyway
So anomaly detection might finally work!
Patching and update management
Both in designing systems as well as tools E.g. Dual-core CPUs might help in testing/deployment; can be
switched off to conserver energy; useful for “peak” needs too
Separating networks (“data diodes”)
Enabling forensics: Ensuring data is available to trace problems back
to the source (attack and/or faults/bugs/…)
36
JOHANNES KEPLER
UNIVERSITÄT LINZ
Altenberger Straße 69
4040 Linz, Österreich
www.jku.at
Michael Sonntag
+43 (732) 2468 - 4137
S3 235 (Science park 3, 2nd floor)
https://www.ins.jku.atTHANK YOU FOR
YOUR ATTENTION!