As we know the future holds great things. Flying cars, tasty 0% Beer, and every platform offers a complete API.
But for now how do we interact with those odd solutions that don’t provide a good API?
All solutions must have a input/output otherwise they wold be a brick (though maybe a UI in JAVA is the only way), and often we can explore this.
Use SSH Commands in a playbook
Create a shell script on a Linux box, this file modifies the system (files, commands…) then restarts a service to take the config and then we simply call this script using a playbook.
Example: Squid Proxy. I wanted to add bad domains to Squid blacklists, but squid has no official API. So my SOAR playbook called, through SSH, a script that added the domain, checked the config, then reloaded the service. Squid now has near real time data.
Update static .txt files
Modify a remote file (HTTP PUT, SCP, FTP, other…) that the other solutions is known to use. The end application knows to re-ingest that file every x minutes even though it doesn’t understand SOAR.
Example – Bluecoat Proxy can read in txt files and use them in ACL. So a playbook needs to update http://10.0.0.1/bad_domains.txt and no API is needed.
HTTP scraping and parse
Maybe your target solution provides a webpage with data on, and you want it, well the data is there, it’s structured, so we just need SOAR to download the HTML body and extract elements.
Example – We’ve all tried to curl HTML and then parse through looking for the contents of ‘div id=”username” ‘ as we wanted info from a webpage.
Use an Expect-script
Expect scripts mimic a user typing keys on a keyboard and can even listen to what the end application has prompted for (e.g. when it sees “password>” it knows to type in ‘123456’). In this case we really are pretending to be an actual person!
Example – Connecting to an old Cisco switch via telnet
I’m sure there are other ways for other problems, but hopefully this gives an idea and helps you work around problems using old solutions.
Andy