There’s a penchant by many to measure the quality of IPS solutions by the number of threat signatures supported by the IPS vendor. Checkpoint points to how it delivers “1,000s of signature, behavioral and preemptive protections.” Fortinet claims its FortiGuard IPS service inspects “Over 8,000 signatures consisting of 15,649 rules.” Cisco IOS Inline IPS “Supports more than 7000 signatures.” Presumably, the more signatures the more thorough the IPS. But is that really the right measure for today’s defending against today’s threat landscape?
The problem with signatures
Signatures are funny things. We might like the idea of specially crafted signatures blocking attacks, but every signature consumes compute resources. The more signatures applied, the more resources consumed. And since all security appliances are limited in their processing capabilities, running too many signatures ultimately requires upgrading (or replacing) the appliance.
The goal then should not be more signatures, but fewer signatures with greater impact. In fact, running too many signatures may be indicative of a problem not a solution. Many of the signatures available to the open source Snort IPS, for example, block attacks against old or no longer used applications, such as old browsers or deprecated applications. Other Snort signatures block traffic using specific details of an attack, such as domain names or IP addresses. But attackers will often change these parameters faster than it takes to issue Snort updates, rendering such signatures irrelevant.
So how do we improve the efficacy of our signatures? Well, certainly part of the answer is knowing when not to create a signature. Blocking attacks from specific domains or IPs is better done with a different kind of engine using reputation data. For example, a good reputation engine is updated by a large amount of data feeds involving thousands of entities (IP addresses and domains, for example) often on an hourly basis. Because of their dynamism, these engines have wider coverage than IPS. And unlike an IPS, they do not need to maintain a rule per entity. All of which allows reputation engines to be better at false positive handling.
But there is a deeper architectural challenge with Snort and traditional IPS systems. Even when they are packaged with other tools or share common management consoles their operation remains siloed. The pattern-matching language used to build the signatures cannot utilise information from other security modules, such as application control, antivirus, and URL categorisation and reputation. For instance, many Snort signatures search for patterns in text files as well as binaries, signatures that are very similar to those used by to anti-virus engines. The irony is that anti-virus engines run signatures very efficiently. There is no point in providing an IPS rule for the same capability.
This nominal interaction between components is intentional. IPS systems were designed to work at wire speed. Integrating their real-time processing with other security products introduces too much latency into the session. However, without that context, IPS signatures end up generating too many false positives, blocking “good” traffic, or too many false negatives, blocking too few threats.
The solution is context-aware protection
IPS could be more effective if signatures are built around the symptoms of an attack and not the specific details of the attack. To do this, the IPS provider needs a deep understanding of real-world traffic patterns. This can often be gained by leveraging big data insights from large volume of traffic. For example, in global network backbones. With that insight, the IPS provider can develop and test IPS signature for optimum effectiveness before releasing them to customers. And if delivered as a service, the IPS provider can then monitor and tweak those signatures to further minimise the number of false positives or negatives.
The real-word insight can be used in context-aware signatures instead of traditional signature. With context-aware signatures, the IPS leverages data from other security and networking sources to abstract signatures from specific variables. Instead of looking at specific domains or IP addresses, for example, context-aware signatures will look domains or IP addresses categorised as “unknown” or “malicious.” In this way, an IPS running context-aware signatures can identify different types of attacks, such as vulnerability exploits, and malware command and control communication, often missed by an IPS running traditional signatures, or only detected at the cost of significant number of false positives or negatives.
Essential to building these signatures is broader context. The signature’s pattern-matching language should tap the full context of networking and security data such as:
- Application and Identity context: The IPS should be application- and identity-aware to understand the risk associated with a potential network attack.
- Reputation context: Leveraging both in-house and external intelligence feeds, the IPS should detect or prevent inbound or outbound communication with compromised or malicious resources.
- Geolocation context: The IPS should enforce a customer-specific geo-protection policy, optionally stopping traffic based on the source and destination country.
- Known vulnerabilities context: Along with behavioural signatures, the IPS should protect against known CVEs, and rapidly adapt to incorporate new vulnerabilities into the IPS DPI engine.
- Network behaviour context: The IPS should detect and prevent unproductive inbound network scans.
To illustrate the impact of context awareness, consider how a traditional IPS might block suspicious IPs and URLs. Hundreds of signatures around specific domains or IP addresses is one approach, but a wasteful one. A context-aware IPS can block suspicious locations by leveraging geolocation restrictions, for example. The following example is from Cato IPS, but could just as easily be from any context-aware IPS:
Rich context has another benefit — performance. Normally an IPS does not have the visibility of the user environment, for example whether a device is an Android or and iPhone. As such, an IPS will run all of its signatures on traffic from all clients. This can lead to not just more false positives but also greater inefficiencies as the system inspects is irrelevant traffic. Ultimately, such an approach forces IT managers in a difficult position - run all signatures, ultimately forcing an upgrade to the IPS appliance, or significantly complicate the IPS deployment by having to evaluate and select the active signatures. The latter option forces IT to weigh the severity of a successful attack being detected by a signature, the signature’s anticipated impact on IPS performance, and the confidence level in the signature’s ability to correctly recognise the attack. A complex calculation to perform on thousands of signatures.
By giving the IPS deeper visibility into the packet stream, though, the IPS can be more intelligent in selecting the rules to be activated. Knowing a device is an Android means that the IPS can safely skip those signatures specific to Windows devices or iPhones, for example. Not only are there fewer false positive (and false negatives) to investigate, but system efficiency significantly improves, letting organisations gain the maximum protection with maximum efficiency.
With mobile devices, IoT, and the cloud, our IT environments are becoming more complex. With that complexity comes a growing range of threats. Stopping those threats can no longer be done efficiently with traditional IPS signatures. Context-awareness spanning multiple domains gives the IPS substantial stopping power, with fewer signatures, that are better aligned with today’s rapidly shifting threat landscape.
Dave Greenfield, secure networking evangelist, Cato Networks
Image Credit: Wright Studio / Shutterstock