Security Testing
in Critical Systems
Peter Wood
Chief Executive Officer
First•Base Technologies
Who is Peter Wood?
Worked in computers & electronics since 1969
Founded First•Base in 1989 (one of the first ethical hacking firms)
CEO, First Base Technologies LLP Social engineer & penetration tester
Conference speaker and security ‘expert’
Vice Chair of BCS Information Risk Management and Audit Group Member of ISACA Security Advisory Group
UK Programme Chair, Corporate Executive Programme
FBCS, CITP, CISSP, MIEEE, M.Inst.ISP Registered BCS Security Consultant Member of ACM, ISACA, ISSA, Mensa
Agenda
•
Scope of this Presentation
•
Vulnerabilities and concerns
•
Security testing
Scope of Presentation
• Supervisory Control And Data Acquisition (SCADA) - computer systems that monitor and control industrial,
infrastructure, or facility-based processes
• Programmable Logic Controller (PLC)
- a computer used for automation of electromechanical processes, such as control of machinery
• Programmable Automation Controller (PAC)
- a compact controller that combines the features and capabilities of a PC-based control system with that of a typical PLC
• Remote Terminal Unit (RTU) or Intelligent Electronic Device (IED)
Network Architecture
• RTUs and IEDs are proprietary devices running embedded operating systems
• These originally used serial communications with field bus protocols such as Modbus, BITBUS, PROFIBUS etc.
• Field bus protocols are now frequently encapsulated in TCP/IP
• SCADA controllers manage communications, analyse data and display the alerts and events
• Industrial systems now use UNIX or Windows in controllers and embedded in some field devices
• This has exposed industrial systems to the same IT security challenges as commercial systems
Agenda
• Overview of critical systems
•
Vulnerabilities and concerns
• Security testing
Authentication Problems
• Default (manufacturer) passwords
• Very poor quality passwords
• Passwords never changed
• Passwords common across many devices
• Shared credentials
• No passwords / anonymous logins
• Remote access via modem
• Systems replaced less often than commercial systems: no cleanup, more opportunity for information leakage
Systems not Patched or Hardened
• Many systems running on legacy (unsupported) operating systems
• Patching can break applications
• Patching can violate some vendors’ service contracts
• Systems never taken off-line, as downtime can cause massive problems
• Systems are rarely hardened as it is believed this may impact the application
• SCADA applications themselves often contain vulnerabilities
Insecure Protocols
• Field bus protocols were not designed to be secure
• Most field devices use proprietary IP stacks that are prone to DoS attacks and buffer overflows
• Field bus protocols designed for serial comms, so no built in authentication – all legitimate packets will be processed
• Most communication is in plain text
Lack of Segmentation
• Firewalls usually only between the corporate network and the industrial network (if at all)
• Firewalls may be badly configured, industrial protocols difficult to control
- All field bus traffic may be on one port
- Cannot risk blocking critical messages
• Wireless can bypass firewalls
• Traditionally SCADA systems were isolated … not any more
• Systems therefore vulnerable to malware, especially worms
Stuxnet: “classic” exploit
• Self-replicated through removable drives (auto-execution vulnerability) • Spread in a LAN through a Windows Print Spooler vulnerability
• Spread through SMB (Microsoft Windows Server Service RPC Handling Remote Code Execution Vulnerability)
• Copied and executed itself through network shares
• Copied and executed itself on computers running a WinCC database server • Automatically executed when the Step 7 project is loaded
• Updated itself through a peer-to-peer mechanism within a LAN
• Exploited a total of four unpatched Microsoft vulnerabilities
• Command and control to download and execute code, including updates
• Contained a Windows rootkit that hid its binaries
• Attempted to bypass security products
• Fingerprinted and targeted Siemens PLCs to sabotage the system
• Hid modified code on PLCs, essentially a rootkit for PLCs
Agenda
• Overview of critical systems
• Vulnerabilities and concerns
•
Security testing
Problems with Testing - 1
While a ping sweep was being performed on an active SCADA network that controlled 9-foot robotic arms, it was noticed that one arm became active and swung around 180 degrees.
The controller for the arm was in standby mode before the ping sweep was initiated.
NIST Special Publication 800-82 Guide to Supervisory Control and Data Acquisition (SCADA) and Industrial Control Systems Security
Problems with Testing - 2
A ping sweep was being performed on an ICS network to identify all hosts that were attached to the network, for inventory purposes.
It caused a system controlling the creation of integrated circuits in the fabrication plant to hang.
This test resulted in the destruction of $50,000 worth of wafers.
NIST Special Publication 800-82 Guide to Supervisory Control and Data Acquisition (SCADA) and Industrial Control Systems Security
Problems with Testing - 3
A gas utility hired an IT security consulting organization to conduct penetration testing on its corporate IT network. The consulting organization carelessly ventured into a part of the network that was directly connected to the SCADA system.
The penetration test locked up the SCADA system and the utility was not able to send gas through its pipelines for four hours.
The outcome was the loss of service to its customer base for those four hours.
NIST Special Publication 800-82 Guide to Supervisory Control and Data Acquisition (SCADA) and Industrial Control Systems Security
Areas for Review
•
Perimeter
•
Network infrastructure
•
Active Directory etc.
•
Host operating systems
•
Applications
Perimeter
•
Identify all external connections
•
Review firewall rules
•
Review remote access methods
•
Check for wireless networks
•
Check physical access
Network Infrastructure
•
Review router configs
•
Review switch tables
•
Conduct physical cable checks
•
Conduct packet sniffing and analysis
Active Directory
•
Manual inspection
•
Interviews
Host Operating Systems
•
Review hardening
•
Review patch levels
•
Review password quality
•
Review share and directory permissions
•
Review remote access
Applications
•
Review ports and services
•
Review OS credentials
•
Review password quality
•
Review remote access
•
Consider code review
PLCs, RTUs, IEDs, etc.
•
Review hardening
•
Review patch levels
•
Review password quality (if any)
•
Conduct packet sniffing
Agenda
• Overview of critical systems
• Vulnerabilities and concerns
• Security testing
Summary and Conclusions
• Industrial systems now use UNIX or Windows exposing them to the same IT security challenges as commercial systems
• Systems still considered to be isolated, but they are not
• Systems not patched or hardened
• All devices will have authentication problems
• Systems replaced less often than commercial systems: no cleanup, more opportunity for information leakage
• Field bus protocols were not designed to be secure
• Poor segmentation and firewalling
• Conventional scanning and testing can cause serious problems
Designing Security In
• Learn from the IT security challenges in commercial systems using UNIX or Windows
• Build firewalls with the understanding that industrial systems may not be isolated
• Work towards hardening and patching systems (thorough application testing required!)
• Segment systems that have authentication problems
• Perform regular cleanup of systems to minimise redundant accounts
• Replace field bus protocols wherever possible, otherwise segment them
Peter Wood
Chief Executive Officer
First Base Technologies LLP [email protected]
http://firstbase.co.uk http://white-hats.co.uk
http://peterwood.com Twitter: peterwoodx
