SecOps Platform Operations Guide

⚠️ Stale — May 2026 platform split. Incident management moved to the SOC platform at soc.bedrockcybersecurity.org (repo bedrock-soc). secops.bedrockcybersecurity.org is now a read-only metrics dashboard — no database, no /api routes, Cloudflare Access auth (not MSAL). Treat this guide as historical context until rewritten; for incident triage see the SOC platform.

What It Is

The SecOps platform (secops.bedrockcybersecurity.org) is the central incident management and security operations system for Cirius Group. It does three things:

1. Receives findings from all 17 security monitoring agents every 4 hours
2. Manages incidents through their full lifecycle: NEW → OPEN → INVESTIGATING → RESOLVED
3. Stores known-good rules that suppress expected/approved activity so agents don't re-alert on the same approved events repeatedly

Everything that the monitoring agents detect flows through this platform. All analyst triage happens here. All suppression decisions live here.

---

Stack

Component	Resource	Location
Web application	ca-secops-prod (Azure Container App)	rg-logging-logs, logging subscription
Database	psql-secops-prod (PostgreSQL)	logging subscription
Container registry	ciriusagentsprod.azurecr.io	logging subscription
Key Vault	cirius-openai-kv-prod	logging subscription
Azure OpenAI	gpt-4o at cirius-openai-prod.openai.azure.com	logging subscription

URL: https://secops.bedrockcybersecurity.org

---

Authentication

Browser Access (Analyst UI)

The platform uses Azure AD SSO via MSAL PKCE — sign in with your ciriusgroup.com account. There are no separate platform credentials. If you can log in to Azure, you can log in to SecOps.

1. Go to https://secops.bedrockcybersecurity.org
2. Click "Sign in with Microsoft"
3. Complete your normal MFA challenge
4. You land on the incident dashboard

Access requires membership in the SecOps Entra group (ffdf1dcb). If you get an authorization error after SSO completes, your account is not in the group — ask Rory.

Machine-to-Machine Access (Agents)

Agents authenticate via X-API-Key header. The key is stored in Key Vault (cirius-openai-kv-prod). Agents fetch it at startup via their managed identity. Never hardcode the API key anywhere.

---

Key Workflows

Incident Triage

Incidents land in the dashboard as NEW. The Analyst Agent (automated, rules-engine) runs immediately after agents post findings and moves each incident to either:

• CLOSED — matched a known-good rule (expected activity, no action needed)
• OPEN — no known-good match, requires human review

As an analyst, your queue is OPEN incidents. For each one:

1. Review the finding: what triggered it, what source system, what severity
2. If it's real → move to INVESTIGATING, begin response per Incident Response
3. If it's a false positive → move to CLOSED with a note, then consider adding a known-good rule

Known-Good Rules

Known-good rules prevent agents from re-alerting on expected activity.

When to add a rule:

• A specific event fires repeatedly and is verified-benign
• A scheduled maintenance task generates alerts
• A specific service account does something that looks suspicious but is normal

When NOT to add a rule:

• You are not sure if the activity is benign
• The event involves a break-glass account — hard-blocked, impossible to suppress
• You want to silence a rule that fires too broadly

Only Rory can approve new known-good rules. If you believe a rule is needed, document the finding, the justification, and the proposed scope, then get approval.

Change Management Integration

Every merged PR in any infra repo auto-creates a CM ticket via POST /api/changes. The SecurityAgent checks for matching CM tickets before creating incidents — a CM ticket within a 2-hour window suppresses infrastructure-change alerts. This prevents false positives during normal Terraform deployments.

If you manually deploy something (which should be rare), create a CM ticket first:

POST /api/changes
{
  "description": "manual change description",
  "source": "manual",
  "environment": "PROD"
}

---

API Reference

The platform exposes a REST API used by agents and CI/CD pipelines.

Endpoint	Method	Used By	Purpose
/api/incidents	POST	SecurityAgent	Create a new incident
/api/ingest/findings	POST	Mini-agents	Bulk upsert findings
/api/known-good	GET	All agents	Fetch suppression rules on startup
/api/known-good/{id}/hit	POST	All agents	Report rule match (fire-and-forget)
/api/changes	POST	GitHub Actions, Kobe	Create CM ticket
/api/changes/recent	GET	SecurityAgent	Check for open CM tickets (2-hour window)
/api/maintenance/active	GET	SecurityAgent	Check for active maintenance window
/api/evidence	POST	ops-automation	Register audit evidence after S3 upload

Swagger/OpenAPI docs are available at https://secops.bedrockcybersecurity.org/docs (requires auth).

---

Incident Lifecycle

NEW
 ├── Analyst Agent matches known-good rule → CLOSED (no notification)
 └── No match → OPEN (Telegram alert if CRITICAL/HIGH)
       │
       ▼
   INVESTIGATING  (analyst picks it up in SecOps UI)
       │
       ▼
   RESOLVED

Telegram is read-only — it shows alerts but has no buttons or actions. All triage and state changes happen in the SecOps UI.

---

Troubleshooting

Platform is down / unreachable

1. Check Container App status in Azure Portal → rg-logging-logs → ca-secops-prod
2. Check recent logs: Azure Portal → Container App → Log stream
3. Check PostgreSQL: psql-secops-prod → is it running?
4. If the Container App is stopped, restart it from the portal or:

   az containerapp revision restart --name ca-secops-prod --resource-group rg-logging-logs

If SecOps is down, agents are configured to fail-open — they raise alerts and skip suppression checks. You may receive more alerts than usual until the platform is restored.

Agents not posting findings

1. Check the Container Apps Jobs in the portal:
   • job-orchestrator-cirius — PROD agents
   • job-orchestrator-cirius — DDE agents
   • job-orchestrator-cirius — AWS agents
2. Look at the most recent job execution logs for errors
3. If a job is stuck or failing, check Key Vault access and managed identity

Incident count looks wrong (too many or too few)

Too many incidents:

• A known-good rule may have expired or been removed
• A new detection agent was deployed with aggressive thresholds
• Check recent deployments for agent changes

Too few incidents:

• Agents may not be running — check job execution history
• A log source may have stopped flowing to LAW — check cirius-logging-law-central
• The Analyst Agent may be closing too aggressively — check known-good rules

Authentication errors in the UI

• Verify your Entra group membership (ffdf1dcb)
• Clear browser cookies and retry SSO
• Check if Conditional Access policy changes were deployed recently

---

Maintenance Windows

Maintenance windows suppress agent alerts during planned work. Create one before:

• Bulk Terraform deployments
• Firewall changes
• Server reboots or patching

POST /api/maintenance/active
{
  "description": "Patching PROD servers",
  "start": "2026-05-24T02:00:00Z",
  "end": "2026-05-24T04:00:00Z"
}

Agents check GET /api/maintenance/active on each run. If a window is active, SecurityAgent suppresses incident creation and logs a heartbeat instead.

---

Deployment

The platform deploys from the bedrock-hub repository via GitHub Actions on merge to main. OIDC auth to the logging subscription. Terraform state in Azure Storage.

Database migrations run automatically on container startup. If a migration fails, the Container App start will fail — check logs for alembic errors.

To force a redeploy without a code change, trigger the GitHub Actions workflow manually from the bedrock-hub repo → Actions → Deploy → Run workflow.

---

Security Notes

• The API key is never logged, never in code, never in environment variables as plaintext
• Break-glass accounts are hard-blocked at the API layer — POST /api/known-good will reject any rule whose scope includes a break-glass account identifier
• All SecOps API calls are logged to the central LAW workspace
• The platform itself is a crown jewel — compromise of SecOps would blind the monitoring system. Treat credentials and access with the same care as a firewall

---

Related Documents

• Security Monitoring Architecture — full architecture: all 17 agents, pipeline diagram, Container Apps Jobs
• Alerting Runbook — alert routing and escalation paths
• Incident Response — what to do when SecOps surfaces a real incident
• Break-Glass Procedure — emergency access procedures

---

Document History

Date	Change	Author
May 2026	Initial draft — consolidates platform details from CLAUDE.md, architecture docs, and bedrock-hub repo knowledge	Rory