Archive

Archive for January, 2011

George Carlin, Lenny Bruce & The Unspeakable Seven Dirty Words of Cloud Security

January 26th, 2011 1 comment
George Carlin
Cover of George Carlin

I have an upcoming cloud security presentation in which I map George Carlin’s “Seven Dirty Words” to Cloud Security challenges.  This shall accompany my presentation at the Cloud Security Alliance Summit at the RSA Conference titled: Commode Computing: Relevant Advances In Toiletry – From Squat Pots to Cloud Bots – Waste Management Through Security Automation”

I’ll leave it as an exercise for the reader to relate my 7 dirty words to George’s originals:

Scalability
Portability
Fungibility
Compliance
Cost
Manageability
Trust

Of course I could have modeled the talk after Lenny Bruce’s original nine dirty words that spawned George’s, but seven of nine appealed to the geek in me.

/Hoff

P.S. George looks remarkably like Vint Cerf in that picture above…uncanny.

Enhanced by Zemanta
Categories: Uncategorized Tags:

Past Life Regressions & Why Security Is a Petunia (Or a Whale) Depending Upon Where You Stand

January 26th, 2011 1 comment
42, The Answer to the Ultimate Question of Lif...
Image via Wikipedia

In Douglas Adam’s epic “The Hitchhiker’s Guide to the Galaxy,” we read about an organism experiencing a bit of a identity crisis at 30,000 feet:

It is important to note that suddenly, and against all probability, a Sperm Whale had been called into existence, several miles above the surface of an alien planet and since this is not a naturally tenable position for a whale, this innocent creature had very little time to come to terms with its identity. This is what it thought, as it fell:

The Whale: Ahhh! Woooh! What’s happening? Who am I? Why am I here? What’s my purpose in life? What do I mean by who am I? Okay okay, calm down calm down get a grip now. Ooh, this is an interesting sensation. What is it? Its a sort of tingling in my… well I suppose I better start finding names for things. Lets call it a… tail! Yeah! Tail! And hey, what’s this roaring sound, whooshing past what I’m suddenly gonna call my head? Wind! Is that a good name? It’ll do. Yeah, this is really exciting. I’m dizzy with anticipation! Or is it the wind? There’s an awful lot of that now isn’t it? And what’s this thing coming toward me very fast? So big and flat and round, it needs a big wide sounding name like ‘Ow’, ‘Ownge’, ‘Round’, ‘Ground’! That’s it! Ground! Ha! I wonder if it’ll be friends with me? Hello Ground!
[
dies]

Curiously the only thing that went through the mind of the bowl of petunias, as it fell, was, ‘Oh no, not again.’ Many people have speculated that if we knew exactly *why* the bowl of petunias had thought that we would know a lot more about the nature of the universe than we do now.

“Security” is facing a similar problem.

To that end, and without meaning to, Gunnar Petersen and Lenny Zeltser* unintentionally wrote about this whale of a problem in two thought provoking blogs describing what they portray as the sorry state of security today; specifically the inappropriate mission focus and misallocation of investment (Gunnar) and the need for remedying the skills gap and broadening the “information security toolbox” (Lenny)  that exists in an overly infrastructure-centric model used today.

Gunnar followed up with another post titled: “Is infosec busy being born or busy dying?”  Fitting.

Both gents suggest that we need to re-evaluate what, why and how we do what we do and where we invest by engaging in a more elevated service delivery role with a focus on enablement, architecture and cost-efficiency based on models that align spend to a posture I can only say reflects the mantra of survivability (see: A Primer on Information Survivability: Changing Your Perspective On Information Security):

[Gunnar] The budget dollars in infosec are not based on protecting the assets the company needs to conduct business, they are not spent on where the threats and vulnerabilities lie, rather they are spent on infrastructure which happens to be the historical background and hobby interest of the majority of technical people in the industry.

[Lenny] When the only tool you have is a hammer, it’s tempting to treat everything as if it were a nail, wrote Abraham Maslow a few decades ago. Given this observation, it’s not surprising that most of today’s information security efforts seem to focus on networks and systems.

Hard to disagree.

It’s interesting that both Gunnar and Lenny refer to this condition as being a result of our “information security” efforts since, as defined, it would appear to me that their very point is that we don’t practice “information security.”  In fact, I’d say what they really mean is that we primarily practice “network security” and pitter-patter around the other elements of the “stack:”

This is a “confused discipline” indeed.  Fact is, we need infrastructure security. We need application security.  We need information security.  We need all of these elements addressed by a comprehensive architecture and portfolio management process driven by protecting the things that matter most at the points where the maximum benefit can be applied to manage risk for the lowest cost.

Yes.

That’s. Freaking. Hard.

This is exactly why we have the Security Hamster Sine Wave of Pain…we cyclically iterate between host, application, information, user, and network-centric solutions to problems that adapt at a pace that far exceeds our ability to adjust to them let alone align to true business impact:

Whales and Petunias…

The problem is that people like to put things in neat little boxes which is why we have neat, little boxes and the corresponding piles of cash and people distributed to each of them (however unfortunate the ratio.)  Further, the industry that provides solutions across this stack are not incentivized to solve long term problems and innovative solutions brought to bear on emerging problems are often a victim of poor timing.  People don’t buy solutions that solve problems that are 5 years out, they buy solutions that fix short-term problems even if they are themselves predicated on 20 year old issues.

Fixing stuff in infrastructure has been easy up until now; buy another box.

Infrastructure has been pretty much static and thus the apps and information have bouyed about, tethered to the anchor of a static infrastructure.  Now that the infrastructure itself is becoming more dynamic, fixing problems upstack in dynamic applications and information — woohoo, that’s HARD, especially when we’re not organized to do any one of those things well, let alone all of them at once!

Frankly, the issue is one where the tactical impacts of the blending and convergence of new threats, vulnerabilities, socio-economic, political, cultural and technology curves chips away at our ability to intelligently respond without an overall re-engineering of what we do.  We’d have to completely blow up the role of “security” as we know it to deliver what Gunnar and Lenny suggest.

This isn’t a bad idea, it’s just profoundly difficult.  I ought to know. I’ve done it.  It took years to even get to the point where we could chip away at the PEOPLE who were clinging on to what they know as the truth…it’s as much generational and cultural as it is technical.

The issue I have is that it’s important to also realize that we’ve been here before and we’ll be here again and more importantly WHY.  I don’t think it’s a vast conspiracy theory but rather an unfortunate side-effect of our past lives.

I don’t disagree with the need to improve and/or reinvent ourselves as an industry — both from the perspective of the suppliers of solutions, the operators or the architects.  We do every 5 years anyway what with every “next big thing” that hits.

To round this back to the present, new “phase shifts” like Cloud computing are great forcing functions that completely change our perspective on where, how, who, and why we practice “security.”  I’d suggest that we leverage this positively and march to that drum beat Lenny and Gunnar are banging away on, but without the notion that we’re all somehow guilty of doing the wrong things.

BTW, has anyone seen my Improbability Drive?

/Hoff

Related articles

Enhanced by Zemanta

Revisiting Virtualization & Cloud Stack Security – Back to the Future (Baked In Or Bolted On?)

January 17th, 2011 No comments

[Like a good w[h]ine, this post goes especially well with a couple of other courses such as Hack The Stack Or Go On a Bender With a Vendor?, Incomplete Thought: Why Security Doesn’t Scale…Yet, What’s The Problem With Cloud Security? There’s Too Much Of It…, Incomplete Thought: The Other Side Of Cloud – Where The (Wild) Infrastructure Things Are… and Where Are the Network Virtual Appliances? Hobbled By the Virtual Network, That’s Where…]

There are generally three dichotomies of thought when it comes to the notion of how much security should fall to the provider of the virtualization or cloud stack versus that of the consumer of their services or a set of third parties:

  1. The virtualization/cloud stack provider should provide a rich tapestry of robust security capabilities “baked in” to the platform itself, or
  2. The virtualization/cloud stack provider should provide security-enabling hooks to enable an ecosystem of security vendors to provide the bulk of security (beyond isolation) to be “bolted on,” or
  3. The virtualization/cloud stack provider should maximize the security of the underlying virtualization/cloud platform and focus on API security, isolation and availability of service only while pushing the bulk of security up into the higher-level programatic/application layers, or

So where are we today?  How much security does the stack, itself, need to provide. The answer, however polarized, is somewhere in the murkiness dictated by the delivery models, deployment models, who owns what part of the real estate and the use cases of both the virtualization/cloud stack provider and ultimately the consumer.

I’ve had a really interesting series of debates with the likes of Simon Crosby (of Xen/Citrix fame) on this topic and we even had a great debate at RSA with Steve Herrod from VMware.  These two “infrastructure” companies and their solutions typify the diametrically opposed first two approaches to answering this question while cloud providers who own their respective custom-rolled “stacks” at either end of IaaS and SaaS spectrums such as Amazon Web Services and Salesforce bringing up the third.

As with anything, this is about the tenuous balance of “security,” compliance, cost, core competence and maturity of solutions coupled with the sensitivity of the information that requires protection and the risk associated with the lopsided imbalance that occurs in the event of loss.

There’s no single best answer which explains why were have three very different approaches to what many, unfortunately, view as the same problem.

Today’s “baked in” security capabilities aren’t that altogether mature or differentiated, the hooks and APIs that allow for diversity and “defense in depth” provide for new and interesting ways to instantiate security, but also add to complexity, driving us back to an integration play.  The third is looked upon as proprietary and limiting in terms of visibility and transparency and don’t solve problems such as application and information security any more than the other two do.

Will security get “better” as we move forward with virtualization and cloud computing.  Certainly.  Perhaps because of it, perhaps in spite of it.

One thing’s for sure, it’s going to be messy, despite what the marketing says.

Related articles

Enhanced by Zemanta

Why I Don’t Speak At Security B-Sides…

January 13th, 2011 2 comments

