Welcome!

How to Implement Large Complex Cloud Solutions

Ed Featherston

Subscribe to Ed Featherston: eMailAlertsEmail Alerts
Get Ed Featherston via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Cloud Computing, Cloud Security Journal

Blog Post

Moving to the Cloud By @EFeatherston | @CloudExpo [#Cloud]

The cloud is no less secure than your current internal environments (for many, it may actually be more secure)

Moving to the Cloud – Can I Take My Security with Me?

You can't have a conversation about technology today without the topic of security breaches ending up front and center as a key concern. This is understandable with all the high profile breaches that have been occurring on what seems a regularly scheduled event. Anthem, the nation's second largest health insurer is the latest in a long line of high profile breaches that have occurred recently. Given the size and severity of these breaches, security is very visible on everybody's radar. This is especially true when discussing migration to the cloud. Unfortunately every breach can result in slowdowns or impediments to cloud migration plans.

The reality is breaches are not going away (see ‘The cloud, security, & breaches - Are the Barbarians at the gate?' for a discussion on that). That doesn't mean you should abandon any plans on migrating to the cloud. The cloud is no less secure than your current internal environments (for many, it may actually be more secure). As with anything else, the key to success is proper planning and designing of your solutions. Let's talk about some of the considerations that need to be addressed that can help alleviate concerns that may be raised due to the hype and emotion of the high profile breaches.

Who owns security in the cloud?
Whether your cloud migration is a SaaS solution, an in-house application migrating to an IaaS solution, or anything in between, ultimately the security of your system is your responsibility. I know there are some that may take me to task with that statement. Let me clarify by saying what that responsibility translates into. It is dependent on the type of implementation/platform being considered. SaaS solutions have security mechanisms and capabilities baked in. So it would seem that the SaaS provider is responsible for security. While they own the technical implementation, you own defining what your security requirements are for that system. Key to that is defining the SLAs you have with the SaaS provider, ensuring they meet or exceed your requirements. The SaaS provider is responsible for executing on those SLAs once they are defined. As you get further down the platform food chain towards IaaS, your responsibility and ownership grows. As well as defining the requirement, you are then responsible for defining the implementation as well.

This is no different than if these applications were in-house, and not in the cloud. Over the years you have probably had many COTS (Commercial off the Shelf) packages deployed. The security implementation is baked into those, just as in a SaaS solution, but you (hopefully) defined what the security requirements were for the package. With house developed applications, as with an IaaS implementation, you were responsible for defining the requirements as well as the technical implementation. Dealing with security concerns in the cloud is no different than dealing with security concerns internally.

One other piece of ownership that sometimes gets forgotten: security testing. No matter the platform, you should own the testing and validating of the security mechanisms in place for your cloud solution. When you define your security requirements, ensure they are measurable, and that a test plan is developed for validating those measures.

Can I take my security with me?
Absolutely. Any of the industry standard security mechanisms are available from all the major cloud providers and implementations. The cloud is not magical; it is still made of the same hardware and software systems you use on a regular basis, and the same security mechanisms are available. The question really should be: Do I want to take my security with me? As with any rationalization process (and migrating to the cloud is a rationalization process), one of the steps should always be a re-evaluation of current security mechanisms. This is an ideal time to determine if there are any new requirements (perhaps based on learnings from recent breaches for example), identify gaps, and select a solution to address those gaps.

A critical component to consider when migrating to the cloud is: How will the data be secured during the migration process? Securing the application is straightforward, as the normal considerations when developing an application apply. The difference when migrating to the cloud, specifically if migrating to a public cloud, is the security mechanisms needed to ensure the data is protected during the transfer process. This is not a step that is usually considered in standard application security mechanisms, and can result in creating a risk during the transition process. This should not be a show stopper, just ensure it is included in the plan and design.

Don't let your migrations be governed by hysteria, hype, or emotion
As I discussed in the article ‘Moving to the Cloud - Cloud Rationalization,' Rule #1 in migrating to the cloud is take the emotion out of the equation. Also avoid migrating because of the hype. Not everything should or will go to the cloud, but don't let fear and hysteria about breaches and security risks be the reason for not migrating. Do the proper planning and design, define what the security needs and risks are based on the data within the system. Not all data is created equal - some should be more secure than others. Our job as technologists is to ensure the processes are in place, and the business educated to the real vs perceived risks, so that the decisions are made based on reality and business value, not on the latest breach in the headlines.

This post is brought to you by The DNA of The Cloud, Intel and Verizon.

More Stories By Ed Featherston

Ed Featherston is VP, Principal Architect at Cloud Technology Partners. He brings 35 years of technology experience in designing, building, and implementing large complex solutions. He has significant expertise in systems integration, Internet/intranet, and cloud technologies. He has delivered projects in various industries, including financial services, pharmacy, government and retail.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.