In 2005, Gary McGraw and Brian Chess published a taxonomy of code vulnerabilities exploited by attackers.  Today, the “Seven Pernicious Kingdoms” continue to be used by MITRE to classify vulnerabilities. With the onset of cloud computing, it is time to begin a new taxonomy that accounts for attacks on cloud infrastructure.

Large data centers and cloud environments have opened new attack vectors. As organizations adopt cloud computing and virtualization technologies, hackers are taking full advantage of the data exfiltration and computer hijacking opportunities provided by the dissolving security perimeter. The increasing rate of security incidents shows the urgency of identifying and protecting against these evolving cloud computing threats. In fact, one well known IR firm indicated that 15% of their investigations now center on cloud attacks.

As organizations adopt cloud computing, the perimeter moves into unprotected territory within these new environments. To protect against cyberattacks, most companies have heavily invested in traditional multi-layer, security appliances—like firewalls and intrusion prevention systems (IPS)—that provide in-depth “north-south” perimeter protection. But, these controls are less effective in securing lateral or “east-west” traffic because they cannot move into public cloud environments and they were not designed to handle the sheer volume of cloud traffic or forwarding the right traffic to them represents an operational hurdle.

When enterprises lack lateral defenses, the attacker has the advantage once inside the perimeter. If an attacker finds a way into a public Amazon AWS or Microsoft Azure environment, he or she can then pivot into an on-premise data center. The seriousness of this problem is highlighted by an increasing number news headlines reporting massive data leaks, like the Equifax breach, or theft of computer resources, as was the case with the recent Tesla cryptocurrency mining attack.

In the last few years, attackers have become increasing skilled in using automation techniques to accomplish their goals. Network worms, like Petya and NotPetya, are perfect examples of how attacks can quickly spread laterally within networks using automation.

The opportunity for attackers is growing because most security practices still follow physical data center layouts, instead of aligning with the virtualized, overlay model of how today’s environments are utilized. When trying to use traditional security tools in virtualized environments, the following are top three issues leading to gaps in protection:

  • Problems operationalizing security controls (setup, scale, maintain)
  • Issues with coordinating multiple products for each environment
  • Aligning security controls with changes in environments

6 CATEGORIES OF CLOUD SECURITY THREATS

Our SX Threat Intelligence Team has been very busy studying the different forms of attacks enabled by cloud adoption. They have identified five distinct categories of attacks that they believe are most likely to give cloud-enabled organizations trouble in 2018. If your organization is considering a move to a virtualized or public cloud environment (or if you have already made the move), then you should be prepared to proactively defend against the following categories of cloud attacks.

#1: Cross-Cloud (a.k.a., X-Cloud)

Many enterprises are under the impression that they can go easy on security if they don’t host ‘critical workload’ or ‘sensitive data’ resources in the cloud, but they couldn’t be more wrong. Attackers commonly use public clouds to gain entry into on-premise data centers.

Once your organization makes the decision to migrate any workloads into the public cloud, the perimeter of your on-premise data center also extends into that public cloud environment.

So the appropriate defenses are needed but, the security controls used to protect your on-premise data center cannot easily extend into your public cloud environment.

This forces many organizations to adopt a fragmented security posture that is complex to maintain and leaves the door open for attackers. Public cloud workloads can become infected with malware. As the malware replicates and spreads, the attack can easily jump from the public to the private cloud using standard protocols—if there are no lateral defenses in place.

#2: Cross-Data Center (a.k.a., X-Data Center)

Once attackers are inside the data center, there is often no boundary to stop them from gaining access to sensitive data and computing resources.

Points of delivery, or PoDs, are modules of machines that work together to deliver services and help maximize the modularity, scalability and manageability of data centers. For cost, scaling and redundancy reasons, it is a common practice to interconnect PoDs across multiple geographic locations. As data centers expand they grow by adding more PoDs.

To secure the connection between various PoDs, enterprises should send all the traffic through a multi-layered perimeter defense system, but this usually doesn’t happen because of the typical issues leading to gaps mentioned before.

Instead security is commonly relaxed, as PoDs are considered trusted zones. This allows different services, such as backups or synchronization of data, to communicate between data center locations without using any intrusive security controls. But the unsecured connection between PoDs opens another potential attack vector. If any component of the PoD is compromised, attacks, including network worms, can spread laterally from one data center to another until the attacker accomplishes his or her goal.

#3: Cross-Tenant (a.k.a., X-Tenant)

Today, in typical public cloud environments anyone can add new virtual private resources within minutes with a simple swipe a credit card. New tenants can then immediately start sending traffic to existing resources—meaning network traffic can be generated between tenants of a cloud. This leaves a security gap that hackers are using to their maximum advantage.

