Our analog world is full of vulnerabilities. I enjoy watching shows like Tiger Team and The Real Hustle because they offer good examples of their great numbers, and how easily they can be exploited. Interestingely enough, we don’t put alot of effort into minimising them either. Instead we accept risks, or transfere them with for instance insurance. We are more focused on detection and response rather than prevention. Likely because it’s evolved as the most cost effective method.

I believe paramount to why this works in the analog world, is because incidents are naturally detectable. If someone steals your juwelery you’ll eventually miss it. We know how much the loss cost, and since all of us have insurance we (or at least the insurance companies) have good averages on what a normal person is likely to loose per year and bases their premiums on that.

But a digital asset can be stolen in a number of ways without the owner knowing about it. Digital incidents aren’t naturally detectable, and we have no real numbers on the number of incidents and the average costs associated with them. In fact, there are insurances for digital security breaches and issues, but if we fail to detect them, when are we ever going to make us of our insurance? It will never be the most cost effective method. It seems like we have no option other than employing prevention and chasing vulnerabilities. But then again, since there are no perfect security, this approach will always leave us with an inaccurate view of incidents and no other options. Just another hamster wheel of pain. Find vulnerability, Patch and Proceed.

Last December I ranted a bit about Swedish security politics and just a couple of days ago ENISA - the European Network and Information Security Agency - released a report with recommendations on how to structure cyber security efforts within the European Union. Below are a few points that caught my attention.

Related to our lack of information on what is really going on out there:

“We recommend that the EU introduce a comprehensive security-breach notification law.”

“We recommend that the Commission (or the European Central Bank) regulate to ensure the publication of robust loss statistics for electronic crime.”

How else are we going to get a good picture of what is actually happening to others and how much it has cost them? My experience says that companies are getting really tired at hearing fictional stories and FUD. We need this.

Related to our inability of acting on issues:

“We recommend that the European Union introduce a statutory scale of damages against ISPs that do not respond promptly to requests for the removal of compromised machines, coupled with a right for users to have disconnected machines reconnected if they assume full liability.”

Internet have no boundaries. If a computer or network in Sweden is compromised and maliciously managed from Poland their respective ISP need to be responsible for disconnecting that machine and be held liable if they don’t. Our laws need teeth.

Related to vulnerabilities and patches:

“We recommend that the EU adopt a combination of early responsible vulnerability disclosure and vendor liability for unpatched software to speed the patch-development cycle.”

“We recommend security patches be offered for free, and that patches be kept separate from feature updates.”

Without a proper picture of where our vulnerabilities are, how are we supposed to be able to define our risk? Before the patch is available, how are we supposed to be able to counter a specific vulnerability with a countermeasure? A law that requires vendors to quickly notify their customers and the public about a vulnerability will allow companies to make the strategic decisions that is necessary. And of course patches should be free.

Last but not least, we need to collaborate on cybercrime.

“We recommend the establishment of an EU-wide body charged with facilitating international co-operation on cyber crime, using NATO as a model.”

Incidents happends to everyone, it’s just a question of when. Therefor, every company needs to plan for Incident Response. So does every nation and union.

Kudos to Enisa for a good report.

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?

I was just notified of multiple vulnerabilities in Check Point Secure Platform R60 . This is in no way surprising since all software have vulnerabilities, but the interesting thing is that the product is certified to Common Criteria Assurance level 4+ (EAL4+). This suits as a good example of why Common Critera and similar certifications mean squat in terms of security.

I do like one thing of the Common Critiera, and that is their choice of using the word “assurance” for describing the certification. We should treat any security investments as “an increased assurance of our resistance to security incidents”. The problem with CC is that a certified product in no way assures me that it functions as it promises (an IPS with zero-day protection is a good example, since those doesn’t exist) or that it is without flaws. The above mentioned vulnerabilities proves that.