🔒 Security Baseline & Compliance Posture¶

Security baseline validation is your operational IT risk equivalent of SOC 2 compliance — discover your security posture across CloudTrail logging, GuardDuty findings, certificate inventory, and root account MFA status, then validate evidence trail ≥99.5% for APRA CPS 234 compliance.

For CxO — what security baseline tells you in 60 seconds

Security baseline covers your AWS account's operational IT risk posture: whether CloudTrail is logging in all regions, whether GuardDuty is enabled and catching findings, whether certificates will expire within 30 days, and whether root account MFA is enabled. These checks validate APRA CPS 234 §36 (operational IT risk governance), SOC 2 CC6 (logical access controls), and NIST CSF 2.0 PR.AC (identity management and access control). Running this baseline monthly provides regulatory-auditable evidence that your AWS security controls are in place and incident response pipelines are active.

Why it matters to you: (1) Regulatory compliance — APRA CPS 234 §36 requires traceable, dated exports of your security posture before quarter-end audit. (2) Risk visibility — these 4 KPIs tell you whether critical findings are being detected and whether CISOs are alerted before incidents escalate. (3) Incident response velocity — if GuardDuty findings accumulate unreviewed, your forensics capability is blind. Running this baseline monthly ensures your security model reflects reality and your remediation pipeline is not saturated.

📊 Governance Posture Snapshot¶

Board-meeting screenshot — 4 KPIs at a glance

Security KPI	Verdict trigger	Evidence file
SecurityHub CRITICAL findings	🟢 =0 findings · 🟡 1–5 findings (investigate) · 🔴 >5 findings (critical risk — escalate)	`tenants/b2b-energy/raw/security/security-findings-${DATE}.csv`
GuardDuty active findings	🟢 <10 findings · 🟡 10–50 findings (investigate, may be legitimate) · 🔴 >50 findings (detection saturation — escalate)	`tenants/b2b-energy/raw/security/guardduty-findings-${DATE}.csv`
Certificate expiry in next 30d	🟢 0 expiring · 🟡 1–2 certs (renewal in progress) · 🔴 >2 certs (renewal failure — escalate)	`tenants/b2b-energy/raw/security/cert-inventory-${DATE}.csv`
Root account MFA enabled	🟢 enabled · 🟡 enabled but age unknown · 🔴 disabled (critical control gap)	`tenants/b2b-energy/raw/security/iam-root-mfa-${DATE}.csv`

Why This Matters¶

Risk Audit Equivalent: Your CISO reviews security findings monthly the same way your CFO closes P&L monthly. Without dated, verified security exports, you have no audit proof for compliance. These 4 CSVs are your risk ledger.

Incident Signal: Security findings are your most actionable risk signal — a GuardDuty finding on 2026-05-20 may indicate lateral movement that, if investigated within 24 hours, stops a data breach. These commands surface findings within hours of occurrence, not weeks later in a quarterly audit.

🛠️ Operational Paths — Generate the Evidence¶

Path 1 — runbooks CLI (recommended)Path 2 — Claude command (agentic)Path 3 — AWS CLI (raw / fallback)

Category	Profile	Commands	Total Duration	Output
Security baseline + threat detection	`$AWS_OPERATIONS_PROFILE`	4 discovery calls (loop below)	~45s	4 dated CSVs in `tenants/b2b-energy/raw/security/`

# Run All — refresh all 4 security baseline datasets
DATE=$(date +%Y-%m-%d)
OUT=tenants/b2b-energy/raw/security
mkdir -p "$OUT"
for CMD in \
    "security cert-inventory --format csv" \
    "security host-findings --format csv" \
    "security remediate-findings --format csv" \
    "cert dns-check --format csv"; do
  NAME=$(echo "$CMD" | awk '{print $1"-"$2}' | tr - _)
  uv run runbooks $CMD \
    --profile $AWS_OPERATIONS_PROFILE \
    --output "$OUT/${NAME}-${DATE}.csv" 2>&1
done

Run individual commands instead (for debugging one dataset)

# From project root
cd /Volumes/Working/projects/command-center

uv run runbooks security cert-inventory \
  --profile $AWS_OPERATIONS_PROFILE \
  --format csv \
  --output tenants/b2b-energy/raw/security/cert-inventory-$(date +%Y-%m-%d).csv

uv run runbooks security host-findings \
  --profile $AWS_OPERATIONS_PROFILE \
  --format csv \
  --output tenants/b2b-energy/raw/security/host-findings-$(date +%Y-%m-%d).csv

uv run runbooks security remediate-findings \
  --profile $AWS_OPERATIONS_PROFILE \
  --format csv \
  --output tenants/b2b-energy/raw/security/remediate-findings-$(date +%Y-%m-%d).csv

uv run runbooks cert dns-check \
  --profile $AWS_OPERATIONS_PROFILE \
  --format csv \
  --output tenants/b2b-energy/raw/security/dns-check-$(date +%Y-%m-%d).csv

Use the Claude security orchestrators for autonomous threat detection with ADLC governance:

/aws:security-posture
/security:cert-inventory
/security:sast

Then in Claude session with $AWS_OPERATIONS_PROFILE configured:

