Docs

Appearance

Arctic Wolf MDR — Scope and Coverage Gaps ​

Purpose ​

Document precisely what Arctic Wolf Managed Detection and Response (MDR) covers at Cirius Group and — equally important — what it does not cover, together with the compensating controls that close each gap. Written for IR, audit, and onboarding reference. If an asset is listed here as "out of scope for Arctic Wolf", that is a deliberate architectural decision and the compensating control is the authority for coverage of that surface.

Arctic Wolf is our MDR provider. They are the 24/7 eyes. They are not the only eyes, and they are not all-seeing. This document draws the line.

What Arctic Wolf Covers ​

Managed endpoints — Windows and macOS ​

Arctic Wolf's Agent is installed on:

  • All managed Windows VMs across Azure PROD (d477c9f8), Azure DDE (ff1c5d68), and AWS Prod/Logging/Networking accounts. Deployment via Intune policies AW-Agent-Azure-Prod / AW-Agent-Azure-DDE (Azure) and SSM document aws-agent-install-win (AWS)
  • All managed macOS laptops enrolled in Intune (MDM-pushed PKG)
  • Syslog forwarder VMs (SYSLOGAZP, SYSLOGDDE, SYSLOGAWP, SYSLOG-VM) — Windows agent present to protect the forwarder itself; the syslog stream content is separately ingested via VLC

Coverage criteria:

  • Agent deployed within 24 hours of the VM being registered in CMDB (tracked by arctic-wolf-cmdb-check.md)
  • CMDB has_aw_agent=true is the authoritative flag
  • aw_coverage_agent (4-hour cycle) flags any CMDB in-scope asset without a checking-in AW agent

Network visibility — VLCs ​

Four Virtual Log Collectors (VLCs) ingest syslog from the network perimeter and hand it to Arctic Wolf:

VLCLocationFeeds
ARCTICWOLFVLCAzure PRODPROD Palo Alto + CEF from SecOps pipeline
ARCTICWOLFVLCDDEAzure DDEDDE Palo Alto + DDE AVD telemetry
ARCTICWOLFVLCAWPAWS LoggingAWS firewall syslog + CloudTrail-adjacent
ARCTICWOLFVLCDRAWS Prod (DR)DR-site firewall, DR VM syslog

Each VLC receives syslog from the corresponding SYSLOG* forwarder VM on UDP/514 or TCP/6514 (TLS). VLCs are appliance-class — no third-party agents permitted — and are tracked in CMDB as system_type=SENSOR.

Azure control plane — full read access ​

Arctic Wolf maintains a service principal in each tenant with:

  • Reader at tenant root
  • Security Reader on the Entra tenant
  • Scoped log-read permissions on subscription management groups

Via the Arctic Wolf Azure connector, they pull:

  • Azure Activity Logs (both tenants)
  • Entra ID sign-in and audit logs (both tenants)
  • Azure AD identity risk events
  • Azure Security Center / Defender for Cloud alerts

Connector health is verified monthly per arctic-wolf-health-check.md.

Authorization model — act-first ​

Arctic Wolf has act-first authorization on containment actions for managed endpoints:

  • Isolate an endpoint from network (via agent)
  • Kill a process
  • Block a hash / prevent re-execution
  • Suspend a user session

They act first, notify Rory immediately, and document in the ticket. This was an explicit decision at MDR onboarding to eliminate response delay for obvious IR scenarios (ransomware encryption, active credential dumping). Act-first does not extend to:

  • Disabling a user account in Entra (they request, Rory approves)
  • Stopping an Azure VM (they request)
  • Applying NSG changes (they request)
  • Any change touching the control plane — always human-in-the-loop

Triage and escalation ​

  • Tier-1 triage of AW-generated alerts happens at Arctic Wolf 24/7
  • Tickets escalate to Cirius (SecOps + Telegram Rory) only when AW determines action is required
  • Tickets that AW resolves as benign are delivered as a daily summary — we review these at monthly health check to catch benign-classifications that warrant our own known-good rule

What Arctic Wolf Does NOT Cover — and Why ​

Arctic Wolf's managed-endpoint and network-telemetry model has real edges. Each surface below is explicitly out of scope for Arctic Wolf. For each, we document the compensating control that owns detection and response for that surface.

Gap 1 — Terraform state and CI/CD pipelines ​

Surface. GitHub Actions workflows in azure-infra, aws-infra, azure-dde-infra, ops-automation, bedrock-hub, palo-alto-configs, bedrock-docs. The OIDC federated credentials (github-deploy-main roles in Azure and AWS), Terraform state in Azure Storage and S3, any secret that touches CI.

Why Arctic Wolf doesn't cover it. AW's Azure connector sees the terraform apply effect in Activity Logs, but does not see the triggering PR, the workflow that ran, the state manipulation, or Actions secret use. GitHub is outside their integration scope.

Compensating controls.

  • github_audit_agent (custom agent, 4-hour cycle) — polls GitHub org audit log, alerts on: non-SHA-pinned Actions, OIDC role changes, Actions secret reads outside CI, workflow run from unexpected actor, branch protection bypass, force-push to protected branches
  • supply_chain_agent — SHA-pin verification for every Action reference in every workflow
  • Branch protection required on all infra repos (no direct pushes to main, required PR review, required status checks)
  • Terraform state storage has diagnostic logging to LAW; storage_audit_agent alerts on state reads/writes outside CI run windows
  • CM ticket creation on every merged infra PR (audit trail, suppresses legitimate control-plane deltas Arctic Wolf would otherwise flag)
  • pr_body_agent LLM-reviews PR bodies for secret exposure before merge

