As we return to our series on New Age Network Detection, let’s revisit our first post. We argued that we’re living through technology disruption on a scale, and at a velocity, we haven’t seen before. Unfortunately security has failed to keep pace with attackers. The industry’s response has been to move the goalposts, focusing on new shiny tech widgets every couple years. We summed it up in that first post:
We have to raise the bar. What we’ve been doing isn’t good enough and hasn’t been for years. We don’t need to throw out our security data. We need to make better use of it. We’ve got to provide visibility into all of the networks (even cloud-based and encrypted ones), minimize false positives, and work through the attackers’ attempts to obfuscate their activity. We need to proactively find the attackers, not wait for them to mess up and trigger an alert.
So that’s the goal – make better use of security data and proactively look for attackers. We even tipped our hat to the ATT&CK framework, which has given us a detailed map of common attacks. But now you have to do something, right? So let’s dig into what that work looks like, and we start first with the raw materials that drive security analytics – data.
In the olden days – you know, 2012 – life was simpler. If we wanted to capture network telemetry we’d aggregate NetFlow data from routers and switches, supplementing with full packet capture where necessary. All activity was on networks we controlled, so it wasn’t a problem to access that data. But alas, over the past decade several significant changes have shifted how that data can be collected:
We should make some finer points on whether you need full packet capture or only metadata for sufficient granularity and context for detection. We don’t think there it’s an either/or proposition. Metadata provides enough depth and detail in most cases, but not all. For instance if you are looking to understand the payload of an egress session you need to full packet stream. So make sure you have the option to capture full packets, knowing you will do that sparingly. Embracing more intelligence and automation in network detection enables working off captured metadata routinely, triggering full packet collection on detection of potentially malicious activity or exfiltration. Be sure to factor in storage costs when determining the most effective collection approach. Metadata is pretty reasonable to store for long periods, but full packets are not. So you’ll want to keep a couple days or weeks of full captures around when investigating an attack, but might always save years of metadata. Another area that warrants a bit more discussion is cloud network architecture. Using a transit network to centralize inter-account and external (both ingress and egress) traffic facilitates network telemetry collection. All traffic moving between environments in your cloud (and back to the data center) runs through the transit network. But for sensitive applications you’ll want to perform targeted collection within the cloud network to pinpoint any potential compromise or application misuse. Again, though, a secure architecture which leverages isolation makes it harder for attackers to access sensitive data in the public cloud.
Another complication for broad and effective network telemetry collection is that a significant fraction of network traffic is encrypted. So you can’t access the payloads unless you crack the packets, which was much easier with early versions of SSL and TLS. You used to become a Man-in-the-Middle to users: terminating their encrypted sessions, inspecting their payloads, and then re-encrypting and sending the traffic on its way. Decryption and inspection were resource intensive but effective, especially using service chaining to leverage additional security controls (IPS, email security, DLP, etc.) depending on the result of packet inspection. But that goose has been cooked since the latest version of TLS (1.3) enlisted perfect forward secrecy to break retrospective inspection. This approach issues new keys for each encrypted session, preventing inspection devices from being able to terminate encrypted connections. Since we can no longer rely on seeing into encrypted packets, we need to get smarter – literally. At this point machine learning (or artificial intelligence, if you prefer that term) comes into play. By analyzing headers for insight into source and destination, frequency, and packet sizes, detection vendors can identify legitimate encrypted network traffic. Then network detection functionality can recognize those patterns. Another option for TLS traffic is to analyze the handshake between source and destination. The signature of the handshake, known as JA3 or JA3S (for server traffic), doesn’t change. When you detect a new handshake you can perform additional analysis of the destination to make sure it’s legitimate. Of course this approach requires some tuning – new connections are not necessarily malicious – but once the system is tuned this approach works well. You’ll also need to focus on the access control aspect of network security to supplement your detection and analysis. For example if you allow inbound SSH to instances or servers for management, you should only allow those connections from a small set of trusted IPs (your internal networks and approved remote networks). You can (and should) supplement the security of the inbound connections by requiring MFA as well. What does this have to do with network detection? Nothing really, but we cannot guarantee you’ll be able to see inside packets, so you’ll need some workarounds to ensure data is protected.
Once you have the data collected and aggregated, it’s time for some math to figure out what’s going on. That’s easy for us to say, but there are so many methods to analyze data – how can you know what will work best? Let’s work through the different types of techniques used by network detection tools.
Another consideration is where analysis takes place: either on-premise or in the cloud. From an enterprise standpoint, so long as detection is accurate and timely, you shouldn’t much care. Although mining a crap-ton of network telemetry is likely to require a big (expensive) set of devices. But the alternative is to send your security rules and sensitive data to the cloud, and you probably pay to move data there, so you’ll need to weigh your options carefully. It all comes down to coverage of your needs for collection, cost-effectiveness, and accuracy. You’ll also be able to enrich collected data before analysis, adding important context to help identify attacks. For instance you could tighten alert thresholds on more sensitive segments. Detection vendors can add additional detections to their analyses for common traffic patterns (see encrypted traffic, above). Then they leverage insights gleaned from their own research teams and analysis of their other customers’ data. It’s timely and generating high interest, so we should mention that these analysis techniques can apply to a broader dataset than just network traffic. That’s what XDR (eXtended Detection and Response) is poised to do. There will be a lot of noise about XDR, and it is an exciting opportunity to build attacks models based on robust multi-faceted data. But let’s not get ahead of ourselves. Detection needs to be use case driven. So we’ll wrap up this series with a focus on how New Age Network Detection can help with use cases like threat hunting, insider threat detection, command and control detection, and everyone’s favorite: ransomware.