Cabinet Office

Main navigation

Accounting, Audit and Monitoring

Definitions

This section deals with three key processes which collectively ensure that security violations are detected. The processes are:

• Accounting. The gathering and maintenance of information relating to possible and actual security violations.
• Audit. The analysis of accounting records, intended to detect and highlight possible security breaches.
• Monitoring. Maintaining a watching brief on critical indicators, to ensure that the accounting process is configured appropriately, and to raise alerts when predefined events occur. These indicators can be technical (such as the output from an Intruder Detection System) or non–technical (such as the level of user problem reporting).

Statement of Best Practice

Accounting and Audit can be considered to be part of the access management process which detects legitimate and non–legitimate access; supports investigation etc.

Recommended best practice is to implement and maintain accounting processes which are appropriate to local circumstances, and which are supported by:

• the timely analysis of those records;
• an ongoing process of review for the accounting and audit mechanisms themselves; and
• alerting mechanisms to allow a timely response to immediate and impending problems.

In addition to being good practice, the effective use of audit records depends upon users being made aware that their actions may be monitored.

Principles of Governance

ISO/IEC 17799
Logging administrator actions, and the maintenance of audit records are identified by the standard as best practice, in addition to the process of managing time synchronisation to maintain integrity of the records.

CESG Documents
IS1 defines three levels of protective monitoring, as a basis for assurance level calculations. CESG INFOSEC Memorandum No 22 (Protective Monitoring) provides a policy statement, definitions and advice on general threats and countermeasures. IS2 gives guidelines and best practice for monitoring and audit in the context of risk management. IS4 sets out the minimum standards for Comsec in this area.

Infrastructure requirements
Where there is a connection to a centralised infrastructure such as the GSi, or Airwave, the connection requirements may mandate audit and accounting processes to support the threat monitoring process for the infrastructure itself. In the case of the GSi there are specific audit and accounting requirements laid down. CPNI issue supporting guidelines in this area, primarily CPNI Technical Note 03/03: Protective Monitoring - Introduction to Audit and Accounting Log Analysis.

Legislation

The key factor is likely to be the Police and Criminal Evidence Act (PACE). Where material gathered in an automated log is to be used as evidence, there must be a reasonable belief that the system was operating correctly at the time the records were produced. However, for service providers the Regulation of Investigatory Powers Act (RIPA) may also be relevant, in terms of logging information for subsequent recovery, in addition to the Data Protection Act, Human Rights Act and Freedom of Information Act.

Best Practice Guidance

Coverage of automated logging

Organisations must acknowledge this and develop a logging policy aligned to business needs, based on the key principles of:

• Currency. Without periodic revision, a policy will inevitably become out of date in a changing business environment. The policy must be periodically reviewed (at least annually) if it is to remain effective.
• Prioritisation. Resources need to be applied in the most effective manner. Administrator accounts and changes to account permissions should always be audited, since this is the primary route for unauthorised access. Server logs generally provide second level fault indications and need not always be full, whereas firewall logs are critical.
• Flexibility. Audit policy must be based on the flexible use of available techniques. Where resource limitations do not permit full logging, consider the use of vertical sampling (full logging on groups or activities, with the groups rotated from time to time) or horizontal sampling (a subset of activities but for all users).
• Adaptability. When a problem is suspected or identified, the audit policy must be adapted to ensure that the right information is gathered to allow an investigation.

Retention
Retention of accounting logs assists with:

• The investigation of the history of an incident, specifically the identification of the extent and duration of a breach.
• The search for patterns of incidents which may only show up in the longer term.
• The production of collated evidence.

The retention of logs is therefore an important part of the audit and accounting process. For most Government systems. logs should be retained for at least six months, under access control, and with periodic checks that the logs remain readable. It is good practice to include in a service contract any specific accounting and auditing requirements.

Analysis
Analysis must always be based on a set of defined objectives. Firewall logs for example will generally be used to obtain a picture of the changing threat environment; server logs will be used to detect violations of user policy; proxy logs will be used to detect possible violations of acceptable Internet use.

Reporting
In all aspects of accounting and audit, it is vital to concentrate on the objective: the effective use of the information to ensure an ongoing level of IA. Communication of the analysis results is a critical aspect of this. In the general case reporting falls into one of two areas: reporting of specific incidents; and reporting of aggregated information.

Reporting of specific incidents must always be carried out with the following principles in mind:

• Anonymity. Depending on the target audience and intended distribution, there may be a requirement for masking of source data.
• Evidence. Each statement made in the report must be supportable through the available evidence. Where doubt exists this must be stated clearly.
• Clarity. There must be a focus on the purpose of the investigation and subsequent reporting.

Reporting on aggregated information should use effective methods of communication such as dashboard reports (where a few key indicators are presented with a simple red/amber/green structure); or balanced scorecards. Balanced scorecards can be particularly useful for security since they include an assessment of the causes of incidents. The diagram below provides an example.

Dashboard reports and balanced scorecards can be used to portray either period summary information (such as the number of detected viruses in the preceding month) or trends. In the general case, some combination of the two will be most useful, since it includes an element of absolute measurement (e.g. measuring period figures for attempted accesses to proscribed web sites, but against an agreed target month on month).

Application
The generation of the reports is not an end in itself. Where action is required as a result of a circumstance identified in a monitoring report, there must be a means of ensuring that the action is:

• relevant to the issue;
• timely;
• appropriate to the circumstances;
• itself monitored for effectiveness.

Synchronisation
For any reasonably sized system, analysis of all sources of accounting information as a unified whole will be a considerable task. To avoid this, an end-to-end analysis should be used to determine the information required from each source to meet a specific requirement. This will then also identify the synchronisation and linkages required between sources.

Surveys
In cases where the underlying risk cannot be mitigated entirely satisfactorily, or for particularly sensitive systems, it may be use to consider occasional, in-depth monitoring and audit exercises (such as the CESG Intrusion Detection Survey).

Forensics
Forensics requires very specialised skills and it is therefore recommended that organisations use experts where there is a requirement.

However, forensic readiness planning is strongly recommended. CPNI provide advice in their Technical Note 1/2005.