January 11, 2009

It is my pleasure to introduce the fruits of the labor of months minutes of diligent research and engineering prowess -- my opus magnum -- the next generation of Cloud Computing. Pending standards-body approval shortly:

I'm looking for extensive peer review prior to standards body submission. Open source also considered. Please ensure you comment below in order to ensure transparency. There are no ivory towers here, flame away (although you might want to open the window first.)

December 29, 2008

UPDATE: HA! So I was *so* close to the real thing! Turns out that instead of 240 Nintendo DS Lites, they used 200 clustered Sony PS III's! I actually guessed that in an email to Sotirov, too! I can't believe you people doubted me!

I initially thought they used the go-kart crashes in Super Mario brothers to emulate MD5 "collisions."

There's a summary of their presentation abstract posted via the link above, but the juicy parts are redacted, hiding the true nature of the crippling effects of the 'sploit about to be released upon the world:

I have a Beowulf cluster of 240 Nintendo DS Lite's running in my basement and harnessing the capabilities thereof was able to apply my custom-written graphical binary isomorphic differ algorithm using neural networking based self-organizing maps and reverse steganography to deduce the obscured content.

I don't wish to be held liable for releasing the content of this prior to their presentation nor do I wish to be pursued for any fair use violations, so I'm hosting the results off shore.

Please click here for the non-redacted image hosted via a mirror site that reveals the content of the abstract.

December 18, 2008

Here's the premise that will change the face of network security, compliance, SIEM and IDP forever:

Twitter as a human-powered SIEM and IPS for correlation

This started as a joke I made on Twitter a few weeks ago, but given the astounding popularity of Cloud-based zaniness currently, I'm going open source with my idea and monetize it in the form of a new startup called CloudCorrelator™.

Here's how it works:

You configure all your network devices and your management consoles (aggregated or not) to point to a virtual machine that you install somewhere in your infrastructure. It's OVF compliant, so it will work with pretty much any platform.

This VM accepts Syslog, SNMP, raw log formats, and/or XML and will take your streamed message bus inputs, package them up, encrypt them into something we call the SlipStream™, and forward them off to...

...the fantastic cloud-based service called CloudCorrelator™ (running on the ever-popular AWS platform) which normalizes the alerts and correlates them as any SIEM platform does providing all the normal features you'd expect, but in the cloud where storage, availability, security and infinite expandability is guaranteed! The CloudCorrelator™ is open source, of course.

This is where it gets fun...

Based upon your policies the CloudCorrelator™ sanitizes your SlipStream™ feed and using the Twitter API will allow Twitter followers to cross-correlate seemingly random events globally, using actual human eyeballs to provide the heuristics and fuzzy logic analysis across domains.

Why bother sending your SlipStream™ to Twitter? Well, firstly you can use existing search tools to determine if anyone else is seeing similar traffic patterns across diverse networks. Take TwitterSearch for example. Better yet, use the TweetStat Cloud to map relevant cross-pollination of events.

December 15, 2008

Besides the sumo suit wrestling match I'm organizing between myself and Simon Crosby at this year's coming RSA 2009 show, I'm really excited to announce that there will be another exciting virtualization security (VirtSec) event happening at the show.

Thanks to Tim Mather at RSA, much scheming and planning has paid off:

"In this verbal cage match session, two well known critics of virtualization security take on two virtualization company CTOs as they spar over how best to secure virtualization platforms: who should be responsible for securing it, and how that ultimately impacts customers and attackers. We have Hoff and Skoudis versus Crosby and Herrod. Refereeing will be respected analyst, Antonopoulos."

Simon Crosby (Citrix CTO), Steve Herrod (VMware CTO), Ed Skoudis (InGuardians) and myself will have a lively debate moderated by Andreas Antonopoulos (Nemertes) that is sure to entertain and educate folks as to the many fascinating issues surrounding the present and future of VirtSec. I expect to push the discussion toward cloud security also...

Since I have spent the better part of my security career building large "cloud-like" services and the products that help, at a minimum, to secure them, I feel at least slightly qualified to dispute many of his points, the bulk of which are really focused on purely technology-driven mechanical analogies and platforms rather than items such as the operational, trust, political, jurisdictional, regulatory, organizational and economical issues that really go toward the "security" (or lack thereof) of "cloud-based" service.

