Last Updated: 11/08/2025
This article looks at providing a checklist for Microsoft Sentinel data source onboarding considerations. Whilst getting data into Microsoft Sentinel is easy, ensuring your data has value (for either detections or investigating) is crucial for keeping your Microsoft Sentinel instance optimised and costs are kept in control.
Key Information Checklist
Define the Need
- Why: Understand the reason and expected result for onboarding this data source.
- Value: Aligns security monitoring with business objectives. Allows for planning of Analytical Rules based on the detection & investigation need.
- Examples: Compliance requirement, monitoring of critical assets, detections of a particular attack/vector.
Identify the Data Source(s)
- Why: Identify what system or application is generating the logs, and how they are exported/streamed.
- Value: Helps determine log format, volume, and relevance.
- Examples: Firewall logs for perimeter defense, endpoint logs for lateral movement detection, identity logs for user accounts & cloud services.
Determine the Use Cases
- Why: Clarify what security scenarios the data will support and what activities we are trying to detect.
- Value: Ensures the data source contributes to actionable insights. Allows for planning and alignment to Analytical Rules.
- Examples: Detect brute-force attacks, monitor privileged accounts, identify data exfiltration, detect ransomware.
Data Assessment Checklist
Assess Data Quality and Format
- Why: Ensure logs are structured, complete, and timestamped.
- Value: High-quality data improves correlation, alert accuracy and improves investigation.
- How: Export example logs from desired platform and conduct an analysis and ensure the logs are timestamped and in a supported format.
Evaluate Integration/Ingestion Method
- Why: Choose between agent-based, API, syslog, or native connector based on the data source and supportability of streaming logs into Microsoft Sentinel.
- Value: Impacts performance, scalability, and maintenance. Ensure the method used is supported by Microsoft.
- How: Microsoft Sentinel has a library of data connectors that can be used and should be explored first. For a full list of data connectors please visit this article.
Define Log Retention and Storage Requirements
- Why: Meet compliance, operational, detection & investigation requirements.
- Value: Longer retention can extend threat detection, hunting and investigations as many APTs operate over a longer dwell time. Longer retention does come with additional costs.
- Note: With Microsoft Sentinel you can define separate retention periods for individual tables. My previous blog on Archiving outlines how you can bulk update tables for retention and archiving.
Configuration Checklist
Configure Parsing and Normalisation
- Why: Standardise log formats for correlation. e.g. Normalise usernames and IPs for cross-source correlation.
- Value: Enables consistent rule application across sources. This is especially relevant for custom data sources.
- Notes: Preconfigured data connectors in Microsoft Sentinel might not require parsing or normalisation. For a full list of data connectors please visit this article.
Map to MITRE ATT&CK or Other Frameworks
- Why: Align detection logic/analytical rules with known adversary behaviors.
- Value: Enhances threat detection coverage and allows for easier heat mapping/gap analysis of threat coverage.
- Notes: Microsoft Sentinel analytical rules can be aligned to MITRE ATT&CK and workbooks can be used for heatmap based reporting. Additionally, when creating Standard Operating Procedures (SOPs) alignment to a known framework can help tag and organise documentation and knowledge bases.
Post Configuration Checklist
Test and Validate Ingestion
- Why: Confirm logs are flowing and parsed correctly.
- Value: Prevents blind spots in monitoring and ensures required data is flowing into Microsoft Sentinel.
- Notes: It is recommended to periodically test ingestion and log integrity.
Document the Onboarding
- Why: Maintain knowledge/documentation to support future audits & troubleshooting.
- Value: Aids troubleshooting and onboarding consistency.
- Notes: Data Connectors & Data Sources can change over time, potentially affecting the logs ingested. Keeping a record of configuration and checking/implementing updates is recommended to ensure accuracy/integrity of Microsoft Sentinel.
Review and Tune Detection Rules
- Why: Avoid alert fatigue and false positives.
- Value: Improves SOC efficiency and response time.
- Notes: This should be a regular occurrence. Checking the health of analytical rules along with if the rules are of value. This is especially key for when data connector configuration changes.
Monitor Performance and Coverage
- Why: Ensure ongoing value and system health.
- Value: Detect ingestion failures or gaps in visibility.
- Notes: Dashboards showing log volume trends and alert rates. Configure alerts for data sources that haven’t been received after a period of time.
Summary
Hopefully these Microsoft Sentinel data source onboarding considerations helps when evaluating data sources into Microsoft Sentinel. Whilst ingesting data is crucial for detections and investigations, it also has a direct impact on the cost. Carefully evaluating the data sources and planning the adequate rules around this will ensure you are getting value from those data sources.
Thank you for taking the time to read this blog, if you haven’t already, please check out my Microsoft Sentinel Cheat Sheet.