I recently spoke with a friend who left the DC region for a position in Silicon Valley. When I asked what he thought of the move he said, “Well, you have the same giant buildings with technology company names on the outside rising out of nowhere. You have the same high quality of engineer, but it seems that the difference is in DC, everyone wears a suit or a tie and looks down upon you if you grab a drink at lunch, or unwind like a younger person would.” 

I thought long and hard about his comment and decided that I would have to find out for myself. Is the DC area high tech community really that stuffy? Do people really not enjoy a good stiff drink after a long day? 

Last night, I attended the Twin Tech party, a sponsored happy hour with the worthy goal of “mixing up our vast, and somewhat fragmented technology culture here in the greater DC region”. I can officially say, the DC tech scene is changing and it’s changing fast.

Let’s start with the venue, instead of holding this event in the suburbs (McCormick & Schmicks anyone?) or at a large hotel bar, they chose to have the event at a trendy up-and-coming part of town in what can be best described as one of DC’s hottest bars, Local 16.  Not only that, because of the overwhelming response to attend, they had to rent out the bar next to it as well. 

I expected that I would arrive and find the place mostly empty and have a few suits there chatting over a drink or 2.  Instead I found myself at the overflow bar with a number of young up and comers in the space.  It was impossible to get into the original venue, and the second venue was packed as well!  Amongst all the people I found a friendly, happy, open vibe that allowed for great conversation, and interesting discussion about new technologies and the ideas people had about using and building the future. 

It was the best of both worlds for a young technologist.  I was able to discuss the topics and issues that were most facilitating and relevant (Social Networking from a corporate perspective, new blogging ideas, how new media is helping old media, etc), while still having a great time, and allowing myself to be properly refreshed for a hot DC summer night.

ShareThis

The good news is that due to the nature of this problem, it is extremely difficult to determine the vulnerability merely by analyzing the patches; a common technique malicious individuals use to figure out security weaknesses.

The typical response I heard was “what do you mean, it can’t be reverse engineered? I’ll just look at the diffs!”

In hindsight, after examining the BIND diffs (yes, I did it too) and discussing with colleagues, all most people saw was UDP source port randomization and a better PRNG for generating the transaction ID, the latter of which would appear to be related to Amit Klein’s cache poisoning attack from about a year ago.

What Rich was really saying is that you can reverse engineer the patch until you’re blue in the face, but that won’t reveal the specifics of the vulnerability.

Dan’s blog post this morning appeared to confirm that interpretation:

DJB was right. All those years ago, Dan J. Bernstein was right: Source Port Randomization should be standard on every name server in production use.

There is a fantastic quote that guides a lot of the work I do: Luck is the residue of design. Dan Bernstein is a notably lucky programmer, and that’s no accident. The professor lives and breathes systems engineering in a way that my hackish code aspires to one day experience. DJB got “lucky” here — he ended up defending himself against an attack he almost certainly never encountered.

Such is the mark of excellent design. Excellent design protects you against things you don’t have any information about. And so we are deploying this excellent design to provide no information.

To translate the fix strategy into a more familiar domain, imagine large chunks of Windows RPC went from Anonymous to Authenticated User only, or even all the way to Admin Only. Or wait, just remember Windows XPSP2 :) This is a sledgehammer, by design. It cuts off attack surface, without necessarily saying why. Astonishingly subtle bugs can be easily hidden, or even rendered irrelevant, by a suitably blunt fix.

Nate McFeters appears to think that Tom Ptacek has figured it out. I’m going to go out on a limb and say that Tom didn’t figure anything out yet but still wanted to write a pithy blog post. I think that if Tom had figured it out, he would have written it down privately and posted the SHA-1 hash, as is the trendy thing to do these days.

Speculation aside, the title of Tom’s blog entry, Dan Kaminsky could have made hundreds of thousands of dollars with this DNS flaw!, does make an important point — Dan didn’t sell the details to ZDI, he used his influence and reputation to coordinate a massive vendor patch effort. That’s an admirable move.

I had an Austin Powers moment today when I opened an email from eSecurityPlanet.com and saw a link to an article called, Feel Vulnerable? Time for Vulnerability Management Tools.  I felt like I had been in suspended animation for years and just woke up. I have not seen an article on vulnerability management in forever and ever. There was nothing earth shattering in this article.  Meat and potatoes VM. That is vulnerability management, not virtual machines.  The fact that VM is more commonly associated with virtualization than vulnerability management in and of itself probably speaks volumes.

Just last week at the Infosec World conference I had remarked to some folks that walking the show floor I did not see one vendor using the term vulnerability management in their signage.  Even some companies that are plainly in the VM space such a nCircle and Qualys, are using risk management and similar terms to describe what they do. So why has vulnerabiity management fallen out of disfavor?  Is it any less important?  In the words of "The Shagadillic One", do they think it ain't sexy? That may be it.  It is not sexy or trendy anymore.  I remember going to RSA a few years ago and every vendor had some strategy around vulnerability management.  I will be looking at this years show and report how many times I see the VM word.

So what is it about the security world.  Do we collectivley have the attention span of a flea. Do security tools go from golden to rust that quickly?  Why are we constantly searching for the next great thing but seemingly at the expense of the last great thing.  Wouldn't it be nice to see something through and make it really work before we rush on to the next one.

