Rational Survivability

Every day I get asked to discuss how Cloud Computing impacts security architecture and what enterprise security teams should do when considering “Cloud.”

These discussions generally lend themselves to a bifurcated set of perspectives depending upon whether we’re discussing Public or Private Cloud Computing.

This is unfortunate.

From a security perspective, focusing the discussion primarily on the deployment model instead of thinking holistically about the “how, why, where, and who” of Cloud, often means that we’re tethered to outdated methodologies because it’s where our comfort zones are.

When we’re discussing Public Cloud, the security teams are starting to understand that the choice of compensating controls and how they deploy and manage them require operational, economic and architectural changes.  They are also coming to terms with the changes to application architectures as it relates to distributed computing and SOA-like implementation.  It’s uncomfortable and it’s a slow-slog forward (for lots of good reasons,) but good questions are asked when considering the security, privacy and compliance impacts of Public Cloud and what can/should be done about them and how things need to change.

When discussing Private Cloud, however, even when a “clean slate design” is proposed, the same teams tend to try to fall back to what they know and preserve the classical n-tier application architecture separated by physical or virtual compensating controls — the classical split-subnet DMZ or perimeterized model of “inside” vs “outside.” They can do this given the direct operational control exposed by highly-virtualized infrastructure.  Sometimes they’re also forced into this given compliance and audit requirements. The issue here is that this discussion centers around molding cloud into the shape of the existing enterprise models and design patterns.

This is an issue; trying to simultaneously secure these diametrically-opposed architectural implementations yields cost inefficiencies, security disparity, policy violations, introduces operational risk and generally means that  the ball doesn’t get moved forward in protecting the things that matter most.

Public Cloud Computing is a good thing for the security machine; it forces us to (again) come face-to-face with the ugliness of the problems of securing the things that matter most — our information. Private Cloud Computing — when improperly viewed from the perspective of simply preserving the status quo — can often cause stagnation and introduce roadblocks.  We’ve got to move beyond this.

Public Cloud speaks to the needs (and delivers on) agility, flexibility, mobility and efficiency. These are things that traditional enterprise security are often not well aligned with.  Trying to fit “Cloud” into neat and tidy DMZ “boxes” doesn’t work.  Cloud requires revisiting our choices for security. We should take advantage of it, not try and squash it.

/Hoff

Related articles by Zemanta

• The Four Horsemen Of the Virtualization (and Cloud) Security Apocalypse… (rationalsurvivability.com)
• Virtualization & Cloud Don’t Offer An *Information* Security Renaissance… (rationalsurvivability.com)
• The Hypervisor Platform Shuffle: Pushing The Networking & Security Envelope (rationalsurvivability.com)
• Security: In the Cloud, For the Cloud & By the Cloud… (rationalsurvivability.com)
• Incomplete Thought: “The Cloud in the Enterprise: Big Switch or Little Niche?” (rationalsurvivability.com)
• Incomplete Thought: The DevOps Disconnect (rationalsurvivability.com)
• You Can’t Secure The Cloud… (rationalsurvivability.com)
• Friday Cloud Poetry: “On the Bullshit That is False Cloud” (rationalsurvivability.com)

Hi. Me again.

In 2008 I wrote a blog titled “Patching the Cloud” which I followed up with material examples in 2009 in another titled “Redux: Patching the Cloud.”

These blogs focused mainly on virtualization-powered IaaS/PaaS offerings and whilst they targeted “Cloud Computing,” they applied equally to the heavily virtualized enterprise.  To this point I wrote another in 2008 titled “On Patch Tuesdays For Virtualization Platforms.”

The operational impacts of managing change control, vulnerability management and threat mitigation have always intrigued me, especially at scale.

I was reminded this morning of the importance of the question posed above as VMware released a series of security advisories detailing ten vulnerabilities across many products, some of which are remotely exploitable. While security vulnerabilities in hypervisors are not new, it’s unclear to me how many heavily-virtualized enterprises or Cloud providers actually deal with what it means to patch this critical layer of infrastructure.

