ArmisEventCollector
Collects alerts, devices and activities from Armis resources.
Analytics & SIEM · Armis
Details
| ID | ArmisEventCollector |
|---|---|
| Provider | Armis |
| Category | Analytics & SIEM |
| From Version | 6.10.0 |
| Docker Image | demisto/python3:3.12.13.10325753 |
| Supported Modules | Agentix XSIAM |
README
Collects alerts, devices and activities from Armis resources.
This integration was integrated and tested with API V.1.8 of Armis API.
This is the default integration for this content pack when configured by the Data Onboarder in Cortex XSIAM.
Notes
- Due to Armis API limitations, it is recommended to configure a separate integration instance for each event type (Alerts, Activities, Devices), and to tweak the limits according to the issues - lowering the limit for timeout or raising the limit for internal server errors.
- Each instance must use its own unique API Secret Key. Reusing the same API Secret Key across multiple instances is prohibited by Armis and will cause authentication conflicts that lead to failed fetches.
- Known issue — intermittent JSON decode errors. The Armis API may occasionally return malformed JSON responses (a known issue on the Armis side). The integration includes an automatic retry mechanism with exponential backoff to handle these transient failures, but in rare cases the error may still occur and will be logged.
Configure Armis Event Collector in Cortex
| Parameter | Description | Required |
|---|---|---|
| Server URL | URL of the Armis instance the event collector should connect to. | True |
| API Secret Key | The API Secret Key allows you to programmatically integrate with the Armis ecosystem. | True |
| Maximum number of events per fetch | Alerts and activity events. | |
| Maximum number of device events per fetch | Devices events. | |
| Trust any certificate (not secure) | ||
| Use system proxy settings | ||
| Event types to fetch | True | |
| Events Fetch Interval | Alerts and activity events. | False |
| Minutes to delay | Number of minutes to delay when fetching events (to handle events creation delay in the Armis database). Default is 10 minutes but note a higher value might be needed for users with heavier traffic. | False |
| Device Fetch Interval | Time between fetch of devices (for example 12 hours, 60 minutes, etc.). | False |
Commands
You can execute these commands from a Cortex XSIAM incident War Room ,as part of an automation, or in a playbook.
After you successfully execute a command, a DBot message appears in the War Room with the command details.
armis-get-events
Manual command to fetch and display events. This command is used for developing/debugging and is to be used with caution, as it can create events, leading to events duplication and exceeding the API request limitation.
Base Command
armis-get-events
Input
| Argument Name | Description | Required |
|---|---|---|
| should_push_events | Set this argument to true in order to create events, otherwise the command will only display them. Possible values are: true, false. Default is false. | Required |
| from_date | The date from which to fetch events. The format should be YYYY-MM-DD or YYYY-MM-DDT:HH:MM:SS. If not specified, the current date will be used. | Optional |
| event_type | The type of event to fetch. Possible values are: Alerts, Activities, Devices. Default is Alerts. | Optional |
| aql | Run your own AQL query to fetch events. | Optional |
Context Output
There is no context output for this command.
Configuration parameters
server_url— Server URL (required)credentials— (required)max_fetch— Maximum number of events per fetchdevices_max_fetch— Maximum number of device events per fetchinsecure— Trust any certificate (not secure)proxy— Use system proxy settingsevent_types_to_fetch— Event types to fetch (required)eventFetchInterval— Events Fetch Intervalfetch_delay— Minutes to delaydeviceFetchInterval— Device Fetch Interval
Commands (1)
-
armis-get-eventsManual command to fetch and display events. This command is used for developing/debugging and is to be used with caution, as it can create events, leading to events duplication and exceeding the API request limitation.
**Important:** This integration is supported by Palo Alto Networks. ## Armis Event Collector Agentless and passive security platform that sees, identifies, and classifies every device, tracks behavior, identifies threats, and takes action automatically to protect critical information and systems. This integration supports the Armis API 1.8.0 version. ### Obtaining an API key from Armis: 1. Log into the Armis platform and browse to **Settings** by clicking your account icon on the top right-hand side of the screen. 2. Choose **Settings API Management**. 3. Click **Create** and copy the generated key. (Do not share this key and do not create a non-encrypted copy of it.) 4. Refer to [Obtaining an API key from Armis](https://docs.ic.armis.com/docs/introduction_api-keys) for more details. ## General note: - The **Activities** and **Alerts** event types are expected to have many logs within a short interval. Therefore, the default limit is 50k and the interval is 1 minute. - The **Devices** event type is expected to have heavier responses but with fewer events within a long interval. Therefore the default limit is 50k and the interval is 4 hours. - Internal server errors may occur when there is a significant disparity between the number of events being fetched and the available events within a given time frame. This can happen when the limit set for fetching events is too low, resulting in the retrieval of older events while a substantial number of new events are available. - Due to Armis API limitations, it is recommended to configure a separate integration instance for each event type, and to tweak the limits according to the issues - lowering the limit for timeout or raising the limit for internal server errors. **Each instance must use its own unique API Secret Key** — reusing the same API Secret Key across multiple instances is prohibited by Armis and will cause authentication conflicts that lead to failed fetches.