InfoSec Blog - What is the security risk of a cloud transition?

If you are in IT or in Information Security, you may have been asked to assess the risk of a transition from on-premise to [...substitute your favorite cloud provider...].  Clear question, isn’t it? What would be your response?

 

Risks in IT stem from diverse sources, both computer and non-computer related, for example, vulnerabilities due to software defects, personnel skill gap, or physical security. Risk responses include risk acceptance, avoidance, mitigation, sharing, or transfer [1]. The optimal response depends on specific situation; let's see how three stages of such cloud transition may look like for a simple service.

 

On-premise 

Let’s assume we have a three-tier service (web, application, database) self-contained in a single server running in our datacentre and we wish to migrate it to one of the major public clouds, for example, the Amazon Web Services (AWS) [2]. This is just an example – not an endorsement.

 

On-premise 3-tier service

Figure 1: On-premise 3-tier service

 

In terms of risks, our organization is responsible for practically everything in this case: datacentre infrastructure (physical security, networking, power), server hardware, operating system, storage, app server, application libraries, and more.

 

Step one: re-hosting

The simplest transition to the cloud is to virtualize our service and drop it into the cloud as a Virtual Machine (VM). Given our example of AWS, the VM would move into the AWS Elastic Compute Cloud (EC2). At the minimum, we need to create the virtual networking (Virtual Private Cloud – VPC) with a virtual machine (EC2 instance), preferably the same OS as on-prem and redeploy the service. We will need the AWS Elastic Block Store (EBS) for the storage volume and we will also interact with the AWS Identity and Access Management (IAM) service. We will not need to make significant changes to our three service tiers web-application-database (Figure 2).

 

Re-hosting from on-prem to the cloud

Figure 2: Re-hosting from on-prem to the cloud

We have now decreased our risks by both mitigation (embracing new security controls offered by AWS) and transfer (of some services to AWS) - we are no longer responsible for the physical security, physical infrastructure, virtualization layer. However, we are still responsible for the configuration of security groups, routes (not routers themselves), network ACLs, subnets, and also the complete OS, web, application, and database.

 

Step two: incremental changes

We have a number of other options to gradually lower the risks – we can place the service behind the AWS Shield to protect the service from denial of service attacks or Web Application Firewall to minimize other types of web attacks (both of these are services managed by AWS). If our service supports clustering we can deploy it to multiple AWS availability zones (datacenters) behind an AWS Elastic Load Balancer to scale and increase the availability. To achieve even higher degree of availability it can be deployed across multiple AWS regions (geographical regions across the globe) with the traffic directed by the AWS DNS service Route53. We can integrate the service with the AWS CloudWatch to monitor and better understand the workload and also automatically resolve availability or performance issues. The AWS CloudTrail provides audit data on any configuration changes; additionally, we can actively enforce change management requirements with the AWS Config. As our deployment is getting more complex, the AWS CloudFormation helps us to define the infrastructure as code (Figure 3).

 

 

Gaining more benefits through incremental changes

Figure 3: Gaining more benefits through incremental changes

 

All of these services are managed services and AWS is responsible for the underlaying infrastructure and maintenance.  In the Shared Security Model, we are responsible for the service selection and configuration. The core of our service remains a monolith and we are still responsible for the OS, application server, web servers, and of course the application itself.  Can we divide this monolithic service model apart to decrease the risks further?

 

Step three: all-in

Except for the initial “re-hosting”, we arrived at this stage with a set of localized small changes. To move away from the traditional server model (and the associated risks) we can take the following steps: the application can be deployed to a container running on AWS Fargate which is a serverless service and the database migrated to Amazon Aurora Serverless. Alternatively, if our service is event-driven we can re-factor the application tier into individual functions running on AWS Lambda (Function-as-a-Service) behind the Amazon API Gateway. The Amazon S3 can host the static content and a NoSQL database in AWS DynamoDB store our application data.  We have now eliminated the risks and costs associated with the OS layer as all these services are managed, serverless, even highly available (AWS manages the servers, networking, backups, software updates – not us). The API Gateway, Lambda, and S3 replaced the web and the application server tiers.

 

Going serverless

Figure 4:  Going serverless

 

While this stage presents a major leap in decreasing the risks associated with the infrastructure and support it requires a lot of effort in re-factoring our application. It also brings new risks related to, e.g., vendor lock-in, loss of control, required skills.

 

Conclusion

We have seen several transition strategies applicable to a simple service and each had different impact on the associated risk. In order to assess the risk, we need to know how deep into the cloud transition the organization is planning to go and understand the various strategies. As the chosen strategy and the risks are inter-related the analysis may need to consist of several iterations involving the cloud solution architects, the business analysis professionals, in addition to the risk assessment experts.

 

Written by: Zdenek Nejedly (Access Management Senior Analyst, Information Security and AWS Certified Solutions Architect – Associate)

 

Details on risk management and AWS services are available below. The diagrams in this blog were created with the AWS Architecture Icons for Microsoft Visio [3].

[1] NIST Risk Management Framework [csrc.nist.gov/Projects/risk-management/rmf-overview]

[2] Amazon Web Services (AWS) https://aws.amazon.com/

[3] AWS Architecture Icons https://aws.amazon.com/architecture/icons/