Archive

Posts Tagged ‘Cloud’

Cloud: Security Doesn’t Matter (Or, In Cloud, Nobody Can Hear You Scream)

January 25th, 2010 9 comments

In the Information Security community, many of us have long come to the conclusion that we are caught in what I call my “Security Hamster Sine Wave Of Pain.”  Those of us who have been doing this awhile recognize that InfoSec is a zero-sum game; it’s about staving off the inevitable and trying to ensure we can deal with the residual impact in the face of being “survivable” versus being “secure.”

While we can (and do) make incremental progress in certain areas, the collision of disruptive innovation, massive consumerization of technology along with the slow churn of security vendor roadmaps, dissolving budgets, natural marketspace commoditzation and the unfortunate velocity of attacker innovation yields the constant realization that we’re not motivated or incentivized to do the right thing or manage risk.

Instead, we’re poked in the side and haunted by the four letter word of our industry: compliance.

Compliance is often dismissed as irrelevant in the consumer space and associated instead with government or large enterprise, but as privacy continues to erode and breaches make the news, the fact that we’re putting more and more of our information — of all sorts — in the hands of others to manage is again beginning to stoke an upsurge in efforts to somehow measure and manage visibility against a standardized baseline of general, common sense and minimal efforts to guard against badness.

Ultimately, it doesn’t matter how “secure” Cloud providers suggest they are.  It doesn’t matter what breakthroughs in technology sprout up in the face of this new model of compute. The only measure that counts in the long run is how compliant you are.  That’s what will determine the success of Cloud.  Don’t believe me? Look at how the leading vendors in Cloud are responding today to their biggest (potential) customers — taking the “one size fits all” model of mass-market Cloud and beginning to chop it up and create one-off’s in order to satisfy…compliance.

Why?  Because it’s easier to deal with the vagaries of trust and isolation and multi-tenant environments by eliminating the latter to increase the former. If an auditor/examiner doesn’t understand or cannot measure your compliance to those things he/she is tasked to evaluate you against, you’re sunk.

The only thing that will budge the needle on this issue is how agile those who craft the regulatory guidelines are or how you can clearly demonstrate why your compensating controls mitigate the risk of the provider of service if they cannot. Given the nature and behavior of those involved in this space and where we are with putting our eggs in a vaporous basket, I wouldn’t hold my breath.  Movement in this area is glacial at best and in many cases out of touch with the realities of just how disruptive Cloud Computing is.  All it will take is one monumental cock-up due to a true Cloudtastrophe and the Cloud will hit the fan.

As I have oft suggested, the core issue we need to tackle in Cloud is trust, since the graceful surrender of such is at the heart of what Cloud requires.  Trust is comprised of Security, Control, Service Levels and Compliance.  It’s relatively easy to establish where we are today with the first three, but the last one is MIA.  We’re just *now* seeing movement in the form of SIGs to deal with virtualization.  Cloud?

When the best you have is a SAS-70, it’s time to weep.  Conversely, wishing for more regulation will simply extend the cycle.

What can you do?  Simple. Help educate your auditors and examiners. Read the Cloud Security Alliance’s guidelines. Participate in making the Automated Audit, Assertion, Assessment, and Assurance API (A6) a success so we can at least gain back some visibility and transparency which helps demonstrate compliance, since that’s how we’re measured.  Ultimately, if you’re able, focus on risk assessment in helping to advise your constituent business customers on how to migrate to Cloud Computing safely.

There are TONS of things one can do in order to make up for the shortcomings of Cloud security today.  The problem is, most of them erode the benefits of Cloud: agility, flexibility, cost savings, and dynamism.  We need to make the business aware of these tradeoffs as well as our auditors because we’re stuck.  We need the regulators and examiners to keep pace with technology — as painful as that might be in the short term — to guarantee our success in the long term.

Manage compliance, don’t let it manage you because a Cloud is a terrible thing to waste.

/Hoff

Reblog this post [with Zemanta]

Incomplete Thought: Batteries – The Private Cloud Equivalent Of Electrical Utility…

January 24th, 2010 21 comments

While I think Nick Carr’s power generation utility analogy was a fantastic discussion catalyst for the usefulness of a utility model, it is abused to extremes and constrains what might ordinarily be more open-minded debate on the present and future of computing.

This is a debate that continues to rise every few days on Twitter and the Blogosphere, fueled mostly by what can only be described from either side of the argument as a mixture of ideology, dogma, passionate opinion, misunderstood perspective and a squinty-eyed mistrust of agendas.

It’s all a bit silly, really, as both Public and Private Cloud have their place; when, for how long and for whom is really at the heart of the issue.

The notion that the only way “true” benefits can be realized from Cloud Computing are from massively-scaled public utilities and that Private Clouds (your definition will likely differ) are simply a way of IT making excuses for the past while trying to hold on to the present, simply limits the conversation and causes friction rather than reduces it.  I believe that a hybrid model will prevail, as it always has.  There are many reasons for this. I’ve talked about them a lot.

This got me thinking about why and here’s my goofy thought for consideration of the “value” and “utility” of Private Cloud:

If the power utility “grid” represents Public Cloud, then perhaps batteries are a reasonable equivalent for Private Cloud.

