Open-Source SOAR Solution : Part 1

Open-Source SOAR Solution : Part 1

With a industry that is tool/software centric we can lose sight on the true solution within Cyber Security. Many companies will buy a specific product to be the “silver bullet” to all their Cyber Security needs, but unfortunately that product will never truly exist. If we as an industry truly want to succeed in this game of Cat and Mouse we must go back to the basics and create “solutions” that are vendor agnostic. Many frame-works have been created to help us get their, but many of them depend on extensive knowledge and resources (People) to make them succeed.

Security Operations Automation and Response

SOAR (Security Operations Automation and Response) is a solution to be that “magic bullet”, at least according to the main vendors in this space (Splunk>Phantom, Swimlane, and Demisto>Cortex). The problem with traditional SOAR platforms is normally you get “locked” into that specific platform. You may spend hundreds of hours creating your “playbooks” to increase your automation needs, unfortunately if you ever decide to leave that specific vendor chances are you will have to re-create those playbooks. What we are doing at Sorsnce Enterprise Labs is trying to create a vendor agnostic solution to help fill this gap.

Docker Containers

With the creation of Docker and containers, DevOps have been more agile in their approach with traditional Web applications. But Cyber Security as a whole has not really adopted the “Container” mentality. What the DevOps industry has done with cloud agnostic and infrastructure as code is really amazing, so why not take the same approach with Cyber Security? The first steps in creating our Open-Source SOAR Solution is to create a valid container and orchestration platform for our application. We will touch on this subject more in future posts.

Module Playbook approach

Many SOAR vendors will create playbooks without a “Module” mindset. What do I mean by “Module”? Let’s look back at Docker Containers and see what the best practices is for implementation. Normally when you architect containers you go with something that is called “microservices”. The turn “microservices” really means breaking things into the smallest chunks as possible, you can read more about “microservices” here. What does that mean for our SOAR solution? Normally within your SOAR platform you should run “actions” from an “artifact“. What is an “artifact“? Normally an “artifact” can be, but not limited to, an IP address, MAC address, File Hash, SAM account name, mailbox, etc. An “artifactcan really be anything with a static value that points to a resource. So lets take an “artifact” that contains a file hash, our action might be to lookup that hash within VirusTotal to verify if its a known bad hash or if its a clean hash. Normal SOAR solutions will take the approach of ingestion point for playbooks, lets take the two scenarios and compare the architecture of our playbooks:

Traditional Playbook Style:

Playbook Name = malware_hunt_and_contain

Event ingestion = SIEM Alert for Malware

Actions Taken = disable user, file reputation, shutdown system, block hash, get file, create ticket, hunt file, logoff user

Apps Used = wildfire, smtp, virustotal, carbonblack

Module Playbook Style:

Playbook Name = sel-malware-alert-module

Event ingestion = Specific Artifact in question

Actions Taken = sel-filehash-recon-module, sel-filehash-hunt-module, sel-filehash-block-module, sel-activedirectory-disable-module

Apps Used = Multiple supported Apps

The Future of SOAR

As we can see in both examples above, the traditional playbook would re-write the same actions for each new playbook being developed. With more of a module and parent playbook configuration we would only need to make a change once to affect all future existing playbooks. Take in example that file hash lookup, if we had a module playbook that takes the “artifactMD5 hash and spits back a variable of “known good” or “known bad“, we can utilize this same functionality in future playbooks instead of having to re-write this functions every time. At Sorsnce Enterprise Labs we recommend creating playbooks to serve a specific function and ingestion artifact. We will talk more about how to achieve this type of methodology in the future. Wrapping up this blog post we want to send you have with a couple of high-lights. These are the main focus points we will talk about in future blog posts.

  • Vendor agnostic platform
  • Module and Parent style of Playbooks
  • Portability and flexibility similar to microservices
  • Point Click automation with little expertise needed

These are the main focus of our Open-Source SOAR Solution. We will be releasing more details in the future as well as a GitHub repository with the code for this project.