Ensuring Data Privacy in Public Clouds
Most enterprises spread data and applications across multiple cloud providers, typically referred to as a multicloud approach. While it is in the best interest of public cloud providers to offer network security as part of their service offerings, every public cloud provider utilizes different hardware and software security policies, methods and mechanisms, creating a challenge for the enterprise to maintain the exact same policy and configuration across all infrastructures. Public cloud providers typically meet basic security standards in an effort to standardize how they monitor and mitigate threats across their entire customer base. Seventy percent of organizations reported using public cloud providers with varied approaches to security management. Moreover, enterprises typically prefer neutral security vendors instead of over-relying on public cloud vendors to protect their workloads. As the multicloud approach expands, it is important to centralize all security aspects.
When Your Inside Is Out, Your Outside Is In
Moving workloads to publicly hosted environments leads to new threats, previously unknown in the world of premise-based computing. Computing resources hosted inside an organization’s perimeter are more easily controlled. Administrators have immediate physical access, and the workload’s surface exposure to insider threats is limited. When those same resources are moved to the public cloud, they are no longer under the direct control of the organization. Administrators no longer have physical access to their workloads. Even the most sensitive configurations must be done from afar via remote connections. Putting internal resources in the outside world results in a far larger attack surface with long, undefined boundaries of the security perimeter.
In other words, when your inside is out, then your outside is in.
[You may also like: Ensuring a Secure Cloud Journey in a World of Containers]
External threats that could previously be easily contained can now strike directly at the heart of an organization’s workloads. Hackers can have identical access to workloads as do the administrators managing them. In effect, the whole world is now an insider threat.
In such circumstances, restricting the permissions to access an organization’s workloads and hardening its security configuration are key aspects of workload security.
Poor Security HYGIENE Leaves You Exposed
Cloud environments make it very easy to grant access permissions and very difficult to keep track of who has them. With customer demands constantly increasing and development teams put under pressure to quickly roll out new enhancements, many organizations spin up new resources and grant excessive permissions on a routine basis. This is particularly true in many DevOps environments where speed and agility are highly valued and security concerns are often secondary.
Over time, the gap between the permissions that users have and the permissions that they actually need (and use) becomes a significant crack in the organization’s security posture. Promiscuous permissions leave workloads vulnerable to data theft and resource exploitation should any of the users who have access permissions to them become compromised. As a result, misconfiguration of access permissions (that is, giving permissions to too many people and/or granting permissions that are overly generous)
becomes the most urgent security threat that organizations need to address in public cloud environments.
[You may also like: Considerations for Load Balancers When Migrating Applications to the Cloud]
The Glaring Issue of Misconfiguration
Public cloud providers offer identity access management tools for enterprises to control access to applications, services and databases based on permission policies. It is the responsibility of enterprises to deploy security policies that determine what entities are allowed to connect with other entities or resources in the network. These policies are usually a set of static definitions and rules that control what entities are valid to, for example, run an API or access data.
One of the biggest threats to the public cloud is misconfiguration. If permission policies are not managed properly by an enterprise will the tools offered by the public cloud provider, excessive permissions will expand the attack surface, thereby enabling hackers to exploit one entry to gain access to the entire network.
Moreover, common misconfiguration scenarios result from a DevOps engineer who uses predefined permission templates, called managed permission policies, in which the granted standardized policy may contain wider permissions than needed. The result is excessive permissions that are never used. Misconfigurations can cause accidental exposure of data, services or machines to the internet, as well as leave doors wide open for attackers.
[You may also like: The Hybrid Cloud Habit You Need to Break]
For example, an attacker can steal data by using the security credentials of a DevOps engineer gathered in a phishing attack. The attacker leverages the privileged role to take a snapshot of elastic block storage (EBS) to steal data, then shares the EBS snapshot and data on an account in another public network without installing anything. The attacker is able to leverage a role with excessive permissions to create a new machine at the beginning of the attack and then infiltrate deeper into the network to share
AMI and RDS snapshots (Amazon Machine Images and Relational Database Service, respectively), and then unshare resources.
Year over year in Radware’s global industry survey, the most frequently mentioned security challenges encountered with migrating applications to the cloud are governance issues followed by skill shortage and complexity of managing security policies. All contribute to the high rate of excessive permissions.