Speaking of which, PDP's definition of the cloud is about as abstract as you can get:

"Cloud technologies are in fact no different than non-cloud technologies. Practically they are the same. I mean the term cloud computing
is quite broad and perhaps it is even a buzword rather than a
well-thought term which describes a particular study of the IT field.
To me cloud computing refers to the process of outsourcing computer cycles and memory keeping scalability in mind."

Well, I'm glad we cleared that up.

At any rate, it's a seriously humorous read that would have me taking apart many of his contradictory assumptions and assertions were it not for the fact that I have actual work to do. So, in the issue of time, I'll offer up his conclusion and you can go back and read the rest:

So, is the cloud secure? I would say yes if you know what you are
doing. A couple of posts back I mentioned that cloud security matters.
It still does. Cloud technologies are quite secure because we tend not
to trust them. However, because cloud computing can be quite confusing,
you still need to spend time in making sure that all the blocks fit
together nicely.

So, there you have it. Those of you who "know what you are doing" are otay and thanks to security by obscurity due to a lack of trust, cloud computing is secure. That's not confusing at all...

November 20, 2008

The fine folks at NASA, with notable contributors such as the Internet's baby-daddy Vint Cerf, have been bit twiddling a new communications protocol this month that has been in the works since 1998. The "launch" of Delay/Disruption Tolerant Networking protocol is currently being field tested on the comet-seeking EPOXI spacecraft.

While TCP/IP has generally worked well beyond its initial design requirements as the terrestrial Internet has scaled unimaginably, it doesn't work so well in interplanetary deep space.

This month, NASA began testing a new protocol
for communications in outer space that could extend the reliability and
versatility of the Internet out of the Earth's atmosphere. The new
protocol, called Disruption-Tolerant Networking, or DTN, has been in
the works for ten years, passed a month of testing with a just-launched
spacecraft and nine ground stations, but is still scheduled to undergo
further tests. ...Communicating in interplanetary space is hard. While even the most
remote regions of the earth can be reached by lightspeed communications
in a modest fraction of a second, and voice conversations from the
earth to the moon can be carried out with only a barely noticeable
delay, several light minutes separate planets even at their closest
approaches. Back-and-forth negotiation isn't feasible, and the cost of
starting processes from scratch are high. Furthermore, disruptions of
communication are numerous and routine. Satellites and planetary
probes have much less power when they're out of the sun, line of sight
must be maintained, dishes properly aimed, etc. Solar flares and other
environmental factors can shut communications channels unexpectedly.

Under the new DTN protocol, nodes retain data in their own memory until
they receive confirmation the data has been received by a suitable
target node. This increases the likelihood that data will arrive at its
destination with a minimum of back-and-forth, communication even when
communication is intermittent or unreliable.

I wonder if it's IPv6 compatible? After we assign a DTN/IP-Address to Internet-enable each celestial body, we'll be out of addresses again!

BTW, I happen to have access to a DTN-enabled uplink which proxy relays my TCP/IP to DTN through the EPOXI spacecraft. Check out the round-trip times on this badboy:

I am interested in understanding if there are any additional security
mechanisms built into DTN as it would be a shame if an advanced alien
race could perform an interplanetary MITM on our transmissions:
"...this is not the planet you are looking for..."

October 31, 2008

I was reading an article on SlashFood titled "Drinking Straw: Friend or Foe" and chuckled at the parallels to the reflexive hyping, purchase and (oft failed) use of "solutions" in the security space. Sometimes I think we need a securitysnopes.com:

Recently, a friend passed along a tip from a dermatologist: Stop
sipping through straws. The doctor said it was the number one cause of
wrinkles.

Even more recently, at lunch one day my aunt relayed
some info from her husband, an orthodontist. He said that drinking
through a straw prevents cavities and tooth decay, since straws allow
sugary beverages to bypass your teeth. When my aunt said this,
everybody around the table (six women) stuck straws in their drinks.

But when I countered with the skincare side of the question, my aunt
was the first to pluck her straw right back out again.

