Rational Survivability

For Sale / Special Price: One (Un)detectable Hyperjacking PillWare: $416,000. Call Now While Supplies Last!

Joanna Rutkowska of "Invisible Things" Blue Pill Hypervisor rootkit fame has a problem.  It's about 6 foot+ something, dresses in all black and knows how to throw down both in prose and in practice.

Joanna and crew maintain that they have the roughed-out prototype that supports their assertion that their HyperJacking malware is undetectable.  Ptacek and his merry band of Exploit-illuminati find this a hard pill to swallow and reckon they have a detector that can detect the "undetectable."

They intend to prove it.  This is awesome!  It's like the Jackson/Lidell UFC fight.  You don't really know who to "root" for, you just want to be witness to the ensuing carnage!

We've got a stare down.  Ptacek and crew have issued a challenge that they expect -- with or without Joanna's participation -- to demonstrate successfully at BlackHat Vegas:

Joanna, we respectfully request terms under which you’d agree to an “undetectable rootkit detection challenge”. We’ll concede almost anything reasonable; we want the same access to the (possibly-)infected machine than any antivirus software would get.

The backstory:

• Dino Dai Zovi, under Matasano colors, presented a hypervisor rootkit (“Vitriol”) for Intel’s VT-X extensions at Black Hat last year, at the same time as Joanna presented BluePill for AMD’d SVM.

• We concede: Joanna’s rootkit is coolor than ours. I particularly liked using the debug registers to grab network traffic out of the drivers. We stopped weaponizing Vitriol.

• Peter Ferrie, the Symantec branch of our Black Hat team, releases a kick-ass paper on hypervisor detection. Peter’s focus is on fingerprinting software hypervisors (like VMWare), but he also comes up with a clever way to detect hardware virtualization.

• Nate Lawson, Dino, and I are, simultaneously, working on hardware rootkit detection techniques.

• Nate, Peter, Dino, and I join up to defend our thesis at Black Hat: if you surreptitiously “hyperjack” an OS, enabling hardware virtualization (or replacing or infecting an existing hypervisor), you introduce so many subtle changes in system behavior —- timing and otherwise —- that you’re bound to be detectable.

...and Joanna respondeth, signaling her "readiness" and conditions for the acceptance of said challenge:

Thomas Ptacek and company just came up with this funny challenge to test our Blue Pill rootkit. And, needles to say, the Invisible Things Lab team is ready to take their challenge, however with some additional requirements, that would assure the fairness of the contest.

First, we believe that 2 machines are definitely not enough, because the chance of correct guess, using a completely random (read: unreliable) detection method is 50%. Thus we think that the reasonable number is 5 machines. Each of them could be in a state 0 or 1bluepill.exe and bluepill.sys

The .sys file is digitally signed, so it loads without any problem (we could use one of our methods for loading unsigned code on vista that we're planning to demonstrate at BH, but this is not part of the challenge, so we will use the official way).

The bluepill.exe takes one argument which is 0 or 1. If it's 1 it loads the driver and infects the machines. If it's 0 it also loads the driver, but the driver does not infect the machine.

So, on each of the 5 machines we run bluepill.exe with randomly chosen argument, being 0 or 1. We make sure that at least one machine is not infected and that at least one machine is infected.

After that the detection team runs their detector.exe executable on each machine. This program can not take any arguments and must return only one value: 0 or 1. It must act autonomously -- no human assistance when interpreting the results.

The goal of the detection team is to correctly mark each machine as either being infected (1) or not (0). The chance of a blind guess is:

(i.e. infected or not). On each of this machines we install two files:

1/(2^5-2) = 3%

The detector can not cause system crash or halt the machine -- if it does they lose. The detector can not consume significant amount of CPU time (say > 90%) for more then, say 1 sec. If it does, then it's considered disturbing for the user and thus unpractical.

The source code of our rootkit as well as the detector should be provided to the judges at the beginning of the contests. The judges will compile the rootkit and the detector and will copy the resulting binaries to all test machines.

After the completion of the contest, regardless of who wins, the sources for both the rootkit and the detector will be published in the Internet -- for educational purpose to allow others to research this subject.

Our current Blue Pill has been in the development for only about 2 months (please note that we do not have rights to use the previous version developed for COSEINC) and it is more of a prototype, with primary use for our training in Vegas, rather then a "commercial grade rootkit". Obviously we will be discussing all the limitations of this prototype during our training. We believe that we would need about 6 months full-time work by 2 people to turn it into such a commercial grade creature that would win the contest described above. We're ready to do this, but we expect that somebody compensate us for the time spent on this work. We would expect an industry standard fee for this work, which we estimate to be $200 USD per hour per person.

If Thomas Ptacek and his colleges are so certain that they found a panacea for virtualization based malware, then I'm sure that they will be able to find sponsors willing to financially support this challenge.

As a side note, the description for our new talk for Black Hat Vegas has just been published yesterday.

So, if you get past the polynomial math, the boolean logic expressions, and the fact that she considers this challenge "funny," reading between the HyperLines, you'll extract the following:

1. The Invisible Things team has asserted for some time that their rootkit is 100% undetectable
2. They've worked for quite sometime on their prototype, however it's not "commercial grade"
3. In order to ensure success in winning the competition and thus proving the assertion, they need to invest time in polishing the rootkit
4. They need 5 laptops to statistically smooth the curve
5. The Detector can't impact performance of the test subjects
6. All works will be Open Sourced at the conclusion of the challenge
   (Perhaps Alan Shimel can help here! ;) ) and, oh, yeah...
7. They have no problem doing this, but someone needs to come up with $416,000 to subsidize the effort to prove what has already been promoted as fact

That last requirement is, um, unique.

Nate Lawson, one of the challengers, is less than impressed with this codicil and respectfully summarizes:

The final requirement is not surprising. She claims she has put four person-months work into the current Blue Pill and it would require twelve more person-months for her to be confident she could win the challenge. Additionally, she has all the experience of developing Blue Pill for the entire previous year.

We’ve put about one person-month into our detector software and have not been paid a cent to work on it. However, we’re confident even this minimal detector can succeed, hence the challenge. Our Blackhat talk will describe the fundamental principles that give the detector the advantage.

If Joanna’s time estimate is correct, it’s about 16 times harder to build a hypervisor rootkit than to detect it. I’d say that supports our findings.

I'm not really too clear on Nate's last sentence as I didn't major in logic in high school, but to be fair, this doesn't actually discredit Joanna's assertion; she didn't say it wasn't difficult to detect HV rootkits, she said it was impossible. Effort and possibility are mutually exclusive.

This is going to be fun.  Can't wait to see it @ BlackHat.

See you there!

/Hoff

Holed up in Milan, Italy on SpecOps Assignment...Advanced Bug Hunting

The location is far from classified; the Grand Visconti Palace in Milan Italy.  It's a dirty job, but someone's got to do it.  This is the nasty stuff though...the wet work. 

This is the stuff nobody else wants to do.  Even talking about it is painful.  Talking about it is what we're trained NOT to do.  But I'm alone.  There's noone coming for me.  This could be it.

I'm holed up in my hotel room on this assignment, awaiting extraction.  I'm fifty clicks from the LZ, the transpo isn't due for another 6 hours.  Radio silence.

I knew that when I took the job that it meant lonely, dangerous work.  It's 01:18am here now.  I'm delirious after an aggravating lack of sleep. 

My mission grinds on against the backdrop of reveling Italian supermodels drunk in the streets below, the enticing aromas of tagliatelle that permeates the very fabric of this country, and what can only be described as the Roman Jerry Spring(ieri) show bellowing through the thin walls of my room from the reveling assclowns next door.

I can't sleep.  I mustn't.  I want to, and I strain against the overbearing slabs of concrete that my eyelids have become.  Must.  Hang.  On.

It's not because of the supermodels, the pasta or the Jerry special on midget tossing.  No, I can't sleep because I am subject to the relentless onslaught of an attack as a direct counter-response to my bug hunting activities.   

This is where all the training pays off.  This is where intuition takes over.  Fear has no place in my world.  I will shed blood.  Some of it mine.  But I shall hold fast and like those from Rome and Sparta before me, I will emerge triumphant.

I am wounded.  I want to scrape away the pain but the more that I do, the worse it becomes.  My very soul itches.

The heat is unbearable.  The sweat drips into my eyes. I must focus.  I practice Tai Chi to center myself and prepare for what is assuredly coming.

My foe is an intelligent adversary.  In light and dark, he appears from stealth taking quick swaths at me; feeling me out for just how far I will go to defend against attack; my reach, my skill, my will.  He is lightning quick.  No warning until it is too late. 

The attack comes.  That sound that drills into my psyche.  It taunts me.  It mocks me.  The inevitable pain delivered again. Can't.  See.

I must take action.  My body takes over.  The will to defend is overwhelming.  I stab the air.  Kicking, screaming, smacking. 

Slapping. 

Myself. 

I've poked myself in the eye with my thumb and backhanded my skull as I valiantly deflect the attack.  I try to hide under the cover of whatever I can shield myself with.  Furniture.  Bedding.  Pellegrino bottles.  I take evasive maneuvers.  Why won't he stop!?  The pain of anticipation is worse than the wounds themselves.

I flashback to training.  Fight stealth with stealth.  I'll wait for his recon; look for the flash and strike.  Must.  Seek.  Cover.

Should I wait it out in the closet -- maybe the bathroom?

He's coming again.  Relentless.  He appears, cloaked in deception and disdain.  Then, like that, he disappears.  I scratch at phantom wounds that aren't there.  That sound!  Make it stop!

Ripping through the air; wildly grasping for swaths of atmosphere...hoping to grab hold of...something in the dark.  And squash it.  Die!

I want to deliver death swiftly.  Mercilessly.  Over and over again.  Uncaring, nasty, excruciating death.  Now.  This has gone on for hours.  I need to sleep.

But it is not to be.  I will be tormented all night until I can leave this hellhole and find solace in the airport awaiting the ride home.

I am now laying in my bathtub where it is safe.  The fan is on, Macbook Pro on my lap, wirelessly connected.  My only lifeline to the world.  To you.

My enemy cannot reach me here.  Perhaps he will retreat and try to strike again later.

F'ing Mosquitoes!

/Hoff

