Discovering Network Traffic Anomalies to Identify Threats
It’s no secret; by nearly any metric available, cybercrime has grown at an alarmingly fast rate in recent years. As a result, organizations are desperate to implement new cybersecurity measures that increase their overall resiliency and ensure business continuity. However, keeping in mind the definition of insanity as “doing the same thing over and over but expecting different results,” it’s clear that we need to approach cybersecurity in a fundamentally different way to start leveling the playing field. To shake up cybersecurity, we have to start looking inward—literally—by monitoring internal network traffic for anomalies that can point out risks, violations of established controls and security issues before they become problems.
Some may rely on versions of publicly available block lists of malicious domains, URLs or IP addresses to protect their organizations from known and legacy threats, but this is a reactive approach at best. It does not protect you if you are part of an attack’s first wave and may not even block variations and continued evolutions of existing attacks. This is an approach based on hope: Hope that someone else will be affected before you and hope that the latest command-and-control (C2) architecture is identified, published on some list and then implemented into your own block list before you get hit. As many have wisely said, hope is not a strategy.
Monitor Internal Traffic for Anomalies
Given that everyone can and will be breached at some point, true business resiliency and a modern security strategy require organizations to monitor their internal traffic for anomalies that highlight risks and could be telltale signs of infection. Once malware has made its way into the organization, regardless of how it got in, it needs to communicate back out to its C2 infrastructure to obtain instructions and move forward with its attack. This means you can prevent damage and data loss if you see the communication and address the threat before it has time to do damage. But to do so, you need true and complete visibility. The only practical and efficient mechanism to do this—whether your environment is self-hosted, in the cloud, across multiple clouds or a hybrid of all of the above—is to gather, inspect and analyze DNS traffic (both east-west and north-south) via a protective DNS solution.
DNS is the ideal inspection and monitoring layer because over 93% of all malware uses DNS for C2 communication. The use of DNS also eliminates concerns around content inspection and the required adaptation to different protocols, letting you focus entirely on the identification of anomalies, such as, “Why and how often is device X talking to destination Y?”
Not all Anomalies are Nefarious
Obviously, not all anomalies are necessarily nefarious, but they provide a strong and unique signal for closer inspection. Common scenarios range from an internal server starting to communicate with a country that it has not historically communicated with to the simple emergence of a new remote destination that hasn’t been seen previously during typical communication patterns. In an ever-changing production environment, new versions of software may legitimately access different resources than they had previously, but it could also be the case that this communication shouldn’t be occurring at all. Regardless, it’s clear that this sort of anomaly requires further inspection to determine the correct next steps. A protective DNS solution provides an immediate alert and allows for near-real-time inspection and resolution as required, whether that resolution simply acknowledges that the communication is expected and should continue as part of a normal pattern or if it flags it as unexpected and initiates a follow-up action—up to and including blocking it, engaging incident response and cleaning up all lingering remnants.
Beyond security, monitoring DNS for anomalies can deliver key visibility for a variety of benefits. For instance, imagine that a new machine (physical or virtual) is deployed but misconfigured and, instead of following standard corporate policy to access software repositories from the local mirror, it is accessing them from a remote repository. This may not be a nefarious anomaly, but it can certainly introduce risk to the overall integrity of the environment. Controls are only as good as the visibility one has to inspect, manage and correct them.
Changes in Traffic Patterns
Baselining the normal traffic patterns can also be valuable to identify anomalies, saving time and reducing alert fatigue by keeping alerts accurate and to a minimum. This is particularly useful in a production environment, where traffic patterns should be relatively predictable and stable. The network communication patterns for databases, for instance, really shouldn’t change except with new software versions or specific re-configurations; other changes to their traffic patterns should trigger an immediate alert and inspection of the event.
By integrating knowledge of attacker infrastructure and network visibility into machine-to-machine communication monitoring, you can obtain insight into not just anomalies that highlight misconfigurations or violations of controls, but also the telltale signs of an attack in progress—signs that would otherwise go unnoticed in a perimeter-focused defense strategy. Once you notice an anomaly, you now have a window in which you can deal with the risk or threat before it causes damage, providing your organization with an invaluable and proactive advantage as part of a business resiliency and business continuity plan.
