Rational Survivability

For those of you who are not in the security space and may not have read the Cloud Security Alliance’s “Guidance for Critical Areas of Focus,” you may have missed the “Cloud Architectural Framework” section I wrote as a contribution.

We are working on improving the entire guide, but I thought I would re-publish the Cloud Architectural Framework section and solicit comments here as well as “set it free” as a stand-alone reference document.

Please keep in mind, I wrote this before many of the other papers such as NIST’s were officially published, so the normal churn in the blogosphere and general Cloud space may mean that  some of the terms and definitions have settled down.

I hope it proves useful, even in its current form (I have many updates to make as part of the v2 Guidance document.)

/Hoff

Cloud Computing (“Cloud”) is a catch-all term that describes the evolutionary development of many existing technologies and approaches to computing that at its most basic, separates application and information resources from the underlying infrastructure and mechanisms used to deliver them with the addition of elastic scale and the utility model of allocation.  Cloud computing enhances collaboration, agility, scale, availability and provides the potential for cost reduction through optimized and efficient computing.

More specifically, Cloud describes the use of a collection of distributed services, applications, information and infrastructure comprised of pools of compute, network, information and storage resources.  These components can be rapidly orchestrated, provisioned, implemented and decommissioned using an on-demand utility-like model of allocation and consumption.  Cloud services are most often, but not always, utilized in conjunction with and enabled by virtualization technologies to provide dynamic integration, provisioning, orchestration, mobility and scale.

While the very definition of Cloud suggests the decoupling of resources from the physical affinity to and location of the infrastructure that delivers them, many descriptions of Cloud go to one extreme or another by either exaggerating or artificially limiting the many attributes of Cloud.  This is often purposely done in an attempt to inflate or marginalize its scope.  Some examples include the suggestions that for a service to be Cloud-based, that the Internet must be used as a transport, a web browser must be used as an access modality or that the resources are always shared in a multi-tenant environment outside of the “perimeter.”  What is missing in these definitions is context.

From an architectural perspective given this abstracted evolution of technology, there is much confusion surrounding how Cloud is both similar and differs from existing models and how these similarities and differences might impact the organizational, operational and technological approaches to Cloud adoption as it relates to traditional network and information security practices.  There are those who say Cloud is a novel sea-change and technical revolution while others suggest it is a natural evolution and coalescence of technology, economy, and culture.  The truth is somewhere in between.

There are many models available today which attempt to address Cloud from the perspective of academicians, architects, engineers, developers, managers and even consumers. We will focus on a model and methodology that is specifically tailored to the unique perspectives of IT network and security professionals.

The keys to understanding how Cloud architecture impacts security architecture are a common and concise lexicon coupled with a consistent taxonomy of offerings by which Cloud services and architecture can be deconstructed, mapped to a model of compensating security and operational controls, risk assessment and management frameworks and in turn, compliance standards.

Setting the Context: Cloud Computing Defined

Understanding how Cloud Computing architecture impacts security architecture requires an understanding of Cloud’s principal characteristics, the manner in which cloud providers deliver and deploy services, how they are consumed, and ultimately how they need to be safeguarded.

The scope of this area of focus is not to define the specific security benefits or challenges presented by Cloud Computing as these are covered in depth in the other 14 domains of concern:

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

We will discuss the various approaches and derivative offerings of Cloud and how they impact security from an architectural perspective using an in-process model developed as a community effort associated with the Cloud Security Alliance.

Principal Characteristics of Cloud Computing

Cloud services are based upon five principal characteristics that demonstrate their relation to, and differences from, traditional computing approaches:

1. Abstraction of Infrastructure
   The compute, network and storage infrastructure resources are abstracted from the application and information resources as a function of service delivery. Where and by what physical resource that data is processed, transmitted and stored on becomes largely opaque from the perspective of an application or services’ ability to deliver it.  Infrastructure resources are generally pooled in order to deliver service regardless of the tenancy model employed – shared or dedicated.  This abstraction is generally provided by means of high levels of virtualization at the chipset and operating system levels or enabled at the higher levels by heavily customized filesystems, operating systems or communication protocols.
2. Resource Democratization
   The abstraction of infrastructure yields the notion of resource democratization – whether infrastructure, applications, or information – and provides the capability for pooled resources to be made available and accessible to anyone or anything authorized to utilize them using standardized methods for doing so.
3. Services Oriented Architecture
   As the abstraction of infrastructure from application and information yields well-defined and loosely-coupled resource democratization, the notion of utilizing these components in whole or part, alone or with integration, provides a services oriented architecture where resources may be accessed and utilized in a standard way.  In this model, the focus is on the delivery of service and not the management of infrastructure.
4. Elasticity/Dynamism
   The on-demand model of Cloud provisioning coupled with high levels of automation, virtualization, and ubiquitous, reliable and high-speed connectivity provides for the capability to rapidly expand or contract resource allocation to service definition and requirements using a self-service model that scales to as-needed capacity.  Since resources are pooled, better utilization and service levels can be achieved.
5. Utility Model Of Consumption & Allocation
   The abstracted, democratized, service-oriented and elastic nature of Cloud combined with tight automation, orchestration, provisioning and self-service then allows for dynamic allocation of resources based on any number of governing input parameters.  Given the visibility at an atomic level, the consumption of resources can then be used to provide an “all-you-can-eat” but “pay-by-the-bite” metered utility-cost and usage model. This facilitates greater cost efficiencies and scale as well as manageable and predictive costs.

Cloud Service Delivery Models

