In the physical world, the benefit of combining detection with prevention seems more clear. A fence with razor wire will deter a casual intruder or pedestrian from wandering onto a property, but a fence can be cut or climbed even with razor wire. We could built a stronger or higher barrier, perhaps a large steel wall, but this is expensive. It's more cost effective to install motion sensors, alarms, and cameras to alert security staff if someone violates the perimeter. This does not analogize well to network security.
It might be difficult to climb a razor wire fence without setting off nearby motion detectors or being seen by the guard monitoring the area with security cameras, but a network attack that can bypass our perimeter defenses will often bypass a NIDS as well or can be easily modified to do so. For instance, Snort has rules to detect some known exploits for known vulnerabilities. If an attacker uses one of these exploits, Snort will trigger an alert. This isn't very valuable. If the vulnerability is known we probably should have patched it already. With good patching procedures, regular vulnerability scanning, and a firewall to prevent direct connections from the Internet to our internal servers, we shouldn't be exposing anything with known vulnerabilities anyway. If an attacker uses an exploit for an unknown vulnerability in an exposed service, he will presumably bypass our preventative defenses and Snort won't be able to detect it (because it's unknown, no signature) so he'll have bypassed our detective measures as well. If we do have an exposed service with a known vulnerability and Snort has a signature for one or more known exploits for that vulnerability, a clever attacker can just modify or obfuscate the payload to avoid detection. The best case (for Snort) is that a signature is available before we are able to patch the vulnerable system in which case Snort provides us with some protection during the window between the signature being installed on Snort and the patch being installed on the vulnerable system.
There is some value in detecting failed attacks. An attacker may try more than one attack before he is successful so detecting failed attacks could help to make his intent clear and aid our interpretation of later alerts. That said, we still need to detect something once he is successful.
Sticking with signature based IDS like Snort, let's say we remove all of the signatures that aren't applicable to our environment (e.g. remove Oracle rules if we don't run Oracle), remove all of the rules that are too out of date to matter (e.g. teardrop), and also remove all of the rules for things that we're definitely blocking anyway. Once we do that, how much is left? Using the remaining rules, what is the probability that if an attacker successfully penetrates our network the IDS will notice? It's a difficult question and I don't have an answer. But, if we're going to keep recommending IDS as a best practice in network security it's something we should be trying to answer. If IDS doesn't perform as advertised, we (or our clients, employers, etc) should be spending money elsewhere.
To be clear, I'm not suggesting that IDS don't ever detect attacks. They do. My concerns are the reliability with which they do so and the ease with which an attacker can evade the IDS if he chooses.
Many of the successful attacks and data breaches are not traditional network penetrations. They're web based attacks and client-side attacks (generally malware). One article claims that 97% of data breaches are due to SQL injection. That seems a little high to me--I'd have guessed 70%--but the trend is real. Web based attacks are harder to analyze for a number of reasons: web based attacks don't require port scans (which are noisy), they don't require compromising multiple machines, they don't require exfiltrating data over unusual channels, and they don't require a continued presence. An attacker can use a SQL injection attack to dump a table from the database or insert a malicious javascript into a discussion forum and he's done.
Does anyone think that NIDS is the appropriate tool for stopping/detecting web based attacks? For simple protocols, simple pattern matching may suffice. For the web... Web applications are incredibly complex and the pattern matching offered by signature based IDS is not sufficient to capture the variety of possible SQL injection, XSS, CSRF, etc. The lack of application awareness, not to mention the traffic we miss because of SSL, are big problems.
Snort offers a variety of signatures for detecting client-side attacks as well, but here I don't even see the point. It seems that the AV vendors are better suited for detecting malicious code on the client and they don't do a great job of it despite having a much larger signature base. See here and here.
Recently, I've asked in several forums about the effectiveness of IDS and the most common response I get is that "it depends on the person running the IDS." In this context, that's absolutely not true. The job of an IDS analyst is to respond to alerts and tune the IDS to reduce false positives. For the sake of this discussion, I'm operating under the (optimistic) assumption that we'll have a good IDS analyst and the IDS will be tuned properly so that the staff aren't flooded with false positives.
So, am I wrong to assert that NIDS are not the right tool for detecting web based attacks?
Am I wrong to assert that AV is better at detecting client side attacks?
Are NIDS effective at detecting network penetrations? Does the coverage from NIDS overlap too much with what we're already accomplishing with preventative defense?
I've leave you with this:
Edit: Chort posted a substantial response here.
No comments:
Post a Comment