Somebody had to be the one to write the first post on our new nCircle VERT weblog.

at least for today. figure i'd post my own "me too hey it's just a test is this thing on" message.

Next week, I'll be in San Francisco at RSA - I'll be blogging some of the highlites of the show, including our event with Gartner and our cocktail reception.

We're also going to have an OVAL Board get-together at some point - should be interesting to meet a lot of those people in person, especially now that we're kicking off the development of the unauthenticated side of the OVAL schema.

I was talking to a reporter yesterday about RSA - he said that he had never seen so many security companies contacting him about a show before. It's interesting to see the growth in this industry. I think it's mostly due to the fact that security is a relatively big buzzword these days - there are a million people peddaling all sorts of interesting security solutions. And there's a lot of snake-oil out there, too.

It's great to be at a company that actually has satisfied customers and a product that genuinely makes people smarter about their security - we're not perfect, but I'm sure that there are going to be products we see at RSA that don't actually make life easier for the security departments out there.

I'll blog more from RSA next week - I'm sure there's going to be lots of good, bad and ugly out there.

I just finished reading Michael Bauer's new post on the O'Reilly Network entitled "Fear and Loathing in Information Security". And I found myself shaking my head.

As long as I've been in information security, I've listened to people in the community complain about the misappropriation of the word "hacker" by the mainstream to mean "criminal". We tried to get them to call the criminals "crackers". We whined. We complained. We protested. We like the word and we wanted everyone else to like it too.

But it's 2005. And Mr. Bauer is just plain wrong.

To put it very simply: there are two very distinct understandings of the word "hacker". One of those is understood by our peers in the infosec and software community - it's a compliment about the way someone approaches ingenious problems. If someone in that community calls me a hacker, I take it as a compliment.

The other meaning of "hacker" is the one understood in the mainstream - my mom's (and probably your mom's) definition of the word. In that world, a hacker is a person who breaks into things. The public doesn't view "hacker" as a term implying skill - only a term implying a pest who breaks into their computers and steals their information. And, the people talked about in the speech he was quoting were exactly those types of peopele - we'd call them script kiddies or some equally derogatory term. And my mom (and probably your mom) would call them "hackers".

That isn't going to change. It's time to get over it.

We can feel free to use the word as we see fit amongst ourselves - it's jargon for our community. However, the rest of the world won't ever change to use the word that way.

And we can revel in that fact - we have a word that the rest of the world doesn't need to understand. It's something that means a different thing to our peers than to outsiders of our little club. It differentiates the person who got their CISSP as a checkbox on their resume and studied only from "CISSPs for Dummies" from the person who got it because they felt like reading the Rainbow series and academic papers on crypto and decided that it was a convenient reason to do so.

We also have to learn to use the word in appropriate senses at the appropriate time. Or when to use it and when not to.

Of course, Mr. Bauer doesn't need to address these issues - he's writing on the O'Reilly Network. They understand that meaning of the word.

One can be incredibly self-righteous when he knows that he's preaching to the choir.

For the perfect illustration of my last post, read the comment trail on Mr. Bauer's post.

Seems that there were some non-choir members in the audience after all. ;)

strolled around the vendor exhibits at rsa today. all i can say is, what a bunch of snake oil.

ZDNet today posted this article about the newly designed vulnerability scoring system that Qualys is announcing at RSA today. I found one line particularly interesting:

"[The system] is designed to provide the first systematic grading of flaws that can be used by companies to assess damage to their vulnerable systems and to prioritize patching.

Well, not quite the first. We've been doing that with nCircle's scoring system for over 5 years. With exactly the same criteria for evaluation. I imagine that they've made some changes - it'll be interesting to see what they've done and if they've run into some of the same flaws as our early versions. I'll post more on that once I've read the paper describing the metric.

I think that this is an excellent thing for the industry - there's no doubt that all of the products need to have a granular metric to assist their customers. Our customers see the benefits of the system on a daily basis - it's good that others in the industry are finally catching up to that view of the world.

It's one that we've had for 5 years now.

Our own Mike Murray gets quoted again, this time, its a new MyDoom worm. Putting the mechanics of the worm aside, how many times do we tell people "don't open attachments"? This worm and a few previous have preyed on the user's eagerness to open email from what they think is their friendly tech support team. The question of the day is "when are we going to make non-repudiation part of the norm?" Reading email is second nature, but obviously something about email lures us into assuming the From field is always accurate. Technology, like MTV, has tricked us. We buy P Diddy clothes at 10,000 times the markup and continue our failure to adopt non-repudiation into our every day lives.

NIAC presented their previously described new vulnerability scoring system at RSA today. I wasn't in the room myself, but have heard a couple of first-hand accounts so far - also, I had seen one of the earlier NIAC drafts.

The scoring system definitely has a couple of good points - they made the good choice of differentiating authenticated and un-authenticated vulnerabilities as well as the acknowledgement of different attack vectors as a key point of severity. They also made many of the same choices we made 5 years ago: being aware of the complexity of the attack as an important factor, being aware of depth of access as the fundamental component of risk, and so on.