Three archetypal models and the derivative combinations thereof generally describe cloud service delivery.  The three individual models are often referred to as the “SPI Model,” where “SPI” refers to Software, Platform and Infrastructure (as a service) respectively and are defined thusly[1]:

1. 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.
2. 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, network, servers, operating systems, or storage, but the consumer has control over the deployed applications and possibly application hosting environment configurations.
   
3. 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.

The OpenCrowd Cloud Solutions Taxonomy shown in Figure 1 provides an excellent reference that demonstrates the swelling ranks of solutions available today in each of the models above.

Narrowing the scope or specific capabilities and functionality within each of the *aaS offerings or employing the functional coupling of services and capabilities across them may yield derivative classifications.  For example “Storage as a Service” is a specific sub-offering with the IaaS “family,”  “Database as a Service” may be seen as a derivative of PaaS, etc.

Each of these models yields significant trade-offs in the areas of integrated features, openness (extensibility) and security.  We will address these later in the document.

Figure 1 - The OpenCrowd Cloud Taxonomy

Cloud Service Deployment and Consumption Modalities

Regardless of the delivery model utilized (SaaS, PaaS, IaaS,) there are four primary ways in which Cloud services are deployed and are characterized:

1. Private
   Private Clouds are provided by an organization or their designated service provider and offer a single-tenant (dedicated) operating environment with all the benefits and functionality of elasticity and the accountability/utility model of Cloud.The physical infrastructure may be owned by and/or physically located in the organization’s datacenters (on-premise) or that of a designated service provider (off-premise) with an extension of management and security control planes controlled by the organization or designated service provider respectively.

   The consumers of the service are considered “trusted.”  Trusted consumers of service are those who are considered part of an organization’s legal/contractual
   umbrella including employees, contractors, & business partners.  Untrusted consumers are those that may be authorized to consume some/all services but are not logical extensions of the organization.

2. Public
   Public Clouds are provided by a designated service provider and may offer either a single-tenant (dedicated) or multi-tenant (shared) operating environment with all the benefits and functionality of elasticity and the  accountability/utility model of Cloud.
   The physical infrastructure is generally owned by and managed by the designated service provider and located within the provider’s datacenters (off-premise.)  Consumers of Public Cloud services are considered to be untrusted.
3. Managed
   Managed Clouds are provided by a designated service provider and may offer either a single-tenant (dedicated) or multi-tenant (shared) operating environment with all the benefits and functionality of elasticity and the  accountability/utility model of Cloud.The physical infrastructure is owned by and/or physically located in the organization’s datacenters with an extension of management and security control planes controlled by the designated service provider.  Consumers of Managed Clouds may be trusted or untrusted.

4. Hybrid
   Hybrid Clouds are a combination of public and private cloud offerings that allow for transitive information exchange and possibly application compatibility and portability across disparate Cloud service offerings and providers utilizing standard or proprietary methodologies regardless of ownership or location.  This model provides for an extension of management and security control planes.  Consumers of Hybrid Clouds may be trusted or untrusted.

The difficulty in using a single label to describe an entire service/offering is that it actually attempts to describe the following elements:

• Who manages it
• Who owns it
• Where it’s located
• Who has access to it
• How it’s accessed

The notion of Public, Private, Managed and Hybrid when describing Cloud services really denotes the attribution of management and the availability of service to specific consumers of the service.

It is important to note that often the characterizations that describe how Cloud services are deployed are often used interchangeably with the notion of where they are provided; as such, you may often see public and private clouds referred to as “external” or “internal” clouds.  This can be very confusing.

The manner in which Cloud services are offered and ultimately consumed is then often described relative to the location of the asset/resource/service owner’s management or security “perimeter” which is usually defined by the presence of a “firewall.”

While it is important to understand where within the context of an enforceable security boundary an asset lives, the problem with interchanging or substituting these definitions is that the notion of a well-demarcated perimeter separating the “outside” from the “inside” is an anachronistic concept.

It is clear that the impact of the re-perimeterization and the erosion of trust boundaries we have seen in the enterprise is amplified and accelerated due to Cloud.  This is thanks to ubiquitous connectivity provided to devices, the amorphous nature of information interchange, the ineffectiveness of traditional static security controls which cannot deal with the dynamic nature of Cloud services and the mobility and velocity at which Cloud services operate.

Thus the deployment and consumption modalities of Cloud should be thought of not only within the construct of “internal” or “external” as it relates to asset/resource/service physical location, but also by whom they are being consumed and who is responsible for their governance, security and compliance to policies and standards.

This is not to suggest that the on- or off-premise location of an asset/resource/information does not affect the security and risk posture of an organization, because it does, but it also depends upon the following:

• The types of application/information/services being managed
• Who manages them and how
• How controls are integrated
• Regulatory issues

Table 1 illustrates the summarization of these points:

Table 1 - Cloud Computing Service Deployment

As an example, one could classify a service as IaaS/Public/External (Amazon’s AWS/EC2 offering is a good example) as well as SaaS/Managed/Internal (an internally-hosted, but third party-managed custom SaaS stack using Eucalyptus, as an example.)

Thus when assessing the impact a particular Cloud service may have on one’s security posture and overall security architecture, it is necessary to classify the asset/resource/service within the context of not only its location but also its criticality and business impact as it relates to management and security.  This means that an appropriate level of risk assessment is performed prior to entrusting it to the vagaries of “The Cloud.”