October 21, 2008

While I like the science of quantum cryptography -- my undergraduate
degree was in physics -- I don't see any commercial value in it. I
don't believe it solves any security problem that needs solving. I
don't believe that it's worth paying for, and I can't imagine anyone
but a few technophiles buying and deploying it. Systems that use it
don't magically become unbreakable, because the quantum part doesn't
address the weak points of the system.

No commercial value? Doesn't solve any security problem that needs solving? Isn't worth paying for? Only a few folks buying and deploying it!?

Hell, I'm writing a business plan right now and going for VC funding! This is obviously the next big thing! After all, this is mantra that the entire security industry is predicated upon.

October 18, 2008

Look, I love my brother from a different mother, and as entertaining as I find Amrit's latest blog on the end of the world due to the world economic malaise, I can't help but remember the last time this happened at the end of the dot-com bubble.

You might say that it's never been this bad. You might be right. However, we've all weathered storms before and while things certainly change -- and not always for the best -- security will survive. It may look a little different, however. Meh.

As I have both said and experienced previously, situations such as this will deliver new regulations and oversight, more compliance requirements, stretched/reduced budgets and a streamlining in role, process, function and technology. It's the flatlining function in the pulse before the CPR kicks in.

Amrit's predictions are interesting, but all of these things were happening well BEFORE the financial crisis hit as part of the normal cycle of punctuated equilibrium. Seriously, we've seen this behavior for the last four years already.* To paraphrase Amrit's "predictions:"

Companies will move more functions/services to outsourced partners and grapple with SLA, ownership and portability issues.

Vendors will quickly grasp at the latest buzzword in order to maintain relevance such as virtualization, SaaS, Cloud, etc.

So again, which of these weren't already happening?

Times are tough. So are we.

See you Monday.

/Hoff

P.S. Buried in the comments is the most profound point I have to make in response to Amrit:

You know how I know this isn't the end of the [security] world? You [Amrit] and I -- people who make a career by squawking on blogs -- still have jobs

* To make it clear, because I've obviously done a poor job understanding Amrit's points, I'm not suggesting that the impacts of the last few months aren't taking a toll. I'm suggesting, however, that the crisis(es) are acting as an accelerant delivering more quickly the outcomes of things already in motion. Further, as I mentioned in the comments, while innovation is certainly delivered from the tech. startup community, it's also driven from corporations when necessity pushes for innovation and innovative solutions even due to reasons like cost control...

September 03, 2008

Sick of it. Sucks monkey balls. Is about as relevant and non-sensical to me as "kosher ham."

I've been really annoyed by this term since I ashamedly added it to my lexicon of "roll-off-the-tip-of-my-tongue" buzzwords years ago for reasons I can't rightly remember. Too much TV.

I suppose temporally, anything not shipping, regardless of how (r)evolutionary it may or may not be, is technically "next generation," but it's today overly (ab)used to imply some quantum leap in capability, functionality, or saleability. Oh, and one usually has to pay more for it.

The truth is -- and as I pointed out in my disruptive innovation presentations -- there just aren't that many "big bangs" that deserve to have this moniker hung upon the mantle, but rather a series of dampened oscillations due to punctuated equilibrium until everything settles down and looks pretty much the same.

Then version 1.17 ships and BAM! Next generation, baby!

To all you product managers and marketers, "next generation" is so over-played at this point that the populous at large simply regards it like the features lists plastered on the trunk lids of automobiles advertising the niftiest new (but abundantly standard) set of features purchased on the luxo-barge meandering about in the lane ahead.

Whilst I am happy to know that Bob got the GLX, limited edition, R-Series with ABS, sunroof, intercooled turbo with XM radio and AWD, the suggestion that his "seats 8 but still makes him look like a dork" mini-van is a "next generation" platform doesn't really say much about Bob, now does it?

--

On the flip side, I'm just thrilled to learn via press release today that "Secure Computing [is] to acquire Securify to drive [its] next generation firewalls" which oddly enough includes a list of features that are aimed squarely at competing with folks like Palo Alto Networks'* "next generation" firewalls which were released sometime ago.

