Archive

Archive for July, 2009

Ralph the Mouth and Potsie Do A Cloud Security Podcast

July 30th, 2009 No comments

microphoneI’ll leave it up to you to figure who’s who [I’m the one with the ‘good’ accent,] but Craig Balding from Cloudsecurity.org and I have teamed up to host a regularly-scheduled (whatever that means) podcast on Cloud Security.

It’s called…wait for it…

The Cloud Security Podcast.

You can find it, and the show notes of our very first (and dodgy) version right here, homed at libsyn. We’ll stick it on iTunes shortly.

We had issues with drop-out over Skype, so I apologize for the annoyances there.

This (last) week’s coverage focused on:

  • What we mean by Cloud Computing?
  • Upcoming Cloud Security Events/Talks
  • Clouds News: Cloud FUD
  • Need to get past the FUD, how can you shape Cloud security today?
  • Non security specific Cloud linkage

Please do comment on our performance.

/Hoff & Craig

Inter-Cloud Rock, Paper, Scissors: Service Brokers, Semantic Web or APIs?

July 27th, 2009 8 comments

A very interesting philosophical and market trajectory arms race is quietly ramping while the rest of the world tries to ping together how the Kindle will kill Cloud Computing and how Twitter already has.

As @Jamesurquhart and I spend our time exploring the longer term evolution of Cloud Computing, we end up in orbit around the notion of the Inter-Cloud (or Intercloud, or InterCloud)

Inter-Cloud represents one vision that describes how Clouds of many types will interoperate, federate and provide for workload portability as well as how those that provide these services and those that consume them, will interact.  You can see an interesting summary of these issues here in a fellow colleague’s post titled: “From India to Intercloud

In the broadest sense, Cloud is being positioned in the long term to allow for true utility.  This means that at a 30,000 foot view, consumers should be able to declare their business and technology requirements for workloads or application needs and TAMO! (then a miracle occurs,) that workload or application presents itself operating somewhere that meets those needs backed up by some form of attestation by the provider. Ultimately, I’d like to see a common way of auditing and validating those attestations.  Apropos for this discussion, I bring up the notion of an API 😉

This all seems like a deceptively simple scenario.  Realistically, it represents a monstrous challenge in execution.  To wit, in Reuven Cohen’s recent write-up (“The Inter-Cloud and the Cloud of Clouds“) he quotes Vint Cerf’s definition of the problem with the issues at hand:

“…each cloud is a system unto itself. There is no way to express the idea of exchanging information between distinct computing clouds because there is no way to express the idea of “another cloud.” Nor is there any way to describe the information that is to be exchanged. Moreover, if the information contained in one computing cloud is protected from access by any but authorized users, there is no way to express how that protection is provided and how information about it should be propagated to another cloud when the data is transferred.

There’s a giant sucking sound coming from the Cloudosphere…

The market is essentially rotating around three ways of describing a solution to this problem:

  1. Consumers of service declare their requirements using some methodology for doing so (either directly to trusted and discrete service providers or) using an intermediary or “service broker.”  In the case of the service broker, it’s their job to take these declarations of service definition (service contracts) and translate them across subscribing service providers who may each have their own proprietary interface.  This is starting to heat up as we already have players emerging in this space and analyst groups are picking up interest (Yankee, Gartner)It would be much better if there were an open and standardized way of ensuring that all providers used the same common interface and way of providing attestation of service contract satisfaction/compliance, which leads to…
  2. There’s the notion of the “semantic” exchange of information between Clouds positioned by folks like Sir Tim Berners-Lee (in reference to Cerf’s quote above): “…by semantically linking data, we are able to create “the missing part of the vocabulary needed to interconnect computing clouds. The semantics of data and of the actions one can take on the data, and the vocabulary in which these actions are expressed appear to constitute the beginning of an inter-cloud computing language.” Capitalizing on Berners-Lee’s definition of the Semantic Web wherein “a vision of information that is understandable by computers, so that they can perform more of the tedious work involved in finding, sharing and combining information on the web,” we see how this approach would play well into the service broker model, also.

  3. We’ve seen a lot of noise around using one or more API’s — open or proprietary — that allow for individual Cloud operation, management, assurance and governance, however nuanced those functions may be.  Open-sourced or not, and even with unifying management interfaces available such as libcloud, each Cloud vendor today sees its capability for management and streamlined operations as its first layer of competitive differentiation and individual API’s — even when abstracted through service brokers — are a way to move offerings forward whilst working toward open standards such as these.

