Device security guidance
Guidance for organisations on how to choose, configure and use devices securely.
Pages
Page 25 of 37
Logging and protective monitoring
Using logging and monitoring to identify threats and protect smartphones, tablets, laptops and desktop PCs
Security monitoring is central to the identification and detection of threats to your IT systems. It acts as your eyes and ears when detecting and recovering from security incidents and it enables you to ensure that devices are used in accordance with your organisational policies.
Effective monitoring relies on proportionate, reliable logging and device management practices. This guidance is designed to give system and network admins advice on the logging and monitoring options available on modern platforms.
Why use logging and protective monitoring?
Many large-scale incidents have been shown to target individual hosts, from which attackers will attempt to further strengthen their access through lateral movement techniques such as credential theft, account impersonation, use of legitimate network tools or known exploits in outdated versions of network protocols to propagate and compromise additional devices to access additional data and services.
Some of these more traditional techniques may not apply in cloud-only or zero trust network architectures. However, monitoring device activity, health, and configuration arguably become more important when deciding whether to permit access to organisational services and data.
Logging and monitoring will help you to identify patterns of activity on your networks, which in turn provide indicators of compromise. In the event of incidents, logging data can help to more effectively identify the source and the extent of compromise.
Preparation for logging and monitoring
There are many types of events and signals that you may be able to collect from devices. Monitoring of devices should form part of your organisation's wider approach to logging and monitoring. Very often, successful intrusion detection requires multiple sources of information.
In general terms, monitoring data could come from event-driven logs, such as website connections, or device configurations details, such as the current operating system version running on a device.
As a first step, you should seek to understand the types and sources of data you need, and are able to collect. To help with this process, we have broadly classified data sources that may be available in the table below.
| Category | Description |
|---|---|
Host-based logs | Host-based logging can provide a rich source of data. Typically, this would include events relating to things like the file system, running processes, and program load events. Host based logging can also provide additional event sources such as website connections and device or service logons. Some device operating systems will support a rich set of built-in system logs that can be forwarded to a centralised store, while others will provide a very limited set of logs. Depending on the device platform, it may be possible to install additional host-based agents to collect log data, above and beyond built-in capabilities. However, this comes with the overhead of requiring additional software to be installed on the device. It also entails extra management requirements for the host-based agent. In some cases, installed agents may even introduce additional threat risks. |
| Service logs | Services such as identity, mail and document storage, as well as back-end services such as databases, will typically generate event or audit logs that can be collected and reviewed. These kinds of logs, including monitoring of authentication attempts and changes to configuration data, can provide additional log sources that may assist in detecting indicators of compromise for devices. |
| Infrastructure logs | Depending on your network architecture, devices such as firewalls, network proxies and intrusion protection or detection systems can all provide network-based monitoring of device events, such as website connections and DNS requests. This can assist in identifying devices that may have connected to malicious sites by, for example, clicking a phishing link or downloading a malicious file. More advanced features can also include signature or heuristic-based detection techniques. |
| Device compliance | An important feature of device management is the monitoring of device status and configuration. This data can be used to assess device compliance against organisational policies. For example, is the device operating system up to date? Because there are many devices and a range of Mobile Device Management systems, the level of support for this kind of compliance data vary widely, as do the actions you can take based on this data. You should consider this when choosing which devices to use in your organisation and when selecting a Mobile Device Management service. |
| Device attestation | Remote device attestation is designed to report a set of trusted signals and measurements for a device and the software running on it. These measurements should be protected and reported in such a way that, even if the device is compromised, the measurements can be relied upon. Stronger forms of attestation will typically combine hardware backed key stores and roots of trust with public key based cryptographic operations for storing and reporting trusted measurements of device state. Support for remote device attestation will vary significantly across different devices and Mobile Device Management services. You should consider this when choosing which devices to use, and when selecting a Mobile Device Management service. |
You should carefully consider your access to, and use of, these data sources. Along with the logging and remote management capabilities of the devices your organisation is using, they will determine your ability to detect and respond to security incidents, or policy breaches.
How to monitor and log