Because multiple tenants share the same cloud, data center, rack or even physical host, the traditional perimeter is dissolved as it moves to where the tenant resources are located. In the most extreme form, no physical network traffic is generated, and two workloads are exchanging traffic over a virtual network.

Especially the volume of traffic, as well as the frequent on boarding of new tenants, present unique security challenges that traditional security solutions were not designed to address.

Even though traffic should pass through multi-layered defenses, it often doesn’t because the implementation of security is left to the tenant itself.

To secure the tenant, it takes a significant amount of time, effort and expertise. Traffic must be redirected and controls put in place—a goal that can be difficult to achieve due to the complexity and scale of modern data centers and cloud environments. This leaves the data center or cloud open to attacks that spread from one tenant to the next.

#4: Cross-Workload (a.k.a., X-Workload)

Typically, there is nothing to stop a workload from communicating with other workloads in the same tenant or virtual network, so your own virtual desktop can spread an attack to your virtual web server, data base or file server.

A workload consists of data, as well as the configuration of the application, computing hardware resources, services that support the application and network connectivity. Once a single workload has been breached, malware can spread from one workload to another within your own virtual private data center.

It is a common scenario for enterprises to use untrusted VMs for browsing and downloading content from the internet. If any VM get infected, one can restore the machine to a previous state which is known to be free of malware. But running on the same tenant, they may also have other workloads that contain sensitive data or ones that have access to.

To reduce the risk of a breach, workloads with different security requirements should be in different zones and traffic traversing those zones should be inspected using a rich set of security controls like what is expected for north-south perimeter defenses. But, it is even harder to put security controls between workloads than any of the three instances above.

#5: Orchestration Attack

As cloud orchestration becomes available via APIs, many developers are adopting these new technologies without fully understanding what they mean for API security. This can leave an open door that allows hackers to target the cloud API layer and then grant themselves privileges to steal sensitive data or resources.

Cloud orchestration is used to provision, deploy or start servers; acquire and assign storage capacity; manage networking; create VMs; manage identities and privileges; and gain access to specific software on cloud services and much more. The goal of an orchestration attack is to steal accounts or private cryptography keys that can then be used to grant privileges to cloud resources. For instance, an attacker may use a stolen account to spin up new VMs, access cloud storage or create new tenants or accounts.

The success of this attack depends on the access privileges of the stolen account, but once an orchestration account is successfully breached, attackers may also attempt to create a backup account for themselves and then use that account to access other resources.

This type of attack cannot be detected with standard network traffic inspection tools, because the attack is aimed at the cloud API layer. An effective solution must examine both network based behavior and account behaviors.

The cryptocurrency mining attack against Tesla is a recent example of an orchestration attack. In this case, attackers were spinning up new workloads that they then used for bitcoin mining.

#6: Severless Attack

Serverless architectures or Function as-a-Service (FaaS) is a relatively new type of service offered in the cloud that enables customers to save money by opting not to deploy servers, maintain and scale based on demand.  The inherent scalability, protection of OS and web servers has made this proven popular architecture.

This new architecture makes is challenging to have n/s security controls, giving ability for attackers to take advantage of the FaaS.  Typically, a FaaS service has a temp file system that is writable, an attacker could persist attacks tools in the temp file system.  The FaaS function could have access to corporate database containing sensitive, it would be possible for an attacker to leak sensitive data and exfiltrate data out using the tools.

A FaaS function with incorrect privilege could help an attacker to spin up new VMs, access cloud storage or create new tenants or accounts.

This type of attack cannot be detected with standard network traffic inspection tools, because the attack is aimed at the FaaS. An effective solution must examine both network based behavior and account behaviors.

 

SOLVING THE CLOUD INSECURITY EPIDEMIC TOGETHER

Moving forward, we expect cloud attacks to accelerate and grow in sophistication. While there is no silver bullet solution that will address every cloud security risk, industry collaboration and intelligent cyber security will enable better defenses and in turn greater business value from cloud innovations.

To this end, we are building a compendium of cloud security threats that we hope will be enriched through industry collaboration. Our goal is to create a taxonomy that can not only be used to classify cloud security vulnerabilities, but also offer a standard way to evaluate the effectiveness of cloud security tools and provide a baseline for threat identification, mitigation and prevention efforts.

Leveraging diverse inputs from academia, government, security practitioners and other commercial vendors, we hope to provide the breadth of structure and depth of knowledge needed to serve as a unified standard of cloud threat vectors. If you would like to join in the conversation, feel free to comment—agree, disagree, or weigh in with a new cloud attack category below.

Tags: , , ,