| 1 | --- |
| 2 | title: Incident alerts |
| 3 | description: How to triage, filter, tag, and collaborate on alerts in SOCFortress CoPilot. |
| 4 | --- |
| 5 | |
| 6 | # Incident alerts |
| 7 | |
| 8 | **Menu:** Incident Management → Alerts |
| 9 | |
| 10 | This is your primary triage queue. |
| 11 | |
| 12 |  |
| 13 | |
| 14 | --- |
| 15 | |
| 16 | ## What you’re looking at |
| 17 | |
| 18 | The Alerts view is split into two parts: |
| 19 | |
| 20 | - **Alerts list** (left): your queue (newest/most relevant alerts) |
| 21 | - **Alert details** (right or modal): the selected alert, with tabs like **Overview** and **Timeline** |
| 22 | |
| 23 | Deep link tip: you can open/highlight an alert directly with: |
| 24 | |
| 25 | `/incident-management/alerts?alert_id=<id>` |
| 26 | |
| 27 | --- |
| 28 | |
| 29 | ## Step 1 — Triage an alert (quick workflow) |
| 30 | |
| 31 | 1) Open **Incident Management → Alerts** |
| 32 | 2) Click an alert in the list to open **details** |
| 33 | 3) In **Overview**, confirm: |
| 34 | - **Customer** (tenant) |
| 35 | - **Title / Description** |
| 36 | - **Assets** impacted (an alert can include multiple assets) |
| 37 | - Any existing **Tags**, **Comments**, and **IOCs** |
| 38 | 4) Decide your next action: |
| 39 | - add a **Comment** (notes + handoff) |
| 40 | - add an **IOC** (evidence you want tracked) |
| 41 | - apply **Tags** (triage labels + RBAC visibility) |
| 42 | - move to a **Case** (if you need investigation tracking) |
| 43 | |
| 44 | --- |
| 45 | |
| 46 | ## Step 2 — Filter the queue (find what matters fast) |
| 47 | |
| 48 | Use the filter controls to narrow your queue. |
| 49 | |
| 50 |  |
| 51 | |
| 52 | ### UI callout: Add filter → Customer Code + Tag |
| 53 | |
| 54 | 1) Click **Add filter** |
| 55 | 2) Add **Customer Code** |
| 56 | - Pick a tenant from the dropdown (shows as `#<code> - <name>`) |
| 57 | 3) Add **Tag** |
| 58 | - The Tag filter is **multi-select** |
| 59 | - You can type a tag and press **Enter** to add it |
| 60 | 4) Click **Submit** to apply |
| 61 | |
| 62 | Available filters include: |
| 63 | |
| 64 | - **Status** (Open / Closed / In progress) |
| 65 | - **Assigned To** (dropdown) |
| 66 | - **Customer Code** (dropdown) |
| 67 | - **Source** (dropdown) |
| 68 | - **Tag** (multi-select; type + Enter) |
| 69 | - **Title** (text) |
| 70 | - **Asset Name** (text) |
| 71 | - **IoC** (text) |
| 72 | |
| 73 | Notes: |
| 74 | - Filters are intended to speed up triage — they don’t bypass security. |
| 75 | - **Customer scoping** and **tag-based visibility** are enforced server-side. |
| 76 | |
| 77 | --- |
| 78 | |
| 79 | ## Step 3 — Apply tags (triage + access control) |
| 80 | |
| 81 | Tags are used for two things: |
| 82 | |
| 83 | 1) **Triage / workflow labels** (examples: `needs-validation`, `high-confidence`, `containment`, `false-positive`) |
| 84 | 2) **Role-based access control (RBAC)**: some environments restrict alert visibility by tag. |
| 85 | |
| 86 | Operator-facing tips: |
| 87 | - If an alert “disappears” from your view, it may be because: |
| 88 | - you no longer have access to that **customer**, or |
| 89 | - you don’t have access to one of the alert’s **tags**. |
| 90 | |
| 91 | --- |
| 92 | |
| 93 | ## Step 4 — Understand assets on alerts (why one alert can have many) |
| 94 | |
| 95 |  |
| 96 | |
| 97 |  |
| 98 | |
| 99 | An alert can be linked to **multiple assets** (hosts/users/entities). |
| 100 | |
| 101 | CoPilot also has **dedup/merge** behavior: |
| 102 | |
| 103 | - If a *new incoming alert* matches an **existing OPEN alert** for the **same customer** and has the **same title**, CoPilot will **not** create a second alert. |
| 104 | - Instead, it **adds the new asset** to the existing alert. |
| 105 | - A new alert is created when: |
| 106 | - the previous alert was moved to a **CLOSED** phase for that customer, or |
| 107 | - the same title appears for a **different customer**. |
| 108 | |
| 109 | Why this matters in triage: |
| 110 | - The alert title may look “unchanged,” but the **asset list grows**, which is often your first signal that scope expanded. |
| 111 | |
| 112 | --- |
| 113 | |
| 114 | ## Step 5 — Comments and IOCs (collaboration + evidence) |
| 115 | |
| 116 |  |
| 117 | |
| 118 |  |
| 119 | |
| 120 | In the alert details pane, use the tabs: |
| 121 | - **Comments** (for notes + handoff) |
| 122 | - **IoCs** (for evidence you want tracked) |
| 123 | |
| 124 | ### UI callout: Add a comment |
| 125 | |
| 126 | 1) Open the alert details |
| 127 | 2) Click the **Comments** tab |
| 128 | 3) Type into **“Write a new comment…”** |
| 129 | 4) Click **Send comment** |
| 130 | |
| 131 | Tip: use comments for decision logging (“why we think this is benign/malicious”), scope notes, and handoff. |
| 132 | |
| 133 | ### UI callout: Add an IOC |
| 134 | |
| 135 |  |
| 136 | |
| 137 | 1) Open the alert details |
| 138 | 2) Click the **IoCs** tab |
| 139 | 3) Click **Create IoC** |
| 140 | 4) Fill out: |
| 141 | - **Description** |
| 142 | - **Type** (IP / DOMAIN / HASH / URL) |
| 143 | - **Value** |
| 144 | 5) Click **Submit** |
| 145 | |
| 146 | Notes: |
| 147 | - The **Value** field is disabled until you select a **Type**. |
| 148 | - IOCs can be deleted later from the IoCs list. |
| 149 | |
| 150 | --- |
| 151 | |
| 152 | ## Timeline (audit trail) |
| 153 | |
| 154 | Use the **Timeline** tab to review alert activity over time (updates, notes, linked context). |
| 155 | |
| 156 | --- |
| 157 | |
| 158 | ## Common gotchas |
| 159 | |
| 160 | ### “Why didn’t a new alert get created?” |
| 161 | It was likely merged into an existing OPEN alert (same customer + same title) and the new entity showed up under **Assets**. |
| 162 | |
| 163 | ### “I can’t delete this alert in bulk” |
| 164 | Bulk delete intentionally skips alerts that are **linked to cases**. |
| 165 | |
| 166 | ### “Why can’t I see an alert my teammate can see?” |
| 167 | Tag-based RBAC and customer access are enforced server-side. Differences in **tag access** or **customer access** can change visibility. |