Once virtualized, we expect/assume that VM’s and the guest OS’s within them should operate with functional equivalence when compared to non-virtualized instances. We have, however, seen that this is not the case. It’s rare, but it happens that OS’s and applications, once virtualized, suffer from issues that cause faults to the underlying virtualization platform itself.

So here’s the $64,000 question – feel free to answer anonymously:

While virtualization is meant to effectively isolate the hardware from the resources atop it, the VMM/Hypervisor itself maintains a delicate position arbitrating this abstraction.  When the VMM/Hypervisor needs patching, how do you regression test the impact across all your VM images (across test/dev, production, etc.)?  More importantly, how are you assessing/measuring compound risk across shared/multi-tenant environments with respect to patching and its impact?

/Hoff

P.S. It occurs to me that after I wrote the blog last night on ‘high assurance (read: TPM-enabled)’ virtualization/cloud environments with respect to change control, the reference images for trust launch environments would be impacted by patches like this. How are we going to scale this from a management perspective?

Related articles by Zemanta

• Incomplete Thought: Virtual Machines Are the Problem, Not the Solution… (rationalsurvivability.com)
• More On High Assurance (via TPM) Cloud Environments (rationalsurvivability.com)
• Redux: Patching the Cloud (rationalsurvivability.com)
• On Patch Tuesdays For Virtualization Platforms (rationalsurvivability.com)

David Sparks (c/o Tripwire) interviewed me on the state of Information Security in virtualized/cloud environments.  It’s another reminder about Information Centricity.

Direct Link here.

Emedded below:

Related articles by Zemanta

• Six Year Old Rationalizes the Cloud (rationalsurvivability.com)
• Cloud Computing Security: (Orchestral) Maneuvers In the Dark? (rationalsurvivability.com)
• From the X-Files – The Cloud in Context: Evolution from Gadgetry to Popular Culture (rationalsurvivability.com)
• ENISA launches Cloud Computing Security Risk Assessment Document (rationalsurvivability.com)
• Cloud: Security Doesn’t Matter (Or, In Cloud, Nobody Can Hear You Scream) (rationalsurvivability.com)
• Mark Masterson’s Brilliant Cloud Security Presentation (rationalsurvivability.com)

Here is some of the recent coverage from the last couple of months or so on topics relevant to content on my blog, presentations and speaking engagements.  No particular order or priority and I haven’t kept a good record, unfortunately.

Important Stuff I’m Working On:

• Cloud Security Alliance
• CloudAudit/A6
• Common Assurance Metrics

Press/Technology & Security eZines/Website/Blog Coverage/Meaningful Links:

• How Cloud Service Brokers Enable the Cloud Marketplace – Connecting SOA to the Cloud
• Incite 2/17/2010 – Open Your Mind – Securosis
• Fun Reading on Security and Compliance #23 – Security Warrior Blog
• From private clouds to solar panels: more control and uniqueness, but are they worth it? – Data Center Dialog
• Want to build a private cloud? – SearchCloudComputing
• What’s The Difference Between Security And Trust In The Cloud? – CSC Trusted Cloud Services
• In The Era Of Mashups, MashSSL Could Be A Savior – CloudAve
• Cloud Computing, A Primer – The Internet Protocol Forum
• On the many limitations of (network) virtual appliances – Virtualization.info
• Incite 1/27/2010: Depending on the Kids – Securosis
• Can regulators keep up with Cloud Computing? – CloudAve
• The network performance within the cloud, an hidden enemy – Reflections of the Void
• The Cloud Computing Compliance Conundrum – Data Center Knowledge
• Is over-capacity inevitable in cloud computing? – virtualization.info
• Cloud Overbooking – Part 1 – Virtually Insane
• Infrastructure 2.0: Squishy Name for a Squishy Concept – f5 DevCentral
• Top 10 Web Hacking Techniques of 2009 – Jeremiah Grossman
• On Virtualization, Clouds and Meta Orchestration – SeekingAlpha
• Forecast for 2010: The Coming Cloud ‘Catastrophe’ – BusinessWeek
• The Daily Incite – 12/28/09 – Meyer’s Choice – Security Incite
• Virtualization, Cloud Computing, And Next-Generation Security – InformationWeek/DarkReading
• My Thoughts After CloudCamp Boston 2009 – Fubardness is Contagious

