Part One of this series can be found here.
Continuing on with our series, this particular post will revolve around "Security Information and Event Management" solutions (SIEM's), their place in the Enterprise, and how you can leverage their exceptional levels of visibility within SkyATP. Deserving particular mention is Juniper's Secure Analytics product-line which, along with our partner, IBM (QRadar), was identified as a leader once again within Gartner's 2016 SIEM Magic Quadrant. As documentation already exists for JSA/Qradar+SkyATP, for the purposes of today, I'll be focusing on the other SIEM MQ Leader, Splunk.
Over the last few years, Splunk has managed to solidify its place as a leading choice for Log Management within many verticals. While Splunk is not a traditional SIEM "out of the box", it can be made into a highly effective security tool via customization and/or by leveraging one of its many security-focused add-ons. For customers who do not necessarily need all of the advanced features included within JSA/QRadar, Splunk can be an attractive option. As you would expect, our SRX-series Gateways have always been able to tighly integrate with Splunk due to their inherent openness and verbose logging capabilities.
The importance of SIEM's within the Enterprise cannot be understated. Time has shown us that while Next-Gen Firewalls with advanced Layer-7 features, copious amounts of Threat Intelligence, and the latest Sandboxing technology can go a long way towards mitigating advanced threats, they are not the be-all and end-all of Security. Network devices are inherently limited in their threat prevention capabilities by the incomplete datasets that they can analyze; Only traffic that physically traverses a NGFW may be inspected. SIEM's, on the other hand, have the capability to monitor each and every entity on the network in great detail without relying on the hosts themselves transiting an inspection point. A fantastic example of this can be found here, where Splunk Engineer Bert Hayes describes a method for identifying Ransomware on Windows workstations. He does this, not by analyzing logs from security products (which of course would work if an agent were installed), but by analzing actual process behaviour on the workstation itself.
While advanced Sandboxing solutions such as SkyATP would be able to identify the hypothetical ransomware described in Bert's post, NGFW's do rely on the end-user downloading the infected file across one of their interfaces. During instances where the payload is delivered to the endpoint "out of band", such as via an infected USB drive, Network-based Sandboxing solutions are not able to intervene.
Once Splunk has been able to identify a host which has become infected, you can leverage the "Alert" function to trigger predefined behaviour. In this case, it would be useful to add this host to the infected-hosts feed within SkyATP to ensure the device is quarantined appropriately. If utilizing Juniper's pervasive SDSN solution, the quarantine would be enforced directly at the access-layer switchport, cutting off any and all abilities for the ransomware to propagate across the network.
Continuing on with our practical examples.
After settling into his desk around 9AM, Steve opens up his Splunk Security Dashboard and notices an upward tick in Critical level IPS events. He'd like to ensure that any hosts launching known exploits against his infrastructure are blacklisted across his entire Enterprise. While a single SRX is able to handle this via its own IDP policy (ip-action ip-block target source-address), he wants to propagate this information out to all SRX, regardless of if they've seen an attack launched against them from that particular source.
Additionally, Corporate has become increasingly concerned with the likelyhood of Data Exfiltration, particularly via covert, encrypted channels. They'd like to ensure that any suspicious connections utilizing encrypted applications are blocked immediately if there is a disproportionate amount of data leaving the Enterprise as compared to what is being received.
Example One: Automatically Blacklisting outside hosts triggering Critical and High severity IDP signatures
Steve begins this task by creating a simple search pattern to identify the appropriate events which should trigger an Alert:
sourcetype="juniper:srx" IDP_ATTACK_LOG_EVENT source_zone_name="Outside" AND (threat_severity="CRITICAL" OR threat_severity="HIGH")
Validating that there are results returned, Steve saves the query as an Alert (Save As -> Alert)
Critical-Severity ShellShock attack being launched from Outside by 45.55.219.243
In the next menu, Steve sets the Alert Type to "Real-Time" and defines a Trigger Action which will execute the script `SkyATP_IPS_Blacklist.sh` when triggered.
Once this has been configured, he deploys the following script into $SPLUNK_HOME/bin/scripts and ensures the appropriate permissions are set.
SkyATP_IPS_Blacklist.sh
I'm hopeful the comments contained within the scripts explain each step along the way. If you have any questions, please leave them below.
$ pwd
/opt/splunk/bin/scripts
$ sudo chmod +x SkyATP_IPS_Blacklist.sh
$ ls -lh
total 12K
-r--r--r-- 1 splunk splunk 71 Sep 23 11:24 readme.txt
-rwxr-xr-x 1 root root 2.9K Nov 21 12:16 SkyATP_IPS_Blacklist.sh
Once deployed, we can see that further attempts by 45.55.219.243 to exploit ShellShock are blocked pre-exploit by Secintel; The SYN packet from the attacker is dropped and never reaches the target server. Thus, no connection is ever established, and no exploit can be launched.
sourcetype="juniper:srx" SECINTEL_ACTION_LOG AND source_address="45.55.219.243"
Verifying the contents of a particular feed can be done on the SRX itself as well:
root@SRX-1500> show security dynamic-address feed-name Splunk_IPS_Blacklist
No. IP-start IP-end Feed Address
1 15.18.223.19 15.18.223.19 Blacklist/3 ID-21300043
2 45.55.219.243 45.55.219.243 Blacklist/3 ID-21300043
Total number of matching entries: 2
Example Two: Identifying covert Data-Exfiltration attempts across encrypted channels
Handling the Data-Exfiltration use case is relatively straight forward with the assistance of some simple math. Steve knows that Juniper SRX include both the packet-count and byte-count for each entity of a session within its logs. He also knows that during a file transfer, the average byte disparity between the device hosting a file and the device retrieving the file is approximately 25:1. For every 1 byte that the client sends to the server, the server will transfer 25 bytes to the client.
Using Splunk, he crafts a search pattern that looks for flows sourced from the Inside Zone of his Enterprise, where the outside server generates more than 1000 packets (to identify meaningful transactions), using a subset of the SRX's Layer-7 applications (AppID), and that the overall percentage of bytes transferred from the outside server is less than 5% when compared to bytes generated by the internal client. Using this logic, we can nearly guarantee that a file upload of reasonable magnitude is occuring when the log is received by Splunk.
The frequency in which Splunk recieves per-session Apptrack_Volume_Update logs from the SRX can be configured to be as little as one minute.
sourcetype="juniper:srx" APPTRACK_SESSION AND source_zone_name="Inside" |
where application="UNSPECIFIED-ENCRYPTED" OR application="OPENVPN" OR application="SSH" OR application="SSL"|
where packets_from_server > 1000 AND ((bytes_from_server / bytes_from_client)*100) < 5
Using this regex, Steve is able to immediately identify multiple instances of exfiltration occuring within his network.
A large data transfer occurring across OpenVPN destined to an AWS server is identifiedApplying the same logic for script construction as what was used within the IDP use case, Steve quickly constructs an alert within Splunk to block any future uploads utlizing the Secintel suite of SkyATP. Small modifications are required, in particular, modifying the regex identifying which IP to block.
SkyATP_Exfiltration.sh
We can see that now, once implemented, Splunk and SkyATP are able to coordinate and block all future exfiltration attempts from the Enterprise. In a real-world scenario, having the SIEM also kick-off an Incident Response process would be highly recommended to ensure the root cause of the leak is identified.
SkyATP's Secintel suite blocks future connection attempts to the C&C server