However, I believe that they made a fundamental error when it comes to the temporal component of their metric: they forgot the audience. The temporal component of the new scoring system works to reduce the score from day #1 until day #n - that is, the vulnerability gets less severe as time marches forward.

This is true in a very global sense: as the enterprises patch vulnerabilities, they become less severe. Thus, the vulnerability (from a global perspective) becomes less wide-spread.

However, this metric isn't designed to talk about the global severity of the vulnerability - it's designed to assist end-users in their decisions on how to patch. Because of this, the thinking above is absolutely backwards.

While a vulnerability may be globally less severe with time because the number of instances grows fewer, the number of available tools and exploit vectors continues to grow (albeit at a slower rate) with each additional day that the vulnerability is publically accessible. This should be obvious to anyone who has ever done a penetration test: the brand new Solaris vulnerability is less likely to have an exploit than the 4-year old Solaris RPC vulnerability. I always loved it when I found a box that was unpatched to older exploits - it made my life easier.

Just like it makes the life of any attacker easier.

This metric (much as our scoring system) is designed to prioritize patching - as I see it, the vulnerabilities that make it easier for an attacker to compromise YOUR network are the ones that have the highest priority, regardless of their global significance.

That will always be the oldest, best known ones.

Because of that, the new CVSS (Common Vulnerability Scoring System) is doomed to fail to actually do what it's supposed to do best - allow customers to protect their networks from attackers.

On Tue, 8 Feb 2005, Dave Aitel wrote:

This is a quick announcement that the recent Microsoft patch (MS-05- has fixed a vulnerability I found a while back in SMB. [excerpted from http://lists.virus.org/dailydave-0502/msg00031.html]

Very convenient how these guys are like 'oh yeah we found that years ago but didn't do anything with it'. Seems to me they like holding on to their shit so they can talk themselves up and look cool, which isn't in keeping with an honourable way to carry one's self, if you ask me.

When I was younger I read, and subsequently became a huge fan of, Steven Levy's book 'Hackers'. I'm sure most people (of a hackish nature) are familar with the book and with the 'Hacker Ethic' that it takes care to promulgate. I thought it was a noble and beautiful creation. To wit, an excerpt from the the Hacker Ethic as listed in the book:

Access to computers -- and anything which might teach you something about how the world works -- should be unlimited and total. Always yield to the Hands-On Imperative! Hackers believe that essential lessons can be learned about the systems -- about the world -- from taking things apart, seeing how they work, and using this knowledge to create new and even more interesting things. They resent any person, physical barrier, or law that tries to keep them from doing this.... Rules which prevent you from taking matters like that into your own hands are too ridiculous to even consider abiding by.... All information should be free. [From Hackers: Heroes of the Computer Revolution by Stephen Levy. Anchor Press / Doubleday. New York, 1984.]

I recognize the need for trade secrets, and that the quality of our life is dependent on the ability to do business and aquire commodities that address our needs as human beings. But there has to be a middle ground and an honourable way to do it. I am aware of the hypocrisy in my own life; I don't live up to the hacker ethic all the time either.

Maybe he didn't want to share the information 'cos he had concerns someone would take it and claim it was theirs. So what? Let it all hang out man - karma will take care of the rest.

I spent a day this last weekend tending to some 30 year old bonsai trees that my father has raised from saplings -- two pines in hand-made oak planters. Long ago, one of these tenacious little trees was rescued from a curbside trash-heap. We invited a friend, a smiling master of bonsai, to help us take a fresh look at these old family friends.

The fundamental drive behind bonsai gardening, as far as I am able to discern, is the impulse towards natural intention. To introduce the human view of nature on nature itself, with all its symmetry and asymmetry, towards some idealized form -- the streamlined version of the ideal tree. In fact, the more the scale of a real tree is reflected in the little tree, the closer the bonsai approaches perfection. The individual tree is what "can be" in nature. It strives towards clear lines, simplicity, a natural looking stance. To reflect back nature's aesthetic palette on something guided by the human hand, one requires experience and clear observations of real phenomena -- you have to have seen lots of real trees. What form can it take? How does it grow? One must understand the organic process of a tree. In this case, the imitation found in bonsai is a form of appreciation and a path to learning about nature's forms in depth.

To strive for this objective, constraints must be put on the bonsai to guide the avenues of growth. The size of the container will determine how much soil the tree has and how far it's roots can grow. Copper wires can shape the growth of limbs. Pruning can further guide growth in the right direction and eliminate that which falls outside of the aesthetic goal or acceptable ranges of shape. It is a continuous process to grow and maintain. A branch that becomes too brittle or obscures another branch might be first to be trimmed.

One thing I learned was that the tree gets most of its nutrients from the little roots, so when you are pruning the root base, it is better to trim the thicker roots. In fact, if you cut off too many of those little roots, the tree will die.

For those not into metaphor, the security of a network grows organically, so it requires the same level of natural intention: organized growth (architecture), the pro-active constraints of a container and limb wiring (policy and discovery), watering and pruning (maintenance and remediation). But the primary point here, I think, is that security is a process continuously aimed at applying an ideal state to an unfolding organism, channeling it continuously. "Becoming secure" is a process that is never complete, because the organism is ever-changing.

so, about maybe 2 months ago, one of my teeth become incredibly sensitive to hot and cold. it was awful. i'd grab a cold bottle of water, take a big drink of it and then i'd feel like someone was drilling into my jaw. horrible.

over the course of the last two months, it went from hot/cold sensitivity, to occasional pain, to pain whenever i touched it with my tongue, to just plain constant pain. so i had to call the dentist yesterday morning, have them take a look. because, as you probably know, mouth pain sucks.

it was my upper right side wisdom tooth. both of my wisdom teeth on the left side were removed in the early 90's by an oral surgery student at the university of the pacific dental school. it cost me only $400 for 2 local-only extractions. lots of cracking and bleeding later, i was less two painfully impacted molars. i never did get around to having the others removed. that is, until yesterday.

lucky for me, the dentist could see me immediately. when i got there they took some x-rays using some new tech i'd never seen before. it was a usb x-ray thing they stuck in my mouth which made me gag. x-rays always make me gag, but this one took the cake. good for me it was fast.

turns out the dentist also does rudimentary extractions right there in his office, and after seeing the x-rays, decided he could do it himself. so, much cracking and pinching later, my problematic wisdom tooth was out.

so what was causing all that pain? that particular tooth, on the side facing the tooth in front of it, had a giant cavity in it. a cavity so big it went down to the inside of the tooth. it was frightening. it was filled with unidentifiable organic matter. it was disgusting. glad it's gone.

so what, you ask, does this have to do with security? well, i'll tell you...

just because you can't see it from the outside, or can't get to it, doesn't mean it can't hurt you. badly. patch your boxes. no matter where they are. otherwise, you are going to be in a world of hurt when someone manages to stuff a couple hundred kbytes of kernel rootkit into that cavity and then twists it around a few hundred times. heh.

The T-Mobile insecurity saga continues to unfold in the press, shocking and entertaining everyone, especially if you are one of Paris Hilton's friends. "Why does this always happen to me?" Ironically, sales are up on Sidekicks. I find it interesting that the exploit used in the T-Mobile hack was an ancient BEA Weblogic vulnerability. Perhaps, like Qualys and the soon-to-be-minted CVSS, they thought that the risk of this vulnerability was going down over time. This is a perfect example of why a vulnerability instance should not be conflated with the global rate of its exploit. On the contrary, there are crackers using automated scans for old vulnerabilities, because it makes their lives of hacking your company that much easier. [Of course, I grant that the much feared, automated zero-day exploit is much worse, but that is the origami unicorn of this tale.]

This week I have been thinking about inside-out attacks, a lot. We haven't exactly figured out how to solve the problem so clearly displayed in Homer's Iliad -- the Greeks hacking the Trojans. Everybody knows the inside is not like the outside. How many licks does it take to get to the center of a Tootsie Pop? We are reminded: never invite the vampire into your house. For the corporate enterprise the "inside job" is the most feared, right? And of course, egress filtering is given a fraction of the consideration of ingress. "Things fall apart; the centre cannot hold." The problem, as Ripley found out in Alien, is a nasty one.

There seems to be a sharp rise in mass, personal-information exposures, all of which are caused by poor vulnerability management. The ChoicePoint debacle is the most egregious, I would say. Doesn't every computer-owning soul have some data they really don't want to share? But what if you don't install your Windows updates? Maybe the network system you store your data on doesn't do proactive vulnerability management. Well, it's all becoming fair game, folks (especially if you are browsing with Internet Explorer!).

On a mundane level, there are things like this going on more and more all of the time. For example, accidentally having your private personal or corporate data snatched up by Google. Maybe your mom will be stung by the latest Active X, bogus-bank, phishing attack, or perhaps a friend managed to share his personal Quicken files when he misconfigured Kazaa. I saw a digital photo gallery put together by a guy who searched Gnutella and Kazaa for known digital photo file extensions to find photos that were shared unintentionally.

Now, I wonder, when will the first mass-embarrassment worm happen? It is only a matter of time before an e-mail virus will advertise the naked starlet-of-the-day to induce me to click on an attachment. But, instead of it being a ruse, it will actually contain never-before-seen naked pictures of her -- ripped, untimely from the private cache of her personal life. How's that for reality tv?

This is already happening, of course, here and there, but it seems to me that the logical next step is an automated, anonymous method, one that is coming some time soon. And what's worse is that, because it will be automated, not just Paris Hilton will be affected.

Flash back to 1999: the Melissa macro virus. If the names of big-time viruses have blended in your mind, like they have for me, I forgive you. Melissa was a virus that infected Microsoft Office document templates, which in turn would infect most Word documents and then send them out to the first 50 people in a person's Outlook address book as soon as one infecte document is opened. To the chagrin of many companies and government agencies, lots of private documents got sent out all over the place.

What happens when we start getting personal information from our friends, relatives, and business associates due to the whim of a highly evolved, discordian worm? Do you want the video of you playing with your light saber on the internet? Sent to your boss? Danger lurks when inside-out attacks meet personal information.

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

How do you develop a safer web browser?

1. stay on top of newly discovered vulnerabilities
2. maintain an open disclosure policy and well organized bug tracking system
3. notify end users of updates
4. make updates transparent and painless

Mozilla Firefox fails on step 4.

Vulnerable users are more likely to update their software when the process is automated and easy. Every complicated dialogue box that you present a user reduces the likelihood that they will complete the update.

Internet Explorer can be updated (cumulatively no less) in an average download of 600K and usually one reboot. In contrast Firefox displays a helpful little red arrow in the corner of your browser window until you update. Once the user clicks on this subtle little icon, they begin the long process of downloading the update. Once that step completes they are greeted with the fact they downloaded a whole new copy of their browser and now have to reinstall the whole thing. This gets a little tricky on multi-user systems, not to mention the novice users whole get freaked out when presented with file system install paths. As a final little insult, Firefox leaves its installation executable lying on your desktop.

Firefox's awkward update process is going to leave a large number of people running vulnerable copies of Firefox 1.0

Mozilla should reward its loyal fan base with an upgrade procedure they can brag about instead of having to make excuses for. The Mozilla development team places an admirable amount of effort on security, now they just need to start delivering it to the people they are trying to protect.

Earlier this week, I went back to my alma mater to give a talk about buffer overflows. Michigan Tech is a unique school located in an abandoned mining town called Houghton in the otherwise untouched wilderness of Michigan's upper peninsula. The nearest city is Minneapolis -- an unreasonable 7 hour 41 minute drive away. The rest is nothing but small towns, abandoned mines, and snow.. lots of snow.. With 300 - 400 inches of snow a year, some days it felt like planet Hoth. At the Minneapolis airport, I recalled the isolation of the region while boarding a 30 seat propeller plane -- the only way to fly into the tiny airport near Houghton.

I was picked up from the airport by a senior who also knew first hand about the region's harsh climate. "Why the hell did you come back here?", he joked with me. While the solitude of the back country does have its certain charm, I distinctly remembered just wanting to get the hell out of there by the time I was a senior. Why the hell did I come back here?

Well, there is some history that makes this too funny to pass up. Eight years ago, when I was a sophomore I used to play around with the world-writable utmps and mess with people using flawed Xauth implementations. Soon one of the lab admins challenged me to get root on the main CS file server. It was easy to find a publicly known buffer overflow vulnerability in one of the many suidroot binaries on that system. After figuring out the proper offsets, I show the exploit to the lab admin. "Holy shit!", he exclaimed at the sight of the root shell prompt. "That's a big problem", he continued, "Someone should fix it." I agreed with him, so I e-mailed the necessary patches to the system admin along with an explanation of how I got root -- only to get my account shutdown the next day for violating the school's computer use policy. The lab admin who challenged me was only a student and the policy is the policy. I was threatened with expulsion and put on probation. The administration made it clear that if anything else happened, I would be out of there. I focused on my course work, did what they told me, and got my degree in the end. There were some good teachers there and I did feel a strange connection with this odd college in the middle of nowhere. But yeah.. a big reason was just the irony of giving a talk about buffer overflows at the same school I was reprimanded for the exact same issue.

it seems that in recent years, nay, the last decade, there has been a tendency for vulnerabilities and policy violations to be lumped together. is having an insecure password, running non-encrypted services such as telnet, or writeable directories via ftpd more of a vulnerability than a violation of policy, or of bad policy?

all of these things, while able to be potentially leveraged to compromise a system, can easily be addressed by applying best practices. wouldn't it be better to call these types of scenarios out in the policy arena?

comments, thoughts, etc.

Kurt Godel, a logician, mathematician and philosopher of mathematics had many interesting things to say. For the purposes of this discussion I am going to restrict myself to one particular theorem of his. This theorem is his second incompleteness theorem which states:

No consistent system can be used to prove its own consistency.

It is important to note that the theorem truly and properly applies only to the field of mathematics. I am, however, going to abuse this notion because I think within it is a held a truth much larger than originally intended. Like Heisenberg's uncertainty principle (and alot of quantum physics) there are, to me, profound philosophic insights. Loosely and sanely applied I think they may have use outside of their original fields.

There has been alot of talk lately about vulnerabilities and security. To me the central point made is that problems still exist which have existed for a very long time. The evolution of human capability and thought should have long ago eliminated these problems.

I am not sure that is the case, nor am I certain that it is possible or even desireable.

If we look at the human body we can see an entity that is very imperfect. But this remarkable imperfection is capable of the greatest acts and accomplishments. We damage ourselves all the time, yet we heal. Despite the impurities we consume or the cuts and scrapes we receive we heal, often becoming stronger and wiser. Organic life is the ultimate fault tolerant system. We are the greatest RAID system ever implemented.

How much effort must we divert to try and make things perfect? At some point we will be putting in far more effort than is worth the results we achieve. We will become too focused on fixing problems before they happen, reducing the resources available to remediating the situation. I would say we are approaching that point now. Would it not be better to accept the inherent imperfection of the universe and instead strive to make our environment and our tools fault tolerant? As long as humans create machines the machines will be imperfect - and so will their products. Our software will be imperfect. As history bears out countless times, our security will be imperfect. This is all as it should be. In fact, I suspect this is the only way it can be.

I am not saying that we should abandon attempts to be secure. What I am saying is that we will never be secure - there is no way for us to prove that we are. You are most vulnerable when you think you are most secure. Just because you have a product, a system, or a methodology and it appears to provide accurate results consistent with your perception of a secure state does not mean that state is useful. Or accurate. To paraphrase the second incompleteness theorem, your secure systems cannot prove their own security. And in much the same vein, I am not sure that a system of accuracy can prove that it itself is accurate. The problem may very well prove intractable.

We cannot eliminate our true weaknesses, only manage them. Much like vulnerabilities.

In January of this year, nCircle hired a pair of co-op students, something we had never done before. Our experience was so positive that we were motivated to expand the program very aggressively; this semester, we will be hiring eight students altogether. Four of these students will be reporting directly to me, which means that my own private department has suddenly expanded into a regiment. Some ignoble wag dubbed it the "Army of Gauth"; naturally, the name has stuck.

As Technical Librarian, I was an information ronin, a (nearly) masterless samurai of sentences, with little more oversight than the occasional foam dart over the cubicle wall. I was permitted to wander my domain of responsibility without let or hindrance. But now I am a conscript commander, tugging at the unfamiliar collar of authority's mantle, and the duties of my new commission included recruitment.

That meant interviews. Lots of interviews.

Okay, so I admit it - I'm a total gadget whore.

I saw the preview of the new Palm "Lifedrive", and I'm in absolute technology love. But what got me thinking was the following marketing picture:

With 4GB of storage, anybody with one of these can very easily carry the entire contents of their desktop around with them. I know that my first thought was: "cool, I can do all of my work without pulling out my laptop".

Of course, that means all my work must be there. And I note that the marketing above doesn't say anything about file encryption.

This gets me wondering - as we face a more complete set of mobility, does security become even harder? These are the same questions that we asked when laptops came around, and laptop encryption has been slow on the uptake, for sure. (Although, I must say, Mac has made it really easy - FileVault rocks)

A laptop is a whole lot harder to misplace than a PDA. And a whole lot harder to steal.

As a gadget geek, this is damn cool. As a security guy, this makes me damn nervous. Where's the optimization point between those two?

Two recent events have got me thinking about encryption. First, SHA-1 was broken. Second, the 40th Anniversary of Moore's Law passed. When you put these two things together, it reminds you that encryption isn't static. Algorithms still get broken, still have problems. As computing systems get faster (and they certainly do), brute force attacks on encryption become faster as well.

At one point, not too long ago, it took days to crack a WEP key. This month, these FBI agents accomplished the task on a 128 bit WEP key in 3 minutes. The point here is that these attack vectors on encryption algorithms won't go away, ever. Systems for encrypting data have expiration dates. They may not be fixed dates and they may not be known dates, but they're out there somewhere.

Which brings us around to system design and architecture. If you design a system that relies on a particular encryption method, you better also consider how you're going to upgrade when that expiration date suddenly appears.

So, I'm not big on jumping on the FUD bandwagon around phishing and social engineering: it seems to me that enough people are writing about them these days that nobody really needs me weighing in on it. However, when I read about Winn Schwartau getting hit at home, I decided I had to post.

First, because it's certainly an interesting "anatomy of a scam" sort of post. And, second, because I think Winn rocks, and I really enjoy his writing style.

Definitely worth a read.

Anybody who knows me at all knows how many books I read. When I read Ross Mayfield's description of his recent airline screening where he was told you could only have 2 books on a plane at a time, I realized how much trouble I was in....

I carry at least two books with me on a normal day... on any flight of moderate (2-3 hours) length, I'm usually carrying 4 or 5.

That's not cool. Just out of curiosity, how could too many books pose a security threat? Any ideas?

I was reading Catspaw's blog today, and she was talking about how they take notes in class - pretty damn cool. Back in the day (8 years ago) when I went to school, we didn't have these new-fangled devices like laptops. Actually, I had a 486 laptop for a while, but vi doesn't exactly equate.

And she turned me on to this new tool: SubEthaEdit.

I'll let her describe the scene:

If you're standing in the front of a classroom, you're likely to notice that the Mac users are all doing the one-mind borgish thing. They all grin, then they all type, then they all listen. Chances are very high that they're all using SubEthaEdit to collaboratively take notes. One student types in the main content of what is being said. Another follows behind and corrects spelling mistakes while a third adds a few extra points. Perhaps another is ahead of the rest, creating structure for the rest of the document -- preparing HTML lists and section headings. Collaborative note taking doesn't just happen in the classroom. It's become a new fad for everything from conferences to meeting minutes to collaborative email composition and more.

Man, I wish we could have done that when I was in school. I may have actually gone to class in that case.

This got me thinking about the pair-writing that Johanna and Esther did last year. This is incredibly cool stuff - collaborative writing.

It also got me thinking that it would be REALLY cool to do over bluetooth - that's the next killer app in my opinion: sitting in a room, collaborating on a document via Bluetooth.

SubEthaEdit is now my default text editor on my Mac. Now, if only I can get someone to do some collaborative blogging with me.

So, as much as I like the Mac, I've come to realize and accept that I'm simply unable to continue my Mac life. I'll continue to be an evangelist for their design, but the fact is, some things simply don't work as well as they do on Windows.

The final straw was my Palm and Entourage - I live and die by the synchronization of those two items. (It's all David Allen's fault) Lately, each time I sync my Palm, the Entourage Palm conduit crashes. So, I only have 1/2 of my items. And none of my tasks. Fatal, I'm telling you - it raises my anxiety level by at least 10%, because I no longer trust any of my systems.

So, I'm going back to Windows. It's a somewhat sad day - I'm back to a far cooler looking laptop (though I like the Thinkpad). But I'll be more productive, which will let me sleep better at night.

Sometimes it is extremely fascinating where you can find strange parallels between two books that look like they should have no correlation with each other whatsoever.

One of my favourite books I read last year, being the mathematician that I am, is "Fooled By Randomness: The Hidden Role of Chance in Life and the Markets" by Nassim Nicholas Taleb. The book is about the role of chance and randomness in life (with a strong focus on the stock market itself). Essentially, the book theorizes that most successful/famous people in the stock market have made their money based on the luck of the draw and that the only real way to be successful when playing the markets is to control risk. (i.e Don't put all your eggs in one basket and don't risk more than you can afford to lose at one time). Taleb really focuses on the idea of the "Black Swan," which can be defined as an "outlier", or an event that one does not expect or has not planned for. These can be both good or bad. Winning the lottery or getting hit by lightning can be considered a "Black Swan." You will be successful if you can survive any "Black Swan" situation in the markets and possibly profit from them.

On mmurray's recommendation, I have just about finished the book "Blink" by Malcolm Gladwell. The book is essentially about the subconscious and its power in our daily lives. The beginning of the book focuses on the uncanny ability to lead us toward a solution before we are even conscious of the fact that we are making them.

At first glance, there doesn't seem to be a real correlation between them. In a stretch, you can consider them both to be business books. Fooled By Randomness with the focus on the stock market and Blink with the focus on the subconscious making quick decisions (e.g. First impressions when conducting an interview).

One of the examples given in Blink was an experiment conducted by the University of Iowa where the testers asked individuals to select cards from decks that differed in colour. If someone drew from one of the decks, they would either win or lose the amount on the card. Without giving too much away, one of the decks that an individual could choose from paid off handsomely, but was also very risky. One could not win by just picking cards from that deck. The other deck was more conservative. One would not win as much as choosing from the other deck, but one would lose even less. The conclusion was that the people taking the experiment could figure that one deck was safer than the other eventually. However, they would be able to determine this subconsciously way before they consciously knew it and would be drawn to the safer deck.

I thought about being "Fooled By Randomness" right after reading this section of "Blink". Taleb talks about how humans often see patterns in things (or believe they understand how things work) that are completely random. Taking the card example that is used in the Iowa Experiment (not exactly the same, they weren't drawing from a standard deck of cards, but using it as an example), if one is drawing from a deck of cards and get 12 red cards in a row, there is a strong chance that the next card will be black. However, even though the odds of getting a black card is much higher than getting a red one, you will be pushed into towards guessing that the next card is red. Even though you know it's a standard deck and logic will dictate that you should pick black, you'll stop for a second. What if this deck is different???
The same is true with flipping a coin. If you are able to flip heads 20 times in row, what are the odds of the next coin flip being heads? (As a note: The odds of anyone flipping heads 20 times in a row is ~1/1000000, or (1/2)^20).

As a math guy, this is messed. My background is numbers and logic. One source is telling you that your subconscious can lead you toward the right conclusion without you even knowing it. Another source is telling you that your subconscious can lie or lead you in the wrong direction depending on the input. (To be fair, Blink does talk about this in later chapters). So, in the end, I conclude this from both books. Trust your instincts, but only when they are not wrong. :)
But when is that? How do I ever know that my subconscious is not leading me in one direction based on a pattern that doesn't really exist?

CanSec West -- Arriving in Vancouver

The trip up to CanSec was a breeze. We vaulted into the sky over the shimmering waters of the Bay, as I wondered if I had remembered to install arpwatch on my system. Descending into Vancouver, I saw the white mountains rising in the east and the blue islands lingering in the west, surrounded by oceanic haze. The airport in Vancouver greeted me with a primeval diorama: native totems with bird-like sound effects, an ancient wooden canoe, a waterfall. The cab ride downtown was brisk, sped by my attempts to ply my Punjabi-Canadian cabbie for information about the location of good Indian restaurants. According to him, they are all good when they are not too busy. So, I guess look for restaurants with very few people in them. Sounds a bit off. I got situated in the hotel and met up with Paul Miseiko for dinner downtown. After that, I managed to hook up with some friends in the Gaslight area for drinks. They were involved in a furious game of speed-pub-hopping and I pulled the ejector seat and headed back to the hotel.

After an "All Canadian Breakfast" at the hotel, Paul and I headed over for registration, which is delayed due to unspecified issues. There are close to a hundred people sitting and standing around, waiting to register.

I remember as a kid getting my first pocket knife. My Dad told me, "this is a tool. Take it out when you intend to use it." The implication was that I would get myself in trouble if I didn't take this advice seriously. Well, I definitely got myself in trouble with that first pocket knife and learned that lesson the hard way -- a casually wielded tool will go astray.

As I sit waiting for the convention to start, I reflect on this. On the wild-west wireless of CanSec, I sort of feel like my laptop is a pocket knife.

I just finished registering and what do you know! Each registered person received a black, CanSec t-shirt and, you guessed it, a pocket knife!

Once the presentations started rolling around 1:30 they didn't stop till about 8:30 PM. Just got back to the hotel, and here are some notes and thoughts on the presentations:

Cedric Blancher's presentation detailed the appalling state of security surrounding mobile workstations. The primary gist is that highly insecure systems are allowed free reign within otherwise highly controlled networks, by the fact that the systems are roaming laptops or uncontrolled home systems. An interesting thing he pointed out was that many systems that have local firewalls, for instance, consider traffic by zones, like internet and local, so that local network traffic easily subverts any firewall restrictions.

Maximillian Dornseif's presentation on exploiting Firewire's bus system to read and write arbitrary system memory might have been the best of the day. Using a few python programs, he showed how you could read from memory and show screen captures or blank out a screen. He demonstrated a program to brute force rewrite instances of GUIDs in system memory to 0 to escalate root privileges of a non-root user (this demo didn't work for the presentation, unfortunately, but he said it normally does). This roughshod method tends to crash a lot of stuff, so he said he often had to reboot with the firewire cable unplugged to get things running again. He also demonstrated via a short video clip an iPod running Linux as it blanked out the screen of a connected computer. A useful example of this type would be for killing password locking screen savers to get immediate access to a system. Apparently, some vendors have already begun quietly patching for this.

[More to come on Day 1]

I woke up around 6am for an early morning and got some work done prior to the CanSec West registration (which started around 9am). The registration procedure had some technical difficulties which halted the process for a little over an hour. After successfully registering I walked towards a glass wall and stared at a piano located on the floor beneath me while contemplating a few melodies.

The first presentation, "Mobile Workstations, mitigating the crawling trojans" presented by Cedric Blancher, was about to begin. I must admit the name sparked more curiosity and excitement then the presentation itself. The "Mobile Workstation" was essentially a laptop, as expected, and the "crawling trojans" simply meant the ever changing insecure network environment the laptop is subject too. Much like in "Independence Day" the Alien skiff kept at Area 51, piloted by... monkeys, invades the perimeter defence of the Alien mother ship undetected while carrying a deadly payload. The mother ship is damaged severely because the Alien's did not anticipate the skiff to be infected by... monkeys. So the morale of the story is not to treat a "Mobile Workstation" as if it were a trusted device (such as an office workstation) because you can not control it, only the monkeys do.

The second presentation, "0wn3d by an iPod: Firewire/1394 Issues" presented by Maximillian Dornseif, was easily my favourite. First introducing the history and some technical data of Firewire/1394, I mean FireWire/1394, I mean iLink... Mr. Dornseif then explained the potential to read and/or write to any physical memory address on a system through the Firewire port without authentication. I must admit I was sceptical at first as it seemed highly illogical that such capabilities would be so easily granted. My scepticism was quickly put to shame as Mr. Dornseif provided us with a demo. Two computers were first linked together using the Firewire port and then the video memory of one computer was read and modify by the other. Someone, somewhere, must be saying "Oops" right about now.

The third presentation, "0wn3d by everything else: USB/PCMCIA Issues" presented by "David Maynor", was particularly boring. At first the issue appeared to be the potential exploitation of device drivers, then DMA, then USB, then firmware, or hiding code in FPGA's that some video cards apparently use... FPGA's used by a consumer video card? Maybe if I was not an avid IDA user I would have enjoyed the IDA screenshots. The lack of consistency left me logging into my IRC client and talking with a few friends about... lack of consistency. I felt like the sky is falling... only it is not falling... but we can pretend it is.

The fourth presentation, "Everything is Vulnerable" presented by Brian Martin & Jake Kouns, started off well. They talked about known issues with vulnerability databases that have annoyed me and my fellow coworkers since the first day we started using them. A fine example entailed a vulnerability database claiming version "1.0" and "2.0" are vulnerable... but what about "0.9"? or "2.2"? The vulnerability is not thoroughly tested (if tested at all) and therefore should only be taken as a partial answer and not a final answer. Of course all the troubles of using a vulnerability database to determine the vulnerable instances of an application can be solved by simply checking for the existence of the vulnerability directly rather then writing peripheral version check. It was also pointed out that vulnerability databases have a tendency never to revisit and update past vulnerabilities. Therefore a vulnerability that claims to have no solution, according to the vulnerability database, may in fact have a solution.

The last presentation I am going to comment on was the sixth presentation, “ICMP Attacks” presented by Fernando Gont. The talk emphasised 3 ICMP attack methods against TCP sessions that can reduce TCP session throughput, increase TCP session latency, and reset a TCP session. Four vectors are required to perform each attack: The Source and Destination IP address, and the Source and Destination TCP port associated with the TCP stream being targeted. If you know your target Source and Destination IP address, and the Destination TCP port, the only vector you need to brute force is the Source TCP port. Therefore the brute force space is only 65536 possibilities. This brute force space can be reduced when considering deterministic port ranges assigned to Source TCP ports by most Operating Systems.

The presentation “Binary Difference Analysis”, presented by Halvar Flake, talked about three key elements of binary analysis: Comparing executable objects, porting information between executable objects, and navigating executable objects.

The tool known as “BinDiff” interfaces with IDA (Interactive Disassembler) and provides the capability to compare two executable objects and provide a set of code logic differences (not physical differences). This technique would be useful (and was designed for) finding undisclosed bugs in patched software when both vulnerable and non-vulnerable executables are available. We use this technique often during Microsoft Tuesday to write rules that directly detect the existence of the patch in a non-invasive manner.

Based on the analysis of the two executable objects “BinDiff” is also capable of porting code comments, variable names, and function names between two executable objects based on code segments that are logically similar (not physically similar). This technique would be useful when you have fully documented and reverse engineered an application that is later patched, or a new version is released, modifying the originally documented executable. To complete the documentation process of the new executable you can use the previously described feature to find any differences in code logic and document them accordingly.

Navigating executable objects with “BinNavi” was very impressive. The application would associate itself with an active process of the executable object you wish to navigate and permit one to take snapshots of the functions called between two points in time. This greatly simplifies the process of determining how to execute certain segments of code (such as the vulnerable segment that was determined when detecting the difference between a vulnerable and non-vulnerable executable). This should also simplify the process of reverse engineering proprietary protocols by permitting one the ability to easily determine how an executable interprets the data it receives. The graphing present in “BinNavi” was amazing from both a usability perspective, narrowing down the amount of information to only important aspects of the graph based on function call analysis, and an eye candy perspective with graph rotations, fitting data onto a single screen (the ball of yarn), and providing graphs similar to “BinDiff”.

Marty Roesch -- Target Based IDS and Snort Roadmap

Marty's presentation was primarily on the next generation of Snort and, more widely, what he thinks needs to happen with IDS in general. Interestingly, he mentioned target-based IDS. I am sure Jon Flowers would have found some interesting comment on this presentation, like "it all comes around doesn't it." Anyhow, I digress. One of the key points is that future IDS requires automated tuning. He said, "We need to take into account endpoints on the network." Events become more suited to meaningful analysis with target and network context. [I am paraphrasing here and there to give the main ideas of his talk]. For example, he said, an IDS needs to know the path mtu, ttl, and the target context. OS can help us understand how to handles fragmentation and packet overlaps, since these can vary by OS. One core problem is if fragment overlaps are processed differently by the IPS/IDS than the end host. He talked a little bit about TCP Stream processing and broke thing into 2 primary groups the "BSD" way and the "Solaris" way. Here is a good quote from one of his slides: "In order to model the target environment accurately, the IDS needs more information about the network and about the target." Not surprisingly, he supports passive methods of getting host awareness, primarily, but thinks active should fill in the blanks (which he debatably referred to as the remaining 10%).

He talked extensively about future Snort features. The DAQ (Data Acquisition) subsystem is currently hard coded to use libpcap, and there are several pcap-isms throughout Snort. IPQ with pcap is a pain. So, basically a new decoder is needed. The fragmentation handling system (Frag III) is in CVS. Endpoint awareness is really about packet reassembly equivalent to that of the endpoint. Snort also needs a smarter stream reassembly. The overhaul of stream processing (Stream 5) is currently in prototype mode and it does target based processing. Additionally, external systems can tell it how to do stream re-assembly. Currently, Snort rules organized around ports. There will soon be a Snort Command Language (API) for informing Snort about target hosts. "SCL" Organizing things by discoverable attributes. The shift is toward grouping signatures by "Micropolicies" which allow you to reference attributes to a specific flow.

He said, "The more information I have about the network the more accurate it gets." There are quite a few Attribute-based Config Advantages (e.g. Automated tuning and Anti-evasion). A question from the audience was about correlating vulnerabilities to the mini-policies. And he basically said, the taxonomy of relating vulnerability data directly is too difficult. Back end correlation is better than inline tuning based on vulnerability. But he also said that you need realtime discovery to make this all work. Also, he mentioned that Snort rules language 2.0 is coming along. He then provided a demo of the API for providing Snort with host context data and a cool decode plugins to make it better for packet viewing (tethereal style).

Barnaby Jack -- Kernel Exploits in Windows

Barnaby's Jacks presentation went really fast and is hard to put into words, since it was mostly demonstration. He basically wanted to show what all you could do with kernel based exploits on Windows. He used the Symantec Firewall vulnerability, which I think he actually found, originally. The key idea for Ring 0 (kernel) exploits is to get a "clean" return. He said,
"'Clean' returns is a technique used to return out of an executing payload, and continue without disrupting the current thread or process." He then demonstrated various ways to use the exploitable kernel vulnerability. For example, to do key logging by modifying TCPIP.SYS and by patching the echo handler. His final demo was to force the vulnerable windows system from kernel to real mode and run an old-school, real mode display.