Which Cloud service deployment and consumption model is used depends upon the nature of the service and the requirements that govern it.  As we demonstrate later in this document, there are significant trade-offs in each of the models in terms of integrated features, extensibility, cost, administrative involvement and security.

Figure 2 - Cloud Reference Model

It is therefore important to be able to classify a Cloud service quickly and accurately and compare it to a reference model that is familiar to an IT networking or security professional.

Reference models such as that shown in Figure 2 allows one to visualize the boundaries of *aaS definitions, how and where a particular Cloud service fits, and also how the discrete *aaS models align and interact with one another.  This is presented in an OSI-like layered structure with which security and network professionals should be familiar.

Considering each of the *aaS models as a self-contained “solution stack” of integrated functionality with IaaS providing the foundation, it becomes clear that the other two models – PaaS and SaaS – in turn build upon it.

Each of the abstract layers in the reference model represents elements which when combined, comprise the services offerings in each class.

IaaS includes the entire infrastructure resource stack from the facilities to the hardware platforms that reside in them. Further, IaaS incorporates the capability to abstract resources (or not) as well as deliver physical and logical connectivity to those resources.  Ultimately, IaaS provides a set of API’s which allows for management and other forms of interaction with the infrastructure by the consumer of the service.

Amazon’s AWS Elastic Compute Cloud (EC2) is a good example of an IaaS offering.

PaaS sits atop IaaS and adds an additional layer of integration with application development frameworks, middleware capabilities and functions such as database, messaging, and queuing that allows developers to build applications which are coupled to the platform and whose programming languages and tools are supported by the stack.  Google’s AppEngine is a good example of PaaS.

SaaS in turn is built upon the underlying IaaS and PaaS stacks and provides a self-contained operating environment used to deliver the entire user experience including the content, how it is presented, the application(s) and management capabilities.

SalesForce.com is a good example of SaaS.

It should therefore be clear that there are significant trade-offs in each of the models in terms of features, openness (extensibility) and security.

Figure 3 - Trade-off’s Across *aaS Offerings

Figure 3 demonstrates the interplay and trade-offs between the three *aaS models:

• Generally, SaaS provides a large amount of integrated features built directly into the offering with the least amount of extensibility and a relatively high level of security.

• PaaS generally offers less integrated features since it is designed to enable developers to build their own applications on top of the platform and is therefore more extensible than SaaS by nature, but due to this balance trades off on security features and capabilities.

• IaaS provides few, if any, application-like features, provides for enormous extensibility but generally less security capabilities and functionality beyond protecting the infrastructure itself since it expects operating systems, applications and content to be managed and secured by the consumer.

The key takeaway from a security architecture perspective in comparing these models is that the lower down the stack the Cloud service provider stops, the more security capabilities and management the consumer is responsible for implementing and managing themselves.

This is critical because once a Cloud service can be classified and referenced against the model, mapping the security architecture, business and regulatory or other compliance requirements against it becomes a gap-analysis exercise to determine the general “security” posture of a service and how it relates to the assurance and protection requirements of an asset.

Figure 4 below shows an example of how mapping a Cloud service can be compared to a catalog of compensating controls to determine what existing controls exist and which do not as provided by either the consumer, the Cloud service provider or another third party.

Once this gap analysis is complete as governed by the requirements of any regulatory or other compliance mandates, it becomes much easier to determine what needs to be done in order to feed back into a risk assessment framework to determine how the gaps and ultimately how the risk should be addressed: accept, transfer, mitigate or ignore.

Conclusion

Understanding how architecture, technology, process and human capital requirements change or remain the same when deploying Cloud Computing services is critical.   Without a clear understanding of the higher-level architectural implications of Cloud services, it is impossible to address more detailed issues in a rational way.

The keys to understanding how Cloud architecture impacts security architecture are a common and concise lexicon coupled with a consistent taxonomy of offerings by which Cloud services and architecture can be deconstructed, mapped to a model of compensating security and operational controls, risk assessment and management frameworks and in turn, compliance standards.

It’s that time again.  I am compelled after witnessing certain behaviors to play anthropologist and softly whisper my observations in your ear.

You may be familiar with Beckett’s “Waiting For Godot”*:

Waiting for Godot follows two days in the lives of a pair of men who divert themselves while they wait expectantly and unsuccessfully for someone named Godot to arrive. They claim him as an acquaintance but in fact hardly know him, admitting that they would not recognise him were they to see him. To occupy themselves, they eat, sleep, converse, argue, sing, play games, exercise, swap hats, and contemplate suicide — anything “to hold the terrible silence at bay”

Referencing my prior post about the state of Cloud security, I’m reminded of the fact that as a community of providers and consumers, we continue to wait for the security equivalent of Godot to arrive and solve all of our attendant Cloud security challenges with the offer of some mythical silver bullet.  We wait and wait for our security Godot as I mix metaphors and butcher Beckett’s opus to pass the time.

Here’s a classic illustration of hoping our way to Cloud security from a ComputerWeekly post titled “Cryptography breakthrough paves way to secure cloud services:”

A research student who had a summer job at IBM, has cracked a cryptography problem that has baffled experts for over 30 years. The breakthrough may pave the way to secure cloud computing services.

This sounds fantastic and much has been written about this “homomorphic encryption,” with many people espousing how encryption will “solve our Cloud security problems.”

It’s a very interesting concept, but as to paving the “…path to secure cloud computing,” the reality is that it won’t.  At least not in isolation and not without some serious scale in ancillary support mechanisms including non-trivial issues like federated identity.

Bruce Schneier wades in with his assessment:

Unfortunately — you knew that was coming, right? — Gentry’s scheme is completely impractical…Despite this, IBM’s PR machine has been in overdrive about the discovery. Its press release makes it sound like this new homomorphic scheme is going to rewrite the business of computing: not just cloud computing, but “enabling filters to identify spam, even in encrypted email, or protection information contained in electronic medical records.” Maybe someday, but not in my lifetime.

The reality is that in addition to utilizing encryption — both existing and new approaches — we still continue to need all the usual suspects as they deal with the fact that fundamentally we’re still in a cycle of constructing insecure code in infostructure sitting atop infrastructure and metastructure that has its own fair share of growing up to do.

As a security architect, engineer, or manager, you need to continue to invest in understanding how what you have does or does not work within the context of Cloud.

You will likely find that you will need to continue to invest in threat and trust models analysis, risk management, vulnerability assessment, (id)entity management, compensating controls implemented as hardware and software technology solutions such as firewalls, IDP, DLP, and policy instantiation, etc. as well as host of modified and new approaches to dealing with Cloud-specific implementation challenges, especially those based on virtualization and massive scale with multitenancy.

These problems don’t solve themselves and we are simply not changing our behavior.  We wait and wait for our Godot.

So here’s the obligatory grumpy statement of the obvious as providers of solutions and services churn to deliver more capable solutions to put in your hands:

There is no silver bullet, just a lot of silver buckshot.  Use it all.  You’re going to have to deal with the cards we are dealt for the foreseeable future whilst we retool our approach in the longer term and technology equalizes some of our shortfalls.

Godot is not coming and you likely wouldn’t recognize him if he showed up anyway because he’d be dressed in homomorphic invisible hotpants…

Get on with it.  Treat security as the enterprise architecture element it is and use Cloud as the excuse to make things better by working on the things that matter.

If Godot does happen to show up, tell him I want my weed whacker back that he borrowed last summer.

/Hoff

* Wikipedia

There are voices raging in my head thanks to the battling angel and devil sitting on my shoulders.

These voices echo the security-focused protagonist and antagonist perspectives of Cloud Computing adoption.

The devil urges immediate adoption and suggests the Cloud is as (in)secure as it needs to be while still providing value.

The angel maintains that the Cloud, whilst a delightful place to vacation, is ready only for those who are pure of heart and traffic in non-sensitive, non-mission-critical data.

To whom do I (or we) listen?

The answer is a measured and practical one that we know already because we’ve given it many times before.

Is the Cloud Secure?  That’s  a silly question.  Is the Cloud “secure enough” is really the question that should be asked, and of course,  the answer is entirely contextual.

My co-worker, James Urquhart, wrote a great post today in which he summarized quite a few healthy debates that are good for Cloud Computing as they encourage discourse and debate.  One of them relates to the difference between the consumer and small/midsize business versus enterprise as it relates to Cloud adoption.  This is quite relevant to my point about “context” above, so for the purpose of this discussion, I’m referring to the enterprise.

To wit, enterprises aren’t as dumb as (we) vendors want them to be; they seize opportunity as it befits them and most times apply a reasonable amount of due care, diligence and evaluation before they leap headlong into course corrections offered by magical disruptive innovation.  There are market dynamics at play that are predictable and yet so many times we collectively gasp at the patterns of behaviors of technology adoption as though we’ve never witnessed them before.

Cloud is no different in that regard.  See my post regarding this behavior titled “Most CIO’s Not Sold On Cloud?  Good, They Shouldn’t Be.”

When I see commentary from CEO’s of leading security companies (such as RSA’s Art Coviello and even my own, John Chambers) that highlight security as an enormous concern in Cloud, I urge people to reflect back on any of the major shifts they’ve seen in IT the last 15 years and consider which shoulder-chirper they listened to and why.

Suggesting that enterprises aren’t already conscious of what the Cloud means to their operational and security models is intellectually dishonest, really.

We’ve all seen convenience, agility and economics stomp all over security before and here’s how this movie will play out:

Cloud will reach a critical mass wherein the technology and operational models mature to a good-enough point, enough time passes without a significant number of material breaches or outages that disrupt confidence and then it becomes “accepted.”  Security, based upon how, where, why and when we invest will always play catch-up.  How much depends on how good a job we do to push the agenda.

The reality is that broad warnings about security in the Cloud are fine; they help remind and reinforce the fact that we need to do better, and quite frankly, I think we are.  So we can either chirp about how bad things are, or we can do something about it.

The good news is that even with the froth and churn, there is such a groundswell of activity by many groups (like the Cloud Security Alliance and the Jericho Forum) that we’re seeing an unprecedented attempt by both suppliers and consumers to do a better job of baking security in earlier.  The problem is that many people can’t see the forest for the trees; expectations of how quickly things can change are distorted and so everything appears to be an instant failure.  That’s sad.

Of course Cloud Security is not perfect, but in measure, the dialog, push for standards and recognition of need (as well as many roadmapped solutions I’m privy to) shows me that our overall response is a heck of a lot better that I’ve seen it in the past.

We’re certainly still playing catch up on the technology front and working toward better ways of dealing with instantiating business process on top of it all, but I’m quite optimistic that we’re compressing the timeframe of defining and ultimately delivering improved security capabilities in Cloud computing.

In the meantime, the compelling market forces of Cloud continue to steamroll onward, and so these apocalyptic assessments of Cloud Security readiness are irrelevant as we continue to see companies large and small utilize Cloud Computing to do things faster, better, more efficiently, cost effectively and with a level of security that meets their needs, which in the end is all that matters.

