CYBER SECURITY TREND #4 FOR 2016 and 2017: SECURITY CONCERNS TO ADDRESS BEFORE MOVING TO THE CLOUD

By - June 3, 2016

In our next submission in this series we will touch on Gartner’s fourth projection for 2016 and 2017 which is focused on the growth of cloud services.

All Things Cloud: With growing business requirements for scalability, diversity, and processing driving ever-more businesses to the cloud, Gartner predicts cloud security services have evolved in capability to the point that they are increasingly considered to be acceptable for organizations of all sizes (though not every organization) moving into 2016—Gartner goes on to add that cloud access security brokers will also grow their capabilities during this time period, and emerge as a solution for ensuring multiple security controls are able to be maintained over an organization’s cloud assets and resources.

The growth of cloud usage within the mid-market is something that RSM has addressed on a wide variety of occasions, so for this posting we’ll summarize the points that have resonated most deeply with our clients. Before starting the process to move sensitive systems, data, or applications to the cloud, organization must understand:

Architecture: What is often referred to as “the cloud” usually takes the form of one of three major architectures, and proper security and regulatory compliance is directly tied to which model you are using.

  • Software as a Service (Saas) is the most common example in which an organization simply utilizes an application completely controlled by a third party. Popular webmail and document sharing platforms are examples. In this scenario, you will have very little opportunity to perform security reviews on the platform, and you will primarily manage your risks via the contract. Pay close attention to availability, ownership of liability, and the cloud provider’s responsibilities during a data breach.
  • Platform as a Service (PaaS) typically means that your organization will move an application to a cloud provider, and that provider will provide you with the necessary virtualized server and connectivity to allow that app to function. In these situations, you will still manage your vendor risk via the contract, but ensure that your team understands that they are still responsible for maintaining the application itself.
  • Infrastructure as a Service (IaaS) means that you are taking existing physical or virtual servers and moving them wholesale into a cloud environment. The vendor’s primary responsibility is to manage connectivity and the security of the underlying infrastructure, while your organization is still responsible for securing the apps and operating systems.

Models: Similar to the points on architecture, organizations need to understand what model of cloud solution they are moving to, with a specific focus on whether or not the model will meet their regulatory requirements.

  • Public: The most common example and represented by solutions such as Gmail or DropBox. All customers are in the same basic environment, which meets basic security controls.
  • Community: These cloud environments are built to meet the security and regulatory requirements of a specific industry. Examples include environments built to meet FISMA (FedRAMP), HIPAA/HITECH, and PCI requirements. They tend to be more expensive than the public cloud options.
  • Private: Organizations with very large internal IT operations may decide to deploy a cloud solution within their own environment. This provides complete control over security and compliance but is the most expensive option.

Zombies: This may seem like an awkward phrase to use during a discussion about cloud services, but it is the largest risk we encounter in many client environments. The core of the issue is that once an organization moves a system, application, business process, etc. to the cloud, it is assumed that the original asset is shut down in fairly short order.  In reality, most studies show that this sun setting process takes an average of 2-3 years. This is normally the case because there are linkages to the original system that cannot be broken and it can take months or years to unwind those dependencies.  It is very common that as soon as the cloud migration takes place attention is diverted from the original systems even though they are still alive and potentially full of sensitive data. Before long the application and underlying operating systems are not being maintained, which creates a situation in which a zombie system (not quite alive, not quite dead) is sitting on the environment, highly vulnerable, and presenting a huge risk to the organization. Make sure that a core part of the cloud migration strategy is the full maintenance and tracking of these systems until their final removal from the network.

Receive Posts by Email

Subscribe and receive notifications of new posts by email.