Establish a strategy
The NCSC's 10 steps to cyber security will help you implement a strategy for security monitoring. This should be first and foremost based on business need and the assessment of risk to business services and assets.
Implement a logging strategy
The Introduction to logging provides a four-step program to help you devise and implement a suitable logging capability.
What to watch
For devices, you should include monitoring of device state and compliance. You should also log device events, including user activity, network communications, authentication and access, to both devices and services.
Collect and analyse
You should collect and analyse your log data. This will give you the ability to detect and respond to security events. Where possible you should automate detection and remediation.
Evolve your plan
Your incident management plans and policies should include the ability to learn from security incidents. These lessons may suggest ways in which you can improve your monitoring set up. For example, a particular type of data may have been missing, or the duration of your log storage may be too short.
Prioritise
In practice, it may not be possible to achieve a perfect solution. This could be due to cost constraints, or the fact that your devices do not support perfect set of monitoring and management features. Whatever the source of these limitations, you should prioritise the questions you need to answer if you're going to spot potential compromise, or security risks.
The constraints of your Mobile Device Management system, and the devices themselves, will tell you which solutions are practically achievable.
Establish a SOC
If your organisation has the resources available, one solution is to establish a security operation centre (SOC). This will help you manage and monitor security risks to your organisation generally.
Logging made easy
For some organisations, particularly smaller ones, establishing a SOC or implementing full scale professional monitoring solution may not be feasible.
However, at the very least, you should have an effective logging system in place. Logging Made Easy (LME) is an NCSC open source project that provides a basic, end-to-end Windows logging capability, along with a set of tools for viewing and analysing the resulting data.
LME demonstrates that, with a modest investment of time and effort, it is possible to build a basic enterprise logging capability.
Technical notes
Data sources vary between platforms
An effective monitoring solution will need to take account of the variation in data available between platforms. To help with this, we've listed some of the most important differences below.
In general, on-device logging, device compliance reporting and attestation capabilities should be combined with monitoring data from network-layer devices such as internal firewalls, network proxies, and the VPN gateway and service logs. This multi-dimensional view is what will give you the most effective overall monitoring capability.
| Operating System | Data Sources |
|---|---|
| Android | For corporately owned devices, set up in device owner mode, with a single user or affiliated users, Android supports remote logging and bug report collection. Security-related events such as Android Debug Bridge (ADB) activity, unlock and lock attempts, and application launching are logged and can be remotely retrieved. Android bug reports can be remotely requested, though this requires interactive approval from the user before it is shared. The details available for remote viewing depend on the MDM provider. Dependent on the MDM provider, network activity logging is also available. Network activity logging captures DNS requests and TCP connections made by the device, and these logs can be forwarded to a remote server for processing and analysis. There are limitations, network activity logging can be bypassed, and if a device contains user profiles which have not been affiliated to your organisation, logs will not be collected. MDM solutions can be used to retrieve some information from the device, that can be used as part of device compliance policies. This data includes:
MDMs may be able to verify boot loader state via Key Attestation. MDMs can use the Android Safety Net API as part of device compliance policies, to verify the integrity of the device. If devices fail a compliance policy, this can be used as a signal to take appropriate action, e.g. block further access to corporate resources. |
| iOS | iOS does not support remote or local historic event collection. MDM solutions can be used to retrieve some information from the device, including device state information, which can be used to verify compliance to your organisational policies. This data allows you to detect such things as:
|
| macOS | macOS logs can be viewed by a local administrator on device, or from a distance using third-party remote administration tools (RATs). Third-party software can also be used to automate log collection. MDM solutions can be used to retrieve some information from the device, including device state information that can be used as part of device compliance policies. This data includes:
|
| Chrome OS | Limited information regarding user and device state can be remotely retrieved from the device using MDM. |
| Linux | Syslog can be used on Linux devices to generate and store system and application logs, which can then be forwarded to a remote log server store. Rsyslog is also available on many Linux distributions and can provider a richer and more flexible set of logging features. Additional auditing can also be performed with auditd for specific events of interest to an administrator. |
| Windows | System event collection can be carried out using Windows Event Collection and Forwarding. These events can be forwarded to a central store. Forwarding can be configured using group policy. Once installed, Sysmon can be used to monitor system activity, and send data to the Windows Event log. Windows event collection can be used to forward logs to a centralised store. The NCSC's Logging Made Easy (LME) is an open source project which provides an end-to-end logging solution for organisations that use Sysmon to collect host based logs. Windows log analytics is a feature of Azure Monitor. This allows logs of events captured on device to be forwarded to your organisation’s Azure log analytics workspace. This includes Windows event logs. This feature requires an additional log analytics agent to be installed on the device, also known as the Microsoft Management Agent. MDM solutions can be used to retrieve some information from the device, including device state information that can be used as part of device compliance policies. This data includes:
Windows Defender ATP is a fully featured threat protection and security monitoring platform that can be used to prevent, detect, investigate and respond to threats. It works in combination with the built-in platform security features of Windows 10, such as Exploit Protection, Attack Surface Reduction Rules, and System Guard, to reduce the attack surface of Windows 10 devices. It includes capabilities such as threat and vulnerability management, end point detection and response, and automated investigation and remediation. It also includes the Microsoft secure score that organisations can use to analyse and improve the security posture of device security. Windows Defender ATP also integrates with Microsoft Intune to manage threats to devices, including device compliance policies and conditional access, e.g. to be able to restrict access to organisation services and data if a high risk threat is seen on a device. Windows Device Health Attestation can collect and report measured boot data, protected by a Trusted Platform Module (TPM). This data is transmitted to the Microsoft health attestation service to validate system boot integrity, including hardware and operating system boot components, kernel integrity, antivirus, and early boot drivers. It returns an encrypted health certificate that is stored on the device. This integrates with Microsoft Intune, so that the health certificate can be requested and used to validate specific device health data points as part of device compliance policies. It can, therefore, also be applied to conditional access policies. |