Recent Speaking Engagements/Confirmed to  speak at the following upcoming events:

• Govt Solutions Forum Feb 1-2 (panel |n DC)
• Govt Solutions Forum Feb 24 D.C.
• ESAF, San Francisco, March 1
• Cloud Security Alliance Summit, San Francisco, March 1
• RSA Security Conference March 1-5 San Francisco
• Microsoft Bluehat Buenos Aires, Argentina – March 16-19th
• ISSA General Assembly, Belgium
• Infosec.be, Belgium
• Codegate, South Korea, April 7-8
• SOURCE Boston, April 21-23
• Shot the Sherrif – Brazil – May 17th
• Gluecon , Denver, May 26/27
• FIRST, Miami, FL,  June 13-18
• SANS DC – August 19th-20th

Conferences I am tentatively attending, trying to attend and/or working on logistics for speaking:

• InterOp April 25-29 Vegas
• Cisco Live – June 27th – July 1st Vegas
• Blackhat 2010 – July 24-29 Vegas
• Defcon
• Notacon

Oh, let us not forget these top honors (buahahaha!)

• Top 10 Sexy InfoSec Geeks (link)
• The ThreatPost “All Decade Interview Team” (link)
• ‘Cloud Hero’ and ‘Best Cloud Presentation’ – 2009 Cloudies Awards (link), and
• 2010 RSA Social Security Bloggers Award nomination (link) 😉

[I often get a bunch of guff as to why I make these lists: ego, horn-tooting, self-aggrandizement. I wish I thought I were that important. 😉 The real reason is that it helps me keep track of useful stuff focused not only on my participation, but that of the rest of the blogosphere.]

/Hoff

I’m happy to announce that the Automated Audit, Assertion, Assessment, and Assurance API (A6) working group is organizing under the brand of “CloudAudit.”  We’re doing so to enable reaching a broader audience, ensure it is easier to find us in searches and generally better reflect the mission of the group.  A6 remains our byline.

We’ve refined how we are describing and approaching solving the problems of compliance, audit, and assurance in the cloud space and part of that is reflected in our re-branding.  You can find the original genesis for A6 here in this series of posts. Meanwhile, you can keep track of all things CloudAudit at our new home: http://www.CloudAudit.org.

The goal of CloudAudit is to provide a common interface that allows Cloud providers to automate the Audit, Assertion, Assessment, and Assurance (A6) of their environments and allow authorized consumers of their services to do likewise via an open, extensible and secure API.  CloudAudit is a volunteer cross-industry effort from the best minds and talent in Cloud, networking, security, audit, assurance, distributed application and system architecture backgrounds.

Our execution mantra is to:

• Keep it simple, lightweight and easy to implement; offer primitive definitions & language structure using HTTP(S)
• Allow for extension and elaboration by providers and choice of trusted assertion validation sources, checklist definitions, etc.
• Not require adoption of other platform-specific APIs
• Provide interfaces to Cloud naming and registry services

The benefits to the cloud provider are clear: a single reference model that allows automation of many functions that today incurs large costs in both manpower and time and costs business.  The base implementation is being designed to require little to no programmatic changes in order for implementation.  For the consumer and interested/authorized third parties, it allows on-demand examination of the same set of functions.

Mapping to compliance, regulatory, service level, configuration, security and assurance frameworks as well as third party trust brokers is part of what A6 will also deliver.  CloudAudit is working closely with other alliance and standards body organizations such as the Cloud Security Alliance and ENISA.

If you want to know who’s working on making this a reality, there are hundreds of interested parties; consumers as well as providers such as: Akamai, Amazon Web Services, Microsoft, NetSuite, Rackspace, Savvis, Terremark, Sun, VMware, and many others.

If you would like to get involved, please join the CloudAudit Working Group or visit the homepage here.

Here is the slide deck from the 2/12/10 working group call (our second) and a link to the WebEx playback of the call.

