Protective Monitoring Guide

Related information

Technical Controls Policy

About this document

Note: This is Legacy IA Policy. It is under review and likely to be withdrawn or substantially revised soon. Please contact us before using this on a new project: security@justice.gov.uk

This policy applies to all staff and contractors who work for the Ministry of Justice (MoJ).

This document is the MoJ IT Security – Protective Monitoring Guide. It is designed to help protect MoJ ICT systems by providing implementation guidance for a protective monitoring solution.

How to use this document

The purpose of this document is to provide guidance on developing a protective monitoring schema for a MoJ ICT system. It must be read in conjunction with CESG Good Practice Guide No.13 - Protective Monitoring for HMG ICT Systems.

Note: This document is a supplement to CESG Good Practice Guide No.13 - Protective Monitoring for HMG ICT Systems, not a replacement.

Overview

Introduction

Protective Monitoring is a set of business processes, with essential support technology, that oversees how ICT systems are used and to assure user accountability for their use of ICT facilities. Protective monitoring places mechanisms for collecting ICT log information to provide an audit trail of defined security relevant events which can be used for reporting and alerting.

HMG Security Policy Framework (SPF) Mandatory Requirement 9 states that:

Departments and Agencies must put in place an appropriate range of technical controls for all ICT systems, proportionate to the value, importance and sensitivity of the information held and the requirements of any interconnected systems.

In order to meet that requirement, the SPF stipulates that ICT systems must:

Put in place a proportionate risk based suite of technical policies and controls including: … IV. Protective Monitoring;

Policy statements on protective monitoring are covered in IT Security – Technical Controls Policy, while this document sets out the MoJ guidance for its implementation.

Scope

This guide applies to all MoJ ICT systems including ICT systems hosted by third party suppliers on behalf of the MoJ.

Demonstration of Compliance

The CESG Information Assurance Maturity Model (IAMM) sets out the minimum maturity level Government departments should attain. Protective monitoring is captured as a basic requirement in Level 1 of this model, which the MoJ will need to demonstrate compliance with in their IAMM return to the Cabinet Office.

Basics of protective monitoring

Accounting and Auditing

Protective monitoring as described in CESG Good Practice Guide (GPG) No.13 centres on the concepts of Account and Auditing.

Accounting is defined as ‘the process of collecting and recording information about events’, whilst Auditing is defined as ‘the systematic, independent and documented process for obtaining audit evidence and evaluating it objectively to determine the extent to which audit criteria are fulfilled’.

An organisation can choose to account for almost every transaction that takes place on the system, but then audit almost none of them. When deciding on what approach to take with accounting and auditing it is necessary to first identify what types of information should be recorded then decide what information should be examined and how regularly that examination should be carried out.

Accreditation and protective monitoring

The audit criteria and the decision on what information is collected and alerted upon must be derived from a risk assessment conducted against the ICT system. This decision making process for the selection of protective monitoring controls forms part of the Accreditation process where the resultant protective monitoring solution must be documented in the Risk Management and Accreditation Document Set (RMADS). This document provides guidance on the selection of those controls, the key questions to be applied to that selection and a template for documenting it.

Further details on the Accreditation process can be found in the Accreditation Framework.

Note: The Accreditor will assess any protective monitoring solution against CESG GPG No.13, the policy statement in the IT Security – Technical Controls Policy and this guide.

Accounting

The decision on how much information needs to be recorded in an accounting log requires a comprehensive assessment and must be consummate with the risks identified. Recording too much information can be as great a problem as recording too little. If too much information is recorded it can become extremely difficult to review and can cause performance and capacity problems for an ICT system. If too little information is recorded it may be impossible to investigate a security incident effectively.

A good method of analysing this problem is to have a structured approach whereby the different types of information which could be captured are analysed at the different levels of an ICT system (e.g. network, system and application), building a picture of the inter-relationships between the different accounting logs (at those different levels). For example, accounting may take place at the following levels:

• Network accounting (e.g. logs created by network components, such as firewalls or domain controller);
• System accounting (e.g. logs created by individual host systems, such as Windows server security logs);
• Application accounting (e.g. logs created by individual applications).

