Protective Monitoring

1. Protective Monitoring Andy Wood Enterprise Security Architect andy@securingtheenterprise.com

2. This presentation… • refers to GPG13, but is not specific to HMG; • does not cover shared services / multi-tenant SOC’s; • is my view of the world.

3. Definition • GPG13 – What it is and is not • What is Protective Monitoring (PM)? • Reasons For Protective Monitoring • Components of a PM Solution • Logs & Log Processing • Tuning • Event Correlation • Using Logs for Evidence • Concept Support Team • Service Maturity • Architecting a PM Service • Protective Monitoring in the Cloud • Considerations for PM Service • PM End to End Concept

4. Use of terms • Protective Monitoring (PM) => UK Government/Defence • Network Security Monitoring (NSM) => everywhere else • Network Situational Awareness => seems to be the new buzz word for the above! • NSM implies only the network layer, and in most cases it is. • PM reaches in to the OS and application layers. “Protective Monitoring is a set of business processes, with essential support technology, that need to be put into place in order to oversee how ICT systems are used (or abused) and to assure user accountability for their use of ICT facilities. “ (CESG GPG13) [1] • Missing people and real-time centralised visibility. “Protective Monitoring is the collection of technology, processes and people to facilitate centralised receipt of audit events pertaining to the use of the ICT infrastructure so as to alert to incidents as they occur and provide forensic evidence to allow for investigation of events leading up to the incident.” (A. Wood) Definition

5. GPG 13 is a guide, it is not policy and it is not a standard. • You do not need to implement it verbatim. • Any protective monitoring control (PMC) and control objective must be pragmatic and relate back to a risk treatment. • There is no such thing as GPG13 compliance! GPG13 – What it is and is not

6. Collection of technology, processes and people • Technology includes audit engines, sensors, collectors, database and event manager; • Processes include incident response, forensic readiness and incident management; • People include incident- analysts, investigators, responders, managers and public relations*; *Others as required such as Industry/Government CERTs or WARPs What is Protective Monitoring?

7. Compliance • Risk Management • Reporting and Continuous Improvement • Situational Awareness • Enabling Accountability • Defence in Depth Reasons For Protective Monitoring

8. Endpoint Audit Engine • Sensors • Collectors • Database • Event Manager / Console Components of a PM Solution

9. SIEM Architecture

10. Logs come in different formats • Normalisation of logs to make ‘usable’ • SIEM should also record raw log for forensic evidence. • Not all logs will be ‘readable’ out of the box by SIEM • Understand your applications, OS’s and devices prior to purchasing a SIEM • Maybe cost for development of new log processing rules • Mitre Common Event Expression (CEE) • In early stages to provide a common event format for logs; • Will help in the future, but for now barely used; Logs

11. Stage 1: Audit event written to log; • Stage 2: Log queried by sensor (or sent to sensor if Syslog) and new events pulled; • Stage 3: Depending on capability, Sensor may normalise log and drop or forward to Collector as configured. • Stage 4: Collector normalises log and carries out event processing. Logs recorded to database. Events of interest passed to Event Manager for action. • Stage 5: Events of interest are compared to alert definitions and if they match they are alerted as incidents, else recorded for reporting and investigation. Log Processing

12. Drop events at the endpoint where possible (tune audit policy) to prevent wasted network and SIEM resource • Otherwise as close to endpoint – i.e. in the sensor layer. • New alerts should alert to the console only for a period of time rather than automatically to a ticketing engine / incident management system • This will allow for focused effort on tuning out false positives. • Regularly review events which have not been alerted to filter out false negatives. Tuning

13. Correlation • “Security event correlation is the process of applying criteria to data inputs, generally of a conditional ("if-then") nature, in order to generate actionable data outputs.” (Richard Bejtlich, 2008) [4] i.e. If you see A and also B or C, then do X If you see 9 failed logon attempts followed by a success, alert someone. • Limitation will be the event window of correlation • Bigger window = more resource to process events • Should be the exception due to resource impact. • Should be implemented on mature PM solution. Event Correlation

14. If logs are to be used as evidence in a court of law you need to consider: • Digitally signing all logs at each process point in SIEM • Provides chain of custody; • For lengthy retention periods, recommend these are double hashed where possible. • Retain raw logs; • Understand how the normalisation process works; • Encrypt all data and communication channels with strong level of crypto; • Strong SIEM user authentication and auditing of all activities related to log access (including DB auditing); and • Consult a legal specialist. Evidence

15. Stage 1 • Automated analysis of events by SIEM; • Flag interesting/unusual events of interest (EoI); • Stage 2 • First line Analysts • Confirm not false positive; • Also review non-alerted events to confirm not false negative; • Stage 3 • Security Investigators investigate cause of incident and work to develop mitigation action. • Stage 4 • Incident handlers / Incident Management / PR are responsible for handling of the incident and response to the business, clients, shareholders and public. Support Process

16. As much a Science as an Art! • Impossible to calculate without a (near) identical reference. • Two options • Reference model • Another system ‘close’ to target system; • Industry metrics • I.e. SANS SIEM sizing white paper [2] • Need to understand the network • Number and types of Network Devices, Servers, Applications and End User Devices. • Calculate events per second (EPS) per endpoint SIEM Sizing

17. Extracted from SANS whitepaper Benchmarking Security Information Event Management (SIEM), Feb 2009 [2] • In reality the figures vary throughout the day, week, month and year depending upon system load. Typical Log Volumes

18. Its all “best guess” as every network operates differently. • Understand BAU activity (BA) • Understand worse case attack profile (AP) • Add a sufficient buffer (BU) SIEM Size = BA + AP + BU SIEM Sizing

