I’ve been asked how to prevent illicit network penetration enough times to realize an esoteric discussion of the recent advances in intrusion detection and firewall protection is not what’s needed. What is needed is a clear picture of available preventative measures, and which of the preventative measures work as advertised.
Getting up to speed, for me, means paying attention to a certain independent test lab. For the past two years, the people at NSS Labs have been testing how well Breach Detection Systems deal with Targeted Persistent Attacks.
It’s entirely understandable if Targeted Persistent Attacks (TPA) and Breach Detection Systems (BDS) are unfamiliar, or appear to be incorrect acronyms. To get that sorted out, I talked to John Pirc, Research Vice President at NSS Labs and published author. Starting with Targeted Persistent Attacks, I asked John why NSS Labs didn’t use Advanced Persistent Threats (APT) like everyone else.
“The truth of the matter is that an APT is sometimes made up of known exploits/vulnerabilities that are not that Advanced; so the term APT doesn’t define the action correctly. TPA highlights that the actor is going after a specific target such as company X or an entire industry sector like financial services, and will be persistent in attacking the target”
John also mentioned there was a detailed examination of APT versus TPA in this blog. Next, I asked John why NSS Labs prefers to use Breach Detection System instead of Next Generation Intrusion Prevention System and Next Generation Firewall:
“The BDS, NGIPS, and NGFW products are similar in that all three can contain signatures and heuristics for identifying malware. However, a BDS separates itself from the pack with its ability to analyze the patterns of network traffic, identify malicious domains, and model the behavior/impact of files that are being downloaded and executed on an attack surface.
In some cases, BDS vendors are able to detect zero-day malware at various stages of propagation, and provide remediation. The ability to identify still-unnamed malware on your network is almost like having your own zero-day research team on site.”
BDS technology having proactive capabilities plus remediation is significant. I asked John how that was accomplished:
“What separates BDS from IDS/IPS is detecting unknown malware. Breach Detection Systems, unlike IDS/IPS, have the ability to model malware behavior through emulation and sandboxing or a combination of both. This places BDS at a distinct advantage over IDS/IPS; as they can identify the presence of dropped files, analyze them, determine if they are known bad or unknown bad, and monitor for command and control callbacks.”
Now that we’re on the same page, I’d like to look at how NSS Labs goes about testing Breach Detection Systems.
To start, this excerpt from the BDS Test Methodology paper describes what the testers will be looking for:
- Centralized management of multiple devices.
- Breach detection capabilities using one or more of the following methods:
- Malware identification (signatures, heuristics, or both).
- Network traffic analysis (flow monitoring, content analysis, or both).
- Sandboxing that allows for modeling internal systems (workstations and servers).
- Browser emulation.
- Domain reputation to identify malicious domains.
- Response mechanisms (for example, alerting, session termination).
The remaining 18 pages of the test methodology report go into intimate detail explaining how the engineers at NSS Labs determine whether a BDS device meets expectations or not.
At the beginning of this article, I mentioned my reliance on NSS Labs to get a clear picture of this complex technology. To get that clarity, besides reading how NSS Labs tests BDS, I also read their annual Breach Detection Systems Buyer’s Guide. The 14-page report is chock-full of analysis and recommendations. For example, here are some overall conclusions of the systems tested this year:
- A BDS is able to detect threats by using a network appliance or stand-alone endpoint, or by using a combination of both.
- A BDS can identify pre-existing breaches as well as malware that is introduced to the system through side channels.
- A BDS that is unable to identify side-channel attacks or command and control traffic from infected machines is little more than a network AV device.
- While high-end network core switches will be capable of supporting most BDS requirements, NSS engineers have noted port-spanning issues with many workgroups switches.
Next NSS Labs offered the following advice for those thinking about purchasing a BDS: “Enterprises looking to deploy a BDS should understand that there are differences in the maturity, technology, and scalability of the solutions that are offered by different vendors.”
Both the paper on BDS test methodology, and the BDS buyer’s guide provide an abundance of information, affording IT pros the opportunity to get familiar with Breach Detection Systems.
Here’s a list of vendors that are offering BDS products.
- Check Point
- Palto Alto networks
- Trend Micro
John mentioned that not all of the above vendors have submitted systems for testing as of this post, and to contact NSS Labs to see if there is a test report on a system you are considering.
With something as complex as Breach Detection Systems, I’m glad there is such a thing as a buyer’s guide. I’d be nervous having to base a decision on one vendor’s market-speak versus another’s.