Each command handles pagination, MCP cross-validation, threat inference, and audit trail capture in tmp/command-center/coordination-logs/.

Why use Claude commands: Automatic finding prioritization (CRITICAL > HIGH > MEDIUM), MCP risk-scoring for unfamiliar threat patterns, APRA CPS 234 audit trail capture, multi-region aggregation.

For direct API validation or when runbooks CLI is unavailable, these sample commands verify core security findings:

# SecurityHub CRITICAL findings
aws securityhub get-findings \
  --filters '{"Severity": [{"Value": "CRITICAL", "Comparison": "EQUALS"}]}' \
  --profile $AWS_OPERATIONS_PROFILE \
  --output json | jq '.Findings | length'

# GuardDuty active findings (last 7 days)
aws guardduty list-findings \
  --region us-east-1 \
  --profile $AWS_OPERATIONS_PROFILE \
  --output json

# ACM certificates expiring in next 30 days
aws acm list-certificates \
  --profile $AWS_OPERATIONS_PROFILE \
  --output json | jq '.CertificateSummaryList[] | select(.DomainName != null)'

# IAM root account MFA status
aws iam get-account-summary \
  --profile $AWS_OPERATIONS_PROFILE \
  --output json | jq '.SummaryMap | {MFADevices, AccountAccessKeysPresent}'

Reference: For all 4 commands, uv run runbooks security <cmd> --help displays the underlying boto3 call and parameter documentation.

Expected Output — 4 CSV Files

Output location: tenants/b2b-energy/raw/security/ · Date suffix: $(date +%Y-%m-%d)

Why these 4 datasets map to the CMDB: Every security control in your ServiceNow risk registry must trace back to a dated source-of-truth export — the CMDB/CSDM mapping column in each tab below shows which Operational IT Risk CI or Information Security Service CI each field lands in. Missing tabs = blind spots in the risk registry that block APRA CPS 234 §36 audit responses.

Certificate InventoryHost FindingsRemediation CandidatesDNS & Certificate Validation

Source: runbooks cert cert-inventory --format csv · File: cert-inventory-*.csv

Field	Description	Example	CMDB/CSDM CI Mapping
`certificate_id`	ACM certificate identifier	`arn:aws:acm:${AWS_DEFAULT_REGION}:${AWS_ACCOUNT_ID}:certificate/cert-id-uuid`	`cmdb_ci_ssl_certificate.resource_id`
`domain_name`	Primary domain	`api.example.com`	`cmdb_ci_ssl_certificate.domain_name`
`expiry_date`	ISO-8601 expiration	`2026-06-15`	`cmdb_ci_ssl_certificate.expiry_date`
`days_until_expiry`	Days remaining	`25`	`cmdb_ci_ssl_certificate.days_remaining`
`status`	Certificate status	`ISSUED`	`cmdb_ci_ssl_certificate.operational_status`
`account_id`	AWS account	`${AWS_ACCOUNT_ID}`	`cmdb_ci_cloud_service_account.account_id`

Source: runbooks security host-findings --format csv · File: host-findings-*.csv

Field	Description	Example	CMDB/CSDM CI Mapping
`finding_id`	SecurityHub/GuardDuty finding ID	`arn:aws:securityhub:${AWS_DEFAULT_REGION}:${AWS_ACCOUNT_ID}:security-control/...`	`u_cmdb_ci_security_event.finding_id`
`resource_type`	AWS resource class	`AwsEc2Instance`	`cmdb_ci_cloud_instance.type`
`resource_id`	EC2/RDS/S3 identifier	`i-0a1b2c3d4e5f6g7h8`	`cmdb_ci_cloud_instance.resource_id`
`severity`	Finding severity	`CRITICAL`	`u_cmdb_ci_security_event.severity`
`finding_type`	Classification	`PCI.EC2.2 — EBS encryption`	`u_cmdb_ci_security_event.finding_type`
`first_observed_at`	Discovery date	`2026-05-20`	`u_cmdb_ci_security_event.first_observed_at`
`account_id`	AWS account	`${AWS_ACCOUNT_ID}`	`cmdb_ci_cloud_service_account.account_id`

Source: runbooks security remediate-findings --format csv · File: remediate-findings-*.csv

Field	Description	Example	CMDB/CSDM CI Mapping
`resource_id`	Resource with remediable finding	`sg-0abc1234def5gh678`	`cmdb_ci_cloud_instance.resource_id`
`resource_type`	AWS resource class	`SecurityGroup`	`cmdb_ci_cloud_instance.type`
`finding`	Remediable issue	`Security group allows unrestricted ingress 0.0.0.0/0`	`u_cmdb_ci_security_event.finding_type`
`remediation_action`	Recommended fix	`Remove ingress rule; restrict to 10.0.0.0/8`	`u_cmdb_ci_security_event.remediation_action`
`severity`	Impact if unremediates	`CRITICAL`	`u_cmdb_ci_security_event.severity`
`account_id`	AWS account	`${AWS_ACCOUNT_ID}`	`cmdb_ci_cloud_service_account.account_id`

Source: runbooks cert dns-check --format csv · File: dns-check-*.csv

