Related to yesterdays post on vulnerability date of birth SANS today presented annual SANS Top-20 2007 Security Risks. I like these reports because they summarizes the most critical public vulnerablities the current year, along with the vulnerability annoncement and all. But it also has some serious issues. From the reports executive summary

Just over the last year, the kinds of vulnerabilities that are being exploited are very different from the ones being exploited in the past.

Really? They are referring to vulnerabilities in client applications and web services, which are essentially just input validation flaws just as format string attacks and many buffer overflows. What is different is that the threat are targeting “very different software” but the the vulnerabilities are not “very different”.

They also doesn’t seem to understand the Date of Birth of a vulnerability:

We have seen significant growth in the number of client-side vulnerabilities, including vulnerabilities in browsers, in office software, in media players and in other desktop applications.

What they mean growth in the number of disclosed client-side vulnerabilities, because applications like Firefox, IE 6 and Acrobat Reader were all developed in 2006 and as such should be featured in those statistics if they want to express their growth. Here they suddenly get it:

Web application vulnerabilities in open-source as well as custom-built applications account for almost half the total number of vulnerabilities being discovered in the past year.

I think it’s sloppy by SANS to not take care when choosing their words. It has become something that is almost expected. Besides that, the report features some good content.

Once every now and then I see reports mentioning the decrease or increase of vulnerabilities. Most of the time, these statements are based from statistics of publically announced vulnerabilities during a specific time period, which can make you wonder - when is a vulnerability actually born, and when is it dead? I think whenever the vulnerability is fixed, i.e. patched, answers the second question and here is a good answer to the first one:

DOB = The “date of birth” of the vulnerability. For software manufacturers, this is the date of first release to users. For enterprises, this is the date of implementation of the software that has the vulnerability in question.

We shouldn’t be so focused on statistics of publicised vulnerabilities since they don’t measure the existence of vulnerabilities, but more likely the effort in finding them. The only way we can decrease the total amount of vulnerabilities are to get rid of them, i.e. by patching. Likewise, the only way we can increase the total amount of vulnerabilities is to add code with vulnerabilities, i.e. create new insecure applications (or perhaps a patch?). Since patches usually follows from vulnerability annoncements that should mean that more vulnerability disclosures means more patches which means more secure software. So, shouldn’t we be conserned if publically announced vulnerabilities drops?

Data Leak Prevention is yet another hyped technology. These are solutions that aims to protect sensitive corporate data from being disclosed or stoled, or more formally to

“protect data at rest, in motion, and in use through deep content analysisâ€?.

The technology used is similar to Intrusion Prevention by both it’s name and by its means (content analysis). The main difference is that they look for indications of leaking data instead of attacks. Here is a great six-part overview of these products by ex-Gartner analyst Rich Mogul.

Somehow I’m pessimsistic about these solutions. The simple reason is that it is is resonable to assume that a person with the intents of leaking data would at least take some action to do it stealthy. Some simple actions that causes problems for these solutions would be to:

• Transfer the information by other protocols than standard messaging such as HTTP, SMTP or IM. Why not use Cryptcat, DNS, ICMP or another covert channel? Or chop it up and send it by many different protocols?
• Use another physical mean of transporation. Why not save it on a floppy, cd-rom, usb-drive or beam it to the PDA? Take a photo of it or just try to remember it?
• Modify the information. Why not rename or resave the file, translate the information to another language, encode or encrypt it?

The failure to combat these is why some argue that DLP solutions are limited to preventing mistakes, rather than intentional leaks. I suppose issues with credit-card and identity theft is driving companies in investing in these solutions, and the belief that these systems will act as another layer when their intrusion prevention systems fails on them.

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.

Dan Geer is a smart man. His recently released paper A Quant Looks at the Future Extrapolation via Trend Analysis is probably one of the best trend presentations I’ve seen. What Geer has done, essentially, is to analyse trend reports from various companies and institutions, including Symantec, Counterpane etc. From the paper:

Why do trend analysis? First, trend analysis is what a statistician will recommend when the underlying topic of interest is changing and the method of measuring it is uncertain. In such a circumstance, and so long as the measurement you do have can be applied consistently, the trend data can be relied on and it is what you need for decision support. Of course, making decisions early is more expensive in decision cost than making them later, but then again later decision making generally comes with fewer workable options.

I’ll go there whenever I need figures, and to understand what they mean.

I argue that IDS and IPS system by default are of little use as protection from targeted, focused, penetration attempts. While some of these systems provides the means of doing so, the lack processes, routines, a human mind, eyes and actions cripples them.

Here’s an interview that highlights these systems inability to do just that. From the interview,

In the majority of cases, they [read: IDS/IPS] just don’t end up doing what they were purchased for. An easy test that most fail is with basic port scans (that almost all are configured to pick up). We assume most are picking up “loud� scans (really fast and obvious scans with no attempt to be sneaky about what we are doing), but few people are pulling us up on this. (Keep in mind, with a majority of our tests, we recommend that clients don’t tell the operations team responsible for monitoring these devices that we are going to test – thereby, we also test the response effectiveness).

Validation and feedback is one of the pillars of security. It’s the only way that these solutions provide security assurance - they don’t do that right out of the box.

This is also spot on

An IPS only forces the attacker to know their exploits better, and take things slower. For instance, an IPS may drop all packets that have NOP sleds in them (0×909090 etc) which is used in a lot of (kind of sloppy) buffer overflows. It is however possible for an attacker to stop the IPS from seeing this.