The network/systems logs can be used to record the following security events:

• All actions taken by the Administrators;
• All actions taken whilst using the database administrators’ accounts;
• All updates to operating system files;
• All workstation time-outs;
• Any attempts to copy the password file;
• All updates to the application software;
• Use of the system out of normal hours.

The application logs tend to record almost all the actions that take place whilst an application is being used. These tend include:

• All failed log-on attempts;
• All successful log-ins;
• All log-offs;
• All updates to a record;
• Each time a record is viewed.

Auditing

The types of auditable event mainly fall into two categories.

Firstly, there are events which need to be checked on a regular basis because they could indicate that someone is actively trying to breach the security of the system. An example of this is unauthorised log-on attempts or copying of the password file.

Secondly, when a breach of security is detected (or reported), the work which was being conducted on the system at that time in order to identify:

• How the breach of security occurred;
• Who was responsible for the breach;
• The amount of damage caused by the breach.

To support an investigation into a security incident, it is important to have a range of flexible reporting tools which allow the investigator to sort through the accounting information collected in a variety of different ways, and allows interconnections to be made between data derived from different sources.

Note: When considering what types of information which should be captured and what auditing should be implemented, it is important to ensure that the relevant IT Security Incident Management Plan is factored into the decision making process. This is to ensure that any protective monitoring solution supports the identification, alerting and investigation of security incidents. Further information can be found in the IT Security Incident Response Plan and Process Guide.

Developing a protective monitoring schema

For the purposes of this guide, a protective monitoring schema sets out all the controls points which will be implemented in an ICT system.

Development stages

The business process for protective monitoring is captured in Figure 1 of CESG GPG No.13. This section covers the stages which should be followed when developing a protective monitoring schema:

• The key questions which must be applied which selecting protective monitoring control items;
• The minimum protective monitoring requirement;
• Selecting minimum control objectives;
• Setting the minimum audit requirement;
• Reporting and service validation.

Key questions

The following key questions cover items which should be thought about when selecting protective monitoring controls:

• What is being audited and monitored? In terms of:
  • Usage scenarios - what users are allowed to do and which actions need to be accounted for;
  • Exceptions and how they will be detected - what users are not allowed to do or what would constitute suspicious activity;
  • The complexity in terms of the different types of connectivity to support these interactions (e.g. air-gapped systems, electronic exchanges, remote access, wireless, Internet services, etc.).
• What information will be collected to support the accounting, audit and monitoring of these activities?
• How the information gathered will be used (including both a list of permitted purposes and a list of prohibited purposes)?
• Who will access the protective monitoring data and their associated responsibilities?
• How the information will be protected, stored, retained and disposed of?
• How notification of monitoring is achieved and how user consent is obtained, or otherwise?

Minimum protective monitoring requirement

The minimum level of protective monitoring which need to be implemented is set out in CESG GPG No.13; Table 1 following reproduces part of GPG13 which sets the baseline requirement to achieve a minimum level of protective monitoring.

Table 1 - Minimum audit requirements

Additional control objectives

Note: During the risk assessment process, additional control objectives may be identified for inclusion into the set derived from CESG GPG No.13. These additional control objectives must be recorded in the protective marking schema.

Minimum control objectives

The minimum control objectives that are to be applied are in the Protective monitoring schema template. These control objectives are provided as a template for the author of the protective marking schema to fill in, notes are provided and once completed can be used as part of the description of the protective monitoring solution presented to the system Accreditor in the RMADS.

Where a minimum control objective cannot be met (for example, due to an implementation restriction or where the risk does not justify the control) it must be recorded as an exception (a template is provided here ).

Note: This is generic set of control objectives and the templates provided in section A.1 and A.2 are designed for the author of the protective marking schema to customising based on the guidance provided in this document, CESG GPG No.13, the ICT system and associated risk assessment.

Control objectives extensibility

It is important to ensure that there is a mechanism in place to review, update or extend the protective monitoring controls once an ICT system is in live operation. This will occur when an ICT system undergoes the re-accreditation process, further details of which can be found in the Accreditation Framework.

