We get this question a lot: Can you analyze encrypted traffic for cyber threats?
The short answer is yes, you can analyze encrypted network traffic, though there are caveats. For example, you cannot read the contents of encrypted traffic that uses the Secure Sockets Layer or Transport Layer Security (SSL/TLS) protocols, which are commonly used to secure web communications in transit. That’s by design, of course, because in many ways the purpose of encryption is precisely for that reason. As such, encryption is both a benefit and a challenge for the defender striving to protect the network.
What the defenders can use is metadata to examine encrypted traffic for threat indicators. Every network transaction, even those that are encrypted – like a website call or a web request – has data that describes it: originating IP address, destination IP address, the network protocol being used (HTTPS), the number of packets sent and the byte count, among potentially hundreds of other attributes. These attributes can be examined to help identify threats or potential threats in several ways – here are three techniques we commonly see:
1) Monitor traffic flow for network anomalies.
The first way is to monitor traffic flow for metadata attributes that indicate abnormal network activity. This works the same way for both encrypted and unencrypted traffic. A newly-established connection, between two machines, that does not typically happen is a good example – a server that an outside supplier legitimately uses to manage IoT devices starts calling a machine that hosts the partner bill payment system. The traffic may be encrypted but you are able to identify that connection as suspicious because these two hosts shouldn’t be talking to each other.
2) Identify anomalies related to the use of encryption.
The second technique is to study the way your organization stands up encrypted communications and profile that behavior. Typically, when encrypted channels are established, two hosts exchange certificates that make an agreement as to the level of encryption. These certificates contain metadata that can be profiled and monitored.
Mismatches between ports and protocols can also be useful for finding anomalies related to the use of encryption. For example, SSL traffic on Port 80, which is typically used for plain text (HTTP) communication, or vice versa, unencrypted traffic on Port 443, which is typically used for secure communication (HTTPS).
3) Profile threat actor encryption behaviors.
JA3 is an open-source software project that offers a relatively new technique for profiling SSL encryption behaviors. JA3 uses attributes of the certificate exchange to create a signature for how that exchange should look and then monitors for deviations. For example, every time a web browser visits a website, the client sends a certificate to set up a secure channel for that communication. Those certificates are specific to that browser version, which enables security to monitor for signatures and distinguish between known threats and authentic channels.
The JA3 project provides a module for Zeek IDS (formerly known as Bro IDS) and is available for download on GitHub. The module was developed by John Althouse, Josh Atkins, and Jeff Atkinson (hence the name JA3) who are members of the security team at Salesforce. The video embedded nearby is from a presentation called Profiling and Detecting All Things SSL With JA3, which the team provided on the capabilities of JA3 in early 2018.
- Bro IDS is One of the Most Powerful Cybersecurity Tools You’ve Never Heard Of
- How Bro IDS can Help Security Capture Institutional Knowledge for Cyber Alert Enrichment and Better Network Traffic Analysis
- What is Bro? And Why IDS Doesn’t Effectively Describe It [Overview and Resources]
- Snort, Suricata and Bro: 3 Open Source Technologies for Securing Modern Networks
If you enjoyed this post, you might also like:
Here is How Open Source DIY Fatigue Saps Cybersecurity Resources