Principle: C1 Security monitoring

Overview

This outcome relates to the scope of your monitoring activities, and the extent to which your collected logs enable you to detect unusual events, indicators of compromise and security incidents.  

Monitoring

Your organisation should have a monitoring strategy in place which enables you to identify signs of malicious activity and respond appropriately. Logs should be collected and analysed on an ongoing basis.

See the National Cyber Security Centre's (NCSC) 10 steps to cyber security guidance for additional factors to consider when implementing your monitoring strategy.

Monitoring coverage

You should collect logs for selected sources across your systems and networks.

Although at 'Partially Achieved' level your coverage does not have to be comprehensive, examples of sources you might collect are:

• host-based logs – for events relating to the file system, running processes and program load events
• service logs – for services such as identity, mail, document storage and back-end services such as databases
• infrastructure logs – for device events such as website connections and domain name system (DNS) requests
• device compliance – for device status and configuration
• device attestation – for device and device software signals and measurements  

For expanded explanations of the above, see the logging and protective monitoring section in NCSC’s device security guidance.

Monitoring user and system activity

Typical examples of suspicious or undesirable user and system activity include:

• unusually high instances of failed login attempts
• access attempts at unusual hours and locations
• changes in system configuration or permissions
• addition or removal of applications and system services from operating systems
• transferral of large amounts of data
• changes to important system files and data records

At 'Partially Achieved' level, your organisation does not need to have a fully agreed list of parameters, and you may not be monitoring for them on a continuous basis.

However, you should be able to show that you monitor some user and system activity using the logs, alerts and tools available to you.  

Network boundary traffic

As part of your monitoring activities, particular consideration should be paid to boundary devices which monitor inbound and outbound connections.

Boundaries that should be prioritised include those located between your:

• network and the internet
• network and third-party networks
• IT system and connected medical devices

Organisations using the Secure Boundary service will generally meet the requirements of C1.a PA#4, which relates to monitoring traffic crossing the network boundary, including IP address connections.

Querying with search tools

Where not all log datasets can be queried easily, you should ensure that you can query at least some where needed to aid in investigations.  

You might do this via a security information and event management (SIEM) platform, or a more localised query tool.  

Monitoring tools

Your monitoring tools should work with most log data, with some configuration.

This may mean making practical changes including:

• enabling connectors or agents – for example, installing or enabling what is needed for a server, firewall or application to send its logs to the monitoring platform
• applying vendor templates – for example, suppliers may provide ready-made rules or templates for common log types
• configuring parsers – this means helping your monitoring tools recognise that one part of a log is the username, another part is the time, and another part is the device or IP address
• mapping key fields – for example, one system might call it 'user', another 'username', and another 'account ID'. These should be mapped so that the monitoring tool treats all these fields as the same kind of information
• creating dashboards or filters for common investigations – this means setting up screens or saved searches so people can quickly find relevant information

Where some logs cannot yet be fully integrated, you should document the gap and prioritise improvements based on risk.

Capturing all common threats

Your monitoring tools and procedures should allow you to understand typical patterns of activity on your networks. Indicators of compromise and unusual system behaviour that align with common threats should stand out as deviations from the norm.

The forms that indicators of compromise take are always changing, but will include known bad internet protocol (IP) addresses, domains, hashes and strings.

Your approach to detecting them should be informed by: 

• your own up-to-date understanding of common threats to your organisation 
• threat intelligence received from NHS England’s National Cyber Security Operations Centre (CSOC), including via Microsoft Defender for Endpoint

Making log data available for analysis

You should ensure log data is available for analysis when needed.

In practice, this means that: 

• you have identified your information or technology assets which would cause the biggest impact to your essential functions if targeted by threat actors
• you understand the logging capabilities of those assets and how to practically access their log data

 Interpreting indicators of good practice

To support your response, you can upload (or link to) evidence which best demonstrates your achievement of the contributing outcome. Examples include:

• documents showing data sources being monitored and rationale
• procedures for monitoring users
• procedures for monitoring network boundary traffic
• procedures for querying log datasets
• monitoring tool configuration information
• threat information supporting monitoring processes
• procedures for accessing log data of critical assets
• scheduled review process for monitoring coverage
• procedures for correlating log data with supporting information

This is not an exhaustive list. You can provide other types of evidence if you feel they are relevant to the contributing outcome.

Your supporting statement should cross-reference how each piece of evidence provides justification for your achievement of the contributing outcome, including relevant page numbers where appropriate.

National services 

The following national services may help you meet the requirements of C1.a Sources and tools for logging and monitoring:

• Security services | Secure Boundary
• Security services | Vulnerability Monitoring Service (VMS)
• Security services | Bitsight
• Security services | Microsoft Defender for Endpoint (MDE)
• NCSC services | Early Warning
• NCSC services | Check your cyber security

Additional guidance

For additional guidance, see:

National Cyber Security Centre CAF guidance | C1 Security monitoring
National Cyber Security Centre | Device security guidance – Logging and protective monitoring
National Cyber Security Centre | 10 steps to cyber security – Logging and monitoring

Overview

To meet this outcome, you need to demonstrate that you have secured your log data through secure design, identity and access management (IAM) and procedural controls.

Securing logs

If compromised, internal log files would enable an attacker to conceal their activities, divert attention and manipulate assessments of ongoing incidents. 

For this reason, it is important to establish a clearly defined set of protective controls and design your system architecture in a way which keeps logs secure.

Controlling access

You should hold logging data in a secure location, appropriately limiting the ways in which it can be accessed from your network.

IAM permissions should be employed. Only privileged users with a legitimate business need should be granted access rights, and this should be done on a case-by-case basis and reviewed regularly.

Monitoring access

You should monitor access to log data by ensuring the systems that store, process or display logs are auditable. Your monitoring activities should enable you to identify log data being:

• copied
• deleted
• modified

Depending on your tools, it may not be possible to detect when log data is being viewed without the viewer performing an action. Other controls should be used to reduce the risk of inappropriate access.

Retention periods

You should define and implement retention periods for log data held by your organisation. A practical approach to this would be grouping logs into sensible categories such as those set out in NCSC guidance on log sources.

For each type of log data your organisation holds, you should define and implement an appropriate retention period. This should reflect the role the logs play in supporting detection, investigation and response activities.

As a general guide, NCSC advises that where logs would help answer key incident investigation questions outlined in tables in their log sources guidance, organisations should retain them for a minimum of 6 months.

Policy and procedural controls

Your organisation must agree a permitted scope of activities relating to log files and ensure that they are documented in your policies and followed by staff members. 

No member of staff should view, copy, delete or modify log files unless they have a legitimate reason to.

National services

The following national services may help you meet the requirements of C1.b Securing logs:

• Security services | Secure Boundary

Supporting evidence

To support your response, you can upload (or link to) evidence which best demonstrates your achievement of the contributing outcome. Examples include:

• documents evidencing log access controls 
• lists of authorised users and systems 
• procedures for monitoring access and actions to log data 
• retention schedules for log data
• policies and procedures for activities relating to log files
• procedures for protecting log data against threats
• procedures for verifying the integrity of log data

This is not an exhaustive list. You can provide other types of evidence if you feel they are relevant to the contributing outcome.

Your supporting statement should cross-reference how each piece of evidence provides justification for your achievement of the contributing outcome, including relevant page numbers where appropriate. 

Additional guidance

For additional guidance, see:

National Cyber Security Centre CAF guidance | C1 Security monitoring
NHS England | NHS Secure boundary service 
NHS England | Microsoft Defender for Endpoint service

Overview

This outcome is about making sure useful alerts are generated, helping you prioritise, investigate and act on them quickly.

Detecting indicators of compromise

Your monitoring tools and procedures should allow you to identify indicators of compromise on your systems and networks.

The forms that indicators of compromise take are always changing, but will include known bad internet protocol (IP) addresses, domains, hashes and strings. 

