Appearance
CMDB Guide — Cirius Group SecOps Platform
The SecOps CMDB (Configuration Management Database) is the authoritative asset registry for all managed infrastructure. It drives phi_adjacent incident escalation, EDR coverage audits, asset risk scoring, and quarterly accuracy audits. This guide defines naming standards, classification criteria, and operational procedures.
Asset Naming Standard
Rule: Asset names in the CMDB must match the bare hostname exactly — uppercase, no FQDN, no domain suffix.
| Cloud | Correct | Wrong |
|---|---|---|
Azure VM BIZWRKAZP01 | BIZWRKAZP01 | bizwrkazp01.ciriusgroup.com |
AWS EC2 ACTDIRAWP01 | ACTDIRAWP01 | actdirawp01 / ip-10-10-0-5 |
DDE VM BC-HOST-01-VM | BC-HOST-01-VM | bc-host-01-vm.ciriusdde.com |
Terraform alignment: The system field should match the Terraform resource's name_prefix or computer_name. This is what the Cortex coverage audit and CMDB accuracy audit use for normalization (_normalize() in all agent code: uppercase, strip FQDN suffix, strip long hex suffixes).
phi_adjacent Classification
phi_adjacent = true means the asset processes, stores, or transmits Protected Health Information (PHI), or has direct authenticated access to systems that do.
PHI exposure visibility on incidents is driven by this flag. Incorrect classification causes missed PHI exposure alerts on incidents.
Always True
| Category | Examples | Why |
|---|---|---|
| PROD billing and clinical servers | BIZWRKAZP01–11, BIZARCAZP01, BIZSQLAZT01, BIZFTPAZP01 | Process or store Medicare/billing PHI directly |
| PROD AD domain controllers | ACTDIRAZP01, ACTDIRAZP02, CGIADSAZP01 | Authenticate all PROD users including PHI system users |
| PROD RDGW and VPN concentrators | CGIRDPAZP01, CGIRDPAZT01 | Entry point to PROD PHI systems |
| PROD FIM and monitoring VMs | NNTFIMAZP01 | Monitor PHI system filesystems |
| DDE AVD session hosts | BC-HOST-01-VM through BC-HOST-07-VM | Medicare billing users work here — PHI in session |
| DDE AD domain controllers | ACTDIRAZC01, ACTDIRAZC02 | Authenticate DDE users who access PHI |
| DDE Entra Connect | ENTRACAZC01 | Syncs credentials for PHI system auth |
| AWS DR replicas of PROD PHI servers | ACTDIRAWP01, ACTDIRAWP02, CGIRDPAWP01, BIZFTPAWP01 | DR copies of phi_adjacent=True PROD machines |
Always False
| Category | Examples | Why |
|---|---|---|
| Syslog VMs | SYSLOGAZP, SYSLOGDDE, SYSLOGAWP, SYSLOG-VM | Log forwarding only — no PHI data |
| Arctic Wolf VLC appliances | ARCTICWOLFVLC, ARCTICWOLFVLCDDE | Appliance-class MDR sensors — no PHI storage |
| Network IP objects (PIP, EIP, NAT) | PIP-NAT-AGENTS-PROD, CIRIUSSVCSPUBLICIP | IP address records, not servers |
| Dashboard environment | All DASHBOARD assets | Customer dashboard infra — no Cirius PHI |
| HOME (user workstations) | All HOME assets | End-user devices — PHI access is transient/not stored |
| AWS network infra | CIRIUS-AWS-FW, CIRIUS-AWS-PAN | Firewall/Panorama infra — not DR replicas |
| Cloud PC / dev tools | CLOUDPC-UBUNTU-VSCODE, KOBE-CLOUD-PC | No PHI access |
Case-by-Case
| Category | Criteria |
|---|---|
PROD firewalls (CIRIUS-SVCS-FW) | True — routes traffic to/from PHI systems |
PROD Panorama (CIRIUS-SVCS-PANORAMA) | True — manages firewalls that route PHI traffic |
DDE firewalls (CIRIUS-DDE-FW) | False — routes DDE traffic but no stored PHI |
| DECOMM assets | Leave unchanged at decommission time — they were phi_adjacent when live |
| New PROD VMs | True by default unless purely infrastructure (network/monitoring tools) |
system_type Enum
| Value | When to use | Examples |
|---|---|---|
SERVER | General-purpose Windows or Linux VM | BIZWRKAZP01, ACTDIRAZP01, BC-HOST-01-VM |
FIREWALL | Palo Alto or network firewall VM | CIRIUS-SVCS-FW, CIRIUS-DDE-FW, CIRIUS-AWS-FW |
DATABASE | Dedicated database server | BIZSQLAZT01 |
SAAS | SaaS service registered as an asset | (future use) |
NETWORK | Pure network object: load balancer IP, NAT IP, EIP | PIP-NAT-AGENTS-PROD, PANORAMA-EIP |
STORAGE | Storage appliance or volume | (future use) |
None | Unknown or not yet classified | Set system_type on any asset showing None |
criticality Assignment
| Level | Criteria | Examples |
|---|---|---|
CRITICAL | Outage = PHI breach or infrastructure down for all users. Loss = irreversible data loss. | ACTDIRAZP01, BIZSQLAZT01, CGIRDPAZP01 |
HIGH | Outage = significant PHI exposure risk or major degraded capability. Affects many users. | BIZWRKAZP01–11, BC-HOST-01–07, VEEAMAZP01 |
MEDIUM | Outage = degraded capability for subset of users. PHI not directly accessible. | NNTFIMAZP01, SYSLOGAZP, CIRIUS-SVCS-FW |
LOW | Outage = minimal business impact. No PHI adjacency. | Dashboard VMs, dev tools, DR non-critical |
Heuristic: If an asset going offline would trigger a P1 incident, it is CRITICAL. If it would trigger a P2, HIGH. P3 = MEDIUM. Lower = LOW.
Upsert Script Inventory
These scripts write to the CMDB. Each uses POST /api/assets (upsert semantics — creates if new, updates all fields if existing).
| Script | Fields Written | Frequency | Auth |
|---|---|---|---|
agents/inventory/cmdb_agent.py | system, environment, system_type, phi_adjacent (partial) | Every orchestrator run (4hr) | INGEST_API_KEY |
findings/cmdb_audit_agent.py | Reads only — posts findings, does not write assets | Quarterly (Jan/Apr/Jul/Oct) | INGEST_API_KEY |
findings/cortex_coverage_agent.py | Reads only — posts findings, does not write assets | Daily | INGEST_API_KEY |
findings/cmdb_analyst_agent.py | Reads only — posts findings/incidents for stale assets | Daily | INGEST_API_KEY |
| Manual CMDB edit (UI) | Any field | On-demand | Azure AD SSO |
| New VM provisioning (deploy.yml) | Full record at provision time | Per-deploy | INGEST_API_KEY |
Field precedence: UI edits (/assets/{id}/update) always win — they set values explicitly. The upsert endpoint overwrites environment/type/criticality, so the provisioning step should set correct values from day one.
Asset Risk Score
Risk score (0–100) is calculated nightly by findings_orchestrator.py via POST /api/assets/recalculate-all.
Formula:
start = 100
for each open finding linked to this asset:
CRITICAL finding: -20
HIGH finding: -10
MEDIUM finding: -5
LOW finding: -2
for each open incident linked to this asset:
CRITICAL incident: -25
HIGH incident: -15
MEDIUM incident: -8
score = max(0, start - deductions)Staleness: If risk_score_updated is more than 7 days old, the CMDB detail page shows an amber "stale" badge. This means the findings pipeline has not run successfully in over a week — investigate job-findings-agents-prod.
Interpretation:
- 90–100: Clean asset, no significant open findings
- 70–89: Minor findings open
- 50–69: Multiple HIGH findings or one CRITICAL
- <50: Critical security posture issue — escalate
Quarterly CMDB Accuracy Audit
cmdb_audit_agent.py runs in January, April, July, and October.
What it checks:
- Cloud VMs not in CMDB → HIGH finding (
CMDB_AUDITsource). Any VM in Azure Resource Graph or AWS EC2 that has no CMDB record is a security blind spot. - CMDB assets not in cloud → MEDIUM finding. Any non-DECOMM CMDB asset with no matching cloud VM is a ghost record — update to DECOMM or investigate.
Acceptance criteria: Discrepancy rate < 5% (near-perfect coverage). After each quarterly audit, action all HIGH findings within 7 days.
When a new VM is provisioned: Add the CMDB record in the same PR as the Terraform resource. See the VM Provisioning Process section in CLAUDE.md.
Adding a New Asset Manually
Use the CMDB tab in the SecOps platform (secops.bedrockcybersecurity.org/assets/) → Add Asset button, or via API:
bash
curl -s -X POST https://soc.bedrockcybersecurity.org/api/assets \
-H "X-API-Key: $INGEST_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"system": "NEWVMAZP01",
"environment": "PROD",
"system_type": "SERVER",
"criticality": "HIGH",
"phi_adjacent": true,
"owner": "roryg@ciriusgroup.com",
"notes": "New billing workstation — added 2026-04-08"
}'Required fields: system. All others are optional but should be set at provision time.