Archive

Author Archive

The Most Overused Term In Security Product Management/Marketing…

September 3rd, 2008 6 comments

Uniqueforks
Next Generation <anything>

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

Categories: Jackassery Tags:

Google’s Chrome: We Got {Secure?} Browsing Bling, Yo.

September 1st, 2008 No comments

Googlebling
From the Department of "Oops, I did it again…"

Back in June/July of 2007, I went on a little rant across several blog posts about how Google was directly entering the "security" business and would eventually begin to offer more than just "secure" search functions, but instead the functional equivalent of "clean pipes" or what has now become popularized as safe "cloud computing."

I called it S^2aaS (Secure Software as a Service) πŸ˜‰  OK, so I’m not in marketing.

Besides the numerous initiatives by Google focused on adding more "security" to their primary business (search) the acquisition of GreenBorder really piqued my interest.   Then came the Postini buyout.

To be honest, I just thought this was common sense and fit what I understood was the longer term business model of Google.  To me it was writing on the wall.  To others, it was just me rambling.

So in my post from last year titled "Tell Me Again How Google Isn’t Entering the Security Market?  GooglePOPs will Bring Clean Pipes…" I suggested the following:

In fact, I reckon that in the long term we’ll see the evolution
of the Google Toolbar morph into a much more intelligent and rich
client-side security application proxy service whereby Google actually
utilizes client-side security of the Toolbar paired with the
GreenBorder browsing environment and tunnel/proxy all outgoing requests
to GooglePOPs.

Google will, in fact, become a monster ASP.  Note that I said
ASP and not ISP.  ISP is a commoditized function.  Serving applications
and content as close to the user as possible is fantastic.  So pair all
the client side goodness with security functions AND add GoogleApps and
you’ve got what amounts to a thin client version of the Internet.

Now we see what Google’s been up to with their announcement of Chrome (great writeup here,) which is their foray into the Browser market with an open source model with heaps of claimed security and privacy functions built in.  But it’s the bigger picture that’s really telling.

Hullo!  This isn’t about the browser market!  It’s about the transition of how we’re going to experience accessing our information; from where, what and how.  Chrome is simply an illustration of a means to an end.

Take what I said above and pair it with what they say below…I don’t think we’re that far off, folks…

From Google’s Blog explaining Chrome:

…we began
seriously thinking about what kind of browser could exist if we started
from scratch and built on the best elements out there. We realized that
the web had evolved from mainly simple text pages to rich, interactive
applications and that we needed to completely rethink the browser. What
we really needed was not just a browser, but also a modern platform for
web pages and applications, and that’s what we set out to build.

Under the hood, we were able to build the foundation of a
browser that runs today’s complex web applications much better. By
keeping each tab in an isolated "sandbox", we were able to prevent one
tab from crashing another and provide improved protection from rogue
sites. We improved speed and responsiveness across the board. We also
built a more powerful JavaScript engine, V8, to power the next
generation of web applications that aren’t even possible in today’s
browsers.

Here come the GooglePipes being fed by the GooglePOPs, being… πŸ˜‰

/Hoff

Categories: Clean Pipes, De-Perimeterization, Google Tags:

Don’t Hassle the Hoff: Recent Press & Podcast Coverage & Upcoming Speaking Engagements

August 28th, 2008 No comments

Here is some of the recent press coverage on topics relevant to content on my blog:
Microphone

  • Information Week: Virtualization Has A Security Blind Spot
  • Information Week: Securing Virtualization, or is that Virtualizing Security?
  • Network World: Black Hat speakers expose virtualization, OS security gaps (**NOTE: Please see here, VERY important)
  • Network World/Computerworld: Black Hat spotlights virtualization, DNS issues (**NOTE: Please see here, VERY important)
  • SearchSecurity (Australia): Could securing virtualised environments destroy ROI?
  • SearchSecurity: Initial virtualization costs could outweigh benefits
  • Computer Zeitung: Today’s Security Products Aren’t Ready For Virtualised Data Centres
  • Wall Street Journal: Hackers On the Move
  • Baseline: Managing Mobility In the Enterprise
  • ITWorld: Pros and Cons of VMware’s New Security Guide

Podcasts/Webcasts/Video:

I am confirmed to  speak at the following upcoming events:

I will be attending the following events:

/Hoff

By Popular Demand: It’s the End of the BGP World & We Know It…In Poetic Review

August 27th, 2008 1 comment

What the hell’s goin’ on here?
something’s surely a mess,
our BGP is announcing
the wrong damned AS

See, I announce with this prefix,
it’s a slash 24,
here to there should take 3 hops,
not 18 or more

I’m pinging the next hop and
that works just fine,
ping a host, subnet over,
slows like a POTS line

That Defcon session,
when we IM’d all night,
that shit’s all encrypted
you told me that, right?

My telnet shell’s cleartext!
DONE! Stabbed it with a FIN fork
So why do these Pcap’s
show SYN’s to New York!?

