1. Automating Security Operations using Phantom

2. About Me Isabella Minca
Intern for 4 months in the Security Adobe
4th year 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

3. 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.

4. 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

5. 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.

6. > 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.

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

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

9. 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.

10. 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.

11. 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

12. 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.

13. 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

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

15. 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

16. ‘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.

17. 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

18. 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.

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

20. 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

21. 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

22. 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

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

24. 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)

25. 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

26. 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.

27. 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.

28. Q & A