I’m not going to explain this analogy in full yet, but wonder if it makes any sense to you.  I’d enjoy your thoughts on what you think I’m referring to. 😉

/Hoff

Cloud: Over Subscription vs. Over Capacity – Two Different Things

January 15th, 2010 10 comments

There’s been a very interesting set of discussions lately regarding performance anomalies across Cloud infrastructure providers.  The most recent involves Amazon Web Services and RackSpace Cloud. Let’s focus on the former because it’s the one that has a good deal of analysis and data attached to it.

Reuven Cohen’s post (Oversubscribing the Cloud) summarizing many of these concerns speaks to the meme wherein he points to Alan Williamson’s initial complaints (Has Amazon EC2 become over subscribed?) followed by CloudKick’s very interesting experiments and data (Visual Evidence of Amazon EC2 network issues) and ultimately Rich Miller’s summary including a response from Amazon Web Services (Amazon: We Don’t Have Capacity Issues)

The thing that’s interesting to me in all of this is yet another example of people mixing metaphors, terminology and common operating methodologies as well as choosing to suspend disbelief and the reality distortion field associated with how service providers actually offer service versus marketing it.

Here’s the kicker: over subscription is not the same thing as over capacity. BY DESIGN, modern data/telecommuication (and Cloud) networks are built using an over-subscription model.

On the other hand, the sad truth is that we will have over capacity issues in cloud; it’s simply a sad intersection of the laws of physics and the delicate balance associated with cost control and service delivery.

Let me frame the following with an example: when you purchase an “unlimited data plan” from a telco or hosting company, you’ll notice normally that this does not have latency or throughput figures attached to it…same with Cloud.  You shouldn’t be surprised by this. If you are, you might want to rethink your approach to service level expectation.

Short and sweet:

  1. There is no such thing as infinite scale.  There is no such thing as an “unlimited ____ plan.”* Even in Cloud. Every provider has limits, even if they’re massive. Adding the word Cloud simply squeezes the limit balloon from you to them and it’s a tougher problem to solve at scale. It doesn’t eliminate the issue, even with “elasticity.”
  2. Allow me to repeat: over subscription is not the same thing as over capacity. BY DESIGN, modern data/telecommuication (and Cloud) networks are built using an over-subscription model.  I don’t need to explain why, I trust.
  3. Capacity refers to the ability, within service level specifications, to meet the contracted needs of the customer and operate within acceptable thresholds. Depending upon how a provider measures that and communicates it to you, you may be horribly surprised if you chose the marketing over the engineering explanations of such.
  4. Capacity is also not the same as latency, is not the same as throughput…
  5. Over capacity means that the provider’s over-subscription modeling was flawed and suggests that the usage patterns overwhelmed the capacity threshold and they had no way of adding capacity in a manner which allows them to satisfy demand

Why is this important?  Because the “illusion” of infinite scale is just that.

The abstraction at the infrastructure layer of compute, network and storage — especially delivered in software — still relies on the underlying capacity of the pipes and bit-buckets that deliver them. It’s a never-ending see-saw movement of Metcalfe’s and Moore’s laws.

The discrete packaging of each virtualized CPU compute element sizing within an AWS or Rackspace is relatively easy to forecast and yields a reasonably helpful “fixed” capacity planning data point; it has a minima of zero and a maxima associated with the peak compute hours/vCPU clock rating of the instance.

The network piece and its relationship to the compute piece is where it gets interesting.  Your virtual interface ultimately is bundled together in aggregate with other tenants colocated on the same physical host and competes for a share of pipe (usually one or more single or trunked 1Gb/s or 10Gb/s Ethernet.) Network traffic in terms of measurement, capacity planning and usage must take into consideration the facts that it is both asymmetric, suffers from variability in bucket size, and is very, very bursty. There’s not generally a published service level associated with throughput in Cloud.

This complicates things when you consider that at this point scaling out in CPU is easier to do than scaling out in the network.  Add virtualization into the mix which drives big, flat, L2 networks as a design architecture layered with a control plane that is now (in the case of Cloud) mostly software driven, provisioned, orchestrated and implemented, and it’s no wonder that folks like Google, Amazon and Facebook are desparate for hugely dense, multi-terabit, wire speed L2 switching fabrics and could use 40 and 100Gb/s Ethernet today.

Check out this interesting article.

Oh, let’s not forget that there are also now providers who are deploying converged data/storage networking of said pipes with the likes of FCoE/DCE with all sorts of interesting ramifications on the above discussion.  If you thought it was tough to get your arms around before…

If you know much about Ethernet, congestion avoidance/recovery/control, QoS, etc. you know that it’s a complex beast. If service levels relating to network performance aren’t in your contract, you’re probably figuring out why right about now.

So, wrapping this up, I have to accept AWS’ statement that they “…do not have over-capacity issues,” because quite frankly there’s nothing to suggest otherwise.  That’s not to say there aren’t performance issues are related to something else (like software or hardware in the stack) but that’s not the same as being over capacity — and you’ll notice that they didn’t say they were not “over-subscribed” but rather they were not “over capacity.” 😉

/Hoff

*Just ask AT&T about their network and the iPhone. This *is* a case where their over-subscription planning failed in the face of capacity…and continues to.

Categories: Cloud Computing Tags: ,