19. EPS increases (significantly) when a network is under attack • Understand risks to network, including capability of threat actors. • Capability will allow you to profile EPS and penetration. • How long will attack last for? • Scenario top 5 attack types and identify impacted systems Attack Profile

20. What about storage of logs? • Typical log event is 600KB. • Daily storage requirement can be calculated by: (((total EPS x 600KB) * 60) * 60) * 24 SIEM Sizing

21. CONTEXTUAL (Business Requirements) • Risk Assessment • Everything must be done as part of risk treatment. • Understand your network • How many network devices, servers, end user devices and applications are there? • Is there a reference network you can use for understanding log volumes? • If not, there are industry reports on ‘typical’ log volumes which can be used as a starter. • Calculate the log volumes (in EPS) and storage capacity you will require. • Understand the requirements from corporate, regulatory and legal policy which the PM service needs to meet. • Talk to Information Asset Owners (IAOs) and Business System Owners (BSOs) to understand their requirements; • From above, create a final list of requirements (shopping list); • For duplicate requirements, use most stringent Architecting a PM Service

22. CONCEPTUAL (High Level) • Work with SIEM vendors to understand how their SIEM can be integrated to meet the business requirements and the log volumes calculated above. • Free advice if you are new to architecting a PM solution. • Further considerations will be discussed later. • Understand the vendors support and licensing agreement and how they will assist with the deployment, tuning and reporting. • Engage with the business to ensure PM is architected in to other business processes such as Incident Management, Computer Emergency Response Team (CERT), etc. • Strategy for event collection • Do not collect everything from day one • You will overload the SIEM / network • Understand what needs to be alerted in real-time and what will be reported (and frequency); • Understand how and where the alerts (incidents) will go; • Get business agreement and signoff; Architecting a PM Service

23. Delivered through Cloud Service Provider (CSP) service APIs • A lot of CSPs don’t have API facility for querying audit information • It is evolving, Amazon and Box have very good APIs and these are improving daily; • API’s = code development • Who will develop and maintain them? • CSP APIs change regularly – first you will know is when it breaks • New services should have requirement to deliver audit information as part of service requirements. • Still large number of CSPs with limited or no automated audit query mechanism. • i.e. Microsoft Office 365 has no ability to automatically query audit activity. • Have to raise service request to technical support! Protective Monitoring in the Cloud

24. Logging • Where possible have applications log to Microsoft Windows Security and/or Application logs and collect from here; • Less risk of using bespoke logs; • If Syslog is used, where possible use TCP for reliability. • Bandwidth • Take account of bandwidth requirements when designing a protective monitoring solution. • Remote sites with low bandwidth connections can be saturated by ‘chatty’ endpoints. Considerations

25. Updates / Upgrades • Be aware that updates and upgrades to applications and OS’s may change the way events are captured and recorded. Always alert to log sources which go quiet for a period of time. • Silent Logs • Log sources which are chatty all the time should be configured to alert staff when they stop receiving logs as this will be an indication something has happened. • The period defined should take account of normal maintenance windows such as patching. Considerations

26. Reporting and Investigations • Queries will impact upon the SIEM being able to process new events • Either calculate the reporting and investigation overhead in to original SIEM, or • Add another system to provide resource for queries and reporting. • Some vendors have VM / special license options for this purpose • What will be the impact on the database? • Should it be duplicated to an ‘investigations and reporting’ database to remove extra load? • What hashing and encryption is being used for the messages coming from the sensors to the database? • Is this of sufficient strength for your requirements? • Are raw logs required for use as evidence in legal proceedings? • How are the raw logs handled and stored to maintain integrity? • Is this compliant with BS1008: Evidential Weight and Legal Admissibility of Electronic Information [3] Considerations

27. Cloud Service Providers Auditing APIs • Security of audit information to and from CSP/SIEM – encrypted? • How will the events be injected in to SIEM? • Types of events you can query? • Any extra costs for audit capability? • Roadmap for future audit functionality? • Notification of changes to auditing capability? Considerations - Cloud

28. During an Incident Response (IR) • Turn off non-critical systems to reduce events being sent to the SIEM; • Auditing policy for during IR • More granular and low level to capture forensic events • Auditing Policy for during BAU • Less granular and low level • Develop system criticality list • Be prepared to turn off system auditing (or sensors) on lower criticality systems as part of IR process Considerations - IR

29. PM End to End Concept

30. PM is complex and must be architected against business requirements and risks. • PM is as much an art as a science. • Architecture strategy should provide evolution through maturity to prevent failure due to overload of noise. • If using Cloud services, engage service providers early. • For future cloud services, include requirements for PM auditing. • Develop scenario based attack patterns and consider worse case for SIEM sizing. • PM analysts, investigators and responders should be experienced, trained and passionate • it will be the difference between success and failure, and provide quicker evolution and maturity of the service; • More cost effective. • Use PM to report to the business and show its (and other security controls) worth. It will help with future investment! Summary

31. [1] CESG Good Practice Guide 13 – Protective Monitoring for HMG ICT Systems, CESG, v1.7 Oct 2012. [2] Benchmarking Security Information Event Management (SIEM), SANS, Feb 2009. Available from: https://www.sans.org/reading-room/analysts-program/eventMgt-Feb09 [3] BS1008:2008 Evidential Weight and Legal Admissibility of Electronic Information, BSI, November 2008. Available from: http://www.bsigroup.com [4] Defining Security Event Correlation, TaoSecurity, November 2008. Available from: http://taosecurity.blogspot.co.uk/2008/11/defining-security-event-correlation.html References