Docs

Appearance

Runbook: Arctic Wolf CMDB Accuracy Check ​

Purpose ​

Arctic Wolf bills per asset and, more importantly, only monitors what it knows about. If a new VM is spun up and never registered with Arctic Wolf, it is invisible to MDR. If an asset is retired and never deregistered, Arctic Wolf alerts on it silently and we pay for it. This runbook is the process for keeping Arctic Wolf's asset list aligned with the Cirius CMDB.

The Cirius CMDB (see cmdb-guide.md) is the authoritative registry. Arctic Wolf's portal is a downstream consumer. The CMDB wins.

Scope ​

This runbook covers reconciliation between:

  • Arctic Wolf portal asset list — Arctic Wolf Concierge console → Assets
  • Cirius SecOps CMDB — secops.bedrockcybersecurity.org/cmdb, API GET /api/cmdb/assets
  • Source-of-truth Terraform resources — azure-infra/, azure-dde-infra/, aws-infra/

A resource is "in scope" for Arctic Wolf if it is:

  • A Windows VM in Azure PROD, Azure DDE, or AWS
  • A macOS laptop enrolled in Intune
  • An Arctic Wolf VLC (they self-register, but we still track in CMDB)
  • A syslog forwarder VM (SYSLOG* pattern — Arctic Wolf ingests its output)

Out of scope: Palo Alto firewalls (no AW agent permitted on PAN-OS — they contribute via syslog instead), appliance-class VMs owned entirely by a vendor, and network-layer IP objects (PIPs, EIPs).

Verification Procedure ​

Run this as part of the quarterly review checklist below, or ad hoc when a discrepancy is suspected.

Step 1 — Export Arctic Wolf asset list ​

  1. Log in to the Arctic Wolf Concierge portal
  2. Navigate to Assets → Endpoint Agents
  3. Export to CSV (button in top right). Save as /tmp/aw-assets-YYYY-MM-DD.csv on the Cloud PC
  4. Repeat for Assets → Network Sensors (covers VLCs) and append to the same CSV

Step 2 — Export CMDB asset list ​

curl -s -H "X-API-Key: $SECOPS_API_KEY" \
  "https://soc.bedrockcybersecurity.org/api/cmdb/assets?format=csv" \
  > /tmp/cmdb-assets-YYYY-MM-DD.csv

Filter to the in-scope system_type values:

  • SERVER — Azure/AWS Windows VMs, syslog VMs
  • WORKSTATION — managed laptops
  • SENSOR — VLCs (if tracked; see cmdb-guide.md)

Step 3 — Normalize names ​

Both lists must be compared against the hostname convention in cmdb-guide.md: uppercase, no FQDN, no domain suffix. The CMDB accuracy audit script (_normalize() in agent code) is already in use by the Cortex coverage audit — reuse it.

Quick normalization for manual comparison:

awk -F, 'NR>1 { n=toupper($1); sub(/\..*$/,"",n); print n }' \
  /tmp/aw-assets-YYYY-MM-DD.csv | sort -u > /tmp/aw-normalized.txt

awk -F, 'NR>1 { n=toupper($1); sub(/\..*$/,"",n); print n }' \
  /tmp/cmdb-assets-YYYY-MM-DD.csv | sort -u > /tmp/cmdb-normalized.txt

Step 4 — Diff and classify ​

comm -23 /tmp/cmdb-normalized.txt /tmp/aw-normalized.txt > /tmp/cmdb-only.txt
comm -13 /tmp/cmdb-normalized.txt /tmp/aw-normalized.txt > /tmp/aw-only.txt

Two diffs matter:

  • In CMDB, not in Arctic Wolf (cmdb-only.txt) — these assets are supposedly live Cirius resources but Arctic Wolf is not monitoring them. Each one is either an onboarding miss or a decommissioned asset still in CMDB. Neither is OK.
  • In Arctic Wolf, not in CMDB (aw-only.txt) — Arctic Wolf is monitoring something we do not know about. Either a stale AW entry, or a resource deployed outside the Terraform/CMDB process.

Step 5 — Cross-reference against Terraform ​

For each entry in both diffs, find the source of truth:

# Example: BIZWRKAZP11 in CMDB but not in AW
grep -R "BIZWRKAZP11" /home/ubuntu/src/azure-infra

The Terraform state answers three questions: does the resource exist, when was it deployed, and what tenant does it belong to. Combine that with CMDB created_at and Arctic Wolf enrollment timestamp.

Step 6 — Remediate ​

SituationAction
In CMDB, in Terraform, running, not in AWOnboard to AW — see "New Resource Onboarding" below
In CMDB, not in TerraformOpen a SecOps finding — CMDB has a ghost asset. Investigate, then update CMDB.
Not in CMDB, in AW, in TerraformAdd to CMDB (terraform resource is the new source of truth) — see cmdb-guide.md section on registering assets
Not in CMDB, in AW, not in TerraformShadow IT. Contain first, investigate origin, then onboard or decommission.
In CMDB, marked DECOMM, still in AWDeregister from AW — see "Decommission" below

Record every action in the quarterly review log so the following quarter's review can verify remediation held.

New Resource Onboarding — Add to Arctic Wolf ​

Run this within 24 hours of any new in-scope resource being deployed.

Trigger ​

A merged PR to azure-infra, azure-dde-infra, or aws-infra that introduces a new resource matching:

  • Azure azurerm_windows_virtual_machine
  • Azure windows-server module invocation
  • AWS aws_instance with OS tag windows

The CI pipeline posts a change management ticket to SecOps per the CI/CD workflow in CLAUDE.md — the new_resource_onboarding flag on the CM ticket triggers a reminder to run this runbook.

Steps ​

  1. Confirm the VM is online and healthy
    • Azure/AWS portal → VM status = running, boot diagnostics OK
  2. Install Arctic Wolf Agent
    • Azure VMs: via Intune policy AW-Agent-Azure-Prod or AW-Agent-Azure-DDE (assigned to the AzureVMs-Prod / AzureVMs-DDE dynamic group). New VMs in the dynamic group pick up the policy automatically — confirm install completed via Intune Devices → device → Apps → filter name "Arctic Wolf"
    • AWS EC2: via SSM document aws-agent-install-win — run on the new instance
    • Other Windows: MSI in Intune, same pattern
  3. Register in Arctic Wolf portal
    • Agent phones home within 15 minutes of install
    • Concierge → Assets → confirm the hostname appears
    • Tag the asset with the correct environment label (prod, dde, aws-dr)
    • Tag with role label where applicable (dc, sqlserver, avd-host, etc.)
  4. Register in Cirius CMDB
    • POST /api/cmdb/assets with hostname (normalized), system_type, phi_adjacent per cmdb-guide.md, source_system, lifecycle=permanent
    • Set has_aw_agent=true, aw_enrolled_at = enrollment timestamp
  5. Confirm coverage cycle completed
    • Wait for the next 4-hour SecOps cycle
    • The aw_coverage_agent should no longer flag the asset as missing
    • If it still flags after two cycles, escalate to Rory

Acceptance ​

Onboarding is complete when all of the following are true:

  • Arctic Wolf Concierge shows the asset with status "Connected" for at least 24 hours
  • Cirius CMDB has the asset with has_aw_agent=true
  • The aw_coverage_agent finding for the asset is closed
  • The CM ticket that triggered onboarding is marked resolved

Decommission — Remove from Arctic Wolf ​

Run this within 24 hours of a resource being destroyed in Terraform.

Steps ​

  1. Confirm the resource is actually destroyed in Terraform state (terraform state list — must be absent)
  2. In Arctic Wolf Concierge, navigate to Assets → find the hostname
  3. Mark the asset Decommissioned (uses Arctic Wolf's decommission flow, not Delete — decommission preserves historical alerts for audit)
  4. Update Cirius CMDB — set lifecycle=decommission, decommissioned_at, has_aw_agent=false
  5. Confirm on the next CMDB accuracy cycle that the asset no longer flags as orphaned

Do not delete from Arctic Wolf. Decommission. The historical record matters for the 6-year HIPAA retention.

Quarterly Review Checklist ​

Run on the first business day of each quarter. Estimated time: 60–90 minutes.

Preparation ​

  • [ ] Confirm Arctic Wolf portal access is working (SSO via Concierge)
  • [ ] Confirm SecOps API key is current ($SECOPS_API_KEY env var or Key Vault)
  • [ ] Confirm Cloud PC has network path to both systems

Asset reconciliation ​

  • [ ] Export Arctic Wolf asset list → /tmp/aw-assets-YYYY-QQ.csv
  • [ ] Export CMDB asset list → /tmp/cmdb-assets-YYYY-QQ.csv
  • [ ] Normalize both lists per Step 3 above
  • [ ] Produce cmdb-only.txt and aw-only.txt diffs
  • [ ] Confirm zero unexplained entries in each diff (every entry classified in the Step 6 table)

Metadata spot checks ​

  • [ ] Pick 5 random assets. Confirm Arctic Wolf environment tag matches CMDB source_system (PROD/DDE/AWS)
  • [ ] Pick 5 random phi_adjacent=true assets. Confirm Arctic Wolf role tag indicates PHI-adjacent class
  • [ ] Confirm all four VLCs are present in both systems and marked phi_adjacent=false

New / decommissioned since last quarter ​

  • [ ] Pull CMDB assets with created_at >= last quarter start. Confirm every one is enrolled in Arctic Wolf
  • [ ] Pull CMDB assets with decommissioned_at >= last quarter start. Confirm every one is Decommissioned in Arctic Wolf
  • [ ] Any discrepancy → open a SecOps finding, remediate, record in review log

Operational health ​

  • [ ] Confirm the aw_coverage_agent has no open findings older than 7 days
  • [ ] Confirm Arctic Wolf ingestion meter is within expected range (investigate >20% drop vs. previous quarter)
  • [ ] Verify the Arctic Wolf Azure connector shows Active in the portal for both PROD and DDE tenants

Documentation ​

  • [ ] File quarterly review summary in SharePoint Compliance → Quarterly Reviews → YYYY-QQ → arctic-wolf-cmdb-review.pdf
  • [ ] Attach the diff files and remediation log
  • [ ] Post summary to SecOps as evidence via POST /api/evidence

Change History ​

DateChangeAuthor
April 2026Initial runbook — CMDB↔AW reconciliation, onboarding, decommission, quarterly reviewKobe

Internal use only — Cirius Group