Security monitoring: aspects of design
Published 22 June 2015
© Crown copyright 2015
This publication is licensed under the terms of the Open Government Licence v3.0 except where otherwise stated. To view this licence, visit nationalarchives.gov.uk/doc/open-government-licence/version/3 or write to the Information Policy Team, The National Archives, Kew, London TW9 4DU, or email: psi@nationalarchives.gov.uk.
Where we have identified any third party copyright information you will need to obtain permission from the copyright holders concerned.
This publication is available at https://www.gov.uk/government/publications/security-operations-and-management/security-monitoring-aspects-of-design
1. Introduction: when to centralise?
You should only consider a centralised security monitoring capability once its purpose and value have been clearly investigated and agreed. Where security monitoring devices are not under the physical control of the organisation that is responsible for centralised security monitoring (such as outsourced capability or shared service contracts), you should ensure that appropriate contractual arrangements are in place to govern the definition, availability and format of security monitoring data.
As organisations move more of their enterprise IT services to public cloud services, their ability to see security monitoring data, at the level asked for, can be much reduced. This does not mean organisations should not be using cloud services because monitoring is challenging or limited. However organisations running their own services within a cloud environment should monitor those services in line with the business needs. Just because an organisation is not able to monitor everything does not mean it is failing at security, provided it identifies, understands and manages the associated risks.
2. Benefits of a centralised security monitoring service
The benefits of a centralised security monitoring service include:
- the identification of attacks across multiple systems
- standardisation of data format allowing consolidation of both inspection and analysis
- business economies due to collocation of resources, people and tools
These benefits can only be achieved by aggregating and correlating the event data from multiple networks across the organisation.
3. Centralised security monitoring: design principles
The introduction of a centralised security monitoring system presents an attractive target for an attacker. It presents the opportunity to compromise a central point, allowing access to the aggregated data stored or a staging point to attack other connected systems.
Malware hidden within the event data captured from one source may infect the centralised infrastructure, or be transmitted onwards to infect other systems.
However, the following design principles can help organisations manage the security risks of aggregating and centrally processing event data.
3.1 Security monitoring device management
Security monitoring devices within the disparate network domains should not be managed from within the dedicated centralised security monitoring network. This is because a management function requires two-way communication, which would break the unidirectional enforcement principle.
3.2 Maintain separation of event data from business data
Separating the centralised security monitoring capability from the organisation’s network can be achieved using a range of technologies such as VLANs, virtual machines or separate physical hardware.
3.3 Enforce inbound unidirectional data flow
By implementing the principle of inbound unidirectional data flow, the following items are prevented from transmission to other connected networks and systems:
- malware
- aggregated or analysed event data
- data collected from systems processing more sensitive data
- attacks resulting from compromise of the centralised security monitoring system
Inbound unidirectional enforcement may be achieved using firewall rules or hardware devices such as data diodes. The level of enforcement should take into account the risks posed to the connected networks and systems, and the risks they pose to centralised security monitoring capability.
The system design should ensure that the inbound unidirectional controls are not compromised by other services (such as service management) that connect to systems on either side of the unidirectional enforcement.
4. Verify origin of security monitoring data
The principle of origin verification is based on the need to provide mitigation against some forms of spoofing attack by verifying the data source. This can be achieved by verifying where the event data comes from against a whitelist of hostnames for a given connected network. This is only effective against the spoofing of hosts that reside in different connected networks, so the impact should be carefully considered against the risk and cost of implementing origin verification.
The system design should ensure that the components used are not vulnerable to content-based attacks which could affect the integrity or availability of the security monitoring data. A simplified view of the recommended security design pattern is shown below.
Within the diagram the origin verification components are checking that there is no data from network A coming in on the network B feed, and vice versa.
Centralised security monitoring capability
5. Protecting the security monitoring service
The fundamental reason for implementing a security monitoring service is to provide a means of mitigating, reducing or managing some information security risks identified by the organisation. For this reason it’s important to protect the confidentiality, integrity, and availability of data associated with the security monitoring service itself:
- Data confidentiality within the security monitoring service must be protected because it performs an aggregation function across the organisation. Fragments of business data from across the organisation will also end up in the collected data for which protection may be required.
- The integrity of the data collected and stored within the security monitoring service must be protected, as costly business actions can result from analysis of incorrect data. Also by altering or deleting security monitoring data, an attacker could avoid detection. Depending on the level of mitigation required the use of file permissions, software polices or hardware devices such as WORM (Write Once Read Many) may be implemented.
- The availability of the security monitoring service must be protected as any outages will expose the organisation to the risks it has been put in place to manage. Content-based attacks against applications within the security monitoring service can affect availability and where this is a significant concern, additional data format constraints and content checking might be applied to event data entering the service. Restricting the complexity of data that enters the service can support the effectiveness of content checking controls.
An attacker may launch attacks against applications within the security monitoring service. Running these applications using the minimum necessary privilege can help. The most recent supported versions of applications and operating systems should be used, and the most recent security patches applied to reduce vulnerabilities. These measures may limit the impact of a successful attack.