At the same point — and this is where the devil will prove out in the details — execution is what matters.

/Hoff

I was brainstorming a couple of Cloud things with Doug Neal and Mark Masterson the other day and whilst grappling for an appropriately delicious analog for Cloud Computing, my 5-year old approached me and asked to play the “burping beer game (iBeer)” on my iPhone.  Aha!

Whilst I have often grouped Cloud Computing with the consumerization of IT (and the iPhone as it’s most visible example) together in concert in my disruptive innovation presentations, I never really thought of them as metaphors for one another.

When you think of it, it’s really a perfect visual.

The iPhone is a fantastic platform that transforms using technology that has been around for quite a while into a more useful experience.  The iPhone converges many technologies and capabilities under a single umbrella and changes the way in which people interact with their data and other people.

In some cases we have proprietary functions and capabilities which are locked into the provider and platform.  We pay for this forced allegiance, but we tolerate it as necessary.  We also see the inventiveness and innovation of people for whom brute forcing their way into openness with jailbreaks is a reasonable alternative.

There’s lots of ankle biting as vendors and providers clamor to bring the familiar trademarks of the iPhone to their own platforms.  There are marketplaces being built around these platforms to open up new opportunities for collaboration, applications and experiences with the, gasp!, phones.

It’s true.  The iPhone is, at its heart, a phone, and we’ve had mobile phones forever.  Some complain that the iPhone is nothing more than a smartly packaged combination of technology we’ve already had for ages and that thanks to Moore’s law, we’re able to cram more and more stuff into smaller and smaller spaces.  That logic therefore dictates that the iPhone is the mini-me “mainframe” of mobility. 😉 And millions buy it still.  It’s like technology timesharing as the phone, Internet and mobility capabilities all compete for a timeshared swath of space in my pocket.

Yes, that’s right.  The iPhone is simply timesharing of functions on a phone. <snort>

To the detractors’ point, however, for all the innovation and exciting capabilities the iPhone brings, it has and continues to suffer from some seriously goofy limitations that in other platforms would be game stoppers, but people settle anyway, waiting for the technology to catch up and dealing with the implications as they become important (or not.)

The best example?  Cut and paste.  I had freaking cut & paste in my Newton 15 years ago.  The lack of C&P made certain things unusable on the iPhone let alone inconvenient and even insecure (having to copy and write-down complex passwords since I stored them in 1password, for example.)

However, I’ve purchased each revision of the iPhone as it came out and have been incrementally giddy with each new hardware/software combinaton, especially with the 3.0 software upgrade which finally gave me my beloved cut and paste 😉  The reality is that there are probably better solutions for my needs, but none that are so damned convenient and sexy to use.

The thing I love about my iPhone is that it’s not a piece of technology I think about but rather, it’s the way I interact with it to get what I want done.  It has its quirks, but it works…for millions of people.  Add in iTunes, the community of music/video/application artists/developers and the ecosystem that surrounds it, and voila…Cloud.

The point here is that Cloud is very much like the iPhone.  As Sir James (Urquhart) says “Cloud isn’t a technology, it’s an operational model.”  Just like the iPhone.

Cloud is still relatively immature and it doesn’t have all the things I want or need yet (and probably never will) but it will get to the point where its maturity and the inclusion of capabilities (such as better security, interoperability, more openness, etc.) will smooth its adoption even further and I won’t feel like we’re settling anymore…until the next version shows up on shelves.

But don’t worry, there’s an app for that.

/Hoff

I wanted to be able to take the work I did in developing a visual model to expose the component Cloud SPI layers into their requisite parts from an IT perspective and make it even easier to understand.

Specifically, my goal was to produce another visual and some terminology that would allow me to take it up a level so I might describe Cloud to someone who has a grasp on familiar IT terminology, but do so in a visual way.

I came up with extending the notion of infrastructure as a foundation and layering what I call metastructure and infostructure layers atop.

You can see how I define “metastructure” and “infostructure” in the diagram definitions to the left.

Essentially Infrastructure is comprised of all the compute, network and storage moving parts that we identify as infrastructure today.

Metastructure* is the protocols and mechanisms that provide the interface between the infrastructure layer and the applications and information above it.

Infostructure is the applications and information/content as well as the service definitions that depend upon the other substrates.

These groupings really align well and simplify how I talk about various elements of Cloud.

Specifically, these three layers line up remarkably well with the S, P, I layer demarcation points that I outlined in my Cloud Model (see the extensive discussion here) built before that I use in my Frogs presentation that has met with good reception thus far.

I can drill down as needed, but if I want to summarize from a security perspective where/what I am talking about, I now have three handy and easily understood set of macro-definitions to help me.

What do you think?  I know we’re all pretty buzzworded out these days, but this really seems to resonate with folks up and down the stack I have presented it to.

Update 6/21: Reuven Cohen posted a nice follow-up to this blog on his in regards to his “metaverse” concept.

/Hoff

* I first mentioned the concept of “metastructure” in a post back in Februrary in another Incomplete Thought titled “Incomplete Thought: What Should Come First…Cloud Portability or Interoperability“

Please excuse me if I’m late to the party bringing this up…

We talk a lot about the utility of Public Clouds to enable the cost-effective and scalable implementation of “server” functionality, whether that’s SaaS, PaaS, or IaaS model, the concept is pretty well understood: use someone else’s infratructure to host your applications and information.

