Savvis blog

About a month or so back, I was attending a tradeshow where I happened to overhear a passionate argument between sessions about the impact of cloud on risk management. It was one of those times when I was trying my best not to eavesdrop, but these two gentlemen were so vocal about their various opinions that it was hard not to hear.

The crux of the argument had to do with whether cloud made risk assessment easier or harder to accomplish. On the "easier" side was the argument that reviewing a cloud services provider once and using contractual language to "lock in" operational controls took several review steps out of scope. On the "harder" side, the argument was that the risk assessment process had to be done for each type of business process that intersected the provider since no one audit could account for every way that the provider would be used (i.e., "Today we use the CSP for public data and we audit their controls for that case, but the business could move private data there tomorrow once the vendor is approved").

It was an interesting discussion and, as you can tell, it stuck with me. I'm still not sure who was "right" in this particular discussion - they both made valid points. But it seems to me that there was something bigger left out of the discussion: namely, the impact of cloud on mitigating control selection.

Here's what I mean: No matter whose model of risk management you're using (ISO, NIST, Octave, etc.), there's more than just the assessment phase. After assessment, there comes risk treatment. In most cases, that means control selection.

Cloud changes this, it seems to me, quite drastically. Specifically, when you engage a cloud provider - whether IaaS, PaaS or SaaS - you are drawing a line in the sand. In effect you say, "Everything below X level of the application stack will be a black box." You are deliberately abstracting yourself away from some portion of the technical substrate. In an IaaS context, it could be that portions of the network leave your scope of control while the OS and platform stay in it. For the PaaS, you retain control over the app but you give up control over the platform ... and everything below that (OS, network, etc.). For SaaS, the whole potato is a black box (the application and everything below).

For some purposes, this is a good thing. The less that's in your scope of control, the less you have to deploy custom security controls to address particular issues. However, it's also important to remember that once a particular level of the stack goes from being "something you can manipulate" to "something you can't," you also lose the ability to deploy a compensating control at that level. This impacts (or at least should impact) your control selection.

As an example, say you have an application that's historically been hosted within your organization's infrastructure. If you discover an issue at the application layer (say the application is vulnerable to SQL injection), you have a number of options across every level of the application stack. You could, for example, update the app. Alternatively, you could implement monitoring in the database or middleware, or you could implement host-level controls or network-level monitoring. All these options are open to you because you control every layer of the stack.

In a cloud context, options are more limited. If you use a PaaS, you can't deploy an OS-level control because you don't control the OS. Is this an issue? Maybe not ... at least, not if you're planning for it. But the bigger issue is what happens when you move existing applications and business processes to the cloud. In that case, compensating controls can "fall on the floor" unless you've either A.) kept detailed records of compensating controls you've historically put in place mapped to the original risks so that you can gauge their efficacy in the new environment or B.) systematically re-evaluated each application to determine what compensating controls will need to be re-implemented. And, not to be a pessimist, but most firms aren't doing either of those things.

Now, I'm not going to say that every firm out there should start from scratch in their risk mitigation strategy when they move to cloud. But I will say that a move to the cloud - at least for firms that are serious about security - could be a useful time to evaluate risks in the applications and processes that they plan to move.

Ed Moyle is senior security strategist at Savvis, a CenturyLink company.

********

Your company's success largely depends on the need for ongoing service and support throughout the life of your outsourced IT infrastructure. Unfortunately, many hosting providers are giving you less service and less touch than ever before.

"Self-automated" and "self-service" are probably terms you're becoming all too familiar with. In some cases customers are satisfied with a standard support model where they engage helpdesk resources to help them navigate and solve an issue with their infrastructure.

Oftentimes, however, complex requirements and issues arise that simply outstrip the model for industry standard support. These complex issues present themselves in the form of large-scale hosting environments, complex technology issues, capacity planning issues, invoicing, portal API development assistance, even full-scale migrations - the spectrum for complex planning and problem solving is incredibly vast. And it takes people to balance it. You need designated resources that know your environment and understand your business objectives (and the urgency behind them).

In the past, coordinating this type of personnel and these efforts might have required a Statement of Work. Further, the lines of communication between your main point of contact and the technical personnel responsible for solving your problems might have been lengthy. You need committed resources and visibility into what's being done.

If you're looking for this class of service, consider a unique team of experts designed to provide additional levels of consultation and support beyond what is included with standard hosting services. These experts could support incident management, problem management, change management, project oversight, training, billing inquiries and more. Plus enhanced customer service often also includes regular touch-base consultation, service reviews, infrastructure planning, monthly reporting and performance scorecards.

Whether you require a lot of support for an extremely complex environment, or you just want a single point of contact that you know and trust to help you sort things out, you need the right personnel. The service provider will have your best interests in mind when setting you up with a designated resource and the technical personnel to back it up. Your business warrants that specific personnel are assigned and trained to become experts on your environment. This ensures the most intimate level of commitment and success.

The overall goal of Savvis Service Management, for example, is to increase customer satisfaction through a tightly bound global network of designated personnel, trained and capable of assisting with on-going support, change management, consultation and training that provides all of the operational support you need, but goes beyond that - into consultative and strategic support for the long run.

