Mission Critical Security in a Post-Stuxnet World Part 2


Published on

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.

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Mission Critical Security in a Post-Stuxnet World Part 2

  1. 1. Addressing the Son-of- Son ofStuxnetCyber Security Solutions for Mission CriticalSystemsEric Byres, P.Eng.CTO,CTO Byres Security Inc Inc.
  2. 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. 3. Stuxnet Had Many Paths to its Victim PLCs
  4. 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. 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. 6. Stuxnet sStuxnet’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. 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. 8. Understanding the Pathways
  9. 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. 10. Protecting the Critical Pieces First• The Attack/Consequence Funnel
  11. 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. 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. 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. 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. 15. Reducing the Vulnerable Systems in theMiddle 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. 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. 17. ISA 99ISA-99 and IEC 62433Security Standards• Using Zones and Conduits to Focus your Efforts
  18. 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. 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. 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. 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. 22. Protecting the Network with Zones andConduits• A firewall in each conduit will allow only the MINIMUM network traffic necessary for correct plant operation Firewall HMI Zone PLC Zone
  23. 23. Using Zones: An Example Oil Refinery
  24. 24. Specifying the Zones
  25. 25. Defining the Conduits
  26. 26. Protecting the Conduits with Firewalls Corporate Firewall Hirschmann Firewall
  27. 27. Making Security Simple
  28. 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. 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. 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. 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. 32. An Example Assumption and Its Impact on aChemical 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. 33. An Example Assumption and Its Impact on aChemical 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. 34. Conclusion• Security technology may be excellent, but the default assumptions determine its usability in an environment.
  35. 35. SCADA/ICS-AppropriateSCADA/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. 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. 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. 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. 39. Some Final Thoughts
  40. 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. 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