Securing Multi-Cloud - VMware Industry Guide
Introduction to Multi Cloud
VMware defines multi-cloud as a model of cloud computing where an organization utilizes a combination of clouds, which can be two or more public clouds, private clouds, or a combination of both public and private clouds. A multi-cloud strategy not only provides more flexibility for which cloud services an enterprise chooses to use, but it also reduces dependence on a single cloud hosting provider. There are several reasons businesses move to a multi-cloud posture. They may want to transform their customer experience, scale the business and innovation, or even drive employee productivity.
Workloads are part of the multi-cloud environment and Cloud Workload Protection (CWP) plays a crucial role in securing the multi-cloud. Today’s modern workloads have changed from monolithic applications to a distributed system that serves a single purpose and can be ephemeral. They can run on physical servers, VMs (Virtual Machines), or containers on-prem or off-prem. On-prem workloads can be long-lasting in physical servers or ephemeral in containers, whereas public cloud workloads could contain a legacy app that was brought onto a cloud virtual instance or could have ephemeral workloads like containers and serverless functions.
The reality today is that enterprise architectures are highly distributed. Most enterprises are purposefully using more than one public cloud infrastructure as a service (IaaS) platform, but still have on-prem workloads to protect. According to surveys by top Analyst firms, most enterprises will have workloads distributed across a combination of on-prem, colocation, and multiple public cloud IaaS platforms – or multi-cloud architecture. According to the VMware F22 H2 Benchmark: Digital Momentum Report, 73% of enterprise technology decision-makers are standardizing on multi-cloud. The worldwide public cloud market is forecasted to reach $482B in 2022.
Multi-cloud is worth getting right Companies that have embraced multi-cloud report significant benefits.1
Why Multi-Cloud Success is not guaranteed: Obstacles stand in the way of long-term success
Many companies have successfully employed a multi-cloud strategy to become more agile and improve operational efficiency. But with opportunities come challenges. Nearly one in four executives1 have concerns about the use of multiple clouds, including:
There are more control points and potential risks when it comes to protecting server workloads. Server workloads have a much better chance of being protected when they are hardened and configured correctly, their attack surface has decreased in size, and vulnerabilities are identified and then patched. According to the 2020 Gartner Market Guide for CWPP, these security requirements were foundational in protecting workloads (See figure below).
With this move to the multi-cloud era organizations are having exponential growth in control points they must have visibility and management over. Attackers are just looking for a door that is cracked open “enough” to get into an organization’s network & silently hide until they execute the next part of their attack. Attacks are becoming more than a single extortion of organization data but attacks that involve an organization’s constituents for double or triple extortion. This form of island hopping by attackers is growing in the multi-cloud era and certain sectors are being impacted by this. See image below from “The Modern Bank Heist 5.0 Report” by VMware.
The rapidly expanding attack surface presents vulnerabilities if left undetected. With dozens and even hundreds of security tools in use by most organizations and the number of threats expanding daily, there are plenty of gaps to exploit. According to the 2019 Forbes Cybersecurity Trailblazers Report, 77% of security practitioners indicated that they have too many point products to track and manage. Complexity leads to overspending, and for IT, it’s also a huge administrative burden to ensure every workload has the proper security agents installed—and all are up to date. Security experts become reluctant systems integrators, constantly writing scripts to stitch all the different security products together. Meanwhile, everyone is frustrated by the difficulty in communicating between teams. Security system complexity is the most expensive of 25 cost factors, increasing the average cost of a breach by $292,000 for an adjusted average total cost of $4.15m. (VMware Leverage Your Infrastructure as Your Security Control Datasheet, IBM Cost of a Data Breach Report 2020)
Although 98% of CISOs say they already use or plan to shift to a cloud-first security strategy, vulnerabilities still persist5. Cloud jacking is on the rise, which makes cloud security a top priority for many. Following the rush to cloud technology amid the pandemic, cybercriminals have continued to exploit cloud environments to deliver integrity and destructive attacks. In a 2021 survey conducted by VMware, 43% of respondents said more than one-third of attacks were targeted at cloud workloads. Increasingly, attackers are using the cloud to island hop along the victim’s supply chain: 49% of all attacks targeted the victim via island hopping6.
In a world of increasingly sophisticated attacks, bad actors see the opportunity created by these realities. They leverage legitimate software (PowerShell) to capitalize on misconfigurations and vulnerabilities to breach your infrastructure. In fact, according to the National Vulnerability Database, the number of Common Vulnerabilities and Exploits (CVEs) observed in devices, networks and applications has tripled from 2016 through 2019. And servers have become the leader among assets involved in breaches. Attackers move laterally, compromising multiple servers to exfiltrate sensitive data7.
Rapidly Changing Landscape
The multi-cloud environment is constantly changing, and organizations are moving to a multi-cloud model at a rapid pace. Through combining multiple environments can lead to more production and innovation, it can also create many surfaces to defend and can be difficult to inventory. Security teams are tasked with protecting legacy, virtualized, and containerized apps across both private and public clouds. The resources themselves are also ephemeral, from APIs to automation, and dynamic services. Each cloud model has different advantages and can help an organization achieve various goals. In fact, over 70% of organizations today are using 2 or more public clouds8. With so many moving parts, a major executive goal is to improve consistency across public cloud environments, but they struggle to have a common set of controls over said clouds with inconsistent infrastructures and unplanned costs.
Workloads are increasingly becoming distributed as our environments continue to get broader and more complex. Many cloud-based applications are business-critical but vulnerable to compromise if any part of the workload (app, data or OS) malfunctions. Of course, the solution is not to shut down a corporate server when an incident occurs. Security and IT operations are secondary to business productivity. This means that securing and monitoring each part of the workload is now an additional—and critical— part of securing your business.
Division of Organizational Ownership
When adopting a multi-cloud model, organizations are having trouble identifying who owns what, and are realizing how complex a multi-cloud environment is. Many teams today are still structured in siloes. IT and Security each have their own tools and areas that they cover, which means they may not have the knowledge or visibility into what is happening in another area.
Complexities create compromise: the problem with “OR”
When addressing this growing complexity, many organizations have to make decisions that result in trade-offs among developer autonomy, spending, security, employee access to apps, and other factors. Conventional wisdom states that compromise is unavoidable when making business and technical decisions. Yet “either/or” propositions mean you never get full value from your multi-cloud investments
Security Threat Landscape
Vulnerability scans have historically been a monthly or quarterly activity. But these point-in-time exercises are not enough. With the continuous expansion of workloads across multi-cloud environments, these scans aren’t providing information that is as broad or as timely as it needs to be to mitigate critical security risks. With shared visibility and risk prioritization, the next step for both security and IT teams is to make workload security a regular part of IT hygiene.
IT admins can efficiently secure workloads. However, they are blind to most workload vulnerabilities and certainly don’t have the context to prioritize impact. And because IT admins often don’t have control over the cloud environment, the roles and responsibilities become clear as mud. Security teams may have some of the information needed to identify vulnerabilities but may not have clear risk prioritization or context to manage remediation effectively. In other words, workload security is likely not being sufficiently managed by anyone.
An important aspect of an adversary’s activity is how they compromise systems to gain control. This control allows them to persist within the environment, establishing a staging server they can use to pivot and target additional systems. Once an adversary has gained initial access to an environment, they enter the most difficult portion of the attack. They will need to find a way to leverage this limited access to gain a stronger foothold while attempting to map out and find resources to accomplish their goal. Attackers look to install an implant on a compromised system that gives them partial control of the machine.
An implant, also known as a beacon, is what is generally regarded as the malware component of an attack. Its goal is to simply make regular network connections out to the command-and-control (C2) server to obtain new commands to execute and pass along the results. In the context of an attack, what is an implant? Malware, webshells, remote access Trojans, and even known good RATs can all be implants that install themselves on a compromised system to allow for remote access. An implant is deployed in a persistent manner to allow an adversary to keep control of that infected system. This is typically done in two ways: passive and active. A passive implant awaits an external connection, such as a webshell on a compromised server. Conversely, an active implant will continually try to send beacon messages to a preset C2 server and await further instructions.
Analysis of RATs in the wild shows that most act as active implants that will communicate with known C2 servers to gather further instructions. Very few RATs make use of passive implants that rely on a service to listen for commands. While such malware could create its own listener, often they install a component into an existing service, such as a web server, to piggyback on existing network connectivity. However, the adversary would need to perform additional research on the infected system and face the risk of insufficient account privileges to install. Because a passive implant has no guarantee that the system will allow incoming connections, and the active implant is a preferred tactic for malware.
From a malware analysis perspective, what is interesting is determining the number of implants that interact via well-known HTTP protocols, and those that create their own specialized protocols. An implant’s purpose is far-reaching, depending on its author. Many are used for very simplistic purposes, such as to show files on the system, download new files, upload existing files, or execute commands. Others allow for more advanced tactics, such as mapping out the local network and pivoting from the infected system into new systems on the network. Overall, depending on the adversary and their ability, an implant can contain a great amount of functionality, as documented in Figure 12.
The top threat to cloud computing is data breaches, and a majority of those cloud breaches are a result of misconfiguration mistakes. It can be hard to scale smart security practices across large organizations, with too many teams working in different ways. In addition to data exposure and breaches, misconfigurations can lead to brute-force attempts and exploits. Because it can be hard to scale, many organizations have to rely on their cloud service provider to configure and secure their cloud deployments. This in turn can make it easy for misconfiguration or security oversight to leave a company’s cloud-based resources exposed to attackers. One way to remediate this and for all teams to gain control of their environments is through the Shared Responsibility Model. The consumer is responsible for the security “in” the cloud. That covers the application and data, hosts and traffic, user activities, and resource configurations. The cloud provider, on the other hand, is responsible for the security “of” the cloud. The data center, hardware, virtualization software, and foundational services.
- When workloads lived in static rack servers in on-premises data centers, it was easy to assign responsibility for keeping them secure. Today, workloads can exist on physical servers, virtual servers, in the public cloud, or even serverless. And workloads can move across all these environments, which makes them difficult to track and manage.
- Workload security is not sufficiently managed by any one group in an organization, it takes multiple teams to work collaboratively.
- IT admins can secure workloads, but they are blind to most workload vulnerabilities and don’t have the context to prioritize the impact
- Security teams may have some of the information needed to identify vulnerabilities but may not have clear risk prioritization or context to manage remediation efficiently
- Attackers strike at any point of misconfiguration or vulnerability. They leverage seemingly benign software to capitalize on misconfigurations and vulnerabilities to breach your infrastructure. In fact, according to the National Vulnerability Database, the number of Common Vulnerabilities and Exploits (CVEs) observed in devices, networks, and applications has tripled from 2016 through 2019. 8 VMware | Published Oct 2021
Developing a Security Strategy
Migration to the cloud – and cloud jacking – shows no sign of slowing down, which must result in security that extends across workloads, containers, and Kubernetes environments. Developing a security strategy means improving corporate governance, enhancing security, and reducing risk. VMware put together the following key constructs that will enable both security and IT teams to proactively reduce the attack surface and harden assets. Adopting these constructs would bridge the gap between these teams, simplify operations, and share the obligations of workload security.
- Minimize agent overhead - Eliminating the need to install agents onto workloads reduces security agent sprawl, minimizes installation, and reboots, and reduces operations overhead. This simplifies the delivery of security as a service for IT.
- Share visibility into vulnerabilities - A unified view of security data ensures clear communication and understanding as to the vulnerabilities detected.
- Automate risk prioritization - To minimize alert fatigue and overworked resources, both teams need to know what to focus on to make the biggest impact on defenses. Having a context-centric system that can automatically prioritize vulnerabilities without bias is critical.
- Streamline workload processes - With shared visibility and risk prioritization, security and IT teams enjoy frictionless experiences through automation and operationalizing consistent security as part of IT hygiene.
Questions to Ask
As you begin to develop your multi-cloud strategy, you need to consider what your needs are, and which vendor aligns with the best. Use the following questions to help you understand what would serve your environment best:
Should container protection be a requirement in our overall strategy?
How can we extend workload scanning proactively into the CI/CD pipeline?
What gaps currently exist in our data collection and visibility that are preventing the prioritization of vulnerabilities and hardening of workloads?
Should my environment be based on a homogenous cloud or a heterogeneous cloud?
Homogenous – several different clouds all from the same vendor
Heterogenous – multiple clouds from multiple vendors
How will moving to a multi-cloud structure affect my business?
What compliance or government regulations must my company be meeting?
What level of automation is needed?
Do I have the right teams in place?
Which areas of the business/environment do we anticipate significant scaling up or down?
What budget can we allocate to increase our security measures?
Don't just throw money at the problem
Do we have enough employees that will understand the different structures we aim to implement?
- Can it consolidate telemetry data across clouds, workloads, networks, and endpoints?
- Does it support every application regardless of OS, configuration, and cloud, or is it reliant on any of the above?
- Can it recognize what constitutes normal behavior within a workload or across workloads?
- What behavioral models does it deploy to detect malware and non-malware (fileless) attacks within workloads and between workloads?
- How many agents are required to install on each workload, container, and OS?
- Can IT Ops, DevOps, and SecOps leverage the same dataset when monitoring and responding to incidents?
- Which governance frameworks does your platform support (e.g., NIST 800-53)?
- How would a typical workflow operate among IT Ops, DevOps and SecOps once a threat, vulnerability or misconfiguration has been identified?
- What is the average CPU consumption per cloud workload protection agent?
- Can it consolidate multiple security capabilities, such as EDR, NGAV, and vulnerability assessment, into a single agent and management console?
- Can the cloud workload protection platform enforce and report on a standardized consistent security policy across private, public, and hybrid cloud environments?
- How does it conduct regular vulnerability scanning without impacting availability and performance?
Summary and Additional Resources
Aligning IT, to workload security, reduces attacks
Security teams and IT admins can work together to improve workload security. And with the right security capabilities, this collaboration can be pain-free and easily operationalized into daily practice. To capitalize on this opportunity, ensure these teams:
Are using a built-in solution with a single agent
Have a unified view of security data embedded in their current work tools
Have the necessary context and continuous monitoring for vulnerabilities with automated risk prioritization
Have leadership support to ensure the operationalization of workload hardening
Three keys to improving workload security
Bring IT admin and security leads together to discuss the opportunity to work together to reduce attacks.
Identify current gaps in data collection and visibility to be able to better prioritize vulnerabilities and harden workloads.
Explore solutions that will get IT admins and security teams the shared visibility and context needed to be successful.
Addressing workload security yields major dividends
Coverage and visibility across all workloads
Simplification of the IT security stack
The ability to respond more quickly to issues with early detection
Better hardened assets
Better prevention of malware and non-desired software and processes
Complete elimination of non-malware
Activation of security for the future—modern environments and workloads
- Secure the Multi-Cloud: https://www.vmware.com/solutions/multi-cloud-security.html
- Global Security Insights Report
- Global Incident Response Threat Report
- 2021 Data Breach Investigations Report
- Conquer Cloud Complexity and Drive Digital Business
- VMware Tech Zone : https://carbonblack.vmware.com/securing-multi-cloud
Description of Changes
Guide was published.