Take5 (Episode #3) - Five Questions for Jeremiah Grossman, Founder/CTO of Whitehat Security

This third instance of Take 5 interviews Jeremiah Grossman, Founder & CTO of Whitehat Security.

First a little background on the victim:

Jeremiah Grossman is the founder and CTO of WhiteHat Security,
considered a world-renowned expert in Web security, co-founder of the
Web Application Security Consortium, and recently named to
InfoWorld's Top 25 CTOs for 2007.  Mr. Grossman is a frequent speaker
at industry events including the BlackHat Briefings, ISACA, CSI,
OWASP, Vanguard, ISSA, OWASP, Defcon, etc.  He has authored of dozens
of articles and white papers, credited with the discovery of many
cutting-edge attack and defensive techniques, and co-author of XSS
Attacks. Mr. Grossman is frequently quoted in major media publications such as InfoWorld, USA Today, PCWorld, Dark Reading, SC  Magazine, SecurityFocus, C-Net, SC Magazine, CSO, and InformationWeek.  Prior to WhiteHat he was an information security officer at Yahoo!

Here is Jeremiah's blog and a new book on XSS that he co-authored.

Questions:

1) You're probably best known for your work on JavaScript attacks,
XSS, and CSRF.  This stuff is such a mess and represents an
insidious vector for attack.  Do you think we're ever going to be
able to get this genie back in the bottle or are we totally screwed?

Fortunately the Web the will hum along and adapt no matter how bad
the "hacker attacks" get. We know XSS and CSRF vulnerabilities are
everywhere, but the bigger problem is we don't know exactly where
they ALL are. This is what makes the problem really hard to solve.
Short of an entire rewrite of THE WEB, we're going to be stuck with
XSS, CSRF, and two dozen other issues for many years to come. Though
as websites are revamped with new development frameworks for business
reasons we'll see security improve naturally.

2) Your days of securing hundreds of websites at Yahoo set the
stage for what you do today.

Yah, I left the behemoth portal and now I find myself responsible for
helping to secure more websites than ever!  :)

What elements of today's emerging security problems that you are
working on do you think will become another area of focus for you
in the long term.

At WhiteHat we’re delivering website vulnerability assessment (VA) on
an unprecedented scale. This is important because companies need to
constantly monitor the security of ALL their websites ALL the time.
Prior to WhiteHat the best a company could do were annual audits only
affordable on a select few websites. As websites change this process
clearly doesn’t work and the number of incidents and vulnerability
prevalence are prime indicators. We need to be able to assess
hundreds, thousands, tens of thousands of the worlds largest and most
important websites no matter how big or how often they change. This
insight will provide intelligence we need to start solving the problem.

The second phase is figuring how to “fix” the problem and prevent new
vulnerabilities from cropping up in the first place. Security inside
the SDLC has been talked about a lot and will improve software
security in the long run. In the mean time, there are a ton of
websites and even more vulnerabilities where relief is required
between now and then. Web application firewalls are a likely option.
What I’d like to see is tight integration between VA solutions and
WAF devices. Since VA knows the specific type and location of
vulnerabilities in a website technically they could communicate a
highly accurate rule or “virtual patch” to a WAF and block any
incoming attacks. This would provide security professionals more
control over the security of a websites and developers time to
address the problem.

3) What do you make of Google's foray into security?  We've seen
them crawl sites and index malware.  They've launched a security
blog.  They acquired GreenBorder.  Do you see them as an emerging
force to be reckoned with in the security space?

I doubt Google has plans to make this a direct revenue generating
exercise. They are a platform for advertising, not a security
company. The plan is probably to use the malware/solution research
for building in better security in Google Toolbar for their users.
That would seem to make the most sense. Google could monitor a user's
surfing habits and protect them from their search results at the same
time.

4) You recently participated in the CSI working group's on Web
Security Research Law in which you and other experts toiled over
the legal and ethical elements of web security vulnerability and
disclosure. Given the report's outcome of more questions than
answers, where do you stand personally on the issue of disclosure?

My personal actions probably won’t change much. I’ve been in the non-
disclosure camp for a while, unless I had a personal relationship
with the company. What has changed is my understanding on the
legalities of website vulnerability discovery. Apparently there is NO
clear-cut guidance as to what security researchers (in the US) are
legally allowed to do or not do. Once the website owner complains to
law enforcement it could quickly become a nightmare for the
researcher no matter how pure their intentions. So the unfortunate
consequence of all this will be the “good guys” will tend to stop
looking, and more importantly stop disclosing, while the bad guys get
the run of the place no matter what anyway. The net effect is bad for
website security and the consumer. Welcome to Web 2.0.

5) So you practice Jiu Jitsu in competition, you play Aussie Rules
Football (in *real* countries like NZ, we play Rugby...) and you
make the Internet safe for women and children.  Death wish,
misplaced angst or ADD?

And you say I have a death wish! I dare you to say those words on the
pitch in front of the Aussies. :)  Anyway, I've NEVER been accused of
having ADD, if anything too focused. I tend to enjoy extreme sports
and keep myself very busy, part of my personality. Unsolvable
problems are the other thing that are attractive to me. Glutton for
punishment. :)

BrokeNAC Mountain - "I wish I knew how to quit you."

An entire day and forum dedicated to NAC in the NYC?  Huh.  I thought we did that at InterOp and RSA already!?  I suppose it's necessary to wade through all the, uh, information surrounding the second coming of network security.

If someone builds one for UTM, I will kill myself.   

Oh NAC...I wish I knew how to quit you!

(I was going to photoshop the poster to the left including Alan Shimel and changing the title to BrokeNAC Mountain, but I can't find my Photoshop CD and I've got a plane to catch to Milan...)

I've made it clear that I think NAC (Network Admission Control and Network Access Control) is valuable and worth investing in as part of a layered defense.  It ain't the silver bullet of security, however.  Maybe Stiennon can come up with a new name for it and it will be?

I've also made it clear that despite the biggest amount of hype since the Furby, NAC will become a feature as part of a conglomeration of solutions in the short term (24 months); it already is a replacement blanket marketing term for companies that used to be SSL VPN's that then became IPS's that are now NAC.  Look at the companies that now claim they're NAC-focused.  That's usually because the "market" they were in previously collapsed -- just like NAC will.

It seems that NAC's relationship with the world plays out just like a scene from Brokeback Mountain where the two main characters discuss whether the public sees through the thin facade of the uneasy relationship they project to the world -- just like the front NAC puts on:

Ennis Del Mar: You ever get the feelin'... I don't know, er... when you're in town and someone looks at you all suspicious, like he knows? And then you go out on the pavement and everyone looks like they know too?
Jack Twist: [Casually] Well... maybe you oughta get out of there, you know? Find yourself someplace different. Maybe Texas.
Ennis Del Mar: [Sarcastically] Texas? Sure, maybe you can convince Alma to let you and Lureen to adopt the girls. And we can just live together herding sheep. And it'll rain money from LD Newsome and whiskey'll flow in the streams - Jack, that's real smart.
Jack Twist: Go to hell, Ennis. If you wanna live your miserable fuckin' life, then go right ahead.
Ennis Del Mar: Fine.
Jack Twist: I was just thinkin' out loud.
Ennis Del Mar: Yep, you're a real thinker there. Goddamn. Jack fuckin' Twist; got it all figured out, ain't ya?

If the next NAC Forum is held in Texas, you'll know the end of the world is near...'course there ain't nuthin' wrong with the heavens rainin' money and streams full-a whiskey...

At any rate, I was catching up on my back-dated blog entries and just read Dom Wilde's (Nevis Networks  Illuminiations Blog) summary of the Network Computing NAC 2007 Forum and couldn't help but chuckle.  Shimel's review seemed a little more upbeat compared to Dom's, but since Alan got stalked by a blogger paparazzi in a three-wheeled, pedal-powered rickshaw, I can see why.

Snippet Summary from Dom's Post:

It's little wonder that people are confused about NAC.  Too many times during the day I found myself with a furrowed brow trying delineate between reality and fiction...Disappointing moment of the day - 7 panelists on the OOB panel frying the audience's collective brain, by taking 10 minutes each to say "me too".  Result: half the audience didn't return after lunch for more lively and concise discussions on in-line and framework based solutions, and more critically, to hear narratives and lessons learned from people who have deployed NAC.

Snippet Summary from Alan's Post:

Anyway, it was a great way for people looking at deploying NAC to come up and touch and feed a real live NAC vendor. Ultimately, you still have to install the product and play with it yourself to see if it works.  There were lots of claims and NAC crap flying today.  I also would like to see more of a panel of answering questions then just giving our elevator pitch powerpoints to the crowd.  Still a worthwhile day and a good job by Network Computing. I think all of the elevator pitches will be posted on NC site soon.

Sounds great.

Both Dom and Alan's companies provide NAC solutions.  Both were at the show.  Both seem to convey the sense that this was more circus than it was scholarly.  I'm not sure that's because it was focused on NAC or because in general most conferences/forums are completely useless, but I'm interested in anyone else's opinion from those what where there.

/Hoff

