Docs

Appearance

SecOps Findings Triage Guide ​

Overview ​

This guide covers what to do when the SecOps platform shows open findings — how to read them, evaluate whether they're real, decide on the right action, and close or escalate appropriately.

For the mechanics of the SecOps platform itself (API, incident lifecycle, known-good rules) see SecOps Platform Guide.
For what to do once an incident is confirmed real see Incident Response.

The agents run every 4 hours. After each run, a summary email goes to IT admin. The SecOps UI at secops.bedrockcybersecurity.org shows all open incidents. Your job during triage is to clear the open queue: close what's noise, escalate what's real.

The Open Queue ​

Log into secops.bedrockcybersecurity.org with your @ciriusgroup.com account. The Incidents view shows everything in OPEN status — these are findings that did not match any known-good rule and have not been reviewed.

A healthy queue after a clean run is 0–3 OPEN incidents. More than 10 OPEN incidents after a run either means something real is happening or the agent is generating noise that needs a known-good rule.

Severity Reference ​

SeverityWhat It MeansDefault Action
CRITICALAgent decided this is likely real and dangerous. immediate_action_required may be set.Review within 1 hour. If you can't disprove it in 5 minutes, escalate.
HIGHMeaningful risk, not necessarily active. Could be approaching expiry, elevated activity, or a gap detected.Review same day. Investigate source before closing.
MEDIUMWorth knowing. Not urgent but warrants a look.Review within 48 hours.
LOW / INFOBackground signal. Informational.Review weekly. Batch-close if clearly benign.

CRITICAL findings with immediate_action_required: true mean the agent decided something is happening right now — don't defer these.

Triage Workflow — Step by Step ​

Step 1 — Read the Finding ​

Every incident has:

  • Severity and source system (PROD, DDE, AWS)
  • Description — what the agent detected
  • Evidence — the raw data: log lines, query results, resource names, timestamps
  • HIPAA risk — why this matters for compliance
  • Recommended action — what the agent suggests doing
  • MITRE technique/tactic — the kill chain context

Read all of it. The evidence block is the most important — it tells you exactly what was seen, not an interpretation of it.

Step 2 — Ask These Questions ​

Is the timing consistent with a legitimate business event?

  • Did anyone do planned maintenance in the last 4 hours?
  • Is there a CM ticket in SecOps for a recent infrastructure change?
  • Is this during business hours for the affected system?

Does the evidence match what the description claims?

  • Sometimes agent descriptions sound alarming but the evidence is thin (e.g., one failed login vs. 50 failed logins). Read the numbers, not just the headline.

Is this something that happens regularly?

  • If you've seen this exact pattern before and it was benign, it probably is again. But that's also the signal to add a known-good rule so you stop seeing it.

What would it look like if this were real?

  • For a credential-related finding: would you expect to see lateral movement too? Check for correlated findings from other agents in the same time window.
  • For a network finding: is there any data exfiltration signal alongside it?

Has Arctic Wolf flagged anything related?

  • Check the Arctic Wolf portal for any alerts in the same time window. Arctic Wolf operates independently and its signal is a strong confirming or disconfirming factor.

Step 3 — Investigate if Unclear ​

Don't close based on intuition alone if you're not certain. Common investigation actions:

bash
# Run a KQL query to see the raw events the agent saw
az monitor log-analytics query \
  --workspace 5d76d1f2 \
  --analytics-query "SignInLogs | where TimeGenerated between (datetime('2026-05-24T10:00:00Z') .. datetime('2026-05-24T14:00:00Z')) | where UserPrincipalName == 'user@ciriusgroup.com'"

# Check Palo Alto traffic logs for a specific IP
# Monitor → Logs → Traffic in Panorama, filter: addr.src eq <ip>

# Check Entra sign-in logs in the portal
# Entra ID → Monitoring → Sign-in logs → filter by user or IP

For cert expiry findings: check the actual expiry date in the evidence. If it's >60 days out, close as LOW priority but note the date in the finding before closing.

For AWS findings: cross-check in CloudTrail. The agent evidence usually includes the CloudTrail event ID or resource ARN.

Step 4 — Decide and Act ​

Close as known-benign:

  • You've verified this is expected activity
  • Change the status to CLOSED
  • Add an analyst note: what you verified and why it's benign
  • If this finding fires regularly: consider a known-good rule (see below)

Escalate to INVESTIGATING:

  • You cannot rule it out after 5–10 minutes of investigation
  • Something about it feels off even if you can't prove it
  • It's a CRITICAL finding that involves a privileged account, PHI system, or security control
  • Change status to INVESTIGATING, add a note with what you've checked so far
  • Notify Rory (Teams or phone)
  • Proceed with Incident Response

Add a known-good rule and close:

  • This fires repeatedly and is always benign
  • See Known-Good Rule Management below before doing this

Agent-by-Agent Triage Notes ​

cert_expiry_agent ​

What it fires on: OneLogin SAML cert expiry (<90 days) and GlobalProtect TLS cert expiry.

Common false positives: None — if it fires, the cert is actually approaching expiry.

How to triage: Look at the expiry date in the evidence. If >60 days: note the date, close LOW with a reminder to act at the 60-day mark. If <30 days: this is a real action item — assign to Rory and track to resolution.

Do not add a known-good rule for cert expiry findings. You want to keep seeing these.

Entra / Identity Agents ​

What they fire on: Unusual sign-ins (impossible travel, unfamiliar locations), MFA fatigue patterns, privileged role changes, break-glass account activity.

Break-glass account findings: NEVER close as benign. Any break-glass login is a CRITICAL finding that requires a documented explanation. If Rory used the break-glass account, he documents it in SecOps himself — look for his note. If there's no note, it's a real alert. These accounts cannot be added to known-good rules.

Impossible travel: Check if the user is on VPN or Twingate. Twingate exit nodes can appear as unusual locations. Check the Twingate access log for the same time window.

Privileged role changes: Find the corresponding CM ticket in SecOps or the Entra audit log. If there's a matching CM ticket within 2 hours, it was expected.

Network / Palo Alto Agents ​

What they fire on: DNS Security blocks (C2 callback domains), threat log spikes, unusual outbound connections, Cortex XDR silence.

DNS Security blocks: Look at the blocked domain in the evidence. Use any threat intelligence lookup (VirusTotal, etc.) to check if it's genuinely malicious. A random internal server querying a known C2 domain is real. A user visiting a miscategorized site is noise.

Cortex XDR silence (0 findings for extended period): This is a "canary in the coal mine" finding — it fires when the EDR that's supposed to be running isn't generating any events. Check Cortex XDR console directly. If the endpoints are there and healthy, close. If an endpoint disappeared from the console, investigate.

AWS / CloudTrail Agents ​

What they fire on: IAM changes, unusual API calls, S3 access patterns, Security Hub findings.

Root account activity: Always CRITICAL. There is no legitimate reason for AWS root account activity in routine operations. If you see this and Rory didn't do it, it's a real incident.

IAM policy changes: Find the CM ticket. All IAM changes go through Terraform via GitHub Actions. If there's a matching merged PR and CM ticket, it's expected.

S3 access from unexpected IPs: Check the source IP. AWS Lambda and internal services use instance metadata IPs. External IPs accessing backup buckets with Object Lock enabled should be investigated.

Operational Agents (backup, VM status, log retention) ​

What they fire on: VMs not running that should be, log retention below threshold, backup jobs not completing.

These are generally actionable, not false positives. A VM that should be running but isn't either stopped itself or someone stopped it. Find out which.

Backup failures: Check Veeam console for the most recent job result. If the last backup was >36 hours ago, investigate immediately — this is the RPO erosion signal.

Known-Good Rule Management ​

A known-good rule tells SecOps "this specific pattern is approved and expected — don't open an incident for it." Use them to reduce noise from repeat benign findings, not to suppress things you're unsure about.

Criteria — When to Add a Rule ​

A finding qualifies for a known-good rule if ALL of the following are true:

  1. It has fired at least 3 times
  2. You have verified each time that it's genuinely benign (not just assumed)
  3. The underlying behavior is expected to continue indefinitely
  4. The rule scope is specific — not "ignore all failed logins", but "ignore failed logins from svc-backup@ciriusgroup.com to the backup storage endpoint during 02:00–04:00"

How to Request a Rule ​

You cannot add known-good rules yourself — only Rory approves them.

  1. In the SecOps incident, add an analyst note: "Proposed for known-good rule — [finding pattern], verified benign [N] times, justification: [reason]"
  2. Tag or message Rory directly
  3. Rory reviews and creates the rule via the SecOps admin interface
  4. Once the rule is active, the next agent run will auto-close future matching incidents

What Cannot Have Known-Good Rules ​

  • Any activity from break-glass accounts (hard API block — the platform will reject these)
  • AWS root account activity
  • Security control modification (disabling MFA, modifying CA policies, disabling logging)
  • First-time activity from any account (by definition can't be "expected")

When to Call Arctic Wolf ​

Arctic Wolf MDR is your 24/7 incident response partner. Call them when:

  • You have a CRITICAL finding you cannot disprove and Rory is unreachable
  • You see correlated findings across multiple agents suggesting an active attack
  • You need a second opinion on whether something is real
  • You've declared an incident and need IR support

Arctic Wolf contact: Arctic Wolf portal → Concierge Security Team or the phone number in Keeper → Emergency Contacts → Arctic Wolf.

They have act-first authorization — they don't need your approval to take containment actions on your behalf during an active incident.

After Triage — Documentation ​

After clearing the queue, add a brief triage note to any incident you closed:

  • What you checked
  • Why you determined it was benign (or not)
  • Any follow-up action needed (cert renewal, rule request, etc.)

This note is the audit trail. For SOC2 CC7.1/CC7.2, auditors will ask how findings are reviewed and resolved — the analyst notes in SecOps are that evidence.

Document History ​

DateChangeAuthor
May 2026Initial draft — triage workflow, severity reference, per-agent triage notes, known-good rule criteria, Arctic Wolf escalation, audit documentation.Rory

Internal use only — Cirius Group