Audit evidence. github-audit-agent.md runbook, SecOps findings table filtered source=github_audit_agent.

Gap 2 — Palo Alto administrative plane ​

Surface. Panorama management console, the 4 firewall local admin accounts (cirius-breakglass on each — never suppressed), candidate-config changes, admin user sessions, Panorama template and device-group commits, license state.

Why Arctic Wolf doesn't cover it. No AW agent is permitted on PAN-OS. Arctic Wolf sees firewall traffic logs via VLC (the data plane) but not admin activity on Panorama or the firewalls themselves.

Compensating controls.

  • panorama_agent (custom, 4-hour cycle) — polls Panorama audit log, alerts on: commits outside change windows, new admin users, role changes, candidate- config diff not committed within 24h (stuck config), any breakglass login
  • firewall_admin_agent — polls per-firewall admin logs directly, alerts on local admin sessions, failed auth bursts
  • Panorama configuration backup every 4 hours to blob + S3 archive (palo-alto-config-backup.md)
  • Quarterly credential rotation for cirius-breakglass local admins per palo-alto-backup-credential-rotation.md
  • CM ticket required for any Panorama commit — admin activity without a CM ticket is a HIGH finding
  • Panorama admin logins route through Twingate only (no direct internet exposure; network-layer control)

Audit evidence. SecOps findings filtered source=panorama_agent and source=firewall_admin_agent.

Gap 3 — AWS CloudTrail and control-plane activity ​

Surface. CloudTrail (all 7 accounts), Security Hub findings, IAM changes, KMS key operations, S3 policy changes, GuardDuty findings, Organizations changes, AWS root account activity.

Why Arctic Wolf doesn't cover it. Arctic Wolf's AWS integration is syslog-only — they ingest what we forward to the VLC. CloudTrail's full firehose is too voluminous to forward wholesale, and its semantic value is maximized by querying in context (e.g., IAM policy evaluation, Security Hub correlation) rather than raw syslog.

Compensating controls.

  • cloudtrail_agent (custom, 4-hour cycle) — Athena queries against CloudTrail S3 archive in the Logging account, alerts on: root account usage (any), IAM policy attachments, KMS key disables, S3 bucket policy changes, CloudTrail trail modifications, access key creations for non-service users
  • aws_security_hub_agent — polls Security Hub across all accounts, surfaces NIST 800-53 R5 failing controls and HIPAA-Omnibus findings
  • aws_root_agent — every root account auth attempt = CRITICAL, no suppression, Telegram + email + SecOps incident
  • guardduty_agent — GuardDuty findings per account, severity-aware routing
  • CloudTrail is org-wide with log file integrity validation, immutable S3 object lock, 6-year retention
  • AWS Audit Manager HIPAA Omnibus framework assigned org-wide (monthly evidence export to compliance archive)

Audit evidence. SecOps findings filtered source IN (cloudtrail_agent, aws_security_hub_agent, aws_root_agent, guardduty_agent). CloudTrail integrity reports in the Logging account S3 bucket.

Summary Coverage Matrix ​

SurfaceArctic WolfCompensating control(s)
Managed Windows VMs — endpointYES (agent)N/A
Managed macOS laptops — endpointYES (agent)N/A
Palo Alto data plane (traffic)YES (VLC)N/A
Azure Activity + EntraYES (connector)N/A
Azure Defender for CloudYES (connector)N/A
GitHub / CI / Terraform stateNOgithub_audit_agent, branch protection, CM tickets
Panorama + FW admin planeNOpanorama_agent, firewall_admin_agent, CM tickets
AWS CloudTrail / IAM / KMSNOcloudtrail_agent, aws_root_agent, Security Hub, Audit Manager
AWS GuardDutyNOguardduty_agent
Break-glass account activityPartial (endpoint)Never-suppressed API block, dedicated agents
SecOps platform itselfNOpgaudit, diagnostic settings to LAW, app insights
Linux VMsPartial (syslog only)auditd, osquery (in-progress)

Break-Glass Handling — Cross-Cutting Note ​

The 18 break-glass accounts (cirius-breakglass*, AWS roots, Entra break- glass, Palo Alto local admins) are permanently unsuppressible at the SecOps API level. Arctic Wolf is not aware of the full break-glass inventory — they see endpoint-side signals only. Break-glass detection is authoritative at the SecOps layer, not at Arctic Wolf.

Any activity on a break-glass account triggers a CRITICAL SecOps incident regardless of other suppression or CM-ticket state. This is intentional and cannot be relaxed.

When a Gap Must Be Re-evaluated ​

Scope gaps get reviewed when any of the following occur:

  • A new platform component is added (new cloud, new SaaS, new firewall)
  • Arctic Wolf expands their integration surface (e.g., announces GitHub integration, CloudTrail native support)
  • A compliance framework revision names a control requiring MDR coverage of a currently-compensating surface
  • A compensating agent degrades or is retired
  • Post-incident review identifies a surface that neither AW nor a compensating control owned

Quarterly review: read this document, confirm each compensating control is still healthy (findings pipeline intact, agent last-run within SLA), update the matrix if anything has moved.

Change History ​

DateChangeAuthor
April 2026Initial scope-and-gap document — three named gaps with compensating controlsKobe

Internal use only — Cirius Group