Log Strategy for Sentinel: What Should You Collect?

Many organizations start their Sentinel journey by connecting every available data connector and streaming all logs into the workspace. The result is a surprisingly steep Azure bill and a sea of data that nobody actually uses. A solid log strategy is not about collecting as much as possible — it is about collecting what matters.

Why Log Strategy Is Critical

Microsoft Sentinel charges based on data volume. Every gigabyte ingested costs money, and those costs can escalate quickly. But this is about more than budget. Too many logs create noise that makes it harder to find real incidents. Too few logs mean blind spots where attackers can operate undetected.

A good log strategy balances three concerns:

• Coverage — — do we have enough data to detect relevant attacks?
• Cost — — are the data volumes justifiable relative to the value they provide?
• Quality — — do the logs give analysts enough context to actually investigate?

A Prioritization Framework for Log Sources

Not all log sources are equally important. Here is a framework for prioritization:

Tier 1: Identity and Authentication (Highest Priority)

These are the most important logs for detecting compromise. Most attacks involve identity theft or credential misuse at some point.

• Entra ID Sign-in Logs — — all sign-ins, including risk assessments from Identity Protection
• Entra ID Audit Logs — — changes to users, groups, roles, and applications
• MFA registration and usage — — detects MFA fatigue attacks and unauthorized enrollment
• Active Directory Security Events — — Event IDs 4624, 4625, 4768, 4769, 4776 as a minimum

Without identity logs, you are blind to most attack techniques.

Tier 2: Endpoint and Email

Endpoint data provides visibility into what actually happens on the machine after initial compromise.

• Microsoft Defender for Endpoint — — alerts, raw events, and device data
• Microsoft Defender for Office 365 — — phishing attempts, malicious attachments and links
• Exchange Online — — mailbox rules, forwarding, and access changes

These sources provide context that is indispensable during investigation.

Tier 3: Network and Cloud

Network and cloud logs cover the perimeter and cloud infrastructure.

• Azure Activity Log — — changes to Azure resources and access control
• Azure NSG Flow Logs — — network traffic between Azure resources
• DNS logs — — excellent for detecting C2 communication and tunneling
• Firewall logs — — filtered on blocked connections and unusual patterns

Tier 4: Application and Business Logic

Application logs are valuable for specific use cases but often generate large volumes.

• Web application logs — — access logs, error messages
• Database logs — — access to sensitive tables, queries
• Business applications — — ERP, HR, and financial systems

These should be connected selectively based on specific detection needs.

Azure Monitor vs. Sentinel: Basic vs. Analytics Logs

Not all logs need full query capabilities. Microsoft offers two log types at different price points:

Analytics Logs (Standard)

• Full KQL query support
• Detection rules can run against these logs
• 90 days of interactive retention (extendable)
• Higher cost per GB

Use Analytics Logs for data you actively need for detection and investigation — identity, endpoint, alerts.

Basic Logs

• Limited KQL support (simple filters, no joins)
• Cannot be used in detection rules
• 30 days of retention
• Significantly lower cost per GB

Use Basic Logs for high-volume data you primarily need for investigation, not detection — raw network logs, detailed endpoint events, application logs.

Archive Tier

For data that must be retained long-term for compliance, use archiving. The data is cheap to store but costs money to retrieve.

What Makes a Log Useful?

Not all logs are created equal. A useful log has these properties:

• Timestamp — — precise UTC time that enables correlation across sources
• User context — — who performed the action (user ID, email, UPN)
• Source IP — — where the action was performed from
• Action description — — what actually happened, not just a generic event code
• Result — — whether the action succeeded or failed
• Target resource — — which resource was affected

Logs without user context or with imprecise timestamps have limited investigative value.

Practical Steps to Build a Log Strategy

1. Map Your Detection Needs

Start with the threats you want to detect, not the data sources. Use MITRE ATT&CK to identify techniques relevant to your industry, then map which log sources cover those techniques.

2. Estimate Data Volume

Before connecting a new source, estimate the daily data volume. Azure Monitor can provide estimates, and many connectors report typical volumes in the documentation. Avoid billing surprises.

3. Choose the Right Log Tier

Not everything needs Analytics Logs. For each source, assess whether it is primarily used for active detection (Analytics) or reactive investigation (Basic).

4. Define Retention Policies

Different log types have different retention needs. Compliance requirements, investigation needs, and cost determine how long data should be stored. Document this as part of the strategy.

5. Review Monthly

Log strategy is not something you configure once and forget. Review data volume and costs monthly. Remove sources that are not generating value and add new sources when the threat landscape changes.

Common Mistakes

• Collecting everything without a plan — — results in high costs and too much noise
• No retention policy — — data is stored indefinitely for no reason
• Ignoring log quality — — connecting sources with poor structure that provide limited value
• Never reviewing ingestion costs — — monthly costs creep upward without anyone noticing
• Over-aggressive cost optimization — — cutting logs needed for investigation just to save money

ForSec helps organizations develop and implement log strategies for Microsoft Sentinel that balance coverage, cost, and quality. We make sure you have the right data at the right price.