rRelated articles by Zemanta

• The Cloud Computing Compliance Conundrum (datacenterknowledge.com)
• Cloud: Security Doesn’t Matter (Or, In Cloud, Nobody Can Hear You Scream) (rationalsurvivability.com)
• Follow-On: The Audit, Assertion, Assessment, and Assurance API (A6) (rationalsurvivability.com)
• A6 Workgroup On The Way Soon (cloudave.com)
• Security vs. Compliance in the Cloud (web2.sys-con.com)
• Recording & Playback of WebEx A6 Working Group Kick-Off Call from 1/8/2010 Available (rationalsurvivability.com)

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

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

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

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

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

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

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

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

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

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

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

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

/Hoff

Related articles by Zemanta

• ENISA launches Cloud Computing Security Risk Assessment Document (rationalsurvivability.com)
• Security and the Cloud – What Does That Even Mean? (rationalsurvivability.com)
• These Apocalyptic Assessments Of Cloud Security Readiness Are Irrelevant… (rationalsurvivability.com)
• The Cloud & eHarmony’s 29 Dimensions Of Compatability… (rationalsurvivability.com)
• Cloud Computing [Security] Architectural Framework (rationalsurvivability.com)
• Jericho Forum and Cloud Security Alliance Join Forces to Address Cloud Computing Security (rationalsurvivability.com)
• From the X-Files – The Cloud in Context: Evolution from Gadgetry to Popular Culture (rationalsurvivability.com)
• Extending the Concept: A Security API for Cloud Stacks (rationalsurvivability.com)

• EuroCloud UK members making sense of Cloud standards and security (cloudave.com)
• The Cloud Computing Compliance Conundrum (datacenterknowledge.com)
• Can regulators keep up with Cloud Computing? (cloudave.com)

The (first annual) 2009 Federal Identity Management & Cyber Security Conference is being held in Washington on December 15-16th.  I’m speaking on day two on a panel moderated by Earl Crane of DHS on “Innovation and security in Cloud Computing.”

The Information Security and Identity Management Committee (ISIMC) of the Federal CIO Council is taking steps to deliver  on the President’s pledge for cybersecurity. ISIMC will discuss strategies and tactics for securing and defending federal IT  systems and networks for trusted and reliable global communication.

The objectives of this conference are awareness, education, and alignment toward a common vision for cyber defense  within the federal community.   This conference will focus on protecting the nation against cyber aggression, while preserving and protecting  the personal privacy and civil liberties that are the core of american values.

Hosted by  the Information Security and Identity management committee (ISIMC), which supports the federal CIO Council  in enabling chief Information officers (CIOs) and chief Information Security officers (CISOs) to  collaborate on: (1) identifying high priority cybersecurity and identity management initiatives; and (2) developing  recommendations for policies, procedures, and standards to address those initiatives that enhance the security  posture and protection afforded to federal government networks, information, and information systems.

Topics Include

• Nation’s top cybersecurity challenges addressed by a
• Panel of government and Private Sector leaders
• US-cert and the challenging landscape of
• Federal cybersecurity
• Security Performance – What Is next?
• Innovation, cloud computing and Web 2.0
• Federal desktop core configuration next Steps
• Supply chain acquisition best Practices
• IT Security Policy and legislation
• Identify, credential and access management

This should be an interesting two days.

Back in 2008 I wrote a piece titled “Patching the Cloud” in which I highlighted the issues associated with the black box ubiquity of Cloud and what that means to patching/upgrading processes:

Your application is sitting atop an operating system and underlying infrastructure that is managed by the cloud operator.  This “datacenter OS” may not be virtualized or could actually be sitting atop a hypervisor which is integrated into the operating system (Xen, Hyper-V, KVM) or perhaps reliant upon a third party solution such as VMware.  The notion of cloud implies shared infrastructure and hosting platforms, although it does not imply virtualization.

A patch affecting any one of the infrastructure elements could cause a ripple effect on your hosted applications.  Without understanding the underlying infrastructure dependencies in this model, how does one assess risk and determine what any patch might do up or down the stack?  How does an enterprise that has no insight into the “black box” model of the cloud operator, setup a dev/test/staging environment that acceptably mimics the operating environment?

