|
| 1 | +# SOCRadar Incidents v4.0 Multi-Tenant |
| 2 | + |
| 3 | +Fetch and manage security incidents from multiple companies using SOCRadar's Multi-Tenant Incident API. Designed for MSPs, MSSPs, and organizations managing multiple subsidiaries. |
| 4 | + |
| 5 | +## Overview |
| 6 | + |
| 7 | +SOCRadar is a digital risk protection platform that provides extended threat intelligence and brand protection capabilities. This Multi-Tenant integration enables XSOAR to ingest security incidents from multiple companies through a single integration instance, including: |
| 8 | + |
| 9 | +- **Brand Protection**: Impersonating domains, phishing attacks, brand abuse |
| 10 | +- **Cyber Threat Intelligence**: Stolen credentials, data leaks, malware infections |
| 11 | +- **Attack Surface Management**: External exposure findings, misconfigurations |
| 12 | +- **Dark Web Intelligence**: Compromised credentials, leaked data from dark web sources |
| 13 | +- **Supply Chain Security**: Third-party risks and vendor security issues |
| 14 | + |
| 15 | +## Multi-Tenant Features |
| 16 | + |
| 17 | +### Centralized Multi-Company Management |
| 18 | + |
| 19 | +- **Single Integration**: Monitor incidents from all your companies through one integration instance |
| 20 | +- **Company Tracking**: Each alarm automatically includes company ID and company name |
| 21 | +- **Smart Filtering**: Filter and manage incidents across companies or focus on specific ones |
| 22 | + |
| 23 | +### Automatic Company ID Handling |
| 24 | + |
| 25 | +- **Auto-Extraction**: When taking actions, company ID is automatically extracted from alarm data |
| 26 | +- **No Manual Input**: You don't need to remember or specify company IDs for most operations |
| 27 | +- **Override Capability**: Manually specify company ID when needed (advanced use cases) |
| 28 | + |
| 29 | +### Company Visibility Control |
| 30 | + |
| 31 | +- **Configurable Display**: Choose whether to show company information in incident details |
| 32 | +- **Custom Fields**: Company ID and company name available in custom fields |
| 33 | +- **Incident Naming**: Company information included in incident names for quick identification |
| 34 | + |
| 35 | +--- |
| 36 | + |
| 37 | +## What's New in Multi-Tenant v4.0 |
| 38 | + |
| 39 | +### Multi-Tenant Specific |
| 40 | + |
| 41 | +- **Multi-Tenant API Endpoint**: Uses `/multi_tenant/{multi-tenant-id}/incidents` for fetching |
| 42 | +- **Company Information**: Each alarm includes both company_id and company_name |
| 43 | +- **Smart Action Handling**: Automatically determines which company to act upon |
| 44 | +- **Default Company Visibility**: Company info shown by default (can be disabled) |
| 45 | + |
| 46 | +### Core Features (from v4.0) |
| 47 | + |
| 48 | +- **Multi-Status Filtering**: Select multiple statuses (OPEN, CLOSED, ON_HOLD) simultaneously |
| 49 | +- **Epoch Time Precision**: Second-level accuracy for incident fetching - zero duplicates |
| 50 | +- **Reverse Pagination**: Fetches newest incidents first for better performance |
| 51 | +- **Dynamic Content Extraction**: Automatically extracts alarm-specific fields regardless of type |
| 52 | +- **Enhanced Deduplication**: Two-layer protection prevents duplicate incidents |
| 53 | + |
| 54 | +### Technical Improvements |
| 55 | + |
| 56 | +- Interval-based fetching with overlap protection |
| 57 | +- Configurable content and entity inclusion |
| 58 | +- Comprehensive debug logging |
| 59 | +- Better error handling and recovery |
| 60 | +- Intelligent company ID extraction from incident context |
| 61 | + |
| 62 | +--- |
| 63 | + |
| 64 | +## Key Differences: Standard vs Multi-Tenant |
| 65 | + |
| 66 | +| **Feature** | **Standard v4.0** | **Multi-Tenant v4.0** | |
| 67 | +| --- | --- | --- | |
| 68 | +| **Configuration** | Company ID + API Key | Multi-Tenant ID + API Key | |
| 69 | +| **Fetch Endpoint** | `/company/{id}/incidents/v4` | `/multi_tenant/{id}/incidents` | |
| 70 | +| **Company Data** | Single company (implicit) | Multiple companies (explicit) | |
| 71 | +| **Company ID in Actions** | Uses configured company ID | Auto-extracted from alarm | |
| 72 | +| **Company Visibility** | Optional (default: hidden) | Optional (default: visible) | |
| 73 | +| **Use Case** | Single organization | MSPs, MSSPs, multi-subsidiary | |
| 74 | + |
| 75 | +--- |
| 76 | + |
| 77 | +## Prerequisites |
| 78 | + |
| 79 | +### Required |
| 80 | + |
| 81 | +- SOCRadar account with Multi-Tenant Incident API access |
| 82 | +- Multi-Tenant ID from SOCRadar platform |
| 83 | +- API Key from SOCRadar platform |
| 84 | +- XSOAR 6.x or later |
| 85 | + |
| 86 | +### API Access |
| 87 | + |
| 88 | +To obtain your API credentials: |
| 89 | + |
| 90 | +1. Log in to [SOCRadar Platform](https://platform.socradar.com) |
| 91 | +2. Reach out support team to get MSSP API Key |
| 92 | + |
| 93 | +--- |
| 94 | + |
| 95 | +## Configuration |
| 96 | + |
| 97 | +### Integration Settings |
| 98 | + |
| 99 | +| **Parameter** | **Required** | **Default** | **Description** | |
| 100 | +| --- | --- | --- | --- | |
| 101 | +| **Server URL** | Yes | `https://platform.socradar.com/api` | SOCRadar API base URL | |
| 102 | +| **API Key** | Yes | - | Your Multi-Tenant API Key from SOCRadar | |
| 103 | +| **Multi-Tenant ID** | Yes | - | Your Multi-Tenant ID (integer) | |
| 104 | +| **Fetch incidents** | No | False | Enable automatic incident fetching | |
| 105 | +| **Incident type** | No | - | XSOAR incident type to create | |
| 106 | +| **Max incidents per fetch** | No | 10000 | Maximum incidents per fetch cycle | |
| 107 | +| **First fetch time** | No | 3 days | Initial time range for first fetch | |
| 108 | +| **Fetch Interval (Minutes)** | No | 1 | Time window for subsequent fetches | |
| 109 | + |
| 110 | +### Filtering Options |
| 111 | + |
| 112 | +| **Parameter** | **Type** | **Description** | |
| 113 | +| --- | --- | --- | |
| 114 | +| **Status Filter** | Multi-select | Select one or more: OPEN, CLOSED, ON_HOLD | |
| 115 | +| **Severity** | Multi-select | Filter by: LOW, MEDIUM, HIGH, CRITICAL | |
| 116 | +| **Alarm Type IDs** | Text | Comma-separated list of type IDs to include | |
| 117 | +| **Excluded Alarm Type IDs** | Text | Comma-separated list of type IDs to exclude | |
| 118 | +| **Main Alarm Types** | Text | Comma-separated main types (e.g., "Brand Protection") | |
| 119 | +| **Alarm Sub Types** | Text | Comma-separated sub types | |
| 120 | + |
| 121 | +--- |
| 122 | + |
| 123 | +## Commands |
| 124 | + |
| 125 | +You can execute these commands from the Cortex XSOAR CLI, as part of an automation, or in a playbook. |
| 126 | +After you successfully execute a command, a DBot message appears in the War Room with the command details. |
| 127 | + |
| 128 | +### socradar-change-alarm-status |
| 129 | + |
| 130 | +*** |
| 131 | +Change the status of one or more alarms. |
| 132 | + |
| 133 | +#### Base Command |
| 134 | + |
| 135 | +`socradar-change-alarm-status` |
| 136 | + |
| 137 | +#### Input |
| 138 | + |
| 139 | +| **Argument Name** | **Description** | **Required** | |
| 140 | +| --- | --- | --- | |
| 141 | +| alarm_ids | Comma-separated list of alarm IDs to update. | Required | |
| 142 | +| status_reason | New status reason for the alarms. Possible values are: OPEN, INVESTIGATING, RESOLVED, PENDING_INFO, LEGAL_REVIEW, VENDOR_ASSESSMENT, FALSE_POSITIVE, DUPLICATE, PROCESSED_INTERNALLY, MITIGATED, NOT_APPLICABLE. | Required | |
| 143 | +| comments | Optional comments explaining the status change. | Optional | |
| 144 | +| company_id | Company ID for the alarm. If not provided, will be auto-fetched from alarm data. Can also use ${incident.socradarcompanyid} from incident fields. | Optional | |
| 145 | + |
| 146 | +#### Context Output |
| 147 | + |
| 148 | +| **Path** | **Type** | **Description** | |
| 149 | +| --- | --- | --- | |
| 150 | +| SOCRadar.Alarm.ID | String | Alarm ID. | |
| 151 | +| SOCRadar.Alarm.Status | String | New alarm status. | |
| 152 | + |
| 153 | +--- |
| 154 | + |
| 155 | +### socradar-mark-false-positive |
| 156 | + |
| 157 | +*** |
| 158 | +Mark an alarm as false positive. |
| 159 | + |
| 160 | +#### Base Command |
| 161 | + |
| 162 | +`socradar-mark-false-positive` |
| 163 | + |
| 164 | +#### Input |
| 165 | + |
| 166 | +| **Argument Name** | **Description** | **Required** | |
| 167 | +| --- | --- | --- | |
| 168 | +| alarm_id | Alarm ID to mark as false positive. | Required | |
| 169 | +| comments | Optional comments explaining why this is a false positive. Default is False positive. | Optional | |
| 170 | +| company_id | Company ID for the alarm. If not provided, will be auto-fetched from alarm data. Can also use ${incident.socradarcompanyid} from incident fields. | Optional | |
| 171 | + |
| 172 | +#### Context Output |
| 173 | + |
| 174 | +| **Path** | **Type** | **Description** | |
| 175 | +| --- | --- | --- | |
| 176 | +| SOCRadar.Alarm.ID | String | Alarm ID. | |
| 177 | +| SOCRadar.Alarm.Status | String | New alarm status. | |
| 178 | + |
| 179 | +--- |
| 180 | + |
| 181 | +### socradar-mark-resolved |
| 182 | + |
| 183 | +*** |
| 184 | +Mark an alarm as resolved. |
| 185 | + |
| 186 | +#### Base Command |
| 187 | + |
| 188 | +`socradar-mark-resolved` |
| 189 | + |
| 190 | +#### Input |
| 191 | + |
| 192 | +| **Argument Name** | **Description** | **Required** | |
| 193 | +| --- | --- | --- | |
| 194 | +| alarm_id | Alarm ID to mark as resolved. | Required | |
| 195 | +| comments | Optional comments explaining the resolution. Default is Resolved. | Optional | |
| 196 | +| company_id | Company ID for the alarm. If not provided, will be auto-fetched from alarm data. Can also use ${incident.socradarcompanyid} from incident fields. | Optional | |
| 197 | + |
| 198 | +#### Context Output |
| 199 | + |
| 200 | +| **Path** | **Type** | **Description** | |
| 201 | +| --- | --- | --- | |
| 202 | +| SOCRadar.Alarm.ID | String | Alarm ID. | |
| 203 | +| SOCRadar.Alarm.Status | String | New alarm status. | |
| 204 | + |
| 205 | +--- |
| 206 | + |
| 207 | +### socradar-add-comment |
| 208 | + |
| 209 | +*** |
| 210 | +Add a comment to an alarm. |
| 211 | + |
| 212 | +#### Base Command |
| 213 | + |
| 214 | +`socradar-add-comment` |
| 215 | + |
| 216 | +#### Input |
| 217 | + |
| 218 | +| **Argument Name** | **Description** | **Required** | |
| 219 | +| --- | --- | --- | |
| 220 | +| alarm_id | Alarm ID to add comment to. | Required | |
| 221 | +| user_email | Email address of the user adding the comment. | Required | |
| 222 | +| comment | Comment text to add. | Required | |
| 223 | +| company_id | Company ID for the alarm. If not provided, will be auto-fetched from alarm data. Can also use ${incident.socradarcompanyid} from incident fields. | Optional | |
| 224 | + |
| 225 | +#### Context Output |
| 226 | + |
| 227 | +| **Path** | **Type** | **Description** | |
| 228 | +| --- | --- | --- | |
| 229 | +| SOCRadar.Alarm.ID | String | Alarm ID. | |
| 230 | + |
| 231 | +--- |
| 232 | + |
| 233 | +### socradar-add-assignee |
| 234 | + |
| 235 | +*** |
| 236 | +Add the assignee(s) of an alarm. |
| 237 | + |
| 238 | +#### Base Command |
| 239 | + |
| 240 | +`socradar-add-assignee` |
| 241 | + |
| 242 | +#### Input |
| 243 | + |
| 244 | +| **Argument Name** | **Description** | **Required** | |
| 245 | +| --- | --- | --- | |
| 246 | +| alarm_id | Alarm ID to add assignee for. | Required | |
| 247 | +| user_emails | Comma-separated list of user email addresses to assign. | Required | |
| 248 | +| company_id | Company ID for the alarm. If not provided, will be auto-fetched from alarm data. Can also use ${incident.socradarcompanyid} from incident fields. | Optional | |
| 249 | + |
| 250 | +#### Context Output |
| 251 | + |
| 252 | +| **Path** | **Type** | **Description** | |
| 253 | +| --- | --- | --- | |
| 254 | +| SOCRadar.Alarm.ID | String | Alarm ID. | |
| 255 | +| SOCRadar.Alarm.Assignees | String | New assignees. | |
| 256 | + |
| 257 | +--- |
| 258 | + |
| 259 | +### socradar-add-tag |
| 260 | + |
| 261 | +*** |
| 262 | +Add or remove a tag from an alarm. |
| 263 | + |
| 264 | +#### Base Command |
| 265 | + |
| 266 | +`socradar-add-tag` |
| 267 | + |
| 268 | +#### Input |
| 269 | + |
| 270 | +| **Argument Name** | **Description** | **Required** | |
| 271 | +| --- | --- | --- | |
| 272 | +| alarm_id | Alarm ID to add/remove tag for. | Required | |
| 273 | +| tag | Tag name to add or remove. | Required | |
| 274 | +| company_id | Company ID for the alarm. If not provided, will be auto-fetched from alarm data. Can also use ${incident.socradarcompanyid} from incident fields. | Optional | |
| 275 | + |
| 276 | +#### Context Output |
| 277 | + |
| 278 | +| **Path** | **Type** | **Description** | |
| 279 | +| --- | --- | --- | |
| 280 | +| SOCRadar.Alarm.ID | String | Alarm ID. | |
| 281 | +| SOCRadar.Alarm.Tags | String | Alarm tags. | |
| 282 | + |
| 283 | +--- |
| 284 | + |
| 285 | +### socradar-test-fetch |
| 286 | + |
| 287 | +*** |
| 288 | +Test incident fetching to verify alarms are available and date parsing works correctly. |
| 289 | + |
| 290 | +#### Base Command |
| 291 | + |
| 292 | +`socradar-test-fetch` |
| 293 | + |
| 294 | +#### Input |
| 295 | + |
| 296 | +| **Argument Name** | **Description** | **Required** | |
| 297 | +| --- | --- | --- | |
| 298 | +| limit | Number of incidents to test fetch (default 5). Default is 5. | Optional | |
| 299 | +| first_fetch | Test date range (e.g., "3 days", "7 days"). Default is 3 days. | Optional | |
| 300 | + |
| 301 | +#### Context Output |
| 302 | + |
| 303 | +| **Path** | **Type** | **Description** | |
| 304 | +| --- | --- | --- | |
| 305 | +| SOCRadar.TestFetch.TotalCount | Number | Total number of incidents found. | |
| 306 | +| SOCRadar.TestFetch.SampleIncidents | Unknown | Sample incidents for testing. | |
| 307 | +| SOCRadar.TestFetch.StartDate | String | Parsed start date used for the test. | |
| 308 | +| SOCRadar.TestFetch.TotalRecords | Number | Total number of incidents from service. | |
| 309 | +| SOCRadar.TestFetch.TotalPages | Number | Total number of pages of incidents from service. | |
| 310 | + |
| 311 | +--- |
| 312 | + |
| 313 | +## License |
| 314 | + |
| 315 | +This integration is provided as part of the Cortex XSOAR content pack. |
0 commit comments