This document and associated checklist is intended to be used as a high-level self assessment to determine coverage quality of an operational SIEM environment for a typical organisation.
Most organisations are strategically migrating services not unique to their specific business to shared common service models as below (diagram from CISA Cloud Security Technical Reference Architecture). This typically results in the Identity, Credential and Access Management and Data relevant observables having the greatest value.
The above diagram should be used as a reference to determine which systems/services are relevant for capturing security logs (i.e. if utilising IaaS, the service provider should facilitate the collection of security logs in bulk, while On-Premise infrastructure would require additional resources to capture security logs from hypervisors, physical servers, storage and physical security).
Referencing the STIX 2.1 Cyber Observable Objects library, the below observables are intended to represent an organisation detection scope of potential threat indicators. The observables objects are ordered based on feasibility of ingestion of all relevant activities external to an organisation.
- IPv4Address, IPv6Address
- UserAccount, EmailAddress
- DomainName, URL
- EmailMessage (date, subject, from, to most relevant)
- File (SHA256 hash most relevant)
- HTTPRequestExt (Inbound HTTP requests through e.g. Web Application Firewalls)
Further information of the purpose of STIX 2.1 and the observable objects can be found here.
The below is a high level summary of assets and services from where security logs should typically be collected. Subsequent detection queries will refer to these assets.
- Users - Identity Services (On Premise and SaaS), Application access
- Mailboxes - Email mailboxes and associated inbound/outbound flows
- Endpoints - Devices that users access organisational resources from
- Servers - Hypervisors, Servers, Container Platforms
- Network Firewalls (Firewalls) - Network egress and internal network control points
- Web Application Firewalls (WAFs) - Network ingress control points
The below checklist should be undertaken by the organisations security team to calculate the percentage coverage of assets (e.g. 8 / 10 Endpoints == 80% coverage) for a given log retention window (normally 12 months). This data is heavily used for threat hunting activities.
These are available as out of the box integrations on fully SaaS platforms such as Microsoft Sentinel connected to Microsoft 365 Defender. On-Prem sign-ins depending on the Defender for Identity require sensor deployment on all Domain Controllers (minimum version Windows Server 2012).
- Users - Query a
IPv4Address,IPv6Address,ProtocolorUser-Agent (HTTPRequestExt)across all Network Traffic for HTTPS sign ins. - Users - Query a
IPv4Address,IPv6AddressorProtocolacross all Network Traffic for On-Prem sign ins.- E.g. Defender for Identity.
- Mailboxes - Email events and URL / attachment analysis using mail server Application Logs.
- E.g. Defender for Office 365
- Query a
DomainNameorEmailAddressacross all emails. - Query a
Subject (EmailMessage)across all emails. - Query a
DomainNameorURLacross all links inside emails. - Query a
SHA256 Hash (File)across all attachments inside emails.
These are available as integrations with some deployment requirements on Windows, macOs and Linux endpoints using Microsoft Defender for Endpoint.
- Endpoints - Query a
IPv4Address,IPv6Address,DomainNameorURLacross all outbound Network Traffic. - Endpoints - Query a
SHA256 Hash (File),Name (File)orFileOriginUrl (File)across all Files and Processes.
Agent based network protection is relatively straightforward to ingest from application servers. High volume network traffic should be reviewed prior to ingestion to understand the volume of events and to avoid loading large quantities of low value events (such as Content Delivery Networks / File Sharing / Media Streaming logs).
- Query an
IPv4Address,IPv6AddressorDomainNameacross all inbound/outbound Network Traffic.- Servers - e.g. Defender Network Protection
- Firewalls - e.g. Sentinel 3rd party connectors
- WAFs - Query a
IPv4Address,IPv6Address,URLorUser-Agent (HTTPRequestExt)across all inbound Network Traffic.
Once the above checklist is validated, an organisation should schedule regular security exercises to detect for suspicious behaviour based on indicators collected from threat intelligence sources and to detect for deviations against known behaviour baselines. A simple example would be to determine a subset of users that are allowed to use legacy authentication protocols (NTLM, LDAP, HTTP Basic Auth), and alerting security analysts whenever a user outside of that list attempts to sign in with a legacy authentication protocol.
Sigma is a flexible rule format that is easy to write and applicable to any type of log file. The project provides a structured library and an open specification in which researchers or analysts can describe and share their detection methods. The WA SOC is actively investing into sigma rule development and a pySigma backend/pipeline for Sentinel, and can provide assistance in converting rules to/from sigma formats.
The WA SOC has curated a pack of over 100 analytics rules from the unified Microsoft Sentinel and Microsoft 365 Defender repository for rapid deployment (last updated Feb 2023):
The ARM template can be deployed multiple times to install new and update existing rules. Rules deployed from this template will be updated in place, however there may be duplicate rules over time (it's worth scanning the names of analytics rules within a workspace, and removing the least recently modified ones after a deployment with the same name). Best practice is also to ensure any locally customised rules within your workspace have a prefix (to simplify distinguishing from externally sourced content).
Deploying the above resources doesn't require any connectors or incur any additional charges. Detections will be dependent on appropriate ingestion having been configured. This deployment also configures and makes use of the Advanced Security Information Model (ASIM) parsers for some analytics rules to enhance coverage across third party ingestion sources.
Example code is available to export your own rules as a backup or to simplify sharing, the script by default packages ASIM rules as well into the ARM template to avoid validation issues.
!!! info "Deployment Walkthrough Video"
<video src='https://github.com/wagov/wasocshared/releases/download/2023-June/Detection.and.Automation.Pack.Deployment.Demonstration.mp4' width=1080 controls/>
??? info "Deployment FAQ"
- **What is the least privilege access role required to deploy a template?**
- [Template Spec Contributor](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#template-spec-contributor) (otherwise Contributor for the overall resource group, or higher will work, too).
- **Can the Analytics Rules/Automation Rules be edited?**
- Yes, in fact some of the Analytics Rules have comments specifically noting that they should be edited, their thresholds should be adjusted as required, or exclusions should be added.
- **How do I update these rules later?**
- We may note that there have been updates and the pack require updating. In this situation it would be a matter of re-deploying the packs over the top of the already deployed rules. Note: This will squash any changed made to the existing rules. We suggest copying and giving a different prefix name to any rules you want to edit so this doesn't occur.
- **How can I give feedback about either of the packs?**
- A Microsoft Form has been created for this purpose and is available: <https://forms.office.com/r/h9ryz8X7aY>
- **How can I contact DGov if I have questions about this?**
- We're always contactable via our monitored mailbox: <cybersecurity@dpc.wa.gov.au>
!!! note "WASOC Automation Rules"
The following package is designed to automatically add task lists to the incidents generated by their paired WASOC Sentinel analytic rules in the Detection Pack. These task lists are intended as a baseline for generalised investigation and remediation steps commonly undertaken for each kind of associated incident:
[](https://portal.azure.com/#create/Microsoft.Template/uri/https%3A%2F%2Fraw.githubusercontent.com%2Fwagov%2FWASOCAutomationPlaybook%2Fmain%2FCollatedDeployment.json)
[](http://armviz.io/#/?load=https%3A%2F%2Fraw.githubusercontent.com%2Fwagov%2FWASOCAutomationPlaybook%2Fmain%2FCollatedDeployment.json)
*Note: This package does not yet cover the Microsoft Defender for IoT Analytic Rules and is under development. Feedback is appreciated.*