Field	Description	Example	CMDB/CSDM CI Mapping
`domain_name`	Domain being validated	`api.example.com`	`cmdb_ci_ssl_certificate.domain_name`
`record_type`	DNS record class	`CNAME`	`cmdb_ci_dns_record.record_type`
`current_target`	Current DNS resolution	`api-load-balancer.example.com`	`cmdb_ci_dns_record.target`
`certificate_match`	Does cert CN match domain?	`MATCH`	`cmdb_ci_ssl_certificate.validation_status`
`validation_date`	Last validation run	`2026-05-20`	`cmdb_ci_dns_record.last_validated`
`account_id`	AWS account	`${AWS_ACCOUNT_ID}`	`cmdb_ci_cloud_service_account.account_id`

🧭 How This Data Becomes the CMDB¶

Downstream flow — raw security data → CSDM risk hierarchy → ServiceNow CMDB

This page's CSV exports are the first step in a 4-stage pipeline that lands in your risk-tracking CMDB:

flowchart LR
  A["raw/security/*.csv<br/>(4 CSV files)"] -->|V1 ingest| B["tenants/b2b-energy/inputs/<br/>security_findings.csv"]
  B -->|V4 transform| C["_base/transforms/snow/<br/>cmdb_ci_security_event.j2"]
  C -->|CSDM publish| D["(ServiceNow CMDB<br/>u_cmdb_ci_security_event table<br/>+ cmdb_ci_ssl_certificate)"]

The flow explained: - V1 (ingest): Raw CSVs are validated and deduplicated into unified security findings inventory. - V4 (transform): The Jinja2 template transforms security data into ServiceNow CMDB risk records (which system had findings, when, severity, remediation status). - CSDM publish: Reconciliation script imports risk records into your ServiceNow instance for incident tracking + compliance reporting.

Data lineage authority: CC-ADR-014 (4-way cross-validation; V4 native-API is ground truth). Regulatory requirement: APRA CPS 234 §36 mandates monthly security posture export before quarter-end close; these CSVs ARE that evidence.

🔧 SRE Detail¶

Prerequisites & Environment Variables

Before running the security discovery commands, ensure your SSO session is active and you have SecurityHub/GuardDuty access configured:

aws sts get-caller-identity --profile $AWS_OPERATIONS_PROFILE

# Expected output: Account ID, UserId, ARN of operations account

Required environment variables:

Variable	Value	Purpose
`AWS_OPERATIONS_PROFILE`	Your AWS operations profile (required)	All security API calls must run against the operations/centralised-ops account
`AWS_DEFAULT_REGION`	AWS region (e.g., `us-east-1`)	Primary region for SecurityHub queries (SecurityHub aggregates multi-region findings)
`TENANT`	`b2b-energy` (default for output directory routing)	Output CSV files route to `tenants/b2b-energy/raw/security/`

Important notes: - SecurityHub API access is restricted to the operations account — no cross-account substitution. - GuardDuty findings are region-specific; run in all enabled regions or aggregate via SecurityHub. - Certificate expiry checks use ACM APIs scoped to the operations account. - Pagination: SecurityHub returns up to 100 items per page; runbooks CLI handles pagination automatically. - This is a READONLY operation; no account changes occur.

Common Issues & Troubleshooting

AccessDenied on SecurityHub API - Verify profile is scoped to AWS operations/centralised-ops account — this API is only available in the designated security account - Check: aws sts get-caller-identity --profile $AWS_OPERATIONS_PROFILE — Account ID should be your operations account - Grant user SecurityHub read-only permissions (SecurityAuditRole or SecurityHubReadOnlyAccess IAM policy) - If you see "User is not authorized to call SecurityHub", your IAM user role is missing the policy

Empty CSV (0 findings) - SecurityHub disabled in region (OK — valid state; means no security monitoring configured) - GuardDuty disabled (OK — valid state; means threat detection is not active) - Zero CRITICAL findings (OK — means no critical-severity threats detected) - Certificate inventory empty (OK — means no ACM certificates in use)

GuardDuty findings >50 - Review severity distribution: are these LOW-confidence findings or HIGH-confidence threats? - Check finding age: if all findings are >30 days old, they may be pre-existing baseline - Verify GuardDuty has >7 days of detection data (new accounts show elevated findings initially)

Related commands (advanced security scenarios)

For security operations beyond baseline assessment, these commands extend the toolkit:

# Automated threat remediation (requires HITL approval for high-risk actions)
uv run runbooks security remediate-findings \
  --profile $AWS_OPERATIONS_PROFILE \
  --auto-remediate-low-risk

# SAST (static application security testing) integration with CI/CD
uv run runbooks security sast \
  --scan-repo . \
  --format json

These commands are optional for the monthly baseline process but highly recommended for proactive threat management (automated remediation can reduce MTTR from days to hours for low-risk findings).

Last Updated: 2026-05-21 | Scope: READONLY AWS SecurityHub, GuardDuty, ACM, IAM APIs only — no mutations | Companion: baseline.md for remediation playbooks.

For questions on certificate renewal, security finding remediation, or CMDB integration, see CC-ADR-014 and the Command-Center security documentation.