As it relates to the desktop/client side of Cloud, we normally think about hosting the desktop/client capabilities as a function of Private Cloud capabilities; behind the firewall.  Whether we’re talking about terminal service-like capabilities and VDI, it seems to me people continue to think of this as a predominantly “internal” opportunity.

I don’t think people are talking enough about the client side of Cloud and desktop as a service (DaaS) and what this means:

If the physical access methods continue to get skinnier (smart phones, thin clients, client hypervisors, virtual machines, etc.) is there an opportunity for providers of Infrastructure as a Service to host desktop instances outside a corporate firewall?  If I can take advantage of all of the evolving technology in the space and couple it with the same sorts of policy advancements, networking and VPN functionality to connect me to IaaS server resources running in Private or Public Clouds, isn’t that a huge opportunity for further cost savings, distributed availability and potentially better security?

There are companies such as Desktone looking to do this very thing in a way to offset the costs of VDI and further the efforts of consolidation.  It makes a lot of sense for lots of reasons and despite my lack of hands-on exposure to the technology, it sure looks like we have the technical capability to do this today.   Dana Gardner wrote about this back in 2007 and it’s as valid a set of points then as it is now — albeit with a much bigger uptake in Cloud:

The stars and planets finally appear to be aligning in a way that makes utility-oriented delivery of a full slate of client-side computing and resources an alternative worth serious consideration. As more organizations are set up as service bureaus — due to such  IT industry developments as ITIL and shared services — the advent of off the wire everything seems more likely in many more places

I could totally see how Amazon could offer the same sorts of workstation utility as they do for server instances.

Will DaaS be the next frontier of consolidation in the enterprise?

If you’re considering hosting your service instances elsewhere, why not your desktops?  Citrix and VMware (as examples) seem to think you might…

/Hoff

Last week Kevin L. Jackson wrote an insightful article titled: Cloud Computing: The Dawn of Maneuver Warfare in IT Security.  I enjoyed Kevin’s piece but struggled with how I might respond: cheerleader or pundit.  I tried for a bit of both while I found witty references to OMD.*

Kevin’s essay is an interesting — if not hope-filled — glimpse into what IT Security could be as enabled by Cloud Computing and virtualization, were one to be able to suspend disbelief due to the realities of hefty dependencies on archaic protocols, broken trust models and huge gaps in technology and operational culture.  Readers of my blog will certainly recognize this from “The Four Horsemen of the Virtualization Security Apocalypse” and “The Frogs Who Desired a King: A Virtualization and Cloud Computing Security Fable”

To the converse, I’ve certainly also done my fair share of trying to change the world both by thought and action in the stance of “cheerleader”; I’ve been involved in everything from massive sensornet deployments to developing AI/Neural Networking based security technologies, so I think I’ve got a fair idea of what the balance looks like.  The salty pragmatist often triumphs, however…

Kevin’s article represents a futurist’s view, which is in no way a bad thing, but I fear it is too far disconnected from the realities of security and operational maturity outside of the navel:

The lead topic of every information technology (IT) conversation today is cloud computing. The key point within each of those conversations is inevitably cloud computing security.  Although this trend is understandable, the sad part is that these conversations will tend to focus on all the standard security pros, cons and requirements. While protecting data from corruption, loss, unauthorized access, etc. are all still required characteristics of any IT infrastructure, cloud computing changes the game in a much more profound way.

Certainly Cloud is a game changer, but just because the rules change does not mean the players do.  We haven’t solved those issues as they pertain to non-virtualized or Cloud infrastructure, so while sad, it’s a crushing truth we have to address.  Further, to get from “here” to “there,” we do need to focus on these issues because that is how we are measured today; most of us don’t get to start from scratch.

To that point, check out “Incomplete Thought: Cloud Security IS Host-Based…At The Moment” for why this gap exists in the first place.

I should make it clear that this does not mean I necessarily disagree with the exploration of Kevin’s future state, in fact I’ve written about it in various forms several times, but it’s important to separate what Cloud will deliver from a security perspective in the short term from the potential of what it can possibly deliver in the long term; this applies to both the cultural and technical perspectives.

I think the most significant challenges I had in reading Kevin’s article revolved around three things:

1. Mixing tenses in some key spots seemed to imply that out of the box today, Cloud Computing can deliver on the promises Kevin is describing now.  Given the audience, this can lead to unachievable expectations
2. The disconnect between the public, private and military sectors with an over-reliance on military analogies as a model representing an ideal state of security operations and strategy can be startling
3. Unrealistic portrayals of where we are with the maturity of Cloud/virtualization mobility, portability, interoperability and security capabilities

In the short term, there are certainly incremental improvements will occur with respect to security thanks to the “lubricant-like” functionality provided by virtualization and Cloud.

These “improvements” however represent gains mostly in automation of manual processes and a resultant increase in efficiency rather than a dramatic improvement in survivability or security given what we have to work with today.

The lack of heterogeneous closed-loop autonomics, governance and orchestration in conjunction with the fact that a huge amount of infrastructure and applications are not virtualization- or Cloud-ready means this picture a vision, not a mission.

Kevin juxtaposes the last few decades of static, Maginot Line IT/Information Security “defense-in-depth” strategy with the unpredictable and “agile, hostile and mobile” notions of military warfighter maneuvers to compare and contrast what he suggests Cloud will deliver with an enlightened state of security capabilities:

Until now, IT security has been akin to early 20th century warfare.  After surveying and carefully cataloging all possible threats, the line of business (LOB) manager and IT professional would debate and eventually settle on appropriate and proportional risk mitigation strategies. The resulting IT security infrastructures and procedures typically reflected a “defense in depth” strategy, eerily reminiscent of the French WWII Maginot line . Although new threats led to updated capabilities, the strategy of extending and enhancing the protective barrier remained. Often describe as an “arms race”, the IT security landscape has settled into ever escalating levels of sophisticated attack versus defense techniques and technologies. Current debate around cloud computing security has seemed to continue without the realization that there is a fundamental change now occurring. Although technologically, cloud computing represents an evolution, strategically it represents the introduction of maneuver warfare into the IT security dictionary.

The concepts of attrition warfare and maneuver warfare dominate strategic options within the military. In attrition warfare, masses of men and material are moved against enemy strongpoints, with the emphasis on the destruction of the enemy’s physical assets. Maneuver warfare, on the other hand, advocates that strategic movement can bring about the defeat of an opposing force more efficiently than by simply contacting and destroying enemy forces until they can no longer fight.

The US Marine Corps concept of maneuver is a “warfighting philosophy that seeks to shatter the enemy’s cohesion through a variety of rapid, focused, and unexpected actions which create a turbulent and rapidly deteriorating situation with which the enemy cannot cope.”   It is important to note, however, that neither is used in isolation.  Balanced strategies combine attrition and maneuver techniques in order to be successful on the battlefield.

The reality is that outside of the military, “shock and awe” doesn’t really work when you’re mostly limited to “compliance and three analysts with a firewall.”  Check out “Security & the Cloud — What Does That Even Mean?”

Here’s where the reality distortion fields trumps the rainbows and unicorns:

With cloud computing, IT security can now use maneuver concepts for enhance defense. By leveraging virtualization, high speed wide area networks and broad industry standardization, new and enhanced security strategies can now be implemented. Defensive options can now include the virtual repositioning of entire datacenters. Through “cloudbursting”, additional compute and storage resources can also be brought to bear in a defensive, forensic or counter-offensive manner. The IT team can now actively “fight through an attack” and not just observe an intrusion, merely hoping that the in-place defenses are deep enough. The military analogy continues in that maneuver concepts must be combined with “defense in depth” techniques into holistic IT security strategies.

Allow me to suggest that “fight[ing] through an attack” by simply redirecting/re-positioning the $victim isn’t really an effective definition of an “active countermeasure” anymore than waiting the attack out because there’s no offense, only defense.  There is no elimination of threat.  I’ve written about that a bit: Incomplete Thought: Offensive Computing – The Empire Strikes Back,  Thinning the Herd & Chlorinating the Malware Gene Pool… and Everybody Wing Chun Tonight & “ISPs Providing Defense By Engaging In Offensive Computing” For $100, Alex. Mobility does not imply security.

To wit:

A theoretical example of how maneuver IT security strategies could be use would be in responding to a  denial of service attack launched on DISA datacenter hosted DoD applications. After picking up a grossly abnormal spike in inbound traffic, targeted applications could be immediately transferred to virtual machines hosted in another datacenter. Router automation would immediately re-route operational network links to the new location (IT defense by maneuver). Forensic and counter-cyber attack applications, normally dormant and hosted by a commercial infrastructure-as-a-service (IaaS) provider (a cloudburst), are immediately launched, collecting information on the attack and sequentially blocking zombie machines. The rapid counter would allow for the immediate, and automated, detection and elimination of the attack source.

To pick on this specific example, even given the relatively mature anti-DDoS capabilities we have today without virtualization or Cloud, simply moving resources around in response to an attack does nothing if the assets are bound to the same IP addresses and hostnames. Fundamentally, the static underpinnings holding the infrastructure together hinder this lofty goal.  You can Cloudburst till the cows come home, but the attacks will simply follow.  You transfer all those assets to a new virtual datacenter and for the most part, the bad traffic goes with it. Distributed intelligence can certainly reduce the pain, but with distributed botnets whose node counts can number in the millions, you’re not going to provide for the “…elimination of the attack source.”

With these large scale botnets as an example, the excess capacity and mobility of the $victim could even have unintended worse ramifications such as what I wrote about here: Economic Denial Of Sustainability (EDoS)

In closing, we’ve got two parallel paths of advancing technology: the autonomics of the datacenter and the evolution of security.  I’ll wager we’ll certainly see improvements in the former that are well out-of-phase and timing with the latter, not the least of which is due to what Kevin closed with:

This revolution, of course, doesn’t come without its challenges.  This is truly a cultural shift. Cloud computing provides choice, and in the context of active defense strategies, these choices must be made in real-time.  While the cloud computing advantages of self-service, automation, visibility and rapid provisioning can enable maneuver security strategies, successful implementation requires cooperation and collaboration across multiple entities, both within and without.
The cloud computing era is also the dawning of a new day in IT security.  In the not to distant future, network and IT security training will include both static and active IT security techniques. Maneuver warfare in IT security is here to stay.

It’s absolutely a cultural issue, but we must strive to be realistic about where we are with Cloud and security technology and capabilities as aligned.  As someone who’s spent the last 15 years in IT/Security, I can say that this is NOT the “…dawning of a new day in IT security,” rather it’s still dark out and will be for quite some time.  There is indeed opportunity to utilize Cloud and virtualization to react better, faster and more efficiently, but let’s not pretend we’re treating the problem when what we’re doing is making the symptoms less noticeable.

