They say the best way to learn is to do and this applies to nothing better than technology. As a relatively new SE at Palo Alto, I knew that if I tried to learn XSOAR by watching hours of videos and reading articles, I would never build that muscle memory that comes from repetition. With that in mind, I decided to find a use case for it and then work out how to make it do that.
After experimenting with automated jobs to block and allow kids games taught me the basics of jobs and incidents and alerting me when high risk URL categories are accessed taught me how to get log data into XSOAR, I wanted something useful. Something that would increase my security and automate a job that I simply would not have the time to carry out myself.
That Golden Goose came in the form of Bitcoin. Now, I know this sounds like the opening line of almost every crypto schill you’ve ever heard, but rest assured I’mnot going to try to sell you unicorns and crypto Rainbows. I run a Bitcoin Node at home. I don’t make any profit from it, but I believe in Bitcoin and running a node to calculate transactions on the Blockchain helps the community and ultimately the currency itself.
The Problem?
I have to open up my firewall to the entire world. Now, because I have a Palo Alto NGFW at home, I can restrict that traffic to ‘Bitcoin’ specifically and only on the default Bitcoin port, but I’m still completely open to any potentially malicious actor. Checking the reputation of IP addresses manually and then blocking those of poor repute is possible, but there are several Bitcoin connections per minute and checking each and every IP would be neither enjoyable or possible without giving up my day job and becoming a reclusive hermit living in the Jundland wastes.
This is where XSOAR came in. Due to its many integration points, I was able to instruct XSOAR to check the reputation of incoming connections in Palo Alto’s Threat Intel Autofocus and then block further connections from that IP in the future, if said IP’s reputation is poor, by adding the IP address to an externally hosted text file (EDL) that Panorama is configured to pull data from every hour. The reason an EDL is used, rather than pushing IP’s to policies, is simple; no change commit is required from Panorama, making the whole process simpler and more dynamic.
The playbook is as follows:
- Dedupe Incidents – I noticed many connections are from the same IP address. This sub playbook recognises that fact and closes the case if the source IP has been seen within the last hour.
- Check for source IP – Allows for a graceful end to the playbook if an IP address is not present in the log that generates the incident.
- Send IP address to Autofocus.
- If Reputation is good, close the incident.
- If Reputation is bad, enrich with IPInfo for investigation, add the IP addressto an EDL that Panorama is constantly pulling data from and email me to make me aware that this has happened.
But there was a problem. My XSOAR server sounded like it was about take off after a few minutes of operation. What was happening? I didn’t take into account the sheer number of inbound connections and the processing required just to run the de-dupe playbook. I was looking at hundreds of incidents being opened per hour.
This is where pre-processing saved the day! Rather than have XSOAR spin up docker images every time a dedupe automation was needed; I added a pre-processing rule to take on some of that burden.
This is how my dashboard looked after 12 hours:
For the IP’s that fail reputation checks, the cases stay open and I receive an email notification containing the IP address and Autofocus’ verdict.
The cases are open for easy access and to allow me to investigate further if I wish, but there is nothing required from me, as the IP addresses have already been added to the text file that my Firewall is reading from for IP addresses to block.
No businesses in their right mind would run Bitcoin node in their Data Centre, but this playbook could be used for any service that has to be open to the outside world. Mail and Web servers must accept connections on port 25/80/443. They may be in your DMZ but do you know who’s attempting to connect to them? Do you check IP reputation before allowing connections to them? Using the IP enrichment info, you could also block IP ranges based on Geographical location to drastically reduce attack surface if you wish.
But it doesn’t end there. Because of XSOAR’s many integration points, these IP addresses can be shared with other technologies:Have a custom policy within Mimecast or Proofpoint for blocked IP’s? XSOAR can hook into and add to those policies for you. Using cloud security technologies? XSOAR can also have them add the IP’s to their blocked lists. XSOAR is like an Octopus amid all these disparate technologies, holding them together and orchestrating collaboration.
Ben
Amazing article, thanks Ben for the concept, your work building it, and time typing it up for everyone to read!
Andy