Tag Archives: cloud governance

The Revolution Will Not Be Televised

Technology loves a good fad. Agile development, Web 2.0, patterns, Web services, XML, SOA, and now the cloud—I’ve lived through so many of these I’m beginning to lose track. And truth be told, I’ve jumped on my fair share of bandwagons. But one thing I have learned is that the successful technologies move at their own incremental pace, independent of the hype cycle around them. Two well known commentators, Eric Knorr from Infoworld, and David Linthicum, from Blue Mountain Labs, both made posts this week suggesting that this may be the case for cloud computing.

Eric Knorr, in his piece Cloud computing gets a (little) more real, writes:

The business driver for the private cloud is clear: Management wants to press a button and get what it needs, so that IT becomes a kind of service vend-o-matic. The transformation required to deliver on that promise seems absolutely immense to me. While commercial cloud service providers have the luxury of a single service focus, a full private cloud has an entire catalogue to account for — with all the collaboration and governance issues that stopped SOA (service-oriented architecture) in its tracks.

I agree with Eric’s comment about SOA, as long as you interpret this as “big SOA”. The big bang, starting-Monday-everything-is-SOA approach certainly did fail—and in hindsight, this shouldn’t be surprising. SOA, like cloud computing, cuts hard across fiefdoms and challenges existing order. If you move too fast, if your approach is too draconian, of course you will fail. In contrast, if you manage SOA incrementally, continuously building trust and earning mindshare, then SOA will indeed work.

Successful cloud computing will follow the incremental pattern. It just isn’t reasonable to believe that if you build a cloud, they will come—and all at once, as Eric contends. We have not designed our mission critical applications for cloud deployment. Moreover, our people and our processes may not be ready for cloud deployment. Like the applications, these too can change; but this is a journey, not a destination.

Private clouds represent an opportunity for orderly transition. Some would argue that private clouds are not really clouds at all, but I think this overstates public accessibility at the expense of the technical and operational innovations that better characterize the cloud. Private clouds are important and necessary because they offer an immediate solution to basic governance concerns and offer a trustworthy transition environment for people, process and applications.

David Linthicum seems to agree. In his posting What’s the Deal With Private Clouds? Dave writes:

In many instances, organizations leverage private clouds because the CIO wants the architectural benefits of public cloud computing, such as cost efficiencies through virtualization, but is not ready to give up control of data and processes just yet.

Dave sees private clouds as a logical transition step, one that supports an incremental approach to cloud computing. It’s not as radical as jumping right into the public cloud, but for that reason it’s a much easier sell to the business. It pulls staff in, rather than driving them out, and in the modern enterprise this is a much better recipe for success. He continues:

I think that many enterprises will stand up private clouds today, and then at some point learn to leverage public clouds, likely through dynamic use of public cloud resources to support bursts in processing on the private cloud. Many are calling this “cloud bursting,” but it’s a great way to leverage the elastic nature of public cloud computing without giving up complete control.

Dave’s hypothesis struck a chord with me. Only last week I had a discussion with a group of architects from a large investment bank, and this describes their strategy precisely. The bank has an internal, private cloud today; but they anticipate moving select applications into public clouds, leveraging the knowledge and experience they gained from their private cloud. These architects recognize that cloud isn’t just about the technology or a change in data center economics, but represents a fundamental shift in how IT is delivered that must be managed very carefully.

This revolution just doesn’t make good TV. The hype will certainly be there, but the actual reality will be a slow, measured, but nonetheless inevitable transition.

PS: The title, of course, is from the great Gil Scott-Heron

Advertisements

On the Death of Design-Time Service Governance

Practically on the anniversary of Anne Thomas Manes now-famous SOA-is-Dead pronouncement, David Linthicum suggests we convene the vigil for design-time service governance. Dave maintains that cloud technology is going to kill this canonical aspect of governance because runtime service governance simply provides much more immediate value. Needless to say, rather than a somber occasion, Dave’s started more of a donnybrook. I guess it’s about time to get off of the bench and join in the fun.

The incendiary nature of is-dead statements often conceal  the subtle but important ideas behind them. Dave’s declaration is no different. What he’s really suggesting is that cloud will rapidly shift the traditional priorities with respect to services governance. In the big SOA era (before Jan 1, 2009), design-time governance was king. It fit nicely into the plan-manage-control discipline underpinning a large enterprise-scale SOA effort. And to support this, tool vendors rushed in and offered up applications to facilitate the process. Run time services governance, in contrast, was often perceived as something you could ignore until later–after all, on-premise IT has reasonably good security and monitoring in place. The technology might be old and the process a little byzantine, but it could tide you over. And if any internal staff were caught accessing services they shouldn’t be you could just fire them.