What fails here, as well as in the earlier port-scan example, is the lack of response. Any alert or action that comes from a targeted penetration attempt should be followed by watchlisting relevant IPs and looking for further signs and attempts, possibly looking at capturing flow and full content data and other types of logs etc. Blocking shouldn’t be limited to the specific session that holds the exploit, but more importantly any following traffic. That will make the assessor work for their money.

Some brief notes on how to enable sFlow on an Extreme Network Summit 250 switch.

Define where to send sFlow-records

configure sflow collector ip 6343 vr "vr-default"

Configure the sample rate. Here the switch is the configured to look at every 512:th packet. InMon provides recommended settings depending on network and traffic.

configure sflow sample-rate 512

Configure a limit as to how many samples the CPU can process at a time, this avoids the sampling process from having impact on the performance of the switch.

configure sflow max-cpu-sample.limit 2000

Enable sFlow sampling on chosen ports. Remember that sFlow is only sampled on ingress traffic - i.e. traffic coming into the specific port. This means that we have to enable sFlow on at least two ports in order to sample traffic going in both directions.

enable sflow ports 1,2

And of course

save

If I recall everything correctly that is about it. InMon has a good reference for sFlow in general and product specific configuration

This is a good piece from Microsoft where they mention the value of security monitoring. From the article

The primary goal of a security monitoring and attack detection system is to help identify suspicious events on a network that may indicate malicious activity or procedural errors.

Microsoft apperently understands the importance of really looking for indications of attacks, instead of living in belief that systems are impenetrable and that security products will offer protection. Their suggestions with regards to the actual process and routine is also accurate:

A security monitoring solution is actually a continual process of planning, implementing, managing, and testing, because that is the very nature of security monitoring. Because the threats to business networks are always changing, the system that monitors the security in a business network must also change.

This process is suggested as a part of their Microsoft Operations Framework (MOF), which also features other operational routines.

I like that Microsoft is putting some effort in the defining the operational requirements for managing their systems and environments. The lack of these kind of security operations are what makes companies fail, not that they don’t have enough security products. The article also features some good hints on analysing Window Event Logs.

A post at the Snort-users mailing list took me to the “best intrusion detection/prevention solution”-competion at SC Magazine. First, is it actually a competition? Deciding something by voting is what I call an election?

Leaving that aside, two things strikes me.

First, what are the critera for deciding what is best? Best as protection against security incidents, most good looking, easiest to administer or the least pricey? Have the voters something to compare with? The results would most likely point to “the most used”, not “the best in terms of protection”. When the results of the “competition” is presented and Snort is the winner, then I consider myself right :)

Secondly, how have the nominees been decided? Among the nominees I see a product that only does wireless (AirDefence), a product that only looks at the host (CA HIPS), a UTM-product (Fortinet), a NBAD-product (lancope), and finally, but also the most striking: an IPS as a managed service (Verisign). Hell, on what criteria have they decided upon these vendors/products? And where are their competitiors such as Juniper, TopLayer, and why not Bro, and where are all the SIEM-solutions?

NSS has the closest thing to a good evaluation standard of IDS/IPS-system. Not perfect though, but I hope people look, and pay, for those reports instead of making decisions on the results of crappy “competitions”.

The has not been much innovation in the firewall market for some time. Sure, they are stateful and performs deep inspection etc but due to the fact that most of them still look at TCP and IP protocol headers for identifying traffic and applications they have too many flaws to be considered a security device. I consider firewalls to be more of a networking device than a security device, since it’s main purpose is to connect untrusted and trusted networks, but not to secure the connections.

There are two basic flaws with common firewalls that makes them unsuitible for calling a security device. IP and Port-number-centric firewalls are flawed since:

• IP-adresses doesn’t properly identify a single user or even a single machine. Current trends of virtualisation makes this even more true. Having IP:s as source and destination-variables isn’t granular enough.
• Port numbers doesn’t properly identify a protocol. There was a time where port 80 was used by HTTP, but today many applications use port 80 for their traffic. One example is Skype. Having port numbers as protocol and application identifiers isn’t granular enough either.

Future firewalls that live up to the requirement of properly identifying users and applications are however to some degree already here. One innovative company is Palo Alto Networks whoms “Next generation firwall” uses a technology they refer to as App-ID

App-ID is a revolutionary traffic classification technology that enables administrators to see exactly which applications are running on their network-irrespective of port, protocol, SSL encryption or other evasive tactics. Architected to address security evasion tactics such as the use of non-standard ports, dynamically changing ports and protocols, emulating other applications, and tunneling to bypass existing firewalls, App-ID gives administrators newfound powers of control over their application traffic.

I like this because allows firewall policies to be described in terms of applications, such as Skype, Bittorrent, HTTP or SMTP instead of service objects that rely on port numbers and header information. There are open source projects that develops similar technology to App-ID, such as L7-filter

L7-filter is a classifier for Linux’s Netfilter that identifies packets based on application layer data. It can classify packets as Kazaa, HTTP, Jabber, Citrix, Bittorrent, FTP, Gnucleus, eDonkey2000, etc., regardless of port.

Besides being application-aware, Palo Altos firewalls integrate with Active Directory to tie users to IP-adresses. Juniper Networks also does that - and much more - in their Unified Access Control-concept (pdf). In that concept the firewall policies uses the user identity instead of IP-adresses, among other things.

Update:

A good interview with founder of Palo Alto Networks, Nir Zuk.

“I think that a more important trend in network security today is the
move from port-centric to application-centric classification
technologies. This will make most of the existing products obsolete,
similar to the way stateful inspection has made its predecessors
disappear from the world…”