Security B-Sides has long since emerged from the “Indie” shadow it was born from and now represents and produces some of the most amazing content and speakers in the security (mainstream and otherwise) industry.

So why don’t I speak at any of them?

Two reasons.

1) Many of the B-Sides get spun up quickly and without much notice.  Those that I might be able to travel to/attend take place alongside the bigger conferences which I am required to attend and/or have committed to speak at far in advance, and…

2) I speak at 30-40 conferences a year. People don’t need to hear me prattle on about the same things I’ve spoken about elsewhere.  Further, many of the folks who respond with awesome CFP submissions to B-Sides don’t (for a number of reasons) speak at the larger conferences…so why should I take up space when others should be given this amazing opportunity?

So there you have it.

Support B-Sides.  One day I’ll get to one live. Until then, I’ll watch the live streams.

/Hoff

The Cloud As a (Hax0r’s) Calculator. Yawn…

January 11th, 2011 2 comments
How a botnet works: 1. A botnet operator sends...
Image via Wikipedia

If I see another news story that talks about how a “hacker” has shown that by “utilizing the cloud” to harness compute on demand to do what otherwise one might use a botnet or specialized hardware to perform BUT otherwise suggest that it somehow compromises an entire branch of technology, I’m going to…

Meh.

Yeah, cloud makes this cheap and accessible…rainbow table cracking using IaaS images via a cloud provider…passwords, wifi creds, credit card numbers, pi…

Please.

See:

Researcher cracks Wi-Fi passwords with Amazon cloud

Using Cloud Computing To Crack Passwords – Amazon’s EC2

Enhanced by Zemanta
Categories: Cloud Computing, Cloud Security Tags:

Incomplete Thought: Why Security Doesn’t Scale…Yet.

January 11th, 2011 1 comment
X-ray machines and metal detectors are used to...
Image via Wikipedia

There are lots of reasons one might use to illustrate why operationalizing security — both from the human and technology perspectives — doesn’t scale.

I’ve painted numerous pictures highlighting the cyclical nature of technology transitions, the supply/demand curve related to threats, vulnerabilities, technology and compensating controls and even relevant anecdotes involving the intersection of Moore’s and Metcalfe’s laws.  This really was a central theme in my Cloudinomicon presentation; “idempotent infrastructure, building survivable systems and bringing sexy back to information centricity.”

Here are some other examples of things I’ve written about in this realm.

Batting around how public “commodity” cloud solutions forces us to re-evaluate how, where, why and who “does” security was an interesting journey.  Ultimately, it comes down to architecture and poking at the sanctity of models hinged on an operational premise that may or may not be as relevant as it used to be.

However, I think the most poignant and yet potentially obvious answer to the “why doesn’t security scale?” question is the fact that security products, by design, don’t scale because they have not been created to allow for automation across almost every aspect of their architecture.

Automation and the interfaces (read: APIs) by which security products ought to be provisioned, orchestrated, and deployed are simply lacking in most security products.

Yes, there exist security products that are distributed but they are still managed, provisioned and deployed manually — generally using a management hub-spoke model that doesn’t lend itself to automated “anything” that does not otherwise rely upon bubble-gum and bailing wire scripting…

Sure, we’ve had things like SNMP as a “standard interface” for “management” for a long while ;)  We’ve had common ways of describing threats and vulnerabilities.  Recently we’ve seen the emergence of XML-based APIs emerge as a function of the latest generation of (mostly virtualized) firewall technologies, but most products still rely upon stand-alone GUIs, CLIs, element managers and a meat cloud of operators to push the go button (or reconfigure.)

Really annoying.

Alongside the lack of standard API-based management planes, control planes are largely proprietary and the output for correlated event-driven telemetry at all layers of the stack is equally lacking.  Of course the applications and security layers that run atop infrastructure are still largely discrete thus making the problem more difficult.

The good news is that virtualization in the enterprise and the emergence of the cultural and operational models predicated upon automation are starting to influence product roadmaps in ways that will positively affect the problem space described above but we’ve got a long haul as we make this transition.

Security vendors are starting to realize that they must retool many of their technology roadmaps to deal with the impact of dynamism and automation.  Some, not all, are discovering painfully the fact that simply creating a virtualized version of a physical appliance doesn’t make it a virtual security solution (or cloud security solution) in the same way that moving an application directly to cloud doesn’t necessarily make it a “cloud application.”

In the same way that one must often re-write or specifically design applications “designed” for cloud, we have to do the same for security.  Arguably there are things that can and should be preserved; the examples of the basic underpinnings such as firewalls that at their core don’t need to change but their “packaging” does.

I’m privy to lots of the underlying mechanics of these activities — from open source to highly-proprietary — and I’m heartened by the fact that we’re beginning to make progress.  We shouldn’t have to make a distinction between crafting and deploying security policies in physical or virtual environments.  We shouldn’t be held hostage by the separation of application logic from the underlying platforms.

In the long term, I’m optimistic we won’t have to.

/Hoff

Related articles

Enhanced by Zemanta