Why Public Clouds are More Secure than Private Clouds

Document ID: | Document Type: ZapFlash
By: Jason Bloomberg | Posted: February 7, 2012

Conventional wisdom would have you believe that Public Clouds are inherently insecure, and that the only way to meet your organization’s stringent security requirements in the Cloud is to implement your own Private Cloud. Conventional wisdom, you say? Unfortunately, there is precious little wisdom available of any kind when it comes to Cloud Computing, let alone the conventional type!

In fact, large software and hardware vendors are largely responsible for the whole “Public Cloud is insecure” canard, introducing fear, uncertainty, and doubt (FUD) into the marketplace. After all, building a Private Cloud means buying a lot of new gear. The last thing the big vendors want is for their customers to move to Public Clouds—unless, of course, they belong to the vendor in question. Don’t be fooled. Public Clouds are typically more secure than Private Clouds, for a number of reasons. Here’s why.

Why Public Clouds are More Secure…

• Hardened thru continual hacking attempts – Public Cloud providers are a juicy target. Hackers know how to find them, realize there’s good stuff inside, and would be the envy of all their hacker pals if they were able to breach the Public Cloud’s defenses. As a result, h4x0r types have been hammering on Amazon Web Services, Microsoft Azure, and all the others. Thousands of them. For years now.

• Attract the best security people available – Public Cloud providers not only attract hackers, they attract talent. If you’re a top Cloud security expert, where would you rather work: Amazon? Or some big insurance company or manufacturer or government agency? I thought so.

• Get the latest security gear due to economies of scale – How many Cloud data centers do the big Public Cloud providers own? And how fast are they building new ones? You don’t need to know the specifics to realize the answers are boatloads and wicked fast. And they’re buying gear for them. New gear. Boatloads of it. Wicked fast.

Why Private Clouds are Less Secure…

• Suffer from “perimeter complacency” – it’s amazing how many enterprises think that their DMZs and firewalls give them adequate security. If it’s on the internal network, it must be secure! As though they completely missed the Internet. And email. Not to mention viruses. What about twenty-somethings downloading malware to the corporate network through their phones? Now the enterprise wants a Private Cloud, so they can put the whole kit and caboodle on their internal network for security purposes. Good luck with that.

• Unknown staff competence – sure, your organization has a lot of great security people. They all know their stuff. Try this: have a big party for them. Two hours in, take a look around the room. See that guy with the lampshade on his head? He’s responsible for Private Cloud security.

• Insufficient penetration testing – how do you test to make sure your Private Cloud is secure—or any other part of your IT infrastructure, for that matter? Simple: have your testers run a series of security tests. Or maybe hire a third party to run them for you. If all the tests pass, you’re secure, right? Maybe for like a minute, until the hackers figure out new attacks that didn’t make it into your security tests. Whoops.

• May have older gear in use – you spent hundreds of thousands of dollars on security hardware. In 2009. Now you’re putting the final touches on your Private Cloud. Try this: ask your CIO for hundreds of thousands of dollars more to replace that three-year-old gear. The response? Maybe next year. Try updating the patches. I’m sure you can make do with what we have. And maybe you can—but don’t expect it to compare with the brand new shiny stuff going into Public Cloud data centers every day.

Virtual Private Clouds to the Rescue?

With a Virtual Private Cloud (VPC), a Public Cloud provider gives you a dedicated, secure connection (usually via a VPN) to your Public Cloud instances. In some cases, those instances are physically separated from other customers, so that your stuff can’t end up on the same box as somebody else’s stuff.

VPCs may actually be the most secure option available today, as you have the best of both worlds. Furthermore, they may address specific regulatory or other governance issues that may prevent your organization from using a multitenant Public Cloud. If you read the first section of this ZapFlash and think that neither Public nor Private sounds secure enough, then a VPC may be the way to go.

However, VPCs aren’t for everyone. They may only be marginally more secure than Public Cloud, as Public Cloud providers have generally done a bang-up job securing their multitenant architectures. And keep in mind, a single-tenant VPC will typically be substantially more expensive than a regular Public Cloud equivalent. The bottom line: VPCs are more about peace of mind than actually increasing security.

The ZapThink Take

You’ll have to excuse me, I’m in a particularly snarky mood today. I must admit that the title of this ZapFlash is actually an overgeneralization. It’s certainly possible that your Private Cloud is more secure than some Public Clouds out there. The true message of this article is that building a truly secure Private Cloud is much harder than it sounds, and the extra work necessary has largely already been taken care of by the Public Cloud providers. And it should now be obvious that Private Clouds are by no means inherently more secure than Public ones.

But there’s a bigger lesson here. Security is all about risk mitigation, and it’s simply impossible to reduce your risk to zero. There’s no such thing as perfect security, which is another way of saying that perfect security is infinitely expensive. Risk mitigation involves weighing acceptable risks, given the nature of those risks and the cost involved in mitigating them. When you deliberate on the question of Public vs. Private Clouds, keep in mind that both approaches are inherently risky—but then again, choosing neither is also risky. Your job is to get the necessary facts in order to make the best decision you can about which risks you are willing to accept. Confuse FUD with facts at your peril.

<<The adage of “No Pain, No Gain” isn’t just for sports. While all organizations fantasize about a fully-integrated IT paradise that works seamlessly across departments, groups and geographies, few actually sign up to experience the pain involved in the process of integration.

The only reason anybody spends money on integration at all is because software, as a rule, doesn't integrate by itself. But no executive thinks that spending money on integration addresses a strategic need of the business. Instead, money spent on integration typically goes into fixing something that really shouldn't have been broken in the first place.

Based on the traditional approach, a software application is defined with system-based requirements, its design, and then coding and testing within a well-defined software development lifecycle. The primary focus is on the code's implementation. As a result, integration with teams has traditionally been tightly coupled with little consideration for metadata. Today, integration solutions and paradigms have shifted the focus to code re-use and consolidated application solutions. This approach redefines the solution based on business-defined services - which is how it should have been done from the start.

With the introduction of service-oriented architecture, the paradigm of business users creating application functionality was very exciting and led to a lot of buzz. This was done through building and managing business processes, all hosted on an enterprise service bus - thus disentangling the integration “spaghetti” forever. SOA abstracts the underlying technology, so that developers enmeshed in connecting systems and applications can now focus on building services. With a selling proposition like that, it was no surprise that everyone wanted a piece of the action.

What Isn't Working with SOA

However, for all the excitement SOA generated, the enthusiasm has dimmed a bit somewhere down the line. So, what happened?

SOA is usually mistaken for a set of Web services defining a complete solution. Rather, SOA is a technology paradigm that supports the processes defined and governed by business. There has been a considerable investment in building SOA infrastructure already, but the payback has been slow, leading companies to invest in development of Web services rather than define a pure service bus.

There is a perception of 'SOA' as a means to enable integration with legacy systems. Legacy encapsulation can certainly be a great enabler for business processes, but it doesn't substitute for an effective SOA strategy.

A successful SOA initiative should focus on reducing complexity, transforming systems into services that implement core capabilities and eliminating redundancy. Further, it must define common patterns that apply to all business units and set up 'software factories' that enable the delivery of new products as services in a fraction of the time it used to take.

A successful SOA initiative must begin with strategic investment and aim at lowering total cost of ownership as subsequent implementations takes place. For an organization to adopt this strategy, it needs to be mature enough to take the risk of initial investment. Organizations with a clear focus on implementation will reap long-term benefits. To define the SOA roadmap well, it is critical to understand that it is about processes or services definition as well as technology and people. (See Figure 1, left.)

What Should We Be Thinking About?

Cut through the hype, be realistic. SOA has been overhyped, oversold and set up to fail. Headlines decrying the failure of strategic SOA projects tell tales of woe. In many cases, organizations that merely needed some straightforward extensions to their existing architecture were up-sold unwieldy architectures that proved impossible to deploy. It's a bit like starting to build a bypass for a town, but somewhere along the way the project grew to the size of a major city. Some useful reality checks:

• Ensure relevance by grading usefulness of each solution fit.
• Start small and deliver business value before becoming more ambitious.
• Define a roadmap for the entire service lifecycle, not just service identification.
• Ensure that SOA is requirements-driven and not demand-driven.

Crack the whip and rein them in. Governance is one of the most abused terms in the SOA world. Many on the SOA team manage architectural principle exceptions to orchestrate grossly inappropriate solution architectures. Those who question them are labeled prudes and dismissed in the name of progressive architecture. It is imperative to determine and price-out the SOA solutions that actually provide significant value to business. Applications that provide very little value to business but cost an awful lot are the ones to eliminate first. Doing SOA right requires core services and infrastructure to be built before the high-visibility, high-value projects can be properly accomplished. It is important to ensure strict adherence of key projects to all governance mandates.

Skip the canonical data model. Purists may shake their heads, but our experience has been that the enterprise canonical data model is not indispensable for an SOA initiative. The way forward is a federated MDM strategy and a brokerage approach to communication between systems. This should ideally be based around a distributed data strategy that leaves information in the source systems but provides references between them. If you consider the impossibility of imposing the canonical data model on your next SaaS provider, the virtue of this approach becomes apparent.

Get on the dirty bus. The real enterprise service bus is a myth. The entire enterprise will never get on a single “bus.” This is primarily because there never will be a business case strong enough pull funding for the strategic service model on legacy systems. A more pragmatic approach would be to divide the enterprise bus into two logical sections: the clean data bus that hosts enterprise services adhering to the enterprise service framework, and the dirty bus to host specific services for legacy and non-adhering systems. The dirty bus clearly scores over the erstwhile point-to-point integration, offering greater control over auditing, logging and exception handling.

Socialize and SLA(y) them. In order to ensure that SOA is useful, it will need to be used. Many an organization has lost the fruits of the SOA karma earned over the years because the services developed were not socialized enough. It is essential that the services are published through an elaborate (yet simple to read) service catalog to ensure that they are available across the enterprise for use. The other crucial factor in ensuring reuse (and indeed use as well) is to make results predictable. This is enforced through well-defined and closely monitored service level agreements. SLAs also bolster the business case by ensuring higher level of reliability in meeting business objectives.

So(A), Where Should We Be Looking To Go?

(See related Figure 2, left.)
Is the future cloudy? Cloud computing is the rage today. It is obvious that SOA and cloud computing go hand-in-hand. Cloud computing encompasses any subscription-based or pay-per-use service that, in real time over the Internet, extends IT's existing capabilities. In essence, this is distributed computing. An application is built using the resource from multiple services, potentially from multiple locations. Behind the service interface is usually a grid of computers to provide the resources. The grid is typically hosted by one company and consists of a homogeneous environment of hardware and software, making it easier to support and maintain. Nothing really changes outside of that, including the need to do SOA properly.

Information as a service. Information as a service accepts the idea that data resides within many systems and repositories. The new paradigm's trick is to enable standardized access to this disparate data. Developing vast databases that have been wrapped and delivered as business intelligence snippets to the whole enterprise vastly increases the reach of critical BI. When you combine this concept with the federated mantra of cloud computing and build it on top of an agile SOA-based platform, the nebulous vision becomes much clearer.

Integration as a service. Right now, three critical technologies (connectivity, policy enforcement and semantics) are available as capabilities and/or services within the SOA. The future will see IaaS infrastructure embedded in hardware or offered more often as managed services. Capabilities, such as analytics, will be offered as a real-time service. And this isn’t too far in the future: A major telecommunications company is now manufacturing an appliance with SOA integration built in. Attached in your basement, it connects you to services provisioned from within the company's network. These services go way beyond mere routing and transformation and provide full-blooded process orchestration capabilities.

Lean and agile competency centers. In this rapidly changing business and technology landscape, the first-generation integration competency centers struggled to constantly deliver significant efficiencies, making it imperative to go beyond the obvious. Most organizations are moving toward defining a framework through the transformation of their organization into a “Lean ICC” - one that is agile, efficient and adaptable in responding to opportunities and threats. The Lean ICC shortens the awareness-to-adoption cycle with an accelerated ICC deployment process accompanied by comprehensive but crisp communication and change management. With a highly modularized yet integrated framework, such competency centers are tailored to the specific needs of business, with prioritization based on market dynamics, enterprise inertia, business priorities, investment strategy and ROI.

To get ahead in the game, organizations must align IT with business strategy. Leveraging existing systems, ensuring acceptance across the enterprise and readily adapting to change can improve performance for competitive advantage. SOA is one critical change agent that can no longer be excluded from any serious IT strategy that aims to be a growth-enabler. Architectural assets without the overhead of owning, operating and maintaining them makes eminent sense.>>

You can find this at: http://www.information-management.com/newsletters/SOA-cloud-as-a-service-ROI-SLA-10021971-1.html?zkPrintable=1&nopagination=1

Gervas

Rethinking Cloud Service Level Agreements

Document ID: | Document Type: ZapFlash
By: Jason Bloomberg | Posted: February 21, 2012

It’s so easy these days to purchase Cloud-based services. Go online, click a few times, enter your credit card info, and presto! You’re in the Clouds. There’s no question the novelty really hasn’t worn off yet. Have you ever wondered, however, what you’re really paying for? Sure, you have some expectation that the service provider will, well, provide you with some services. But what are they promising to give you, specifically?

Enter the Service Level Agreement (SLA). The SLA is part of the contract between you and your service provider. It spells out the specifics of what they’re providing you as well as penalties the provider must pay in the event that they don’t live up to the SLA.

Or, maybe not.

The reality is, what’s actually in a Cloud SLA, or what should be in such an agreement, is all over the map. Ask the public IaaS providers, and they’ll give you one answer. Ask SaaS or PaaS providers, and they’ll tell you something different. And what about private Clouds? SLAs take on an entirely new meaning there as well. Let’s see if we can make sense of it all.

The Three Contexts for a Cloud SLA

This confusion over what belongs in Cloud SLAs centers on the fact that there are very different contexts for SLAs depending on the heritage of the organization writing them:

• The managed hosting provider context: for service providers who had traditionally been in the hosted data center business, SLAs center on availability, measured in the familiar multiple-nines of uptime. Want 99.9% uptime? Pay one price. Want four nines, or five nines? Pay increasingly higher prices. If the provider drops the ball, they pay you a penalty, usually in the form of service credits. In other words, the crappier the service is, the more of it you get.

• The software vendor context: when you buy a piece of software, you don’t get an SLA at all. Instead, you get an end-user license agreement (EULA). Instead of spelling out what the vendor will do for you, EULAs tell you what you are allowed to do with the software, and more importantly (to the vendor, anyway), what you’re not allowed to do with it. And then there’s all the boilerplate about no warranties or fitness for a particular purpose. When the vendor moves their software to a Cloud delivery model, thus becoming a SaaS or PaaS vendor, they typically retain the EULA context for their offering. From their perspective, SaaS is more about software than about services.

• The enterprise operations context: it is the responsibility of the operations (ops) team to provide and support the IT capabilities the enterprise requires and pays for. If a business unit requires, say, a Web site with a three second or less response time, then infrastructure and solution architects specify the necessary hardware, software, and network capabilities to meet that requirement, the business cuts the check, and the ops team keeps all that gear running as per the requirements. A different business unit may have different non-functional requirements, which might cost more or less, but in any case, would lead to a different SLA. In this case, if the ops team drops the ball and violates an SLA, predetermined mitigation activities that are part of the governance framework kick in, but service credits are unlikely to be on the list.

For consumers of Cloud services, therefore, simply having a conversation about SLAs with your Cloud provider can lead to confusion, especially when there is a collision among these contexts.

When Contexts Collide

Salesforce.com provides an eye-opening case study that shows how confusing the aftermath can be when these three contexts collide. On the one hand, Salesforce is a SaaS and PaaS provider, built from the ground up to deliver software capabilities via a Cloud provider model. On the other hand, a substantial part of their business is with large enterprises who have come to expect uptime-based SLAs from their service providers.

For many years, Salesforce refused to publish SLAs of any kind, instead favoring EULA-type agreements. That is, until some well-publicized downtime back in the 2006 timeframe. Large customers finally realized that their businesses depended on Salesforce, and sought to strong-arm the vendor into publishing—and sticking to—negotiated SLAs.