Somethin’ sure does look fishy,
TTLs all askew
are the ISPs tapping traffic
‘tween me and you?

I’m just paranoid, man,
I’m sure it’s all fine.
These ping-pong effects?
BGP’s grand design

I mean really, why worry?
Even though, I confess,
it’s not like we’re vulnerable
like with DNS

BGP must be foolproof
auth’d and encrypted
there’s no way they’ve gamed it,
redirected or sniffed it

It would be quite stupid
if AS routes, you could twiddle,
intercept all my traffic
with a man-in-the-middle

Nah, I’ll sit here, use torrents,
my bits are secure,
close my eyes and imagine
that the Internet’s pure

What’s next though, I wonder,
what protocol hack
will cause Internet chaos
and make the tubes crack?

Categories: Jackassery, Poetry Tags:

My Awesome NetBIOS and Token Ring Beacon Attack Will Pwn the Internets!

August 26th, 2008 3 comments

Foobar
I was blipping through my RSS reader this evening and noticed this new little doozy of a headline referencing a story that is now weeks old:

Revealed: The Internet’s Biggest Security Hole

Holy crap! That’s pretty scary looking, huh?  Another Internet’s biggest security hole!?  I can’t take another.  I don’t have another poem in me.  What sort of "fool" disclosure is this!?

Then again, there are plenty of big ‘holes on the Internet, so I thought I better make sure it wasn’t me this time πŸ˜‰