Take5 (Episode #2) - Five Questions for Marcus Ranum

This second instance of Take 5 interviews Marcus Ranum.  Yep, no shit.

First a little background on the victim, Marcus Ranum, in his own words:

I don't know how to describe myself, anymore. At this point I have held every job you can hold in the security industry - from system administrator to coder, engineering team leader, product manager, product marketing, CSO, CTO, and CEO, industry analyst, teacher, and consultant. If I got to choose which of those I'd rather you thought of me as, it'd be teacher.

Back in the early 90s I did a lot with developing firewalls, and designed and coded the DEC SEAL and TIS Firewall Toolkit - both of which were pretty popular and ground-breaking in their time. I also founded one of the early IDS start-ups, Network Flight Recorder (recently bought by Checkpoint) and served as CEO there for 4 years.Today, I am the CSO of Tenable Network Security - the company that produces a the Nessus vulnerability scanner and a suite of security management tools. I live in the wilds of Pennsylvania with 2 huge dogs, 2 horses, and about 18 cats, and spend my spare time doing photography, farming, and too much other stuff to list.

1. Let's get this out of the way first...The Security Industry vs. Marcus Ranum...Why so grumpy or are you just misunderstood?

I don't understand! Does the security industry disagree with me? What, are they, stupid?

Just kidding. I'm grumpy - and justifiably so - because, like many security people, I've noticed that if you work really hard to organize your thinking about security so that it becomes clear - your good advice will be completely ignored anyhow. Many of the problems that we encounter all over the place today are just instances of the same problems that smarter people than myself predicted we'd have in the early 1980's.

So, I see the industry as dangerously out of step with its constituents. Remember: this is about protecting real people against real bad things. It's not a theoretical game. I get really pissed off when I see glib little sociopathic weasels putting innocent people at risk so they can market their products (to those same people!) - it disgusts me. And it disgusts me when I see the media, government agencies, and big-name vendors playing the game.

Those are the short-term frustrations. There are longer-term ones, as well. One of my dad's friends was a cardiologist and he used to periodically go on a rant that went like this: "90% of my patients come in and are overweight, out of shape, and drink too much, smoke, or snort cocaine. They tell me all this and I tell them they're ripe for a heart attack. Then I tell them that they need to lose some weight, exercise, and take it a bit easier on their bodies - and they look at me like I'm crazy and ask 'what's Plan B'?"   

Well, that's how I feel about security a lot of the time.  The problems we deal with are so stupid and so obvious - sometimes it makes me want to ask executives, "What are you, retarded?"  Even a Harvard MBA should be able to figure out that if you have copies of your data all over the place where anyone in the enterprise can get at them, it's going to wind up on laptops and on the Internet.

So - I am frustrated and I am middle-aged (and then a little bit) - at a certain point I feel the long-term downside of speaking my mind will get less and less significant, so why not just let it all hang out?

2. You're at Tenable Security as CSO now, what are you doing there and why?  You and Ron Gula make a great couple, but are you involved in any other security or technology ventures?

Well, originally, it was Ron and Renaud. Tenable was already cooking along on course before I got involved. I knew Ron from the NFR days because I used to compete with him when he was selling the (now Enterasys) Dragon IDS against us. My role at Tenable is to be a mix between class clown, consultant, and technical trainer - I teach our customers' classes on how to use our products and feed back ideas and questions through Ron. It works pretty well. Best of all, the rest of the management team at Tenable are all highly technical geeks.

There's no arguing about how to do the right thing with Venture Capitalists because we're self-bootstrapped and suit-free. On the other hand, we'll argue all day about which Linux distro is better - if you can pick and choose your battles, I'll take technical debates about how many angels can fit on a USB thumb-drive over talking to MBAs any day.

I serve as an advisor to several security start-ups and have to be very careful to keep from getting at competitive cross-purposes. But I love the advisory role - you can look at where a product is going and say, "hey, it'd be nice if it did X, Y, Z" - and a few months later, it does. It's like being an important customer without having to talk to sales guys! I make a point of actually pounding on products and getting as deep as I can, too.

For example, I am on an advisory board for a company called Fortify that makes a source-code security analyzer tool, and I grabbed the product and spent a week running some of my own code (and other popular open source products) through it. That kind of thing can be really fun!

3. You've recently started publishing your "Rear Guard" PodCast.  It's quite entertaining and what some might describe as classic "Ranum."  What attracted you to PodCasting and do you see starting a Blog?

I got interested in podcasting because I have a real problem with writing - I'll write an article and go over it again and again and again until I'm happy with it. Writing is like pulling teeth for me. Sometimes, such as the time I was stuck in Frankfurt airport with nothing to do for 36 hours and the only electrical outlet was in the beer-bar - then I get a lot of writing done in a burst. But it doesn't come easy for me whereas speaking does. So I was listening to a few of my old audio recordings from conferences and thought, "Hey, I can get stuff out there really fast this way!"   Besides it's a great way to play with tech toys like audio recorders and phone line-taps, etc!

Normally I am an instant nay-sayer about "the new thing" for its own sake but I think that podcasting is fascinating - essentially it's completely liberated asynchronous radio. If that's not fantastic, I don't know what is! The barrier to entry is basically nonexistent - it's so low there's no need to worry about sponsorship or marketing crap to pay for it. It's an environment where content truly is king: if your stuff is good, people will listen.

With respect to a blog - probably not. There are already great blogs out there and I don't like the short note format. I prefer to write constructed arguments or tutorials; I just can't whip out a couple paragraphs and let them go like some people can. Blogging tends to encourage a high volume of content. With my schedule and wildly varying energy/attention levels I can't do more than an intermittent effort.

4. Are there any companies with emerging products or technology in the security space that you feel really "get it" and are doing the "right things" to move security ahead in the right direction?

I'd like to dodge that question, if I may. Otherwise I'll sound like a marketing guy.

But the sad truth is that a lot of what I see out there is reinventing the wheel to varying degrees. The industry has reinvented antivirus and firewalls about ten times so far - of course it gets called something new and whizzbang each time. That's inevitable (and uninteresting) because security is a moving target - someone is always getting new bright ideas like "let's tunnel remote procedure calls over SSL by encoding them in XML" and the poor guys trying to secure it only have a limited set of techniques they can apply (content filtering, signatures, protocol analysis) and - of course - they'll work as well as they always do.

There is cool stuff being done but I'd categorize it mostly as "solid new implementations of good old ideas."  There's nothing wrong with that, either.

5. As one of the "founding fathers" of network security -- from your firewall days to NFR and beyond -- what advice do you have for the up and coming security "professionals"  who are going to have to deal with "securing" networks and assets in an already dynamic and hostile environment while serving the "Frappacino-YouTube-FaceBook-SecondLife-Tor-Twitter-I_Want_It_Now-AlwaysOn" generation who hack life?

Succinctly? "Get used to losing every battle you fight."

I actually get a fair number of Emails every month from people who are thinking about getting into information security. My old suggestion used to be to identify an interesting but not overly ambitious problem in the security space, make a decent attempt at making it less of a problem, and publish everything you can about what you did, why, and what you learned.

Thanks to the "bug of the minute" mindset we're stuck in now, security has become an intellectual wasteland and the people who will be the next generation of stars will always be the ones who are solving problems (not creating them) and helping the poor outgunned IT specialist.

My new suggestion, when someone asks me about a career in security, is to reconsider the whole idea. In 10 years (probably less) security is going to re-collapse back into system administration and network administration.  Your security practitioner of the future is going to be the guy who clicks the "make it secure" button on the rack of Cisco gear - and he'll have no idea what that button does. On the systems side, he'll be the Windows system administrator who forklift-pushes Microsoft Security for Windows to all the desktops, enables it, and reboots them. That'll be that.

Note: I am not saying it'll actually be secure, or work, but that's about the tolerance for security effort that will be left in most IT executives' minds. And, of course, security will be reporting to lawyers. After all these years of short-sighted security experts saying, "What we need is legislation..." now we've got it.

And, as a consequence, security is going to be permanently in the "expense" column and it'll be a legal mitigation/triage game played by executives and lawyers, with the security guy's job consisting mostly of hovering over the system admin's shoulder to make sure that they actually clicked the "on" button where it says "security."

So - I think security's about to suffer a mental and financial heat-death. Frankly, we deserve it. If you look at what security has accomplished in the minds of most IT execs, during the last 10 years, it has been an endless stream of annoying bug-fixes. All the positive stuff is completely overwhelmed by the flood of mal-this and mal-that and the constant yammering for attention from the vulnerability pimps.

6. Bonus question.  Assuming I qualify the form factor to something that can be carried on your person, what's your favorite weapon?

That would have to be my custom-forged Bugei daisho that I commissioned in the early 1990's. But if it was a situation involving more horizontal separation, I'd have to go with my Barrett model 95 with the 8-32x US Optics scope.

/mjr.

How to Kick Ass in Information Security -- Hoff's Spritually-Enlightened Top Ten Guide to Health, Wealth and Happiness

I’ve spent a while in this business and have been doing time on planet Earth in a variety of roles in the security field; I’ve been a consumer, a CISO, a reseller, a service provider, and a vendor, so I think I have a good sense of shared empathy across the various perspectives that make up the industry's collective experience.

I get to spend my time traveling around the world speaking to very smart people; overworked, tired, cynical, devoted, and fanatical security folks who are all trying to do the right thing within the context of the service they provide their respective businesses and customers.

A lot of them are walking around in a trance however, locked into the perpetual hamster wheel of misery that many will have you believe is all security can ever be.  That’s bullshit.  I love my job; I’ve loved every one of them in this space.  They have all had their ups and downs, but I know that I’ve made a positive difference in every one because I believe in what I’m doing and more importantly I believe in how I’m doing it.   If you want to manifest misery, then you will.  If you want to change the way security is perceived, you will.

Most of the people I speak to all have the identical set of problems and for some reason seem to be stuck in the same pattern and not doing much about trying to solve them.  Now, I’m not going to try and get all preachy, but when I hear the same thing over and over, up and down the stack from the Ops trenches to the CSO and nobody seems to be able to gain traction towards a solution, I’m puzzled as to whether it’s the problem or the answer people are seeking.

In many cases, people feel the need to solve problems themselves.  It's the classic "Dad won't pull into the gas station to ask directions when he's lost" syndrome.  Bad form.   Let's just pull over for a second and see if we can laugh this thing off and then get back on the road with a map.

I thought that I’d summarize what I've heard and articulate it with my top ten things that anyone who is responsible for architecting, deploying, managing and supporting an information security program should think about as they go about their jobs.   This isn’t meant to compete with Rothman’s Pragmatic CSO book, but if you want to send me, say, half the money you would have sent him, I’m cool with that.

These are not in any specific order:

1.    Measure Something
I don’t care whether you believe in calling this “metrics” or not.  If you’ve got a pulse and a brain (OK, you probably need both for this) then you need to recognize that the axiom “you can’t manage what you don’t measure” is actually true, and the output – no matter what you call it – is vitally important if you expect to be taken seriously.

Accountants have P&L statements because they operate around practices that allow them to measure the operational integrity and fiscal sustainability of a business.  Since security is functional service mechanism of the business, you should manage what you do as a business.

I’m not saying you need to demonstrate ROI, ROSI, or RROI, but for God’s sake, in order to gauge the efficiency, efficacy and investment-worthiness of what you’re doing, you need to understand what to focus on and what to get around to when you can spare cycles.  Be transparent about what you’re doing and why to management.  If you have successes, celebrate them.  If you have failures, provide a lessons-learned and move on.

You don't need a degree in statistics, either.  If you want some good clue as to what you can easily do to start off measuring and reporting, please buy this.  Andy Jaquith, while stunningly handsome and yet quaintly modest (did I say that correctly, Andy?) knows his shizzle.

2.    Budget Isn’t Important
That’s right, budget isn’t important, it’s absolutely everything.   If you don’t manage your function like it is a business burning your own cash then you won’t survive over the long term.  Running a business takes money.  If you don't have any, well...  As my first angel investor, Charles Ying taught me, “Cash is King.”   I only wish I learned this and applied it earlier.

If you lead a group, a team or a department and you come to the second budget cycle (the first you probably had no control over since you inherited it) under your watch and you open the magic envelope to discover that you don’t have the budget to execute on the initiatives in your security program that align to the initiatives of supporting the business, then quit.

You should quit because it’s your fault. It means you didn’t do your job.  It means you're not treating things seriously as a set of business concerns.

Whether you’re in a downcycle budget-cutting environment or not, it’s your job to provide the justification and business-aligned focus to get the money you need to execute.  That may mean outsourcing.  That may mean you do more with less.  That may mean that you actually realize that there tradeoffs that you need to illustrate which indicate risk, reward and investment strategies and let someone else make the business decision to fund them or not.

Demonstrate what you can offer the business from your security portfolio and why it’s worth investing in.  You won't be able to do everything.  Learn to stack the deck and play the game.  Anyone who tells you that a budget cycle isn't a game is (1) a lousy liar, (2) someone who doesn't have any budget and (3) nobody you need to listen to.

3.    Don’t Be a Technology Crack-Whore
If you continue to focus on technology to solve the security “problem” without the underlying business process improvement, automation and management & measurement planes in place to demonstrate what, why and how you’re doing things, then you’re doomed.   I'm not going to re-hash the ole "People, Process and Technology" rant as that's overplayed.

Learn to optimize.  Learn to manage your security technology investments as a portfolio of services that can be cross-functionally leveraged across lines of business and operationalized and cost-allocated across IT.

Learn to recognize trends and invest your time and energy in understanding what, if anything, technology can do for you and make smart decisions on where to invest; sometimes that’s with big companies, sometimes that’s with emerging start-ups. 

Quantify the risk vs. return and be able to highlight the lifecycle of what you expect from a product.  Understand amortization and depreciation schedules and how they affect your spend cycles and synch this to your key vendor’s roadmaps.

If your solutions deliver, demonstrate it.  If they fail, don’t try to CYA, but refer back to the justification, see where it blew a gasket and gracefully move on.  See #1 above.

4.    Understand Risk
Please take the time to understand the word “risk” and it’s meaning(s).  If you continue to overuse and abuse the term in conversation with people who actually have to make business decisions and you don’t communicate “risk” using the same lexicon and vocabulary as the people who write the checks, you’re doing yourself a disservice and you’re insulting their intelligence. 

If you don’t understand or perform business impact analyses and only talk about risk within the context of threats and vulnerabilities, you’re going to look like the FUD-spewing technology crack-whore in #3 above. 

This will surely be concluded because you sound like all you want is more money (see #2) because you clearly can’t communicate and speak the language that demonstrates you actually understand what and how what you do unequivocally contributes to the business; probably because you haven’t measured anything (see #1)

If you want to learn more about how to understand risk, please read this.  Alex Hutton is one wise MoFo.

5.    Network
That’s a noun and a verb.  Please don’t hunker in your bunker.  Get out and talk to your constituents and treat them as valued customers.  Learn to take criticism (see #6) and ask how you’re doing.  By doing that, you can also measure impact directly (see #1.)   You should also network with your peers in the security industry; whether at local events, conferences or professional gatherings, experiencing and participating in the shared collective is critical.

I, myself, like the format of the various "CitySec" get-togethers.  BeanSec is an event that I help to host in Boston.  You can find your closest event by going here.

The other point here is that as budget swings towards the network folks who seem to be able to do a better job at communicating how investing in their portfolio is a good idea (see #1 and #2) you better learn to play nice.  You also better understand their problems (see #6) and the technology they manage.  If you expect to plug into or displace what they do with more kit that plugs into “their” network, you better be competent in their space.  If they’re not in yours, all the better for you.

6.    Shut-up and Listen
Talk with one hole, listen with two.

If I have to explain this point, you’ve probably already dismissed the other five and are off reading your Yahoo stock page and the latest sports scores.  God bless and call me when you start your landscaping business…I need my hedges trimmed.

7.    Paint a Picture
Please get your plans out of your head and written down!  Articulate your strategy and long-term plan for how your efforts will align to the business and evolve over time to mature and provide service to the business.  Keep it short, concise, in “English” and make sure it has pretty pictures.  Circulate it for commentary.  Produce a mantra and show pride in what you do and the value you add to the business.   It’s a business plan.  Sell it and support it like it is.  Demonstrate value (see #1) and you’ll get budget (#2) because it shows that you understand you make business decisions, not technology knee-jerks.

This means that you keep pulse with what technology can offer, how that maps to trends in your business, and what you’re going to do about them with the most efficient and effective use of your portfolio. 

Most of this stuff is common sense and you can see what’s coming down the pike quite early if you pay attention.  If you craft your business plan and evolution in stages over time, you’ll look like a freaking prescient genius.  You'll end up solving problems before they become one.  Demonstrate that sort of track record and you'll have more runway to do what you want as well as what you need.

8.    Go buy a Car
User or new, it doesn’t matter.  Why?  Because the guys and gals who sell cars for a living have to deal with schmucks like you all day long and yet they still make six-figures and go home at the end of the day after an 8-10 hour shift and get to ignore the office.  They know how to sell.  They listen (#6,) determine what you have to spend (#2) and then tell you how good you look in that ’84 Sentra and still manage to up-sell you to a BMW M3 with the paddle shifters and undercoating.

You need to learn to sell and market like a car salesman – not the kind that makes you feel sticky, but the kind that you want to invite over to your BBQ because he had your car washed while you waited, brought you coffee and called you back the day after to make sure everything was OK.

Seriously.  Why do you think that most CEO's were salesmen?  You're the CEO of the security organization.  Act like it.

9.    Learn to Say “Yes” by saying “No” and vice-versa
Ah, no one word with so few letters inspires such wretched responses from those who hear it.  And Security folks just LOVE to say it.  We say it with such a sense of entitlement and overwhelming omnipotence. too.   We say it and then giggle to ourselves whilst we strike the Dr. Evil pinky pose wearing the schwag-shirt we scored from the $5000 security conference we attended to learn how to more effectively security the business by promoting security as  an enabler.

It’s OK to say no, just think about how, why and when to say it.  Better yet, get someone else to say it, preferably the person who’s trying to get you to say yes.  Use the Jedi mind-trick.  Learn to sell – or unsell.  This is tricky security ninja skills and takes a while to master.   

Having someone justify the business reason, risk and rewards for doing something – like you should be doing – is the best way to have someone talk themselves out of having you do something foolish in the first place.  You won’t win every battle, but the war will amass less casualties because you’re not running over every hill lobbing grenades at every request.

10.    Break the Rules
Security isn’t black and white.  Why?  Because despite the fact that we have binary compute systems enforcing the rules, those who push the limits use fuzzy logic and don’t concern themselves with the constraints of 1 and 0.   You shouldn’t, either.

Think different.  Be creative.  Manage risk and don’t be averse to it because if you’re running your program as a business, you make solid decisions based on assessments that include the potential of failure. 

Don’t gauge success by thinking that unless you’ve reached 100% that 80% represents failure.  Incremental improvement over time – even when it’s not overtly dramatic – does make a difference.  If you measure it, by the way, it’s clearly demonstrable.

Challenge the status quo and do so with the vision of fighting the good fight – the right one for the right reasons – and seek to improve the health, survivability, and sustainability of the business.

Sometimes this means making exceptions and being human about things.  Sometimes it means getting somebody fired and cleared out of their cube.  Sometimes it means carrot, sometimes stick.

If you want to be a security guard, fine, but don’t be surprised when you get treated like one.  Likewise, don’t think that you’re entitled to a seat at the executive table just because you wear a tie, play golf with the CFO, or do the things on this list.

Value is demonstrated and trust is earned.   Learn to be adaptive, flexible and fair -- dare I say pragmatic, and you'll demonstrate your value and you'll earn the trust and confidence of those around you.

So there you go.  One Venti-Iced-Americano inspired "Hoff's giving back" rant. Preachy, somewhat cocky and self-serving?  Probably.  Useful and proven in battle?  Absolutely.   If anyone tells you any different, please ask them why they're reading this post in the first place.    

Think about this stuff.  It's not rocket science.  Never has been.  Most of the greatest business people, strategists, military leaders, and politicians are nothing more than good listeners who can sell, aren't afraid of making mistakes, learn from the ones they make and speak in a language all can relate to and understand.  They demonstrate value and think outside of the box; solving classes of problems rather and taking the parochial and pedestrian approach that we mostly see.

You can be great, too.  If you feel you can't, then you're in the wrong line of work.

/Hoff

The 4th Generation of Security Devices = UTM + Routing & Switching or New Labels = Perfuming a Pig?

That's it.  I've had it.  Again.  There's no way I'd ever make it as a Marketeer.  <sigh>

I almost wasn't going to write anything about this particular topic because my response can (and probably should) easily be perceived as and retorted against as a pissy little marketing match between competitors.  Chu don't like it, Chu don't gotta read it, capice?

Sue me for telling the truth. {strike that, as someone probably will}

However, this sort of blatant exhalation of so-called revolutionary security product and architectural advances disguised as prophecy is just so, well, recockulous, that I can't stand it.

I found it funny that the Anti-Hoff (Stiennon) managed to slip another patented advertising editorial Captain Obvious press piece in SC Magazine regarding what can only be described as the natural evolution of network security products that plug into -- but are not natively -- routing or switching architectures.

I don't really mind that, but to suggest that somehow this is an original concept is just disingenuous.

Besides trying to wean Fortinet away from the classification as UTM devices (which Richard clearly hates
to be associated with) by suggesting that UTM should be renamed as "Flexible Security Platform," he does a fine job of asserting that a "geologic shift" (I can only assume he means tectonic) is coming soon in the so-called fourth generation of security products.

Of course, he's completely ignoring the fact that the solution he describes is and has already been deployed for years...but since tectonic shifts usually take millions of years to culminate in something noticeably remarkable, I can understand his confusion.

As you'll see below, calling these products "Flexible Security Platforms" or "Unified Network Platforms" is merely an arbitrary and ill-conceived hand-waving exercise in an attempt to differentiate in a crowded market.  Open source or COTS, ASIC/FPGA or multi-core Intel...that's just the packaging and delivery mechanism.  You can tart it up all you want with fancy marketing...

It's not new, it's not revolutionary (because it's already been done) and it sure as hell ain't the second coming.  I'll say it again, it's been here for years.  I personally bought it and deployed it as a customer almost 4 years ago...if you haven't figured out what I'm talking about yet, read on.

Here's how C.O. describes what the company I work for has been doing for 6 years and that he intimates Fortinet will provide that nobody else can:

We are rapidly approaching the advent of the fourth generation security platform. This is a device that can do all of the security functions that are lumped in to UTM but are also excellent network devices at layers two and three. They act as a switch and a router. They supplant traditional network devices while providing security at all levels. Their inherent architectural flexibility makes them easy to fit into existing environments and even make some things possible that were never possible before. For instance a large enterprise with several business units could deploy these advanced networking/security devices at the core and assign virtual security domains to each business unit while performing content filtering and firewalling between each virtual domain, thus segmenting the business units and maximizing the investment in core security devices.

One geologic shift that will occur thanks to the advent of these fourth generation security platforms is that networking vendors will be playing catch up, trying to patch more and more security functions into their under-powered devices or complicating their go to market message with a plethora of boxes while the security platform vendors will quickly and easily add networking functionality to their devices.

Fourth generation network security platforms will evolve beyond stand alone security appliances to encompass routing and switching as well. This new generation of devices will impact the networking industry it scrambles to acquire the expertise in security and shift their business model from commodity switching and routing to value add networking and protection capabilities.

Let's see...combine high-speed network processing whose routing/switching architecture was designed by the same engineers that designed Bay/Welfleet's core routers, add in a multi-core Intel processing/compute layer which utilizes virtualized, load-balanced security applications as a  service layer that can be overlaid across a fast, reliable, resilient and highly-available network transport and what do you get?

This:

Up to 32 GigE or 64 10/100 switching ports and 40 Intel cores in a single chassis today...and in Q3'07 you'll also have the combination of our NextGen network processors which will provide up to 8x10GigE and 40xGigE with 64 MIPS Network Security cores combined with the same 40 Intel cores in the same chassis.

By the way, I consider that routing and switching are just table stakes, not market differentiators; in products like the one to the left, this is just basic expected functionality.

Furthermore, in this so-called next generation of "security switches," the customer should be able to run both open source as well as best-in-breed COTS security applications on the platform and not constrain the user to a single vendor's version of the truth running proprietary software.

-----

But wait, it only gets better...what I found equally as hysterical is the notion that Captain Obvious now has a sidekick!  It seems Alan Shimel has signed on as Richard's Boy Wonder.  Alan's suggesting that again, the magic bullet is Cobia and that because he can run a routing daemon and his appliance has more than a couple of ports, it's a router and a switch as well as a multi-function UTM UNP swiss army knife of security & networking goodness -- and he was the first to do it!  Holy marketing-schizzle Batman! 

I don't need to re-hash this.  I blogged about it here before.

You can dress Newt Gingrich up as a chick but it doesn't mean I want to make out with him...

This is cheap, cheap, cheap marketing on both your parts and don't believe for a minute that customers don't see right through it; perfuming pigs is not revolutionary, it's called product marketing.

/Hoff

United's entire flight control network down?

I'm sitting on the tarmac at Logan in an A320.  I've been sitting here for almost an hour behind a fleet of other united planes. According to the pilot, United has experienced a system-wide computer outage that affects the navigational systems of all planes. We can't take off because the plane doesn't know where to go...and neither does the pilot. So much for triple redundancy!

Hoff

** Update: I guess he wasn't kidding!  That's realtime blogging for you folks! 

I blogged this from my phone via email whilst the failure occurred.  The good news is that the delay rippled through the entire schedule, so my connector in Denver to Oakland was also delayed, so I made the flight ;)

Here's a link from Bloomberg as an update regarding the failure:

United Air Says Computer Failure Blocked All Takeoffs (Update5)

By Susanna Ray

      June 20 (Bloomberg) -- UAL Corp.'s United Airlines, the world's second-biggest carrier, stopped all takeoffs around the globe for more than two hours today after the failure of the computer that controls flight operations.         

The outage lasted from 9 to 11 a.m. New York time, delaying about 268 flights and forcing 24 cancellations, the Chicago- based airline said. United said it was investigating and hoped to resume normal operations by tomorrow.         

United relies on the computer that broke down today for everything needed to dispatch flights, including managing crew scheduling and measuring planes' weight and balance, spokeswoman Robin Urbanski said. Federal law requires weight-and-balance assessments for passenger flights before takeoff.         

A worldwide grounding from a computer fault is ``very unusual,'' said Darryl Jenkins, an independent aviation consultant in Marshall, Virginia. ``Somewhere there was a massive failure.''         

...

Delays, Cancellations         

Delays at Chicago's O'Hare International Airport, the world's second-busiest and United's main hub, averaged one to two hours, said Wendy Abrams, a spokeswoman for the Chicago Airport System. Officials opened gates at the international terminal to unload stranded United passengers.         

United has a backup for its Unimatic system, ``and we're investigating why that didn't work,'' Urbanski said. Planes airborne during the breakdown were allowed to keep flying, she said.         

Preflight weight-and-balance checks are an important safety step. Improper loading reduces speed, efficiency, climbing rates and maneuverability, according to a Federal Aviation Administration handbook. Those changes, combined with abnormal stresses on an aircraft, can lead to crashes.         

The Unimatic system ``handles all the operational parts of the airline,'' said Rick Maloney, a former United vice president for flight operations who is now dean of the aviation college at Western Michigan University in Kalamazoo.         

`Well Protected'         

``That system is so well protected,'' Maloney said in an interview. ``I'm really pretty surprised.''         

Companywide shutdowns because of computer glitches are infrequent, said Robert Mann of R.W. Mann & Co., a Port Washington, New York-based consultant. ``But every airline has been bitten at one time or another by system failures of this sort, whether they be dispatch, departure control, passenger service, kiosks, communications, baggage or some other.''         

Today's delays will add to the industry's tardiness so far this year.         

U.S. airlines managed only 72.5 percent of flights on time this year through April, the worst rate since the federal government began keeping track in the current format in 1995, according to the U.S. Bureau of Transportation Statistics.         

Consultants including Jenkins said today's computer meltdown shouldn't damage United's long-term reputation. ``These are things that you recover from,'' he said.         

                                                                                                                                            

Take5- Five Questions for Chris Wysopal, CTO Veracode

In this first installment of Take5, I interview Chris Wysopal, the CTO of Veracode about his new company, secure coding, vulnerability research and the recent forays into application security by IBM and HP.

This entire interview was actually piped over a point-to-point TCP/IP connection using command-line redirection through netcat.  No packets were harmed during the making of this interview...

First, a little background on the victim, Chris Wysopal:

Chris Wysopal is co-founder and CTO of Veracode. He has testified on Capitol Hill on the subjects of government computer security and how vulnerabilities are discovered in software. Chris co-authored the password auditing tool L0phtCrack, wrote the windows version of netcat, and was a researcher at the security think tank, L0pht Heavy Industries, which was acquired by @stake. He was VP of R&D at @stake and later director of development at Symantec, where he led a team developing binary static analysis technology.

He was influential in the creation of responsible vulnerability disclosure guidelines and a founder of the Organization for Internet Safety.  Chris wrote "The Art of Software Security Testing: Identifying Security Flaws", published by Addison Wesley and Symantec Press in December 2006. He earned his Bachelor of Science degree in Computer and Systems Engineering from Rensselaer Polytechnic Institute.

1) You’re a founder of Veracode which is described as the industry’s first provider
of automated, on-demand application security solutions.  What sort of application
security services does Veracode provide?  Binary analysis, Web Apps?
 

Veracode currently offers binary static analysis of C/C++ applications for Windows and Solaris and for Java applications.  This allows us to find the classes of vulnerabilities that source code analysis tools can find but on the entire codebase including the libraries which you probably don't have source code for. Our product roadmap includes support for C/C++ on Linux and C# on .Net.  We will also be adding additional analysis techniques to our flagship binary static analysis.

 
2) Is this a SaaS model? How do you charge for your services?  Do you see manufacturers
using your services or enterprises?
 

Yes. Customers upload their binaries to us and we deliver an analysis of their security flaws via our web portal.  We charge by the megabyte of code.  We have both software vendors and enterprises who write or outsource their own custom software using our services.  We also have enterprises who are purchasing software ask the software vendors to submit their binaries to us for a 3rd party analysis.  They use this analysis as a factor in their purchasing decision. It can lead to a "go/no go" decision, a promise by the vendor to remediate the issues found, or a reduction in price to compensate for the cost of additional controls or the cost of incident response that insecure software necessitates.

 
3) I was a Qualys customer — a VA/VM SaaS company.  Qualys had to spend quite
a bit of time convincing customers that allowing for the storage of their VA data was
secure.  How does Veracode address a customer’s security concerns when uploading their
applications?

We are absolutely fanatical about the security of our customers data.  I look back at the days when I was a security consultant where we had vulnerability data on laptops and corporate file shares and I say, "what were we thinking?"  All customer data at Veracode is encrypted in storage and at rest with a unique key per application and customer.  Everyone at Veracode uses 2 factor authentication to log in and 2 factor is the default for customers.  Our data center is a SAS 70 Type II facility. All data access is logged so we know exactly who looked at what and when. As security people we are professionally paranoid and I think it shows through in the system we built.  We also believe in 3rd party verification so we have had a top security boutique do a security review our portal application.

 
4) With IBM’s acquisition of Watchfire and today’s announcement that HP will buy
SPI Dynamics, how does Veracode stand to play in this market of giants who will
be competing to drive service revenues?
 

We have designed our solution from the ground up to have the Web 2.0 ease of use and experience and we have the quality of analysis that I feel is the best in the market today.  An advantage is Veracode is an independent assessment company that customers can trust to not play favorites to other software companies because of partnerships or alliances. Would Moody's or Consumer Reports be trusted as a 3rd party if they were part of a big financial or technology conglomerate? We feel a 3rd party assessment is important in the security world.

 
5) Do you see the latest developments in vulnerability research with the drive for
pay-for-zeroday initiatives pressuring developers to produce secure code out of the box
for fear of exploit or is it driving the activity to companies like yours?
 

I think the real driver for developers to produce secure code and for developers and customers to seek code assessments is the reality that the costs of insecure code goes up everyday and its adding to the operational risk of companies that use software.  People exploiting vulnerabilities are not going away and there is no way to police the internet of vulnerability information.  The only solution is for customers to demand more secure code, and proof of it, and for developers to deliver more secure code in response.

I see your "More on Data Centralization" & Raise You One "Need to Conduct Business..."

Bejtlich continues to make excellent points regarding his view on centralizing data within an enterprise.  He cites the increase in litigation regarding inadequate eDiscovery investment and the increasing pressures amassed from compliance.

All good points, but I'd like to bring the discussion back to the point I was trying to make initially and here's the perfect perch from which to do it.  Richard wrote:

Christopher Christofer Hoff used the term "agile" several times in his good blog post. I think "agile" is going to be thrown out the window when corporate management is staring at $50,000 per day fines for not being able to produce relevant documents during ediscovery. When a company loses a multi-million dollar lawsuits because the judge issued an adverse inference jury instruction, I guarantee data will be centralized from then forward. "

...how about when a company loses the ability to efficiently and effectively conduct business because they spend so much money and time on "insurance policies" against which a balanced view of risk has not been applied?  Oh, wait.  That's called "information security." ;)

Fear.  Uncertainty.  Doubt.  Compliance.  Ugh.  Rinse, later, repeat.

I'm not taking what you're proposing lightly, Richard, but the notion of agility, time to market, cost transformation and enhancing customer experience are being tossed out with the bathwater here. 

Believe it or not, we have to actually have a sustainable business in order to "secure" it. 

It's fine to be advocating Google Gears and all these other Web 2.0 applications and systems. There's one force in the universe that can slap all that down, and that's corporate lawyers. If you disagree, whom do you think has a greater influence on the CEO: the CTO or the corporate lawyer? When the lawyer is backed by stories of lost cases, fines, and maybe jail time, what hope does a CTO with plans for "agility" have?

But going back to one of your own mantras, if you bake security into your processes and SDLC in the first place, then the CEO/CTO/CIO and legal counsel will already have assessed the position the company has and balance the risk scorecard to ensure that they have exercised the appropriate due care in the first place. 

The uncertainty and horrors associated with the threat of punitive legal impacts have, are, and will always be there...and they will continue to be exploited by those in the security industry to buy more stuff and justify a paycheck.

Given the business we're in, it's not a surprise that the perspective presented is very, very siloed and focused on the potential "security" outcomes of what happens if we don't start centralizing data now; everything looks like a nail when you're a hammer.

However, you still didn't address the other two critical points I made previously:

1. The underlying technology associated with decentralization of data and applications is at complete odds with the "curl up in a fetal position and wait for the sky to fall" approach
2. The only reason we have security in the first place is to ensure survivability and availability of service -- and make sure that we stay in business.  That isn't really a technical issue at all, it's a business one.  I find it interesting that you referenced this issue as the CTO's problem and not the CIO.

As to your last point, I'm convinced that GE -- with the resources, money and time it has to bear on a problem -- can centralize its data and resources...they can probably get cold fusion out of a tuna fish can and a blow pop, but for the rest of us on planet Earth, we're going to have to struggle along trying to cram all the 'agility' and enablement we've just spent the last 10 years giving to users back into the compliance bottle.

/Hoff

Off to NorCal & Utah this Week /UK & Milan, Italy next week.

I'm traveling to NorCal and Utah this week for customer visits and then off to the UK and then speak at the I4 forum in Milan, Italy.

I'll be thinking of you all over a bowl of penne and lovely Barolo.  Ciao!

If you're in the area, ping me.

/Hoff

Bye Bye, SPI (Dynamics...)

I think this one has been forecasted about eleventy-billion times already, but HP is acquiring SPI Dynamics.

I think it's clear why, and HP, just like IBM, are going to use this to drive service revenue.  I wonder when HP's acqusition of an MSSP will take place to compete with BT's efforts with Counterpane & INS, etc.?

Well, that leaves only 600+ security companies left in the security consolidation dating pool...

/Hoff

Security Application Instrumentation: Reinventing the Wheel?

Two of my favorite bloggers engaged in a trackback love-fest lately on the topic of building security into applications; specifically, enabling applications as a service delivery function to be able to innately detect, respond to and report attacks.

Richard Bejtlich wrote a piece called Security Application Instrumentation and Gunnar Peterson chimed in with Building Coordinated Response In - Learning from the Anasazis.  As usual, these are two extremely well-written pieces and arrive at a well constructed conclusion that we need a standard methodology and protocol for this reporting.  I think that this exquisitely important point will be missed by most of the security industry -- specifically vendors.

While security vendor's hearts are in the right place (stop laughing,) the "security is the center of the universe" approach to telemetry and instrumentation will continue to fall on deaf ears because there are no widely-adopted standard ways of reporting across platforms, operating systems and applications that truly integrate into a balanced scorecard/dashboard that demonstrates security's contribution to service availability across the enterprise.   I know what you're thinking..."Oh God, he's going to talk about metrics!  Ack!"  No.  That's Andy's job and he does it much better than I.

This mess is exactly why the SEIM market emerged to clean up the cesspool of log dumps that spew forth from devices that are, by all approximation, utterly unaware of the rest of ecosystem in which they participate.  Take all these crappy log dumps via Syslog and SNMP (which can still be proprietary,) normalize if possible, correlate "stuff" and communicate that something "bad" or "abnormal" has occurred.

How does that communicate what this really means to the business, its ability to function, deliver servce and ultimately the impact on risk posture?  It doesn't because security reporting is the little kid wearing a dunce hat standing in the corner because it doesn't play well with others.

Gunnar stated this well:

Coordinated detection and response is the logical conclusion to defense in depth security architecture. I think the reason that we have standards for authentication, authorization, and encryption is because these are the things that people typically focus on at design time. Monitoring and auditing are seen as runtime operational acitivities, but if there were standards based ways to communicate security information and events, then there would be an opportunity for the tooling and processes to improve, which is ultimately what we need.

So, is the call for "security application instrumentation" doomed to fail because we in the security industry will try to reinvent the wheel with proprietary solutions and suggest that the current toolsets and frameworks which are available as part of a much larger enterprise management and reporting strategy not enough? 

Bejtlich remarked on the need for mechanisms that report application state must be built into the application and must report more than just performance:

Today we need to talk about applications defending themselves. When they are under attack they need to tell us, and when they are abused, subverted, or breached they would ideally also tell us

I would like to see the next innovation be security application instrumentation, where you devise your application to report not only performance and fault logging, but also security and compliance logging. Ideally the application will be self-defending as well, perhaps offering less vulnerability exposure as attacks increase (being aware of DoS conditions of course).

I would agree, but I get the feeling that without integrating this telemetry and the output metrics and folding it into response systems whose primary role is to talk about delivery and service levels -- of which "security" is a huge factor -- the relevance of this data within the visible single pane of glass of enterprise management is lost.

So, rather than reinvent the wheel and incrementally "innovate," why don't we take something like the Open Group's Application Response Measurement (ARM) standard, make sure we subscribe to a telemetry/instrumentation format that speaks to the real issues and enable these systems to massage our output in terms of the language of business (risk?) and work to extend what is already a well-defined and accepted enterprise response management toolset to include security?

To wit:

The Application Response Measurement (ARM) standard describes a common method for integrating enterprise applications as manageable entities. The ARM standard allows users to extend their enterprise management tools directly to applications creating a comprehensive end-to-end management capability that includes measuring application availability, application performance, application usage, and end-to-end transaction response time.

Or how about something like EMC's Smarts:

Maximize availability and performance of mission-critical IT resources—and the business services they support. EMC Smarts software provides powerful solutions for managing complex infrastructures end-to-end, across technologies, and from the network to the business level. With EMC Smarts innovative technology you can:

• Model components and their relationships across networks, applications, and storage to understand effect on services.
• Analyze data from multiple sources to pinpoint root cause problems—automatically, and in real time.
• Automate discovery, modeling, analysis, workflow, and updates for dramatically lower cost of ownership.

            

...add security into these and you've got a winner.   

There are already industry standards (or at least huge market momentum) around intelligent automated IT infrastructure, resource management and service level reporting. We should get behind a standard that elevates the perspective of how security contributes to service delivery (and dare I say risk management) instead of trying to reinvent the wheel...unless you happen to like the Hamster Wheel of Pain...

/Hoff

Does Centralized Data Governance Equal Centralized Data?

I've been trying to construct a palette of blog entries over the last few months which communicates the need for a holistic network, host and data-centric approach to information security and information survivability architectures. 

I've been paying close attention to the dynamics of the DLP/CMF market/feature positioning as well as what's going on in enterprise information architecture with the continued emergence of WebX.0 and SOA.

That's why I found this Computerworld article written by Jay Cline very interesting as it focused on the need for a centralized data governance function within an organization in order to manage risk associated with coping with the information management lifecycle (which includes security and survivability.)  The article went on to also discuss how the roles within the organization, namely the CIO/CTO, will also evolve in parallel.

The three primary indicators for this evolution were summarized as:

1. Convergence of information risk functions
2. Escalating risk of information compliance
3. Fundamental role of information.

Nothing terribly earth-shattering here, but the exclamation point of this article to enable a
centralized data governance  organization is a (gasp!) tricky combination of people, process
and technology:

"How does this all add up? Let me connect the dots: Data must soon become centralized,
its use must be strictly controlled within legal parameters, and information must drive the
business model. Companies that don’t put a single, C-level person in charge of making
this happen will face two brutal realities: lawsuits driving up costs and eroding trust in the
company, and competitive upstarts stealing revenues through more nimble use of centralized
information."

Let's deconstruct this a little because I totally get the essence of what is proposed, but
there's the insertion of some realities that must be discussed.  Working backwards:

• I agree that data and it's use must be strictly controlled within legal parameters.
• I agree that a single, C-level person needs to be accountable for the data lifecycle
• However, I think that whilst I don't disagree that it would be fantastic to centralize data,
  I think it's a nice theory but the wrong universe. 

Interesting, Richard Bejtlich focused his response to the article on this very notion, but I can't get past a couple of issues, some of them technical and some of them business-related.

There's a confusing mish-mash alluded to in Richard's blog of "second home" data repositories that maintain copies of data that somehow also magically enforce data control and protection schemes outside of this repository while simultaneously allowing the flexibility of data creation "locally."  The competing themes for me is that centralization of data is really irrelevant -- it's convenient -- but what you really need is the (and you'll excuse the lazy use of a politically-charged term) "DRM" functionality to work irrespective of where it's created, stored, or used.

Centralized storage is good (and selfishly so for someone like Richard) for performing forensics and auditing, but it's not necessarily technically or fiscally efficient and doesn't necessarily align to an agile business model.

The timeframe for the evolution of this data centralization was not really established,
but we don't have the most difficult part licked yet -- the application of either the accompanying
metadata describing the information assets we wish to protect OR the ability to uniformly classify and
enforce it's creation, distribution, utilization and destruction.

Now we're supposed to also be able to magically centralize all our data, too?  I know that large organizations have embraced the notion of data warehousing, but it's not the underlying data stores I'm truly worried about, it's the combination of data from multiple silos within the data warehouses that concerns me and its distribution to multi-dimensional analytic consumers. 

You may be able to protect a DB's table, row, column or a file, but how do you apply a policy to a distributed ETL function across multiple datasets and paths?

ATAMO?  (And Then A Miracle Occurs) 

What I find intriguing about this article is that this so-described pendulum effect of data centralization (data warehousing, BI/DI) and resource centralization (data center virtualization, WAN optimization/caching, thin client computing) seem to be on a direct  collision course with the way in which applications and data are being distributed with  Web2.0/Service Oriented architectures and delivery underpinnings such as rich(er) client side technologies such as mash-ups and AJAX...

So what I don't get is how one balances centralizing data when today's emerging infrastructure
and information architectures are constructed to do just the opposite; distribute data, processing
and data re-use/transformation across the Enterprise?  We've already let the data genie out of the bottle and now we're trying to cram it back in?  (*please see below for a perfect illustration)

I ask this again within the scope of deploying a centralized data governance organization and its associated technology and processes within an agile business environment. 

/Hoff

P.S. I expect that a certain analyst friend of mine will be emailing me in T-Minus 10, 9...

*Here's a perfect illustration of the futility of centrally storing "data."  Click on the image and notice the second bullet item...:

Really, There's More to Security than Admission/Access Control...

Dr. Joseph Tardo over at the Nevis Networks Illuminations blog composed a reasonably well-balanced commentary regarding one or more of my posts in which I was waxing on philosophically about about my beliefs regarding keeping the network plumbing dumb and overlaying security as a flexible, agile, open and extensible services layer.

It's clear he doesn't think this way, but I welcome the discourse.  So let me make something clear:

Realistically, and especially in non-segmented flat networks, I think there are certain low-level security functions that will do well by being served up by switching infrastructure as security functionality commoditizes, but I'm not quite sure for the most part how or where yet I draw the line between utility and intelligence.  I do, however, think that NAC is one of those utility services.

I'm also unconvinced that access-grade, wiring closet switches are architected to scale in either functionality, efficacy or performance to provide any more value or differentiation other than port density than the normal bolt-on appliances which continue to cause massive operational and capital expenditure due to continued forklifts over time.  Companies like Nevis and Consentry quietly admit this too, which is why they have both "secure switches" AND appliances that sit on top of the network...

Joseph suggested he was entering into a religious battle in which he summarized many of the approaches to security that I have blogged about previously and I pointed out to him on his blog that this is exactly why I practice polytheism ;) :

In case you aren’t following the religious wars going on in the security blogs and elsewhere, let me bring you up to date.

It goes like this. If you are in the client software business, then security has to be done in the endpoints and the network is just dumb “plumbing,” or rather, it might as well be because you can’t assume anything about it. If you sell appliances that sit here and there in the network, the network sprouts two layers, with the “plumbing” part separated from the “intelligence.” Makes sense, I guess. But if you sell switches and routers then the intelligence must be integrated in with the infrastructure. Now I get it. Or maybe I’m missing the point, what if you sell both appliances and infrastructure?

I believe that we're currently forced to deploy in defense in depth due to the shortcomings of solutions today.  I believe the "network" will not and cannot deliver all the security required.  I believe we're going to have to invest more in secure operating systems and protocols.  I further believe that we need to be data-centric in our application of security.  I do not believe in single-point product "appliances" that are fundamentally functionally handicapped.  As a delivery mechanism to deliver security that matters across network I believe in this.

Again, the most important difference between what I believe and what Joseph points out above is that the normal class of "appliances" he's trying to suggest I advocate simply aren't what I advocate at all.  In fact, one might surprisingly confuse the solutions I do support as "infrastructure" -- they look like high-powered switches with a virtualized blade architecture integrated into the solution.

It's not an access switch, it's not a single function appliance and it's not a blade server and it doesn't suffer from the closed proprietary single vendor's version of the truth.  To answer the question, if you sell and expect to produce both secure appliances and infrastructure, one of them will come up short.   There are alternatives, however.

So why leave your endpoints, the ones that have all those vulnerabilities that created the security industry in the first place, to be hit on by bots, “guests,” and anyone else that wants to? I don’t know about you, but I would want both something on the endpoint, knowing it won’t be 100% but better than nothing, and also something in the network to stop the nasty stuff, preferably before it even got in.

I have nothing to disagree with in the paragraph above -- short of the example of mixing active network defense with admission/access control in the same sentence; I think that's confusing two points.   Back to the religious debate as Joseph drops back to the "Nevis is going to replace all switches in the wiring closet" approach to security via network admission/access control:

Now, let’s talk about getting on the network. If the switches are just dumb plumbing they will blindly let anyone on, friend or foe, so you at least need to beef up the dumb plumbing with admission enforcement points. And you want to put malware sensors where they can be effective, ideally close to entry points, to minimize the risk of having the network infrastructure taken down. So, where do you want to put the intelligence, close to the entry enforcement points or someplace further in the bowels of the network where the dumb plumbing might have plugged-and-played a path around your expensive intelligent appliance?

That really depends upon what you're trying to protect; the end point, the network or the resources connected to it.  Also, I won't/can't argue about wanting to apply access/filtering (sounds like IPS in the above example) controls closest to the client at the network layer.  Good design philosophy.   However, depending upon how segmented your network is, the types, value and criticality of the hosts in these virtual/physical domains, one may choose to isolate by zone or VLAN and not invest in yet another switch replacement at the access layer.

If the appliance is to be effective, it has to sit at a choke point and really be and enforcement point. And it has to have some smarts of its own. Like the secure switch that we make.

Again, that depends upon your definition of enforcement and applicability.  I'd agree that in flat networks, you'd like to do it at the port/host level, though replacing access switches to do so is usually not feasible in large networks given investments in switching architectures.  Typical fixed configuration appliances overlaid don't scale, either.

Furthermore, depending upon your definition of what an enforcement zone and it's corresponding diameter is (port, VLAN, IP Subnet) you may not care.  So putting that "appliance" in place may not be as foreboding as you wager, especially if it overlays across these boundaries satisfactorily.

We will see how long before these new-fangled switch vendors that used to be SSL VPN's, that then became IPS appliances that have now "evolved" into NAC solutions, will become whatever the next buzzword/technology of tomorrow represents...especially now with Cisco's revitalized technology refresh for "secure" access switches in the wiring closets.  Caymas, Array, and Vernier (amongst many) are perfect examples.

When it comes down to it, in the markets Crossbeam serves -- and especially the largest enterprises -- they are happy with their switches, they just want the best security choice on top of it provided in a consolidated, agile and scalable architecture to support it.

Amen.

/Hoff

Rothman Speaks!

...You need Flash to see this...

Firefox also seems to have intermittent trouble rendering this.

If you only see 1/2 of Mr. Rothman, right-click and select "show all"
and then click on the little purple play icon.  IE has no issue.

Turn the volume WAY up...I had to whisper this @ work.

/Hoff

McAfee's Bolin suggests Virtual "Sentinel" Security Model for Uncompromised Security

Christopher Bolin, McAfee's EVP & CTO blogged an interesting perspective on utilizing virtualization technology to instantiate security functionality in an accompanying VM on a host to protect one or more VM's on the same host.  This approach differs than the standard approach of placing host-based security controls on each VM or the intra-VS IPS models from companies such as Reflex (blogged about that here.)

I want to flush out some of these concepts with a little more meat attached

He defines the concept of running security software alongside the operating system it is protecting as "the sentinel":

In this approach, the security software itself resides in its own virtual machine outside and parallel to the system it is meant to protect, which could be another virtual machine running an operating system such as Windows. This enables the security technology to look omnisciently into the subject OS and its operation and take appropriate action when malware or anomalous behavior is detected.

Understood so far...with some caveats, below.

The security software would run in an uncompromised environment monitoring in real-time, and could avoid being disabled, detected or deceived (or make the bad guys work a lot harder.)

While this supposedly uncompromised/uncompromisable OS could exist, how are you going to ensure that the underlying "routing" traffic flow control actually forces the traffic through the Sentinel VM in the first place? If the house of cards rests on this design element, we'll be waiting a while...and adding latency.  See below.

This kind of security is not necessarily a one-to-one relationship between sentinel and OSs. One physical machine can run several virtual machines, so one virtual sentinel could watch and service many virtual machines.

I think this is a potentially valid and interesting alternative to deploying more and more host-based security products (which seems odd coming from McAfee) or additional physical appliances, but there are a couple of issues with this premise, some of which Bolin points out, others I'll focus on here:

1. Unlike other applications which run in a VM and just require a TCP/IP stack, security applications are extremely topology sensitive.  The ability to integrate sentinels in a VM environment with other applications/VM's at layer 2 is extremely difficult, especially if these security applications are to act "in-line." 
   
   Virtualizing transport while maintaining topology context is difficult and when you need to then virtualize the policies based upon this topology, it gets worse.  Blade servers have this problem; they have integrated basic switch/load balancing modules, but implementing policy-driven "serialization" and "parallelization" (which is what we call it @ Crossbeam) is very, very hard.



2. The notion that the sentinel can "...look omnisciently into the subject OS and its operation and take appropriate action when malware or anomalous behavior is detected" from a network perspective is confusing.  If you're outside the VM/Hypervisor, I don't understand the feasibility of this approach.  This is where Blue Lane's VirtualShiel ESX plug-in kicks ass -- it plugs into the Hypervisor and protects not only directed traffic to the VM but also intra-VM traffic with behavioral detection, not just signatures.
   
   
3. Resource allocation of the sentinel security control as a VM poses a threat vector inasmuch as one could overwhelm/DoS the Sentinel VM and security/availability of the entire system could be compromised; the controls protecting the VMs are competing for the same virtualized resources that the resources are after.
   
   
4. As Bolin rightfully suggests, a vulnerability in the VM/VMM/Chipsets could introduce a serious set of modeling problems.

I maintain that securing virtualization by virtualizing security is nascent at best, but as Bolin rightfully demonstrates, there are many innovative approaches being discussed to address these new technologies.

/Hoff

CSI Working Group on Web Security Reseach Law Concludes...Nothing

In May I blogged what I thought was an interesting question regarding the legality and liability of reverse engineering in security vulnerability research.  That discussion focused on the reverse engineering and vulnerability research of hardware and software products that were performed locally.

I continued with a follow-on discussion and extended the topic to include security vulnerability research from the web-based perspective in which I was interested to see how different the opinions on the legality and liability were from many of the top security researchers as it relates to the local versus remote vulnerability research and disclosure perspectives.

As part of the last post, I made reference to a working group organized by CSI whose focus and charter were to discuss web security research law.  This group is made up of some really smart people and I was looking forward to the conclusions reached by them on the topic and what might be done to potentially solve the obvious mounting problems associated with vulnerability research and disclosure.

The first report of this group was published yesterday. 

Unfortunately, the conclusions of the working group is an inditement of the sad state of affairs related to the security space and further underscores the sense of utter hopelessness many in the security community experience.

What the group concluded after 14 extremely interesting and well-written pages was absolutely nothing:

The meeting of minds that took place over the past two months advanced the group's collective knowledge on the issue of Web security research law.  Yet if one assumed that the discussion advanced the group's collective understanding of this issue, one might be mistaken.

Informative though the work was, it raised more questions than answers.  In the pursuit of clarity, we found, instead, turbidity.

Thus it follows, that there are many opportunities for further thought, further discussion, further research and further stirring up of murky depths.  In the short term, the working group has plans to pursue the following endeavors:

• Creating disclosure policy guidelines -- both to help site owners write disclosure policies, and for security researchers to understand them.
• Creating guidelines for creating a "dummy" site.
• Creating a more complete matrix of Web vulnerability research methods, written with the purpose of helping attorneys, lawmakers and law enforcement officers understand the varying degrees of invasiveness

Jeremiah Grossman, a friend and one of the working group members summarized the report and concluded with the following: "...maybe within the next 3-5 years as more incidents like TJX occur, we’ll have both remedies."  Swell.

Please don't misunderstand my cynical tone and disappointment as a reflection on any of the folks who participated in this working group -- many of whom I know and respect.  It is, however, sadly another example of the hamster wheel of pain we're all on when the best and brightest we have can't draw meaningful conclusions against issues such as this.

I was really hoping we'd be further down the path towards getting our arms around the problem so we could present meaningful solutions that would make a dent in the space.  Unfortunately, I think where we are is the collective shoulder shrug shrine of cynicism perched periously on the cliff overlooking the chasm of despair which drops off into the trough of disillusionment.

Gartner needs a magic quadrant for hopelessness. <sigh>  I feel better now, thanks.

/Hoff

Evan Kaplan and Co. (Aventail) Take the Next Step

So Aventail's being acquired by SonicWall?  I wish Evan Kaplan and his team well and trust that SonicWall will do their best to integrate the best of Aventail's technology into their own.  It's interesting that this news pops up today because I was just thinking about Aventail's CEO today as part of a retrospective of security over the last 10+ years.

I've always admired Evan Kaplan's messaging from afar and a couple of months ago I got to speak with him for an hour or so.  For someone who has put his stake in the ground the ground for last 11 years as a leader in the SSL VPN market, you might be surprised to know that Evan's perspective on the world of networking and security isn't limited to "tunnel vision" as one might expect.

One of my favorite examples of Evan's beliefs is this article in Network World back in 2005 that resonated so very much with me then and still does today.  The title of the piece is "Smart Networks are Not a Good Investment" and was a "face off" feature between Evan and Cisco's Rob Redford.

Evan's point here -- and what resonates at the core of what I believe should happen to security -- is that the "network" ought to be separated into two strata, the "plumbing" (routers, switches, etc.) and intelligent "service layers" (security being one of them.)

Evan calls these layers "connectivity" and "intelligence."

The plumbing should be fast, resilient, reliable, and robust providing the connectivity and the service layers should be agile, open, interoperable, flexible and focused on delivering service as a core competency.   

Networking vendors who want to leverage the footprint they already have in port density and extend their stranglehold single vendor version of the truth obviously disagree with this approach.  So do those who ultimately suggest that "good enough" is good enough.

Evan bangs the drum:

Network intelligence as promoted by the large network vendors is the Star Wars defense system of our time - monolithic, vulnerable and inherently unreliable. Proponents of smart networks want to extend their hegemony by incorporating application performance and security into a unified, super-intelligent infrastructure. They want to integrate everything into the network and embed security into every node. In theory, you would then have centralized control and strong perimeter defense.

Yup.  As I blogged recently, "Network Intelligence is an Oxymoron."  The port puppets will have you believe that you can put all this intelligence in the routers in switches and solve all the problems these platforms were never designed to solve whilst simultaneously scale performance and features against skyrocketing throughput requirements, extreme latency thresholds, emerging technologies and an avalanche of compounding threats and vulnerabilities...all from one vendor, of course.

While on the surface this sounds reasonable, a deeper look reveals that this kind of approach presents significant risk for users and service providers. It runs counter to the clear trends in network communication, such as today's radical growth in broadband and wireless networks , and increased virtualization of corporate networks through use of public infrastructure. As a result of these trends, much network traffic is accessing corporate data centers from public networks rather than the private LAN, and the boundaries of the enterprise are expanding. Companies must grow by embracing these trends and fully leveraging public infrastructure and the power of the Internet.

Exactly.  Look at BT's 21CN network architecture as a clear and unequivocal demonstration of this strategy; a fantastic high-performance, resilient and reliable foundational transport coupled with an open, agile, flexible and equally high-performance and scalable security service layer.  If BT is putting 18 billion pounds of their money investing in a strategy like this and don't reckon they can rely on "embedded" security, why would you?

Network vendors are right in recognizing and trying to address the two fundamental challenges of network communications: application performance and security. However, they are wrong in believing the best way to address these concerns is to integrate application performance and security into the underlying network.

The alternative is to avoid building increasing intelligence into the physical network, which I call the connectivity lane, and building it instead into a higher-level plane I call the intelligence plane.                      

The connectivity plane covers end-to-end network connectivity in its broadest sense, leveraging IPv4 and eventually IPv6 . This plane's characteristics are packet-level performance and high availability. It is inherently insecure but incredibly resilient. The connectivity plane should be kept highly controlled and standardized, because it is heavy to manage and expensive to build and update. It should also be kept dumb, with change happening slowly.

He's on the money here again.  Let the network evolve at its pace using standards-based technology and allow innovation to deliver service at the higher levels.  The network evolves much more slowly and at a pace that demands stability.  The experientially-focused intelligence layer needs to be much more nimble and agile, taking advantage of the opportunism and the requirements to respond to rapidly emerging technologies and threat/vulnerabilities.

Look at how quickly solutions like DLP and NAC have stormed onto the market.  If we had to wait for Cisco to get their butt in gear and deliver solutions that actually work as an embedded function within the "network," we'd be out of business by now.

I don't have the time to write it again, but the security implications of having the fox guarding the henhouse by embedding security into the "fabric" is scary.  Just look at the number of security vulnerabilities Cisco has had in their routing, switching, and security products in the last 6 months.  Guess what happens when they're all one?   I sum it up here and here as examples.

Conversely, the intelligence plane is application centric and policy driven, and is an overlay to the connectivity plane. The intelligence plane is where you build relationships, security and policy, because it is flexible and cost effective. This plane is network independent, multi-vendor and adaptive, delivering applications and performance across a variety of environments, systems, users and devices. The intelligence plane allows you to extend the enterprise boundary using readily available public infrastructure. Many service and product vendors offer products that address the core issues of security and performance on the intelligence plane.

Connectivity vendors should focus their efforts on building faster, easier to manage and more reliable networks. Smart networks are good for vendors, not customers.

Wiser words have not been spoken...except by me agreeing with them, of course ;)  Not too shabby for an SSL VPN vendor way back in 2005.

Evan, I do hope you won't disappear and will continue to be an outspoken advocate of flushing the plumbing...best of luck to you and your team as you integrate into SonicWall.

/Hoff

Congratulations to Richard Bejtlich - Good for him, bad for us...

Congratulations go to Richard Bejtlich as he accepts a position as GE's Director of Incident Response.  It's a bittersweet moment as while GE gains an amazing new employee, the public loses one of our best champions, a fantastic teacher, a great wealth of monitoring Tao knowledge and a prolific blogger.

While I am sure Richard won't stop all elements of what he does, he's going to have his hands full.  I always privately wondered how he maintained that schedule.  Mine is crazy, his is pure lunacy.

I am grateful that I'm scheduled to attend one of Richard's last classes -- the TCP/IP Weapons School @ Blackhat.  I've attended Richard's classes before and they are excellent.  Get 'em while you still can.

Again, congratulations, Richard.

/Hoff