Your approach to detecting them should be informed by threat intelligence acquired through NHS England’s CSOC, including via Microsoft Defender for Endpoint.

Updating for new signatures or indicators of compromise

The technologies you use to detect indicators of compromise on your networks should automatically be updated with the latest signatures or indicators of compromise. If you have a large IT estate, these updates can be initialised from a central management source.

Where updates are performed manually, you should have a robust process for ensuring they are applied promptly.

Prioritising alerts

Where multiple alerts are received, you should prioritise them according to the criticality of the systems they affect and the risk they pose, and follow up the most urgent ones first.

Enriching alerts at a later time

If alerts cannot be generated automatically containing all the additional context a person would need to be able to triage and address them effectively, a process should be in place to add necessary contextual information at a later time. 

Necessary context which may need to be understood in relation to the alert includes:

• which asset was affected
• whether it is a critical system
• where it is located on the network
• whether the activity matches known threat intelligence

Off the shelf tooling and user reports

Although not an optimal solution, your organisation can achieve a basic level of monitoring coverage through a combination of:

• off-the-shelf tooling using vendor default rules, signatures and alert settings
• users reporting events and potential incidents when they notice something unusual

Automated actions relating to detections and alerting

Where appropriate, your detections and alerting result in automated actions being taken. Examples of this include:

• malware detected on an endpoint being automatically quarantined by antivirus
• a compromised, non-compliant or suspiciously behaving device being automatically locked, wiped or isolated from the network
• known malicious IP addresses, domains and URLs being automatically blocked by firewalls and web filtering
• a host process, script, or session being automatically terminated if it matches malicious behaviour or indicators of compromise
• a file attachment or email being automatically blocked, quarantined or removed from inboxes where security tooling detects known malicious content or indicators of phishing

Monitoring user or system abnormalities

While you may only carry out the activity on an unscheduled basis, you should review user or system activity to identify unusual patterns that may indicate malicious activity.

Examples of activities that may indicate a security event are given in guidance for C1.a under the heading 'Monitoring user and system activity'. 

Regular interval monitoring

Your organisation should monitor your logs on a scheduled basis, with enough frequency to ensure that alerts are not left unnoticed or unresolved for an unacceptable length of time.

Supporting evidence

To support your response, you can upload (or link to) evidence which best demonstrates your achievement of the contributing outcome. Examples include:

• monitoring tool configuration information relating to detecting indicators of compromise
• processes for updating monitoring tools for new indicators of compromise
• procedures for prioritising alerts
• procedures for post-hoc enrichment of alerts
• evidence of off-the-shelf tooling and user reports being used to detect potential incidents
• evidence of automated processes in monitoring tools
• procedures for monitoring user or system abnormalities 
• evidence of regular interval monitoring
• monitoring tool configuration information relating to routine enrichment of alerts
• procedures for validating alerts
• evidence of alerts being specifically configured
• evidence of near real-time monitoring

This is not an exhaustive list. You can provide other types of evidence if you feel they are relevant to the contributing outcome.

Your supporting statement should cross-reference how each piece of evidence provides justification for your achievement of the contributing outcome, including relevant page numbers where appropriate.

National services

The following national services may help you meet the requirements of C1.c Generating alerts:

Security services | Secure Boundary
Security services | Vulnerability Monitoring Service (VMS)
Security services | Bitsight
Security services | Respond to a cyber alert
Security services | Microsoft Defender for Endpoint (MDE)
NCSC services | Early Warning
NCSC services | Check your cyber security

Additional guidance

For additional guidance, see:

National Cyber Security Centre CAF guidance | C1 Security monitoring

Overview

This outcome is about your ability to detect signatures, indicators of compromise and security incidents through your threat intelligence, monitoring and associated technologies.

Responding to alerts

You should ensure that you investigate, triage and take follow up actions in response to:

• any threats which you have been contacted about directly by the Department for Health and Social Care (DHSC)/NHS England
• threat intelligence and alerts received from NHS England’s CSOC, including via Microsoft Defender for Endpoint
• alerts you have configured locally that may monitor for examples such as known indicators of compromise, suspicious user behaviour or unusual events