Kapela’s and Pilosov’s cool performance at Defcon was sadly drowned out by Uncle Dan’s DNS flaw and the sheer weight of his grandma’s cookies (which I received zero samples of, by the way ;( )

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’ll be FAMOUS!

/Hoff

Categories: Jackassery Tags:

All Your Virtualized Storage Are Belong To Us…

August 26th, 2008 5 comments

Brocadesan
A point I’ve raised in my Four Horsemen presentation that I’m spending a lot of time researching is on the topic of how virtualization is accelerating the adoption of SAN storage and to a larger extent I/O virtualization and what that means to security.

I wanted to introduce this topic as a teaser to a larger series of posts.  This is not a treatise on the subject and is deliberately thin on detail and thick on corner case illustration.  You have been warned.

What I’m both extremely intrigued by and really worried about as we move further along the virtualization continuum is the strange duality offered up by the intersection of consolidated compute, resources and information overlaid with tremendous distributed mobility and the security (or lack thereof) of this pooled storage holding all our crown jewels.

Centralized storage offers great benefits: easier to backup/restore, simpler management, better cost effectiveness, facilitated resiliency and potentially better security.  However, that all depends upon how and who is actually responsible for the operational aspects of security and defining the policies and compliance requirements in the first place.

We see the grappling matches of responsibility being waged between who is responsible for securing our basic virtualized environments from the "server" and "network" perspective today and we’re struggling for answers.

What about securing storage?

This isn’t an argument about filesystem partitioning, ACL’s and GPO.  This is a whole other networking fabric or set of appliances that are being deployed, conntected to our hosts and administered/secured by…who?

Think about it; we’re moving away from local storage to pooled "networked" storage.  Not only is our critical information stored in these pools, but the Virtual Machine (VM) images are also.  Databases too.  One stop shopping!

Sure, this has trend has been going on for years, but virtualization and consolidation are shining the ugly light on the fact that we’ve been covering our eyes as to what this means to our overall security posture for many years.  That’s not going to last much longer.

Depending upon who is responsible for the architecture of your virtualized storage, your perfectly reasonable asset, network segmentation and layered defense may go out the window when "machines" from multiple tiers all interconnect to a single storage fabric. 

It shouldn’t happen, but it does; think about your (coming soon) virtualized DMZ’s and what that might mean to this diagram:

Vmwaredmz_virtualization

You might notice that for "simplicity" although the management/service console network is represented, the storage "network" is not.  I’ll bet dollars to doughnuts that all three tiers would be serviced by a single SAN in the real world…

I’ve heard that over your dead body would you combine multiple network zones on the same physical/virtualized host like in the picture above.  Strangely though I bet many of you connect physical assets (virtualized or not) of varying criticality to the same SAN fabric though like in the Brocade diagram on the top left.

What exactly is the difference?

Will the real SAN storage security experts please stand up?  OK, how
about if you’re faking it really well?  Um, how about you storage
admins posing as security experts?  Server admins who eat LUNs for
lunch?  Network engineers who admin Cisco, Brocade, Xsigo I/O virtualization switches?

Bueller?

I am *not* a security storage expert but I’m reasonably skilled in many
other elements of security, and that’s really the point of all of
this.  I recognize there are many things that can be done to segment/zone/mask/secure
storage, but I don’t have those skills and I don’t know how to assess others’ either.  I’d bet that if you haven’t
been involved in securing storage for quite some time, even if you’re
being drug into virtualized environments, you’re in the same boat?

Food for (scary) thought.

/Hoff

Categories: Virtualization Tags:

Complete Slides: The Four Horsemen Of the Virtualization Security Apocalypse

August 19th, 2008 10 comments

4horsemen_blackhat
UPDATE: Here’s the latest version of the presentation as I updated it for SecTor in Canada.Β  It includes many additions as well as modified single slides of the animated ones.

You can find the slides from October 2008 here.


There were some significant differences in the slides that were on the CD issued by the Blackhat folks and what I delivered.

You might be interested in them.Β  I’ve exported the presentation to PDF with each animation built as a separate slide – in some cases that means there are 5-6 slides with advancing bullets, graphics, etc.Β  As annoying as that may be, it fixes the mess of the positional overlay problem you’ll see if you view the PDF from the CD.

As an important note, my slides are designed to accompany my speaking, not the other way around, so in some cases they don’t explain themselves.Β  This is by design πŸ˜‰

I will be giving updates to this presentation throughout the rest of the year since it’s a presentation designed to communicate the virtualization “state of the art” as it relates to VirtSec.Β  So, if you attend a conference and see this talk advertised, it will have new/updated content.

Be warned, this PDF is huge (~55 MB) because my slides are intensely graphical.

Enjoy.

/Hoff

(In 5 days there have been almost 1000 downloads of this preso.Β  If any of you have feedback, I’d really appreciate it.Β  Thanks)

High Availability Security Virtual Appliances…Check Point Steps Up

August 18th, 2008 No comments

One of my key topics in my Blackhat presentation "The Four Horsemen of the Virtualization Security Apocalypse" focused on today’s lack of state-synchronized high availability/load-balanced solutions for security virtual appliances that offer the same functionality as their physical appliance counterparts.

I used an example from a vendor I didn’t name in one of my slides to illustrate that if you attempted to replicate the options you have today in physical appliances in a virtual construct, you would not be able to (using this particular solution suite as an example.)

Fwfuzz
That vendor was Check Point and I was referring to their SPLAT-based virtual appliance. 

The version that was available for ESX environments when I created my presentation offered no load-balanced HA capabilities whatsoever as stated in the release notes. 

However, today I received the announcement of Check Point’s VPN-1 Virtual Edition (virtual appliance.)

Based upon what I am reading in the administrator’s guide, VE now includes support for ClusterXL HA FW/VPN state-synchronized load sharing across one or more ESX hosts.

This is a great first step in the right direction.

We should expect more solutions to start arriving shortly to address many of the issues I brought up as the current "state of the art," and this is a good example of that. 

There are numerous caveats and limitations, many of which I spoke directly about in my presentation with many of them related to the interdependencies of network topologies, virtual networking and interaction with VMware’s integrated HA/clustering solutions…which was one of the other key topics in my talk πŸ˜‰ I’ll update some of them as an addendum to this post shortly. Updated below.

You can find information regarding Check Point’s VPN-1 Virtual Edition here.

/Hoff

Updated: If you read the release notes, you’ll notice these little gems.  I don’t have the time to go through each of these limitations, but they’re significant and go to the point that all things are not equal in V versus P:

  • Interface bonding on the virtual machine running the VPN-1 Virtual Edition is not supported
    with ClusterXL.
  • VMotion is not supported
  • VPN-1 gateways in the Bridge Mode must have their internal and external interfaces connected
    to port groups that are configured in promiscuous mode.
  • VPN-1 gateways in the Bridge Mode are not supported with ClusterXL.
  • Virtual machines may be connected to a maximum of four different virtual switches. This may
    limit the number of virtual networks protected by a VPN-1 Virtual Edition machine. This
    limitation can be overcome using VLANs.

I’ll give them props for this one, though, given its refreshing honesty:

  • VPN-1 Virtual Edition does not protect the VMkernel.
Categories: Virtualization Tags:

Virtualized Infrastructure: It’s All Fun and Games Until Someone Loses An (PC)I…

August 15th, 2008 5 comments

Monkeys
I just responded to a comment from Iben Rodriguez on one of my virtualization and PCI blog entries from a while back and posted an observation while at the same time managed to make a funny (see the title.)

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.

Whack-a-mole!

/Hoff

Categories: Jackassery, Virtualization Tags:

Leo Laporte Reads My DNS Debacle Poem on Security Now Podcast…

August 14th, 2008 1 comment

Secnowpodcast
From the Department Of Serendipity…

Thanks to a heads-up from my buddy Jack Daniel, rumors that Leo Laporte read my DNS Debacle poem on the Security Now podcast are confirmed. 

I’ve listened to and watched Leo’s shows for a long time and it was very cool to hear him rattle off my prose. 

Despite the glorious buzz of two-stroke gardening equipment in the background, Leo’s fantastic radio voice, dripping in the style of Dr. Suess, added a surreal quality to my poem as he read it.

Thanks very much to both Steve Gibson and Leo Laporte for the nod.

It starts at around 18:40 into the podcast.  Check it out here.

/Hoff

Categories: Jackassery Tags: