Best practices for event logging and threat detection
Intro
Event logging, in conjunction with event log analysis, supports the secure operation of critical systems and services by enabling network visibility and cyber threat identification.
The Australian Signals Directorate’s Australian Cyber Security Centre (ASD’s ACSC) in cooperation with:
- United States (US) Cybersecurity and Infrastructure Security Agency (CISA), the Federal Bureau of Investigation (FBI) and the National Security Agency (NSA)
- United Kingdom (UK) National Cyber Security Centre (NCSC-UK)
- Canadian Centre for Cyber Security (CCCS)
- New Zealand National Cyber Security Centre (NCSC-NZ) and Computer Emergency Response Team (CERT NZ)
- Japan National Center of Incident Readiness and Strategy for Cybersecurity (NISC) and Computer Emergency Response Team Coordination Center (JPCERT/CC)
- The Republic of Korea National Intelligence Services (NIS) and NIS’s National Cyber Security Center (NCSC-Korea)
- Singapore Cyber Security Agency (CSA)
- The Netherlands General Intelligence and Security Service (AIVD) and Military Intelligence and Security Service (MIVD).
have recently developed the ‘Best practices for event logging and threat detection’ publication, detailing best practice guidance for event logging and threat detection for cloud services, enterprise information technology (IT) networks, enterprise mobility and operational technology (OT) networks.
This guidance is intended primarily for cyber security practitioners, IT managers, OT operators, network administrators and network operators within medium to large organisations.
There are four key factors to consider when pursuing event logging and threat detection best practices:
1. Develop an enterprise-approved logging policy.
2. Centralise log collection and correlation.
3. Maintain log integrity, including through secure log storage.
4. Develop a detection strategy for relevant threats.
Enterprise-approved event logging policy
Developing and implementing an enterprise approved logging policy improves an organisation’s chances of detecting malicious behaviour on their systems and enforces a consistent method of logging across an organisation’s environments.
The logging policy should take into consideration any shared responsibilities between service providers and the organisation.
The policy should also include details of the events to be logged, event logging facilities to be used, how event logs will be monitored, event log retention duration, and when to reassess which logs are worthy of collection.
The table below summarises logs by category and event types to be captured for analysis, as recommended by SOCFortress:
To strengthen detection of malicious actors employing LOTL techniques, some relevant considerations for event logging include:
- On Linux-based systems, logs capturing the use of curl, systemctl, systemd, python and other common LOLBins leveraged by malicious actors.
(SOCFortress)Recommended implementation: Enable additional telemetry in Linux systems using tolls like OSQUERY:
- On Microsoft Windows-based systems, logs capturing the use of wmic.exe, ntdsutil.exe, Netsh, cmd.exe, PowerShell, mshta.exe, rundll32.exe, resvr32.exe and other common LOLBins leveraged by malicious actors. Ensure that logging captures command execution, script block logging and module logging for PowerShell, and detailed tracking of administrative tasks.
(SOCFortress)Recommended implementation: Enable the collection of Powershell logs and events:
Install Sysmon (Sysinternals) and collect all related events.
- For cloud environments, logging all control plane operations, including API calls and end user logins. The control plane logs should be configured to capture read and write activities, administrative changes, and authentication events.
(SOCFortress)Recommended implementation: Monitor auth activity in Azure AD:
Organisations are encouraged to properly organise logged data into ‘hot’ data storage that is readily available and searchable, or ‘cold’ data storage that has deprioritised availability and is stored through more economical solutions — an important consideration when evaluating an organisation’s log storage capacity.
Centralised log collection and correlation
Enterprise Networks
It’s recommend that organisations prioritise the following log sources within their enterprise network:
- Critical systems and data holdings likely to be targeted
(SOCFortress)Recommended implementation: Collect inventory and organise assets by type and criticality:
The inventory should include installed software and system services enabled:
- Internet-facing services, including remote access, network metadata, and their underlying server operating system.
(SOCFortress)Recommended implementation: Ensure that logs from public-facing applications, like MS-IIS web apps, are collected and analysed:
- Identity and domain management servers.
(SOCFortress)Recommended implementation: Ensure that activity logs for users and groups are collected:
- Any other critical servers.
(SOCFortress)Recommended implementation: Ensure that logs from databases, ERP systems, CRM solutions, etc., are collected and analysed
- Edge devices, such as boundary routers and firewalls
(SOCFortress)Recommended implementation: Collect and analyse events from your NextGenFW/UTM appliances:
Integhrations available:
- Administrative workstations.
- Highly privileged systems such as configuration management, performance and availability monitoring (in cases where privileged access is used), Continuous Integration/Continuous Delivery (CI/CD), vulnerability scanning services, secret and privilege management.
- Data repositories.
(SOCFortress)Recommended implementation: Collect and analyse events from your NAS/SAN appliances:
File Integrity monitoring on storage units:
- Security-related and critical software.
(SOCFortress)Recommended implementation: Ingest, parse and classify alerts and events from your advanced endpoint protection solution in your SIEM:
- User computers.
(SOCFortress)Recommended implementation: Install EDR in all workstations/laptops in your organisation:
- User application logs.
(SOCFortress)Recommended implementation: Organise apps and processes by vendor, product and version:
- Web proxies used by organisational users and service accounts.
(SOCFortress)Recommended implementation: Ensure that logs from web proxies and reverse proxies are collected (NGINX logs below):
- DNS services used by organisational users.
(SOCFortress)Recommended implementation: Ensure that logs from endpoints related to DNS resolution requests are collected and analysed (sysmon)
Integrate external DNS protection solutions like Cisco Umbrella or CloudFlare:
- Email servers.
(SOCFortress)Recommended implementation: Collect and analyse events from Exchange online and MS Threat Intel (defender for O365):
- DHCP servers.
- Legacy IT assets (that are not previously captured in critical or internet-facing services).
Operational Technology (OT)
It’s recommend that organisations prioritise the following log sources in their OT environment (note that in cases where OT devices do not support logging, device logs are not available, or are available in a non-standard format, it is good practice to ensure network traffic and communications to and from the OT devices are logged):
- OT devices critical to safety and service delivery, except for air-gapped systems
- Internet-facing OT devices
- OT devices accessible via network boundaries.
Reference: Advanced network traffic analysis uing Zeek
Enterprise mobility using mobile computing devices
In the context of enterprise mobility, the aim of effective event logging is to detect compromised accounts or devices; for example, due to phishing or interactions with malicious applications and websites.
Log sources to keep in mind:
- web proxies used by organisational users
- organisation operated DNS services
- device security posture of organisationally managed devices
- device behaviour of organisationally managed devices
- user account behaviour such as sign-ins
- VPN solutions
- MDM and Mobile Application Management (MAM) events5.
Cloud computing
Adjust event logging practices in accordance with the cloud service that is administered, whether Infrastructure-as-a-Service (IaaS), Platform-as-
a-Service (PaaS), or SaaS are implemented.
Log sources related to cloud computing:
- critical systems and data holdings likely to be targeted
- internet-facing services (including remote access) and, where applicable, their underlying server operating systems
- use of the tenant’s user accounts that access and administer cloud services
- logs for administrative configuration changes
- logs for the creation, deletion and modification of all security principals, including setting and changing permissions
- authentication success and/or failures to third party services (e.g. SAML/OAuth)
- logs generated by the cloud services, including logs for cloud APIs, all network-related events, compliance events and billing events.
(SOCFortress)Recommended implementation: Collect and analyse events from your cloud deployment and services
Azure (IaaS/PaaS/SaaS):
Office 365:
Integrations available:
Secure storage and event log integrity
Implement a centralised event logging facility. Enable log aggregation and then forward select, processed logs to analytic tools, such as security information and event management (SIEM) solution and extended detection and response (XDR) solutions.
Forwarding event logs to a centralised and secure storage capability prevents the loss of logs once the local device’s storage is exhausted. In the event of a cyber security incident, an absence of historical event logs will frequently have a negative impact on cyber security incident response activities.
Secure transport and storage of event logs
Implement secure mechanisms such as Transport Layer Security (TLS) 1.3 and methods of cryptographic verification to ensure the integrity of event logs in-transit and at rest.
Protecting event logs from unauthorised access, modification and deletion
Logs may contain sensitive data that is useful to a malicious actor. As a result, users should only have access to the event logs they need to do their job. An event logging facility should enable the protection of logs from unauthorised modification and deletion.
The storage of logs should be in a separate or segmented network with additional security controls to reduce the risk of logs being tampered with in the event of network or system compromise.
Events logs should also be backed up and data redundancy practices should be implemented.
Centralised event logging enables threat detection
The aggregation of event logs to a central logging facility that a SIEM can draw from enables the identification of:
- deviations from a baseline: A baseline should include installed tools and software, user account behaviour, network traffic, system intercommunications and other items, as applicable. Particular attention should be paid to privileged user accounts and critical assets such as domain controllers. A baseline is derived by performing an analysis of normal behaviour of some user accounts and establishing ‘always abnormal’ conditions for those same accounts.
- cyber security events: Occurrence of a system, service or network state indicating a possible breach of security policy, failure of safeguards or a previously unknown situation that may be relevant to security.
- cyber security incidents: Unwanted or unexpected cyber security event, or a series of such events, that either has compromised business operations or has a significant probability of compromising business operations.
Timely ingestion
Timely ingestion of event logs is important in the early detection of a cyber security events and cyber security incidents. If the generation, collection and ingestion of event logs is delayed, the organisation’s ability to identify cyber security incidents is also delayed.
Need Help?
The functionality discussed in this post, and so much more, are available via the SOCFortress platform. Let SOCFortress help you and your team keep your infrastructure secure.
Website: https://www.socfortress.co/
Contact Us: https://www.socfortress.co/contact_form.html