AlphaSOC makes use of its Wisdom API for everything it does. The Wisdom API resides in the cloud, and the Wisdom API interacts with 3rd party services for automated lookups and makes use of threat feeds. Based on the feeds and the lookups and some internal magical trickery, the Wisdom API generates results that outperform traditional “lists”.
Not the enemy - but still perhaps in the threat model
“The cloud!” somebody shouts out loud. “This means my data is sent to the cloud – my precious telemetry data that in the hands of the bad guys could reveal too much about myself!”.
This is correct. And for the sake of transparency, let’s have a look at what actually goes on behind the scenes.
1. Accessing the AlphaSOC Wisdom API directly
2. Accessing the AlphaSOC Wisdom API using an on-premises AE server
In this scenario the AlphaSOC NBA addon is installed on your Splunk search head. The addon sends the raw telemetry data – specifically FQDN’s, IP’s & URL’s (including timestamps) that your clients and users are accessing to the AE server. The AE server then uses the AplhaSOC Wisdom API to query it for destinations it has not seen. The raw telemetry data stays between AlphaSOC NBA and the AE server. The Wisdom API “sees” the source IP of whomever is accessing it, but in this scenario no egress traffic is necessary from the Splunk search heads – and the AE server can be subnetted and NATted differently than the search heads. All in all, less data is sent to the cloud – and the data is much harder to specifically fingerprint.
What did life look like before AlphaSOC
In this scenario, we opted not to use AlphaSOC at all – and continue to let the analysts work their own ways as they have always done. Now to start with, there is of course a lot of manual searching going on. There might be a threat intel feed – or then not – but rarely many. The threat intel feed of course carries a separate cost in this scenario, and does not come with Splunk Enterprise out of the box. As the analyst does the analysts job, searches and then finds something that may be relevant, the analyst will manually post this data to several third party sites to find out more information. Again, this is all manual – and as the analyst is doing this, the source ip of the analyst is revealed – as well as the internet destionations beeing looked up to the third party service.
Without AlphaSOC we have manual searches, manual investigations and … well, a lot of manual stuff. In addition, we are “leaking” (for the lack of a better word) all the same information as we are in the scenario with the on-premises AlphaSOC AE server. What are we gaining? Practically nothing.
Thoughts and recommendations
AlphaSOC AE is a good option where network segragation, egress firewall policies and minimizing the data being sent outwards are part of your toolkit when you mitigate and manage your risks and threat models. For many, accessing the AlphaSOC Wisdom API directly is just as good a solution as using the on-premises AE server.
The risk of doing manual tedious labour during normal business hours instead of an automated engine doing automated relentless analyzing 24/7 for you – and only waking you up when the shit really hits the fans – is most likely much bigger than whatever risk you are adding by accessing the Wisdom API – regardless of how you are accessing it.