I am absolutely bullish on Cloud, but not Cloud Security as it stands, at least not until we make headway toward fundamentally fixing the foundational problems we have that allow the problems to occur in the first place.

/Hoff

* I thought that out of all of OMD’s tracks, the most apropos titles to match to this blog post would be “Pandora’s Box,” “Dreaming,” or “The New Stone Age” 😉  Thanks for the motivation, @csoandy

I’ve covered this before in more complex terms, but I thought I’d reintroduce the topic due to a very relevant discussion I just had recently (*cough cough*)

So here’s an interesting scenario in virtualized and/or Cloud environments that make use of virtual appliances to provide security capabilities*:

Since virtual appliances (VAs) are just virtual machines (VMs) what happens when a SysAdmin spins down or moves one that happens to be your shiny new firewall protecting your production VMs behind it, accidentally or maliciously?  Brings new meaning to the phrase “failing closed.”

Without getting into the vagaries of vendor specific mobility-enabled/enabling technologies, one of the issues with VMs/VAs is that there’s not really a good way of designating one as being “more important” or functionally differentiated such as “security” or “critical application” that would otherwise ensure a higher priority for service availability (read: don’t spin this down unless…) or provide a topological dependency hierarchy in virtualized network constructs.

Unlike physical environments where system administrators (servers) are segregated from access to network and security appliances, this isn’t the case in virtual environments. In Cloud environments (especially public, multi-tenant) where we are often reliant only upon virtual security capabilities since we have no option for physical alternatives, this is an interesting corner case.

We’ve talked a lot about visibility, audit and policy management in virtual environments and this is a poignant example.

/Hoff

*Despite the silly notion that the Google dudes tried to suggest I equated virtualization with Cloud as one-in-the-same, I don’t.

Have you ever seen a presentation or listened to a talk and thought “Wow. That person just clearly and brilliantly summarized all the things I wanted to say in a way I never could?”

I just had that experience.

I am working with Mark on a project and was sent a link to check out some of his musings.  One of them was titled “Risk and Security in the Enterprise Cloud.”

It is, quite possibly, one of the best security presentations on Cloud I’ve seen.  It’s a fantastic merge of theoretical myth busting, information systems survivability, security models and Cloud.

Basically, it’s my entire blog of three years wrapped up into 120 slides presented in my favorite minimalist style.  Wow.  Humbling.

It’s freaking brilliant.

Please read it.

/Hoff

I’m sure more details will emerge, but as written in Information Week, this story is just bizarre:

Less than a month and a half after coming out as federal cloud CTO, Patrick Stingley has returned to his role as CTO of the Bureau of Land Management*, with the General Services Administration saying the creation of the new role came too early. “It just wasn’t the right time to have any formalized roles and responsibilities because this is still kind of in the analysis stage,” GSA CIO Casey Coleman said in an interview today. “Once it becomes an ongoing initiative, it might be a suitable time to look at roles such as a federal cloud CTO, but it’s just a little premature.”

Cloud computing is a major initiative of federal CIO Vivek Kundra, and its importance was even outlined in an addendum to the president’s 2010 budget last month. Kundra introduced Google Apps to city employees in his former role as CTO of Washington, D.C., and has said that he believes cloud computing could be one way to cut the federal IT budget.

So Cloud Computing, despite all we hear about the Government’s demands for such services as a critical national initiative is “…still kind of in the analysis stage” and isn’t at the “…right time to have any formalized roles and responsibilities”?

Wow.

While Stingley is no longer the formal federal cloud CTO, he has by no means turned his attention away from cloud computing. As of last Thursday, he was still scheduled to give a presentation titled “Development Of A Federal Cloud Computing Infrastructure” at the Geospatial Service-Oriented Architecture Best Practices Workshop on Tuesday morning, though as CTO of the BLM, not as a representative of the GSA.

The GSA isn’t by any means taking its foot off the accelerator with cloud computing. However, Coleman wants to make sure it’s done in the right way. “As we formalize the cloud computing initiative, we will have a program office, we will have a governance model,” she said.

Despite the elimination — for now — of the federal cloud CTO role, Coleman said that it’s “fair to say” that the GSA will be taking a central role in pushing the Obama administration’s cloud computing initiative, noting that the GSA should be a “center of gravity” for federal government IT.

Perhaps this was simply lost in GovSpeak translation, but something does not compute here.  I’m very much for correcting missteps early, but what an absolutely confusing message to send: Cloud is uber-important, we’re moving full-steam ahead, but nobody — or at least not the GSA — is steering the ship?

What could go wrong?

Whether it was decided that the GSA was not the appropriate office to lead/govern the Federal Cloud efforts, they are amongst the most innovative:

The GSA is experimenting with cloud computing for its own internal use. For example, federal information Web site USA.gov is hosted via Terremark’s Enterprise Cloud infrastructure as a service product, which charges by capacity used. When it was time for renegotiation of its old hosting contract, the GSA opened the contract to bidders and ended up saving between 80% and 90% with Terremark on a multiyear contract worth up to $135 million.

It’s also possible that under the Obama administration, the GSA might begin playing more of a shared-services role in IT, as it does in building management. However, Coleman is coy about whether that’s likely to happen, saying only that it would depend on the goals of the administration and the incoming GSA administrator. Stingley is reported to have been thinking about how the GSA might build out a federal cloud that agencies could easily tap into.

There’s a back-story here…

Hoff

* Aha!  I figured it out. See the problem is that you can’t appoint the CTO from something called the Bureau of LAND Management and expect them to be able to manage CLOUDS!  Silly me!