Mark Dickinson is senior product manager, hosting, at Savvis, a CenturyLink company.

I am astonished by how little practical or empirical data exists on the topic of cloud bursting. A quick Google search on "cloud burst" or "cloud bursting" yields, well, not much - that is, short of "Men Who Stare at Goats" references, questionable YouTube clips and a campy '80s "art rock" video. To further mystify the topic, all of these data points really revolve around the dubious and Fringe-esque claims of "cloud busting" (notice the missing "R") - or making rain by tampering with clouds.

Yet, the concept of cloud bursting (with the "R"), or horizontal application scaling into the cloud (i.e. moving compute workloads into an on-demand resource pool to access additional capacity), has come up in just about every one of my conversations with enterprise clients. Why? Because this could be one of the fastest and most impactful ways for customers to harness the power of cloud computing to grow applications and respond to seasonal, cyclical, or ramping demands ...  and it's really pretty straightforward if you have selected the right cloud provider.

I guess I shouldn't be too surprised about limited information on the topic, considering that cloud capabilities vary greatly from provider to provider (see our evangelism efforts on Not All Clouds are Created Equal). Therefore, there is not one easy three-step guide on how to cloud burst. But, hypothetically, if one were to exist it might look something like this - assuming you have your workloads already virtualized:

1. Define what you will be bursting. Of course, this relates to applications - but the important question is which layer within the application architecture is ideally suited to a cloud bursting use case? Is it the web, application or database layer within a traditional three-tier relational database-driven application stack, or are we talking about a flat file, NoSQL or big data bursting scenario?

2. Select your target cloud. This directive is tightly correlated to how you responded to the first step, since cloud service providers each handle tiered models and distributed data models differently. Most enterprises tend to prefer highly secure and high-performance cloud that makes it easy bring in workloads.

3. Convert your source images and upload. Based on the provider you have selected, it's time to bring in your image. Is it a VMDK, OVF, XenVM or something else? It's common that VMs in even Open Virtualization Format should adhere to some service provider-specific configurations. Tools like VMware Studio, Platespin and others can be used to convert workloads.

Now that you have identified your applications, chosen a provider and converted your image to interoperate with your cloud, as well as uploaded it, you are practically there! However, there are still several factors to consider, and cloud vendors handle these very differently:

- How will you launch your workloads? From a template, from a clone or from a dormant VM/instance?

- How will you connect, and how much data do you intend to push over this network connection? Is it a point-to-point network, MPLS, EVPL or VPN, and is it production data, metadata, sensitive data or management traffic?

- How automated should this solution be? An API can provide full automation, but will require coding and additional business logic in your applications. Is the cloud portal you have chosen easy enough to operate to take advantage of cloud bursting?

- How will the cloud handle your security policies? Does the cloud you have chosen have the governance and maturity you would expect for you data? Can you even bring your own policies into the cloud? After all, the cloud holds your data, shouldn't it be able to support your existing IT policies?

- How will you handle load balancing? Will you need local and possibly global load balancing that can be dynamically updated to include the new workloads you have bursted into the cloud?

- How will you charge back? Does your cloud bursting solution make it easy to charge back internal and external customers and set spend limits, controlling cloud sprawl and avoiding the auto-ballooning of cloud costs?

Whether you are cloud bursting or busting, as the great Lil' Wayne eloquently put it, "Make it Rain." Optimize your existing workloads and select the right provider - one that cannot only help burst your workloads onto enterprise-class cloud platforms, but also help you develop the IT strategies you need to grow your business.

Aditya Joglekar is director of cloud business solutions for Savvis, a CenturyLink company.

Identity management is a hard problem. It's hard technically, it's hard to get executives and business partners to care about it, and it's hard when complexities (like cloud and mobile) are introduced to the environment. In fact, if you look at identity from an economic point of view - and you systematically analyze the costs of identity in your environment (including provisioning, access management, access review, etc.) chances are good that you're spending more on those things - organization-wide - than just about anything else IT related.

If that doesn't resonate with you, it could be because the costs are hidden - or at least don't show up as a line-item in the IT budget. Consider, for example, the costs of provisioning across the enterprise as a whole. The IT side of the issue is probably pretty obvious: You see the impact to staff time; you see the impact to helpdesk overhead, etc. But there are other aspects of this problem that don't hit IT and may be less visible.

Consider provisioning of access to specialized business apps or one-off apps that aren't maintained or supported by the IT department. For example, if the individuals who actually create users accounts are specialists on the business side - their time represents a cost (in many cases a large one) to the organization, but because IT doesn't directly feel the costs involved, they can potentially go unnoticed. If noticed, they may not be top of the priority list to address.

The same is true for access review. If, like many, access review consists of a periodic report to managers along with a request for them to evaluate the appropriateness of accounts and user roles, their time costs money - not your money, but someone's. The time those managers spend in that task don't hit the IT budget, but yet cost the organization significant dollars on a per-year basis.

Lack of ROI Means Money Out of Your Pocket

