CONTROL SYSTEM ATTACK EXAMPLES
Incidents the US ICS-CERT responded to Oct 2012-May 2013
ICS THREAT VECTORS
2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015
Professional Attackers
• Preparatory work from Nation State Actors
• Mostly silent attacks so far
Insider Jobs (e.g., Smart Metering Fraud)
• Clear Business Model
• Substantial Damage
Accidential Attacks
• Poor Robustness
• Collateral Damage
ICS VULNERABILITIES: ROOT
CAUSES
•
Low maturity
•
Insider Threats/Supply Chain protection
– Do you know who you depend on ?
– GPS, Weather forcast, Robin Seggelmann, ... ?
•
Poor Procurement
•
Cost Savings at the wrong place
•
Vendor/Buyer conflicts
•
IT Solutions in OT Environments
•
Difficult to make a good risk assesment
•
And... Securing a Process Control System is HARD!
SECURITY AND PRIVACY NO LONGER
OPTIONAL
NIS Directive
• Explicity includes energy sector
• Support and obligation:
• Duty to take “appropriate technical and
organisational measures”
• Duty to inform authorities of any significant
incident
• “Sanctions provided must be effective,
proportionate, and dissuasive”
General Data Protection Regulation: up to 2% of
worldwide revenue fine for data protection violations
(might increase to 5% or 100 million)
Sources:
European Commission, General Data Protection Regulation, COM(2012) 11 final (2013/0027 (COD) European Commission, NIS Directive, COM (2013) 48 final 2012/0011 (COD)
SPECIAL CHALLENGES IN
CRITICAL
ROBUSTNESS CHALLENGES
It is hard to build a robust system as it is. The systems we are building now are
• far more complex
WHY AUTOMATION
(EXAMPLE SMART GRID))
• Integrate Renewables
– Supply is getting less predictable, so control
demand instead (e.g., dynamic pricing)
– Lower energy quality
• Local generation
– “Imagine water flows upstream”
– E.g., how do we turn of power for maintenance ?
• Ageing Workforce
– Need to react to events remotely rather than
sending “Guys with keys”
• Manage Electronic Vehicles
– One Tesla = 60 households
– Multi stakeholders, little regulation
• Better failure handling, less copper
INFORMATION VS PROCESS
SECURITY
INFORMATION VS PROCESS
SECURITY
• Control
• Being able to send control
commands to the process
• Observability
• Knowing the state of the process
and its components
• Operations
• The process should always
operate within its safety
boundaries, even without human
interaction
NEW RELEVANT FACTORS
• System design
– Geographical spread, device lifetime, real time, fragile devices,
unexperienced vendors
– Safety design
• People
– IT vs. OT Conflict
• Consequences
– Many processes require a higher uptime than google
– The kind of attacks we see in the PC world are intolerable
– Physical Damage/Death/National collapse
– More fuzzy input (weather, ...)
• Attacker Factors
– No clear businessmodel
FAILURE OF IT BEST PRACTICES
send command
authentication required.
passcode is ‘Xfr56y3’
Xfr56y3
passcode accepted.
awaiting command.
HOW TO (NOT) MEASURE
TEMPERATURE
• SOAP/JAVA
• MySQL Database
• Apache Webserver
• Linux Server
Good interoperability.
Persistent Storage.
Reliable communication.
HOW TO (NOT) MEASURE
TEMPERATURE
• SOAP/JAVA
• MySQL Database
[1,211,154
Lines of Code]
• Apache Webserver
[2,277,189
Lines of Code]
• Linux Server
[15,803,499 Lines of code]
“One of the design goals for
SOAP was that it should
easily pass through firewalls.”
“Barclays: 97% Data breaches
still due to SQL Insertion”
See OWASP top 10 for ways
to misconfigure your web
server
“Industry average: 1 security
relevany bug for 1000 lines of
REALITY CHECK
• The Security Maturity level in control systems is insufficient
• Culture shock for both security- and power communities
• Money is there (somewhere)
• Safety culture can be morphed into security culture
• Not all functionality will be activated at once
• Most attackers don’t know what they’re doing, either (yet)
Strategy: Buy time and design for upgradability along a mid-term
security roadmap to achieve a reasonable level of security by the
time critical components go online.
PRAGMATIC SECURITY
• Low Hanging Fruits
– The NSA can bring you down anyhow
• But: NSA style attacks are tickling down
• USB-Firmware attacks on ICS has been demonstrated
– The 12-year old might find it cool
• Default passwords (if at all), Webattacks,…
• Keep is simple
– Complexity leads to error
– Feature creep kills
• Say no to SOAP, JAVA, Flash, …
• Your PLC does not need Apache
• Define what you want and what you don’t
– Clear requirements make clear code
– A lot of systems put IT in “because we can”
– E.g., … why do I need a Smart Meter anyhow ? Andy why by 2020 ?
• Compromise
CASE STUDY: STUXNET
• Four novel attack technologies
• Double-digit millions in attackercost
• Two nation state actors
• Likely use of field agents
• Multi-year attack preparation
• Likely rebuild of entire facility
• Attack on at least 2 software vendors
CASE STUDY: MAROOCHY
WASTEWATER TREATMENT
• Feb 9 till April 23, 2000, a
disgrunteled ex-employe of
the wastewater management
system reversed pumps,
leading to massive damage
and inconvenience
Training: Engineers saw what was happening, but did not suspect a
security issue for several weeks
Policy: Ex-employee had access to radio equipment
IDEAL WORLD SECURE DESIGN PROCESS
Source: NISTIR 7628 Cyber Security Strategy
External dependency analysis 4c. Vendor Require mets 5b. Penetration test
PROCUREMENT AND REQUIREMENTS
•
Pen-tests are overkill at the current
maturity level
– Replay, OWASP top 10, cleartext/no
passwords, homemade ciphers, basic
SQL insertion, no memory for upgrades,
20 million devices with one key,
undocumented telnet ports, …
•
If you don’t ask for security, you don’t get
it.
– Vendors only deliver what they have to
– Many vendors do not have the maturity
themselves to develop secure solutions
•
Danger of security by compliance and
exercises in avoidance
– NERC CIP, Common Criteria for Smart
Meters
EXAMPLE REQUIREMENTS
Requirement
Recommendation
Recommended Assurance
Activity
The gateway SHALL have sufficient memory (ROM and RAM) and computation power reserves to allow updates of security functionality.
The updateability MUST be ensured throughout the product life-cycle.
1. The vendor SHOULD provide design evidence that
sufficient reserves are available to update security functionality.
2. This includes in particular cryptographic algorithms and communication protocols. For examples of security
functionality see SPR.01. 3. The gateway SHOULD have
storage reserved solely for updating security
functionality.
1. Analysis of the design
documentation provided by the vendor.
Requirement
Recommendation
Recommended Assurance
Activity
The meter SHALL verify the validity of all data packets and data format received on the following
interfaces:
• Multi-utility interface between electricity meter and other utility meters,
• maintenance interface,
• LAN between electricity meter and Central System,
• WAN between electricity meter and Central System.
1. Both device design and implementation SHOULD ensure that the device is not negatively affected by corrupt or deliberately malformed packets are received.
2. The requirement is valid for all layers in the OSI model.
1. It is recommended to carry out fuzzing tests on the described interfaces.
2. The vendor should provide a detailed documentation of all security tests.
Future Proof
Data Integrity
Requirement
Recommendation
Recommended Assurance
Activity
The meter SHALL verify the
integrity of firmware images before they are applied.
• The vendor SHALL digitally sign the firmware update.
• Firmware updates without valid digital signature MUST be rejected. • The firmware update MUST be rejected if its version number is lower than the version number of the installed firmware.
• The meter SHALL support the downgrade to an older firmware version. Any such downgrade SHALL be imported under a new version number.
• Data on the meter (e.g., stored meter data or log entries) SHALL NOT be altered or deleted by a firmware update.
1. The vendor SHOULD digitally sign the firmware update using the ECDSA algorithm with an allowed key strength as defined in the Chapter
Strong Cryptographic Primitives.
2. The public key for the validation of the signature SHOULD be installed during the manufacturing process. 3. Digitally signed firmware
updates can be sent out as broadcast/multicast. 4. Adequate release
management of a firmware build SHOULD ensure the
1. The functional requirement should be verified by testing the implemented firmware-update functions.
2. Performing an audit or
establishing a certification scheme (such as ISO27001), i.e., reviewing the implemented processes and procedures for firmware updates. 3. Carrying out a fuzzing test to verify that the firmware update functions are adequately implemented.