The cloud inverts this priority. If you deploy even one service into the public cloud, you must have runtime service governance in place. That one service needs to be hardened and protected as you would a DMZ-based application. You must have continuous visibility into its operation from the moment you turn it on. Run time governance simply cannot be put off.

The cloud is also about agility. We are attracted to the cloud because it offers rapid deployment, elastic computing, and that hard to refuse pay-for-what-you-need model. This same sense of agility is a leitmotiv throughout the entire development process. When you talk to teams that have been successful with the cloud, they are usually small, they rail against enterprise bureaucracy, and agile development process is in their DNA. They are comfortable and extremely efficient with the tools and process they have, and they don’t see a lot of reason to change this. Do they still need discipline, organization, process, communication, sharing? Absolutely–but they have this; it’s ingrained into their existing process. I see this in my teams developing products every day. It’s the mix of great management, excellent people, process where it’s been shown to be needed, and a basic set of tools we all rely on every day.

Will design-time services governance tools disappear completely? Of course not. But their value becomes apparent with scale, when you begin to approach “a lot of services” (and no,  nobody really knows what this means–probably more than a scoville, less than a parsec). The point is, in the cloud nobody starts there, but they do need to focus immediately on the threats.

In the end, governance priorities in the cloud come down to a pretty simple precept: Duplicating a piece of functionality probably won’t get you fired; leaving an open door that was used to compromise corporate data probably will.

Cloud Security Alliance Guidance v2 Released

Last week, the Cloud Security Alliance (CSA) released its Security Guidance for Critical Areas of Focus in Cloud Computing V2.1. This is a follow-on to first guidance document released only last April, which, gives you a sense of the speed at which cloud technology and techniques are moving. I was one of the contributors to this project.

The guidance explores the issues in cloud security from the perspective of 13 different domains:

Cloud Architecture

  • Domain 1: Cloud Computing Architectural Framework

Governing in the Cloud

  • Domain 2: Governance and Enterprise Risk Management
  • Domain 3: Legal and Electronic Discovery
  • Domain 4: Compliance and Audit
  • Domain 5: Information Lifecycle Management
  • Domain 6: Portability and Interoperability

Operating in the Cloud

  • Domain 7: Traditional Security, Business Continuity, and Disaster Recovery
  • Domain 8: Data Center Operations
  • Domain 9: Incident Response, Notification, and Remediation
  • Domain 10: Application Security
  • Domain 11: Encryption and Key Management
  • Domain 12: Identity and Access Management
  • Domain 13: Virtualization

I thought the domain classification was quite good because it serves to remind people that technology is only a small part of a cloud security strategy. I know that’s become a terrible security cliche, but there’s a difference between saying this and understanding what it really means. The CSA domain structure–even without the benefits of the guidance–at least serves as a concrete reminder of what’s behind the slogan.

Have a close look at the guidance.  Read it; think about it; disagree with it; change it–but in the end, make it your own. Then share your experiences with the community. The guidance is an evolving document that is a product of a collective, volunteer effort. It’s less political than a conventional standards effort (look though the contributors and you will find individuals, not companies). The group can move fast, and it doesn’t need to be proscriptive like a standard–it’s more a distillation of considerations and best practices. This one is worth tracking.

Upcoming Webinar: Controlling Your SOA Across The Global Enterprise and Cloud

I’ll be delivering a Webinar next week about Layer 7’s Enterprise Service Manager (ESM) product. ESM offers the global view of clusters of SecureSpan Gateways and the services under their management. It’s functions fall into three main areas:

Enterprise-scale Management

  • Centrally manage and monitor all Gateways and associated services across the extended enterprise and into the cloud

Automated Policy Migration

  • Centrally approve and then push policy to any Gateway across the enterprise, automatically resolving environmental discrepancies

Disaster Recovery

  • Remotely manage, troubleshoot, backup and restore all Gateways, supporting full disaster recovery

ESM is an important tool for managing SOA in the Enterprise, but it also plays a critical role when SOA moves to the cloud. In addition to extending an organization’s visibility and control, ESM provides critical tools for automating the migration of policy to new environments:

I’ll go into this process in detail in the webinar. Hope to see you there. Here is the official abstract:

Organizations have begun extending their SOA initiatives beyond traditional enterprise boundaries to encompass third-party, geographically remote, and even cloud-based resources. As a result, the complexity associated with migrating applications across these environments (for example, from development in India to test in the cloud to production in a hosted data center) has increased exponentially. In this webinar from Layer 7, you will learn how topology and identity issues between environments, geographies and settings (i.e., enterprise vs. cloud) can be easily resolved and even automated, dramatically reducing migration risk.

You can sign up for this webinar at http://www.layer7tech.com/main/media/webinars.html.

Visualizing the Boundaries of Control in the Cloud

