The move to the public cloud is the biggest computing paradigm to unfold since the early 2000s, when the internet boom first exploded. According to the 451 Group®, enterprise IT executives expect 60 percent of workloads will run in the cloud by 2018. Driving this growth are greater agility and scalability, higher performance, and faster access to innovative technologies, all of which enable organizations to gain a competitive edge.
Just as the nascent adoption of the public cloud introduces new business, productivity and agility opportunities, so too does it expose potential security risks. There are two well-understood facts about the public cloud. First, it is essentially someone else's computer – a set of virtualized resources (compute, networking and application) that you control yet are operating on a system owned by a third party. Second, the public cloud is an extension of your network. Less understood is just how secure your applications and data are in the public cloud. While the cloud service provider infrastructure is likely highly secure, your applications and data in the public cloud are only secure with your help.
Attackers are location-agnostic. Their intent is to compromise your network to steal user data, intellectual property or computing resources, whether in the public cloud, private cloud or physical data center. It is your responsibility to take the necessary steps to protect your applications and data in the public cloud – a fact not always clear to the business groups and DevOps teams driving public cloud adoption. This paper is intended to arm security teams with the information they need to engage early, ask appropriate questions and work toward protecting the public cloud as vigilantly as the data center.
Outlined below are 10 key considerations to effectively protect data and applications in the public cloud from a multitude of ever-evolving security threats that often mirror those faced in a traditional, on-premise data center.
Public cloud providers, such as Amazon® Web Services (AWS®) and Microsoft® Azure®, make it clear security is a shared responsibility. In this model, the provider is responsible for ensuring the platform is always on, available, up to date and so on.
In fact, most believe the cloud provider's global data center infrastructure is more secure than their own. What gets lost is the fact that you, the customer, are responsible for protecting your own applications and data running within the public cloud.
Figure 1 highlights the responsibility breakdown. Securing your workloads in the public cloud (shown in red for clarity) is no different from securing them on-premise. You are in complete control of what security to implement and must take steps to safeguard your content, be that customer data or intellectual property.
Figure 1: Public cloud shared responsibility model
Many public cloud projects are driven by business groups, such as DevOps, that quickly spin up new products or functional prototypes. Challenges arise based on two things: general availability of new application approaches, and the security team, which is often brought in to assist with deployment. Both identify possible architecture-based security holes.
Ideally, security and DevOps should work in tandem to understand the scope of public cloud projects and ensure the architecture of the application deployments meets business development needs while mitigating security risks.
Public cloud usage is often referred to as "shadow IT," given how easily an account can be established. Employees doing what is "right for the business" may create security holes if the environment is not configured properly. It is imperative to know who in your organization is using the public cloud and to ensure the environment is configured correctly.
Figure 2: Public cloud automation test environment
Attackers leverage automation to find potential targets within minutes. Once identified, they look for weaknesses, checking default passwords, probing for SSH misconfigurations and so on.
To highlight the effects of attackers' automation capabilities, a test environment with instances of an SQL database and a WordPress® server was spun up in the public cloud. As shown in Figure 2, the environment was probed from more than 35 countries with more than 25 different applications – all within eight hours. Unlike in a private data center, where there is less concern about public exposure, resources in the public cloud are widely exposed. This example serves as a reminder of the importance of security in the public cloud.
There are several security options to choose from when moving to the public cloud, most of which are similar to the options for physical networks.
Organizations that rely on internal personnel to manage public cloud and security deployments must be prepared for attrition. Typically, only a few engineers know the environment well, but they don't necessarily have time to keep proper documentation or manage knowledge-sharing requirements. If even one of those engineers leaves the company, the organization may not be well-positioned to effectively manage security needs moving forward.
Personal branding consultant John Antonios once said, "knowledge plus action is power." In public cloud security, knowledge begins with safely enabling all traffic traversing your environment, spanning mobile, network and cloud.
Figure 3: Complete traffic flow context
The magnitude of digital data traversing these environments is immense. By utilizing a virtualized next-generation firewall as part of a natively integrated, comprehensive security platform, organizations gain necessary insight into traffic identity and characteristics so they can make more informed policy decisions to protect applications and data from threats.
Native public cloud tools provide little visibility at the application layer. Further, in some cases, in-depth networking knowledge is required to interpret the data accurately. Even with accurate interpretation, knowing that 344KB of data is flowing from a source IP address and port to a destination address and TCP 443 is of limited value when it is well-known that hundreds of applications can utilize TCP 443.
In some hybrid deployments where the public cloud is connected to corporate via an IPsec VPN, the use of port-based controls to limit access to only TCP 80 and TCP 443 is viewed as sufficient, the argument being that exposure is limited only to that which is coming from corporate. This is a fundamentally flawed position.
The reality is that port controls provide an initial level of control but no contextual awareness of the application traffic, the content within or the user. As displayed in Figure 3, understanding the complete context of traffic flow, including the source/destination IP and country; protocol(s); user or user group facilitating the activity; URL category; application identity and specific application functions in use; and specific filename and type can help you make more informed security policy decisions.
There are those who believe the attackers have already "won," and thus choose to implement a detection and remediation approach. However, with complete awareness of your environment, a prevention philosophy is indeed possible. Enabling the prevention of successful cyberattacks in the public cloud requires four key capabilities:
The combination of knowledge and enforcement is a powerful security tool. It's critical to identify applications on the network and in the public cloud – irrespective of port, protocol, evasive tactic or encryption – as well as identify application characteristics, specific application functions in use and relative risk. With this knowledge, a more consistent security policy can be deployed globally to protect your network from known and unknown attacks.
Using application identity as a means of enforcing a positive security model reduces the attack surface by enabling only allowed applications and denying all else. You can align application usage to business needs, control application functions (e.g., allow SharePoint documents for all but limit SharePoint administration access to the IT group), and stop threats from gaining access and moving laterally within your network.
Applying application-specific threat prevention policies to allowed application flows is a key step in adhering to a prevention philosophy. Application-specific threat prevention policies can block known threats, including vulnerability exploits, malware, and malware-generated command-and-control traffic.
Unknown and potentially malicious files are analyzed based on hundreds of behaviors. If a file is deemed malicious, a prevention mechanism is delivered in as few as five minutes. Once the prevention technique has been delivered, the information gained from file analysis is used to continually improve all other prevention capabilities.
The public cloud enables your organization to address business challenges with an agile, more scalable approach. To take full advantage of the cloud, recommended best practices include "applying the concepts of the data center to your deployment, while leaving the traditional constructs behind." This way, organizations can achieve high availability and scalability.
Using traditional two-device high availability as an example, we can assume that the premise behind HA should be applied to your public cloud deployment. However, the advantage of hardware-based acceleration for sub-second failover is lost when operating in the public cloud because you are operating on someone else's computer. To execute failover from one device instance to another, the process is accomplished in software. This may take up to 60 seconds depending on the environment, and might not span different regions. The cloud-centric approach utilizes the cloud provider fabric and its inherent resiliency features, such as load balancing, to quickly and seamlessly accomplish the end goal of HA.
Figure 4: A Cloud-centric approach
Automation is a central tenet of the public cloud, where rapid change is common. When security best practice change control is followed, the delay may induce friction, slowing deployments or, worse, weakening security if the deployment does not "wait" for change control to work. By automating security in the public cloud, organizations can eliminate security-induced "friction" and take advantage of the flexibility and agility benefits offered in the public cloud. Automation tools that organizations should look for in their public cloud security include:
To maintain effective security for data and applications in the public cloud, policy consistency is essential. Controlling your distributed network of firewalls, physical and virtualized, from one central location and applying a single, consistent security rule base from the network to the public cloud is critical to maintaining security functionality and efficiency. Centralized management provides insight into traffic and threats network-wide, simplifying management and helping you minimize security policy lag as workloads in the public cloud change.
Organizations are boarding the public cloud train to achieve more efficient time to market, improve overall business and continue carving a competitive edge. However, as business-centric groups continue to drive adoption, security teams are not always involved in the process. Based on common experiences, these security considerations are designed to be educational and informative. Ideally, the goal is to encourage dialogue between the security and business groups to achieve a public cloud architecture and deployment that accounts for both groups' demands.