Security Event Monitoring (SEM) Working Group

Transcription

1 Security Event Monitoring (SEM) Working Group Dale Peterson, SEM WG Chair Digital Bond, Inc. Collaborating to Advance Control System Security

2 Control Systems Are Being Monitored Detecting Intrusions and Security Events Security Event Monitoring (SEM) Products Managed Security Services Providers (MSSP s) 2

3 SEM Working Group Projects Use data from monitored SCADA/DCS to quantify threat Risk = Threat x Vulnerability x Impact Add SCADA/DCS intelligence to monitored solutions Working Group Meeting: Tomorrow at 2:00 4:30 Salon B, Grande Ballroom 3

4 Adding SCADA Intelligence To SEM SEM not looking at SCADA/DCS application logs Many security events in these logs Modify display, grant admin, server failover, Proposed solution: Data Dictionary Identify and normalize security events Create database tables with applicable patterns Related Example: Project LOGI2C 4

5 Quantifying The Threat Craig Baltes LURHQ Collaborating to Advance Control System Security

6 SCADA/DCS Network Monitoring What is being monitored? How does the Working Group insure only SCADA/DCS events are reported? What types of events are detected? 6

7 CISCOSYSTEMS CISCOSYSTEMS CISCOSYSTEMS PLC Monitor Field Security Devices Alerts, blocked intrusion attempts Field Monitor Network IDS Servers HMI Monitor Firewall & VPN Logs and Alerts Internet NIDS Backup Control Center Firewall-Firewall VPN NIDS Enterprise DMZ Decision Support Servers Monitor Critical High Risk Servers Alerts, Operating System, and Application Logs: Control, Historian, DSS, Active Directory and Web Servers; Web and Database Applications; and SCADA/DCS Applications Untrusted Hosts

8 8 Sherlock Platform Architecture

9 Security Event Management 9 Technology People & Process firewall firewall IPS NIDS HIDS Negative Filter 4,989,950 Non-Security Event No Action Required 75 5,000,000 events Sherlock Inspector and Inspector Agent Remaining Events of Interest Event Consolidation Positive Filter 10, , Automated Analysis 200 Security Event Worm - Customer Not Vulnerable 75 Security Event Information Gathering 50 Non-Security Actionable 3 per week Anomaly Incident Handling Process: Aggregate, Correlate, Categorize, Assess Threat, and Respond Incident is logged for future correlation and reported, but no further action required. Low Threat Incident requires near term intervention by LURHQ and/or the customer to prevent availability or security issue. Medium Threat server server server Security Event Human Controlled Exploit Attempt 1 per week Incident requires immediate intervention by LURHQ and the customer to prevent and/or remediate availability or security issue in progress. High Threat Information from Intelligence, Scanning, Trending & Auditing

10 Threat Statistics Number of control systems monitored Number of actionable events An actionable event requires a MSSP call or An actionable event causes an asset owner to investigate or initiate a response Categorize the actionable events Denial of Service Scan Exploit Suspicious User Activity Malware Other SCADA Application or Exploit 10

11 Threat Statistics Comments Expectation is a low number of actionable events Activity on these networks is limited Organizations monitoring are leading edge and more secure Data is only provided in aggregate All asset owner and MSSP data is combined MSSP s can be a big help Provide data on multiple control systems Another level of anonymity WG Request: ask your MSSP to participate 11

12 First set of data April-May Monitoring 12 SCADA Networks 8 Actionable Events 5 from Network Scans 3 from Suspicious User Activity 12

13 Contact Information Dale Peterson Control System SEM Chair Digital Bond, Inc Craig Baltes Senior Security Consultant LURHQ