over the last 20 years, a lot has changed in information security: encryption technology is better and more widely deployed; trust models are being developed and deployed in various ways; system security is, for the most part, no longer on the honor system; various authentication technologies intended to improve on password based authentication are becoming more popular, bringing along their own slew of issues. biometrics, once the bailiwick of pulp sci-fi authors, are now widely deployed at businesses and government agencies all over the world. the romanticized image of "hacking" -- late night sessions basking in the green glow of a vt100 terminal connected at 300bps to your favorite underground bbs -- is all but dead. the security industry has gone mainstream, and with it have come a raft of technical solutions to technical problems. while a lot has changed, we still have a long way to go.

technical solutions for technical problems are wholly appropriate. technical solutions to social problems, however, aren't necessarily the best solution. one of the hardest things for IT groups is managing the impact of security on the primary business goals of the organization. security is important, but how much are you willing to impact your business in order to achieve an acceptable level of security? that's a hard question to answer because it involves not only implementing technical solutions, but also changing the behavior of users.

so, the question i pose is: how can we address the social issues involved in infosec? soylent green is made from people, and more often than not, so are many security issues that arise in enterprise environments.

So, I went and got a hair cut yesterday. Actually, "hair cut" probably isn't the right term, since I accompanied my girlfriend to a "salon". (Yes, you have to call it that... I got corrected when saying "barber shop"). And it was significantly different - calling this guy a barber would be like calling Yo-Yo Ma a fiddler. He was a "stylist". Or a "hair designer". Or, perhaps a hair architect.

Of course, I spent the entire time asking questions about what he was doing - everything he did had purpose and was well understood. He was a scientist and an artist of hair. I now know far more about how hair (and especially my hair) works than I ever imagined.

That, of course, made me think of the creation of vulnerability detection rules. The old way of doing it is that of the barber - just whip something together that looks moderately good and works most of the time. No major issues - just "good enough".

Then there's the way that our guys do it - with intent and understanding of all the principles and rules behind what they're doing. I've seen vulnerability rules that I can only call beautiful - they're not just good, they're aesthetically pleasing in their elegance.

That's something I don't see when looking at Nessus - their rules are the "barber" type. Nothing against the product or the people - I really just don't find that the rule authors care about their craft. It's work done just to "hurry up and get it done", rather than getting it done right.

And, similar to my "hair architect" yesterday, it's alwaays the little things that makes the difference. He understood the waves of the hair and the texture with an eye that a normal barber wouldn't have. Just like one of the VERT guys can look at a vulnerability and understand the subtle nuances - the way the code line is likely to have produced the vulnerability, how it should interact with other parts of the code, etc. It's about experience and a lot of time spent studying craft.

And you can see the craftmanship in the results.

It's the difference between a Ford Pinto and a Jaguar. They'll both get you from point A to point B, but one will make sure you're safe and comfortable when you get there. The other just might explode on the way.

So, I've finally spent some real time reading the NIAC CVSS report and I genuinely believe that they made a mistake with the temporal metric.

What's worse is that they should know that they made a mistake. From the report itself:

"As a vulnerability ages, certain intrinsic characteristics will change with time. In many cases, when first discovered, a set of vulnerable systems will be at or close to its peak, while the availability of exploit and remedial information will be at its lowest point. As time progresses, patch information will become more available and more systems will be fixed as more exploits occur, driving the need for the fix. Eventually, the set of vulnerable systems will reach its low point as remedial information reaches its high point."

In other words, the vulnerability is most wide-spread at day 0, and is most severe for a given system at day n (where n >> 0).

This suggests to me that there are two useful metrics for talking about the vulnerability's severity:

• When talking about the vulnerability's Global Severity (i.e. impact to all systems), the vulnerability is most severe in its early days.


• When talking about the vulnerability's Local Severity (i.e. impact on a single host), the vulnerability grows continuously more severe as time goes forward.

The CVSS team realized that. Unfortunately, the products using CVSS are going to be rating Local Severity more often than Global Severity - Qualys, Symantec, etc.

This leaves them in a problem spot, because the way that CVSS handles the temporal metric suggests that it is concerned only with Global Severity - it starts at its highest point, and reduces the severity over time. From the paper again: "the temporal metrics serve only to reduce the base score by a maximum of 25%."

Unfortunately, the product space and the authors of the paper aren't taking this into account. It's going to end up doing a great dis-service to the security of the products and their customers. They'll spend their time patching the least-likely to be exploited vulnerabilities while the oldest, most exploitable vulnerabilities will continuously have their scores reduced.

It's an attacker's dream. They won't find any 0-days, but Unicode, Sadmind and the Slammer vuln are going to be less likely to be patched based on the recommendation of tools using this new scoring system.

It seems like a small issue on the surface, but it's going to cause huge repercussions over the long term and ultimately make us all less secure than we should be.

Anybody who has lived in the security industry for a while has read articles like this one. I have to say that I'm somewhat fatiuged by it.

Before I rant a bit, I'll issue a caveat: I'm the first to argue that the majority of people don't take security seriously enough. It's the first thing to go on most budgets, and if it weren't for regulatory compliance issues, it'd be the easiest thing in the world to dismiss with the "it won't happen to me" excuse.

But it's time to have the conversation as though people are intelligent.

The thing that bothered me the most was this line:

"Trust is nearly gone for email", Perry declared. I suspect it is gone completely.

The author then goes on to show that only 1-3% of email is legitimate, and suggests (by implication) that email faces a slow death.

I hate to say it this way, but that is ridiculous. Email isn't going away because of spam and viruses any more than snail mail went away because of junk ads and mail-bombs.

The key is to solve the business problem around it, not to make it go away. Email is here to stay. And no amount of FUD like "EMAIL IS DEAD!!! SPAM KILLED THE EMAIL STAR!" will change that fact.

I understand that it makes good business sense for the speaker (VP at Trend Micro) to spread this - his business is around sanitizing email from threats. But the real question around spam and viruses is about business - specifically, how much time and money are you spending to combat the problem?

It's really a time/space problem (as TK likes to say): how much time/resource are you wasting because of the threat. If you can then counteract it at a cost less than that, it's sensible.

Example: I get a pile of spam (100-200/day). However, my mail filters are good enough that I only see about 10/day. The cost is so insignificant that I simply delete those 10 (or add them to my mail filters) manually. I don't go out and search for a product to handle them, because it's such a small resource requirement.

I certainly don't stop using email because of it. Nor will I ever.

Read an interesting link from the linking integrity blog this morning about a Canadian CEO who has proclaimed that security is about brand protection (which should justify your security spend).

The whole article is here and uses Choicepoint as the example of why security breaches are about brand protection. The CEO (Mary Kirwin of Headfry) then makes the leap that, if security is about branding, it can't be about technology.

Talk about a muddle.

First, let me say that she's right. Not in the way that she thinks that she is, but she's right: security is not about technology. But it's sure as hell not about branding, either.

Security is about business.

Let me say that again.

Security is about business.

Sure, protecting and enhancing your brand is part of doing business. But it's not the whole thing.

Security processes are designed to add value to your business processes. If they don't, you're wasting your money. The rest of the article succeeds in making that argument - however, all of the quotes are narrowly focused. The other people are talking about metrics - it's all small picture stuff.

We need to start looking at Security as a value add to the business proposition - not as "technology", or "metrics", and sure as heck not as "brand protection". Sure, it provides all of those things, but security is really about enhancing the way that you do business.

Laurent Bossavit was talking about risk on his blog.

He arrives at a final definition of:

"Risk consists of future consequences, arising from present causes or foreseeable events, which - if they materalize - will exceed our normal capacities for coping."

This actually forsees an interesting point: there are actually two ways to avoid risk.

The first is to avoid or transfer the future consequences. This is the standard plan - either attempt to manage the risk, or transfer it to another party (e.g. buy insurance).

Bossavit hits on an interesting ability, however, which is tightly coupled to the comments I made recently on this blog: risk can be averted by increasing your ability to cope. That is, by creating more value.

This is where one can look at security processes as a value creation engine. If the process of securing your business process can also implement process efficiency enhancement at the same time as it actually is used for loss prevention, you will create a situation whereby value is added at the same time.

In this way, you're not only avoiding loss, you're also enhancing the value of your process at the same time - you're creating a situation by which your ability to cope with future loss is enhanced by a better utilization of your current resources.

A little while ago I read an article entitled “A long winding road out of beta”. Initially after reading the article I began to wonder what happened to the logic behind a beta release. Originally, it was a period of testing that was performed before a piece of software was released to work out any final bugs. What has changed between then and now? Are users getting used to unstable software? From a personal perspective, it has been disheartening to watch the general public come to accept “rebooting” a computer as a solution to a problem. To me, that is equivalent to buying a new bedroom set because the dresser handle has a loose screw.

As frustrating as it is, this general decrease in software quality also creates opportunities. As people get used to crappy software, a company with a quality product that is competitively priced stands to win huge Market share. This winning product may (and probably will) have fewer features than its competition. As long as it does what it was intended to do reliably, consistently and correctly, people will begin to see just how bad some of the other offerings are and switch.

I then pondered on what causes such a lack of quality. The short list of answers I came up with is: Lack of pride in a product, lack of peer-review, human error and compressed timelines. The list can grow indefinitely, but those were some of the major ones that stuck out to me.

How does one combat these confounding factors? For a lack of pride in a product, one must have people who have a personal stake in their work. By this, I don’t mean giving bonus’ based on achievements, I am referring to people that work for the enjoyment of the work itself and not the pay cheque that accompanies it. Happy employees do good work. Lack of peer review can be resolved by having people work cohesively in groups. The kind of group that sits in a room together actively discussing all aspects of their daily work, not one that meets a few times a week to give status updates to each other. Human error? Automation I say. Automate those tasks which do not require thought. Computers are good at doing. People are good at thinking. Lastly, compression of timelines must be defeated in the scoping stage. Every project has a momentum life-cycle. It is built slowly at the beginning, constantly increasing until a peak is reached and then rapidly decays. If a project is properly scoped, this peak happens about ¾ of the way through, which leaves time for final tweaking and wind down before project completion.

In the end, it all comes down to that “good” feeling you get when you complete a project. If it isn’t present, odds are, the final product is really a beta.