LOG-06: Sign-In Log Anomaly Baseline

Overview

This guide walks you through establishing a baseline of normal privileged activity so you can detect anomalies against it: unusual spikes in role changes, Conditional Access policy modifications, consent grants, and out-of-pattern admin sign-ins. Without knowing what "normal" looks like, you cannot recognize the abnormal. This control is an advisory, analysis-driven baseline, best paired with a SIEM for continuous monitoring.

Control ID: LOG-06 Category: Logging & Visibility Baseline Level: Level 2 (Enhanced Security) Severity: Medium License Required: None (audit and sign-in logs are available on all tiers; longer retention and richer analytics benefit from P1/P2 and a SIEM)

Why This Matters

Without a baseline of normal activity, you cannot detect anomalous behavior. Establishing what "normal" looks like enables detection of unauthorized role assignments, policy changes, and consent grants.

An attacker who reaches admin privilege tends to do a burst of sensitive operations: assigning roles, weakening a Conditional Access policy, granting consent to an app. Each of those is individually a valid admin action. What gives them away is that they deviate from your established rhythm. A baseline turns "someone changed a policy" into "someone changed a policy at 3am from an unfamiliar location, and we make zero policy changes overnight."

Expected State

• Baseline of normal privileged operations is established
• Unusual spikes in role changes or CA modifications are detected
• SIEM integration provides continuous anomaly monitoring

Prerequisites

Before You Start

1. Decide what counts as privileged operations to baseline: directory role assignments, Conditional Access create/update/delete, app consent grants, credential additions to service principals, and admin interactive sign-ins.
2. Decide where you will keep and analyze logs long enough to establish a baseline (built-in retention is limited; export to storage or SIEM for durability, see LOG-02 and LOG-03).

Time Estimate

TrueConfig Remediation

This is a manual, advisory control. TrueConfig performs advisory analysis based on your audit log patterns and flags deviations, but establishing the operational baseline and wiring up continuous monitoring is done by your team, with SIEM integration recommended for real-time coverage. There is no single toggle that "creates a baseline"; the steps below set it up.

Step-by-Step Instructions

Step 1: Establish What Normal Looks Like

1. In the Microsoft Entra admin center, go to Monitoring & health > Audit logs.
2. Review a representative recent window (for example 30 days) and record norms for each sensitive operation:
   • Directory role changes: how many per week, by whom, during what hours
   • Conditional Access changes: how often policies are created/updated, and by which admins
   • App consent / credential additions: typical volume and actors
3. In Monitoring & health > Sign-in logs, record the normal picture for admin sign-ins: usual locations, devices, and hours.
4. Write these norms down. This documented set of "normal" ranges is your baseline.

Step 2: Export Logs for Durable Analysis

Built-in retention is limited, so send logs somewhere they persist long enough to baseline and hunt.

1. Go to Monitoring & health > Diagnostic settings > + Add diagnostic setting.
2. Select the log categories to export (AuditLogs, SignInLogs, and the non-interactive / service principal sign-in categories).
3. Send to your destination:
   • Log Analytics workspace / Microsoft Sentinel for querying and alerting
   • Storage account for long-term archive (see LOG-02)
   • Event hub to stream to a third-party SIEM (see LOG-03)
4. Save.

Step 3: Build Anomaly Detections

In your SIEM (Microsoft Sentinel shown conceptually):

1. Create scheduled analytics rules that fire when activity exceeds your documented baseline, for example:
   • A spike in role assignments beyond your normal weekly rate
   • Any Conditional Access policy modification outside business hours
   • App consent grants above your normal volume, or to apps requesting high-privilege scopes
   • Admin sign-ins from unfamiliar locations or new devices
2. Route alerts to your security team.
3. Enable relevant built-in Sentinel analytics and UEBA if available; they add behavioral baselining on top of your manual norms.

Step 4: Add Privileged Operation Alerts

Even without a full SIEM, configure targeted alerts:

1. Use PIM alerts for privileged role activity anomalies (see PA-04).
2. Configure privileged operation alerts (see LOG-04) for the most sensitive actions.
3. These complement the baseline by catching specific high-risk events immediately.

Step 5: Review and Tune Regularly

1. Revisit the baseline periodically (for example quarterly). Organizations change; the "normal" range drifts.
2. Tune detections to reduce false positives and close gaps revealed by real incidents or red-team exercises.

Verification Checklist

• The set of privileged operations to baseline is defined
• Documented norms exist for role changes, CA changes, consent grants, and admin sign-ins
• Audit and sign-in logs are exported to a durable destination (SIEM/storage)
• Anomaly detections exist for spikes and out-of-pattern privileged activity
• Alerts route to the security team
• Privileged operation / PIM alerts complement the baseline
• A recurring review keeps the baseline current

Troubleshooting

"We have no historical logs to baseline against"

Built-in Entra log retention is limited (and shorter without P1/P2). Start exporting to a Log Analytics workspace or storage now so you accumulate history, then baseline once you have a representative window.

"Too many false-positive anomaly alerts"

Your thresholds are tighter than reality. Widen the baseline ranges to match genuine normal activity, exclude known bulk-change events (planned migrations), and iterate. A noisy detection gets ignored, which defeats the purpose.

"We do not have a SIEM"

You can still baseline manually and use PIM alerts and privileged operation alerts (LOG-04) for the highest-risk events. SIEM integration is recommended for continuous, correlated detection but is not strictly required to establish the baseline.

"Service principal activity is missing from sign-in logs"

Enable the service principal and non-interactive sign-in categories in diagnostic settings. Workload identity activity is a key part of the anomaly picture (see PA-08 and CA-12).

"Which log has role changes vs sign-ins?"

Role assignments, Conditional Access edits, and consent grants are in the Audit logs. Who signed in, from where, and how is in the Sign-in logs. A good baseline uses both.

Cost Considerations

Note: You can start entirely license-free by documenting norms and using built-in PIM and privileged operation alerts, then add SIEM ingestion as budget allows for continuous monitoring.

Related Controls

• LOG-01: Enable Unified Audit Logging - The log source this baseline depends on
• LOG-05: Admin Activity Anomaly Detection - Detection built on top of the baseline
• LOG-04: Configure Privileged Operation Alerts - Immediate alerts for the highest-risk actions
• PA-08: Risky Service Principal Detection - Workload identity anomalies

Additional Resources

• Microsoft Learn: Microsoft Entra audit logs
• Microsoft Learn: Microsoft Entra sign-in logs
• Microsoft Learn: Stream logs to a SIEM via diagnostic settings
• Microsoft Learn: Microsoft Sentinel analytics rules