In response to a post on risk versus uncertainty.

“people spend too much time trying to reduce uncertainty and too little time focusing on reducing risk.”

My impression is the exact opposite. Companies spend to much time (and money!) on ad-hoc attempts in reducing risk with no control of where their biggest risks are or how these countermeasures actually pays of in terms of risk reduction. There is too much focus on headline-threats and efforts resembling “fire-fighting” and “socker-goal security”. Companies buy firewalls, intrusion prevention systems, data leak prevention solutions for millions so the can put them into place and forget them. There is too much uncertainty in daily security operations, which is why I think that reducing uncertainty is crucial. Companies often can’t answer the simplest questions. I say implement solutions that give you insights in vulnerabilities, threats, assets and ultimately risks (no, the answer isn’t an annual risk-analysis paper exercise). Then (!) implement measures for risk reduction.

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).

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.