Recording & Playback of WebEx A6 Working Group Kick-Off Call from 1/8/2010 Available

January 10th, 2010 No comments

If you’re interested in the great discussion and presentations we had during the kickoff call for the A6 (Automated Audit, Assertion, Assessment, and Assurance API) Working Group, there are two options to listen/view the WebEx recording:

Topic: A6 API Working Group – Kickoff Call-20100108 1704
Create time: 1/8/10 10:07 am
File size: 33.23MB
Duration: 1 hour 1 minute
Description: Streaming recording link:
https://ciscosales.webex.com/ciscosales/ldr.php?AT=pb&SP=MC&rID=41631852rKey=178e8b04941e5672
Download recording link:
https://ciscosales.webex.com/ciscosales/lsr.php?AT=dw&SP=MC&rID=41631…

MAKE SURE YOU VIEW THE CHAT WINDOW << It contains some really excellent discussion points.

We had two great presentations from representatives from the OGF OCCI group and CSC’s Trusted Cloud Team.

I’ll be setting up regular calls shortly and a few people have reached out to me regarding helping form the core team to begin organizing the working group in earnest.

You can also follow along via the Google Group here.

/Hoff

In need of a cool logo for the group by the way… 😉

To Achieve True Cloud (X/Z)en, One Must Leverage Introspection

January 6th, 2010 No comments

