| name | orca-alert-triage |
| description | Analyzes Orca Security alerts with timeline visualization, risk assessment, and progressive disclosure. Use when user asks to triage, analyze, explain, summarize, investigate, or check an Orca alert by ID (e.g., "triage orca-3636513", "what is alert orca-3548863", "check orca-3636513"). |
Orca Alert Triage Skill
Formats Orca Security alerts into analyst-friendly summaries with behavioral timelines, risk analysis, and progressive disclosure of investigation steps.
Usage
/orca-alert-triage <alert-id>
/orca-alert-triage orca-3636513
/orca-alert-triage orca-3548863
Or natural language:
- "triage alert orca-3636513"
- "explain orca-3548863"
- "analyze alert orca-3636513"
What This Skill Does
- Fetches alert data from Orca Security via MCP
- Analyzes timeline to identify behavioral patterns and remediation blockers
- Calculates blast radius by checking related assets and correlation
- Formats output with progressive disclosure (summary first, details on request)
- Provides contextual recommendations based on alert type and severity
Output Format
Initial Summary (Always Shown)
═══════════════════════════════════════════════════════════════════
ALERT TITLE
═══════════════════════════════════════════════════════════════════
VERDICT: <assessment> | CONFIDENCE: <percent> | ACTION: <what to do> | TIMELINE: <when>
───────────────────────────────────────────────────────────────────
ALERT TIMELINE
───────────────────────────────────────────────────────────────────
BEHAVIORAL PATTERN / VULNERABILITY LIFECYCLE:
[Visual timeline with key events]
RECURRENCE: <pattern analysis>
ESCALATION: <status change summary>
RED FLAGS: <critical indicators if present>
───────────────────────────────────────────────────────────────────
WHAT HAPPENED
───────────────────────────────────────────────────────────────────
[2-3 sentence summary of the alert]
───────────────────────────────────────────────────────────────────
WHY IT MATTERS
───────────────────────────────────────────────────────────────────
Risk Level: <severity> (Orca Score: X.X)
BEHAVIORAL ASSESSMENT / SEVERITY FACTORS:
[Risk indicators with ✓/✗ symbols]
BLAST RADIUS:
• Affected Assets: X
• Alert History: [correlation]
• Environment: [prod/dev/test]
• Impact: [description]
BUSINESS IMPACT: [concise statement]
═══════════════════════════════════════════════════════════════════
Follow-up options:
- Reply with "investigate" for investigation checklist
- Reply with "evidence" for detailed references
- Reply with "remediate" for remediation steps
- Reply with "correlate" for related alerts
Progressive Disclosure Sections (On Request)
Investigation Checklist (investigate):
- Pre-investigation verification steps
- CloudTrail/audit log queries with actual commands
- Correlation checks
- Clear escalation criteria with team/channel info
Evidence & References (evidence):
- Alert metadata (IDs, rules, timestamps)
- Anomaly context details
- Direct links (Orca, AWS Console, etc.)
- MITRE ATT&CK mappings
Remediation Steps (remediate):
- Immediate actions
- Patching/fix instructions
- Verification commands
- Rollback procedures if needed
Correlation Analysis (correlate):
- Related alerts on same asset
- Similar alerts across environment
- Attack campaign indicators
- Historical pattern analysis
Alert Processing Logic
1. Fetch Alert Data
Tools: get_alert, get_alert_timeline, get_asset_alerts_count_grouped_by_risk_level
2. Determine Alert Category
- Anomaly Detection: Behavioral analysis focus
- Vulnerability (CVE): Exploitability and patch status focus
- Misconfiguration: Compliance and fix complexity focus
- Malware/Threat: Incident response focus
3. Timeline Analysis
Analyze event_log for:
- Duration open: First detection → current time
- Recurrence pattern: Single event vs repeated
- Status changes: Count and pattern (closed→reopened = friction)
- Manual interventions: User actions indicate organizational issues
- Integration health: Which notifications succeeded/failed
Key patterns to identify:
Pattern Interpretation
────────────────────────────────────────────────────────────────
Single event, no recurrence Likely benign/false positive
Open > 7 days, no action Ownership/priority issue
Closed → Reopened same day Premature closure, issue persists
Multiple dismiss/reopen Remediation blockers/disagreement
Failed notifications Integration health problem
4. Risk Assessment
Calculate confidence level based on:
-
Anomaly alerts:
- Same tool family = High confidence benign
- Minor version change = High confidence benign
- Completely new tool = Low confidence, investigate
- Multiple anomalies same timeframe = Medium confidence threat
-
Vulnerability alerts:
- CVSS + Orca Score + EPSS + Exposure + Data sensitivity
- Exploit in wild = Critical regardless of CVSS
- Public facing + High CVSS = Critical
- Internal + No exploit = Medium/Low priority
-
Misconfiguration alerts:
- Compliance framework impact
- Data exposure risk
- Privilege escalation potential
5. Blast Radius Calculation
Query for:
1. Asset alert count (get_asset_alerts_count_grouped_by_risk_level)
2. Similar alerts (discovery_search with same alert type + timeframe)
3. Asset context (permissions, exposure, sensitive data)
4. Related assets (same vulnerability/misconfiguration pattern)
Format as:
BLAST RADIUS:
• Affected Assets: X [type]
• Alert History: Clean | N alerts | Targeted
• Correlation: Isolated | Part of pattern (N similar alerts)
• Environment: Production | Dev | Test
6. Verdict Generation
Verdict Formula:
IF severity = critical AND (exploit_available OR exposure = public) THEN
"Active Threat"
ELSE IF anomaly AND single_occurrence AND same_tool_family THEN
"Likely Benign"
ELSE IF vulnerability AND fix_available AND NOT exploited THEN
"Patchable Risk"
ELSE IF status_changes > 3 AND duration > 7d THEN
"Remediation Blocked"
ELSE
"Requires Investigation"
Confidence Calculation:
Start: 50%
+ Same tool family (anomaly): +30%
+ Minor version bump: +20%
+ Clean baseline 30+ days: +15%
+ No correlation with suspicious activity: +15%
+ Single occurrence: +10%
OR
+ Known CVE with CVSS: +40%
+ Public exploit available: +30%
+ Verified by multiple sources: +20%
Cap at: 100%
Floor at: 30%
Timeline Guidance:
Severity Public Facing Exploited Timeline
──────────────────────────────────────────────────
Critical Yes Yes NOW (immediate)
Critical Yes No 4 hours
Critical No Yes 24 hours
High Yes - 48 hours
Medium - - 1 week
Low - - 2 weeks
Info - - Review on close
Follow-up Command Handlers
When user replies with keywords, provide the appropriate section:
"investigate" / "investigation" / "how to investigate"
Two-phase approach — gather data from Orca first, then suggest external actions only for gaps.
Phase 1: Automated investigation using Orca data (do this BEFORE showing anything to the user)
Query Orca MCP tools to gather as much context as possible:
- Asset deep-dive — use
get_asset_by_id to get full asset details (permissions, exposure, tags, configuration)
- Alert correlation — use
get_asset_alerts_count_grouped_by_risk_level to see what else is firing on this asset
- Related alerts — use
discovery_search to find:
- Other alerts on the same asset (e.g., same IAM user, same VM, same domain)
- Similar alert types across the environment (e.g., all "MFA disabled" alerts, all "exposed tool" alerts)
- Alerts in the same account/subscription in the same timeframe
- Cloud logs & runtime events — if available via Orca, check:
- CloudTrail events / Azure Activity Log / GCP Audit Log tied to the asset
- Runtime events (process execution, network connections, file changes)
- Login/authentication events for the identity
- Asset relationships — check what the asset has access to, what connects to it, lateral movement paths
Synthesize all findings into a structured investigation report:
═══════════════════════════════════════════════════════════════════
INVESTIGATION REPORT — <alert-id>
<alert title>
═══════════════════════════════════════════════════════════════════
───────────────────────────────────────────────────────────────────
FINDINGS FROM ORCA DATA
───────────────────────────────────────────────────────────────────
ASSET CONTEXT:
[Full asset details — permissions, exposure, config, relationships]
ALERT CORRELATION:
[Other alerts on this asset — grouped by risk level]
[Pattern: isolated finding vs. part of a cluster]
RELATED ACTIVITY:
[Cloud logs, runtime events, login history from Orca]
[Suspicious vs. expected activity]
VERDICT UPDATE:
[Did investigation change the initial verdict? Why?]
───────────────────────────────────────────────────────────────────
GAPS — What Orca data could NOT answer
───────────────────────────────────────────────────────────────────
[Only if there are real gaps after Phase 1]
[ ] <specific action> — why it's needed, what to look for
<runnable command or console URL>
ESCALATION CRITERIA:
[When to escalate based on what was found AND what gaps remain]
═══════════════════════════════════════════════════════════════════
Phase 2: External investigation steps (only for gaps)
Only suggest manual commands or external tool queries when Orca data is insufficient. Examples of valid gaps:
- Orca doesn't have CloudTrail/audit logs for the specific timeframe
- Need to verify current state (is the issue still present right now?)
- Need data from systems Orca doesn't cover (email, Slack, ticketing details)
- Need to check external breach databases
When suggesting external steps, always:
- Explain WHY Orca data was insufficient for this specific check
- Provide runnable commands with actual values pre-filled from the alert
- Include what to look for in the output (not just "review the logs")
"evidence" / "references" / "details"
Show EVIDENCE & REFERENCES:
- Alert metadata
- Anomaly context (baseline vs new values)
- Event IDs and evidence room links
- All relevant URLs (Orca, AWS Console, etc.)
- MITRE ATT&CK mapping if applicable
"remediate" / "fix" / "patch"
Two-step flow — always ask for format first, then generate output.
Step 1: Ask the user how they want the remediation delivered.
Use AskUserQuestion to present format options. The available options depend on the alert's cloud provider and asset type:
| Option | When to offer | Description |
|---|
| Step-by-step instructions | Always | Console walkthrough with manual steps |
| Terraform | Always (cloud resources) | HCL code to fix the misconfiguration or harden the resource |
| CloudFormation | AWS alerts only | CFN template (YAML) to remediate |
| Azure Resource Manager (ARM) | Azure alerts only | ARM/Bicep template to remediate |
| Pulumi | Always (cloud resources) | Pulumi code (TypeScript) to remediate |
| CLI commands | Always | Cloud CLI commands (aws/az/gcloud/cf) to run directly |
Only show options relevant to the alert's cloud provider. For example:
- Azure alert → offer: Instructions, Terraform, ARM/Bicep, CLI commands (az)
- AWS alert → offer: Instructions, Terraform, CloudFormation, CLI commands (aws)
- GCP alert → offer: Instructions, Terraform, CLI commands (gcloud)
- Cloudflare alert → offer: Instructions, Terraform, CLI commands (cf/curl)
- Multi-cloud / other → offer: Instructions, Terraform, CLI commands
Step 2: Generate remediation in the selected format and write to file.
After the user selects a format, generate the remediation and always write code/template/script output to a file using the Write tool. Use a sensible filename based on the alert ID and format:
- Terraform →
remediate-<alert-id>.tf
- CloudFormation →
remediate-<alert-id>.cfn.yaml
- ARM/Bicep →
remediate-<alert-id>.bicep
- Pulumi →
remediate-<alert-id>.ts
- CLI commands →
remediate-<alert-id>.sh
- Step-by-step instructions → display inline (no file needed)
Write the file to the current working directory. After writing, show a summary of the remediation with the file path, and display the key sections (immediate actions, verification, prevent recurrence) inline. The user can then review and apply the file.
Structure the inline summary as:
═══════════════════════════════════════════════════════════════════
REMEDIATION — <alert-id> (<selected format>)
<alert title>
═══════════════════════════════════════════════════════════════════
IMMEDIATE ACTIONS:
[blocking/isolation steps if critical]
FIX:
[full remediation in the selected format — code block for IaC/CLI]
VERIFICATION:
[commands to confirm the fix worked]
PREVENT RECURRENCE:
[guardrails to avoid regression]
═══════════════════════════════════════════════════════════════════
For each format, the content should be:
Step-by-step instructions: Console walkthrough matching Orca's RemediationConsole field, enriched with context from the alert.
Terraform: Complete .tf snippet that remediates the finding. Include provider block, resource/data blocks, and comments explaining each setting. Use the alert's asset details (IDs, names, regions) to pre-fill values where possible.
CloudFormation / ARM / Bicep: Complete template with parameters, resources, and outputs. Pre-fill known values from the alert.
Pulumi: TypeScript Pulumi program with imports, resource definitions, and exports.
CLI commands: Runnable shell commands with actual values from the alert (asset names, IDs, regions). Include verification commands at the end.
Always include at the end:
VERIFICATION:
[ ] Run verification command(s) provided above
[ ] Wait for next Orca scan or trigger manual rescan
[ ] Confirm alert status changes to closed
"correlate" / "related" / "similar"
Query and show:
discovery_search: <alert-type> in last 7 days
- Similar alerts: X found
- Pattern: Isolated | Widespread | Targeted
- Affected accounts: [list]
- Recommendation: [based on pattern]
Error Handling
If MCP query fails:
⚠️ Unable to fetch alert data for <alert-id>
Possible reasons:
• Alert ID not found (check spelling: orca-XXXXXXX)
• MCP authentication expired
• Network connectivity issue
Try:
1. Verify alert ID in Orca UI
2. Check MCP status: `claude mcp list`
3. Re-authenticate if needed
Best Practices
DO:
✅ Start with verdict (decision first, details second)
✅ Use visual timeline with symbols (●, ├─, └─, ⚠️)
✅ Show clear next actions with timelines
✅ Provide runnable commands, not generic advice
✅ Highlight red flags prominently
✅ Progressive disclosure (offer investigation steps, don't force them)
✅ Calculate confidence level transparently
DON'T:
❌ Dump all data at once
❌ Use excessive emojis (limit to critical indicators only)
❌ Include irrelevant details (asset creation date unless relevant)
❌ Provide generic recommendations ("review the logs")
❌ Skip the timeline (it shows critical behavioral patterns)
❌ Overuse technical jargon without context
Example Outputs
Low-Severity Anomaly (orca-3636513)
Initial output: 15-20 lines with verdict, timeline, what happened, why it matters
User types: "investigate"
Follow-up: Investigation checklist with CloudTrail queries
Result: Analyst closes alert in ~2 minutes
Critical Vulnerability (orca-3548863)
Initial output: 25-30 lines with RED FLAGS section
Automatic: Show remediation urgency ("NOW")
Timeline shows: 39 days open, multiple status changes (friction indicator)
User types: "remediate"
Follow-up: Specific patching steps for Log4j
Result: Analyst escalates with full context
Required MCP Tools
This skill requires the Orca Security MCP server. Below is the tested tool reference with correct parameter names and known issues.
Verified Working Tools
| Tool | Parameters | Notes |
|---|
get_alert | alert_id (string, e.g. "orca-1234") | Primary alert data. Returns full alert with RiskFindings, ScoreVector, Inventory, AssetData. |
get_alert_timeline | alert_id (string) | Returns event_log array with status changes, notifications, score overrides. |
get_asset_by_alert_id | alert_id (string) | Get the asset tied to an alert. |
get_asset_by_id | asset_id (UUID or asset_unique_id), optional model_type | Full asset details. Use the Inventory id field (UUID), NOT asset_unique_id. |
get_asset_by_name | asset_name (substring), optional model_type, name_match_limit | Search by name substring. May return multiple results. |
get_asset_related_alerts_summary | asset_id (UUID) | Top 50 alerts on this asset. Key for investigation — returns related alerts with RiskFindings including CloudTrail events. |
get_asset_related_attack_paths_summary | asset_id (UUID) | Attack paths connected to the asset. |
get_asset_crown_jewel_info | group_unique_id (string) | Check if asset is a crown jewel. Use the GroupUniqueId or cluster_unique_id from alert data. |
discovery_search | search_phrase (natural language), optional limit (1-10) | Natural language search across Orca data. Use for finding similar alerts, related assets, etc. |
Known Issues & Gotchas
get_asset_alerts_count_grouped_by_risk_level: Requires asset_id as a UUID. Using asset_unique_id format (e.g., "AwsUser_506464807365_...") causes a 400 error. Use the Inventory id field instead.discovery_search: Parameter is search_phrase, NOT query. Uses natural language, not a query DSL.get_asset_related_alerts_summary: This is the most valuable investigation tool — related alerts often contain CloudTrail events, runtime detections, and other context not in the primary alert.- MCP connection: If Orca MCP servers from
.mcp.json are not loading, fall back to direct HTTP calls to https://api.orcasecurity.io/mcp using SSE protocol (Accept: application/json, text/event-stream). Parse the data: line from the SSE response.
- Asset ID types: Alerts contain multiple ID formats. For MCP tool calls:
- UUID (e.g.,
c46cb523-3c5d-5bae-...) → use with get_asset_by_id, get_asset_related_alerts_summary, get_asset_related_attack_paths_summary
asset_unique_id (e.g., AwsUser_506464807365_...) → do NOT use with asset tools expecting UUIDGroupUniqueId / cluster_unique_id → use with get_asset_crown_jewel_info
Implementation Notes
- Cache timeline analysis - Don't re-fetch on follow-up questions
- Format consistently - Use the same symbols and structure across all alerts
- Validate alert ID format - Must be "orca-XXXXXXX"
- Handle missing data gracefully - Not all alerts have all fields
- Respect progressive disclosure - Initial output max 30 lines
- Use current date - Calculate age dynamically from today's date
Success Metrics
A successful triage should enable the analyst to:
- ✅ Make close/investigate decision in < 60 seconds
- ✅ Understand behavioral context without deep diving
- ✅ Know exact next steps (not just "investigate")
- ✅ Identify remediation blockers from timeline
- ✅ Escalate with full context if needed
