protective monitoring andy wood enterprise security architect [email protected]
TRANSCRIPT
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.
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
DEFINITION
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)
GPG13 – WHAT IT IS AND IS NOT
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!
WHAT IS PROTECTIVE MONITORING?
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
REASONS FOR PROTECTIVE MONITORING
Compliance
Risk Management
Reporting and Continuous Improvement
Situational Awareness
Enabling Accountability
Defence in Depth
COMPONENTS OF A PM SOLUTION
Endpoint Audit Engine
Sensors
Collectors
Database
Event Manager / Console
SIEM ARCHITECTURE
LOGS
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;
LOG PROCESSING
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.
TUNING
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.
EVENT CORRELATION
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.
EVIDENCE
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.
SUPPORT PROCESS
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.
SIEM SIZING
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
TYPICAL LOG VOLUMES
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.
Type Avg. EPSWindows Servers – Low to High Use 1 - 50Windows Workstations 1Windows AD Servers 10Unix Servers 2Network Routers 1Network Switches 2Network Firewalls - Internal 10Network Firewalls DMZ Avg 40Network IPS/IDS 15Network VPN 2Web Servers (IIS, Apache, Tomcat) 1Database (MSSQL, Oracle, Sybase – # of instances)
1
Email Servers (Exchange, Sendmail, etc) 2AntiVirus Server (indicate number of AV clients)
5
SIEM SIZING
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
ATTACK PROFILE
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
SIEM SIZING
What about storage of logs?
Typical log event is 600KB.
Daily storage requirement can be calculated by:
(((total EPS x 600KB) * 60) * 60) * 24
ARCHITECTING A PM SERVICE
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
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;
PROTECTIVE MONITORING IN THE CLOUD
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!
CONSIDERATIONS
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
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
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 - CLOUD
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 - IR
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
PM END TO END CONCEPT
SUMMARY
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!
REFERENCES
[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