The word in the blogosphere was that Salesforce fought the publication of such SLAs tooth and nail, relenting only in the case of their largest customers—and then, required those SLAs to be confidential, presumably so that different customers might get different promises. And what about all those Salesforce customers who didn’t have the clout to wrest an SLA from the vendor? Salesforce rolled out trust.salesforce.com, a PR effort meant to convince their customers that they could be trusted to provide good service. In other words, “trust us, we’re Salesforce.com. You don’t need an SLA.”

Salesforce’s apparent anti-customer stance might seem quixotic, but makes sense from the perspective of a software vendor. Why offer to provide free service credits or other bonuses when most customers will buy your stuff regardless? But from the customer perspective, people are left scratching their heads, wondering if some other customer has extracted a better SLA. If everybody is sharing the same underlying infrastructure, then why would Salesforce promise different service levels to different customers?

Private Cloud providers must also navigate their own context collisions. On the one hand, these organizations’ Cloud teams are simply a part of the ops team, responsible for keeping the lights on like they always have. But on the other hand, their internal customers are likely to be comparing private and public Cloud options, or at the least, comparing their internal private Cloud with virtual private Cloud offerings from public Cloud providers. Remember, from the Cloud consumer’s perspective, a Cloud is a Cloud. Why would you expect service credits from one provider and internal service level guarantees from another?

On Beyond Uptime

Of the three contexts discussed above, the managed hosting provider’s focus on uptime is perhaps the most familiar context for SLAs. If you’re contracting with a third party for IT capabilities, then making sure those capabilities are up and running is certainly the most important non-functional requirement, correct?

Not so fast. Clouds are fundamentally different from managed hosting providers in one significant respect: elasticity is even more important than reliability. Remember, when working with the Cloud you must plan for and expect failure; it is the Cloud’s ability to automatically recover from such failures that compensates for the Cloud’s underlying shortcomings. How fast your Cloud can scale up, its ability to do so regardless of the demand, its ability to deprovision instances even more rapidly, and in particular its ability to recover automatically from failure, are the characteristics you’re really paying for.

The surprising conclusion to this focus on elasticity over reliability is that none of the three SLA contexts above are actually well-suited for the Cloud. Instead, you want your SLA to focus more on how well the Cloud deals with unexpected events, including failures, spikes in demand, and other situations that fall outside the norm. After all, these are the characteristics of the Cloud that make it a Cloud. You could say that Cloud SLAs should measure just how Cloudy that Cloud is: in other words, how well it lives up to the core value propositions that differentiate the Cloud from traditional hosted computing environments.

The ZapThink Take

However you look at Cloud SLAs—measuring reliability, Cloudiness, or something else—never forget where the rubber hits the road: the business value the Cloud provides. Why not base Cloud SLAs on how well the Cloud meets business needs? Such a mission-focused SLA would have to focus on specific, measurable goals for the Cloud. For example, if you move your payroll app into the Cloud, your key metric might be whether you made your payroll on time.

Such mission-focused SLAs might be workable when dealing with a SaaS provider, but promise to be quite problematic with PaaS or IaaS offerings, since the mission success with those service models depends upon the software running on the respective platform or infrastructure. In these situations, if something goes wrong, is it the Cloud that’s violating its SLA, or is it something wrong with the software you put in the Cloud?

For system integrators and software developers who are building bespoke Cloud-based apps for their customers, this question is paramount. After all, the customer simply wants their requirements to be met. If something goes wrong, and the consultant points their finger at the Cloud provider and vice versa, the customer will only become more upset. The problem is, poorly architected apps aren’t able to take advantage of the elasticity benefit of the Cloud, through no fault of the PaaS or IaaS provider.

There is an important warning here. It seems that every enterprise and government agency is looking to move many of their apps to the Cloud, and they’re hiring consultants to do the heavy lifting. However, both customer and consultant are still thinking of the Cloud as a glorified managed hosting provider, responsible for maintaining uptime-based SLAs. The reality is quite different. As Cloud-based deployments mature, the line between development and operations blurs, as Cloud behavior merges with application behavior. It will take several years before anybody will have a clue how to write—let alone comply with—an SLA that addresses this new reality.