For your locally configured alerts, you may rely on specific tools and focus only on high-priority alerts, rather than monitoring every alert source across your organisation.

Standard operating procedures (SOPs) for common alerts

You should identify the alert types your organisation is most likely to face, and create clear documented procedures for how responsible individuals should respond to them.

Examples of common use cases could include:

• alerts received from NHS England’s CSOC, including via Microsoft Defender for Endpoint
• alerts received from suppliers
• malware detection or suspected ransomware
• phishing or malicious email alerts
• suspicious login activity or compromised accounts
• network boundary alerts, such as suspicious inbound or outbound traffic

Triaging alerts and recording actions

You should perform some triage of your alerts and record actions taken by your monitoring and detection personnel.

Triaging could include:

• checking whether the alert is likely to be genuine or a false positive
• identifying the affected user, device, system or service
• checking whether the affected asset supports a critical system
• categorising the alert by type and priority/severity level

Examples of details which might be relevant to record in relation to actions taken by monitoring and detection personnel are given in 'Documenting and using triage activities to drive improvements' below.

Your triaging may be limited to certain tools or alert types.

Contextualising alerts against normal user or system behaviour

You should use your understanding of normal user or system behaviour to inform your decision making within triage.

This means that certain alerts which you might otherwise categorise as low priority, for example a failed login, might be escalated due to contextual factors such as an unusual location, device or time of day.

Supporting evidence

To support your response, you can upload (or link to) evidence which best demonstrates your achievement of the contributing outcome. Examples include:

• SOPs for alerts
• evidence of triage activities
• procedures for factoring normal user behaviour into alert response
• documentation showing all security tools being identified and used
• procedures for using triage activities to drive improvements
• procedures for factoring threat information into alert response 

This is not an exhaustive list. You can provide other types of evidence if you feel they are relevant to the contributing outcome.

Your supporting statement should cross-reference how each piece of evidence provides justification for your achievement of the contributing outcome, including relevant page numbers where appropriate. 

Additional guidance

For additional guidance, see:

National Cyber Security Centre CAF guidance | C1 Security monitoring
NHS England | Microsoft Defender for Endpoint service 
NHS England | Vulnerability monitoring service 
NHS England | Bitsight cyber security ratings service 
NHS England | Cyber incident response exercise service

Overview

To achieve this outcome, you need to have considered your monitoring team’s skills, tools and overall structure to ensure they can competently identify, analyse, investigate and report security threats.

Investigative skills and basic understanding

Monitoring and detection staff should have some investigative skills and a basic understanding of the data they need to work with.

Relevant skills and knowledge may include:

• understanding what common alert data means, such as timestamps, usernames, device names, IP addresses, domains, URLs, file hashes and event IDs
• using available tools to check the basic context of an alert
• identifying the affected user, device, system or service
• distinguishing obvious false positives from alerts that need further investigation
• knowing when to escalate to an incident response process

Your Training Needs Analysis (TNA) (see ‘B6.b Training’) should identify the competency requirements for staff members who are conducting your organisation’s security monitoring activities, and plan how training is to be delivered where it is needed.

Workflows

You should establish workflows for monitoring teams to adhere to when: 

• analysing logs and relevant data
• investigating sources
• reporting findings and suggested follow up actions to relevant decision makers

Your documentation should clearly define:

• lines of reporting
• communication channels
• processes for escalation and resolution

Your monitoring and detection staff should be able to follow the main or routine processes, but gaps may exist for some scenarios.

Understanding operational context

Your monitoring and detection personnel should have some understanding of the operational context they’re working in.

Practically this means that they should understand any findings from your essential functions scoping activity that would help them better understand which alerts are most likely to affect critical services, patients, sensitive data or operational continuity.

Dealing with cases effectively 

Your organisation’s monitoring teams should prioritise, assign, track, escalate and close alerts in a controlled way.