Honestly, my bet is that this arms race will net out such that we’ll end up with some combination of all three.

This isn’t as simple-sounding as it started, especially when we throw in the definitional differences between workload portability and interoperability  as alluded to by all three approaches.

Add packaging elements such as OVF and the problem starts expanding into a very complex multi-dimensional issue very quickly.

Workload portability using common packaging formats (such as OVF) can be leaned upon to show how providers might deal the “lock-in” argument (you can move from my competitor to me,) but true interoperability is the real challenge here.

Reuven said it very well: “...what the world needs is not yet another API to control the finer nuances of a physical or virtual infrastructure but instead a way for that infrastructure to communicate with other clouds around it regardless of what it is. The biggest hurdle to cloud interoperability appears to have very little to do with a willingness for cloud vendors to create open cloud API’s but instead the willingness to provide the ability for these clouds to effectively inter-operate with one another. More simply the capability to work along side other cloud platforms in an open way.”

Here’s how I see Inter-Cloud playing out: In the short term we’ll need the innovators to push with their own API’s, then the service brokers will abstract them on behalf of consumers in the mid-stream and ultimately we will arrive at a common, open and standardized way of solving the problem in the long term with a semantic capability that allows fluidity and agility in a consumer being able to take advantage of the model that works best for their particular needs.

Thoughts?

/Hoff

Extending the Concept: A Security API for Cloud Stacks

July 24th, 2009 7 comments

Please See the follow-on to this post: http://www.rationalsurvivability.com/blog/?p=1276

