This 2-part presentation, "Mission Critical Security in a Post-Stuxnet World," contains slides from the Hirschmann 2011 Mission Critical Network Design Seminar. It summarizes a lot of information about the Stuxnet malware and discusses what it means for the future of SCADA and ICS security. The presentation is ideal for anyone needing a crash course on Stuxnet, or as a tool for informing management about the implications of it.

1. Addressing the Son-of-
Son of
Stuxnet
Cyber Security Solutions for Mission Critical
Systems
Eric Byres, P.Eng.
CTO,
CTO Byres Security Inc
Inc.

2. The Stuxnet Worm
• July, 2010: Stuxnet worm was discovered attacking
Siemens PCS7 S7 PLC and WIN-CC systems
PCS7,
around the world
• Infected 100,000 computers
• Infected at least 22
manufacturing sites
• Appears t have i
A to h impactedt d
its possible target, Iran’s
nuclear enrichment
program

3. Stuxnet Had Many Paths to its Victim PLCs

4. The “Air Gap Is Dead
Air Gap”
• A modern ICS or SCADA system is highly complex
and interconnected
• Multiple potential pathways exist from the outside
world to the process controllers
• Assuming an air-gap between ICS and corporate
networks is unrealistic
• Focusing security efforts on a few obvious pathways
F i it ff t f b i th
(such as USB storage drives or the Enterprise/ICS
firewall) is a flawed defense

5. SCADA and ICS in the Bull s Eye
Bull’s
• ICS platforms are becoming an obvious target for
attacks
• “Security Researchers” focusing on SCADA/ICS
because it is easy money/fame (little malicious
intent)
• Actors with intent have access to the weapons:
• Download exploits for free (Italian list)
• Purchase tool kits (Gleg)
• Directed where to look for more vulnerabilities

6. Stuxnet s
Stuxnet’s Legacy
• Model for simple, destructive SCADA worms
• Exploits
E ploits inherent PLC design iss es
issues
• Applicable to almost all industrial controllers
• There are no possible “patches” to the PLC
patches

7. Protecting Against the “Son of Stuxnet”
Son-of-Stuxnet
• Understanding and Managing the Pathways
• Protecting the Critical Pieces First
• ISA-99 and IEC 62433 Security Standards
• Making Security Simple and Focused

8. Understanding the Pathways

9. Look At All Possible Pathways
• Don’t focus on a single pathway such as USB keys
• Consider all possible infection path a s
pathways:
• Removable Media (CDs, DVDs, USB Drives)
• File Transfer (Database, PDFs, PLC Project Files)
• Portable Equipment (Laptops, Storage Units, Config Tools)
• Internal Network Connections (Business, Lab, QA, Support)
• External Connections (Support Contractor Customer)
(Support, Contractor,
• Wireless (802.11, 802.15, Licensed-band, Cellular,
Wireless HART, ISA-100a, Bluetooth, USB tethering)
• Other Interfaces (Serial Data Highways)
(Serial,
• Have strategies for discovering/mitigating ALL
pathways

10. Protecting the Critical Pieces First
• The Attack/Consequence Funnel

11. Practical Solutions for ICS Professionals
• You are NOT going to be able to:
• Restructure your IT department’s focus and practices
department s
• Get suppliers to provide vulnerability-free products
• Patch every ICS system immediately
• Cut off all pathways in to and out of your ICS

12. Practical Solutions for ICS Professionals
• You should be able to:
• Restrict and manage the data flows into your systems
• Restrict and manage the data flows out of your systems
• Detect unusual behaviors in you systems
• Patch most ICS products within a patch management
strategy
• Progressively reduce the probably of attacker success the
deeper into the ICS/SCADA system they go

13. The Attack/ Consequence Funnel
External Corporate
Internal Enterprise Assets
Explo Opport
Avai
Att
Co
Process DMZ
oit
onsequen
ilablePath
tack Qua
HMI/Supervisory
Systems
antity
nces
hways
tunities
Primary Control
Systems
Safety
Systems
Process

14. Keeping All the Rubbish Out
External Corporate
Internal Enterprise Assets Process DMZ is a critical
Choke Point
Process DMZ
HMI/Supervisory Limited Pathways
Systems
Primary Control
Limited Protocols
Systems
Managed Egress
Safety
Systems
Disjoint Protocols
Process

15. Reducing the Vulnerable Systems in the
Middle
External Corporate
Internal Enterprise Assets  Windows-based
applications offer a major
Process DMZ attack opportunity
pp y
HMI/Supervisory Patch applications, not
Systems just the O/S
Primary Control
Systems A/V Deployment
Safety
Systems
White Listing ( )
g (?)
Process Separation of HMI & Control

16. Securing Last line of Defense Critical Systems
Last-line-of-Defense
External Corporate
Internal Enterprise Assets
Process DMZ High Consequence
HMI/Supervisory
Systems Focus on monitoring and
Primary Control securing SIS B
i Boundary
d
Systems
Limited Pathways
Safety
Systems
Anomaly Detection
Process

17. ISA 99
ISA-99 and IEC 62433
Security Standards
• Using Zones and Conduits to Focus your Efforts

18. ANSI/ISA-99:
ANSI/ISA 99: Dividing Up The Control System
• A core concept in the ANSI/ISA-99 (now IEC
62443.02.01)
62443 02 01) security standard is “Zones and
Zones
Conduits”
• Offers a level of segmentation and traffic control
inside the control system.
• Control networks divided into layers or zones based
on control function
function.
• Multiple separated zones manage that “defense in
depth” strategy

19. ANSI/ISA-99:
ANSI/ISA 99: Connecting the Zones
• Connections between the zones are called conduits,
and these must have security controls to:
• Control access to zones
• Resist Denial of Service (DoS) attacks or the transfer of
malware
l
• Shield other network systems
• Protect the integrity and confidentiality of network traffic
• It is important to understand and manage all your
conduits between zones, not just the obvious ones.

20. Security Zone Definition
• “Security zone: grouping of logical or physical assets
that share common security requirements .
requirements”
[ANSI/ISA-99.02.01–2007- 3.2.116]
• A zone has a clearly defined border (either logical or
physical), which i th b
h i l) hi h is the boundary b t
d between i l d d and
included d
excluded elements.
HMI Zone
PLC Zone

21. Conduits
• A conduit is a path for the flow of data between two
zones.
zones
• can provide the security functions that allow different zones
to communicate securely.
• Any
A communications b t
i ti between zone must h
t have a conduit.
d it
Conduit
HMI Zone
PLC Zone

22. Protecting the Network with Zones and
Conduits
• A firewall in each conduit will allow only the
MINIMUM network traffic necessary for correct plant
operation
Firewall
HMI Zone
PLC Zone

23. Using Zones: An Example Oil Refinery

24. Specifying the Zones

25. Defining the Conduits

26. Protecting the Conduits with Firewalls
Corporate Firewall
Hirschmann
Firewall

27. Making Security Simple

28. An Industrial Firewall Installation Gone Bad
Bad…
• An automotive company wanted layered protection
for key PLCs and robots
• Decided to install over 100 personal firewalls in front
of indentified critical devices
• All firewalls had to be removed within a few
months…
• Why?
Wh ?

29. BCIT SCADA Firewall Research Project
• In 2003 the research centre at the British Columbia
Institute of Technology (BCIT) was commissioned to
investigate issues and best practices in firewall
deployment in SCADA systems
• Results:
• “CPNI Good Practice Guide on SCADA Firewall
Deployment”
p y
• “The Special Needs of SCADA/PCN Firewalls:
Architectures and Test Results”
• Several restricted access documents
restricted-access documents…

30. What We Found
Found…
“While the results indicate that commercial
firewalls can b successfully used, th study
fi ll be f ll d the t d
also shows important differences between
the configuration of firewalls in industrial and
IT settings.”
The Special Needs of SCADA/PCN Firewalls:
Architectures and Test Results
Byres, Hoffman, et. al.
y , ,

31. Misapplication of IT Security Assumptions
• There are important differences between information
technology (IT) networks and industrial automation
and control systems (IACS) networks.
• Problems occur because assumptions that are valid
in the IT world may not be on the plant floor
• Some examples:
• Valid types of outbound traffic
• Importance of web “customers”
• Assumed protection from DoS attacks via routers
• “Critical” protocols
• Desired state on failure

32. An Example Assumption and Its Impact on a
Chemical Plant
• IT Assumption: Outbound traffic is safe, inbound
traffic is unsafe
• Result:
By default, all ports are blocked on the outside
y , p
interface, and all ports are open on the inside
interface of the security appliance.
Cisco ASA 5500 Adaptive Security Appliances
Document ID: 91970

33. An Example Assumption and Its Impact on a
Chemical Plant
• Plant Floor Reality: Cisco ASA firewall is installed
between DCS and PLCs with DCS as SCADA
master (thus inbound traffic to PLC must be allowed)
• Event: Firewall installed with default rule sets
• Impact: All traffic to PLCs is blocked, plant down for
three hours

34. Conclusion
• Security technology may be excellent, but the
default assumptions determine its usability in an
environment.

35. SCADA/ICS-Appropriate
SCADA/ICS Appropriate Technologies
• Select security solutions that are easy for engineers
and technicians to deploy
• Use ICS-appropriate detection technologies can
raise an alarm when equipment is compromised or
at risk of compromise
• Deploy ICS-appropriate security technologies
• Look beyond t diti
L kb d traditional network l
l t k layer fi
firewalls,
ll
towards firewalls that are capable of Deep Packet
Inspection of key SCADA and ICS protocols

36. Example: SCADA Focused Monitoring
SCADA-Focused
• Stuxnet had to connect to and reprogram the victim
PLCs to be successful
• Win-CC Servers likely the reprogramming point
• Q
Question: Should an HMI server be reprogramming
p g g
a PLC?
• Traffic analysis beyond the basic IP Address / TCP
port would d t t thi
t ld detect this…

37. Example: Fixed Configuration Safety Firewall
• Firewalls designed specifically for a single purpose
• Cannot be disabled or mis configured by staff
mis-configured
• Can be tuned for specific control systems
• Aware of SCADA protocols and capable of deep
packet inspection
• Sanity checking of protocols like Modbus
• Can provide fine grained controls of
allowed commands

38. Example: Deep Packet Inspection for OPC
• Stuxnet made extensive use of RPC protocol, which
is the basis of OPC
• IT firewalls can’t manage RPC or OPC traffic
• Firewall needs to be able to “understand” SCADA
protocols like OPC
• Requires “Deep Packet Inspection”
technology f automation systems
t h l for t ti t
• Example: Hirschmann OPC Enforcer
automatically inspects and manages
OPC traffic

39. Some Final Thoughts

40. Making Security Work in the SCADA World
• "Certainly controls engineers and operators need to
be security aware but they should not all need to be
aware,
security experts.“
• "We have to make this [security] something a plant
superintendent, engineer, or senior operator can do
in their spare time, or it will flop."
ISA-99 Discussion Forum

41. Some Final Thoughts
• IT and SCADA systems are different
• Translates to differing req irements for safe and
requirements
reliable deployments of security systems in SCADA
• We can’t stop all infections
p
• We can prevent attackers from reaching their goals
• Security AND safety can be significantly improved
with good policy and appropriate technology