Further, someone at PAN and Secure Computing will undoubtedly be shocked to learn that Crossbeam, Fortinet, and Cisco all have "next generation firewalls" too. Crap! What comes after "next generation?"

I suppose whatever it is would have to be made of pure unobtanium...

I knew I should have trademarked that...

/Hoff

* Speaking of Palo Alto Networks, you may have missed that a couple of weeks ago, PAN secured a C-Round of $27M. That ought to be good for a couple more 'next generations' of something...they also finally got a new CEO back in July (Lane Bess from Trend Micro.)

The gist of this story is that by utilizing the built-in friendliness of BGP, you can cause bad things™ to happen by redirecting, intercepting and then sending traffic back on its way with a high likelihood of not being detected.

"We're not doing anything out of the ordinary," Kapela told Wired.com.
"There's no vulnerabilities, no protocol errors, there are no software
problems. The problem arises (from) the level of interconnectivity
that's needed to maintain this mess, to keep it all working."

It's another case of "everyone knows this can (and probably does) happen, but we're just hoping it doesn't," and very smart people have been warning others about this for years. You shouldn't drink the water overseas, either.

Even as recently as the YouTube/Pakistan issue which was a BGP-related issue that caused a DoS, not-so-smart people such as your humble author suggested exactly this sort of thing was possible:

Yes, this is really a demonstration of unavailability, but
what I'm getting at here is that fundamentally, the core routing
protocol we depend upon for the backbone Internet transport is roughly
governed by the same rules that we depend upon whilst driving down a
road separated by nothing more than painted lines...you simply
hope/trust that nobody crosses the line and crashes into you head-on.

There is very little preventing someone from re-routing traffic.
This could result in either a denial of service (as the traffic would
not reach its destination) or even something akin to an interception,
"storage" and eventual forwarding for nefarious means.

So, here we have a case where again we depend upon a protocol that
was designed to provide (A)vailability, yet C and I are left
floundering in the wings. We'll no doubt see another round of folks
who will try and evangelize the need for secure BGP -- just like secure
DNS, secure SMTP, secure...

This will hit deaf ears until we see the same thing happen again...

Ooooh. I must be psychic.

Wait until I demonstrate how to redirect the NetBIOS traffic of every Win2K/XP box that has NBT bound to the NICs by a cleverly devious combination of ICMP source quench, token ring beacons and uPnP.

I wanted to both reflect upon Iben's comment as well as chuckle a bit.

From what I extracted from his comment, Iben is suggesting that perhaps virtualization should not affect an auditor's approach or differentiate the audit process from a physical server depending upon the definition of a "server:"

Is an ESX Host a server?

It should be considered similar to the chassis holding a bunch of blade servers.

These have management ports on separate networks, with LDAP authentication over security protocols like ssh and ssl.

And why not treat them as a hybrid device with different network switches, storage controllers, etc?

Vmware has recently removed the word "Server" from after the ESX product name...

It's not a server, it's a hypervisor.

It's not a server, it's a switch.

By defining what a server is and is not a PCI Audit should be pretty straight forward.

I think this is a messy question and one we ought to continue to address. I need to go and check out my ISACA references to seek guidance on this matter from a, um, "higher" source ;) I do think that ultimately this is a very subjective issue, to which I responded:

The answers to your questions/suppositions are quite simple:

"It all depends upon the auditor."

Most of the folks I've spoken to recently are essentially counting
upon the ignorance of the auditors and the general confusion regarding
terminology and technology to glide by at this point.

Server/blade/hypervisor/switch ... it's all fun and games until someone loses a (PC)I... ;)

"As long as I put in place the same host controls I do in a physical
environment and not tell the auditor it's virtualized, it's all good
and what they don't know, won't hurt me."

Sad but true.

I find this practice/observation to be more and more common as the push to virtualize all infrastructure -- including externally-facing DMZ's -- starts to become more visible in the compliance and audit spaces.

Per the article above "Now he's one of the first victims of such an attack. "It's funny," he said. "I got owned."*

Yeah, real funny.

/Hoff

* There's lots of thrashing going on as to the veracity of HD's quote rearding being owned. Regardless of the theatrics involved, it's interesting food for thought when the result of exploit research might be turned against the researcher...