Back in October 2008, I wrote a post detailing efforts around the Xen community to create a standard security introspection API (Xen.Org Launches Community Project To Bring VM Introspection to Xen🙂

The Xen Introspection Project is a community effort within Xen.org to leverage the existing research presented above with other work not yet public to create a standard API specification and methodology for virtual machine introspection.

That blog was focused on introspection for virtualization proper but since many of the larger cloud providers utilize Xen virtualization as an underpinning of their service architecture and as an industry we’re suffering from a lack of visibility and deployable security capabilities, the relevance of VM and VMM introspection to cloud computing is quite relevant.

I thought I’d double around and see where we are.

It looks as though there’s been quite a bit of recent activity from the folks at Georgia Tech (XenAccess Project) and the University of Alaska at Fairbanks (Virtual Introspection for Xen) referenced in my previous blog.  The vCloud API proffered via the DMTF seems to also leverage (at least some of) the VMsafe API capabilities present in VMware‘s vSphere virtualization platform.

While details are, for obvious reasons sketchy, I am encouraged in speaking to representatives from a few cloud providers who are keenly interested in including these capabilities in their offerings.  Wouldn’t that be cool?

Adoption and inclusion of introspection capabilities will overcome some of the inherent security and visibility limitations we face in highly-virtualized multi-tenant environments due to networking constraints for integrating security functionality that I wrote about here.

I plan a follow-on blog in more detail once I finish some interviews.

/Hoff

Reblog this post [with Zemanta]

The Great Cloud Security Challenge: I Triple-Dog-Dare You…

December 27th, 2009 15 comments

I TRIPLE-DOG-DARE You!

There’s an awful lot of hyperbole being flung back and forth about the general state of security and Cloud-based services.

I’ve spent enough time highlighting both the practical and hypothetical (many of which actually have been realized) security issues created and exacerbated by Cloud up and down the stack, from IaaS to SaaS.

It seems, however, that there are a select few who ignore issues brought to light and seem to suggest that Cloud providers are at a state of maturity wherein they not only offer parity, but offer better security than the “average” IT shop.  What’s interesting is that while I agree that “Cloud Security is not insurmountable,” neither is non-Cloud security — but it’s sure as hell not progressed much in 40 years.

What’s missing is context.  What’s missing is the very risk assessment methodologies they reference in their tales of fancy.  What’s missing is that in the cases they suggest that security is not an obstacle to Cloud, there’s usually not much sensitive data or applications involved.

Ignore the U.S. CIO’s words of wisdom when he discusses the reality of security and moving to the Cloud. Ignore the CIO’s and CISO’s of the Fortune 500. Ignore everything in my Cloudifornication presentation and recent issues related to such. Ignore pragmatism.

Take my challenge instead…Here’s my dare:

  1. I’ll pay for an AWS EC2 instance for a month
  2. You choose the OS and LAMP stack components you’ll deploy in this AMI
  3. You harden it however you see fit, but ensure the web server can be reached via port 80 from the Internet*
  4. You put a .txt file somewhere on a readable filesystem (mounted) or create a row in a DB accessible via the web server
  5. This .txt file or row in the DB contains the following: Your name, (billing) address, social security number, credit card number, mother’s maiden name and your bank’s ABA routing number and checking account number
  6. I’ll invite some people I know to test your hypothesis for you

Let’s see if they want to put their money (literally) where their mouths are?  After all, they claim that Cloud providers will be able to secure their applications and data.

I triple-dog-dare you.

The only diatribes that we ought to be spared from are those that themselves don’t offer a balance of reality, responsibility and maturity as those they accuse of doing the same.

It’s not that Cloud deployments *can’t* be at least as secure as non-Cloud deployments with appropriate adjustments.  My issue with these wanderlust expressions is that the implication today that Cloud providers not only achieve parity but also exceed it — and that Cloud providers have some capability or technology the rest of us do not — given the challenges we have, is incredulous.

I’m all for evangelism, but generalizing about the state of security (in Cloud or otherwise) is a complete waste of electrons.  Yes, Cloud brings us opportunity and acts as a forcing function and we *will* see improvements, but NOT because we put blinders on and pretend that the delivery model (Cloud) will fix 40 years of legacy computing challenges — especially since Cloud is built upon most of them in the first place!

See here.

/Hoff

* Feel free to use SSL if it makes you feel any better.

Cloud Security Alliance v2.1 Security Guidance for Critical Areas of Focus in Cloud Computing Available

December 17th, 2009 No comments

CSA-LogoVersion 2.1 of the Cloud Security Alliance “Security Guidance for Critical Areas of Focus in Cloud Computing” is available for download here.

It’s important to note that in this version of the guidance there are some notable changes in structure and content focus:

The guidance provided herein is the second version of the Cloud Security Alliance document, “Security Guidance for Critical Areas of Focus in Cloud Computing”, which was originally released in April 2009.  The permanent archive locations for these documents are:

http://www.cloudsecurityalliance.org/guidance/csaguide.v2.1.pdf  (this document)
http://www.cloudsecurityalliance.org/guidance/csaguide.v1.0.pdf  (version 1 guidance)

In a departure from the first version of our guidance, a decision was made to separate the key guidance from the core domain research.  Each domain’s core research is being released as its own white paper.  These white papers and their release schedule are located at:

http://www.cloudsecurityalliance.org/guidance/domains/

In another change from the first version, Domain 3: Legal and Domain 4: Electronic Discovery were combined into a single domain.  Additionally, Domain 6: Information Lifecycle Management and Domain 14: Storage were combined into a single domain, renamed Data Lifecycle Management.  This has caused a renumbering of our (now 13) domains.

We have hundreds of pages of edited/compiled content for each of these domains and the working groups will be releasing their schedules for the domain work products shortly.

Thanks to everyone who contributed!  We look forward to delivering even more value in the follow-on releases.

/Hoff,
Technical Advisor CSA

From the X-Files – The Cloud in Context: Evolution from Gadgetry to Popular Culture

November 27th, 2009 4 comments

apple1984

[This post was originally authored November 27, 2009.  I pushed it back to the top of the stack because I think it’s an interesting re-visitation of the benefits and challenges we are experiencing in Cloud today]

Below is an article I wrote many months ago prior to all the Nicholas Carr “electricity ain’t Cloud” discussions.  The piece was one from a collection that was distributed to “…the Intelligence Community, the DoD, and Congress” with the purpose of giving a high-level overview of Cloud security issues.

The Cloud in Context: Evolution from Gadgetry to Popular Culture

It is very likely that should one develop any interest in Cloud Computing (“Cloud”) and wish to investigate its provenance, one would be pointed to Nicholas Carr’s treatise “The Big Switch” for enlightenment. Carr offers a metaphoric genealogy of Cloud Computing, mapped to, and illustrated by, a keenly patterned set of observations from one of the most important catalysts of a critical inflection point in modern history: the generation and distribution of electricity.

Carr offers an uncannily prescient perspective on the evolution and adaptation of computing by way of this electric metaphor, describing how the scale of technology, socioeconomic, and cultural advances were all directly linked to the disruptive innovation of a shift from dedicated power generation in individual factories to a metered utility of interconnected generators powering distribution grids feeding all. He predicts a similar shift from insular, centralized, private single-function computational gadgetry to globally-networked, distributed, public service-centric collaborative fabrics of information interchange.

This phenomenon will not occur overnight nor has any other paradigm shift in computing occurred overnight; bursts of disruptive innovation have a long tail of adoption. Cloud is not the product or invocation of some singular technology, but rather an operational model that describes how computing will mature.

There is no box with blinking lights that can be simply pointed to as “Cloud” and yet it is clearly more than just timesharing with Internet connectivity. As corporations seek to drive down cost and gain efficiency force-multipliers, they have ruthlessly focused on divining what is core to their businesses, and expensive IT cost-centers are squarely in the crosshairs for rigorous valuation.

To that end, Carr wrote another piece on this very topic titled “IT Doesn’t matter” in which he argued that IT was no longer a strategic differentiator due to commoditization, standardization, and cost. This was followed by “The End of Corporate Computing” wherein he suggested that IT will simply subscribe to IT services as an outsourced function. Based upon these themes, Cloud seems a natural evolutionary outcome motivated primarily by economics as companies pare down their IT investment — outsourcing what they can and optimizing what is left.

Enter Cloud Computing

The emergence of Cloud as cult-status popular culture also has its muse anchored firmly in the little machines nestled in the hands of those who might not realize that they’ve helped create the IT revolution at all: the consumer. The consumer’s shift to an always-on, many-to-many communication model with unbridled collaboration and unfettered access to resources, sharply contrasts with traditional IT — constrained, siloed, well-demarcated, communication-restricted, and infrastructure-heavy.

Regardless of any value judgment on the fate of Man, we are evolving to a society dedicated to convenience, where we are not tied to the machine, but rather the machine is tied to us, and always on. Your applications and data are always there, consumed according to business and pricing models that are based upon what you use while the magic serving it up remains transparent.

This is Cloud in a nutshell; the computing equivalent to classical Greek theater’s Deus Ex Machina.

For the purpose of this paper, it is important that I point out that I refer mainly to so-called “Public Cloud” offerings; those services provided by parties external to the data owner who provides an “outsourced” service capability on behalf of the consumer.

This graceful surrender of control is the focus of my discussion. Private Clouds — those services that may operate on the corporation’s infrastructure or those of a provider but managed under said corporation’s control and policies, offers a different set of benefits and challenges but not to the degree of Public Cloud.

There are also hybrid and brokered models, but to keep focused, I shall not address these directly.

Cloud Reference Model

Cloud Reference Model

A service is generally considered to be “Cloud-based” should it meet the following characteristics and provide for:

  • The abstraction of infrastructure from the resources that deliver them
  • The democratization of those resources as an elastic pool to be consumed
  • Services-oriented, rather than infrastructure or application-centric
  • Enabling self-service, scale on-demand elasticity and dynamism
  • Employs a utility-like model of consumption and allocation

Cloud exacerbates the issues we have faced for years in the information security, assurance, and survivability spaces and introduces new challenges associated with extreme levels of abstraction, mobility, scale, dynamism and multi-tenancy. It is important that one contemplate the “big picture” of how Cloud impacts the IT landscape and how given this “service- centric” view, certain things change whilst others remain firmly status quo.

Cloud also provides numerous challenges to the way in which computing and resources are organized, operated, governed and secured, given the focus on:

  • Automated and autonomic resource provisioning and orchestration
  • Massively interconnected and mashed-up data sources, conduits and results
  • Virtualized layers of software-driven, service-centric capability rather than infrastructure or application- specific monoliths
  • Dynamic infrastructure that is aware of and adjusts to the information, applications and services (workloads) running over it, supporting dynamism and abstraction in terms of scale, policy, agility, security and mobility

As a matter of correctness, virtualization as a form of abstraction may exist in many forms and at many layers, but it is not required for Cloud. Many Cloud services do utilize virtualization to achieve scale and I make liberal use of this assumptive case in this paper. As we grapple with the tradeoffs between convenience, collaboration, and control, we find that existing products, solutions and services are quickly being re-branded and adapted as “Cloud” to the confusion of all.keep focused, I shall not address these directly.

Modeling the Cloud

There exist numerous deployment, service delivery models and use cases for Cloud, each offering a specific balance of integrated features, extensibility/ openness and security hinged on high levels of automation for workload distribution.

Three archetypal models generally describe cloud service delivery, popularly referred to as the “SPI Model,” where “SPI” refers to Software, Platform and Infrastructure (as a service) respectively.

NIST - Visual Cloud Model

NIST – Visual Cloud Model

Using the National Institute of Standards and Technology’s (NIST) draft working definition as the basis for the model:

Software as a Service (SaaS)

The capability provided to the consumer is to use the provider’s applications running on a cloud infrastructure and accessible from various client devices through a thin client interface such as a Web browser (e.g., web-based email).

The consumer does not manage or control the underlying cloud infrastructure, network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

Platform as a Service (PaaS)

The capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created applications using programming languages and tools supported by the provider (e.g., Java, Python, .Net). The consumer does not manage or control the underlying cloud infrastructure,

Infrastructure as a Service (IaaS)

The capability provided to the consumer is to rent processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, deployed applications, and possibly select networking components (e.g., firewalls, load balancers).

Understanding the relationship and dependencies between these models is critical. IaaS is the foundation of all Cloud services with PaaS building upon IaaS, and SaaS — in turn — building upon PaaS. We will cover this in more detail later in the document.

Peanut Butter & Jelly — Making the Perfect Cloud Sandwich

Infostructure/Metastructure/Infrastructure

Infostructure/Metastructure/Infrastructure

To understand how Cloud will affect security, visualize its functional structure in three layers:

  • The Infrastructure layer represents the traditional compute, network and storage hardware and operating systems familiar to us all. Virtualization platforms also exist at this layer and expose their capabilities northbound.
  • The Infostructure layer represents the programmatic components such as applications and service objects that produce, operate on or interact with the content, information and metadata.
  • Sitting in between Infrastructure and Infostructure is the Metastructure layer. This layer represents the underlying set of protocols and functions with layers such as DNS, BGP, and IP address management, which “glue” together and enable the applications and content at the Infostructure layer to in turn be delivered by the Infrastructure.

Certain areas of Cloud Computing’s technology underpinnings are making progress, but those things that will ultimately make Cloud the ubiquitous and transparent platform for our entire computing experience remain lacking.

Unsurprisingly, most of the deficient categories of technology or capabilities are those that need to be delivered from standards and consensus-driven action; things that have always posed challenges such as management, governance, provisioning, orchestration, automation, portability, interoperability and security. As security solutions specific to Cloud are generally slow in coming while fast innovating attackers are unconstrained by rules of engagement, it will come as no surprise that we are constantly playing catch up.

Cloud is a gradual adaptation rather than a wholesale re-tooling, and represents another cycle of investment which leaves us to consider where to invest our security dollars to most appropriately mitigate threat and vulnerability:

Typically, we react by cycling between investing in host-based controls > application controls > information controls > user controls > network controls and back again. While our security tools tend to be out of phase and less innovative than the tools of our opposition, virtualization and Cloud may act as much needed security forcing functions that get us beyond solving just the problem du jour.

The need to apply policy to workloads throughout their lifecycle, regardless of state, physical location, or infrastructure from which they are delivered, is paramount. Collapsing the atomic unit of the datacenter to the virtual machine boundary may allow for a simpler set of policy expressions that travel with the VM instance. At the same time, Cloud’s illusion of ubiquity and infinite scale means that we will not know where our data is stored, processed, or used.

Combine mobility, encryption, distributed resources with multiple providers, and a lack of open standards with economic cost pressure and even basic security capabilities seem daunting. Cloud simultaneously re-centralizes some resources while de-perimeterizing trust boundaries and distributing data. Understanding how the various layers map to traditional non-Cloud architecture is important, especially in relation to the Cloud deployment model used; there are significant trade-offs in integration, extensibility, cost, management, governance, compliance, and security.

Live by the Cloud, Die by the Cloud

Despite a tremendous amount of interest and momentum, Cloud is still very immature — pockets of innovation spread out across a long-tail of mostly-proprietary infrastructure-, platform-, and software-as-a-service offerings that do not provide for much in the way of or workload portability or interoperability.

Cloud is not limited to lower cost “server” functionality. With the fevered adoption of netbooks, virtualization, low-cost storage services, fixed/mobile convergence, the proliferation of “social networks,” and applications built to take advantage of all of this, Cloud becomes a single pane of glass for our combined computing experience. N.B., these powers are not inherently ours alone; the same upside can be used for wrongdoing.

In an attempt to whet the reader’s appetite in regards to how Cloud dramatically impacts the risk modeling, assumptions, and security postures of today, I will provide a reasonably crisp set of examples, chosen to bring pause:

Organizational and Operational Misalignment

The way in which most enterprise IT organizations are structured — in functional silos optimized to specialized, isolated functions — is diametrically opposed to the operational abstraction provided by Cloud.

The on-demand, elastic and self-service capabilities through simple interfaces and automated service layers abstract away core technology and support staff alike.

Few IT departments are prepared for what it means to apply controls, manage service levels, implement and manage security capabilities, and address compliance when the IT department is operationally irrelevant in that process. This leaves huge gaps in both identifying and managing risk, especially in outsourced models where ultimately the operational responsibility is “Cloudsourced” but the accountability is not.

The ability to apply specific security controls and measure compliance in mass-marketed Public Cloud services presents very real barriers to entry for enterprises who are heavily regulated, especially when balanced against the human capital (expertise) built-up by organizations.

Monoculture of Operating Systems, Virtualized Components, and Platforms

The standardization (de facto and de jure) on common interfaces to Cloud resources can expose uniform attack vectors that could affect one consumer, or, in the case of multi-tenant Public Cloud offerings, affect many. This is especially true in IaaS offerings where common sets of abstraction layers (such as hypervisors,) prototyped OS/application bundles (usually in the form of virtual machines) and common sets of management functions are used — and used to extend and connect the walled garden internal assets of enterprises to the public or semi-public Cloud environments of service providers operating infrastructure in proxy.

While most attack vectors target applications and information at the Infostructure layer or abuse operating systems and assorted hardware at the Infrastructure layer, the Metastructure layer is beginning to show signs of stress also. Recent attacks against key Metastructure elements such as BGP and DNS indicate that aging protocols do not fare well.

Segmentation and Isolation In Multi-tenant environments

Multi-tenancy in the Cloud (whether in the Public or Private Cloud contexts) brings new challenges to trust, privacy, resiliency and reliability model assertions by providers.  Many of these assertions are based upon the premise that that we should trust — without reliably provable models or evidence — that in the absence of relevant illustration, Cloud is simply trustworthy in all of these dimensions, despite its immaturity. Vendors claim “airtight” information, process, application, and service, but short of service level agreements, there is little to demonstrate or substantiate the claims that software-enabled Cloud Computing — however skinny the codebase may be — is any more (or less) secure than what we have today, especially with commercialized and proprietary implementations.

In multi-tenant Cloud offerings, exposures can affect millions, and placing some types of information in the care of others without effective compensating controls may erode the ROI valuation offered by Cloud in the first place, and especially so as the trust boundaries used to demarcate and segregate workloads of different consumers are provided by the same monoculture operating system and virtualization platforms described above.

Privacy of Data/Metadata, Exfiltration, and Leakage

With increased adoption of Cloud for sensitive workloads, we should expect innovative attacks against Cloud assets, providers, operators, and end users, especially around the outsourcing and storage of confidential information. The uptake is that solutions focused on encryption, at rest and in motion, will have the side effect of more and more tools (legitimate or otherwise) losing visibility into file systems, application/process execution, information and network traffic. Key management becomes remarkably relevant once again — on a massive scale.

Recent proof-of-concepts such as so-called side- channel attacks demonstrate how it is possible to determine where a specific virtual instance is likely to reside in a Public multi-tenant Cloud and allow an attacker to instantiate their own instance and cause it to be located such that it is co-resident with the target. This would potentially allow for sniffing and exfiltration of confidential data — or worse, potentially exploit vulnerabilities which would violate the sanctity of isolated workloads within the Cloud itself.

Further, given workload mobility — where the OS, applications and information are contained in an instance represented by a single atomic unit such as a virtual machine image — the potential for accidental or malicious leakage and exfiltration is real. Legal intercept, monitoring, forensics, and attack detection/incident response are heavily impacted, especially at the volume and levels of traffic envisioned by large Cloud providers, creating blind spots in ways we can’t fathom today.

Inability to Deploy Compensating or Detective Controls

The architecture of Cloud services — as abstract as they ought to be — means that in many cases the security of workloads up and down the stack are still dependent upon the underlying platform for enforcement. This is problematic inasmuch as the constructs representing compute, networking and storage resources — and security — are in many cases themselves virtualized.

Further we are faced with more stealthy and evasive malware that is able to potentially evade detection while co-opting (or rootkitting) not only software and hypervisors, but exploiting vulnerabilities in firmware and hardware such as CPU chipsets.

These sorts of attack vectors are extremely difficult to detect let alone defend against. Referring back to the monoculture issue above, a so-called blue- pilled hypervisor, uniform across tens of thousands of compute nodes providing multi-tenant Cloud services could be catastrophic. It is simply not yet feasible to provide parity in security capabilities between physical and Cloud environments; the maturity of solutions just isn’t there.

These are heady issues and should not be taken lightly when considering what workloads and services are candidates for various Cloud offerings.

What’s old is news again…

Perhaps it is worth adapting familiar attack taxonomies to Cloud.

Botnets that previously required massive malware- originated endpoint compromise in order to function can easily activate in standardized fashion, in apparently legitimate form, and in large numbers by criminals who wish to harness the organized capabilities of Bots without the effort. Simply use stolen credit cards to establish fake accounts using a provider’s Infrastructure-as-a-Service and hundreds or thousands of distributed images could be activated in a very short timeframe.

Existing security threats such as DoS/DDoS attacks, SPAM and phishing will continue to be a prime set of tools for the criminal ecosystem to leverage the distributed and well-connected Cloud as well as targeted attacks against telecommuters using both corporate and consumerized versions of Cloud services.

Consider a new take on an old problem based on ecommerce: Click-fraud. I frame this new embodiment as something called EDoS — economic denial of sustainability. Distributed Denial of Service (DDoS) attacks are blunt force trauma. The goal, regardless of motive, is to overwhelm infrastructure and remove from service a networked target by employing a distributed number of attackers. An example of DDoS is where a traditional botnet is activated to swarm/overwhelm an Internet connected website using an asynchronous attack which makes the site unavailable due to an exhaustion of resources (compute, network, or storage.)

EDoS attacks, however, are death by a thousand cuts. EDoS can also utilize distributed attack sources as well as single entities, but works by making legitimate web requests at volumes that may appear to be “normal” but are done so to drive compute, network, and storage utility billings in a cloud model abnormally high.

An example of EDoS as a variant of click fraud is where a botnet is activated to visit a website whose income results from ecommerce purchases. The requests are all legitimate but purchases are never made. The vendor has to pay the cloud provider for increased elastic use of resources but revenue is never recognized to offset them.

We have anti-DDoS capabilities today with tools that are quite mature. DDoS is generally easy to spot given huge increases in traffic. EDoS attacks are not necessarily easy to detect, because the instrumentation and business logic is not present in most applications or stacks of applications and infrastructure to provide the correlation between “requests” and “ successful transactions.” In theexample above, increased requests may look like normal activity. Many customers do not invest in this sort of integration and Cloud providers generally will not have visibility into applications that they do not own.

Ultimately the most serious Cloud concern is presented by way of the “stacked turtles” analogy: layer upon layer of complex interdependencies at the Infastructure, Metastructure and Infostructure layers, predicated upon fragile trust models framed upon nothing more than politeness. Without re-engineering these models, strengthening the notion of (id)entity management, authentication and implementing secure protocols, we run the risk of Cloud simply obfuscating the fragility of the supporting layers until something catastrophic occurs.

Combined with where and how our data is created, processed, accessed, stored, and backed up — and by whom and using whose infrastructure — Cloud yields significant concerns related to on-going security, privacy, compliance and resiliency.

Moving Forward – Critical Areas of Focus

The Cloud Security Alliance (http://www. cloudsecurityalliance.org) issued its “Guidance for Critical Areas of Focus” related to Cloud Computing Security and defined fifteen domains of concern:

  • Cloud Architecture
  • Information lifecycle management
  • Governance and Enterprise Risk Management
  • Compliance & Audit
  • General Legal
  • eDiscovery
  • Encryption and Key Management
  • Identity and Access Management
  • Storage
  • Virtualization
  • Application Security
  • Portability & Interoperability
  • Data Center Operations Management
  • Incident Response, Notification, Remediation
  • “Traditional” Security impact (business continuity, disaster recovery, physical security)

The sheer complexity of the interdependencies between the Infrastructure, Metastructure and Infostructure layers makes it almost impossible to recommend focusing on only a select subset of these items since all are relevant and important.

Nevertheless, those items in boldface most deserve initial focus just to retain existing levels of security, resilience, and compliance while information and applications are moved from the walled gardens of the private enterprise into the care of others.

Attempting to retain existing levels of security will consume the majority of Cloud transition effort.  Until we see an expansion of available solutions to bridge the gaps between “traditional” IT and dynamic infrastructure 2.0 capabilities, any company can only focus on the traditional security elements of sound design, encryption, identity, storage, virtualization and application security. Similarly, until a standardized set of methods allow well-defined interaction between the Infrastructure, Metastructure and Infostructure layers, companies will be at the mercy of industry for instrumenting, much less auditing,

Cloud elements — yet, as was already stated, the very sameness of standardization creates shared risk. As with any change of this magnitude, the potential of Cloud lies between its trade-offs. In security terms, this “big switch” surrenders visibility and control so as to gain agility and efficiency. The question is, how to achieve a net positive result?

Well-established enterprise security teams who optimize their security spend on managing risk versus purely threat, should not be surprised by Cloud. To these organizations, adapting their security programs to the challenges and opportunities provided by Cloud is business as usual. For organizations unprepared for Cloud, the maturity of security programs they can buy will quickly be outmoded.

Summary

The benefits of Cloud are many. The challenges are substantial. How we deal with these challenges and their organizational, operational, architectural, and technical impacts will fundamentally change the way in which we think about assessing and assuring the security of our assets.

The Cloud & eHarmony’s 29 Dimensions Of Compatability…

November 23rd, 2009 7 comments

I speak to many customers — large companies in numerous verticals and service providers —  who are for the reasons we are all very well aware of, engaging in projects large and small focused on Cloud adoption.

On the enterprise side, the dialog almost inevitably goes like this:

We’re working on taking applications and data which are not heavily regulated/compliance scoped, business critical or contain sensitive information and move them to a public cloud provider like AWS — we’re also considering virtual private clouds to use public cloud infrastructure in private ways.

We’ve had great success with low-hanging fruit and grid-like utility offerings, but we’re having a bear of a time with real “applications” — taking them as they run today internally and making them run the same way on someone elses’ kit.  It’s not always the application, either, but rather the attendant dependencies on other critical IT-centric functions that cause the issues (Ed: “metastructure”)

In parallel we’re engaging in building private clouds for critical applications that either have complex development and support/integration issues that are not ready for running on others’ infrastructure and/or have compliance and regulatory requirements that prevent us from moving them off our infrastructure.

We’re continuing to invest and optimize our internal virtualization deployments; we’re reducing footprint but really increasing compute, network and storage density.  Don’t let the smaller physical space fool you, we’re getting bigger in more efficient floor plans.  We’ve standardized on VMware. We’re figuring out how vSphere and vCloud intersect and what that means in the long term and how that impacts our choice of Cloud providers.

We understand that using the same vendor we use for virtualization to ultimately deliver our private cloud should yield easier portability and workload interoperability, but we’re worried about vendor lock-in…sort of.

We’d really like to be able to move workloads/applications/information in and out of private clouds to public/virtual public offerings and support workloads/applications/information that were born in the cloud on our private cloud, too.  These present a whole host of security and lifecycle management issues.

In the long term, what we want to do is build a self-service portal (not unlike apps.gov) that depending upon business logic and security/compliance requirements, etc. will allow a business constituent consumer to deploy packaged or bespoke workloads/application/information and not have to care about where it runs.

That would be nice.  We’d like to be able to do that with the thousands of applications we already support today.

We’re investigating cloud brokers currently, but most don’t do what they advertise they do or have severe limitations. While they often plug the gaps between the various cloud providers, we trade one vendor lock-in problem for another with custom orchestration and provisioning frameworks.  We’re trying to roll our own — cobbling together bits and pieces — but it’s an integration nightmare.

The lack of standard APIs and competing implementation semantics with immature sets of management, security, provisioning, orchestration and governance solutions really makes this all very, very difficult.

What should we do?

This story is the same over and over.

It’s literally the Cloud equivalent of eHarmony.com’s 29 dimensions of compatibility; it’s such a multidimensional problem in large enterprises that have a huge number of applications (thousands) and a ton of sunk infrastructure, mature decades-old operational practices, cultural dispositions, and economic pressures that it’s hard to figure out what to do.

For large enterprises (and the service providers who cater to them) Cloud is not a simple undertaking, at least not to those who have to deal with bridging the gap between the “old world” and the new shiny bits glimmering off in the distance.

Consider that the next time you hear a story of cloud successes and scrutinize what that really means.

/Hoff

ENISA launches Cloud Computing Security Risk Assessment Document

November 20th, 2009 1 comment

ENISA-LOGOENISA (the European Network and Information Security Agency) today launched their 124 page report on Cloud Computing Security Risk Assessment.

At first glance it’s an excellent read and will be a fantastic accompaniment to the the CSA’s guidance.  I plan to dig into it more over the weekend.  I really appreciate the risk assessment approach which allows folks to prioritize their efforts on understanding the relevant high-level issues associed with Cloud.

Very well done.  I look forward to seeing how CSA and ENISA can further work together on upcoming projects!  I think the European perspective will help bring some balance and alternative views on Cloud in regards to legal and compliance issues specifically.

You can find the document here.

ENISA, supported by a group of subject matter expert comprising representatives from Industries, Academia and Governmental Organizations, has conducted, in the context of the Emerging and Future Risk Framework project, an risks assessment on cloud computing business model and technologies. The result is an in-depth and independent analysis that outlines some of the information security benefits and key security risks of cloud computing. The report provide also a set of practical recommendations.