Security Orchestration Use Case: Responding to Phishing Attacks

Sea Full of Phish

Phishing emails are one of the most frequent, easily executable, and harmful security attacks that organizations – regardless of size – face today. With over 90% of all data breaches starting with a phishing email, the potential for financial damage is real and immediate. Phishing emails are also very simple for attackers to craft, resulting in an attack volume and velocity that SOCs and analysts can’t keep up with.

Security analysts face numerous challenges while responding to phishing attacks. Handling attack numbers without burning out, switching between multiple screens to coordinate response, avoiding errors while completing mundane tasks, and standardizing response and reporting procedures are all sources of worry.

How Orchestration Helps

Security orchestration platforms can use ‘phishing playbooks’ that execute repeatable tasks at machine speed, identify false positives, and prime the SOC for standardized phishing response at scale.

1. Ingestion

A security orchestration platform can ingest suspected phishing emails as incidents from a variety of detection sources such as SIEMs and logging services. If the SOC aggregates all suspected phishing mails in a common mailbox, then a mail listener integration can be configured on the orchestration platform for ingestion.

Once the email is ingested, a playbook is triggered and goes through steps to automate enrichment and response.

2. Enrichment

To keep the end users updated, the playbook sends an automated email to the affected user and let them know that the suspected phishing email is being investigated. The two key steps that the playbook can perform for enrichment are triage and IOC extraction.

By looking at the ‘ingredients’ of the email such as title, email address, attachments, and so on, the playbook assigns incident severity by cross-referencing these details against external threat databases. Following this, the playbook extracts out IOCs from the email and checks for any reputational red flags from existing threat intelligence tools that the SOC uses.

Once this enrichment is done, the playbook checks if any malicious indicators were found. Based on this check, different branches of response can ensue.

3. Response

Different branches of the playbook will execute depending on whether malicious indicators were detected in the suspected phishing email.

If malicious indicators were detected, the playbook sends an email to the affected user with further instructions. The playbook also scans all organizational mailboxes/endpoints to identify other instances of that email and delete all instances to avoid further damage. Finally, the playbook adds the malicious IOCs to blacklists/watchlists on the SOC’s other tools.

If malicious indicators were not detected, there are still precautions to be taken before confirming that the email is harmless. The playbook checks if there are any attachments with the email and detonate them in a sandbox for further analysis. If that analysis doesn’t throw up any alarms, the playbook can give way to analysts for qualitative and manual investigation. Once the analysts are satisfied that the email isn’t malicious, the playbook sends an email to the affected user apprising them of the false alarm.

Looking for other applications of security orchestration? Access our GitHub playbook repository and see what's possible

A Good Playbook Should Be...

Simple and intuitive: The playbook should ideally be represented as a task/process flow through a simple drag-and-drop graphical interface.  Coding expertise shouldn't be a 'must-have' to make even the most complex playbooks, although each playbook’s code should also be available for analysts to tweak if required.

Primed for automation: Analysts should be able to automate the entire playbook in response to a phishing attack, greatly reducing response time, effort, and the possibility of human error for large-volume attacks. However, analysts should also be able to include manual steps in playbooks and require human intervention for sophisticated attacks.

Customizable: Analysts should be able to make copies of the standard playbook, modify it, or embed it in other playbooks as needed.

We hope you found this use case walk-through helpful. This is only a skeletal workflow - your own 'playbook' can be as simple or complex as you need them to be.

To learn about more security orchestration use cases, download our whitepaper.

To see Cortex XSOAR in action, sign up for our free Community Edition!