I had an Austin Powers moment today when I opened an email from eSecurityPlanet.com and saw a link to an article called, Feel Vulnerable? Time for Vulnerability Management Tools.  I felt like I had been in suspended animation for years and just woke up. I have not seen an article on vulnerability management in forever and ever. There was nothing earth shattering in this article.  Meat and potatoes VM. That is vulnerability management, not virtual machines.  The fact that VM is more commonly associated with virtualization than vulnerability management in and of itself probably speaks volumes.

Just last week at the Infosec World conference I had remarked to some folks that walking the show floor I did not see one vendor using the term vulnerability management in their signage.  Even some companies that are plainly in the VM space such a nCircle and Qualys, are using risk management and similar terms to describe what they do. So why has vulnerabiity management fallen out of disfavor?  Is it any less important?  In the words of "The Shagadillic One", do they think it ain't sexy? That may be it.  It is not sexy or trendy anymore.  I remember going to RSA a few years ago and every vendor had some strategy around vulnerability management.  I will be looking at this years show and report how many times I see the VM word.

So what is it about the security world.  Do we collectivley have the attention span of a flea. Do security tools go from golden to rust that quickly?  Why are we constantly searching for the next great thing but seemingly at the expense of the last great thing.  Wouldn't it be nice to see something through and make it really work before we rush on to the next one.

Dear friend Opher Etzion responds to my post Betting on the SOA Horse with a discussion on how SOA, EDA and CEP are technically orthogonal, concluding:

“Event Processing can have different interactions with SOA, and when IBM’s announcements in this area will be available you’ll realize that there are different entry points. Event processing can also work in legacy and non-SOA environment.”

Richard Veryard, who also kindly reads my blog (and Opher’s blog) replies with Technological Perfecta where he opines,

“I think there are some mutual dependencies between these technologies, but they are what I call soft dependencies.”

Opher, Richard, you guys are technically right, but you are blogging orthogonally to the message in Betting on the SOA Horse.

First of all, my post was not a technical discussion, it was a discussion about business, marketing, timing positioning and the software industry in general. Therefore, it is a bit humorously orthogonal to reply to a marketing metaphor about investments, competition, software postioning and horse racing with architectual posts about technology and how they are related or interdependent.

In a nutshell, here is why….

Candidly speaking, despite what many analysts want you to believe, end users rarely build “SOAs” “EDAs” or CEPs”. End users have IT budgets to solve business problems with the most cost effective technology they can find; and they do not care (if they have a clue) what cute three letter acronyms have been created by analysts to describe momentum in the software market. Sorry, it is true really.

For example, I remember when I was in Tokyo where the very capable and conservatively risk adverse Japanese executives told me time and time again, “We don’t care about SOA we simply want to integrate our systems.” They were quick to remind me, “You guys in America must realize we don’t care what the western analysts, supported by software companies, say. They have a conflict-of-interest anyway and they are not end users. What we care about are mature technologies with solid reference clients and proven implementations.”

By the way, this is one reason I admire Japanese business so much. They are not impressed with handwaving hyperbole. They just want to see results. In other words, “Prove it, don’t just say it.” The devil is in the details, as they say. The Japanese are highly skillful at cutting through the smoke-and-mirrors. I think this is one reason the Japanese are among the leaders in so many industry sectors, but that is a blog story for another day.

To this point, if you are in front of customers and you are pushing SOA because your software company has “bet the farm” on positioning themselves as an SOA company, you are making a mistake. Three letter acronyms and technology jargon do not solve business problems. In fact, for the most part, they are a red-herring. The same is true of EDA and CEP. This was the main message in my post Betting on the SOA Horse.

How do I make such a statement?

Because for over 20 years I have worked as a consultant working on the opposite side of the table of hungry software vendors who come into our house (organization) tossing out buzzwords, acronyms, and jargon. My job was solving real business problems, not selling software. We used to wonder when all the scrabble and babble the software companies were tossing at us was going to turn into a business language that solves a real business problems easily, rapidly and economically. That day never came.

Then, I made a conscious decision to take a break from a long career of consulting to get an insiders perspective on, and perhaps even transform, the software industry. This experience, working for a software company, was an eye-opener, and one I am most likely not to repeat. I have never been interested in selling softare. I am interested in real business solutions.

Candidly speaking again, many software companies tend to live in “La La Land”.

They create go-to-market strategies based on jargon, buzzwords and three letter acronyms that have very little to do with understanding their customer’s business problems, risks, and culture. They spin and position and reposition in a land of smoke-and-mirrors happy to sell you a gold disk of “the-answers-to-all-your-problems.” They leave you the gold disk, and your business problem, as they drive away, looking at you in the rear view mirror as they count the revenue from their victorious campaign.

These same companies bet on jargon like SOA, EDA, CEP, BAM and they hedge their bets with different combinations of the above, the theme of my post Betting on the SOA Horse, which was not a technology nor architectural discussion, in any way.

Is it any real wonder why SOA has become, for the most part, complex, vendor-driven jargon barely making a dent in the real-world, whereas social-networking and other grass-roots user-driven technologies, most without trendy three letter acronyms, has left SOA in the dust for the past few years?