The point is that it's not cheap. Because of that - and because the economic impact may not be directly visible to management, that means it's often hard to build support for improvements (e.g., automated provisioning, access management, monitoring and other identity-related systems and tools). It's a dilemma: From a security point of view, it's in our best interests to see those tools get deployed and improvements made - but fighting the myopia is hard.

It's hard to have a conversation like, "We spend X on identity now, but we want to spend X-Y on operational costs by purchasing a tool with an initial capital outlay of Z. Although the tool will set us back by Z this year, we anticipate it'll pay for itself in N years and subsequent cost savings of Q over the lifetime of the product, which we estimate to be L."

It's hard to argue with reasoning like that (assuming your numbers aren't bogus). But you can't do it for identity when the relevant variables are spread around the organization.

For security pros it's frustrating because in almost every case, it's cheaper to replace legacy manual processes with an automated system, because it's more effective from a security standpoint (reducing human error and ensuring coverage), and because it helps in a cloud context. Cloud vendors can (or at least should be able to) leverage the output of these tools directly - for example through support of technologies like SAML, SPML and XACML (to mention a few). But proving it's better without numbers is like trying to catch the wind.

Can You Get Visibility? Maybe Now's a Good Time

So for the pragmatists out there - what can you do?

Say you want to be able to build support for an automated identity approach but you're finding building a business case to be challenging because of the invisibility of costs described above? Some will tell you to make stuff up - i.e., "estimate based on numbers of accounts created, average review time, etc." As a last resort, this can be a "better-than-nothing" Hail Mary - but it also has the potential to blow up in your face. Like maybe if the person you're presenting your calculations to spends five minutes reviewing his/her access list and the average you estimated is two hours; it's hard to pull back from that if they lose confidence in your numbers from the get-go.

One strategy you can try first before resorting to guessing involves leveraging existing IT metrics initiatives to attempt to collect data organization-wide (i.e., outside of IT). For example, looking to current hot initiatives to piggyback on: If you're in the federal government, you could include these metrics in your required continuous monitoring strategy (it's a requirement, it's top of everyone's mind, so now is a time you might be able to get farther than otherwise). ... In the private sector, you could attempt to leverage your cloud initiatives themselves to help gather data by making it part of questionnaires or data-gathering being done to support a cloud move. In fact, anything that involves data-gathering from the business (a BIA, vendor review, auditing, etc.) can be a good place to try to find data sources to help drive a realistic cost model.

The point is - getting good data here is a fundamental part of building a useful cost model that accounts for both visible and "hidden" costs. And if you really want to get traction with investments to your identity management program, chances are good you'll need this kind of hard evidence to make progress.

Ed Moyle is senior security strategist at Savvis, a CenturyLink company.

Are independent software vendors (ISVs) prepared for the next generation of service integration and intermediation?

Over the last several years we have discussed the opportunities and challenges of moving to a Software-as-a-Service (SaaS) model. At Savvis, we have spoken to hundreds of software companies and each seems to be at various stages of their SaaS migration. Some have built out their own infrastructure because a cloud service did not exist when they were going to market or they jumped, feet first, into a cloud platform and are now reaping the benefits. For whatever reason, the choice was made and execution began.

So now we're in early 2012 and ISVs are evaluating or re-evaluating their prior infrastructure decisions. SaaS is going through a metamorphosis. That is, ISVs are looking for new channels to market and having someone else sell their Software-as-a-Service on their behalf. If, as an ISV, you haven't already begun planning for intermediation, aggregation, integration and trust, you need to.

Let me start in reverse order: You must find a cloud platform that you can trust. It isn't just about you trusting the infrastructure on which your application is running, but also about what your customers need. Your enterprise customers are evaluating the application AND they want the peace-of-mind of knowing that their application is running on enterprise-grade infrastructure and that the cloud provider hosting it has the experience to manage and secure their cloud effectively and efficiently. Enterprises also want to know that the application can scale appropriately in the cloud and can grow and expand globally.

Enterprises also need applications that integrate with legacy applications and infrastructure. The best way to achieve this is for you to run your application in a data center where your customers already have a footprint. Instead of trying to integrate applications over the Internet, it makes sense to place your application with a service provider that has network experience and a global backbone so that data can be manipulated securely with private connectivity. A simple example of this is a cross-connect. A cross-connect offers off-Internet connectivity where data can be prioritized through quality-of-service.

Your application will also need a robust set of APIs. Over the next several years, your application will be driven through a set of services, such as user access, billing, monitoring, management and auto-scaling, just to name a few.

Another consideration is aggregation. You want to run your application in a cloud where other applications are running. When your cloud provider hosts a broad and comprehensive set of business applications, it makes it easier to integrate with the services that your enterprise customers demand.

Lastly, if you haven't already, you need to begin thinking about intermediation. In the future, you may be considering new channels to market and need assistance accessing enterprise customers or maybe you are considering going down-market into the small and medium business (SMB) space. Your cloud provider should be able to assist you with this.

Innovation is everywhere, and focusing on your application and expanding it to meet future needs will bode well for the future of your software business. I look forward to your comments.

Larry Steele is technical vice president, Software-as-a-Service, at Savvis, a CenturyLink company.