Why Expel Asks for Console Access

For many of our integrations, we require that you grant our SOC analysts a certain level of access to the vendor technology's console when you set up your security device in Workbench. This page explains why we need this access, at what level, and under what circumstances.

Why We Need Access

Gaining access to your console allows our SOC analysts to fully triage and research any events that result in an Expel Alert. At a base level, we must be able to determine the vector and extent of attacker activity for an identified threat. We do this by querying the integration via the Workbench API to obtain all necessary data.

However, some integrations do not allow us to get everything we need via the API. In these cases we ask you for console access. For example:

• Logs are not always queryable via the API, so maintaining access to the console is critical for gathering necessary log data.

• Some artifacts cannot be pulled remotely via the API and must be gathered directly from the console; examples include PCAP, malware reports, and certain types of files like browser histories or malicious binaries quarantined by EDR.

• Events from EDR integrations do not always include fundamental information (like network connections) that is necessary for triage, and this information can only be gathered by accessing the console.

Remember that a vendor alert does not typically include all of the contextual timeline activity surrounding the event of interest, so maintaining console access helps us quickly bridge any gaps.

Which Integrations Require Console Access

We have less of a need for console access if the information within the console is similar in display/quality as the information queryable via API. Therefore we generally require console access for the following types of integrations:

1. Endpoint Detection and Response (EDR)

2. SIEM

3. Any network technology with artifacts that can be downloaded (but not queried via API)

4. Integrations that are not fully queryable via API, including webhook integrations

Note that currently, cloud security logs (both Cloud Identity / SaaS and Cloud Infrastructure) are typically ingested into an internal SIEM and then queried by Expel, so direct access is not necessarily needed.

Access Levels

Minimum Requirements

The level of access that we ask for is meant to support essential triage and research activities. At minimum, we ask for visibility into:

• Alert data

• Timeline events recorded by the security technology

• Live response/real time response shell (EDR integrations only; more info on this below)

For some integrations, we ask for read-only access. For others, like Wiz (which supports status syncing), we ask for read and write access so that we can simultaneously update the status in your console.

Live Response/Real Time Response Shell Access

For EDR integrations, a live session (shell) is often created on the host to pull in artifacts such as browser history, suspicious files, log data, and registry entries. We ask for access to this shell to acquire those artifacts during an investigation, which helps us tremendously with identifying a root cause or attack vector for an identified threat.

Simply enabling real time response (without granting shell access) is not enough, because it does not always allow our SOC analysts to acquire the artifacts and files. Some reasons for this limitation include:

• EDR agent software on the host not supporting file or log acquisition

• The host being offline, and therefore no live session is available

• EDR agent software not supporting live response for the host operating system

Not every EDR integration supports live response/real time response, but many do. If we are unable to acquire a needed artifact due to lack of direct access, you may have to manually locate and upload it for us. This can increase triage time.