AN AUTOMATED TESTING PROCEDURE TO EVALUATE INDUSTRIAL DEVICES

AN AUTOMATED TESTING PROCEDURE TO EVALUATE INDUSTRIAL DEVICES COMMUNICATION ROBUSTNESS Author: Filippo Tilaro Supervised by: Brice Copy

Overview Ø Ø Ø Scope & Objectives IT & Industrial Security Model Security Metrics & Testing Requirements o o Ø ISA-99 ISCI CRT Test-bench implementation o o Testing Techniques Device Monitoring Vulnerability Reporting System Reproducibility

Background Ø Technological Evolution: o Growing interconnectivity between the fabric and the management level o IT functionalities with inherent vulnerabilities into control devices o Lack of security standards and guidelines o Growing number of discovered PCS vulnerabilities - 2010: Vx. Works and STUXNET - 2011: Sunway Force. Control and p. Net. Power, Beckhoff Twin. CAT 'TCATSys. Srv. exe' Network Do. S, Rockwell RSLogix Overflow, Measuresoft Scada. Pro, Cogent Data. Hub, Azeo. Tech DAQFactory Stack Overflow, Progea Movicon, Scada. TEC Modbus. Tag. Server and Scada. Phone Remote Buffer Overflow, Scadatec Procyon 'Coreservice. exe' Stack Buffer Overflow, Siemens Win. CC Flexible Runtime Heap Overflow, Active. X in Advantech Broadwin Web. Access, Sunway Force. Control SCADA SHE, Control Microsystems (Schneider Electric) Clear. SCADA Remote Authentication Bypass, Inductive Automation Ignition Disclosure, Siemens SIMATIC S 7 -300 Hardcoded Credentials, Password Protection Vulnerability in Siemens SIMATIC Controllers (S 7 -200, 300, 400, 1200), Siemens SIMATIC S 7 -1200 PLC, Honeywell Scan. Server Active. X Control Ø Result: recovery from attacks is expensive in terms of: o time, cost, effort

IT vs Industrial Security Model Ø Different requirements: o Performances – o Availability – o best-effort vs real-time reboot strategy vs no downtimes admitted Network architecture – generic services (DNS, Domain Controller, …) vs industrial services Ø Updating and patching Ø Communication protocols o Ø Public vs proprietary Software and component lifetime

Approach Ø Objectives: o Ø To improve the Process Control System (PCS) security level Strategy: o Investigate cyber security standards (ISA-99, NERC-CIP, IEC 62351) o ISA-99 as reference model -> ISCI Communication Robustness Test (CRT) o Determine key cyber security aspects relevant to CERN o Design and implement a test bench: o - Assess the PCSs devices network robustness - Discover and Classify vulnerabilities of control system devices - Integrating more and more specific attacks Defining metrics for security evaluation

ISCI CRT Testing Phases Ø Ø 5 security testing phases: o Discover Protocol Functionalities and Attack Surface o Storms and Maximum Load Tests o Single Field Injection o Combinatorial Fields Injection o Cross State Fuzzing (for Stateful Protocols) Fulfilling the ISCI CRT requirements: o Integration of the CRT tests into the TRo. IE test-bench developed at CERN

Test-bench diagram Target System Testing Extended Peach Fuzzing Panel Attacker System Monitoring Partner Reporting System Vulnerabilities DB Configurator Traffic Analyzer Signals Monint. Web front-end

Protocol Robustness Testing Ø Ø IEEE defines robustness “in the degree to which a system or component can function correctly in the presence of invalid inputs or stressful environmental conditions. “ What is a robustness failure? o Failure to return the expected packet o Inability to progress to next protocol state o Dropped connections o Lost or modified data o MORE IMPORTANT: Any unexpected effect in the process control!

Testing Techniques Ø Ø Brute Force Testing: o Simple but inefficient o Not all the combinations are interesting Fuzzing & Grammar Testing: o Not random: essential for debugging! o Not exhaustive but we can cover specific sequences o Grammar driven o Integration of the security specialists’ knowledge

Fuzzing Testing Requirements Ø A Common Framework: o Ø Scalability o Ø Ø No standalone scripts Handle and organize the growing amount of tests (almost infinite combinations) Tests Customization o Protocol header format o Protocol field values o Protocol state machine Reproducibility o Essential for any debugging activity

I/O Monitoring Ø Objective: o Ø Detect any delay or anomaly in the device’s process control I/O during the phase of testing Precedent solution : with the use of another PLC The analysis was affected by synchronization issues between the PLC under test and the monitoring one Low Analysis Time Resolution, not enough to fulfill the ISCI requirements Ø Current solution : with a Digital Acquisition Card (DAC) ü No synchronization issues ü Finer time resolution than the previous one

Device Status Monitoring Ø Ø Internal resources of the device under test: o Scan-cycle & execution time o Memory usage o CPU status o I/O signals memory & communication modules conditions. No common way to query the device o Open-source library o Proprietary libraries - Supported by the vendors - Compatible with different versions of the same device model - Specific API to gather diagnostic information

Testing Reporting System Ø Ø No standard common format to store vulnerabilities Vulnerability classification & query support: o Improve data analysis o Track progresses o Redeploy attacks o Check device version status

Tests Reproducibility 3 -Layers Architecture Reverse Proxy & Access Control REST Web Service Extended Peach Framework JSON Client Ø Authentication to run a test Ø Built-in invariant test definitions Ø No specific security knowledge Ø OS Compatibility

Any Questions Thank you for attending!