Automating Security Operations using Phantom

About Me Isabella Minca Intern for 4 months in the Security Team @ Adobe 4th year student @ Univ. Politehnica of Bucharest Hello, my name is Isabella Minca. I have been an intern for 4 months in the Security Team at Adobe and I am in my 4th year of studies at the Faculty of Automatic Control and Computer Science at Politehnica University of Bucharest

Our goals Security Alerts Phantom overview Phantom Playbooks Agenda Our goals Security Alerts Phantom overview Phantom Playbooks What's next Today I am going to talk about Automation of Security Operations using Phantom. The agenda includes: our goals, an insight on security alerts, an overview on Phantom, getting familiar with Phantom playbooks and how to create one and in the end I will talk a little bit about what is next for us regarding this subject.

Our goals Automate repetitive manual work of analysts Enrich existing knowledge on Security Alerts In the future: Discovering new potentially malicious behavior So, there are 2 main things we try to achieve with Phantom: Automation of repetitive manual work of analysts and Enrichment of existing knowledge on Security Alerts. In the future we could be able even to discover new potentially malicious behavior

Logs SIEM Alerts Triage Security Alerts Now let’s talk about how security alerts are generated. Logs based on information about resources in the cloud environment are collected by the SIEM. Based on the information provided, alerts trigger in the SIEM and show up as events. After an alert shows up, analysts investigate further on what caused the alert to trigger, how severe the problem is, what are the remediation steps.

> 100 different types of alerts How much data? 30 TB logs/day 150 alerts/day > 100 different types of alerts So how much data are we talking about? Well, on an average we receive 30 terrabytes of logs per day, analysts investigate and resolve around 150 alerts every day and there are over 100 types of alerts.

How the log looks like in the SIEM Log example How the log looks like in the SIEM

How the alert looks like in the SIEM Alert example How the alert looks like in the SIEM

Manually handling the alerts includes a lot of repetitive work Manual triage Manually handling the alerts includes a lot of repetitive work Example: Azure Weak Network Security Group As you can imagine, a good part of an analyst work in handling the Security Alerts easily becomes repetitive. Let’s see an example: We get an alert when someone creates a Network Security Group with weak rules within an Azure subscription belonging to the company’s cloud environment. An example of a weak rule would be allowing all the inbound traffic on port 22.

Workflow for handling the alert Example Workflow for handling the alert NSG still exists? NSG still weak? Create Jira ticket The usual steps that an analyst follows are: checking if the Network Security Group still exists or it has been deleted in the meantime. Then, checking if its rules are still too permissive or they have been restricted. If the answer to the first 2 questions is yes, then a Jira ticket is created or a previous ticket for the same issue is updated with the new information.

All of these steps can be automated Example (cont) All of these steps can be automated So here it comes Phantom As you can see, each of this steps can be performed automatically. So here it comes Phantom

Security Orchestration Response capabilities What is Phantom? Security Orchestration Automation Response capabilities What exactly is Phantom? It is a tool that facilitates security orchestration, automation and response capabilities.

Aims to help scaling security operations efforts What is Phantom?(cont.) Aims to help scaling security operations efforts Recently acquired by Splunk It enables security teams to dramatically scale their operations efforts. Also, It has been recently acquired by SIEM vendor Splunk

Main Components Apps Playbooks Assets Events Its main components are: Apps, Playbooks, Assets and Events

Third party technologies Used similarly to an API Apps Third party technologies Used similarly to an API Apps allow the usage of third party technologies, in a manner similar to an API. For example you can run a search in Splunk or Jira, you can list tickets in Jira, perform nmap on an ip

‘Codification’ of the security operations plan Playbooks Written in Python ‘Codification’ of the security operations plan Playbooks are codifications of security operations plan, modelling the workflow desired for a certain scenario. They are written in Python.

Assets Specific instances of physical or virtual devices Examples: servers, endpoints, firewalls Assets are specific instances of physical or virtual devices within your organization. Can be: servers, endpoints, firewalls

Events Asset Events Phantom server Polling Events represent external data arrived on the Phantom server by polling on an asset (for instance an Asset can represent a SIEM server and events are security alerts). Events can also be created manually on the Phantom server.

Why Phantom? Phantom playbook vs. Plain Python script You may ask why use Phantom playbooks instead of plain Python scripts

Why Phantom?(cont.) Event Playbook Event Artifact Playbooks run naturally on events, collecting the data in 'artifacts' that can be used as some sort of variables in a playbook. Playbook Event

Why Phantom?(cont) APP Asset 1 PLAYBOOK Asset 2 ACTION 1 ACTION 2 What is more, integrating apps that expose actions which can be called for a certain asset, making api calls to a server that requires authentication becomes much easier, the configuration for assuring connectivity with an asset only has to be done once Asset 2

Examples of useful integrations Splunk Jira Slack SMTP Virus Total Some examples of useful third party technologies integrated as apps: Splunk, Jira, Slack, SMTP, Virus Total

Let’s create a Playbook! Demo Now let’s create a simple playbook from scratch.

Alerts for Weak Network Security Group in Azure Achievements Alerts for Weak Network Security Group in Azure Let’s see what we achieved so far with Phantom playbooks: we automated the workflow for Azure Weak Network Security Group alerts (as I mentioned before)

Achievements(cont.) Alerts for Publicly Exposed Azure Containers Container still exists? Container still exposed? Create Jira ticket We automated the triage flow for Publicly Exposed Azure Containers. The usual triage steps would be: check if container still exists and is still exposed, and if that is the case create a new Jira ticket if no previous one has been created for the same issue

SG restricted/deleted? Achievements(cont.) Follow-up work on Jira tickets for AWS Weak Security Groups SG restricted/deleted? Cross out All SGs crossed out? Close ticket We also used Phantom to automate tedious follow-up work on Jira tickets for AWS Weak Security Groups. The playbook iterates through open tickets that report AWS Weak Security Groups. It checks for each security group in the ticket if it has been restricted or deleted and crosses those out. In the end, if all the security groups in a ticket have been crossed out, it closes the ticket.

What is on for the future? Next steps Automate repetitive manual work Enrich alert data Use ML to detect security issues What is on for the future? So what is on for the future. We plan on continuing automating repetitive manual work and enriching alert data, since it can significantly reduce the workload of analysts and help focusing on improving the security posture. Also, we would like to use Machine Learning to detect other security issues.

Q & A