Archive for the Category Intrusion Prevention

 
 

Where’s the traffic? Filtering network traffic in virtualised environments

Ever wondered how intrusion detection solutions and vendors are acting on current virtualisation trends?

The most obvious peril hypervisors pose to virtualized network security is simply that they take that network traffic out of the range of conventional security devices. A packet sniffing appliance can’t see packets that never leave a given physical server. V-Agent solves that problem by residing within the virtualized network. It’s a logical approach to the problem.

V-agent by Catbird  is essentially a guest system - “a virtual security appliance” - that attatches itself and runs in the virtual network provided by the host (i.e. VMWare ESX) to virtual machines. V-agent then monitors and filters traffic between other guest system as a traditional IPS. Other functionallities provided by V-agent are NAC-like features for limiting the possibilties of accidently publishing guest systems, and protection of the “hypervisor”.

This is interesting, because virtualisation certainly twists the concept of the “network”. The cloud becomes even cloudier, so to speak. But virtual systems and guest machines are still essentially the same old Windows and Unix systems, and they use the same ways of communications as they always have. What is it to say that traditional solutions won’t work? They might just have to become a bit virtual?

Intrusion Detection and Prevention as threat centric tools

I’ve spent alot of time lately writing about how various security technologies fail. My idea is that the problem boils down to the fact that most of our security efforts are vulnerability oriented. Fixing the vulnerabilities seem to be the smartest thing to do, right? Problems is, we can’t keep up with patching and we aren’t aware of all our vulnerabilities, or even a small part of them. To some degree, we will always be vulnerable. In order to complement the natural patch management process I favor efforts and technologies that are threat centric instead of vulnerability centric; Meaning efforts that focus on preventing threats instead of instances of attacks at vulnerabilities.

In an attempt to make an example, have a look at authentication systems. Most of us understand that all passwords can be broken if the necessary time and resources are put into it. The security of the authentication system relies on the strength of passwords, and in order to higher the bar for brute forcing it we

  • create a basic policy that defines the minimum strength of the password (eight chars, with numbers etc).
  • we force the user to change the password every four, six or eight weeks.
  • we only let the user make three unsuccessfull attempts before disallowing any further attempts (or we incrementaly increase the delay between each possible attempt).

The first two points are vulnerability oriented, meaning they attempt to increase the strength of the password and as such decrease the vulnerability of the password. They increase the level of effort the threat must put into brute forcing the password. The last one, however, focuses on preventing any attempts of guessing the password. It doesn’t increase the strength of the password, but drastically limits the threats possibility to repeatably try passwords. This measure is threat oriented and no matter how much money or time he or she puts into buying equipment for crunching numbers, all they have is three attempts (there are other ways of defeating authentication systems though).

This kind of threat centric approach is what most Intrusion Prevention technologies lack. Common IPS:s functions as authentication systems without the threat centric part; They block individual attacks but passively lets the intruder keep trying until he crafts an exploit that slips through. Good examples are solutions that correlates alerts with vulnerability information of the target (which ISS does) in order to decide what to block. They forget to question whether the activity itself is acceptable. Just because the webserver runs Apache, all attempts at exploiting it as an IIS is ok? Or just because a perticular vulnerability isn’t present in this version of Apache, the activity is ok? This kind of thinking is, for example, what causes IPS implementation to fail at repelling penetration tests.

To be fair, some IPS:s have the necessary functionallity for being a threat centric tool. Juniper, for instance, has the option to block individual offending packets, an offending session and ultimately an offending IP for a configurable amount of time. Other IPS:s has similar functionality. Problem is that the functionallity isn’t used in an automated fashion due to the risk of consequences from creating long lasting blocks of legitimate traffic sources. This is why I advocate the involvement of a human to make the ultimate decision to block an offending IP for a given time, or use a good SIEM system (Security Information and Event Management) that correlates alerts with other information sources to get the knowledge of context necessary to make accurate decisions.

Expect to see more posts related to threat centric security in the future.

DR on Future firewalls - agrees on app awareness but misses identity awareness

Related to my earlier post Future firewalls are protocol, application and identity aware, Dark Reading today has an article spinning on the same topic entitled Firewalls Ready for Evolutionary Shift. I consider Identity and Application awareness to be the two most important features in future firewalls simply because they enable firewalls to function more like they were, and are, intended. An IP no longer identifies a user and a port number or even a protocol no longer identifies an application, and firewalls need to make their decisions on other parameters that does.

The article agrees with me on Application awareness, and as I, also reference Palo Alto Networks App-ID. In addition to that, Gartner also feels that integrated IPS-functionallity will be “next-generation”, which I don’t agree with. Integrated IPS-functionallity gives no new security functionallity. It is perhaps more practical, but it doesn’t solve any problems that IPS-systems have. That the article don’t mention identity awareness is sad in an otherwise great piece.

And, sometimes I wonder what Gartner is smoking. These paragraphs got my attention

CheckPoint, Cisco, and Juniper, for instance, already have some initial basic IPS capabilities in their firewalls today, Young says. “It’s less about firewalls and more about how networks and users have changed,” he says. “As they change, the firewall is forced to change.”

Gartner, Juniper is offering their full blown IPS as a blade in their ISG-series (Integrated Security Gateway).

IPS catch rates as identified by mu Security

Related to yesterdays post entitled IDS and IPS systems and their effectiveness on reppelling penetration tests, Network World recently conducted a review of the prevention-ratio from of IPS:s whom are a part of UTM-products.

We tested intrusion-prevention systems in two scenarios: protecting clients (such as Web browser) and protecting servers (such as Web and e-mail servers) separately. The percentages shown are scores from our tests using Mu Security’s Mu-4000 Security Analyzer appliance to launch the attack traffic, showing what percentage of the known vulnerabilities in each category (attacks against clients, and against servers) was caught by each IPS.

The tool used in the tests are from mu Security. My, very rough, analysis of the results

  • Juniper has the greatest detection and prevention rate with 87 procent catch rate of server-side attacks and 70 procent of client-side attacks. My conclusion is as such that IPS systems -at best- prevents us from roughly 80 procent of known vulnerabilities. Interestingly, this equals the ineffectiveness of anti-malware technology.
  • By doing a quick overview of the results I would say that the avarage prevention rate is around 35 procent of known vulnerabilities, validating that my saying that IPS-systems in general provide very little value.

A very important thing to say about the test is that it in no way models the nature of the threat. The tests are based on publically known vulnerabilities and exploits which all of the vendors have had access to if they had care to look for them (or contact mu Security for a couple of test runs). In reality, we face issues such as evasion, noise, unkown vulnerabilities and unknown services. The results of this test are as such the best possible outcome and should be considered overly optimistic. Still interesting, and WAY better than SC Magazines attempt.