Minimum audit requirements

The minimum audit requirement is specified in CESG GPG No.13 where the following provides the audit criteria which must be captured in the protective monitoring schema (a template table is provided here ):

• The retention period of any protective monitoring data captured;
• Details on when log checks are to be carried;
• Details on when the protective monitoring system is to be manned;
• Details on when the system is to be subject to compliance review;
• Details on the reporting structure (refer to Reporting Structure ), which should be specified in terms of a weekly, monthly or annual report.

Baseline Control Set and implementation of controls objectives

Table 2 defines the minimum controls which must be implemented to achieve the baseline controls set out in HMG IA Standard Numbers 1 & 2 – Supplement: Technical Risk Assessment and Risk Treatment.

Table 2 - Baseline controls to achieve protective monitoring

With Table 2 in mind CESG GPG No.13 outlines a number of options which should be consider when translating the identified control objectives into a protective monitoring solution which can be implemented in an ICT system.

The following provides the typical list of components which can be put together to deliver a protective monitoring solution:

• Security Information and Event Management (SIEM) system, which includes:
  • Log collection;
  • Log analysers;
  • Filtering, query and pattern matching tools;
  • Reporting tools;
  • Computer forensic tools;
  • Network management system;
• Intrusion Detection and Prevention System (IDS/IPS);
• Network Intrusion Detection System (NIDS);
• Host Intrusion Detection System (HIDS);
• Wireless Intrusion Detection System (WIDS).

A template is provided here to capture all the accounting items to be collected and where those items are collected.

Reporting Structure

Protective monitoring is only effective if there is a clear and effective reporting structure is in place to ensure that any alerts generated by the protective monitoring solution are escalated to the relevant people.

Note: The protective monitoring solution must fit into the overall IT Security Incident Management plan; refer to the IT Security Incident Response Plan and Process Guide for further details.

Service Validation

Once the protective monitoring schema has been generated and approved by the system Accreditor, the next step in delivering an effective protective monitoring solution is ensuring that the service provided is working as planned and that it is effectively gathering the data. This part of the protective monitoring solution must be document and should contain the following:

• Details on the initial operational capability and the start date;
• A defined series of service review points, specifically identifying the review of the control sets and the validation of data gathered;
• A defined criteria for spurious or unnecessary data that should be identified during the validation period and removed from the log reporting/alerting mechanism;
• Details on the full operational capability and the start date. At the point the protective monitoring service is fully operational, no changes may be made to the service without the approval of the system Accreditor.

Protective monitoring schema template

Minimum control objective

This section of the template captures the implementation details and compliance evidence for each protective monitoring control (PMC) specified in CESG GPG No.13. A minimum control object for each PMC is entered and is intended to provide an initial starting position.

Minimum control objective for PMC 1

For PMC 1 the following is to be implemented:

Minimum control objective for PMC 2

For PMC 2 the following is to be implemented:

Minimum control objective for PMC 3

For PMC 3 the following is to be implemented:

Minimum control objective for PMC 4

For PMC 4 the following is to be implemented:

Minimum control objective for PMC 5

For PMC 5 the following is to be implemented:

Minimum control objective for PMC 6

For PMC 6 the following is to be implemented:

Minimum control objective for PMC 7

For PMC 7 the following is to be implemented:

Minimum control objective for PMC 8

For PMC 8 the following is to be implemented:

Minimum control objective for PMC 9

For PMC 9 the following is to be implemented:

Minimum control objective for PMC 10

For PMC 10 the following is to be implemented:

Minimum control objective for PMC 11

For PMC 11 the following is to be implemented:

Minimum control objective for PMC 12

For PMC 12 the following is to be implemented:

Exceptions

The exceptions to the minimum baseline requirements must be recorded, based on the following template table.

Audit regime

The audit regime which forms part of the protective marking solution must be recorded based on the following template table:

Accounting items

The following table provides a template to capture all the accounting items to be collected in an ICT system, its source and alerting details.

Contact and Feedback

For any further questions or advice relating to security, or for any feedback or suggestions for improvement, contact: security@justice.gov.uk.