PROTECTIVE MONITORING
Andy Wood
Enterprise Security Architect
andy@securingtheenterprise.com
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

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

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

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?

Compliance

Risk Management

Reporting and Continuous Improvement

Situational Awareness

Enabling Accountability

Defence in Depth
REASONS FOR PROTECTIVE MONITORING

Endpoint Audit Engine

Sensors

Collectors

Database

Event Manager / Console
COMPONENTS OF A PM SOLUTION
SIEM ARCHITECTURE

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

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

Drop events at the endpoint where possible (tune
audit policy) to prevent wasted network and SIEM
resource


New alerts should alert to the console only for a
period of time rather than automatically to a ticketing
engine / incident management system


Otherwise as close to endpoint – i.e. in the sensor layer.
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

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

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


Stage 1

Automated analysis of events by SIEM;

Flag interesting/unusual events of interest (EoI);
Stage 2



Confirm not false positive;

Also review non-alerted events to confirm not false negative;
Stage 3


First line Analysts
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

As much a Science as an Art!

Impossible to calculate without a (near) identical reference.

Two options

Reference model


Industry metrics


Another system ‘close’ to target system;
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
Type
Windows Servers – Low to High Use
Windows Workstations
Windows AD Servers
Unix Servers
Network Routers
Network Switches
Network Firewalls - Internal
Network Firewalls DMZ Avg
Network IPS/IDS
Network VPN
Web Servers (IIS, Apache, Tomcat)
Database (MSSQL, Oracle, Sybase – # of
instances)
Email Servers (Exchange, Sendmail, etc)
AntiVirus Server (indicate number of AV
clients)
Avg. EPS
1 - 50
1
10
2
1
2
10
40
15
2
1
1
2
5
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

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

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

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
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;
ARCHITECTING A PM SERVICE

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
 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

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

/ Upgrades
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.


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?


Some vendors have VM / special license options for this purpose
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 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

During an Incident Response (IR)

Turn off non-critical systems to reduce events being sent to the
SIEM;

Auditing policy for during IR


Auditing Policy for during BAU


More granular and low level to capture forensic events
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
PM END TO END CONCEPT

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
[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/readingroom/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-eventcorrelation.html
REFERENCES