{"id":1266,"date":"2026-11-01T07:06:10","date_gmt":"2026-11-01T07:06:10","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/?p=1266"},"modified":"2026-11-01T07:09:37","modified_gmt":"2026-11-01T07:09:37","slug":"microsoft-sentinel-intermediate-one-complete-end-to-end-hands-on-lab-part-3","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/microsoft-sentinel-intermediate-one-complete-end-to-end-hands-on-lab-part-3\/","title":{"rendered":"Microsoft Sentinel Intermediate: One Complete End-to-End Hands-On Lab – Part – 3"},"content":{"rendered":"\n

Module 2: Intermediate | Day 3 only<\/strong> | Complete instructor-and-learner manual<\/h2>\n\n\n\n
\n

Edition:<\/strong> 1 November 2026
Course:<\/strong> Microsoft Sentinel Technical Training \u2014 5-day progressive curriculum
This document:<\/strong> Day 3 only; prerequisite: successful completion of Foundations (Days 1\u20132)
Primary user interface:<\/strong> Microsoft Defender portal (https:\/\/security.microsoft.com<\/code>)
Format:<\/strong> Day-wise, hands-on, step-by-step; no hourly timetable<\/strong>
Scope:<\/strong> I01\u2013I14, the 14 new<\/em> Intermediate competencies from the supplied agenda
Lab safety:<\/strong> Authorized, isolated Azure environment and fictional data only<\/p>\n<\/blockquote>\n\n\n\n

\n\n\n\n

READ FIRST \u2014 verification, boundaries, and a credible PASS result<\/h2>\n\n\n\n

What has been checked:<\/strong> The procedures and navigation paths in this manual were researched against Microsoft Learn pages available on 1 November 2026<\/strong>. Source-specific links are supplied beside each lab, and the source register is at the end. This document has been structurally and internally checked for syllabus coverage, complete examples, Markdown formatting, and evidence checkpoints.<\/p>\n\n\n\n

What cannot honestly be claimed:<\/strong> This manual was not run against your Azure tenant. The instructor must validate permissions, portal labels, region, features, data connector prerequisites, Linux distribution, actual field mappings, analytics rule scheduling, and billed usage in the assigned lab. A command appearing in the document is not<\/em> evidence that it succeeded in your tenant. Never mark a cloud lab PASS without the observable evidence specified below.<\/strong> Some features change by tenant and license, and some remain in preview.<\/p>\n\n\n\n

Do not use production identities, internet-routable test endpoints, actual threat infrastructure, active containment, or unapproved log ingestion.<\/strong> 198.51.100.23<\/code> and 203.0.113.10<\/code> are documentation-only addresses from TEST-NET ranges; they are labels inside fictitious records<\/em>, not destinations to contact. Do not expose TCP\/UDP 514 to the public internet.<\/p>\n\n\n\n

Day 3 complete means:<\/strong> Learner proves a second telemetry path (or an instructor-approved evidence-only substitution), correlates records from two relevant sources, enriches the result, publishes and tunes a controlled scheduled detection, configures low-risk incident-metadata automation, visualizes source quality, diagnoses failures, and produces an auditable final evidence pack. To earn the full operational PASS<\/strong>, the real connectors, rule, incident, and automation must actually produce the expected results. The offline synthetic track can award conceptual credit but not a claim of live deployment.<\/p>\n\n\n\n

Source freshness and critical corrections to older tutorials<\/h3>\n\n\n\n
    \n
  1. Portal:<\/strong>\u00a0Microsoft says its Azure-portal Sentinel experience will no longer be supported after\u00a031 March 2027<\/strong>. Teach the Defender portal first; Azure portal remains useful for Azure VM, network, agent, DCR and resource administration. [R01]<\/li>\n\n\n\n
  2. Collection:<\/strong>\u00a0Use\u00a0Syslog via AMA<\/strong>\u00a0and\u00a0Common Event Format (CEF) via AMA<\/strong>, with an explicit Data Collection Rule (DCR) and association. Avoid the retired legacy Log Analytics agent patterns. Facility and severity choices govern what enters the destination. [R02], [R03]<\/li>\n\n\n\n
  3. Threat intelligence:<\/strong>\u00a0New indicators belong in\u00a0ThreatIntelIndicators<\/code><\/strong>\u00a0(and STIX objects in\u00a0ThreatIntelObjects<\/code>), not the formerly ingested\u00a0ThreatIntelligenceIndicator<\/code>\u00a0table. The legacy TIP\/Graph indicator connector was announced for discontinuation in 2026; do not teach it as a new onboarding route. [R10], [R11]<\/li>\n\n\n\n
  4. UEBA:<\/strong>\u00a0Its enabling roles and supported sources must be checked. The current Defender experience has\u00a0Settings > Microsoft Sentinel > UEBA<\/strong>, with workspace anomaly detection configured separately where required. Activating UEBA creates additional telemetry and possible storage charges. [R12]<\/li>\n\n\n\n
  5. Analytics:<\/strong>\u00a0Scheduled rules must return\u00a0TimeGenerated<\/code><\/strong>\u00a0from source data. Enabling a rule does not automatically prove an alert or incident exists. Their evaluation can be affected by ingestion delay, lookback, result thresholds, grouping, and Defender integration. [R13], [R14]<\/li>\n\n\n\n
  6. Automation:<\/strong>\u00a0Day 3 uses\u00a0incident-metadata actions<\/strong>\u00a0(e.g., tag, owner, status) only; Logic Apps\/playbooks, approval gates, and disruptive remediation are Day 4 topics. Available trigger\/action combinations differ; alert-creation rules do\u00a0not<\/strong>\u00a0support the same metadata actions as incident-creation rules. [R15]<\/li>\n\n\n\n
  7. Workbooks:<\/strong>\u00a0Azure Monitor workbooks are workspace-associated Azure resources. Creation requires workbook-write permissions; Defender has its own viewer and some visualizations may route to Azure. [R16]<\/li>\n<\/ol>\n\n\n\n

    5W1H learning contract for Day 3<\/h3>\n\n\n\n
    Lens<\/th>Day 3 answer the learner must demonstrate<\/th><\/tr><\/thead>
    What<\/strong><\/td>AMA, Syslog, CEF, DCR, KQL correlation, watchlist, threat indicators, UEBA, custom detections, automation rules, workbooks<\/td><\/tr>
    Why<\/strong><\/td>Broaden coverage, improve evidential confidence, add asset\/business context, reduce unnecessary alerts, standardize safe SOC case handling<\/td><\/tr>
    Who<\/strong><\/td>Platform\/collector owner, connector engineer, detection author, watchlist steward, SOC analyst, SOC lead, approval authority<\/td><\/tr>
    When<\/strong><\/td>Ingest on agreed source need; correlate when separate signals share defensible keys; tune only with observed examples; automate after scoping<\/td><\/tr>
    Where<\/strong><\/td>Linux forwarding VM, DCR\/agent, Log Analytics workspace, Microsoft Sentinel configuration, Defender incident queue, workbook resource group<\/td><\/tr>
    How<\/strong><\/td>Authorized source \u2192 safe Linux test event \u2192 AMA+DCR \u2192 Syslog<\/code>\/CommonSecurityLog<\/code> \u2192 KQL + watchlist \u2192 detection \u2192 incident automation \u2192 workbook + evidence<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    Lab architecture (the arrows matter)<\/h3>\n\n\n\n
    configurationLinux demonstration eventsrsyslog or syslog-ngApproved firewall \/ CEF demoAzure Monitor AgentData Collection Rule + VM associationLog Analytics workspaceSyslog tableCommonSecurityLog tableTime-bounded KQL correlationSentinel watchlistScheduled analytics ruleDefender incidentMetadata-only automation ruleSource-health workbook<\/pre>\n\n\n\n
    Important distinction:<\/strong> A synthetic query that displays two datatable()<\/code> tables does not<\/strong> prove AMA, CEF parsing, a DCR, a stored log, or a real alert. It is a teaching fallback only. The normal path below uses real test<\/strong> events created on a controlled lab VM.<\/p>\n\n\n\n
    \n\n\n\n
    1. Instructor preparation (mandatory; complete before learners begin)<\/h1>\n\n\n\n
    1.1 Continuity from Days 1\u20132<\/h2>\n\n\n\n
    Keep the same fictional tenant storyline, Aster Retail<\/strong>. Students completed Foundations and can already identify the Microsoft Entra tenant, subscription, resource group, Sentinel-enabled Log Analytics workspace, baseline KQL, basic built-in detection, and incident-triage workflow. Do not re-teach those labs.<\/strong> Verify their artifacts and move immediately to the new<\/em> Intermediate tasks.<\/p>\n\n\n\n
    Scenario:<\/strong> A privileged account appears in a Linux audit-like application event, followed by a firewall denial from the same test source address. The SOC must correlate and interpret these signals, verify whether the identity is high value, classify a synthetic finding, create a tuned detector, assign the case safely, and visualize pipeline quality.<\/p>\n\n\n\n
    Scenario limitations:<\/strong> A shared IP plus a time window is not proof of a user’s identity. NAT, proxies, shared hosts, deliberate falsification, timing skew, and field parsing can create false links. The lab deliberately asks students to tighten correlation with an account field where the CEF parser supplies one.<\/p>\n\n\n\n
    1.2 Choose and record the delivery track<\/h2>\n\n\n\n
    Track<\/th>What is available<\/th>Can demonstrate<\/th>Can claim<\/th><\/tr><\/thead>
    A \u2014 full Azure lab (recommended)<\/strong><\/td>Approved subscription; existing Sentinel workspace; Linux VM; allowed agent\/DCR\/write roles<\/td>Real Syslog, optional CEF, watchlist, rule, incident, metadata automation, workbook<\/td>Full operational PASS if all evidence gates pass<\/td><\/tr>
    B \u2014 instructor-managed shared lab<\/strong><\/td>Learners receive reader access + instructor controls one collector and writes<\/td>Full evidence chain, with separately attributable learner submissions<\/td>PASS on demonstrated competencies; infrastructure steps recorded as instructor-operated<\/em><\/td><\/tr>
    C \u2014 restricted\/synthetic<\/strong><\/td>Query editor only, or instructor-supplied screenshots and CSV<\/td>datatable()<\/code> KQL, interpretation, simulated detection design, cost\/risk decisions<\/td>Conceptual PASS only; not<\/strong> live connector\/detection\/automation PASS<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    Use A or B<\/strong> for a course advertised as fully hands-on. Track C must be disclosed clearly to students.<\/p>\n\n\n\n
    1.3 Prerequisites and role ownership<\/h2>\n\n\n\n
    Component\/action<\/th>Preflight requirement<\/th>Who verifies<\/th><\/tr><\/thead>
    Microsoft Sentinel<\/td>Existing Sentinel-enabled Log Analytics workspace from Day 1; correct tenant and workspace<\/td>Instructor<\/td><\/tr>
    Portal<\/td>Learner can access Defender portal and the workspace-specific Sentinel experience<\/td>Instructor<\/td><\/tr>
    Linux VM<\/td>Instructor-approved Azure Linux VM using an AMA-supported OS; rsyslog<\/code> or syslog-ng<\/code>; logger<\/code>, shell, sudo<\/code>; accessible over Bastion or approved private SSH<\/td>Infrastructure owner<\/td><\/tr>
    Azure Arc (only for non-Azure servers)<\/td>Azure Connected Machine agent, supported configuration, connectivity<\/td>Infrastructure owner<\/td><\/tr>
    AMA installation<\/td>Permission to install VM extension; Microsoft guidance identifies VM Contributor \/ Azure Connected Machine Resource Administrator or equivalent<\/td>Azure administrator<\/td><\/tr>
    DCR creation and association<\/td>Monitoring Contributor at appropriate scope (or equivalent operations) and access to selected VM<\/td>Azure administrator<\/td><\/tr>
    Content hub<\/td>Permission to install needed Syslog \/ CEF solutions and access data connectors<\/td>Sentinel administrator<\/td><\/tr>
    Detection authoring<\/td>Microsoft Sentinel Contributor or appropriate workspace\/resource-group write permissions<\/td>Sentinel administrator<\/td><\/tr>
    Watchlist creation<\/td>Sufficient Sentinel workspace write permissions to create\/manage watchlists<\/td>Sentinel administrator<\/td><\/tr>
    Incident operations<\/td>Permitted Defender\/Sentinel incident-management role, owner\/team as applicable<\/td>SOC lead<\/td><\/tr>
    Workbook<\/td>At least Workbook Contributor on the workspace resource group for writing; Workbook Reader for reading<\/td>Azure administrator<\/td><\/tr>
    UEBA enablement<\/strong> (optional)<\/td>Microsoft Entra Security Administrator or equivalent<\/em> plus required Azure role, no blocking workspace lock; not needed merely to read existing UEBA results<\/td>Identity\/Sentinel administrator<\/td><\/tr>
    Threat intelligence onboarding<\/strong> (optional)<\/td>Valid licensed\/approved feed, correct connector\/API, legal authority to use it<\/td>TI owner<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    Do not assign Owner or Tenant Global Administrator broadly just to get a lab working.<\/strong> Have the instructor perform privileged steps where delegated access is unavailable. Role prerequisites are not interchangeable: VM and DCR administration are Azure control-plane activities; incident analysis and rule authoring have separate RBAC boundaries. [R02], [R12], [R13], [R16]<\/p>\n\n\n\n
    1.4 Safe naming and configuration record<\/h2>\n\n\n\n
    Before beginning, instructor fills this actual<\/em> environment sheet:<\/p>\n\n\n\n
    Field<\/th>Actual value (fill before class)<\/th><\/tr><\/thead>
    Training tenant (non-secret label)<\/td>________________<\/code><\/td><\/tr>
    Azure subscription (friendly name)<\/td>________________<\/code><\/td><\/tr>
    Region (Log Analytics + chosen VM)<\/td>________________<\/code><\/td><\/tr>
    Resource group (existing or new dedicated)<\/td>rg-sentinel-d3-lab-<cohort><\/code><\/td><\/tr>
    Workspace name (Day 1)<\/td>________________<\/code><\/td><\/tr>
    Linux collector VM<\/td>vm-sentinel-d3-<cohort><\/code><\/td><\/tr>
    OS + release (cat \/etc\/os-release<\/code>)<\/td>________________<\/code><\/td><\/tr>
    Agent extension state<\/td>________________<\/code><\/td><\/tr>
    Syslog DCR name<\/td>dcr-sentinel-d3-syslog<\/code><\/td><\/tr>
    CEF DCR name (if used)<\/td>dcr-sentinel-d3-cef<\/code><\/td><\/tr>
    Watchlist alias<\/td>day3_privileged_accounts<\/code><\/td><\/tr>
    Rule name<\/td>SENTINEL-D3-LAB-Privileged-Source-Correlation<\/code><\/td><\/tr>
    Automation name<\/td>SENTINEL-D3-LAB-Tag-And-Assign<\/code><\/td><\/tr>
    Workbook name<\/td>Sentinel D3 - Source Quality and Correlation<\/code><\/td><\/tr>
    Temporary owner (valid SOC user)<\/td>________________<\/code><\/td><\/tr>
    Approved maximum ingestion \/ cost budget<\/td>________________<\/code><\/td><\/tr>
    Planned cleanup owner<\/td>________________<\/code><\/td><\/tr>
    Allowed lab source IPs\/networks<\/td>________________<\/code><\/td><\/tr>
    Source mode<\/td>Syslog direct \/ Syslog+CEF \/ approved evidence-only<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    Keep an artifact register<\/strong>: DCR names\/IDs, extensions, solution installs, generated test marker, created analytics and automation rules, workbook, watchlist, and temporary VM. Without this register, safe cleanup is hard.<\/p>\n\n\n\n
    1.5 Financial, security, and data-protection gates<\/h2>\n\n\n\n
      \n
    1. Confirm subscription and resource-group budget alerts, VM SKU\/hourly charge, Log Analytics ingestion\/retention charge, possible Sentinel pricing, and whether connector data is billable. Do not assert this is a free lab.<\/li>\n\n\n\n
    2. Use a small, shut-down-capable VM and minimal bounded test events; do not activate all facilities globally to ‘see what happens’.<\/li>\n\n\n\n
    3. Require an approved region and data residency posture. Use only fictitious data.<\/li>\n\n\n\n
    4. Prefer Bastion\/private network access;\u00a0do not open port 514 publicly<\/strong>. For localhost-injected messages, there is no need for a public network listener.<\/li>\n\n\n\n
    5. Log ingestion and DCR updates can affect data volume, noise and charges. Instructor approval required before expanding facilities\/levels.<\/li>\n\n\n\n
    6. No actual account lockouts, firewall blocking, disabling identities, emailing outsiders, or Logic Apps playbooks in Day 3.<\/li>\n\n\n\n
    7. Decide cleanup before beginning: will the trainer delete only Day 3 resources, keep the Day 1\u20132 workspace, or remove an entire dedicated lab RG?\u00a0Never delete a shared workspace by accident.<\/strong><\/li>\n<\/ol>\n\n\n\n
      Instructor readiness checklist<\/h3>\n\n\n\n
        \n
      • [ ] Day 1\/2 learner progression already passed or equivalent evidence reviewed.<\/li>\n\n\n\n
      • [ ] Correct Sentinel workspace and selected Linux VM are documented.<\/li>\n\n\n\n
      • [ ] VM OS is compatible with current AMA support; VM connectivity is healthy.<\/li>\n\n\n\n
      • [ ] Agent\/DCR\/Content hub permissions are assigned or an instructor executor is present.<\/li>\n\n\n\n
      • [ ] At least one route to a real connector exists; alternative track announced if not.<\/li>\n\n\n\n
      • [ ] No production data source or public port 514 is included.<\/li>\n\n\n\n
      • [ ] Lab budget and acceptable telemetry rate are approved.<\/li>\n\n\n\n
      • [ ] A valid incident owner exists for automation lab.<\/li>\n\n\n\n
      • [ ] The instructor can open Log Analytics query editor, Analytics, Automation and Workbooks.<\/li>\n\n\n\n
      • [ ] Optional threat-intelligence and UEBA permissions\/charges are separately approved.<\/li>\n\n\n\n
      • [ ] Screenshots may capture only fictitious lab data and non-sensitive resource details.<\/li>\n<\/ul>\n\n\n\n
        1.6 How the learner records actual evidence<\/h2>\n\n\n\n
        Use this template at the end of every<\/strong> lab. Do not replace an empty result with a guessed result.<\/p>\n\n\n\n
        Lab ID:\nOperator \/ learner:\nWorkspace (friendly name):\nUTC start\/end:\nDelivery track: A \/ B \/ C\nExecuted steps (deviations and screenshots):\nQuery \/ command run:\nActual evidence (table, result count, name, timestamp):\nExpected vs observed:\nTroubleshooting performed:\nInstructor witness:\nVerdict: PASS \/ PARTIAL (reason) \/ BLOCKED (reason) \/ FAIL\nCreated artifacts for cleanup:\n<\/code><\/pre>\n\n\n\n
        The instructor owns raw screenshots and grading records. Do not place keys, tokens, secrets or privileged connection strings in evidence.<\/strong> Redact subscription IDs if evidence will leave the organization.<\/p>\n\n\n\n
        \n\n\n\n
        2. Navigation map and required competencies<\/h1>\n\n\n\n
        Lab<\/th>Syllabus<\/th>Main artifact \/ observable result<\/th>Hands-on track<\/th><\/tr><\/thead>
        D3-L01<\/td>I01<\/td>Source-selection decision record<\/td>All<\/td><\/tr>
        D3-L02<\/td>I02<\/td>Linux VM + AMA\/DCR + Syslog evidence<\/td>A\/B<\/td><\/tr>
        D3-L03<\/td>I02\u2013I03<\/td>CEF collector test or documented alternative; multicloud path matrix<\/td>A\/B\/C<\/td><\/tr>
        D3-L04<\/td>I04<\/td>Ingestion quality evidence and data-fidelity report<\/td>A\/B\/C<\/td><\/tr>
        D3-L05<\/td>I05<\/td>Reproducible KQL composition workbook \/ query pack<\/td>All<\/td><\/tr>
        D3-L06<\/td>I06<\/td>Two-source time-bounded correlation with limitations<\/td>A\/B\/C<\/td><\/tr>
        D3-L07<\/td>I07<\/td>Governed CSV watchlist + enriched query<\/td>A\/B\/C<\/td><\/tr>
        D3-L08<\/td>I08<\/td>Indicator verification and contextual decision<\/td>All; live TI optional<\/td><\/tr>
        D3-L09<\/td>I09<\/td>UEBA context or validated no-UEBA fallback<\/td>All; live UEBA optional<\/td><\/tr>
        D3-L10<\/td>I10<\/td>Scheduled custom rule, alert, and incident<\/td>A\/B<\/td><\/tr>
        D3-L11<\/td>I11<\/td>Replayed positive\/negative test cases; measured tuning<\/td>A\/B\/C<\/td><\/tr>
        D3-L12<\/td>I12<\/td>Low-risk incident metadata automation; audit evidence<\/td>A\/B<\/td><\/tr>
        D3-L13<\/td>I13<\/td>New source-health\/correlation workbook<\/td>A\/B<\/td><\/tr>
        D3-L14<\/td>I14<\/td>Multi-layer fault isolation and remediation journal<\/td>All<\/td><\/tr>
        D3-CAP<\/td>I01\u2013I14<\/td>Final assessment + 100-point evidence rubric<\/td>All; operational PASS only A\/B<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
        Dependency chain:<\/strong> L02 Syslog \u2192 L03 CEF (optional but recommended) \u2192 L04 quality \u2192 L05 KQL \u2192 L06 correlation \u2192 L07 enrichment \u2192 L10 detection \u2192 L11 tuning \u2192 L12 incident automation \u2192 L13 workbook \u2192 L14 troubleshooting \u2192 capstone. L08 and L09 add context if approved; do not block the core lab because a TI provider or licensed source is absent.<\/p>\n\n\n\n
        \n\n\n\n
        DAY 3 \u2014 INTERMEDIATE HANDS-ON LABS<\/h1>\n\n\n\n
        D3-L01 \u2014 Choose collection patterns for a realistic security estate (I01)<\/h2>\n\n\n\n
        Competency:<\/strong> Choose API, managed connector, agent-based, or syslog-forwarder intake based on source type, operational ownership, data quality, cost and compliance. Not a repeat of the Day 1 starter Microsoft connector.<\/p>\n\n\n\n
        Prerequisite:<\/strong> The learner can access the appropriate Sentinel workspace and its Data connectors listing.<\/p>\n\n\n\n
        Exact guided procedure<\/strong><\/p>\n\n\n\n
          \n
        1. Sign in to\u00a0Microsoft Defender portal<\/strong>\u00a0at\u00a0https:\/\/security.microsoft.com<\/code>; ensure the intended tenant is active.<\/li>\n\n\n\n
        2. Navigate to\u00a0Microsoft Sentinel > Configuration > Data connectors<\/strong>. Confirm the configured workspace; don’t assume a connector belongs to the workspace you intended. [R01], [R02]<\/li>\n\n\n\n
        3. Record the installed and available\u00a0Syslog via AMA<\/strong>,\u00a0Common Event Format (CEF) via AMA<\/strong>, and approved third-party connectors (if visible). If a connector is absent, check whether its solution must first be installed from\u00a0Microsoft Sentinel > Content management > Content hub<\/strong>.<\/li>\n\n\n\n
        4. For each candidate source, record its transport, logs generated, destination table, authentication, upstream agent needs, owner, service\/VM cost, estimated volume, and who signs off.<\/li>\n\n\n\n
        5. Build the table below, changing only the\u00a0selection<\/em>\u00a0to suit your actual environment.<\/li>\n<\/ol>\n\n\n\n
          Source<\/th>Preferred intake<\/th>Destination (confirm in connector)<\/th>Limitation \/ acceptance criterion<\/th><\/tr><\/thead>
          Azure subscription control-plane audit<\/td>Existing Day 1 Azure Activity<\/td>AzureActivity<\/code><\/td>No need to reconnect for Day 3<\/td><\/tr>
          Linux system\/application syslog<\/td>Syslog via AMA + DCR<\/td>Syslog<\/code><\/td>Supported Linux VM; facilities\/severity correctly selected<\/td><\/tr>
          Firewall emitting CEF<\/td>CEF via AMA + Linux forwarder + DCR<\/td>CommonSecurityLog<\/code><\/td>Vendor product mapping; separate facility, no duplicate ingest<\/td><\/tr>
          AWS CloudTrail (if approved)<\/td>Supported Microsoft\/partner CloudTrail solution\/connector<\/td>Source-specific, inspect connector<\/td>Cloud-side authorization + region\/account governance<\/td><\/tr>
          GCP audit or other SaaS<\/td>Supported connector\/API or Logs Ingestion API<\/td>Connector-specific<\/td>Authentication, event coverage, field mapping<\/td><\/tr>
          Vendor application without connector<\/td>Ingestion API\/custom integration only after design review<\/td>Custom table if designed<\/td>Contract, parsing, schema, ownership, costs<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
            \n
          1. Mark which additional data you will really ingest\u00a0today<\/strong>. The reference lab uses a Linux syslog source and (where possible) a synthetic CEF firewall source.<\/li>\n\n\n\n
          2. Compare two alternatives: API\/managed integration versus a collector\/agent. Write why one is safer\/cheaper\/more maintainable for the selected source.<\/li>\n<\/ol>\n\n\n\n
            PASS D3-L01:<\/strong> Student submits the decision matrix and correctly distinguishes source availability from active ingestion<\/em>. Not a PASS:<\/strong> Merely finding a connector tile.<\/p>\n\n\n\n
            Troubleshooting:<\/strong> Missing connector \u2192 check Content hub solution and permissions; wrong tenant\/workspace \u2192 switch explicitly; no connector available \u2192 select documented offline pattern and mark operational integration BLOCKED.<\/p>\n\n\n\n
            Reference:<\/strong> [R02], [R03], [R04].<\/p>\n\n\n\n
            \n\n\n\n
            D3-L02 \u2014 Provision\/validate Linux collector; configure AMA, DCR, and Syslog (I02)<\/h2>\n\n\n\n
            Competency:<\/strong> Prove that the second telemetry pipeline exists end-to-end. This is the first indispensable live lab<\/strong>.<\/p>\n\n\n\n
            A. Prepare an isolated Linux VM<\/h3>\n\n\n\n
              \n
            1. Instructor creates or provides an\u00a0Azure virtual machine<\/strong>\u00a0with an OS explicitly supported by current Azure Monitor Agent for Linux. Prefer a small Ubuntu LTS\/RHEL-class image only after verifying the AMA compatibility list in [R05]; don’t blindly choose ‘latest’ or use an arbitrary distro.<\/li>\n\n\n\n
            2. Place VM in the approved training subscription, resource group, region and private network. Use private SSH or Azure Bastion. Do not give the VM a public 514 rule.<\/li>\n\n\n\n
            3. Confirm the VM is running, has DNS\/HTTPS connectivity to required Azure Monitor endpoints, and has available disk space. Restrict SSH to authorized principals. An Arc-enabled non-Azure alternative is acceptable only when Azure Arc Connected Machine agent is already healthy.<\/li>\n\n\n\n
            4. Open an SSH\/Bastion terminal and record the host\/version:<\/li>\n<\/ol>\n\n\n\n
              cat \/etc\/os-release\nuname -a\nhostname -f || hostname\nid\npython3 --version\ncommand -v logger\ncommand -v rsyslogd || command -v syslog-ng\n<\/code><\/pre>\n\n\n\n
                \n
              1. For Ubuntu with\u00a0rsyslog<\/code>\u00a0installed, check services. If not installed, use the distribution’s supported package mechanism after instructor approval;\u00a0do not run a downloaded opaque shell script without reviewing its current Microsoft-generated contents<\/strong>.<\/li>\n<\/ol>\n\n\n\n
                sudo systemctl status rsyslog --no-pager || true\nsudo systemctl status syslog-ng --no-pager || true\nsudo systemctl status azuremonitoragent --no-pager || true\n<\/code><\/pre>\n\n\n\n
                  \n
                1. Record which syslog daemon actually runs. Avoid running\u00a0rsyslog<\/code>\u00a0and\u00a0syslog-ng<\/code>\u00a0concurrently on the same listener unless explicitly designed. If\u00a0logger<\/code>\u00a0is missing, have the administrator install the distro’s\u00a0util-linux<\/code>\u00a0package using an approved method.<\/li>\n<\/ol>\n\n\n\n
                  Expected evidence:<\/strong> Operating-system identification, syslog daemon active, authorized VM access, VM resource ID and subscription recorded. AMA may not yet be installed at this stage.<\/p>\n\n\n\n
                  B. Make the Syslog connector available<\/h3>\n\n\n\n
                    \n
                  1. In Defender portal, open\u00a0Microsoft Sentinel > Content management > Content hub<\/strong>.<\/li>\n\n\n\n
                  2. Search for the\u00a0Syslog<\/strong>\u00a0solution; install\/update the supported solution\u00a0only in the training workspace<\/strong>\u00a0if the required connector is absent. Confirm installation completed.<\/li>\n\n\n\n
                  3. Go to\u00a0Microsoft Sentinel > Configuration > Data connectors<\/strong>, search for\u00a0Syslog via AMA<\/strong>, open the connector page. If none appears, revisit solution installation\/permissions rather than guessing a similarly named legacy connector. [R02]<\/li>\n<\/ol>\n\n\n\n
                    C. Create and attach the Data Collection Rule<\/h3>\n\n\n\n
                      \n
                    1. From the\u00a0Syslog via AMA connector page<\/strong>, choose\u00a0+ Create data collection rule<\/strong>.<\/li>\n\n\n\n
                    2. Basics:<\/strong>\u00a0enter\u00a0dcr-sentinel-d3-syslog<\/code>\u00a0(append cohort suffix if name already used); choose approved subscription\/resource group.<\/li>\n\n\n\n
                    3. Resources:<\/strong>\u00a0choose the actual Linux VM. For Azure VM, the host should be visible. For non-Azure host, confirm Arc connection first. Do not select other machines.<\/li>\n\n\n\n
                    4. Collect:<\/strong>\u00a0choose only\u00a0facility\u00a0local5<\/code><\/strong>\u00a0and severity\u00a0Warning<\/strong>\u00a0(this also covers more severe messages). If the current wizard presents a different facility list, locate and record\u00a0local5<\/code>; do not select all facilities as a workaround.<\/li>\n\n\n\n
                    5. Review the selected stream\/destination and the\u00a0correct target workspace<\/strong>. Create the DCR.<\/li>\n\n\n\n
                    6. Refresh the connector page and verify the DCR is listed and linked to the correct VM. Azure’s extension installation may be initiated automatically from this workflow; check\u00a0Azure portal > VM > Extensions + applications<\/strong>\u00a0and ensure\u00a0AzureMonitorLinuxAgent<\/code>\u00a0reaches\u00a0Provisioning succeeded<\/strong>. [R02], [R06]<\/li>\n\n\n\n
                    7. In Azure portal, open\u00a0Monitor > Data Collection Rules<\/strong>, select this DCR, and verify its resource association, facility-level selection, and destination. Screenshot the\u00a0actual<\/strong>\u00a0association, not only the DCR name.<\/li>\n\n\n\n
                    8. On Linux, re-check agent service and host resources:<\/li>\n<\/ol>\n\n\n\n
                      sudo systemctl is-active azuremonitoragent || true\nsudo systemctl is-active rsyslog || true\nsudo systemctl is-active syslog-ng || true\ndf -h \/\n<\/code><\/pre>\n\n\n\n
                      Expected evidence:<\/strong> AMA service is active or<\/em> extension provisioning is successful as documented; DCR association includes the selected VM; allowed local5<\/code>\/Warning filter and intended destination are visible.<\/p>\n\n\n\n
                      D. Send a bounded, harmless Syslog test message<\/h3>\n\n\n\n
                        \n
                      1. Define a unique training marker; write it down so your queries can isolate this run:<\/li>\n<\/ol>\n\n\n\n
                        DAY3_RUN_ID=\"D3-$(date -u +%Y%m%dT%H%M%SZ)\"\necho \"$DAY3_RUN_ID\"\n<\/code><\/pre>\n\n\n\n
                          \n
                        1. On the selected VM, send\u00a0one<\/strong>\u00a0local application-style event. This is not an actual privileged login, and its fictional source IP will never be contacted:<\/li>\n<\/ol>\n\n\n\n
                          logger -p local5.warning -t SENTINEL_D3 \\\n  \"SENTINEL_D3_LAB run=${DAY3_RUN_ID} actor=lab.admin@asterretail.example src=198.51.100.23 outcome=success event=privileged_session\"\n<\/code><\/pre>\n\n\n\n
                            \n
                          1. Check the local system journal or syslog, depending on distribution. Some distributions won’t write this local facility to\u00a0\/var\/log\/syslog<\/code>; do not infer collection failure solely from an absent file.<\/li>\n<\/ol>\n\n\n\n
                            sudo journalctl -t SENTINEL_D3 --since \"20 minutes ago\" --no-pager | tail -n 15\n<\/code><\/pre>\n\n\n\n
                              \n
                            1. In the correct\u00a0workspace Logs<\/strong>\u00a0query experience, run the query below. Replace\u00a0D3-REPLACE-THIS<\/code>\u00a0with the exact printed run ID. Remember that ingested records can arrive asynchronously; Microsoft’s connector troubleshooting guidance allows\u00a0up to about 20 minutes<\/strong>. [R02], [R06]<\/li>\n<\/ol>\n\n\n\n
                              Syslog\n| where TimeGenerated >= ago(2h)\n| where SyslogMessage contains \"SENTINEL_D3_LAB\"\n| where SyslogMessage contains \"D3-REPLACE-THIS\"\n| project TimeGenerated, Computer, Facility, SeverityLevel, ProcessName, SyslogMessage\n| order by TimeGenerated desc\n<\/code><\/pre>\n\n\n\n
                                \n
                              1. If rows are not present, run the broad scoping query to distinguish ingestion from an over-tight filter:<\/li>\n<\/ol>\n\n\n\n
                                Syslog\n| where TimeGenerated >= ago(2h)\n| summarize Count=count(), Latest=max(TimeGenerated) by Computer, Facility, SeverityLevel\n| order by Latest desc\n<\/code><\/pre>\n\n\n\n
                                  \n
                                1. Use a\u00a0UTC<\/strong>\u00a0timestamp in the evidence register and record actual ingestion latency if\u00a0ingestion_time()<\/code>\u00a0is available (see L04). Never change the selected workspace mid-test.<\/li>\n<\/ol>\n\n\n\n
                                  PASS D3-L02:<\/strong> DCR + VM association evidence, healthy agent\/daemon, an observed row with the unique marker in the destination Syslog<\/code> table<\/strong>, and its TimeGenerated<\/code>. PARTIAL:<\/strong> only host-level logger evidence. BLOCKED:<\/strong> inability to install agent or access workspace.<\/p>\n\n\n\n
                                  Diagnostic sequence:<\/strong> no Linux emission \u2192 fix logger<\/code>\/syslog daemon; missing agent extension \u2192 check Azure VM scope\/role; missing DCR association \u2192 assign right VM; wrong facility or severity \u2192 correct narrow DCR; no workspace rows \u2192 inspect endpoint access, AMA logs, workspace and allowed processing delay. Do not ‘fix’ this by collecting everything.<\/strong><\/p>\n\n\n\n
                                  Sources:<\/strong> [R02], [R03], [R05], [R06].<\/p>\n\n\n\n
                                  \n\n\n\n
                                  D3-L03 \u2014 Collect a synthetic CEF firewall signal and compare multicloud options (I02, I03)<\/h2>\n\n\n\n
                                  Competency:<\/strong> Explain raw Syslog versus CEF, add a second class of telemetry without facility collision, and select supported third-party\/multicloud collection paths. No real firewall is required<\/strong>\u2014only a lab-generated CEF-format message.<\/p>\n\n\n\n
                                  A. Plan the forwarding route before changing it<\/h3>\n\n\n\n
                                  Approved synthetic CEF via loggerLocal UDP 514 listenerrsyslog \/ syslog-ngAMA local receiving endpointCEF DCR: local4 Warning+CommonSecurityLog<\/pre>\n\n\n\n
                                    \n
                                  1. On the Linux collector from L02, verify that\u00a0rsyslog<\/code>\u00a0or\u00a0syslog-ng<\/code>\u00a0is installed and\u00a0azuremonitoragent<\/code>\u00a0is healthy.<\/li>\n\n\n\n
                                  2. In Defender portal open\u00a0Microsoft Sentinel > Content management > Content hub<\/strong>, locate the\u00a0Common Event Format<\/strong>\u00a0(CEF) solution and install it if required. Then open\u00a0Microsoft Sentinel > Configuration > Data connectors > Common Event Format (CEF) via AMA<\/strong>. [R02]<\/li>\n\n\n\n
                                  3. Create a DCR named\u00a0dcr-sentinel-d3-cef<\/code>\u00a0using the same approved subscription, destination workspace and\u00a0only the intended lab Linux VM<\/strong>.<\/li>\n\n\n\n
                                  4. In\u00a0Collect<\/strong>, choose facility\u00a0local4<\/code><\/strong>\u00a0with minimum severity\u00a0Warning<\/strong>. It must\u00a0not<\/em>\u00a0overlap the\u00a0local5<\/code><\/strong>\u00a0Syslog DCR from L02. Where the portal provides stream\/destination details, confirm CEF target stream\u00a0Microsoft-CommonSecurityLog<\/code><\/strong>\u00a0(destination table\u00a0CommonSecurityLog<\/code>) rather than generic\u00a0Syslog<\/code>.<\/li>\n\n\n\n
                                  5. Create the DCR and verify it is associated with the VM. Confirm the AMA extension succeeded. Record whether two DCRs are associated with this single VM, and check they don’t collect the same facility into both streams. [R02], [R03]<\/li>\n\n\n\n
                                  6. If the host is acting as a Syslog\/CEF log\u00a0forwarder<\/strong>, follow the\u00a0current installation script shown on that exact connector page<\/strong>\u00a0to configure your chosen syslog daemon and forwarding\/listening behavior.\u00a0Inspect the script in the UI and have the instructor authorize it before execution.<\/strong>\u00a0Do not paste a stale URL\/script from an older tutorial. This can modify rsyslog\/syslog-ng files and open a local listener.<\/li>\n\n\n\n
                                  7. Verify the listener from the Linux machine:<\/li>\n<\/ol>\n\n\n\n
                                    sudo systemctl status azuremonitoragent --no-pager\nsudo systemctl status rsyslog --no-pager || true\nsudo systemctl status syslog-ng --no-pager || true\nsudo ss -lunp | grep ':514' || true\nsudo ss -ltnp | grep -E '(:28330|:514)' || true\n<\/code><\/pre>\n\n\n\n
                                      \n
                                    1. If no UDP 514 listener exists, return to the currently documented connector\/daemon configuration.\u00a0Do not set\u00a00.0.0.0:514<\/code>\u00a0on an internet-accessible host just to make the test pass.<\/strong>\u00a0Use a private Linux host and local injection.<\/li>\n<\/ol>\n\n\n\n
                                      B. Emit one controlled CEF message<\/h3>\n\n\n\n
                                      In the same Linux host terminal, execute the following. Its field values are fictitious; the logger sends to localhost only. The syntax follows the structure of Microsoft’s CEF-via-AMA test instructions; actual parsing must still be verified on the workspace. [R02], [R06]<\/p>\n\n\n\n
                                      logger -p local4.warning -P 514 -n 127.0.0.1 --rfc3164 -t CEF \\\n  '0|AsterLab|Firewall|1.0|D3-100|Privileged source was denied|5|src=198.51.100.23 dst=203.0.113.10 suser=lab.admin@asterretail.example act=deny msg=SENTINEL_D3_LAB'\n<\/code><\/pre>\n\n\n\n
                                      Why -t CEF<\/code> rather than putting CEF:<\/code> into an arbitrary shell string?<\/strong> With the Microsoft-documented logger<\/code> approach, the syslog application tag is used to construct the expected RFC-style payload. Third-party devices may produce a different but valid envelope; inspect the actual raw payload on a test host if parsing fails.<\/p>\n\n\n\n
                                      In the workspace Logs editor:<\/p>\n\n\n\n
                                      CommonSecurityLog\n| where TimeGenerated >= ago(2h)\n| where DeviceVendor == \"AsterLab\" and DeviceProduct == \"Firewall\"\n| project TimeGenerated, Computer, DeviceVendor, DeviceProduct,\n          DeviceEventClassID, Activity, DeviceAction,\n          SourceIP, DestinationIP, SourceUserName\n| order by TimeGenerated desc\n<\/code><\/pre>\n\n\n\n
                                      Expected:<\/strong> At least one new CommonSecurityLog<\/code> record with DeviceVendor = AsterLab<\/code>, DeviceProduct = Firewall<\/code>, and SourceIP = 198.51.100.23<\/code>. Verify<\/strong> whether the parser populated SourceUserName<\/code> from suser<\/code> and DeviceAction<\/code> from act<\/code>; different product schemas and parsers can alter field names\/values. A Syslog event without parsed CEF columns is not<\/strong> the same as successful CEF parsing.<\/p>\n\n\n\n
                                      If the correct CEF fields have not appeared, wait for the documented processing window then follow L14. Do not keep replaying unbounded messages. Use the diagnostic KQL below to check whether the data appeared as generic Syslog instead:<\/p>\n\n\n\n
                                      Syslog\n| where TimeGenerated >= ago(2h)\n| where SyslogMessage contains \"AsterLab\" or SyslogMessage contains \"D3-100\"\n| project TimeGenerated, Computer, Facility, ProcessName, SyslogMessage\n| order by TimeGenerated desc\n<\/code><\/pre>\n\n\n\n
                                      An appearance only<\/strong> in Syslog<\/code> suggests a CEF stream\/facility\/parser\/configuration issue. It may also be normal for the current DCR’s intended design; check exactly what you configured rather than assuming the connector is wrong.<\/p>\n\n\n\n
                                      C. Instructor walkthrough: multi-cloud and third-party collection choices<\/h3>\n\n\n\n
                                      For each hypothetical environment below, find the currently supported integration route in Content hub. Do not<\/strong> connect live tenants to the lab without written authorization.<\/p>\n\n\n\n
                                      Estate<\/th>Source-side prerequisite to discuss<\/th>Typical destination consideration<\/th>Mandatory mapping questions<\/th><\/tr><\/thead>
                                      AWS CloudTrail<\/td>Account\/region coverage; bucket\/event delivery; least privilege<\/td>CloudTrail connector\/solution’s documented table<\/td>API vs data event selection; timestamps; cross-account scope<\/td><\/tr>
                                      GCP Cloud Audit Logs<\/td>GCP project\/org permissions and delivery mechanism<\/td>GCP connector or approved log pipeline<\/td>Principal identity, resource hierarchy, event category<\/td><\/tr>
                                      Firewall \/ NDR<\/td>CEF-compatible device or collector; networking<\/td>CommonSecurityLog<\/code> if connector uses CEF<\/td>Which field contains source IP\/action\/user? NAT?<\/td><\/tr>
                                      Identity SaaS<\/td>Supported provider connector, API or streaming integration<\/td>Connector-specific logs<\/td>Principal naming; failure codes; service-account exclusion<\/td><\/tr>
                                      Custom app<\/td>Design-reviewed DCR + Logs Ingestion API \/ partner route<\/td>Explicitly named custom table<\/td>Schema and transformation; event-time; pagination; retries<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                      PASS D3-L03:<\/strong> Student demonstrates a parsed test CEF record or<\/strong> provides an instructor-authorized alternate-source evidence record with honest reason; plus a completed multicloud selection matrix. Full live correlation assessment still needs two appropriate actual sources.<\/strong> Do not claim that listing AWS or GCP connectors constitutes onboarding them.<\/p>\n\n\n\n
                                      Troubleshooting:<\/strong> logger<\/code> rejected --rfc3164<\/code> \u2192 inspect logger --help<\/code> and use an approved supported Linux utility; port 514 not listening \u2192 inspect Microsoft script\/rsyslog config and listen address; record only in Syslog \u2192 check CEF facility (local4<\/code>), stream and header; record nowhere \u2192 packet\/daemon\/agent\/DCR\/egress checks. Consult [R02], [R03], [R06].<\/p>\n\n\n\n
                                      \n\n\n\n
                                      D3-L04 \u2014 Test the ingestion pipeline for fidelity, timeliness, and duplicates (I04)<\/h2>\n\n\n\n
                                      Competency:<\/strong> Determine whether data is usable for detections; separate \u201cevents are present\u201d from \u201cthe source is trustworthy.\u201d<\/p>\n\n\n\n
                                      A. Confirm basic coverage and freshness<\/h3>\n\n\n\n
                                        \n
                                      1. In Logs, select the correct workspace, set an appropriate time window, and execute the queries individually:<\/li>\n<\/ol>\n\n\n\n
                                        Syslog\n| where TimeGenerated >= ago(24h)\n| summarize Events=count(), LastEvent=max(TimeGenerated), Hosts=dcount(Computer)\n    by Facility, SeverityLevel\n| order by Events desc\n<\/code><\/pre>\n\n\n\n
                                        CommonSecurityLog\n| where TimeGenerated >= ago(24h)\n| summarize Events=count(), LastEvent=max(TimeGenerated),\n            MissingSrc=countif(isempty(SourceIP)),\n            MissingAction=countif(isempty(DeviceAction))\n    by DeviceVendor, DeviceProduct\n| order by Events desc\n<\/code><\/pre>\n\n\n\n
                                          \n
                                        1. Use a field-level sample to verify that source IP, actor\/user and event classification mean what the SOC thinks they mean:<\/li>\n<\/ol>\n\n\n\n
                                          CommonSecurityLog\n| where TimeGenerated >= ago(2h)\n| where DeviceVendor == \"AsterLab\"\n| project TimeGenerated, DeviceVendor, DeviceProduct,\n          SourceIP, SourceUserName, DeviceAction,\n          DestinationIP, DeviceEventClassID, Activity\n| take 20\n<\/code><\/pre>\n\n\n\n
                                            \n
                                          1. Inspect the actual source (SyslogMessage<\/code>) rather than trusting a parser or apparent IP field blindly. Compare an emitted test string to its resulting row.<\/li>\n<\/ol>\n\n\n\n
                                            B. Measure arrival delay only if available<\/em><\/h3>\n\n\n\n
                                            ingestion_time()<\/code> can return a valid ingestion timestamp when supported by the table’s ingestion-time policy; null<\/code> is not proof that no data arrived. Also, event TimeGenerated<\/strong> may reflect device clock behavior rather than actual receipt time.<\/p>\n\n\n\n
                                            Syslog\n| where TimeGenerated >= ago(2h)\n| where SyslogMessage contains \"SENTINEL_D3_LAB\"\n| extend IngestedAt = ingestion_time()\n| extend IngestDelaySeconds = datetime_diff('second', IngestedAt, TimeGenerated)\n| project TimeGenerated, IngestedAt, IngestDelaySeconds,\n          Computer, Facility, SyslogMessage\n| order by TimeGenerated desc\n<\/code><\/pre>\n\n\n\n
                                              \n
                                            1. If\u00a0IngestedAt<\/code>\u00a0is null or the delay looks negative\/implausible, record\u00a0not measurable in this table\/configuration<\/strong>, then compare your instructor’s shell emission UTC timestamp, observed ingestion UTC timestamp, VM time sync and source time fields. Do not publish an SLA conclusion based on one synthetic event.<\/li>\n<\/ol>\n\n\n\n
                                              C. Check duplicates and parsing quality<\/h3>\n\n\n\n
                                              Syslog\n| where TimeGenerated >= ago(2h)\n| where SyslogMessage contains \"SENTINEL_D3_LAB\"\n| summarize Count=count(), First=min(TimeGenerated), Last=max(TimeGenerated)\n    by Computer, SyslogMessage\n| order by Count desc\n<\/code><\/pre>\n\n\n\n
                                              A Count > 1<\/code> can mean intentionally re-sent source events<\/strong> or true duplication. Inspect whether the same message was generated multiple times; determine whether both Syslog and CEF DCRs match the same facility. Do not deduplicate events indiscriminately in detections without preserving distinct source-event IDs.<\/p>\n\n\n\n
                                              CommonSecurityLog\n| where TimeGenerated >= ago(24h)\n| summarize Total=count(),\n            EmptySourceIP=countif(isempty(SourceIP)),\n            EmptyUser=countif(isempty(SourceUserName)),\n            EmptyAction=countif(isempty(DeviceAction))\n    by DeviceVendor, DeviceProduct\n| extend SourceIPCompletenessPct =\n         iif(Total == 0, real(null), 100.0 * (Total - EmptySourceIP) \/ Total)\n| order by Total desc\n<\/code><\/pre>\n\n\n\n
                                                \n
                                              1. Prepare a small quality report:<\/li>\n<\/ol>\n\n\n\n
                                                Test<\/th>Actual observation<\/th>Expected acceptance condition<\/th><\/tr><\/thead>
                                                Freshness<\/td>________<\/code><\/td>New test rows visible within documented delay\/window<\/td><\/tr>
                                                Table target<\/td>________<\/code><\/td>Syslog in Syslog<\/code>, CEF in CommonSecurityLog<\/code><\/td><\/tr>
                                                Host\/source identity<\/td>________<\/code><\/td>Distinguishes lab VM and fictional source<\/td><\/tr>
                                                Source address\/action<\/td>________<\/code><\/td>Fields present and semantically correct, or limitation recorded<\/td><\/tr>
                                                Clock\/time<\/td>________<\/code><\/td>Source time plausible; skew assessed<\/td><\/tr>
                                                Duplication<\/td>________<\/code><\/td>Repeated rows explained, not assumed<\/td><\/tr>
                                                Narrow collection<\/td>________<\/code><\/td>Selected DCR facilities\/severities are documented<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                PASS D3-L04:<\/strong> Quantitative query results and a reasoned fidelity verdict. \u201cTwo rows exist\u201d without schema\/duplicate\/timestamp analysis is insufficient.<\/p>\n\n\n\n
                                                Sources:<\/strong> [R02], [R03], [R06].<\/p>\n\n\n\n
                                                \n\n\n\n
                                                D3-L05 \u2014 Intermediate KQL lab: let<\/code>, join<\/code>, union<\/code>, extend<\/code>, parse<\/code>, mv-expand<\/code>, distinct<\/code> (I05)<\/h2>\n\n\n\n
                                                Competency:<\/strong> Compose advanced queries intentionally and verify that joins do not inflate confidence or row counts. These exercises run without any ingestion<\/strong> because they use in-query datatable()<\/code> and print<\/code> samples. They are for KQL learning, not for a deployed analytics rule.<\/p>\n\n\n\n
                                                Exercise K01 \u2014 Reusable expressions, filtering and calculated fields<\/h3>\n\n\n\n
                                                Copy one block at a time<\/strong> into the workspace Logs query editor:<\/p>\n\n\n\n
                                                let AdminEvents = datatable(Actor:string, SourceIP:string, Action:string)\n[\n  \"lab.admin@asterretail.example\", \"198.51.100.23\", \"privileged_login\",\n  \"lab.ops@asterretail.example\",   \"203.0.113.99\",  \"read_config\",\n  \"lab.admin@asterretail.example\", \"198.51.100.23\", \"change_setting\"\n];\nAdminEvents\n| extend IsPrivilegedAction = Action in (\"privileged_login\", \"change_setting\")\n| where IsPrivilegedAction\n| project Actor, SourceIP, Action, IsPrivilegedAction\n<\/code><\/pre>\n\n\n\n
                                                Expected:<\/strong> Two rows for lab.admin@...<\/code>. Explain that let<\/code> improves readability but doesn’t automatically materialize or cache a query.<\/p>\n\n\n\n
                                                Exercise K02 \u2014 join kind=inner<\/code> (and why row counts multiply)<\/h3>\n\n\n\n
                                                let Identity = datatable(Actor:string, SourceIP:string)\n[\n  \"lab.admin@asterretail.example\", \"198.51.100.23\",\n  \"lab.user@asterretail.example\",  \"203.0.113.99\"\n];\nlet Firewall = datatable(SourceIP:string, FirewallAction:string)\n[\n  \"198.51.100.23\", \"deny\",\n  \"192.0.2.55\", \"allow\"\n];\nIdentity\n| join kind=inner (Firewall) on SourceIP\n| project Actor, SourceIP, FirewallAction\n<\/code><\/pre>\n\n\n\n
                                                Expected:<\/strong> Exactly one matching row. Modify Firewall<\/code> to include the same SourceIP<\/code> twice and observe duplicate matches; then articulate why IP equality alone is insufficient attribution<\/strong>.<\/p>\n\n\n\n
                                                Exercise K03 \u2014 Time-bounded correlation<\/h3>\n\n\n\n
                                                let Logins = datatable(LoginAt:datetime, Actor:string, SourceIP:string)\n[\n  datetime(2026-11-01T09:00:00Z), \"lab.admin@asterretail.example\", \"198.51.100.23\",\n  datetime(2026-11-01T11:00:00Z), \"lab.user@asterretail.example\", \"203.0.113.99\"\n];\nlet Blocks = datatable(BlockAt:datetime, SourceIP:string)\n[\n  datetime(2026-11-01T09:05:00Z), \"198.51.100.23\",\n  datetime(2026-11-01T11:45:00Z), \"203.0.113.99\"\n];\nLogins\n| join kind=inner (Blocks) on SourceIP\n| where BlockAt between (LoginAt - 10m .. LoginAt + 10m)\n| project LoginAt, Actor, SourceIP, BlockAt\n<\/code><\/pre>\n\n\n\n
                                                Expected:<\/strong> Only the 09:00\/09:05 pair. Note: static test timestamps are fine in in-query<\/strong> teaching examples but unsuitable for alert rules that should evaluate new events.<\/p>\n\n\n\n
                                                Exercise K04 \u2014 union<\/code> heterogeneous sources safely<\/h3>\n\n\n\n
                                                let Linux = datatable(Actor:string, Action:string)\n[\n  \"lab.admin@asterretail.example\", \"login\"\n]\n| extend Source=\"Linux\";\nlet Cloud = datatable(Actor:string, Action:string)\n[\n  \"lab.admin@asterretail.example\", \"role_change\"\n]\n| extend Source=\"Cloud\";\nunion Linux, Cloud\n| project Source, Actor, Action\n| order by Source asc\n<\/code><\/pre>\n\n\n\n
                                                Expected:<\/strong> Two rows. union<\/code> appends results; it does not infer a relationship. It may introduce null columns or type-suffixed columns if schemas don’t align; project<\/code> harmonizes them.<\/p>\n\n\n\n
                                                Exercise K05 \u2014 parse<\/code> an agreed application contract<\/h3>\n\n\n\n
                                                let Raw = datatable(Message:string)\n[\n  \"actor=lab.admin@asterretail.example src=198.51.100.23 action=privileged_login\",\n  \"actor=lab.user@asterretail.example src=203.0.113.99 action=read_config\"\n];\nRaw\n| parse Message with \"actor=\" Actor:string \" src=\" SourceIP:string \" action=\" Action:string\n| project Actor, SourceIP, Action\n<\/code><\/pre>\n\n\n\n
                                                Expected:<\/strong> Both actors\/IPs\/actions extracted. Change one record’s separator or key spelling: extraction can fail. Compare this with extract()<\/code> using a regex; choose based on source contract rather than trying to recover every malformed record silently.<\/p>\n\n\n\n
                                                Exercise K06 \u2014 mv-expand<\/code> and distinct<\/code><\/h3>\n\n\n\n
                                                print Actors=dynamic([\n  \"lab.admin@asterretail.example\",\n  \"lab.ops@asterretail.example\",\n  \"lab.admin@asterretail.example\"\n])\n| mv-expand Actor = Actors to typeof(string)\n| distinct Actor\n| order by Actor asc\n<\/code><\/pre>\n\n\n\n
                                                Expected:<\/strong> Two unique actors. Explain that mv-expand<\/code> can increase row volume and query cost.<\/p>\n\n\n\n
                                                Exercise K07 \u2014 join kind=leftouter<\/code> versus lookup<\/code><\/h3>\n\n\n\n
                                                let Findings = datatable(Actor:string, SourceIP:string)\n[\n  \"lab.admin@asterretail.example\", \"198.51.100.23\",\n  \"lab.user@asterretail.example\", \"203.0.113.99\"\n];\nlet Business = datatable(Actor:string, Owner:string, Criticality:string)\n[\n  \"lab.admin@asterretail.example\", \"Identity Team\", \"High\"\n];\nFindings\n| lookup kind=leftouter Business on Actor\n| project Actor, SourceIP, Owner, Criticality\n<\/code><\/pre>\n\n\n\n
                                                Expected:<\/strong> Two findings; unmatched user has empty enrichment. An unrecognized actor must not be fabricated as ‘low risk.’<\/p>\n\n\n\n
                                                Exercise K08 \u2014 Reduce many-to-many joins before operating on a security decision<\/h3>\n\n\n\n
                                                let Identity = datatable(Actor:string, SourceIP:string)\n[\n  \"adminA\", \"198.51.100.23\",\n  \"adminA\", \"198.51.100.23\"\n];\nlet Firewall = datatable(SourceIP:string, Decision:string)\n[\n  \"198.51.100.23\", \"deny\",\n  \"198.51.100.23\", \"deny\"\n];\nlet RawJoin = Identity | join kind=inner (Firewall) on SourceIP;\nRawJoin\n| summarize JoinedRows=count(), UniqueActors=dcount(Actor) by SourceIP\n<\/code><\/pre>\n\n\n\n
                                                Expected:<\/strong> Four joined rows from only two records on each side. Explain why metrics need clear event identity (and potentially summarize<\/code>, deduplication or arg_max<\/code>) before claiming an attack rate.<\/p>\n\n\n\n
                                                PASS D3-L05:<\/strong> Learner runs all eight examples, records expected\/actual counts, explains join<\/code> vs union<\/code>, demonstrates parsing failure, and identifies the four-row join amplification.<\/p>\n\n\n\n
                                                Common errors:<\/strong> Missing ;<\/code> after let<\/code>; TimeGenerated<\/code> silently lost in an alert query; data types mismatch in join keys; many-to-many expansion; union<\/code> used as correlation; dynamic array not expanded; no normalization of case\/whitespace for identity fields.<\/p>\n\n\n\n
                                                KQL reference:<\/strong> [R07].<\/p>\n\n\n\n
                                                \n\n\n\n
                                                D3-L06 \u2014 Correlate Linux and firewall data with a defensible time window (I06)<\/h2>\n\n\n\n
                                                Competency:<\/strong> Build a two-source KQL correlation against the actual Syslog<\/code> and CommonSecurityLog<\/code> tables and critique its assumptions.<\/p>\n\n\n\n
                                                A. Prepare evidence and inspect join keys<\/h3>\n\n\n\n
                                                  \n
                                                1. Verify that L02 produced a\u00a0Syslog<\/code>\u00a0row with\u00a0SENTINEL_D3_LAB<\/code>\u00a0and that L03 produced a parsed\u00a0CommonSecurityLog<\/code>\u00a0row with\u00a0DeviceVendor=AsterLab<\/code>.<\/li>\n\n\n\n
                                                2. In the Logs editor, run the query below; use a window that includes your bounded test. Do not reuse old Day 1\/2 events that have no shared identity keys.<\/li>\n\n\n\n
                                                3. Examine the parsed\u00a0LabActor<\/code>, source IP, and CEF\u00a0SourceUserName<\/code>; if parser output is missing, record it before correlating.<\/li>\n<\/ol>\n\n\n\n
                                                  let Linux = Syslog\n| where TimeGenerated >= ago(2h)\n| where SyslogMessage contains \"SENTINEL_D3_LAB\"\n| extend SourceIP = extract(@\"src=([0-9.]+)\", 1, SyslogMessage)\n| extend LabActor = extract(@\"actor=([^\\s]+)\", 1, SyslogMessage)\n| where isnotempty(SourceIP) and isnotempty(LabActor)\n| project LinuxTime=TimeGenerated, LinuxHost=Computer,\n          SourceIP, LabActor, LinuxRaw=SyslogMessage;\nlet Firewall = CommonSecurityLog\n| where TimeGenerated >= ago(2h)\n| where DeviceVendor == \"AsterLab\" and DeviceProduct == \"Firewall\"\n| where isnotempty(SourceIP)\n| project FirewallTime=TimeGenerated, SourceIP, SourceUserName,\n          DeviceAction, DeviceEventClassID;\nLinux\n| join kind=inner (Firewall) on SourceIP\n| where FirewallTime between (LinuxTime - 10m .. LinuxTime + 10m)\n| project LinuxTime, FirewallTime, LinuxHost, LabActor,\n          SourceIP, SourceUserName, DeviceAction, DeviceEventClassID\n| order by LinuxTime desc\n<\/code><\/pre>\n\n\n\n
                                                  Expected:<\/strong> At least one joined row when the two emitted records share source IP and are within ten minutes. If the messages were sent more than ten minutes apart, send one new bounded<\/em> pair after instructor approval and record the emission timestamps. There is no guaranteed fixed row count<\/strong> if a cohort has repeated the test; this is why you inspect evidence and add scope.<\/p>\n\n\n\n
                                                  B. Tighten the correlation<\/h3>\n\n\n\n
                                                  If SourceUserName<\/code> reliably parsed from suser<\/code>, add this condition after<\/strong> the time predicate:<\/p>\n\n\n\n
                                                  | where tolower(LabActor) == tolower(SourceUserName)\n<\/code><\/pre>\n\n\n\n
                                                  If the user field is blank, you cannot<\/strong> claim account-identity correlation\u2014only shared source-IP\/time evidence. Explain NAT\/shared proxy and time-skew limitations. Consider a unique event correlation ID for real integrations and vendor-specific parsing contracts.<\/p>\n\n\n\n
                                                  C. Convert the result into a compact detection candidate<\/h3>\n\n\n\n
                                                  Copy and run the following separately. Its TimeGenerated<\/code> is derived from actual source events and is suitable for a scheduled-rule candidate<\/em> after lab-specific testing. Not production-ready<\/strong> without source tuning, alert ownership, and peer review.<\/p>\n\n\n\n
                                                  let Linux = Syslog\n| where TimeGenerated >= ago(20m)\n| where SyslogMessage contains \"SENTINEL_D3_LAB\"\n| extend SourceIP = extract(@\"src=([0-9.]+)\", 1, SyslogMessage)\n| extend Account = extract(@\"actor=([^\\s]+)\", 1, SyslogMessage)\n| where isnotempty(SourceIP) and isnotempty(Account)\n| project LinuxTime=TimeGenerated, Account, SourceIP, Computer;\nlet Firewall = CommonSecurityLog\n| where TimeGenerated >= ago(20m)\n| where DeviceVendor == \"AsterLab\" and DeviceProduct == \"Firewall\"\n| project FirewallTime=TimeGenerated, SourceIP,\n          SourceUserName, DeviceAction;\nLinux\n| join kind=inner (Firewall) on SourceIP\n| where FirewallTime between (LinuxTime - 10m .. LinuxTime + 10m)\n| where isempty(SourceUserName) or tolower(Account) == tolower(SourceUserName)\n| summarize TimeGenerated=max(LinuxTime),\n            FirewallLastSeen=max(FirewallTime),\n            EvidencePairs=count(),\n            SampleAction=take_any(DeviceAction),\n            Host=take_any(Computer)\n          by Account, SourceIP\n| project TimeGenerated, Account, SourceIP, Host,\n          FirewallLastSeen, EvidencePairs, SampleAction\n| order by TimeGenerated desc\n<\/code><\/pre>\n\n\n\n
                                                  Annotation:<\/strong> The isempty(SourceUserName)<\/code> branch tolerates a missing CEF account but weakens attribution. For production-style high-fidelity rules, remove that branch and require an actually parsed matching account, after validating the parser and deciding what to do with missing identities. Do not treat this query as a confirmed attack detector: the injected records were fictional test logs.<\/p>\n\n\n\n
                                                  D. Evaluate a minimum three-case test set<\/h3>\n\n\n\n
                                                  Case<\/th>Test input<\/th>Desired query behavior<\/th>Why<\/th><\/tr><\/thead>
                                                  Positive P1<\/td>Syslog + CEF same source IP, within 10 minutes, actor matches (if provided)<\/td>Match<\/td>Two different telemetry sources agree<\/td><\/tr>
                                                  Negative N1<\/td>Syslog source IP different from CEF<\/td>No match<\/td>Join key differs<\/td><\/tr>
                                                  Negative N2<\/td>Same IP but 30+ minutes apart<\/td>No match<\/td>Time boundary rejected<\/td><\/tr>
                                                  Edge E1<\/td>Same IP, different CEF user<\/td>No match<\/strong> if strict actor equality enabled; otherwise explicitly flagged weak<\/td>Shared infrastructure ambiguity<\/td><\/tr>
                                                  Edge E2<\/td>Repeated test events<\/td>Possibly multiple pairs, then summarized<\/td>Join multiplicity<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                  Do not generate thousands of events for testing; if live time-bound cases are hard to replay safely, execute datatable()<\/code> variants as in L05 and separately label the real-path observation.<\/p>\n\n\n\n
                                                  PASS D3-L06:<\/strong> The KQL runs with live joined results or<\/strong> the instructor records a clearly marked alternate two-source evidence set. Learner states the join key and time window, demonstrates at least one negative test, and writes limitations. No source data, no PASS on ‘correlation demonstrated.’<\/p>\n\n\n\n
                                                  Sources:<\/strong> [R07], [R13].<\/p>\n\n\n\n
                                                  \n\n\n\n
                                                  D3-L07 \u2014 Governed watchlist creation and business-context enrichment (I07)<\/h2>\n\n\n\n
                                                  Competency:<\/strong> Turn a CSV reference list into contextual enrichment, control its lifecycle, avoid using watchlists as large-scale event storage.<\/p>\n\n\n\n
                                                  A. Build a tiny approved CSV file<\/h3>\n\n\n\n
                                                  Create a local UTF-8 text file named day3_privileged_accounts.csv<\/code> with exactly this content. This is embedded in the manual<\/em> so no separate download is required:<\/p>\n\n\n\n
                                                  UserPrincipalName,Owner,Criticality,ApprovedUntil,Comment\nlab.admin@asterretail.example,Identity Team,High,2026-12-31,Fictional lab privileged account\nlab.ops@asterretail.example,Cloud Operations,Medium,2026-12-31,Fictional operations account\nlab.breakglass@asterretail.example,Security Lead,Critical,2026-12-31,Fictional emergency account\n<\/code><\/pre>\n\n\n\n
                                                    \n
                                                  1. Open the file in a plain-text editor, confirm header names, no extra comments\/blank header lines, and no real employee data.<\/li>\n\n\n\n
                                                  2. Confirm the owner\/steward, source-of-truth, change approval, review cadence, and removal date. Watchlists are reference data; they are not a master identity directory. [R08]<\/li>\n<\/ol>\n\n\n\n
                                                    B. Create the watchlist in the correct Sentinel workspace<\/h3>\n\n\n\n
                                                      \n
                                                    1. In Defender portal go to\u00a0Microsoft Sentinel > Configuration > Watchlist<\/strong>.<\/li>\n\n\n\n
                                                    2. Choose\u00a0+ New<\/strong>\u00a0(or equivalent\u00a0Create<\/strong>\u00a0action shown in the current portal).<\/li>\n\n\n\n
                                                    3. Enter Name:\u00a0Day 3 Privileged Accounts<\/code>, Alias:\u00a0day3_privileged_accounts<\/code><\/strong>, Description:\u00a0Synthetic authorized training reference list<\/code>; save the owner in the class ledger.<\/li>\n\n\n\n
                                                    4. On\u00a0Source<\/strong>, choose\u00a0Local file<\/strong>, upload\u00a0day3_privileged_accounts.csv<\/code>, and indicate that the header is on line 1 (0 rows preceding the header).<\/li>\n\n\n\n
                                                    5. Choose\u00a0SearchKey =\u00a0UserPrincipalName<\/code><\/strong>\u00a0(the column used to join events to this list).<\/li>\n\n\n\n
                                                    6. Review and create. Wait for the watchlist to be queryable; a successful UI notification does not guarantee immediate query visibility. [R09]<\/li>\n<\/ol>\n\n\n\n
                                                      C. Verify the list, then enrich a live correlation<\/h3>\n\n\n\n
                                                      _GetWatchlist('day3_privileged_accounts')\n| project SearchKey, UserPrincipalName, Owner, Criticality, ApprovedUntil\n| order by SearchKey asc\n<\/code><\/pre>\n\n\n\n
                                                      Expected:<\/strong> Three synthetic entries, each with correct SearchKey<\/code> and owner\/criticality. The watchlist may have cached refresh behavior and an internal TimeGenerated<\/code> timestamp; do not interpret watchlist TimeGenerated<\/code> as when the account became privileged<\/strong>. [R08]<\/p>\n\n\n\n
                                                      Then run this live<\/strong> enrichment against Syslog (doesn’t require CEF to be present):<\/p>\n\n\n\n
                                                      let Privileged = _GetWatchlist('day3_privileged_accounts')\n| project JoinKey=tolower(SearchKey), Owner, Criticality, ApprovedUntil;\nSyslog\n| where TimeGenerated >= ago(2h)\n| where SyslogMessage contains \"SENTINEL_D3_LAB\"\n| extend Account=extract(@\"actor=([^\\s]+)\", 1, SyslogMessage)\n| where isnotempty(Account)\n| extend JoinKey=tolower(Account)\n| lookup kind=leftouter Privileged on JoinKey\n| project TimeGenerated, Computer, Account, Owner, Criticality,\n          ApprovedUntil, SyslogMessage\n| order by TimeGenerated desc\n<\/code><\/pre>\n\n\n\n
                                                      Expected:<\/strong> Fictional lab.admin@...<\/code> event enriches to Owner = Identity Team<\/code>, Criticality = High<\/code>. If the watchlist has no match, output may have null enrichment. Null is not the same as approved unprivileged<\/em>.<\/p>\n\n\n\n
                                                      D. Add controlled review logic (not an implicit permanent bypass)<\/h3>\n\n\n\n
                                                        \n
                                                      1. Ask the learner: Does\u00a0ApprovedUntil<\/code>\u00a0mean the account is safe?\u00a0No.<\/strong>\u00a0It might mean a temporary approval period, not an exception to detect suspicious behavior.<\/li>\n\n\n\n
                                                      2. Discuss when an\u00a0allowlist<\/strong>\u00a0is legitimate: signed ownership, specific behavior\/context, scope, expiry, audit trail; avoid broad ‘ignore all activity from this user’ filters.<\/li>\n\n\n\n
                                                      3. For an actual time-bound review example:<\/li>\n<\/ol>\n\n\n\n
                                                        _GetWatchlist('day3_privileged_accounts')\n| extend ApprovalEnd=todatetime(ApprovedUntil)\n| extend ApprovalCurrent=isnotnull(ApprovalEnd) and ApprovalEnd >= now()\n| project SearchKey, Owner, Criticality, ApprovalEnd, ApprovalCurrent\n<\/code><\/pre>\n\n\n\n
                                                        This does not<\/strong> change watchlist rows and does not suppress detections; it only derives current approval context.<\/p>\n\n\n\n
                                                        PASS D3-L07:<\/strong> Watchlist exists, _GetWatchlist()<\/code> returns the expected records, a real or separately labeled synthetic event is enriched with the correct owner\/criticality, and a stewardship\/expiry policy is documented.<\/p>\n\n\n\n
                                                        Troubleshooting:<\/strong> invalid file format; alias case; header misspelling; wrong SearchKey; wrong workspace; tolower()<\/code> mismatch; newly created list not yet queryable; stale\/missing reference owners.<\/p>\n\n\n\n
                                                        Sources:<\/strong> [R08], [R09].<\/p>\n\n\n\n
                                                        \n\n\n\n
                                                        D3-L08 \u2014 Evaluate threat-intelligence indicators safely (I08)<\/h2>\n\n\n\n
                                                        Competency:<\/strong> Recognize indicator lifecycle, expiry, confidence, source reliability and false matches; use TI as context<\/em>, not a blanket verdict. No real malicious IOC and no external TI subscription are needed for the required exercise.<\/strong><\/p>\n\n\n\n
                                                        A. Discover the correct 2026 TI experience<\/h3>\n\n\n\n
                                                          \n
                                                        1. In Defender portal, locate\u00a0Microsoft Sentinel > Threat management > Threat intelligence<\/strong>\u00a0(navigation may also surface TI under an investigation-oriented Defender experience, depending on onboarded services). Check the workspace\/tenant context.<\/li>\n\n\n\n
                                                        2. Record which approved TI connectors and feature licenses are already available. Do\u00a0not<\/strong>\u00a0subscribe to a feed, register credentials or import public malicious infrastructure for the training just to make a query return rows.<\/li>\n\n\n\n
                                                        3. If an approved feed already exists, check that the workspace contains\u00a0ThreatIntelIndicators<\/code><\/strong>. This is the modern indicator table; the old\u00a0ThreatIntelligenceIndicator<\/code>\u00a0ingestion was retired in 2025. The old Threat Intelligence Platforms (TIP) connector was slated to stop collecting in June 2026; current new integrations should use supported TIP upload API or TAXII methods, approved by the TI owner. [R10], [R11]<\/li>\n\n\n\n
                                                        4. If the table is available, query its actual schema. This is\u00a0read-only<\/strong>:<\/li>\n<\/ol>\n\n\n\n
                                                          ThreatIntelIndicators\n| where TimeGenerated >= ago(30d)\n| summarize arg_max(TimeGenerated, *) by Id\n| where IsDeleted == false and Revoked == false and IsActive == true\n| project TimeGenerated, Id, ObservableKey, ObservableValue,\n          Confidence, ValidFrom, ValidUntil, Pattern, Tags\n| take 25\n<\/code><\/pre>\n\n\n\n
                                                          Important:<\/strong> The IsActive<\/code> property and expiry handling are related but not identical. In an operational TI match, additionally consider the current time against validity fields and the exact ObservableKey<\/code>\/pattern semantics. A numeric Confidence<\/code> value is not a mathematically calibrated probability of attack.<\/p>\n\n\n\n
                                                            \n
                                                          1. If the table does not exist, or is empty due to missing entitlements\/connectors, record\u00a0not available in lab<\/strong>\u00a0and complete B. Do not fabricate a live TI match.<\/li>\n<\/ol>\n\n\n\n
                                                            B. Self-contained synthetic TI matching exercise<\/h3>\n\n\n\n
                                                            Run this query independently; it uses fictional records and stays inside the query engine:<\/p>\n\n\n\n
                                                            let Network = datatable(TimeGenerated:datetime, SourceIP:string, Action:string)\n[\n  datetime(2026-11-01T09:06:00Z), \"198.51.100.23\", \"deny\",\n  datetime(2026-11-01T09:08:00Z), \"203.0.113.99\", \"allow\"\n];\nlet Indicators = datatable(IndicatorIP:string, Confidence:int,\n                           ValidUntil:datetime, Revoked:bool)\n[\n  \"198.51.100.23\", 80, datetime(2026-12-31T00:00:00Z), false,\n  \"203.0.113.99\",  90, datetime(2026-01-01T00:00:00Z), true\n];\nNetwork\n| lookup kind=leftouter Indicators on $left.SourceIP == $right.IndicatorIP\n| extend IndicatorUsable = isnotnull(IndicatorIP)\n                    and Revoked == false\n                    and ValidUntil > datetime(2026-11-01T00:00:00Z)\n| project TimeGenerated, SourceIP, Action, Confidence,\n          ValidUntil, Revoked, IndicatorUsable\n<\/code><\/pre>\n\n\n\n
                                                            Expected:<\/strong> 198.51.100.23<\/code> is a fictional<\/em> valid indicator in the simulated snapshot, while 203.0.113.99<\/code> is not usable because revoked\/expired. The test is deliberately anchored to the scenario date<\/strong> so its expected output remains reproducible. In live TI queries use now()<\/code> and actual indicator source field mappings.<\/p>\n\n\n\n
                                                            C. Analyst decision worksheet<\/h3>\n\n\n\n
                                                            Question<\/th>Required answer<\/th><\/tr><\/thead>
                                                            Is an IP match sufficient to label a person malicious?<\/td>No; NAT, infrastructure sharing, stale indicators and spoofed logs must be assessed<\/td><\/tr>
                                                            What makes an indicator actionable?<\/td>Provenance, accuracy, observable type, expiry, confidence, relevant behavior and ownership<\/td><\/tr>
                                                            How do you handle an expired indicator?<\/td>Filter from active matching or clearly label historical context; do not silently enforce<\/td><\/tr>
                                                            What is the difference between TI and a watchlist?<\/td>TI is threat-context evidence with indicator lifecycle; watchlist may be business reference data<\/td><\/tr>
                                                            Where is the audit record?<\/td>Feed\/operator provenance, imported indicator ID, action taken, UTC timestamps, review decision<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                            PASS D3-L08:<\/strong> Learner demonstrates correct 2026 table\/connector awareness, executes synthetic validity checks, states matching limitations, and writes one justified intelligence disposition. Optional live bonus:<\/strong> approved feed\/table actually returns data.<\/p>\n\n\n\n
                                                            Sources:<\/strong> [R10], [R11], [R17].<\/p>\n\n\n\n
                                                            \n\n\n\n
                                                            D3-L09 \u2014 Inspect User and Entity Behavior Analytics (UEBA) context (I09)<\/h2>\n\n\n\n
                                                            Competency:<\/strong> Determine when UEBA enrichments can strengthen an investigation, what scores mean, and what must not<\/strong> be inferred from an anomaly.<\/p>\n\n\n\n
                                                            A. Confirm availability and roles before<\/em> enabling anything<\/h3>\n\n\n\n
                                                              \n
                                                            1. Ask the instructor whether UEBA is already enabled in the training workspace and whether identity-signal sources are present. Do not turn it on without approval: it creates additional data and can increase storage cost.<\/li>\n\n\n\n
                                                            2. If authorized to enable UEBA, confirm the enabling principal has\u00a0Microsoft Entra Security Administrator<\/strong>\u00a0or equivalent tenant permissions\u00a0plus<\/em>\u00a0the required Azure RBAC, and that resource locks do not block changes. Merely viewing UEBA data does\u00a0not<\/strong>\u00a0require these special enablement roles. [R12]<\/li>\n\n\n\n
                                                            3. In Defender portal go to\u00a0System > Settings > Microsoft Sentinel > UEBA<\/strong>. Under current documented experience, turn on UEBA only with explicit approval, select only intended directory\/source options, and choose\u00a0Connect<\/strong>.<\/li>\n\n\n\n
                                                            4. For anomaly detection (if authorized), go to\u00a0Settings > Microsoft Sentinel > SIEM workspaces<\/strong>, select the correct workspace, open\u00a0Anomalies<\/strong>, and toggle\u00a0Detect Anomalies<\/strong>\u00a0if available and approved.<\/li>\n\n\n\n
                                                            5. For supported sources, verify the actual connector dependencies and data readiness.\u00a0A fictional CEF product from L03 is not automatically a supported UEBA input.<\/strong>\u00a0Microsoft documents only supported vendor\/source schemas. [R12]<\/li>\n<\/ol>\n\n\n\n
                                                              B. Inspect available UEBA logs (read-only)<\/h3>\n\n\n\n
                                                              If BehaviorAnalytics<\/code> is present:<\/p>\n\n\n\n
                                                              BehaviorAnalytics\n| where TimeGenerated >= ago(7d)\n| project TimeGenerated, UserPrincipalName, ActivityType,\n          SourceIPAddress, EventSource, InvestigationPriority,\n          ActivityInsights\n| order by InvestigationPriority desc, TimeGenerated desc\n| take 25\n<\/code><\/pre>\n\n\n\n
                                                              If the table exists but no rows are returned, that is an observable result\u2014not proof UEBA is broken. Verify enabled sources, permissions, volume and whether any events actually qualify for profiling. If the table is unavailable, use the synthetic scoring discussion in C and record that live UEBA was not tested.<\/p>\n\n\n\n
                                                              C. Interpret the scores without overclaiming<\/h3>\n\n\n\n
                                                              Microsoft distinguishes BehaviorAnalytics.InvestigationPriority<\/code> (0\u201310)<\/strong> from Anomalies.AnomalyScore<\/code> (0\u20131)<\/strong>. They describe different levels of unusual behavior, and a high score is not a conviction. [R18]<\/p>\n\n\n\n
                                                              Synthetic interpretation table:<\/p>\n\n\n\n
                                                              Fictional evidence<\/th>Score<\/th>Analyst response<\/th><\/tr><\/thead>
                                                              Admin launches approved first-time service change<\/td>Investigation priority 8\/10<\/td>Validate change request and relevant roles; unusual does not prove malicious<\/td><\/tr>
                                                              Multiple independently suspicious events form a new pattern<\/td>Anomaly score 0.91\/1<\/td>Prioritize corroboration, isolate time window and evidence, escalate if justified<\/td><\/tr>
                                                              Routine nightly automation looks normal<\/td>1\/10<\/td>Still check source fidelity and whether a policy violation occurred<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                                \n
                                                              1. Write one alternative benign explanation for a high score and one serious concern a low score would not rule out.<\/li>\n\n\n\n
                                                              2. State where UEBA might add useful context to L06’s correlation (identity profile, peer context, historical behavior).<\/li>\n\n\n\n
                                                              3. Note why unsupported or thin telemetry can produce a misleading risk picture.<\/li>\n<\/ol>\n\n\n\n
                                                                PASS D3-L09:<\/strong> Documented availability\/approval check, live query result if supported<\/strong>, correct comparison of two score types, and a reasoned analyst statement. Do not block progression<\/strong> because UEBA is unavailable if the substitute exercise is completed; mark optional live feature NOT VERIFIED.<\/p>\n\n\n\n
                                                                Sources:<\/strong> [R12], [R18], [R19].<\/p>\n\n\n\n
                                                                \n\n\n\n
                                                                D3-L10 \u2014 Publish and validate a custom scheduled analytics rule (I10)<\/h2>\n\n\n\n
                                                                Competency:<\/strong> Convert the real cross-source query into a working detection, map entities and useful custom details, control its lookback and alert generation, and demonstrate the alert \u2192 incident path. This lab must be performed in a dedicated training workspace<\/strong> or by an instructor with approved write privileges.<\/p>\n\n\n\n
                                                                A. Pre-publish validation and safety checks<\/h3>\n\n\n\n
                                                                  \n
                                                                1. Confirm that L06’s\u00a0compact candidate query<\/strong>\u00a0runs in the intended Log Analytics workspace, returns rows for recent\u00a0actual<\/em>\u00a0test logs, includes a legitimate\u00a0TimeGenerated:datetime<\/code>, and returns the columns\u00a0Account<\/code>,\u00a0SourceIP<\/code>,\u00a0Host<\/code>,\u00a0EvidencePairs<\/code>, and\u00a0SampleAction<\/code>.<\/li>\n\n\n\n
                                                                2. If L03’s CEF source is unavailable,\u00a0do not insert a synthetic\u00a0datatable()<\/code>\u00a0into a production-like scheduled analytics rule<\/strong>. Either (a) complete the rule-authoring walkthrough as a non-deployed design exercise or (b) ask the instructor to provide a separate, approved real data source and rewrite the query for that source. Mark operational rule PASS only after real evidence exists.<\/li>\n\n\n\n
                                                                3. Confirm that the rule uniquely matches\u00a0lab markers<\/strong>\u00a0and\u00a0AsterLab<\/code>\u00a0test device data. No broad\u00a0SecurityEvent<\/code>\/SigninLogs<\/code>\u00a0queries or real privileged accounts should be alerted on by this exercise.<\/li>\n\n\n\n
                                                                4. Save the exact tested query in the instructor evidence pack. Record the last query result UTC timestamp.<\/li>\n<\/ol>\n\n\n\n
                                                                  B. Create the scheduled query rule via Defender portal<\/h3>\n\n\n\n
                                                                    \n
                                                                  1. Open\u00a0Microsoft Sentinel > Configuration > Analytics<\/strong>.<\/li>\n\n\n\n
                                                                  2. Select\u00a0+ Create > Scheduled query rule<\/strong>. [R13]<\/li>\n\n\n\n
                                                                  3. In the general stage, enter:\n
                                                                      \n
                                                                    • Name:<\/strong>\u00a0SENTINEL-D3-LAB-Privileged-Source-Correlation<\/code><\/li>\n\n\n\n
                                                                    • Description:<\/strong>\u00a0TRAINING ONLY: synthetic Linux plus CEF source-IP\/time correlation; test marker required; delete after lab<\/code><\/li>\n\n\n\n
                                                                    • Severity:<\/strong>\u00a0Low<\/code>\u00a0or\u00a0Informational<\/code>\u00a0per instructor policy,\u00a0not<\/em>\u00a0High simply because the fictional account is called admin<\/li>\n\n\n\n
                                                                    • Status:<\/strong>\u00a0Disabled<\/code>\u00a0until the query\/settings are checked; then enable for the bounded demonstration<\/li>\n\n\n\n
                                                                    • MITRE ATT&CK:<\/strong>\u00a0only choose tactics\/techniques for which the scenario supports an explanatory mapping; absence of mapping is preferable to inaccurate labels<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                                                                    • On\u00a0Set rule logic<\/strong>, paste the validated\u00a0candidate KQL from D3-L06 section C<\/strong>, adjusted only for actual test field mappings.<\/li>\n\n\n\n
                                                                    • Entity mapping<\/strong>\u00a0(if supported by your rule editor):\n
                                                                        \n
                                                                      • Account<\/code>\u00a0entity \u2192 identifier\u00a0FullName<\/strong>\u00a0\u2192 column\u00a0Account<\/code>\u00a0(confirm email-string handling in your tenant)<\/li>\n\n\n\n
                                                                      • IP<\/code>\u00a0entity \u2192 identifier\u00a0Address<\/strong>\u00a0\u2192 column\u00a0SourceIP<\/code><\/li>\n\n\n\n
                                                                      • Host<\/code>\u00a0entity \u2192\u00a0HostName<\/strong>\u00a0or current supported host identifier \u2192 column\u00a0Host<\/code>,\u00a0if the current wizard offers a compatible mapping<\/em>. Record any omitted mapping rather than guessing.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                                                                      • Custom details:<\/strong>\u00a0map useful scalar outputs such as\u00a0EvidencePairs<\/code>\u00a0and\u00a0SampleAction<\/code>, avoiding secrets or raw log payloads. Keep descriptions short.<\/li>\n\n\n\n
                                                                      • Query scheduling:<\/strong>\u00a0use\u00a0Run query every 5 minutes<\/strong>,\u00a0Lookup data from the last 20 minutes<\/strong>, which satisfies the current documented condition that lookback \u2265 interval. Microsoft describes minimum 5-minute intervals for scheduled queries; the engine can introduce processing offset\/ingestion delay. [R14]<\/li>\n\n\n\n
                                                                      • Alert threshold:<\/strong>\u00a0Generate alert when results > 0<\/strong>; select\u00a0Group all events into a single alert<\/strong>\u00a0for the lab to prevent a storm.<\/li>\n\n\n\n
                                                                      • Use\u00a0Test with current data<\/strong>\u00a0if shown, and document the result. Simulation is useful but\u00a0does not constitute proof of an alert or incident<\/strong>.<\/li>\n\n\n\n
                                                                      • Incident settings:<\/strong>\u00a0leave\u00a0Create incidents from alerts<\/strong>\u00a0enabled in a Sentinel-on-Defender environment. For the training rule, prefer default\/simple grouping until the instructor authorizes a change; read the available options to avoid accidental incident floods. [R13], [R14]<\/li>\n\n\n\n
                                                                      • Review any automated response stage without adding Day 4 playbooks. Create the rule; confirm it appears under active rules with the expected name.<\/li>\n<\/ol>\n\n\n\n
                                                                        C. Prove the actual alert and incident chain<\/h3>\n\n\n\n
                                                                          \n
                                                                        1. If the query has recently matching rows, enable the rule and wait for its actual scheduled evaluation. If data ages out of the 20-minute lookback before the first run, have the instructor send\u00a0one fresh bounded Syslog+CEF pair<\/strong>\u00a0as in L02\/L03 and record the UTC time. Do not increase collection volume impulsively.<\/li>\n\n\n\n
                                                                        2. In the\u00a0Defender portal incident queue<\/strong>\u00a0\/ relevant Microsoft Sentinel incident experience, search for the training rule or its associated alert. Depending on tenant\/portal edition, incidents may be visible under unified Incidents, with case-preview options available separately. Record the actual label used by the tenant.<\/li>\n\n\n\n
                                                                        3. Open the incident. Confirm the alert was created by\u00a0SENTINEL-D3-LAB-Privileged-Source-Correlation<\/code>, the evidence time is recent, and intended mapped entities\/custom details are visible.<\/li>\n\n\n\n
                                                                        4. Record: rule name, run\/test UTC timestamps, alert identifier, incident identifier, mapped IP\/account, severity, and any missing fields.<\/li>\n\n\n\n
                                                                        5. If no incident appears: verify first that a\u00a0real alert exists<\/strong>, then check incident creation settings, query matches during scheduled lookback, actual query execution, portal filters, RBAC and integration mode. A search returning zero results for a UI view is not proof the rule never executed.<\/li>\n<\/ol>\n\n\n\n
                                                                          Mandatory proof chain:<\/strong><\/p>\n\n\n\n
                                                                          Actual Linux Syslog row\n   + actual parsed CEF row\n       \u2193\nTime-bounded KQL result with TimeGenerated\n       \u2193\nEnabled scheduled analytics rule (name + settings)\n       \u2193\nCreated alert (real ID)\n       \u2193\nCreated Microsoft Defender \/ Sentinel incident (real ID)\n<\/code><\/pre>\n\n\n\n
                                                                          PASS D3-L10:<\/strong> Instructor has evidence of every link<\/strong> of this chain and can inspect entity mapping. PARTIAL:<\/strong> saved\/enabled rule but no alert\/incident. BLOCKED:<\/strong> missing role\/permissions\/second source; leave the rule disabled and record the reason.<\/p>\n\n\n\n
                                                                          Failure tips:<\/strong> Source events too old; no CEF table; empty actor; facility filtered; event timestamp skew; TimeGenerated<\/code> absent in final projection; query is too costly; rule set Disabled; scheduled window excludes events; rule fails to create incidents; wrong Defender queue view. See L14.<\/p>\n\n\n\n
                                                                          Sources:<\/strong> [R13], [R14], [R20].<\/p>\n\n\n\n
                                                                          \n\n\n\n
                                                                          D3-L11 \u2014 Tune rule fidelity, grouping, ownership and false-positive behavior (I11)<\/h2>\n\n\n\n
                                                                          Competency:<\/strong> Show measured improvements without suppressing genuine signal. Change one factor at a time; maintain a before\/after test matrix.<\/p>\n\n\n\n
                                                                          A. Establish the baseline<\/h3>\n\n\n\n
                                                                            \n
                                                                          1. Take a screenshot or record the L10 rule query, evaluation interval, lookback, threshold, event grouping, incident settings, alert count and false-positive observations.<\/li>\n\n\n\n
                                                                          2. Determine how many\u00a0distinct<\/strong>\u00a0lab source events underlie one detection (do not use joined row count as the event count; L05 showed why joins multiply).<\/li>\n\n\n\n
                                                                          3. Record the current rule name\/version in the course log and identify an owner for tuning changes.<\/li>\n<\/ol>\n\n\n\n
                                                                            B. Introduce an approved benign comparator<\/h3>\n\n\n\n
                                                                            The instructor may emit one<\/strong> extra harmless syslog message with a separate fictional maintenance identity. It should not<\/strong> be used to bypass policy; it is there to evaluate relevance and false positives.<\/p>\n\n\n\n
                                                                            logger -p local5.warning -t SENTINEL_D3 \\\n  'SENTINEL_D3_LAB actor=lab.maintenance@asterretail.example src=192.0.2.44 outcome=success event=authorized_maintenance'\n<\/code><\/pre>\n\n\n\n
                                                                              \n
                                                                            1. Confirm this message reached Syslog.<\/li>\n\n\n\n
                                                                            2. Observe that the current\u00a0two-source correlated rule should not trigger from Syslog alone<\/strong>\u00a0without matching CEF evidence. If it does, investigate the query rather than writing a broad exception.<\/li>\n\n\n\n
                                                                            3. In a self-contained synthetic query, create a matching firewall event for maintenance and test whether a\u00a0scoped<\/strong>\u00a0documented maintenance exception would be justified. This avoids generating another live alert unnecessarily.<\/li>\n<\/ol>\n\n\n\n
                                                                              C. Create an explicit decision table<\/h3>\n\n\n\n
                                                                              Test ID<\/th>Source conditions<\/th>Desired handling<\/th>Expected lesson<\/th><\/tr><\/thead>
                                                                              P1<\/td>Lab admin and CEF match; no change ticket<\/td>Alert \/ triage<\/td>Correlated signal worthy of review<\/td><\/tr>
                                                                              P2<\/td>Same signal, novel source, repeated evidence<\/td>Review; possibly higher severity after corroboration<\/td>Not necessarily one alert per event<\/td><\/tr>
                                                                              N1<\/td>Syslog only<\/td>No cross-source alert<\/td>A source-only event is not this detector’s target<\/td><\/tr>
                                                                              N2<\/td>Different IP \/ outside time window<\/td>No alert<\/td>Avoid unrelated joins<\/td><\/tr>
                                                                              B1<\/td>Approved maintenance identity, valid ticket\/time<\/td>Possible documented scoped exception<\/td>No unconditional identity allowlist<\/td><\/tr>
                                                                              E1<\/td>Parser fails to populate actor<\/td>No high-fidelity account conclusion<\/td>Data-quality dependency<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                                              D. Apply a narrow, reversible refinement<\/h3>\n\n\n\n
                                                                                \n
                                                                              1. Prefer a strict actor match (when CEF parsed\u00a0SourceUserName<\/code>\u00a0is demonstrably present) instead of the weakened L06 branch:<\/li>\n<\/ol>\n\n\n\n
                                                                                \/\/ Use this as a replacement predicate in the correlated query\n| where isnotempty(SourceUserName)\n| where tolower(Account) == tolower(SourceUserName)\n<\/code><\/pre>\n\n\n\n
                                                                                  \n
                                                                                1. Consider excluding\u00a0only approved maintenance action types within a real change window<\/strong>. An example of the\u00a0logical requirement<\/em>, not a copy-paste production filter:<\/li>\n<\/ol>\n\n\n\n
                                                                                  EXCLUDE ONLY IF:\n  account is in governed maintenance reference data\n  AND change ID matches an approved ticket\n  AND event UTC time is inside authorized start\/end\n  AND the behavior actually matches that change's permitted scope\n  AND detection owners have approved the exception\n<\/code><\/pre>\n\n\n\n
                                                                                    \n
                                                                                  1. Re-run both positive and negative tests in the query editor. If the positive case disappears after strict account matching, investigate whether missing CEF parsing\u2014not benign behavior\u2014caused it.<\/li>\n\n\n\n
                                                                                  2. Update the rule in the approved lab only after showing the test evidence. Preserve previous query\/version, and document rollback.<\/li>\n\n\n\n
                                                                                  3. In rule configuration review\u00a0alert threshold<\/strong>,\u00a0event grouping<\/strong>,\u00a0incident grouping<\/strong>, and suppression options. These have distinct semantics: suppressing rule evaluations after an alert is not the same as excluding benign records in KQL. Avoid both alert storms and blind intervals. [R14]<\/li>\n\n\n\n
                                                                                  4. Record actual incident dispositions and owner-hand-off convention (for example, New \u2192 Active; then evidence-based classification), without using automatic closure for a security-critical situation.<\/li>\n<\/ol>\n\n\n\n
                                                                                    E. Quantify the effect carefully<\/h3>\n\n\n\n
                                                                                    Report observed<\/strong> values rather than invented industry benchmarks:<\/p>\n\n\n\n
                                                                                    Measure<\/th>Before<\/th>After<\/th>Interpretation<\/th><\/tr><\/thead>
                                                                                    Positive test cases detected<\/td>___\/___<\/code><\/td>___\/___<\/code><\/td>Should not lose true test cases<\/td><\/tr>
                                                                                    Negative test cases alerted<\/td>___\/___<\/code><\/td>___\/___<\/code><\/td>Should decrease or stay zero<\/td><\/tr>
                                                                                    Distinct source events<\/td>___<\/code><\/td>___<\/code><\/td>Dedup\/identity limitations recorded<\/td><\/tr>
                                                                                    Alerts \/ test window<\/td>___<\/code><\/td>___<\/code><\/td>Not a substitute for accuracy<\/td><\/tr>
                                                                                    Known false positives<\/td>___<\/code><\/td>___<\/code><\/td>Must be documented examples<\/td><\/tr>
                                                                                    Mean time to disposition in lab<\/td>___<\/code><\/td>___<\/code><\/td>Not a production SOC SLA<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                                                    PASS D3-L11:<\/strong> One documented, reversible change with before\/after positive and<\/em> negative evidence, clear source quality assumptions and a rollback plan. FAIL:<\/strong> \u201cWe filtered the admin account entirely, so noise is gone.\u201d<\/p>\n\n\n\n
                                                                                    Sources:<\/strong> [R13], [R14], [R21].<\/p>\n\n\n\n
                                                                                    \n\n\n\n
                                                                                    D3-L12 \u2014 Create non-playbook incident automation: safe tag + assignment (I12)<\/h2>\n\n\n\n
                                                                                    Competency:<\/strong> Scope low-risk automation to this one training rule<\/strong>, test that a real incident is tagged\/assigned, and avoid loops or unintended cases. This lab deliberately excludes Logic Apps\/playbooks, account disabling, endpoint isolation, network blocks and notifications to external users<\/strong> (covered in Day 4 only).<\/p>\n\n\n\n
                                                                                    A. Preflight: review the trigger\/action combinations<\/h3>\n\n\n\n
                                                                                      \n
                                                                                    1. Open\u00a0Microsoft Sentinel > Configuration > Automation<\/strong>\u00a0in the Defender portal.<\/li>\n\n\n\n
                                                                                    2. Select\u00a0Create > Automation rule<\/strong>. [R15]<\/li>\n\n\n\n
                                                                                    3. Choose\u00a0When incident is created<\/strong>\u00a0(or the currently available matching creation trigger) so you can use\u00a0Add tags<\/strong>,\u00a0Assign owner<\/strong>, and possibly\u00a0Change status<\/strong>. Do\u00a0not<\/strong>\u00a0choose\u00a0When alert is created<\/strong>\u00a0if the intent is incident metadata: Microsoft documents\u00a0Run playbook<\/strong>\u00a0as its available action on the basic alert trigger, not arbitrary incident fields. [R15]<\/li>\n\n\n\n
                                                                                    4. Decide on the\u00a0exact analytic rule name<\/strong>\u00a0condition, preferring\u00a0Analytic rule name<\/strong>\u00a0rather than just an incident title, since Defender can normalize or modify titles. If a different condition UI appears, record the actual supported condition and avoid widening the scope.<\/li>\n\n\n\n
                                                                                    5. Select an actual allowed SOC owner. A display name typed without a valid principal may be rejected or cause a rule error.<\/li>\n<\/ol>\n\n\n\n
                                                                                      B. Configure a reversible rule<\/h3>\n\n\n\n
                                                                                      Use the following desired configuration, adapting field names to the wizard when required:<\/p>\n\n\n\n
                                                                                      Property<\/th>Intended Day 3 setting<\/th><\/tr><\/thead>
                                                                                      Name<\/td>SENTINEL-D3-LAB-Tag-And-Assign<\/code><\/td><\/tr>
                                                                                      Trigger<\/td>When incident is created<\/strong><\/td><\/tr>
                                                                                      Condition<\/td>Analytic rule name<\/strong> contains SENTINEL-D3-LAB-Privileged-Source-Correlation<\/code><\/td><\/tr>
                                                                                      Action 1<\/td>Add tag TRAINING-D3-INTERMEDIATE<\/code><\/td><\/tr>
                                                                                      Action 2<\/td>Assign owner a real designated instructor \/ SOC lab user<\/strong><\/td><\/tr>
                                                                                      Action 3 (optional)<\/td>Set status Active<\/code> only if instructor’s workflow allows it<\/td><\/tr>
                                                                                      Order \/ expiration<\/td>Explicitly scope\/order it; select expiration\/disable at cleanup where supported<\/td><\/tr>
                                                                                      Actions deliberately omitted<\/td>Run playbook, close incident, email outside lab, disable account, block IP<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                                                        \n
                                                                                      1. Save the automation rule and verify that it appears enabled\u00a0only<\/strong>\u00a0for the intended lab scope.<\/li>\n\n\n\n
                                                                                      2. To test a\u00a0creation<\/strong>\u00a0trigger, generate\u00a0one new<\/strong>\u00a0bounded matched Syslog\/CEF pair after ensuring the rule was created and that the scheduled analytics rule is enabled. Existing incidents do\u00a0not<\/strong>\u00a0retroactively fire a newly created creation trigger.<\/li>\n\n\n\n
                                                                                      3. Wait for an actual\u00a0new<\/strong>\u00a0incident. Inspect its tag and owner; also inspect the automation execution\/audit information where available.<\/li>\n\n\n\n
                                                                                      4. If the same incident is grouped with an earlier one rather than a new incident being created, the creation trigger may not fire. Record the actual grouping behavior and arrange a controlled new-incident scenario if the training workspace allows it.<\/li>\n\n\n\n
                                                                                      5. Test the negative path: an incident from an\u00a0unrelated<\/strong>\u00a0rule must not receive the training tag\/owner because of this automation rule. Do not generate an unrelated production incident; instructor may use an already existing synthetic lab case or a documented rule-condition inspection.<\/li>\n\n\n\n
                                                                                      6. Write a rollback\/disable action and turn off the automation immediately after the test if the cohort does not need it for the capstone.<\/li>\n<\/ol>\n\n\n\n
                                                                                        C. Failure cases and troubleshooting<\/h3>\n\n\n\n
                                                                                        Symptom<\/th>Check first<\/th>Do not do<\/th><\/tr><\/thead>
                                                                                        Rule never fired<\/td>New incident created after<\/strong> automation? condition matches actual analytics rule name?<\/td>Make an unrestricted rule<\/td><\/tr>
                                                                                        No owner assigned<\/td>Valid permitted principal? connector\/workspace RBAC?<\/td>Give Global Admin to everyone<\/td><\/tr>
                                                                                        Tag applied to wrong incidents<\/td>Scope, condition, rule order, case-sensitive assumptions<\/td>Ignore collateral tagging<\/td><\/tr>
                                                                                        Multiple updates\/re-triggering<\/td>Using updated trigger? update loop? idempotence and conditions<\/td>Use repeated loops as test<\/td><\/tr>
                                                                                        Action unavailable<\/td>Alert vs incident trigger differences; preview conditions<\/td>Assume portal is broken<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                                                        PASS D3-L12:<\/strong> Real new<\/strong> lab incident has the intended tag and valid owner (and provenance is recorded), plus negative scope reasoning and rollback. A saved automation rule without observed effect is only PARTIAL.<\/p>\n\n\n\n
                                                                                        Sources:<\/strong> [R15].<\/p>\n\n\n\n
                                                                                        \n\n\n\n
                                                                                        D3-L13 \u2014 Build a focused, operational workbook (I13)<\/h2>\n\n\n\n
                                                                                        Competency:<\/strong> Create\u2014not merely view\u2014a custom operational workbook answering two specific questions: Is the new Linux\/CEF source alive?<\/strong> and Is the correlation showing recent evidence?<\/strong><\/p>\n\n\n\n
                                                                                        A. Permissions and design<\/h3>\n\n\n\n
                                                                                          \n
                                                                                        1. Verify\u00a0Workbook Contributor<\/strong>\u00a0at the destination resource-group scope (or equivalent workbook-write permission). An ordinary Sentinel incident-reader role is not automatically enough. [R16]<\/li>\n\n\n\n
                                                                                        2. Choose the same workspace as L02\/L03; confirm it uses a queryable tier for the tables required by the lab. Do not confuse a long-retention data-lake query with an active analytics-rule input.<\/li>\n\n\n\n
                                                                                        3. Plan three workbook elements: heading, trend\/volume chart, and source-health table. Optional fourth: real L06 correlation results.<\/li>\n<\/ol>\n\n\n\n
                                                                                          B. Create a workbook in Microsoft Defender portal<\/h3>\n\n\n\n
                                                                                            \n
                                                                                          1. Go to\u00a0Microsoft Sentinel > Threat management > Workbooks<\/strong>\u00a0and choose\u00a0Add workbook<\/strong>. Microsoft documents this as the from-scratch creation route. [R16]<\/li>\n\n\n\n
                                                                                          2. Select\u00a0Edit<\/strong>. Add a Markdown\/text section stating\u00a0SENTINEL D3 \u2014 LAB DATA ONLY<\/code>\u00a0and the learner’s intended workspace.<\/li>\n\n\n\n
                                                                                          3. Add a query control. Set\u00a0Data source = Logs<\/strong>,\u00a0Resource type = Log Analytics<\/strong>, then select the exact lab workspace. Some menu labels are inside an editor dialog rather than top-level navigation; record your actual version.<\/li>\n\n\n\n
                                                                                          4. Paste the trend query below into the query component. Set visualization to an area, bar, or time chart if offered:<\/li>\n<\/ol>\n\n\n\n
                                                                                            Syslog\n| where TimeGenerated >= ago(24h)\n| where SyslogMessage contains \"SENTINEL_D3_LAB\"\n| summarize EventCount=count() by bin(TimeGenerated, 5m), Computer\n| order by TimeGenerated asc\n<\/code><\/pre>\n\n\n\n
                                                                                              \n
                                                                                            1. Run it and inspect the output\u00a0before choosing a chart<\/strong>. If only one safe test event exists, the chart will show only a single bucket;\u00a0that is valid<\/strong>, not a visual defect. Do not generate excessive log volume to make the graph look pretty.<\/li>\n\n\n\n
                                                                                            2. Add a second query component, configured as a table, with source freshness:<\/li>\n<\/ol>\n\n\n\n
                                                                                              Syslog\n| where TimeGenerated >= ago(24h)\n| where SyslogMessage contains \"SENTINEL_D3_LAB\"\n| summarize Events=count(), LastSeenUTC=max(TimeGenerated) by Computer, Facility\n| order by LastSeenUTC desc\n<\/code><\/pre>\n\n\n\n
                                                                                                \n
                                                                                              1. If CEF ingestion succeeded, add a third table:<\/li>\n<\/ol>\n\n\n\n
                                                                                                CommonSecurityLog\n| where TimeGenerated >= ago(24h)\n| where DeviceVendor == \"AsterLab\" and DeviceProduct == \"Firewall\"\n| summarize Events=count(), LastSeenUTC=max(TimeGenerated),\n            MissingSourceIP=countif(isempty(SourceIP))\n     by DeviceProduct, DeviceAction\n| order by LastSeenUTC desc\n<\/code><\/pre>\n\n\n\n
                                                                                                  \n
                                                                                                1. Optional: add a fourth results table using\u00a0D3-L06’s compact correlation candidate<\/strong>. Ensure its query is not inadvertently scheduled as an alert; workbook queries are read-only visualizations.<\/li>\n\n\n\n
                                                                                                2. Add a descriptive title\/labels:\u00a0Synthetic Linux data volume<\/code>,\u00a0Syslog last event<\/code>,\u00a0CEF parsing health<\/code>,\u00a0Correlated evidence \u2014 lab only<\/code>. Choose a consistent UTC time window.<\/li>\n\n\n\n
                                                                                                3. Select\u00a0Done editing<\/strong>, then\u00a0Save<\/strong>. Enter the exact workbook name\u00a0Sentinel D3 - Source Quality and Correlation<\/code>, approved subscription\/resource group, and workspace association. [R16]<\/li>\n\n\n\n
                                                                                                4. Close and reopen the saved workbook. Verify it appears under the correct workspace and that all controls can query without author privileges on every data source.<\/li>\n\n\n\n
                                                                                                5. Where the Defender portal cannot display a supported visualization, Microsoft notes that\u00a0Open in Azure<\/strong>\u00a0may be required for some workbook features. This is an implementation exception, not a recommendation to use Azure portal for the whole course. [R16]<\/li>\n<\/ol>\n\n\n\n
                                                                                                  C. Interpretation and validation questions<\/h3>\n\n\n\n
                                                                                                  Record the actual<\/em> answers:<\/p>\n\n\n\n
                                                                                                    \n
                                                                                                  • What UTC time was the last successful Syslog event received? Is it within the tested period?<\/li>\n\n\n\n
                                                                                                  • Does CEF show\u00a0MissingSourceIP<\/code>\u00a0greater than zero? If yes, what is the impact on L06 joins?<\/li>\n\n\n\n
                                                                                                  • Is an empty correlation chart due to data absence, a time filter, a KQL error, or a missing connector?<\/li>\n\n\n\n
                                                                                                  • Which query executes across the widest historical range? Can the workbook be bounded to reduce unnecessary queries?<\/li>\n\n\n\n
                                                                                                  • If this workbook is shared, who needs workbook-reader access and workspace Log Analytics read permissions?<\/li>\n<\/ul>\n\n\n\n
                                                                                                    PASS D3-L13:<\/strong> New saved workbook (not a screenshot of a default template), two functional original query components with real lab output, readable labels, reopened view, and correct student interpretation. PARTIAL:<\/strong> workbook saved but one query fails or data source unavailable; record it honestly.<\/p>\n\n\n\n
                                                                                                    Sources:<\/strong> [R16].<\/p>\n\n\n\n
                                                                                                    \n\n\n\n
                                                                                                    D3-L14 \u2014 Diagnose and repair intermediate failures systematically (I14)<\/h2>\n\n\n\n
                                                                                                    Competency:<\/strong> Trace a failure across source \u2192 network\/daemon \u2192 AMA \u2192 DCR \u2192 workspace \u2192 KQL \u2192 analytic rule \u2192 incident \u2192 automation \u2192 workbook<\/strong>. Students must fix safe simulated faults without destroying working lab infrastructure.<\/p>\n\n\n\n
                                                                                                    A. Instructor troubleshooting decision tree<\/h3>\n\n\n\n
                                                                                                    NoYesNoYesNoYesNoYesNoYesNoYesNoYesNoYesWas test emitted on Linux?logger \/ application \/ daemonDid it reach local syslog listener?protocol + host firewall + port 514Is AMA running and VM associated to DCR?agent extension + DCR resource associationCorrect facility, severity and destination?DCR streams + workspace + duplicate facilitiesRows in target table after delay?AMA diagnostics + endpoint access + parsingDoes scoped KQL return rows?time filter + schema + join keysDid rule run and create an alert?interval + lookback + TimeGenerated + thresholdIncident and automation executed?incident settings + grouping + RBAC + triggerVerify final workbook and evidence pack<\/pre>\n\n\n\n
                                                                                                    B. Non-destructive Linux checks<\/h3>\n\n\n\n
                                                                                                    Run on the actual collector host (approved diagnostic access required):<\/p>\n\n\n\n
                                                                                                    # Check services: no restart or configuration changes.<\/em>\nsudo systemctl status azuremonitoragent --no-pager\nsudo systemctl status rsyslog --no-pager || true\nsudo systemctl status syslog-ng --no-pager || true\n\n# Verify relevant TCP\/UDP listeners. Some routes use UNIX sockets locally.<\/em>\nsudo ss -lunp | grep ':514' || true\nsudo ss -ltnp | grep -E '(:28330|:514)' || true\n\n# Inspect rsyslog syntax without changing it (rsyslog systems only).<\/em>\nsudo rsyslogd -N1 2>&1 | tail -n 40 || true\n\n# Find recent agent and syslog service messages (redact secrets\/identifiers).<\/em>\nsudo journalctl -u azuremonitoragent --since '30 minutes ago' --no-pager | tail -n 60\nsudo journalctl -u rsyslog --since '30 minutes ago' --no-pager | tail -n 60 || true\n\n# Verify adequate free disk (full disk can halt logging).<\/em>\ndf -h \/\n<\/code><\/pre>\n\n\n\n
                                                                                                    Packet inspection only when explicitly permitted<\/strong> and only for a short bounded duration: sudo tcpdump -ni lo udp port 514 -c 10<\/code>. Do not continuously capture traffic or export payloads outside the lab. Check that test traffic actually goes to loopback or the approved private listener. Microsoft documents port 514 to syslog daemon and a local AMA forwarding port such as 28330 in relevant architectures; the exact configured endpoint must be verified on your VM. [R06]<\/p>\n\n\n\n
                                                                                                    C. Scenario-based fault tests<\/h3>\n\n\n\n
                                                                                                    T01 \u2014 DCR exists but Syslog is empty<\/strong><\/p>\n\n\n\n
                                                                                                      \n
                                                                                                    1. Verify the exact VM resource appears under the DCR resource associations.<\/li>\n\n\n\n
                                                                                                    2. Confirm AMA extension\/service is healthy and that the destination workspace is correct.<\/li>\n\n\n\n
                                                                                                    3. Confirm collection\u00a0local5<\/code>\u00a0Warning+<\/strong>\u00a0covers the\u00a0logger<\/code>\u00a0event; re-run one bounded\u00a0logger<\/code>\u00a0message.<\/li>\n\n\n\n
                                                                                                    4. Query broad\u00a0Syslog<\/code>\u00a0(without the marker filter), then narrow. Wait for documented processing delay.<\/li>\n\n\n\n
                                                                                                    5. Record root cause.\u00a0Do not broaden every facility<\/strong>\u00a0as a permanent fix.<\/li>\n<\/ol>\n\n\n\n
                                                                                                      T02 \u2014 CEF present in Syslog but not CommonSecurityLog<\/code><\/strong><\/p>\n\n\n\n
                                                                                                        \n
                                                                                                      1. Check test message framing and\u00a0-t CEF<\/code>\/syslog tag.<\/li>\n\n\n\n
                                                                                                      2. Compare\u00a0local4<\/code>\u00a0against actual received facility; verify the CEF stream\u00a0Microsoft-CommonSecurityLog<\/code>\u00a0and its DCR association.<\/li>\n\n\n\n
                                                                                                      3. Verify rsyslog\/syslog-ng forwarding configuration produced by the current Microsoft script.<\/li>\n\n\n\n
                                                                                                      4. Check the raw message for a valid\u00a0CEF:0|vendor|product|version|class|name|severity|extensions<\/code>\u00a0envelope.<\/li>\n\n\n\n
                                                                                                      5. Record whether parser limitations, DCR routing, or an incorrectly generated CEF test was responsible.<\/li>\n<\/ol>\n\n\n\n
                                                                                                        T03 \u2014 Duplicate alerts \/ excessive rows<\/strong><\/p>\n\n\n\n
                                                                                                          \n
                                                                                                        1. Count raw events in Syslog and\u00a0CommonSecurityLog<\/code>\u00a0independently.<\/li>\n\n\n\n
                                                                                                        2. Inspect repeated\u00a0logger<\/code>\u00a0tests and DCR facility overlap.<\/li>\n\n\n\n
                                                                                                        3. Compute join multiplicity; compare\u00a0EvidencePairs<\/code>\u00a0to\u00a0distinct source events<\/em>.<\/li>\n\n\n\n
                                                                                                        4. Check alert-per-event versus one-alert grouping, incident grouping and rule suppression.<\/li>\n\n\n\n
                                                                                                        5. Apply a scoped query correction; do not ‘fix’ duplicates by simply closing all resulting incidents.<\/li>\n<\/ol>\n\n\n\n
                                                                                                          T04 \u2014 Invalid or empty KQL join<\/strong><\/p>\n\n\n\n
                                                                                                            \n
                                                                                                          1. Run left and right subqueries independently and count rows in the same UTC window.<\/li>\n\n\n\n
                                                                                                          2. Inspect column types (SourceIP<\/code>,\u00a0Account<\/code>,\u00a0TimeGenerated<\/code>,\u00a0SourceUserName<\/code>).<\/li>\n\n\n\n
                                                                                                          3. Normalize only defensible join keys (e.g., case, whitespace); do not invent missing identity.<\/li>\n\n\n\n
                                                                                                          4. Inspect whether both devices observed source IP from the same network vantage (NAT\/proxy may differ).<\/li>\n\n\n\n
                                                                                                          5. Test a synthetic two-row join that must succeed, then return to the real query.<\/li>\n<\/ol>\n\n\n\n
                                                                                                            T05 \u2014 Custom scheduled rule enabled but no alert<\/strong><\/p>\n\n\n\n
                                                                                                              \n
                                                                                                            1. Confirm KQL returns at least one\u00a0recent real<\/em>\u00a0row during the intended lookback.<\/li>\n\n\n\n
                                                                                                            2. Ensure its final results include\u00a0TimeGenerated<\/code>\u00a0and query scheduling lookback \u2265 interval.<\/li>\n\n\n\n
                                                                                                            3. Confirm rule is enabled, correct workspace\/table plan, no disabled incident setting, and appropriate alert threshold.<\/li>\n\n\n\n
                                                                                                            4. Review evaluation timing and ingestion delay; simulation alone isn’t actual alert proof.<\/li>\n\n\n\n
                                                                                                            5. Check whether the alert exists but is merged into an existing incident or hidden by portal filters.<\/li>\n<\/ol>\n\n\n\n
                                                                                                              T06 \u2014 Incident exists but automation didn’t apply tag<\/strong><\/p>\n\n\n\n
                                                                                                                \n
                                                                                                              1. Confirm a\u00a0new incident<\/strong>\u00a0was created\u00a0after<\/em>\u00a0automation was enabled.<\/li>\n\n\n\n
                                                                                                              2. Check the actual analytic rule name against the automation condition.<\/li>\n\n\n\n
                                                                                                              3. Confirm the trigger is incident creation, not alert creation; verify tag\/owner actions are supported.<\/li>\n\n\n\n
                                                                                                              4. Review automation rule ordering and audit\/execution details, plus owner eligibility.<\/li>\n\n\n\n
                                                                                                              5. Ensure incident grouping didn’t append an alert to an old incident without a creation event.<\/li>\n<\/ol>\n\n\n\n
                                                                                                                T07 \u2014 Empty custom workbook<\/strong><\/p>\n\n\n\n
                                                                                                                  \n
                                                                                                                1. Confirm workspace selection, query time range and connected tables.<\/li>\n\n\n\n
                                                                                                                2. Run the workbook KQL in Logs separately; note its actual result.<\/li>\n\n\n\n
                                                                                                                3. Confirm workbook reader and Log Analytics permissions; distinguish authorization failure from no results.<\/li>\n\n\n\n
                                                                                                                4. Verify the workbook was saved\/reopened in the intended resource group.<\/li>\n\n\n\n
                                                                                                                5. If a visualization isn’t available in Defender, use the documented Open in Azure option if allowed.<\/li>\n<\/ol>\n\n\n\n
                                                                                                                  T08 \u2014 UEBA\/TI table not available<\/strong><\/p>\n\n\n\n
                                                                                                                    \n
                                                                                                                  1. Ask whether the feature has actually been enabled and appropriate sources\/feeds installed.<\/li>\n\n\n\n
                                                                                                                  2. Check role\/permissions, source dependencies and elapsed processing time; note that absence may be expected.<\/li>\n\n\n\n
                                                                                                                  3. Use the synthetic exercise. Record feature as\u00a0not verified<\/em>\u00a0rather than creating an unrelated broad subscription.<\/li>\n<\/ol>\n\n\n\n
                                                                                                                    D. Complete a root-cause journal<\/h3>\n\n\n\n
                                                                                                                    Issue<\/th>Initial symptom<\/th>Reproduction<\/th>Layer causing failure<\/th>Evidence<\/th>Smallest safe correction<\/th>Re-test<\/th>Revert if needed<\/th><\/tr><\/thead>
                                                                                                                    T01<\/td><\/td><\/td><\/td><\/td><\/td><\/td><\/td><\/tr>
                                                                                                                    T02<\/td><\/td><\/td><\/td><\/td><\/td><\/td><\/td><\/tr>
                                                                                                                    T03<\/td><\/td><\/td><\/td><\/td><\/td><\/td><\/td><\/tr>
                                                                                                                    T04<\/td><\/td><\/td><\/td><\/td><\/td><\/td><\/td><\/tr>
                                                                                                                    T05<\/td><\/td><\/td><\/td><\/td><\/td><\/td><\/td><\/tr>
                                                                                                                    T06<\/td><\/td><\/td><\/td><\/td><\/td><\/td><\/td><\/tr>
                                                                                                                    T07<\/td><\/td><\/td><\/td><\/td><\/td><\/td><\/td><\/tr>
                                                                                                                    T08<\/td><\/td><\/td><\/td><\/td><\/td><\/td><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                                                                                    PASS D3-L14:<\/strong> Learner independently traces at least three<\/strong> different failure layers and records evidence for a corrected or conclusively isolated root cause. At least one must involve data collection\/quality and one detection\/incident stage. Do not intentionally disable shared collectors or revoke permissions to create a classroom exercise.<\/p>\n\n\n\n
                                                                                                                    Sources:<\/strong> [R06], [R13], [R14], [R15], [R16], [R20].<\/p>\n\n\n\n
                                                                                                                    \n\n\n\n
                                                                                                                    3. End-of-Day 3 capstone \u2014 integrated, evidence-based examination<\/h1>\n\n\n\n
                                                                                                                    D3-CAP \u2014 Aster Retail: correlated privileged-source investigation<\/h2>\n\n\n\n
                                                                                                                    Mission:<\/strong> An authorized Linux application test records a fictional privileged session. An approved firewall simulator emits a matching denied-traffic CEF event. You will prove ingestion, correlate it, enrich it, build an explainable detection, tune without losing signal, route the resulting training incident safely and demonstrate monitoring. Use your actual<\/strong> lab evidence and do not substitute fabricated console screenshots.<\/p>\n\n\n\n
                                                                                                                    Learner execution steps<\/h3>\n\n\n\n
                                                                                                                      \n
                                                                                                                    1. Source design:<\/strong>\u00a0State why\u00a0Syslog via AMA<\/code>\u00a0and\u00a0CEF via AMA<\/code>\u00a0are selected, their role boundaries, expected tables, and the no-overlap facility design. Include one alternate integration pattern for a non-Microsoft source.<\/li>\n\n\n\n
                                                                                                                    2. Telemetry:<\/strong>\u00a0Produce one approved Linux test event plus one CEF event (instructor-controlled if necessary); record source UTC timestamps, VM, DCR IDs, workspace, and observed row IDs\/fields.<\/li>\n\n\n\n
                                                                                                                    3. Quality:<\/strong>\u00a0Show table-level\u00a0TimeGenerated<\/code>, mapped source IP\/action, missing-field\/duplicate\/freshness analysis and any parsing caveats.<\/li>\n\n\n\n
                                                                                                                    4. Correlation:<\/strong>\u00a0Demonstrate a joined result that uses an explicit ten-minute window and explain why IP equality is weak without an account match or similar additional evidence.<\/li>\n\n\n\n
                                                                                                                    5. Context:<\/strong>\u00a0Use\u00a0day3_privileged_accounts<\/code>\u00a0watchlist to identify the fictional high-value user and the reference-data owner. Discuss optional UEBA\/TI context honestly based on availability.<\/li>\n\n\n\n
                                                                                                                    6. Detection:<\/strong>\u00a0Show a validated scheduled rule, low-risk lab severity, correct\u00a0TimeGenerated<\/code>, entity mapping, current query schedule and alert threshold; demonstrate a\u00a0real<\/strong>\u00a0alert and incident if on Track A\/B.<\/li>\n\n\n\n
                                                                                                                    7. Tuning:<\/strong>\u00a0Test a positive and negative case, preserve query versions, document any narrow exception and rollback.<\/li>\n\n\n\n
                                                                                                                    8. Case operations:<\/strong>\u00a0Show a scope-limited creation automation that tags and assigns a\u00a0new<\/strong>\u00a0lab incident; produce action evidence and demonstrate safe negative scope.<\/li>\n\n\n\n
                                                                                                                    9. Dashboard:<\/strong>\u00a0Open the original source-health workbook and answer whether Syslog and CEF are fresh, complete and correlated.<\/li>\n\n\n\n
                                                                                                                    10. Troubleshooting:<\/strong>\u00a0Solve or isolate three injected\/documented problems using the diagnostic decision tree.<\/li>\n\n\n\n
                                                                                                                    11. Closeout:<\/strong>\u00a0Disable noisy temporary artifacts and record how the instructor will remove or retain approved lab resources.<\/li>\n<\/ol>\n\n\n\n
                                                                                                                      Objective rubric (100 points)<\/h3>\n\n\n\n
                                                                                                                      Competency<\/th>Points<\/th>Required observable evidence<\/th><\/tr><\/thead>
                                                                                                                      Collection selection\/architecture (I01\u2013I03)<\/td>12<\/td>Correct patterns, owner, least privilege, facility separation<\/td><\/tr>
                                                                                                                      Working additional source + schema validation (I02\u2013I04)<\/td>18<\/td>AMA\/DCR association, real Syslog plus CEF (or approved second source), correct destination records<\/td><\/tr>
                                                                                                                      Intermediate KQL + correlation (I05\u2013I06)<\/td>18<\/td>let<\/code>\/join, window, parsed fields, source-attribution caveats, negative test<\/td><\/tr>
                                                                                                                      Watchlist + contextual judgment (I07\u2013I09)<\/td>12<\/td>Queryable watchlist, correct enrichment; TI\/UEBA availability and interpretation<\/td><\/tr>
                                                                                                                      Custom scheduled detection (I10)<\/td>15<\/td>Rule, actual alert and incident, mapping, schedule, threshold, test evidence<\/td><\/tr>
                                                                                                                      Measured detection tuning (I11)<\/td>8<\/td>Before\/after positive and negative outcomes, rollback<\/td><\/tr>
                                                                                                                      Low-risk metadata automation (I12)<\/td>7<\/td>New incident tagged and assigned with correct scope<\/td><\/tr>
                                                                                                                      New workbook (I13)<\/td>5<\/td>Reopened saved workbook, working custom queries<\/td><\/tr>
                                                                                                                      Troubleshooting and documentation (I14)<\/td>5<\/td>Three-layer evidence-based root cause journal<\/td><\/tr>
                                                                                                                      Total<\/strong><\/td>100<\/strong><\/td><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                                                                                      Mandatory operational competency gates<\/h3>\n\n\n\n
                                                                                                                      A learner obtains Day 3 Intermediate operational PASS<\/strong> only when:<\/p>\n\n\n\n
                                                                                                                        \n
                                                                                                                      • [ ] Score\u00a0at least 80\/100<\/strong>; and<\/li>\n\n\n\n
                                                                                                                      • [ ] At least\u00a0one new source<\/strong>\u00a0genuinely ingested into the workspace and its schema was validated; and<\/li>\n\n\n\n
                                                                                                                      • [ ] Correlation of\u00a0two actual telemetry sources<\/strong>\u00a0was demonstrated (not only\u00a0datatable()<\/code>); and<\/li>\n\n\n\n
                                                                                                                      • [ ] A queryable watchlist enrichment was shown or an explicitly approved equivalent business-context lookup demonstrated; and<\/li>\n\n\n\n
                                                                                                                      • [ ] A\u00a0real custom scheduled detection<\/strong>\u00a0produced a real alert and incident; and<\/li>\n\n\n\n
                                                                                                                      • [ ] At least one reversible false-positive\/tuning change passed positive and negative testing; and<\/li>\n\n\n\n
                                                                                                                      • [ ] Incident metadata automation acted on a new\u00a0lab<\/strong>\u00a0incident with proper scoping; and<\/li>\n\n\n\n
                                                                                                                      • [ ] One custom workbook was saved\/reopened and three troubleshooting layers were evidenced; and<\/li>\n\n\n\n
                                                                                                                      • [ ] No unsafe production activity, uncontrolled ingestion or unapproved privileged changes occurred.<\/li>\n<\/ul>\n\n\n\n
                                                                                                                        Restricted Track C rule:<\/strong> Learners can obtain a conceptual \/ design completion<\/strong> recognition if they meet the knowledge items and score threshold, but must complete outstanding live gates before being marked operationally qualified for Advanced. One may arrange a supervised remediation test; never change the grading rule retroactively.<\/p>\n\n\n\n
                                                                                                                        Instructor answer key \/ expected reasoning<\/h3>\n\n\n\n
                                                                                                                          \n
                                                                                                                        • Data connectors differ in event scope, privileges, transport, data schema and operational ownership. A connector installed from Content hub is\u00a0not<\/strong>\u00a0proof of a live event stream.<\/li>\n\n\n\n
                                                                                                                        • Syslog\u00a0local5<\/code>\u00a0and CEF\u00a0local4<\/code>\u00a0are a documented\u00a0lab design choice<\/em>, not universal facilities. DCR destination and collector must match the actual emitted record.<\/li>\n\n\n\n
                                                                                                                        • One real emitted event may produce a row after processing delay. The precise row count is\u00a0not fixed<\/strong>\u00a0because the cohort may repeat tests, agent\/parser behavior varies, and grouping changes output.<\/li>\n\n\n\n
                                                                                                                        • An IP+time join is weaker than a corroborated multi-attribute link. Joined row counts can multiply; count distinct underlying source events where required.<\/li>\n\n\n\n
                                                                                                                        • Watchlists are governed reference data;\u00a0SearchKey<\/code>\u00a0must match the selected CSV column. Missing lookup result is\u00a0unknown context<\/strong>, not an automatic safe classification.<\/li>\n\n\n\n
                                                                                                                        • Indicators need validity, source, confidence, expiry and type; a match does not prove compromise. For 2026 use\u00a0ThreatIntelIndicators<\/code>, not the old table.<\/li>\n\n\n\n
                                                                                                                        • UEBA investigation priority and anomaly scores differ in range\/meaning; anomalies demand corroboration. Synthetic CEF doesn’t magically enable UEBA.<\/li>\n\n\n\n
                                                                                                                        • Scheduled analytics must return source-based\u00a0TimeGenerated<\/code>\u00a0and evaluate real records during the lookback. A saved rule or simulation alone isn’t a detected incident.<\/li>\n\n\n\n
                                                                                                                        • Event grouping, incident grouping and suppression are distinct controls; false-positive exclusions need controlled tests and explicit rollback.<\/li>\n\n\n\n
                                                                                                                        • Case metadata automation needs an\u00a0incident<\/strong>\u00a0trigger, not a basic alert trigger, for tag\/owner operations; preexisting incidents are not guaranteed to fire creation automations.<\/li>\n\n\n\n
                                                                                                                        • Operational workbook data selection and user permissions should be verified independently. No chart result can mean a genuine zero, time mismatch or a permissions\/query failure.<\/li>\n<\/ul>\n\n\n\n
                                                                                                                          \n\n\n\n
                                                                                                                          4. Classroom troubleshooting and evidence worksheet templates<\/h1>\n\n\n\n
                                                                                                                          4.1 One-page incident\/detection change record<\/h2>\n\n\n\n
                                                                                                                          Course: Microsoft Sentinel Intermediate \/ Day 3\nScenario: Aster Retail \u2014 entirely fictional security observations\nRule name and exported query version:\nRule author + review\/approval:\nWorkspace and data tier:\nData sources, DCRs, collector:\nSource test timestamps (UTC):\nLinux record observed (ID\/marker):\nCEF record observed (ID\/class\/vendor\/product):\nJoin key and time window:\nCorroborating identity context (or missing field):\nWatchlist alias + owner + review date:\nThreat indicator \/ UEBA status and limitations:\nBefore\/after detection positives and negatives:\nRule schedule, lookback, threshold, grouping:\nAlert ID and incident ID:\nAutomation rule name, trigger\/condition\/actions:\nAction evidence (tag + owner):\nWorkbook name\/URL or resource ID:\nFalse-positive assumptions and open risks:\nRevert plan:\nInstructor signature\/date:\n<\/code><\/pre>\n\n\n\n
                                                                                                                          4.2 Lab result ledger<\/h2>\n\n\n\n
                                                                                                                          Lab<\/th>Date\/UTC<\/th>Student<\/th>Execution track<\/th>Actual result<\/th>Evidence ref<\/th>PASS\/PARTIAL\/BLOCKED<\/th>Instructor<\/th><\/tr><\/thead>
                                                                                                                          L01<\/td><\/td><\/td><\/td><\/td><\/td><\/td><\/td><\/tr>
                                                                                                                          L02<\/td><\/td><\/td><\/td><\/td><\/td><\/td><\/td><\/tr>
                                                                                                                          L03<\/td><\/td><\/td><\/td><\/td><\/td><\/td><\/td><\/tr>
                                                                                                                          L04<\/td><\/td><\/td><\/td><\/td><\/td><\/td><\/td><\/tr>
                                                                                                                          L05<\/td><\/td><\/td><\/td><\/td><\/td><\/td><\/td><\/tr>
                                                                                                                          L06<\/td><\/td><\/td><\/td><\/td><\/td><\/td><\/td><\/tr>
                                                                                                                          L07<\/td><\/td><\/td><\/td><\/td><\/td><\/td><\/td><\/tr>
                                                                                                                          L08<\/td><\/td><\/td><\/td><\/td><\/td><\/td><\/td><\/tr>
                                                                                                                          L09<\/td><\/td><\/td><\/td><\/td><\/td><\/td><\/td><\/tr>
                                                                                                                          L10<\/td><\/td><\/td><\/td><\/td><\/td><\/td><\/td><\/tr>
                                                                                                                          L11<\/td><\/td><\/td><\/td><\/td><\/td><\/td><\/td><\/tr>
                                                                                                                          L12<\/td><\/td><\/td><\/td><\/td><\/td><\/td><\/td><\/tr>
                                                                                                                          L13<\/td><\/td><\/td><\/td><\/td><\/td><\/td><\/td><\/tr>
                                                                                                                          L14<\/td><\/td><\/td><\/td><\/td><\/td><\/td><\/td><\/tr>
                                                                                                                          CAP<\/td><\/td><\/td><\/td><\/td><\/td><\/td><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                                                                                          4.3 Technical troubleshooting matrix<\/h2>\n\n\n\n
                                                                                                                          Observable symptom<\/th>Likely causes<\/th>First safe verification<\/th>Success criterion<\/th><\/tr><\/thead>
                                                                                                                          Linux event absent locally<\/td>Wrong daemon, logger<\/code> failed, host access issue<\/td>Journal, daemon, logger<\/code> output<\/td>Test marker observable on source\/daemon<\/td><\/tr>
                                                                                                                          Syslog table empty<\/td>AMA not installed, DCR not associated, facility mismatch<\/td>VM extension, DCR, broad Syslog query<\/td>Lab marker in target workspace<\/td><\/tr>
                                                                                                                          CEF not parsed<\/td>Wrong facility\/stream\/header\/forwarder script<\/td>Raw message, port 514, CommonSecurityLog<\/code> query<\/td>Vendor\/product\/source columns populated<\/td><\/tr>
                                                                                                                          Duplicate CEF\/Syslog<\/td>DCR facility overlap, repeated test generation<\/td>DCR streams and event counts<\/td>Duplicates explained or corrected<\/td><\/tr>
                                                                                                                          Delay unexplained<\/td>Clock skew, ingestion pipeline, lag<\/td>UTC clocks + ingestion_time when available<\/td>Plausible evidence timeline<\/td><\/tr>
                                                                                                                          No KQL join<\/td>Mismatched IP\/time\/user, missing source<\/td>Execute sides independently<\/td>Correct positive case, negative case rejected<\/td><\/tr>
                                                                                                                          Watchlist no match<\/td>Wrong alias, SearchKey, casing, delayed creation<\/td>_GetWatchlist()<\/code> + normalized keys<\/td>Intended context present<\/td><\/tr>
                                                                                                                          TI no table<\/td>No feed, wrong workspace, unsupported tier<\/td>Table list\/connector inventory<\/td>Availability recorded correctly<\/td><\/tr>
                                                                                                                          UEBA empty<\/td>Feature\/source not enabled, thin data, role<\/td>UEBA settings\/sources\/tables<\/td>No false claim of UEBA signal<\/td><\/tr>
                                                                                                                          Analytics no alert<\/td>Stale TimeGenerated, threshold, window, disabled rule<\/td>Saved query + interval\/lookback + rule status<\/td>Actual alert ID<\/td><\/tr>
                                                                                                                          Alert but no incident<\/td>Incident disabled, grouping, Defender view<\/td>Rule incident settings + incident filters<\/td>Actual incident ID or documented reason<\/td><\/tr>
                                                                                                                          Automation silent<\/td>Old incident, rule condition\/owner error<\/td>New incident UTC + rule action audit<\/td>Intended tag and owner<\/td><\/tr>
                                                                                                                          Workbook empty<\/td>Query\/time\/workspace\/permissions mismatch<\/td>Run KQL in Logs, reopen workbook<\/td>Expected query component result<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                                                                                          \n\n\n\n
                                                                                                                          5. Safe laboratory cleanup and post-course handover<\/h1>\n\n\n\n
                                                                                                                          \n
                                                                                                                          Cleanup order matters.<\/strong> Stop active detections and automations before deleting the data sources or VM. Keep the Day 1\/Day 2 Sentinel workspace intact unless its owner explicitly authorized otherwise.<\/p>\n<\/blockquote>\n\n\n\n
                                                                                                                          Step 1 \u2014 Disable lab analytics and automation<\/h2>\n\n\n\n
                                                                                                                            \n
                                                                                                                          1. In\u00a0Microsoft Sentinel > Configuration > Analytics<\/strong>, find exactly\u00a0SENTINEL-D3-LAB-Privileged-Source-Correlation<\/code>\u00a0and\u00a0disable<\/strong>\u00a0it. Confirm status; do not disable unrelated rules.<\/li>\n\n\n\n
                                                                                                                          2. In\u00a0Microsoft Sentinel > Configuration > Automation<\/strong>, disable exactly\u00a0SENTINEL-D3-LAB-Tag-And-Assign<\/code>\u00a0and confirm no additional lab rule remains.<\/li>\n\n\n\n
                                                                                                                          3. If the course needs reproducible grading, export safe rule\/query configuration through an approved process; remove credentials and resource identifiers before sharing externally.<\/li>\n<\/ol>\n\n\n\n
                                                                                                                            Step 2 \u2014 Close\/document training-only incidents<\/h2>\n\n\n\n
                                                                                                                              \n
                                                                                                                            1. Locate incidents created by the training rule. Preserve the necessary instructor evidence and disposition.<\/li>\n\n\n\n
                                                                                                                            2. Close according to the approved training classification (e.g., simulated\/benign test activity) and record that no real compromise occurred. Follow the actual available incident classification labels in your Defender tenant; don’t invent one.<\/li>\n\n\n\n
                                                                                                                            3. Verify automated ownership\/tagging has stopped on new incidents.<\/li>\n<\/ol>\n\n\n\n
                                                                                                                              Step 3 \u2014 Remove reference data and workbook (if exclusive to this lab)<\/h2>\n\n\n\n
                                                                                                                                \n
                                                                                                                              1. Delete or retain\u00a0day3_privileged_accounts<\/code>\u00a0only according to the course retention plan. It should not become a production privileged account authority.<\/li>\n\n\n\n
                                                                                                                              2. Delete or retain\u00a0Sentinel D3 - Source Quality and Correlation<\/code>\u00a0based on whether it belongs to a shared teaching library. Avoid deleting a workbook created by another cohort.<\/li>\n\n\n\n
                                                                                                                              3. Record the names, dates, owners and decision in the artifact register.<\/li>\n<\/ol>\n\n\n\n
                                                                                                                                Step 4 \u2014 Remove CEF\/Syslog DCRs and extensions responsibly<\/h2>\n\n\n\n
                                                                                                                                  \n
                                                                                                                                1. Identify the exact training-created DCRs and their VM associations in Azure Monitor.<\/li>\n\n\n\n
                                                                                                                                2. Do not delete a shared agent, shared DCR or monitoring association.<\/strong>\u00a0If the VM is dedicated and no other sources depend on the DCR, remove the training-only associations\/rules with owner approval.<\/li>\n\n\n\n
                                                                                                                                3. Remove the training-only forwarder configuration or shut down the dedicated VM per infrastructure policy. If Microsoft’s forwarder script changed rsyslog files, remove only the generated configuration and validate the remaining daemon; do not casually overwrite system config.<\/li>\n\n\n\n
                                                                                                                                4. Reconcile the final VM state: stopped\/deallocated or deleted if exclusive to the lab. Deallocation may stop VM compute charges but persistent disks\/public IP resources can still incur costs; inspect Azure Cost Management.<\/li>\n<\/ol>\n\n\n\n
                                                                                                                                  Step 5 \u2014 Verify post-lab safety and spending<\/h2>\n\n\n\n
                                                                                                                                    \n
                                                                                                                                  • [ ] No active Day 3 scheduled analytics rule.<\/li>\n\n\n\n
                                                                                                                                  • [ ] No active Day 3 metadata automation.<\/li>\n\n\n\n
                                                                                                                                  • [ ] All training incidents documented and dispositioned per lab policy.<\/li>\n\n\n\n
                                                                                                                                  • [ ] Watchlist\/workbook ownership resolved.<\/li>\n\n\n\n
                                                                                                                                  • [ ] Temporary Linux test VM, DCRs and forwarding settings handled with owner approval.<\/li>\n\n\n\n
                                                                                                                                  • [ ] Correct Sentinel workspace remains as planned for Days 4\u20135.<\/li>\n\n\n\n
                                                                                                                                  • [ ] No unexpected collection\/ingestion costs or real customer data exposure.<\/li>\n\n\n\n
                                                                                                                                  • [ ] A final cleanup record was signed.<\/li>\n<\/ul>\n\n\n\n
                                                                                                                                    \n\n\n\n
                                                                                                                                    6. Exact syllabus-to-lab coverage audit<\/h1>\n\n\n\n
                                                                                                                                    This table is the mechanical non-duplication<\/strong> and completeness<\/strong> crosswalk. Day 1\/2 content is assumed as a prerequisite, not re-taught.<\/p>\n\n\n\n
                                                                                                                                    Intermediate topic<\/th>Main lab(s)<\/th>Practical objective<\/th>Evidence gate<\/th><\/tr><\/thead>
                                                                                                                                    I01<\/strong> Expand data-source coverage<\/td>L01<\/td>Connector decision matrix<\/td>Chosen route + ownership<\/td><\/tr>
                                                                                                                                    I02<\/strong> Linux\/network telemetry, AMA, Syslog\/CEF, DCR<\/td>L02, L03<\/td>Configure approved agent\/forwarder\/DCR<\/td>Real target-table events<\/td><\/tr>
                                                                                                                                    I03<\/strong> Third-party and multicloud intake<\/td>L03<\/td>Select and compare AWS\/GCP\/firewall\/app patterns<\/td>Documented integration matrix<\/td><\/tr>
                                                                                                                                    I04<\/strong> Pipeline validation<\/td>L04<\/td>Schema, timestamps, latency, duplicates<\/td>Fidelity report<\/td><\/tr>
                                                                                                                                    I05<\/strong> Intermediate KQL<\/td>L05<\/td>let<\/code>, join<\/code>, union<\/code>, extend<\/code>, parse<\/code>, mv-expand<\/code>, distinct<\/code><\/td>Eight correct query exercises<\/td><\/tr>
                                                                                                                                    I06<\/strong> Identity\/infrastructure correlation<\/td>L06<\/td>Time-bounded two-source join<\/td>Positive\/negative evidence<\/td><\/tr>
                                                                                                                                    I07<\/strong> Watchlist enrichment<\/td>L07<\/td>CSV \u2192 SearchKey \u2192 _GetWatchlist<\/code> join<\/td>Enriched record + owner<\/td><\/tr>
                                                                                                                                    I08<\/strong> Threat indicators<\/td>L08<\/td>Validity, confidence, expiry, source<\/td>Live read or synthetic TI exercise<\/td><\/tr>
                                                                                                                                    I09<\/strong> UEBA introduction<\/td>L09<\/td>Enable\/consume only if authorized; interpret scores<\/td>Live read or authorized substitute<\/td><\/tr>
                                                                                                                                    I10<\/strong> Custom scheduled rule<\/td>L10<\/td>KQL, mapping, threshold, lookback, incident<\/td>Real alert and incident<\/td><\/tr>
                                                                                                                                    I11<\/strong> Detection tuning\/incident flow<\/td>L11<\/td>Scoped exceptions, grouping, precision proxy<\/td>Before\/after test matrix<\/td><\/tr>
                                                                                                                                    I12<\/strong> Metadata automation (no playbooks)<\/td>L12<\/td>Created-incident scoped tag\/assignment<\/td>New tagged\/assigned incident<\/td><\/tr>
                                                                                                                                    I13<\/strong> Focused workbook<\/td>L13<\/td>Saved original source-quality visualization<\/td>Reopened functioning workbook<\/td><\/tr>
                                                                                                                                    I14<\/strong> Intermediate failures<\/td>L14<\/td>Multi-layer troubleshooting<\/td>Root-cause journal<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                                                                                                    Day 4 reserved material:<\/strong> ASIM-based detection engineering, detailed threat hunting\/ATT&CK mapping, NRT vs scheduled\/custom detection strategy, Logic Apps\/playbook construction, managed identity and response approval gates. Day 5 reserved material:<\/strong> enterprise workspace architecture, lake\/storage strategy, KQL jobs, content-as-code CI\/CD, SOC metrics, health\/audit operationalization and full production governance. Do not repeat those modules here.<\/p>\n\n\n\n
                                                                                                                                    \n\n\n\n
                                                                                                                                    7. Official Microsoft source register (verified for this edition)<\/h1>\n\n\n\n
                                                                                                                                    \n
                                                                                                                                    Links below point to Microsoft Learn documentation reviewed for this manual<\/strong>, not to any user tenant. Microsoft can revise documentation and portal screens; before running a future cohort, re-check pages, particularly connector and licensing guidance. These are the sources for the documented procedures, not proof of a successful run in the training subscription.<\/p>\n<\/blockquote>\n\n\n\n
                                                                                                                                    Ref<\/th>Official documentation<\/th>Used for<\/th><\/tr><\/thead>
                                                                                                                                    R01<\/strong><\/td>Microsoft Sentinel in the Defender portal<\/a><\/td>Primary experience, migration, limitations, UI navigation<\/td><\/tr>
                                                                                                                                    R02<\/strong><\/td>Ingest Syslog and CEF messages to Microsoft Sentinel with AMA<\/a><\/td>Connector prerequisites, DCR wizard, Linux tests, CEF examples<\/td><\/tr>
                                                                                                                                    R03<\/strong><\/td>Syslog and CEF AMA connector overview<\/a><\/td>Architecture, facility overlap and duplicate avoidance<\/td><\/tr>
                                                                                                                                    R04<\/strong><\/td>Connect data sources to Microsoft Sentinel<\/a><\/td>Connectors\/selection foundations<\/td><\/tr>
                                                                                                                                    R05<\/strong><\/td>AMA supported operating systems and environments<\/a><\/td>Collector host compatibility, Azure Arc applicability<\/td><\/tr>
                                                                                                                                    R06<\/strong><\/td>Troubleshoot Syslog and CEF via AMA<\/a><\/td>Agent\/rsyslog\/port checks, 20-minute ingestion allowance<\/td><\/tr>
                                                                                                                                    R07<\/strong><\/td>Kusto Query Language documentation<\/a><\/td>Operator meanings and reproducible KQL exercises<\/td><\/tr>
                                                                                                                                    R08<\/strong><\/td>Use watchlists to correlate and enrich event data<\/a><\/td>_GetWatchlist<\/code>, SearchKey, stewardship and limits<\/td><\/tr>
                                                                                                                                    R09<\/strong><\/td>Create watchlists in Microsoft Sentinel<\/a><\/td>CSV upload, alias, wizard, SearchKey<\/td><\/tr>
                                                                                                                                    R10<\/strong><\/td>Threat intelligence in Microsoft Sentinel<\/a><\/td>Modern TI lifecycle, table transitions<\/td><\/tr>
                                                                                                                                    R11<\/strong><\/td>Work with STIX objects and indicators<\/a><\/td>ThreatIntelIndicators<\/code>\/ThreatIntelObjects<\/code> and legacy retirement<\/td><\/tr>
                                                                                                                                    R12<\/strong><\/td>Enable User and Entity Behavior Analytics<\/a><\/td>UEBA roles, setup, supported data, optional anomaly toggle<\/td><\/tr>
                                                                                                                                    R13<\/strong><\/td>Create a scheduled analytics rule<\/a><\/td>New scheduled rule wizard, mapping, TimeGenerated<\/code><\/td><\/tr>
                                                                                                                                    R14<\/strong><\/td>Scheduled analytics rule options and behavior<\/a><\/td>Thresholds, event grouping, interval\/lookback, ingestion delay<\/td><\/tr>
                                                                                                                                    R15<\/strong><\/td>Create and use Microsoft Sentinel automation rules<\/a><\/td>Incident trigger\/actions, scoping, audit, preview differences<\/td><\/tr>
                                                                                                                                    R16<\/strong><\/td>Visualize and monitor by using workbooks<\/a><\/td>New custom workbook, permissions, save\/refresh<\/td><\/tr>
                                                                                                                                    R17<\/strong><\/td>ThreatIntelIndicators table schema<\/a><\/td>Validity\/confidence\/revocation\/observable columns<\/td><\/tr>
                                                                                                                                    R18<\/strong><\/td>Advanced threat detection with UEBA<\/a><\/td>Risk score interpretation and behavior context<\/td><\/tr>
                                                                                                                                    R19<\/strong><\/td>BehaviorAnalytics table schema<\/a><\/td>UEBA field names and scoring output<\/td><\/tr>
                                                                                                                                    R20<\/strong><\/td>CommonSecurityLog schema<\/a><\/td>CEF parsed field names and meanings<\/td><\/tr>
                                                                                                                                    R21<\/strong><\/td>Microsoft Sentinel best practices<\/a><\/td>Collection, detection quality and query efficiency<\/td><\/tr>
                                                                                                                                    R22<\/strong><\/td>Threat detection in Microsoft Sentinel<\/a><\/td>Scheduled vs modern unified custom detections and guidance<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                                                                                                    2026 design note on rule engines:<\/strong> The syllabus explicitly asks students to author a custom scheduled analytics rule<\/strong> in Day 3 (I10), so that hands-on procedure is retained here. Microsoft’s newer Defender custom detections<\/strong> experience is relevant and may be preferable for some production deployments; a complete comparison belongs to Advanced Day 4<\/strong>, not a replacement of this skill requirement. [R22]<\/p>\n\n\n\n
                                                                                                                                    \n\n\n\n
                                                                                                                                    8. Final quality checklist for the training provider<\/h1>\n\n\n\n
                                                                                                                                      \n
                                                                                                                                    • [ ] This is\u00a0Day 3 alone<\/strong>; Day 1\/2 material is referenced as prerequisite, not repeated.<\/li>\n\n\n\n
                                                                                                                                    • [ ] Every syllabus item I01\u2013I14 has its own practical lab coverage and a PASS standard.<\/li>\n\n\n\n
                                                                                                                                    • [ ] Instructions clearly distinguish real ingestion, in-query synthetic data and optional integrations.<\/li>\n\n\n\n
                                                                                                                                    • [ ] Every Azure resource operation identifies the intended tenant\/workspace\/VM and appropriate permission.<\/li>\n\n\n\n
                                                                                                                                    • [ ] There is no uncontrolled public syslog listener, external malicious infrastructure, credential leak or disruptive remediation.<\/li>\n\n\n\n
                                                                                                                                    • [ ] Source and destination schemas are inspected before claiming a valid correlation.<\/li>\n\n\n\n
                                                                                                                                    • [ ] Source-linked timestamps are retained in scheduled analytics query output.<\/li>\n\n\n\n
                                                                                                                                    • [ ] TI and UEBA instructions describe current tables\/roles and optional branches.<\/li>\n\n\n\n
                                                                                                                                    • [ ] Rule, incident and metadata automation must have\u00a0observed<\/strong>\u00a0success, not only saved configuration.<\/li>\n\n\n\n
                                                                                                                                    • [ ] Workbook and DCR resources have explicit cleanup owners.<\/li>\n\n\n\n
                                                                                                                                    • [ ] Capstone grade and critical skills gate are reproducible and auditable.<\/li>\n\n\n\n
                                                                                                                                    • [ ] Instructor verifies tenant-specific menus, licensed features and cost before classroom delivery.<\/li>\n<\/ul>\n\n\n\n
                                                                                                                                      End of Microsoft Sentinel Day 3 Intermediate Gold Standard Hands-On Lab Guide.<\/strong><\/p>\n","protected":false},"excerpt":{"rendered":"
                                                                                                                                      Module 2: Intermediate | Day 3 only | Complete instructor-and-learner manual Edition: 1 November 2026Course: Microsoft Sentinel Technical Training \u2014 5-day progressive curriculumThis document: Day 3 only; prerequisite: successful completion of Foundations… <\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1266","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/1266","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=1266"}],"version-history":[{"count":2,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/1266\/revisions"}],"predecessor-version":[{"id":1274,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/1266\/revisions\/1274"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=1266"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=1266"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=1266"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}