The below guide has been constructed to prioritise connectors and configuration based on cost and complexity. There are several free data sources for Microsoft Sentinel, however the best approach is to connect as much as you can, then monitor costs and run queries to understand your data ingestion to reduce your costs where possible.
It is recommended to deploy Microsoft Sentinel in the Australia East region. If you have not already done so, you can follow the steps below:
If you have Log Analytics setup in another region, it is recommended to move it to Australia East where possible, as query performance is reduced when spanning multiple regions, and the majority of existing deployments are in Australia East.
These connectors are largely built into the cost of the services they protect, and provide a high value in terms of assets protected. Some additional context is provided on how to best configure and onboard devices and services, however only the emphasised steps need to be completed to establish a baseline SIEM environment.
- Connect Azure Active Directory (Azure AD) - Identity management logs
- Turn on Microsoft 365 Defender - this includes Office 365, Endpoint, Identity and Cloud Apps
-
Protect against Threats using Defender for Office 365 to align with the ACSC Essential Eight Maturity Model
- Use Exchange Online and SharePoint Online for all staff email & file services
- Integrate with Defender for Endpoint
-
Configure Microsoft Defender for Endpoint in Intune
- Use Intune for endpoint management and mobile device management
- Windows, macOS and Linux servers should also be onboarded into Microsoft 365 Defender for Endpoint unless they are separately sending the above data to Sentinel via another connector (e.g. Microsoft Defender for Cloud or Container Insights)
- Windows devices in Defender for Endpoint - Windows 7+, Windows Server 2008 R2+
- Defender for Endpoint on Mac - macOS 10.15+ (Catalina)
- Defender for Endpoint on Linux - Debian 9+, Ubuntu 16.04+, RHEL6+, SLES12+, CentOS6+, OEL7+, Fedora33+
- Align with the ACSC Strategies to Mitigate Cyber Security Incidents by moving endpoints to Windows cloud configuration which includes Security Baseline for Windows, then configure WDAC policy for Application Control, Defender for Endpoint Baseline and Edge Baseline.
This is the lowest cost way per device to get baseline monitoring in place.
-
Install Identity Sensors - Install on all domain controllers and ADFS servers
- This is only relevant where on-premise Active Directory syncs to Azure AD, if entirely using Azure AD this is not required
- Configure RADIUS Accounting on 802.1X networks & VPNs - Capture 802.1X events via RADIUS accounting traffic forwarded to Identity Sensors (VPNs, wireless, 802.1X ports)
-
Connect Microsoft 365 Defender to collect events from Defender for Office 365 and Defender for Endpoint
- Enable collection of events from all Advanced Hunting tables (Defender, Office 365, Identity, Cloud Apps & Alerts)
-
- Connect Azure Activity log - Comprehensive Azure service monitoring.
These are good for querying manually, however most require some work to Normalise using the Advanced Security Information Model (ASIM) to be incorporated into automatic incident generation using standard Sentinel rules.
- AWS S3 Connector - This collects data via S3 buckets so has some delays compared to higher level integrations like Microsoft 365 Defender or Container Insights
- Logstash to connect data sources to Microsoft Sentinel - For third party platforms without microsoft documented connection guidance, this is the best integration option.
- CEF-formatted logs from your device or appliance
- Linux-based sources using Syslog
- Ingest Azure Frontdoor / Application Gateway WAF events into Sentinel - WAF events are a high quality security event source for monitoring ingress to applications
- For third party WAF's, they typically have an API to log events or retreive incidents which can be integrated using the Logstash connector above and the HTTP Poller input plugin or the Cloudwatch input plugin for any AWS service outputs (including WAF)
- Container Insights - Centrally monitor Kubernetes cluster performance and query logs
- Microsoft Defender for Cloud - If possible Enable all Microsoft Defender plans
Use Microsoft Defender for IoT/OT for passive network monitoring for devices not supported by Defender for Endpoint/Cloud via TAP/packet broker (previously CyberX), this is a very high quality egress monitoring event source. Microsoft makes significant volume discounts available.
- To manage costs it is recommended to use policy based routing or L3 segmentation to separate your endpoint traffic from OT devices, and utilise a packet broker to push OT traffic into the OT sensor, enterprise firewall packet broker config guides are listed below:
- Firewalls (best option): Palo Alto Packet Broker, Checkpoint Mirror and Decrypt
- Switches: Cisco SPAN, Cisco Meraki Port Mirror, Fortinet SPAN
- A scalable architecture supporting SD-WAN's would be using IPSEC to route OT egress traffic via a public cloud provider (Azure Site to Site, AWS Site to Site) and then monitor the egress using a cloud firewall supporting packet brokering (e.g. Palo Alto VM Series) to a sensor hosted on the public cloud environment itself.
Microsoft Sentinel has builtin queries to understand your data ingestion at a per table level. To get further granularity you can look at specific devices sending a lot of data using additional usage queries or directly run manual queries from Investigate your Log Analytics usage.
Once you have identified the high cost items, you can reduce the events generated at the source, using a Logstash filter for a custom source or with configuration in Sentinel itself:
- Ingestion time transformations - should be used to eliminate low value logs before they are persisted within Log Analytics & Sentinel
- Basic Logs - should be used for high volume tables that aren't queried regularly (approx 1/4 cost per GB ingested)