What happens when the underlying CloudOS gets patched (or needs to be) and blows your applications/VMs sky-high (in the PaaS/IaaS models?)

How does one negotiate the process for determining when and how a patch is deployed?  Where does the cloud operator draw the line?   If the cloud fabric is democratized across constituent enterprise customers, however isolated, how does a cloud provider ensure consistent distributed service?  If an application can be dynamically provisioned anywhere in the fabric, consistency of the platform is critical.

I followed this up with a practical example when Microsoft’s Azure services experienced a hiccup due to this very thing.  We see wholesale changes that can be instantiated on a whim by Cloud providers that could alter service functionality and service availability such as this one from Google (Published Google Documents to appear in Google search) — have you thought this through?

So now as we witness ISP’s starting to build Cloud service offerings from common Cloud OS platforms and espouse the portability of workloads (*ahem* VM’s) from “internal” Clouds to Cloud Providers — and potentially multiple Cloud providers — what happens when the enterprise is at v3.1 of Cloud OS, ISP A is at version 2.1a and ISP B is at v2.9? Portability is a cruel mistress.

Pair that little nugget with the fact that even “global” Cloud providers such as Amazon Web Services have not maintained parity in terms of functionality/services across their regions*. The US has long had features/functions that the european region has not.  Today, in fact, AWS announced bringing infrastructure capabilities to parity for things like elastic load balancing and auto-scale…

It’s important to understand what happens when we squeeze the balloon.

/Hoff

*corrected – I originally said “availability zones” which was in error as pointed out by Shlomo in the comments. Thanks!

Werner Vogels brought a smile to my face today with his blog titled “Seamlessly Extending the Data Center – Introducing Amazon Virtual Private Cloud.”  In short:

We have developed Amazon Virtual Private Cloud (Amazon VPC) to allow our customers to seamlessly extend their IT infrastructure into the cloud while maintaining the levels of isolation required for their enterprise management tools to do their work.

In one fell swoop, AWS has:

• Legitimized Private Cloud as a reasonable, needed, and prudent step toward Cloud adoption for enterprises,
• Substantiated the value proposition of Private Cloud as a way of removing a barrier to Cloud entry for enterprises, and
• Validated the ultimate vision toward hybrid Clouds and Inter-Cloud

They made this announcement from the vantage point of operating as a Public Cloud provider — in many cases THE Public Cloud provider of choice for those arguing from an exclusionary perspective that Public Cloud is the only way forward.

Now, it’s pretty clear on AWS’ position on Private Cloud; straight form the horse’s mouth Werner says “Private Cloud is not the Cloud” (see below) — but it’s also clear they’re willing to sell you some 😉

The cost for VPC isn’t exorbitant, but it’s not free, either, so the business case is clearly there (see the official VPC site)– VPN connectivity is $0.05 per VPN connection with data transfer rates of $0.10 per GB inbound and ranging from $0.17 per GB – $0.10 per GB outbound depending upon volume (with heavy data replication or intensive workloads people are going to need to watch the odometer.)

I’m going to highlight a couple of nuggets from his post:

We continuously listen to our customers to make sure our roadmap matches their needs. One important piece of feedback that mainly came from our enterprise customers was that the transition to the cloud of more complex enterprise environments was challenging. We made it a priority to address this and have worked hard in the past year to find new ways to help our customers transition applications and services to the cloud, while protecting their investments in their existing IT infrastructure. …

Private Cloud Is Not The Cloud – These CIOs know that what is sometimes dubbed “private cloud” does not meet their goal as it does not give them the benefits of the cloud: true elasticity and capex elimination. Virtualization and increased automation may give them some improvements in utilization, but they would still be holding the capital, and the operational cost would still be significantly higher.

…

We have been listening very closely to the real requirements that our customers have and have worked closely with many of these CIOs and their teams to understand what solution would allow them to treat the cloud as a seamless extension of their datacenter, where their standard management practices can be applied with limited or no modifications. This needs to be a solution where they get all the benefits of cloud as mentioned above [Ed: eliminates cost, elastic, removes “undifferentiated heavy lifting”] while treating it as a part of their datacenter.

