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.
The definition of telemetry
Telemetry is the “raw data” we are collecting to process the events and produce the intelligence back to the end user (in our case Splunk). There are four categories of telemetry (DNS, IP, HTTP and TLS). DHCP and VPN data is used only for enrichment in AE. The amount of telemetry categories utilized depends heavily on the content that is being ingested. There are two components involved in the processing of the data – the Analytics Engine and the Wisdom API.
Below we outline what the telemetry data is and which data is sent to each component.
DNS
IP
HTTP
TLS
DHCP/VPN
- Timestamp
- Source IP address
- DNS request record type
- Timestamp
- Source IP & port
- Bytes in and bytes out
- Application protocol
- Security apparatus action
- Session duration
- Timestamp
- Source IP
- HTTP client method
- HTTP client referrer
- HTTP server status
- HTTP server content type
- Security apparatus action
- Bytes in and bytes out
- Web application fingerprint
- Timestamp
- Source IP
- Source IP
- Source hostname
- Source MAC
- Source username
- Lease duration
- Lease termination
- DNS request FQDN
- Destination IP & port
- Network protocol
- URL
- HTTP client user agent
- TLS server IP & port
- TLS server X.509 certificate
- TLS client JA3 fingerprint
- TLS server JA3S fingerprint
What's stored in the cloud
Some of the data the Wisdom API processes is stored in the cloud. The reason for storing data instead of immediately discarding it is as follows:
The stored data is encrypted at rest. Access to the data (by AlphaSOC personnel only) requires MFA. Everything is audited annually by a third party.
Deployment options
1. Accessing the AlphaSOC Wisdom API using cloud Analytics Engine
In this scenario the AlphaSOC NBA addon is installed on your Splunk search head. The addon sends the raw telemetry data to the Analytics Engine in the cloud and then to the Wisdom API. In addition, the Wisdom API of course “sees” the source IP of whomever is accessing it (the source ip of your Splunk installation). Whether or not this is a big issue is up for each and every AlphaSOC user to map to their own threat model, but this nevertheless at least requires you to allow some egress traffic from your Splunk search heads to AlphaSOC.
2. Accessing the AlphaSOC Wisdom API using on-premises Analytics Engine
In this scenario the AlphaSOC NBA addon is installed on your Splunk search head. The addon sends the raw telemetry data to the local Analytics Engine. The Analytics Engine then uses the AlphaSOC Wisdom API to query it for destinations it has not seen. The raw telemetry data stays between AlphaSOC NBA and the Analytics Engine. The Wisdom API “sees” the source IP of whomever is accessing it (the source ip of your Splunk installation), but in this scenario no egress internet traffic is necessary from the Splunk search heads – and the Analytics Engine 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 to your users.
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 analytics engine. What are we gaining? Practically nothing.
Thoughts and recommendations
A locally installed AlphaSOC analytics engine 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 analytics engine.
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.
