Principle
The organisation monitors the security status of the networks and systems supporting the delivery of essential services in order to detect potential security problems and to track the ongoing effectiveness of protective security measures.
Description
An effective monitoring strategy is required so that actual or attempted security breaches are discovered and there are appropriate processes in place to respond. Good monitoring is more than simply the collection of logs. It is also the use of appropriate tools and skilled analysis to identify indicators of compromise in a timely manner so that corrective action can be taken.
This principle also indicates the need to provide effective and ongoing operational security. As time goes on new vulnerabilities are discovered, support arrangements for software and services change and functional needs and uses for technology change. Security is a continuous activity and the effectiveness of the security measures in place should be reviewed and maintained throughout the delivery and operational lifecycle of a system or service.
Guidance
In order to comply with NIS Directive requirements, your security monitoring should focus on detecting incidents or activity that impact on the protection and resilience of essential services and the network assets and systems that underpin them. Log and network data collection, analysis tools and threat intelligence should prioritise these assets and systems.
Of course, your monitoring should also address other security and resilience requirements that are outside the scope of the NIS Directive e.g. the protection of personal data, or general network performance and service quality.
Known and Unknown threats
An organisation’s monitoring capability should be able to find known threats on their network, for example detecting when known command and control traffic is communicating to the Internet, or an AV signature is present in a file. Automated Intruder Prevention or Detection tools (IPS or IDS) or automated remediation are recommended, in cases where proven effective, as this frees up valuable analyst time. IDS can be particularly useful, as they can be placed strategically, to monitor particular network sections where attacks might be expected, or of particular concern (e.g. at a firewall, or on a particular host). Organisations should endeavour to understand what automated tools do and how best to use them, in order to ensure they are getting value for money from them.
Organisations should also have the capability to find previously unknown threats, by looking for indicators of attack combined with local system knowledge and sector threat information.
C1 focuses on known threats, where as C2 covers unknown threats.
Log collection and aggregation
Having the correct visibility of your systems is critical to detect potentially malicious activities. Indicators of Compromise will usually contain common tell-tale signs of an attack, so ensure you collect and aggregate the following log sources:
-
Web site traffic going to the Internet. At a minimum this should include domain names and URL’s, but if possible, stretch to the full HTTP header information. This is because the initial infection and persistent connections are often made through HTTP(S) traffic and could appear to come from user devices (most likely) or servers. HTTP headers often provide clues to malicious activity.
-
Email traffic. Again, as a minimum, the metadata about what’s sent and received, but if it is possible to capture both headers and contents then consider doing so. Phishing attacks, delivered over email, often tempt the user to click links, so getting visibility of these links in combination with web traffic helps detection and subsequent analysis.
-
IP connections between your network and the Internet. It is useful to capture 5-tuple metadata of accepted connections on the edge of your network. This would show any raw connections coming out of your network, such as HTTP traffic not going through a proxy server or direct malware command and control sessions.
- Netflow from the IT or OT (Operational Technology) boundary. Capturing netflow crossing OT boundaries is particularly important, as it is so much more difficult to patch OT systems, so they inherently carry vulnerabilities.
Your log collection should capture staff use of corporate systems, both regular users and system administrators, at the application and operating system layers. This helps to identify suspicious user behaviour for either an attacker or insider.
Duration and level of logging is a corporate choice, balancing storage cost with ability to retrospectively query data during (and after) an incident. Consider any legal data protection laws you may need to adhere to on the collected information, for example if collecting personal data in logs.
The audit and log information should be held in a database with access controls that limit access to monitoring analysts, and is isolated from other corporate trust domains. This is important as it will prevent an attacker from deleting or modifying logs.
Your organisation’s asset management processes should ensure knowledge of network assets is sufficiently detailed and accurate to quickly and efficiently trace observed events to their sources.
Monitoring and analysis tools
The collected logs should be compared against Indicators of Compromise (from threat intelligence sources) to detect known threats.
You should choose appropriate tools to help analyse and correlate differently structured and normalised network datasets, to identify and investigate events of interest. These tools should be chosen to optimally scale to and use the types of network and logging data you expect to analyse and the workflows you have designed to analyse, triage and investigate security events. Your staff should receive the appropriate training to use these tools.
Consider the flexibility of the tools used, as you do not want to preclude your analysts from proactively finding unknown threats (as described in C2). Avoid purchasing black box tools that do not allow flexible querying, or provide results without showing the corresponding rationale.
Threat Intelligence
This is a key requirement for any security monitoring capability and can come in many formats, volumes and quality. Threat intelligence can be collected from open discussion forums, trusted relationships, paid-for contracts with threat intelligence companies or even generated internally.
Threat intelligence can be either automated feeds that describe Indicators of Compromise (e.g. hashes of known nefarious files or lists of IP addresses) or more descriptive human readable reports documenting indicators of attacks or reporting on a type of malware. You should consume both types of threat intelligence appropriately.
We would recommended that when choosing automated threat intelligence feeds, favour quality over quantity (false positives can be costly for analyst time) and ensure the feeds can be automatically ingested by your chosen analysis platform.
Governance, Roles and Workflows
Your operational monitoring teams should comprise roles and responsibilities that cover both security and performance related monitoring. Combining these functions can help bring greater business benefit and multi-purpose use of the same datasets.
The size and structure of these teams will vary between organisations, but should usually include people who know the network, its hardware and software and the types of data that they process and produce. The team should also include investigators, who can work with threat intelligence to identify, investigate and triage security events and managers who understand the organisation’s business and are able to assess the significance of security events in terms of their potential to cause harm, such as disrupting operations or leaking sensitive corporate or personal data.
Your monitoring capability should work seamlessly with Incident Management (see Objective D), knowing when and how to alert on or escalate events and how to share the right sort of information with incident managers. Monitoring and Incident Management may even comprise some of the same staff, working as part of a Security Operations Centre (see NCSC guidance – SOC Buyer’s Guide).
Regular Review and Update
Your monitoring strategy and capability should evolve with your business requirements, networks and systems. That is, as the system develops (e.g. new systems, networks or software versions), the monitoring capability is updated in order to ensure that all essential services and related assets are covered. Your capabilities should also evolve to keep up with changes in the threats you need to mitigate.
Your tools should be configurable and adjustable to handle new datasets and your monitoring staff should be able to work with these changes. New IT systems should be designed to produce logging data that allows the appropriate level of monitoring, before they are made operational.
References
CREST – Protective Monitoring Guidance
NIST – Continuous Security Monitoring
NIST Guide to Intrusion Detection and Intrusion Prevention Systems
ISO 27002 / 27019
IEC 62443
< Back to Principle B6 Forward to Principle C2 >
Source: NCSC
