Expel Alerts are visible in Workbench only after you have set up your security device and the tuning process is complete. The events coming from your security devices are triaged by our bots and may (or may not) result in the creation of Expel Alerts in Workbench based on a number of factors, including detection strategy.
Quick Links
Device Tuning
After you complete the setup guide(s) to connect your security devices, Workbench can begin consuming the signals and data from those devices. However, Expel first needs to go through a tuning period to allow our Josie bot to begin sorting out the signals. This means that:
- A new device is automatically "suppressed" for about 48 hours, which allows the tuning process to complete.
- This suppression will be automatically lifted when the tuning process has finished, and full monitoring of your device will begin at that time.
Note
We will still be actively monitoring your device during the tuning process, and will notify you of any critical or high security incidents that occur.
Event Triage Process
An event refers to any signal, data, or alert that we ingest from your security device. An Expel Alert is only created if the event merits further assessment by our SOC Analysts. Therefore, you may see an alert in your vendor technology but not see an associated Expel Alert in Workbench.
Step 1: Josie Bot
Events from your security device are initially triaged by our Josie bot, which leverages detection strategy to automatically process and classify many events.
- If Josie decides an event needs further review, it creates an Expel Alert in Workbench (sometimes multiple events will be tied to one Expel Alert).
- This action notifies our SOC Analysts of a potential security issue that needs human review.
Our Josie bot will automatically ignore certain activity that Expel already knows is not a true security issue. It is common for our analysts to instruct Ruxie (another Expel bot) to ignore certain non-malicious events after they have been triaged internally, investigated, and found to be benign.
Step 2: SOC Investigation
The next step is for the SOC Analyst to look at the Expel Alert in Workbench.
- If the SOC Analyst believes there is a need for more in-depth analysis, they open an Investigation. During the investigation, they may query your devices for more information, review additional logs, and use the Ruxie bot to help gather data.
- If the SOC Analyst can identify the activity and confirm the event is not malicious, the Expel Alert is closed. The SOC Analyst will include information about what they found and why they closed it, and may also instruct Josie on how to handle the event if it arises again.
Step 3: SOC Incident
Incidents are only flagged when an Investigation by the SOC Analyst indicates malicious activity may be present.
- If the SOC Analyst finds anything that appears malicious during the Investigation, they flag the Investigation as an Incident. The SOC Analyst then actively works to discover and mitigate whatever has been compromised, and Workbench generates notifications to your communication channels based on your settings (these notifications may include instructions on what to do).
- If the SOC Analyst finds nothing malicious during the Investigation, it is closed as benign. The SOC Analyst will include information about what they found and why they closed it.
FAQs
Why wasn't a vendor alert escalated and turned into an Expel Alert?
We action on vendor alerts based on the detection strategy for that integration, as this outlines the types of events (including vendor alerts) that we are looking for. An Expel Alert is only created if Josie determines an event merits further assessment by our SOC Analysts. We choose not to surface certain things (like test alerts) that we know are not malicious. It is also common for our analysts to instruct Josie to ignore certain non-malicious events after they have been triaged internally, investigated, and found to be benign.
If no events are coming through at all, and therefore no Expel Alerts are being created, then you would want to check your security device configuration to make sure the connection is active and polling. You can find more information about device health and fixing an unhealthy device in Security Device Health.
Why did I get multiple Expel Alerts for the same or a similar activity? I have an Expel Alert that is similar to one I received a half hour ago.
Occasionally this can happen if multiple vendors detect the same activity and create separate alerts, or if the device generating the alerts creates multiple alerts of different severities due to an internal threshold that was crossed, or if seemingly similar alerts actually follow slightly different logic paths. It is also possible that the timing of two alerts is just far enough apart that it falls outside of our deduplication window.
Why is the time between a vendor alert and a corresponding Expel Alert sometimes so long?
The speed at which we can create an Expel Alert depends on how quickly the vendor technology makes events available to us, and also how often we normally poll that type of security device. Our polling schedule differs for each integration. Sometimes there is a delay with the vendor in publishing data to the API (this can take an hour or more for vendor alerts) so this delays when our Josie bot can consume and triage it.
Why can't I find a particular event in Workbench that I know occurred?
The event search in Workbench only goes back 14 days. If the event is older than this and you would like more information, contact support and give them your device GUID (Organization Settings > Security Devices then select the Copy button for the device GUID in the GUID column).
But also remember that if you do not see an Expel Alert for the event, the event may have been purposely suppressed by our detection strategy. This action may impact its final visibility in the event search.
Why did one vendor alert surface and become an Expel Alert, but a similar one on the same device did not?
In high volume situations, we may choose to bucket vendor alerts based on our own internal criteria. Sometimes an event shares certain types of data (like a URL or hostname), and in those cases we will only surface one of those events for a particular condition. Other times events come through that we know are not malicious unless they occur in certain quantities, so we will only surface an Expel Alert when a particular threshold is met.
If you were expecting 5 Expel Alerts because there were 5 vendor alerts, but this did not occur, there is likely a condition on the backend that is instructing Josie not to surface them on a 1:1 basis.
When an Expel Alert is resolved and closed in Workbench, will the vendor alert also be closed within my integration?
Not usually. Only some integrations (like Wiz) support status synching by default. However, you can leverage webhooks or the Workbench API to enable one-way status syncing for your MDR or ticketing integrations. You should be familiar with automation and have a tool like SOAR in place to successfully set this up for your organization, as this type of status syncing must be configured and maintained by you.
How do I know that your detection strategy is not missing threats, especially in cases where Expel Alerts are infrequent?
Our SOC analysts have a methodical, data science-driven approach to our detection strategy. They track precision and recall, and also perform detailed monitoring around every decision to fire or not fire. All of their detection activity is actively captured internally and they hold themselves to a continuous improvement process. There are safety thresholds in place that they track daily and weekly to ensure they are staying on track, and that your organization is protected.
How are you evolving your detection strategy and alert triage to stay ahead of attackers?
We have different teams that are each dedicated to specific parts of the Cyber Kill Chain and MITRE ATT&CK frameworks, and others that perform original research with sources like OSN, Atmos Lion, Scattered Spider, etc. We also have a team that is dedicated to monitoring vendor alerts, so that we see any vendor changes as they occur. Learn more about our detection strategy approach in About Detection Strategy.