Implementing SIEM and SOAR platforms — Australian Signals Directorate

5 min readJun 2, 2025

Intro

The Australian Signals Directorate (ASD) has released a series of publications about SIEM and SOAR platforms. These allow organisations to detect and respond to cyber security threats.

In this article we’ll review the main topics covered in these publications and how SOCFortress can help organisations to achieve the goals described ASD’s guidelines and recommendations.

Reference: https://www.cyber.gov.au/resources-business-and-government/maintaining-devices-and-systems/system-hardening-and-administration/system-monitoring/implementing-siem-and-soar-platforms

Implementing SIEM and SOAR platforms: Executive guidance

SIEM and SOAR platforms are foundational components of a robust cybersecurity posture. SIEMs collect, centralise, and analyse log data across diverse IT environments to detect anomalies and raise alerts. SOAR platforms extend this functionality by automating incident response actions through predefined playbooks, significantly reducing response times and enabling security teams to focus on high-priority threats.

Benefits of leveraging SIEM and SOAR platforms include:

Enhanced visibility and threat detection.
Improved response efficiency.
Resilience against stealthy or destructive attacks (e.g., Volt Typhoon).
Alignment with compliance frameworks like the Essential Eight and CISA CPGs

SIEM tools ingest logs from across the organisation, applying rules and threat intelligence to detect suspicious activities and generate alerts.
SOAR systems either work alongside SIEMs or integrate with them, automating specific incident responses (e.g., isolating a compromised device).

Implementing these platforms is neither simple nor static. Challenges include:

Correctly tuning alerts to avoid both false positives and missed detections.
Ensuring SOAR actions only trigger in legitimate incidents.
High costs in licensing, staffing, training, and ongoing tuning
Necessity of expert staff or reliable external service providers.

Strategic Recommendations

Evaluate Internal vs. Outsourced Implementation: In-house teams offer better contextual awareness, but require significant investment in skills and resources. Outsourcing introduces concerns about visibility, data sovereignty, and responsiveness.
Identify Hidden Costs: Many SIEM products are priced by data volume ingested, potentially escalating costs without proper data governance.
Plan for Ongoing Training: The evolving threat landscape demands continuous staff education and skill development.
Implement SIEM First: Ensure the SIEM is mature and accurately detecting incidents before layering in SOAR automation.
Test and Validate Performance: Regular internal testing and third-party assessments (e.g., penetration testing) are critical to ensure effectiveness.

Implementing SIEM and SOAR platforms: Practitioner guidance

SIEM platforms aggregate, centralise, and analyse logs from diverse systems and support detection, investigation, and alerting workflows.
Centralised logging simplifies investigations and supports compliance (e.g., Essential Eight, CISA CPGs).

SIEMs make security data accessible and actionable. SIEMs detect suspicious activity and support anomaly detection through baselines and integrated threat intel. Standardised event data improves detection accuracy. Timely alerts and historical context improve incident handling.

SOARs, on the other hand, automate actions like isolation, credential revocation, or blocking IPs, which can mirror adversary automation.

Best Practice Principles for Implementation

The ASD publication breaks implementation into three phases: Procurement, Establishment, and Maintenance.

Procurement Phase

Define Scope with a Proof of Concept (POC): Focus on specific business risks, use cases, and risk models. Account for hybrid/multi-cloud integration and stakeholder roles.
Favour Data Lake Architecture: Improves log accessibility and integrity while enabling flexible analysis. Consider isolating logs in monitoring enclaves.
Multi-Source Correlation: Select SIEMs capable of ingesting and correlating logs across legacy, cloud, and third-party systems.
Plan for Hidden Costs: Log ingestion models often inflate costs. Integration, switching vendors, or reliance on single-vendor ecosystems can increase TCO.
Invest in People: Upskilling is vital. Train teams on SIEM/SOAR fundamentals, threat detection, log parsing, and alert tuning.

Establishment Phase

Baseline “Normal” Network Behavior: Critical for detecting deviations. Build baseline over time and validate with threat hunting and real-world scenarios.
Standardise Logging Practices: Use consistent log schemas, define retention periods, and monitor for gaps in log generation.
Align with Enterprise Architecture: Embed the SIEM into infrastructure planning. Keep the System Owner informed of new data sources and architecture changes.

Maintenance Phase

Evaluate Threat Detection Continuously: Regularly test alerts and update rules to align with evolving threat models. Use MITRE ATT\&CK and tools like MaGMa for structured evaluation.
Pre-process Logs Before Ingestion: Minimize cost and optimize detection by filtering at the host, forwarder, or SIEM layer. Prioritize logs relevant to security.
Test and Validate Performance: Conduct tabletop exercises, penetration tests, and simulate attack scenarios (e.g., LSASS dump, Golden Ticket, DCSync, C2 detection).

Priority logs for SIEM ingestion: Practitioner guidance

This document is intended for cyber security practitioners and provides detailed, technical guidance on the logs that should be prioritised for SIEM ingestion.
It covers log sources including Endpoint Detection and Response tools, Windows/Linux operating systems, and Cloud and Network Devices.

The guidance focuses on helping practitioners:

Select high-value logs that contribute most to threat detection and response.
Establish efficient log ingestion pipelines.
Ensure log collection aligns with the Essential Eight Maturity Model and CISA’s Cybersecurity Performance Goals (CPGs).

Logs should be prioritised based on:

Relevance to security operations.
Value in detecting threats.
Forensic utility during incident response
Support for compliance and assurance activities

Priority definition:

High-priority (ingest and actively alert).
Medium-priority (store for later investigation).
Low-priority (avoid or selectively ingest).

Priority Log Categories and Recommendations

A. Endpoint Detection & Response (EDR)

Alerts (e.g., detections, quarantines).
Host activity logs (process creation, execution flow).
Enrichment telemetry (may include large data volumes)

B. Windows OS Logs

Security logs (Event ID 4688 — process creation, 4624 — logon).
Sysmon logs (detailed process, file, registry, and network telemetry).
Application logs (useful for specific context).
Print, clipboard, or generic UI logs

C. Linux OS Logs

Syslog (auth.log, secure, sudo logs).
Auditd logs (kernel-level event tracking).
Debug-level daemon logs unless investigating specific issues

D. Cloud Service Logs (Azure, AWS, GCP)

Authentication logs (e.g., Azure AD sign-in, AWS CloudTrail).
Administrative activity (IAM changes, resource provisioning).
Storage access logs (e.g., S3 access logs).
Generic service health logs unless correlated to incidents

E. Network Devices & Firewalls

Firewall logs (allowed/blocked connections, config changes).
VPN logs (auth success/failures, session details).
Switch/router logs (interface changes, routing anomalies)

F. Security Appliances

IDS/IPS logs (e.g., Suricata, Snort alerts).
Email security gateway logs.
DLP system logs (data transfer violations)

G. Identity & Access Management Systems

Authentication/authorization events.
Privileged access management (PAM) actions.
Audit trails from identity providers

H. Application and Database Logs

Access logs for sensitive systems.
DB query logs (privileged accounts, admin functions).
General transaction logs unless tagged for relevance

Deployment Considerations

Log Source Coverage: Focus on systems critical to business or exposed to internet threats.
Log Collection Pipeline: Use endpoint agents, centralised forwarders, or cloud-native integrations.
Retention Policies: Define retention based on incident response, compliance, and cost constraints.
Filtering and Preprocessing: Use host-level or collector-level filtering to reduce ingestion volume.

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/