We have developed Amazon Virtual Private Cloud (Amazon VPC) to allow our customers to seamlessly extend their IT infrastructure into the cloud while maintaining the levels of isolation required for their enterprise management tools to do their work.

With Amazon VPC you can:

• Create a Virtual Private Cloud and assign an IP address block to the VPC. The address block needs to be CIDR block such that it will be easy for your internal networking to route traffic to and from the VPC instance. These are addresses you own and control, most likely as part of your current datacenter addressing practice.
• Divide the VPC addressing up into subnets in a manner that is convenient for managing the applications and services you want run in the VPC.
• Create a VPN connection between the VPN Gateway that is part of the VPC instance and an IPSec-based VPN router on your own premises. Configure your internal routers such that traffic for the VPC address block will flow over the VPN.
• Start adding AWS cloud resources to your VPC. These resources are fully isolated and can only communicate to other resources in the same VPC and with those resources accessible via the VPN router. Accessibility of other resources, including those on the public internet, is subject to the standard enterprise routing and firewall policies.

Amazon VPC offers customers the best of both the cloud and the enterprise managed data center:

• Full flexibility in creating a network layout in the cloud that complies with the manner in which IT resources are managed in your own infrastructure.
• Isolating resources allocated in the cloud by only making them accessible through industry standard IPSec VPNs.
• Familiar cloud paradigm to acquire and release resources on demand within your VPC, making sure that you only use those resources you really need.
• Only pay for what you use. The resources that you place within a VPC are metered and billed using the familiar pay-as-you-go approach at the standard pricing levels published for all cloud customers. The creation of VPCs, subnets and VPN gateways is free of charge. VPN usage and VPN traffic are also priced at the familiar usage based structure

All the benefits from the cloud with respect to scalability and reliability, freeing up your engineers to work on things that really matter to your business.

Jeff Barr did a great job of giving a little more detail on his blog but also brought up a couple of points I need to noodle on from a security perspective:

Because the VPC subnets are used to isolate logically distinct functionality, we’ve chosen not to immediately support Amazon EC2 security groups. You can launch your own AMIs and most public AMIs, including Microsoft Windows AMIs. You can’t launch Amazon DevPay AMIs just yet, though.

The Amazon EC2 instances are on your network. They can access or be accessed by other systems on the network as if they were local. As far as you are concerned, the EC2 instances are additional local network resources — there is no NAT translation. EC2 instances within a VPC do not currently have Internet-facing IP addresses.

We’ve confirmed that a variety of Cisco and Juniper hardware/software VPN configurations are compatible; devices meeting our requirements as outlined in the box at right should be compatible too. We also plan to support Software VPNs in the near future.

The notion of the VPC and associated VPN connectivity coupled with the “software VPN” statement above reminds me of Cohesive F/T’s VPN-Cubed solution.  While this is an IaaS-focused discussion, it’s only fair to bring up Google’s Secure Data Connector that was announced some moons ago from a SaaS/PaaS perspective, too.

I would be remiss in my musings were I not to also suggest that Cloud brokers and Cloud service providers such as RightScale, GoGrid, Terremark, etc. were on the right path in responding to customers’ needs well before this announcement.

Further, it should be noted that now that the 800lb Gorilla has staked a flag, this will bring up all sorts of additional auditing and compliance questions, as any sort of broad connectivity into and out of security zones and asset groupings always do.  See the PCI debate (How to Be PCI Compliant In the Cloud)

At the end of the day, this is a great step forward toward — one I am happy to say that I’ve been talking about and presenting (see my Frogs presentation) for the last two years.

/Hoff

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.

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

Related articles by Zemanta

• Extending the Concept: A Security API for Cloud Stacks (rationalsurvivability.com)
• Follow-On: The Audit, Assertion, Assessment, and Assurance API (A6) (rationalsurvivability.com)
• A6 Workgroup On The Way Soon (cloudave.com)
• Cloud Security (slideshare.net)