In my role as CTO for nCircle, I spend a lot of time at tradeshows. I always make time to visit the vendor booths. Sometimes I am greeted with friendly faces and other times they don't want to interact with me either because I am not a potential customer or because they view me as a competitor. No biggy. An observation that I have made recently is that our security market is so primitive when it comes to articulating the value proposition that it falls back to an 'appeal to emotions' technique that can be classified in 5 categories. These are just traditional categories of human reasoning. It is important to know what technique is in play so that your parser can quickly qualify in or more likely, qualify out the noise. :-) They are as follows:

Appeal to Tradition: This is the claim that appeals to the status quo. It is the assertion that the idea or solution is 'good' because it is traditional, comfortable, or the way that things have always been done. The reality of this tactic is that even if it is not logical, old ideas, old beliefs, and old policies are not intimidating and 'comfortable' to people.
Example: "We have been doing it this way for 20 years, and we don't fix what isn’t broken."

Appeal to Fear: The is the grand daddy of all security vendors and security professionals that just can't help themselves. The appeal to fear is the notion that if some course of action is not pursued, terrible consequences will occur. This is your traditional 'scare tactics'. Yawn.
Example: "If you don't buy my product, your information systems will be compromised and you will be left homeless and live a life of suffering."

Appeal to Force: The appeal to force is simply the assertion that you should do what we say or what we believe, if you do not, we will do something unpleasant to you. This may seem like the same as the appeal to fear but it is a more specialized case since the negative consequence is a direct or indirect threat by the person or organization making the claim to the audience.
Example: "If the private industry does not get their act together on security, they will not be able to join our organization" or "People not compliant with X will not be allowed in to our organization"

Ad Misseracordium (appeal to pity): This is exactly what it appears to be: the assertion that somebody should do something out of a sense of pity or compassion. So what? It is often abused when a vendor or sales person is trying to make a case by using emotional images or rhetoric to support their argument and is targeting pity for their cause. I'm going to spare you the example on this one.

Appeal to Popularity (bandwagoning): It is the assertion that ou should believe something or do something because everybody else believes it or does it. In some text books it is called "Ad populum". The fact is that in a highly dynamic, not well understood fields (ie Information Security), the predator will prey on the victims deep insecurities and get them to see emotional security in doing and thinking like everyone else.
Example: "No one gets fired for buying IBM"

Everyone is guilty of these charges to some degree. Being the person that I am, I like to see them in neat little boxes with labels. Fallacies suck. I'm a reasonable person so present your information in a way that I can use my own reasoning and if we are lucky, we may even have a good debate with both of us learning a thing or two. :-)

I now return you to your regularly scheduled programming.

-- Tim "TK" Keanini

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.

I must admit, I'm a big fan of Halley's blog. Her recent post invoked a question that I've been asking a lot about the security industry of late:

If you're searching for data -- are the results true, valid, credible? ... Will we pay a premium in the future for clean, pristine data?"

This is a key issue in the vulnerability management space. I dare say that it's the key issue - how good is your data? Can you trust it to make decisions on?

We often talk about the "may be" vulnerability reports that a lot of our competitors use - I think that's the ultimate example of bad, un-credible data. These are the vulnerabilities that report:

"You may be vulnerable to this condition".

Obviously, these come from the old days of vulnerability assessment, where the administrator was scanning a box or two, and knew exactly what they were scanning (or could know at a moment's notice through logging in to the box). However, now that vulnerability management tools scan thousands or hundreds of thousands of devices, it's really hard to deal with these "may be vulnerable" issues.

Some look at this as a "geek" level issue, but I think that's missing the point. With security issues being driven to the top of the organization by regulations such as Sarbanes-Oxley, HIPPA and GLBA, we're seeing an increased importance on the results of security tools. And these regulations don't accept the answer "Maybe."

To me, that lack of integrity is what will kill this market in the long term. Either that, or, as Halley suggests, we'll see customers begin to demand the type of integrity of data that they can make sound decisions on.

Sometimes it's difficult to blog on what I do for a living.

That last entry came out sounding a bit like marketese, but it wasn't meant to be. The crappy data that this industry churns out really pisses me off. It's bad when it comes to our customers, but it's REALLY bad when it comes to what we do.

One of my team noted it on Friday night while we were having a drink or two:

"Mike, you just seem so... uh... agitated sometimes.

You know what? I AM agitated.

I'm agitated whenever I see a false positive. I'm agitated when I see us fail to report on something that we should.

And I'm especially agitated for this entire industry, because I know that we do it better than anybody else out there. I can't imagine running my business on some of the crappy data that is out there:

"Your 500,000 hosts may be vulnerable". Gee, thanks, Sherlock... I knew THAT before I bought your vulnerability management tool.

Our product (IP360) is far from perfect, but I'd at least trust the results to make a huge number of decisions on. And it gets better every day - we put a lot of effort into making a damn good product.

We don't do the whole "maybe" vulnerability thing - I don't think I could look myself in the mirror in the morning if we did.

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?

Today I took a few members of the Toronto team west to Kitchener, to attend the Security of Quality conference, put on by the ASQ.

It was an opportunity to sit in a room full of people who have solved real quality problems, unlike our industry. The IT industry in general, and IT security specifically are still such new industries that quality isn't exactly expected - customers accept crashes from Microsoft on a daily basis like they're normal. These are the same customers who will freak out and take their car to a mechanic the moment that they hear a funny noise.

What's more interesting is that the entire industry pretends that nothing's really happening - everybody talks like the quality problem in IT security is already solved. Especially in the vulnerability management industry: everyone claims "the best coverage!!!" and "NO FALSE POSTIVES!!!".

Let me be the first to say it: the emperor has no clothes on.

Quality is taboo in this industry because everybody knows that we haven't solved all the problems yet. Our competitors solve the problem by BUILDING IN quality problems:

Got a false-positive? Call it a "Potential" vulnerability and let the customer figure it out.

It's pathetic, really. Gauth calls it "lying". I call it "an extreme lack of integrity".

Flat out: there's no solution with perfect coverage and no false positives. But we fix every false positive that we're told about. And we're working to make the product perfect.

That's integrity - we work to be better than we are, rather than just hiding our errors and offloading it to the customer.

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.