Update: Wow, did this ever stir up an amazing set of commentary on Twitter. No hash tag, unfortunately, but comments from all angles.  Most of the SecTwits dropped into “fire in the hole” mode, but it’s understandable.  Thank you @rybolov (who was there when I presented this to the gub’mint and @shrdlu who was the voice of, gulp, reason 😉

The Audit, Assertion, Assessment, and Assurance API (A6) (Title credited to @CSOAndy)

It started innocently enough with a post I made on the crushing weight of companies executing “right to audit clauses” in their contracts.  Craig Balding followed that one up with an excellent post of his own.

This lead to Craig’s excellent idea around solving a problem related to not being able to perform network-based vulnerability scans of Cloud-hosted infrastructure due to contractual and technical concerns related to multi-tenancy.  Specifically, Craig lobbied to create an open standard for vulnerability scanning API’s (an example I’ve been using in my talks for quite some time to illustrate challenges in ToS, for example.)  It’s an excellent idea.

So I propose — as I did to a group of concerned government organizations yesterday — that we take this concept a step further, beyond just “vulnerability scanning.”

Let’s solve BOTH of the challenges above with one solution.

Specifically, let’s take the capabilities of something like SCAP and embed a standardized and open API layer into each IaaS, PaaS and SaaS offering (see the API blocks in the diagram below) to provide not only a standardized way of scanning for network vulnerabilities, but also configuration management, asset management, patch remediation, compliance, etc.

Further (HT to @davidoberry who reminded me about my posts on the topic) we could use TCG IF-MAP as a comms. protocol for telemetry.

mappingmetal_compliance.044

This way you win two ways: automated audit and security management capability for the customer/consumer and a a streamlined, cost effective, and responsive way of automating the validation of said controls in relation to compliance, SLA and legal requirements for service providers.

Since we just saw a story today titled “Feds May Come Up With Cloud Security Standards” — why not use one they already have in SCAP to suggest we leverage it to get even better bang for the buck from a security perspective.  This concept extends well beyond the Public sector and it doesn’t have to be SCAP, but it seems like a good example.

Of course we would engineer in authentication/authorization to interface via the APIs and then you could essentially get ISV’s who already support things like SCAP, etc. to provide the capability in their offerings — physical or virtual — to enable it.

We’re not reinventing the wheel and we have lots of technology and standardized solutions we can already use to engineer into the stack.

Whaddya thunk?

/Hoff

Reblog this post [with Zemanta]

Amazon and Zappos: The Cloud Clobbers Clog and Crocs Cobblers – Controversy Coming!

July 23rd, 2009 2 comments

I have been mortified with the titles of many blogs/articles this week relating the strangest and most sensational orthogonal topics in regards to Cloud.

My favorite:

Will the Kindle Krisis Kill Cloud Computing

I decided that in a last-ditch effort to drive sagging readership I would submit a this one:

  • Amazon – Sole Crushing Corporate Cloud Clobbers Cool Cobbler Company

That’s right!  It’s a Cloudastrophe: Amazon (AmaZappos?) actually owns your shoes and will steal them off your feet.

Ultimately I think that Zappos acquisition was a strategic goldmine for Amazon because clearly WhisperNet is the next generation upgrade to SneakerNet… <groan!>

Categories: Uncategorized Tags:

Tons Of Interesting Papers/Presentations From Usenix/HotCloud ’09

July 21st, 2009 No comments

If you haven’t yet checked out the papers and presentations from Usenix/HotCloud ’09, you definitely should.

Some very interesting stuff.

Here.

/Hoff

Cloud Is A Rorschach — You See What You Want To See…

July 21st, 2009 No comments

rorschachThe view from the last 2 weeks clearly has been from the short bus squad*.

That is all.

/Hoff

*WARNING: Those who travel by means of the horizontally-challenged horseless carriage may be offended by my analogy.  Those of you suggesting I am being insensitive should know that I pick equally on long buses also.

Cloud Computing [Security] Architectural Framework

July 19th, 2009 3 comments

CSA-LogoFor 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


Problem Statement

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

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

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

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

Figure 4 - Mapping the Cloud Model to the Security Model
Figure 4 – Mapping the Cloud Model to the Security Model

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.


[1] Credit: Peter M. Mell, NIST

I Wish I Were Six Again; Innovation Angst Didn’t Suck Then.

July 15th, 2009 14 comments

I want tell you a little secret.  I want to be the next Ron Popeil.  I don’t care to be the first, just the first to realize a vision regarding something I verbalize.  I think I actually have a reasonable track record to warrant my lofty aspirations:

*When I was six growing up on a sheep farm in New Zealand, I grabbed an air mail envelope, drew a picture accompanied by some text and sent it off addressed to some generic address at the Pentagon in the U.S.  The drawing was an idea I had for what is now called a Thrust Vectoring Nozzle on jet aircraft.  I also paired that with oil injection into the manifold to produce enormous amounts of black smoke  to enable evasive action.  I figured I’d go for a two-fer.

* When I was 17 I wrote a similar letter complete with diagrams to Shimano because I was so damned tired of the crappy braking system on my off-road bicycle and suggested a hub-centric disk brake system for bicycles.

* In 1996, after forming my first startup and angel funding, my father-in-law and I architected an ASIC-based firewall appliance that would run Check Point firewall-1 code (ported) to a platform that had no OS and provided extremely high levels of performance with offload NPU’s and high-speed memory for state-table synchronization in clusters.  We took it to Check Point. They laughed.  6 months later they did a deal with Ascom Timeplex…

* In 2001 I built a prototype of an, um, entertainment system that involved 3D goggles, VRML, a nintendo power glove and, er, adult entertainment via a network-based  pay-per-play service

* Oh, the hits just-a-kept-on-comin’…

Somewhere between then and now, despite helping raise millions in VC funding for other people’s ideas, I stopped verbalizing my own and that makes me sad.

Where and when I can, I’m going to verbalize some of the ideas buried in my brain.  I have hundreds of them.  One day I hope one of them make someone else say “HEY! I thought of that!”  I’m an idea guy.  I want a T-Shirt that says that.

You have anything you’ve “invented” that’s showed up sometime later?

/Hoff

Categories: Uncategorized Tags:

Cloud Security: Waiting For Godot & His Silver Bullet

July 15th, 2009 No comments

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

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

You Might Be A Social Media Expert If…

July 10th, 2009 5 comments

My friend Dave Shackleford made one innocent little quip about social media experts on Twitter yesterday and in a fit of caffeine inspired (a)muse(ment) I went on a little rant.

Sung to the tune of Jeff Foxworthy’s “You might be a redneck…”:

  1. “If you think twitter is a sexual position, you might be a social media expert”
  2. “If the top three items in your browser history include the words “singles” “dating” or “matematch,” you might be a social media expert”
  3. “If your idea of fast food is ordering your X-Large pizza online — for yourself only — you might be a social media expert”
  4. “If you go to tweet-ups to pick up on women…you might be a social media expert”
  5. “If you’ve ever asked someone to become a Facebook fan of YOU, you might be a social media expert”
  6. “If you’ve ever broken up with someone over twitter & mistakenly @’d instead of DM’ing them, you might be a social media expert”
  7. “If your mom has more Facebook friends and Twitter followers than you do — some of whom she’s met– you might be a social media expert”
  8. “If you apply the David Koresh definition of ‘followers’ to Twitter, you might be a social media expert”
  9. “If you’ve ever sent defensive DM’s to @beaker because you’re offended by his SocMed jokes, you’re def. a fscking Social Media expert
  10. “If you had no idea ponies don’t really come in pink with bedazzled outfits, you might be a social media expert”
  11. “If you’ve ever tweeted for help on how to operate a power tool in real-time, you might be a social media expert”
  12. “If your idea of a hot date is the poetry aisle @ Barnes & Nobles on ‘Middle Eastern Comedy Reading Night’ you might be a SocMed Expert”
  13. “If your idea of a pet is a LOLcat that uses kitty twitter, you might be a social media expert”
  14. “If you went to Defcon and had a shirt made that said “I poked your mom on Facebook” to wear to the invite-only FB party that night, you…oh”
  15. “If you have seen, let alone own, ‘Breakin’ 2: Electric Boogaloo,’ you might be a social media expert”
  16. “If you’ve EVER said ‘Thunderbirds are go!’ at a party that involved alcohol and people over 23, you might be a social media expert”
  17. “If your idea of a tough workout is 10 minutes on the Wii Fit, you might be a social media expert”

Here are some of the contributions that my like-minded and sheepish followers penned:

  1. If you use your WiiFit to update your statistics on Facebook and MySpace, you might be a social media expert [@n0b0d4]
  2. If you’ve ever suggested a IPS and SIEM based on Twitter, you might be a Social Media expert *looks at @Beaker* [@innismir]
  3. If you named your twins Tweet and Retweet, you might be a social media expert [@n0b0d4]
  4. If you refuse to talk to your parents because they aren’t on Facebook and Twitter, you might be a social media expert [@n0b0d4]
  5. You know you’re a social media expert when…you can celebrities look at you followers and are jealous [@n0b0d4]
  6. If people send help when you haven’t tweeted in 3 hours, you might be a social media expert? [@samj – in response to my CTO wondering why I was MIA from Twitter for 3 hrs ;)]
  7. If you bought a book of funny quotes cause you thought it would make for interesting tweets, you might be a social media expert. [@pcalvin]
  8. If you stopped posting for 1 day and people start asking if you’re ok, you might be a social media expert. [@lonervamp]
  9. If you learned how to dance from Dance Dance Revolution, you might be a social media expert [@noora_freedman]
  10. If followe[rs|es] exceeds your dunbar number by an order of magnitude you might be a social media expert <- works for monkeys too [@samj]
  11. If you’ve ever cared whether or not someone follows you back you might be a social media expert. [@samj]
  12. If you shake hands by making sure to follow everyone who follows you, you might be a social media expert [@jamesurquhart]
  13. If the thousands of hours you spent playing Everquest are finally paying off, you might be a social media expert. [@jamesurquhart]
  14. If you’ve ever left a meeting with your CIO to finish a tweet you might be a social media expert [@andywillingham]
  15. If you’ve ever won a blogworld pass with a tweet, you might be a social media expert [@n0b0d4]
  16. If you refer to Friendster as the historic way people used to communicate, you might be a social media expert [@munozrick]
  17. If you follow 10,000 people but only 20 follow you back, you might be a social media expert” [@vmdoug]
  18. If your idea of a great book title is “How to win followers and influence people”, you might be a social media expert. [@daveshackleford]
  19. If you count the letters in every sentence as you write, you might be a social media expert” [@munozrick]
  20. If you become anxious about the number of API calls left in your Twitter client, you might be a social media expert. [@daveshakleford]
  21. If you’ve ever switched Twitter clients to avoid RT your own lame joke, you might be a social media expert [@n0b0d4]
  22. If you can’t live without your Flip Video camera, you might be a social media expert. [@dirflash]
  23. If you think hashtags should not be removed from mattresses, you might be a social media expert. [@lmclaughlin]
  24. If you’ve ever though 140 characters is too much, you might be a social media expert [@n0b0d4]
  25. If you have ever switched the keys on your keyboard around just to keep life interesting…you might be a social media expert [@cparadis_]

/Hoff

Categories: Jackassery, Social Media Tags: