SCADA Security: How Do I Know If I ve Already Been Owned?

Transcription

1 SESSION ID: SOP-W04 SCADA Security: How Do I Know If I ve Already Been Owned? Gib Sorebo Chief Cybersecurity Technologist 17-Leidos

2 Overview Reasons for Concern Cybersecurity Challenges within Industrial Controls Systems (ICS) The Undiscovered Breach The Attack Lifecycle Current State of Control System Cybersecurity Monitoring Options for Greater Visibility Potential Ecosystem 2

3 3 Reasons for Concern: Supply Chain, Network Attacks, and Accidents Soviet Trans-Siberian Pipeline Sabotage (1982) Taum Sauk (2005) Federal Energy Regulatory Image. Used by permission. Turkish Pipeline (2008) Stuxnet (2010) German Steel Mill (2014) Ukraine Grid (2015 & 2016) WannCry / NotPetya (2017)

4 HMI = Human Machine Interface 4 Anatomy of an Attack: Ukraine Electric Grid 2015 Attacker sends phishing with pdf containing malicious macro Attacker uses credentials log into utility s VPN User clicks infected pdf Macro captures user credentials and returns them to attacker Attacker maneuvers to HMI and logs in with same credentials Attacker begins switching off power at various substations around country

5 Cybersecurity challenges within ICS Limited Visibility Lack of Cybersecurity Expertise/Culture IT/OT Divide Long Update Cycle 5

6 The Undiscovered Breach 99*. Median number of days attackers were present on a victim s network before being discovered in Excellus discovered the attack on Aug. 5 [2015] and an investigation determined that it occurred on Dec. 23, Source: 2017 Mandiant M-Trends Report *Note: Much of the recent dwell time decline is due to attacks designed to attract immediate attention such as ransomware and data wiping malware. 6

7 Typical IT Attack Lifecycle 1. Conduct Reconnaissance 2. Establish Foothold 7 3. Move Laterally and Gain Privileges 4. Accomplish Mission 1. Conduct Reconnaissance: Attacker analyzes the intended victim to identify a way to get in and what they want to get once they penetrate the network 2. Establish Foothold: Attacker gains control of a single computer inside the perimeter generally a server or a personal computer and then load tools onto that computer for remote control 3. Move Laterally and Gain Privileges: Attacker moves around the network to get closer to the computers that they want to access, and obtains privileged credentials to access them 4. Accomplish Mission: Attacker accomplishes their mission, stealing data (confidentiality), changing data (integrity) or destroying data (availability)

8 The Purdue Model An OT Attack Lifecycle Goal is to control or disrupt here Proprietary Technology OT = Operational Technology 8

9 Current State of Industrial Security Monitoring No security data; only control & performance information Security Operations Center Traditional IT Actuator HMI = Human Machine Interface WAN = Wide Area Network SIEM = Security Information and Event Management SOC = Security Operations Center PLC = Programmable Logic Controller 9 Monitored Unmonitored

10 Covering All Layers of the Software/Device Field devices (Purdue layer 0) Sensors (current state) Actuators (current state) HMIs and Engineering workstations (Purdue layer 2) Variable data (e.g., set points) Start/Stop Alarm setting Underlying HMI code Controller programming code Binaries/configuration files PLC - Controller (Purdue layer 1) Programming logic (e.g., ladder logic, structured text, instruction lists) Variable data (e.g., set points) Higher layers (Purdue layers 3-5) Application level settings (e.g., analytics, alarms, triggers) Access control settings Application and workstation configuration 10

11 Control Systems Options for Greater Visibility Look for power and frequency changes on actuators & sensors Consider network honeypots where appropriate Packet capture and parsing of proprietary protocols Where feasible, install monitoring agent on controllers 11

12 Outcomes for Monitoring Scenarios Network & Serial Data Captures Power and frequency measurements Parse log files Software Monitoring Agent Honeypots Detect anomalies Identify performance issues Build baseline Identify authorized changes Compare with intended input Detect anomalies Build baseline Detect performance issues Correlate across multiple log sources Build baseline Identify anomalies Block prohibited operations (optional) Real-time reporting of anomalies Compare with intended input On perimeter, get early insights on potential threats Internally, quickly validate intrusions 12

13 Example Architecture SIEM Packet collection/ids Endpoint agents Log parser Honeypots Data Aggregator Power monitoring 13

14 Building Custom Parsers Original Log device_id=6, state_time= :43:10.970, device_state=1, teststat=0 Post Parsing Event Time = :43:10 Device ID = Pump 3 Device State = Turning Pump On Status = OK Set correlation rule to trigger when unexpected events occur Logs Read Like a sentence. Making logs human readable allows for anyone to understand exactly what happened Increases readability of reports on historical data 14

15 Options for Tools SIEM and Aggregators OSSIM Simple Event Correlator Parsers and Analytics OpenSOC Metron Skyline Packet Collection Bro Suricata Moloch Endpoint Agents OSSEC Samhain Conpot Power Monitoring Some commercial options available Honeypots Conpot 15

16 How the Defenses Address Each Layer 1. Conduct Reconnaissance 2. Establish Foothold 3. Move Laterally and Gain Privileges 4. Accomplish Mission Honeypots offer early warning of scans and other reconnaissance Endpoint agents detect initial landing point (e.g., via phishing of IT side) Internal honeypots alert when touched the pieces together 16 Packet collection & IDS sensors alert on lateral movement Agents on HMIs and other OT systems detect suspicious connections and programs SIEMs and other backend platforms pull all OT aware packet analysis tools detect set point and other changes sent to controllers OT-aware honeypots detect attempts to change OT components Log parser detects changes to controllers Power monitoring on actuators & sensors offer final detection option

17 Putting it All Together Conduct Hardware and Software Inventory While many OT environments are good at keeping track of the physical inventory, software, and particularly their version, are often missed 17

18 Putting it All Together Conduct Hardware and Software Inventory Note opportunities for visibility (e.g., log files, network tap/span port options, connectivity, endpoint configuration files) Often referred to as a Kill Chain Analysis, this is where one might find evidence of an attack 18

19 Putting it All Together Conduct Hardware and Software Inventory Note opportunities for visibility (e.g., log files, network tap/span port options, connectivity) Identify commercial, ICS vendor-provided, and open source tools Be creative; some of the best tools may not even be considered security tools (e.g., configuration management, data historians) 19

20 Putting it All Together Conduct Hardware and Software Inventory Note opportunities for visibility (e.g., log files, network tap/span port options, connectivity) Identify commercial, ICS vendor-provided, and open source tools Build and implement test environment to demonstrate capabilities Many control system vendors offer virtual twins for testing and modeling; other comparable environments are freely available 20

21 Putting it All Together Conduct Hardware and Software Inventory Note opportunities for visibility (e.g., log files, network tap/span port options, connectivity) Identify commercial, ICS vendor-provided, and open source tools Build and implement test environment to demonstrate capabilities Coordinate with production team for access to data and tool deployment Be patient and conscious of IT/OT culture differences; help OT understand why this help them 21

22 Putting it All Together Conduct Hardware and Software Inventory Note opportunities for visibility (e.g., log files, network tap/span port options, connectivity) Identify commercial, ICS vendor-provided, and open source tools Build and implement test environment to demonstrate capabilities Coordinate with production team for access to data and tool deployment Build use cases and develop analytics and correlation rules Focus on what the bad guys would want to do and how they would want to accomplish it (e.g., tactics, techniques, and procedures) 22

23 Putting it All Together Conduct Hardware and Software Inventory Note opportunities for visibility (e.g., log files, network tap/span port options, connectivity) Identify commercial, ICS vendor-provided, and open source tools Build and implement test environment to demonstrate capabilities Coordinate with production team for access to data and tool deployment This will be an iterative process based on tool feasibility, budget, time, and skills. Build use cases and develop analytics and correlation rules Deploy tools and collect data 23

24 Putting it All Together Conduct Hardware and Software Inventory Note opportunities for visibility (e.g., log files, network tap/span port options, connectivity) Identify commercial, ICS vendor-provided, and open source tools Build and implement test environment to demonstrate capabilities Coordinate with production team for access to data and tool deployment Build use cases and develop analytics and correlation rules Start small with low risk environments less sensitive to disruption working with tabletop environments first Deploy tools and collect data Test by simulating threats 24

25 What Else? Alignment with Control Processes Staffing Levels for Security Operations Center Other Considerations Coverage of All Attack Stages False Positives No Disruption to Operations 25

26 Apply What You ve Learned Today Next Week You Should: Review the architectures for your control system environments Talk to process control engineers and managers about feasibility of gaining more visibility and explain how that helps them Inquire about virtual environments and modeling tools available In the Next Three Months You Should: Acquire and gain familiarity with tools in a test environment based on kill chain analysis of your control system environments Demonstrate operating model in a virtual environment Develop use cases 26

27 Apply What You ve Learned Today In the Next Six Months You Should: Develop and present deployment plan based on research and testing performed and coordination with OT teams and gain approval Deploy tools and data collection processes to low risk control system environments Simulate threats at multiple locations in OT environment Analyze data collected to determine ability to detect threats Iterate exercises and migrate approach to progressively higher risk environments (will likely take longer than six months to complete) 27

28 Questions For more information contact: Gib Sorebo Leidos Chief Cybersecurity Technologist phone:

29 Tools Reference SIEM and Aggregators Packet Collection Parsers and Analytics Endpoint Agents Power Monitoring Can leverage enterprise SIEM with some customizations; open source and commercial options also available. Open source: OSSIM: Simple Event Correlator: Multiple commercial options for both collection and analysis for ICS Open source: Wireshark: Bro: Suricata: Moloch: Included with SIEM and tools to build custom parsers Open source: OpenSOC: Apache Metron: Skyline (anomaly detection): Most are targeted at enterprise, but can be customized for ICS environments Open source: OSSEC (host-based IDS): Samhain: Conpot (Control System Honeypot): Some commercial options available 29