Box Event Collector

This Integration is part of the Box Pack.#

Supported versions

Available on Cortex XSIAM.

Box Event Collector#

Collect events from Box's logs.

Permissions#

The command is using the events endpoint with enterprise login. The user making the API call will need to have admin privileges, and the application will need to have the scope manage enterprise properties checked.

This is the default integration for this content pack when configured by the Data Onboarder in Cortex XSIAM.

Configure Box Event Collector in Cortex#

To acquire the "Credential JSON", you need to get a JWT token and an app from Box. You can use the guide from Box V2 to get those credentials.

Parameter	Required
Verify SSL Certificate	False
Credentials JSON	True
Fetch Events	False
First fetch timestamp (<number> <time unit>, e.g., 12 hours, 7 days)	False
Maximum number of events per fetch	False

Commands#

You can execute these commands from the CLI, 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.

box-get-events#

Get events.

Base Command#

box-get-events

Input#

Argument Name	Description	Required
limit	Maximum events to fetch. Default is 10.	Optional
created_after	Fetch events from this time (<number> <time unit>, e.g., 12 hours, 7 days). Default is 3 days.	Optional

Context Output#

There is no context output for this command.

Command example#

!box-get-events limit=1 created_after="30 days"

Context Example#

{
    "BoxEvents": {
        "action_by": null,
        "additional_details": null,
        "created_at": "2022-04-10T05:39:15-07:00",
        "created_by": {
            "id": "00000000000",
            "login": "johndoe@example.com",
            "name": "John Doe",
            "type": "user"
        },
        "event_id": "event_id",
        "event_type": "ADD_LOGIN_ACTIVITY_DEVICE",
        "ip_address": "ip_address",
        "session_id": null,
        "source": {
            "id": "00000000000",
            "login": "johndoe@example.com",
            "name": "John Doe",
            "type": "user"
        },
        "type": "event"
    }
}

Human Readable Output#

Results#

action_by additional_details created_at created_by event_id event_type ip_address session_id source type
2022-04-10T05:39:15-07:00 type: user
id: 0000000000
name: John Doe
login: johndoe@example.com event_id ADD_LOGIN_ACTIVITY_DEVICE ip_address type: user
id: 0000000000
name: John Doe
login: johndoe@example.com event

action_by	additional_details	created_at	created_by	event_id	event_type	ip_address	session_id	source	type
		2022-04-10T05:39:15-07:00	type: user id: 0000000000 name: John Doe login: johndoe@example.com	event_id	ADD_LOGIN_ACTIVITY_DEVICE	ip_address		type: user id: 0000000000 name: John Doe login: johndoe@example.com	event

Troubleshooting & Advanced Configuration#

Each fetch cycle collects up to the Maximum number of events per fetch value (default 2500, capped internally at 5000) and then persists its position, so events are collected incrementally across cycles.

If ingestion is falling behind on a high-volume tenant (events arrive faster than they are collected), you can help the collector keep up by:

Increasing Maximum number of events per fetch (up to 5000) so each cycle collects more events.
Decreasing Events Fetch Interval (for example, to 1 minute) so cycles run more frequently.