Supporting evidence

To support your response, you can upload (or link to) evidence which best demonstrates your achievement of the contributing outcome. Examples include:

• descriptions of roles and monitoring-related activities 
• evidence of monitoring skills and understanding 
• workflows for monitoring processes
• procedures for factoring essential functions knowledge into monitoring activities
• procedures for case management
• evidence of monitoring personnel looking beyond the fixed process
• evidence of monitoring activities shaping new log data collection
• procedures for identifying areas for improvement in monitoring activities

This is not an exhaustive list. You can provide other types of evidence if you feel they are relevant to the contributing outcome.

Your supporting statement should cross-reference how each piece of evidence provides justification for your achievement of the contributing outcome, including relevant page numbers where appropriate.

National services 

The following national services may help you meet the requirements of C1.e Personnel skills for monitoring and detection:

Training services | Cyber Incident Response Exercise (CIRE)
Security services | Vulnerability Monitoring Service (VMS)
Security services | Bitsight
NCSC services | Early Warning
NCSC services | Exercise in a box
NCSC services | Check your cyber security

Additional guidance

For additional guidance, see:

National Cyber Security Centre CAF guidance | C1 Security monitoring

For this contributing outcome, there is no minimum expected level of achievement for ‘Standards met’. You are still required to assess your achievement level and provide a response, showing you have considered the implications of the contributing outcome for your organisation’s cyber security and information governance (IG) activities. The DSPT ‘Standards met’ expectation should be regarded as a minimum compliance level, not the end goal of your organisation’s cyber security and IG activities.

Overview

This contributing outcome is about how your organisation uses threat intelligence and knowledge of system and user behaviour to detect cyber security incidents.

Threat intelligence effectiveness

Your organisation should be able to show that threat intelligence is not just received, but used and reviewed. 

For example, you might track whether intelligence has: 

• led to new detection rules
• supported investigations
• helped identify incidents
• revealed gaps in your monitoring coverage

Threat intelligence services

Your organisation should use a range of threat intelligence services to support monitoring and detection.

This could include receiving or using intelligence from:

• sector-based information sharing groups
• NHS England, NCSC or other public sector cyber alerts
• supplier feeds

Those sources do not need to have been selected through a detailed risk-based assessment of your specific business needs or health and care sector threats.

Using system abnormalities and threat intelligence to signify adverse activity

Your organisation should use learning from past incidents, near misses and the threat intelligence you receive to define the types of user and system behaviour that may indicate adverse activity.

You should review:

• previous incidents affecting your own organisation, similar organisations and your suppliers
• threat intelligence from sources mentioned in 'Threat intelligence services' above

You should then translate these into practical signs that can be monitored on your own systems. These could include:

• repeated failed logins followed by a successful login
• access from unusual locations, devices or times
• privileged account use outside expected patterns
• unexpected changes to permissions, configuration or security settings
• unusual communication between systems that do not normally interact
• large or unusual data transfers
• repeated access to sensitive records or datasets outside normal usage
• suspicious use of tools, scripts or processes commonly associated with attacks

Supporting evidence

To support your response, you can upload (or link to) evidence which best demonstrates your achievement of the contributing outcome. Examples include:

• procedures for validating threat intelligence effectiveness
• threat intelligence services and feeds
• procedures for turning incidents and threat intelligence into actionable monitoring activities
• procedures for sharing feedback on IoCs and other intelligence
• procedures for internal communications on threat intelligence
• baselines for understanding user and system abnormalities
• scheduled review processes for user and system abnormalities

This is not an exhaustive list. You can provide other types of evidence if you feel they are relevant to the contributing outcome.

Your supporting statement should cross-reference how each piece of evidence provides justification for your achievement of the contributing outcome, including relevant page numbers where appropriate. 

Additional guidance

For additional guidance, see:

National Cyber Security Centre CAF guidance | C1 Security monitoring
NHS England | Vulnerability monitoring service
NHS England | Bitsight cyber security ratings service
NHS England | Cyber incident response exercise service