Two weeks ago, I delivered a webinar about new security models in the cloud with Anne Thomas Manes from Burton Group. Anne had one slide in particular, borrowed from her colleague Dan Blum, which I liked so much I actually re-structured my own material around it. Let me share it with you:

This graphic does the finest job I have seen of clearly articulating where the boundaries of control lie under the different models of cloud computing. Cloud, after all, is really about surrendering control: we delegate management of infrastructure, applications, and data to realize the benefits of commoditization. But successful transfer of control implies trust–and trust isn’t something we bestow easily onto external providers. We will only build this trust if we change our approach to managing cloud security.

Cloud’s biggest problem isn’t security; it’s the continuous noise around security that distracts us from the real issues and the possible solutions. It’s not hard to create a jumbled list of things to worry about in the cloud. It is considerably harder to come up with a cohesive model that highlights a fundamental truth and offers a new perspective from which to consider solutions. This is the value of Dan’s stack.

The issues in the cloud that scare us the most all fall predicatably out of the change in control this environment demands. Enterprise IT has carefully constructed an edifice of trust based on its existing on-premise security models. Cloud challenges these models. Cloud rips pieces from the foundation of this trust, leaving a structure that feels unstable and untrustworthy.

We cannot simply maintain existing security models in the cloud; instead, we need to embrace a new approach to security that understands the give-and-take of control that is inherent to the cloud. This demands we recognize where we are willing to surrender control, acknowledge that this conflicts with our traditional model, and change our approach to assert control elsewhere. Over time we will gain confidence in the new boundaries, in our new scope of control, and in our providers–and out of this will emerge a new formal model of trust.

Let’s consider Infrastructure-as-a-Service (IaaS) as a concrete example. Physical security is gone; low-level network control is gone; firewall control is highly abstracted. If your security model–and the trust that derives from this–is dependent on controlling these elements, then you had better stay home or build a private cloud. The public cloud providers recognize this and will attempt to overlay solutions that resemble traditional security infrastructure; however, it is important to recognize that behind this façade, the control boundaries remain and the same stack elements fall under their jurisdiction. Trust can’t be invested in ornament.

If you are open to building a new basis for trust, then the public cloud may be a real option. “Secure services, not networks” must become your guiding philosophy. Build your services with the resiliency you would normally reserve for a DMZ-resident application. Harden your OS images with a similar mindset. Secure all transmissions in or out of your services by re-asserting control at the application protocol level. This approach to secure loosely coupled services was proven in SOA, and it is feasible and pragmatic in an IaaS virtualized environment. It is, however, a model for trust that departs from traditional network-oriented security thinking, and this is where the real challenge resides.

I Went for Coffee and RDS was Waiting for Me When I Returned

Here at Layer 7, we’ve been really excited about Amazon’s Relational Data Service (RDS) ever since they announced it last month. RDS is basically a managed mySQL v5.1 instance running in the Amazon infrastructure. The point of RDS to provide another basic service that we all need all of the time, managed within the AWS ecosystem. It offers some great scaling options (in terms of instance sizing), but best of all, it provides automatic snapshoting of  database instances. This revolutionizes EC2 because it solves the nagging persistence problem that we all face when we terminate instances. We’ve all come up with clever ways of dealing with this using S3 and EBS,  but now it’s gotten much easier.

Since RDS is really mySQL under the covers, I had been hearing that it’s pretty easy to port to. We’ve been itching to play with it here, using Layer 7’s SecureSpan Gateway AMI that’s runs in EC2. Unfortunately, this Fall has been really busy, so none of us have had an opportunity to play with it until now.

The inimitable Jay Thorne, who is a musician first but holds down a day job here as Director of Development for the Tactical group, finally cleared an afternoon to put RDS through it’s paces. I had to step out for coffee with another of our execs, which turned into a longer-than-expected discussion. But by the time I got back, Jay was done: SecureSpan using persistent Amazon RDS storage. Hello, cloud registry/repository…

Here’s Jay’s summary, which I think speaks for itself:

Total elapsed time: 1.25 hours
Number of pdf documents read: 1
Number of web pages read: 3
Number of command copy/pastes from doc: 6
Number of dbs created by mistake until I got the zoning right: 2
Number of mistyped credentials until I learned to use a creds file: 7
Number of dumpfiles created source side: 1
Number of times I had to import to get it right: 1
Number of characters in the hostname of the db: 50
Number of hosts I put in the db firewall allow list: 1
Number of sets of user credentials I created: 1
Number of lines in our internal wiki article I wrote about this: 35
Number of bangs on the keyboard in frustration: 0

 

Webinar Available: New Security Model Requirements for the Cloud

Last week, Anne Thomas Manes, Research Director from Burton and I did a Webinar entitled New Security Model Requirements for the Cloud. It’s probably generated the most feedback of any webinar I’ve done. It’s now online, so have a look at it here.