Security data on the cloud is not the same as an on-premises effort and the faster a company recognizes these challenges, the safer is their data
By Jonathan Maresky
Cloud network security may not sound very different from traditional network security – and it’s not, at least in some respects. Cloud networks use the same fundamental paradigms and protocols as on-prem networks, so there is some overlap between cloud network security and conventional network security. According to industry analysts, firewalls are as foundational in the cloud as they are on-premises, for instance, as Gartner notes, “network firewalls remain key network security controls”.
But if you think the traditional network security solutions and processes that you have in place can protect your cloud networks, think again. Despite some similarities between cloud networks and on-prem networks, there are also crucial differences. If you deploy cloud-native apps, for instance, you’re likely to encounter complex internal networks and additional network management components – like service meshes and ingress controllers – that you wouldn’t encounter in most on-prem environments.
This means that you can’t simply “lift and shift” a conventional network security strategy to protect cloud networks. As this blog explains, cloud network security requires additional capabilities, tools and strategies that you may not have in place if your workloads traditionally ran on-prem.
Cloud network security vs. cloud security
To understand cloud network security, you must first understand cloud security in general. Today, a popular model for thinking through the meaning of cloud security is Gartner’s concept of the Cloud Native Application Protection Platform, or CNAPP. CNAPPs are designed to secure cloud-native applications – meaning those that run in cloud-based environments – protecting all layers of the hosting stack and all stages of the software delivery lifecycle.
Because cloud-native apps often include complex networking architectures, CNAPPs must protect multiple facets of network functionality – ranging from next-generation firewalls and load balancers to Web apps and APIs. They must also provide granular segmentation and secure both North-South and East-West traffic.
Given that every cloud deployment connects to a network outside the cloud, and uses networking to transfer data between different assets inside the cloud, a secure network is the foundation for the rest of your cloud security strategy.
Single-cloud, hybrid cloud and multi-cloud network security
That’s true, by the way, regardless of which type of cloud architecture you use. You might use a single cloud, or you might be among the 90 percent of organizations that use multiple clouds. You might also operate a hybrid cloud environment that combines private clouds or on-prem resources with public cloud-based services.
Regardless of your cloud architecture, all types of cloud environments – single-cloud, multi-cloud and hybrid cloud – depend on the network to tie infrastructure and workloads together, so they are all subject to severe risks when cloud network security is compromised. This makes it critical to deploy a network security solution that can support all of your cloud resources in a consistent and efficient way, no matter which type of cloud hosts them.
Cloud network security and shared responsibility
Note, too, that shared responsibility models don’t absolve businesses of the need to secure cloud networks. Shared responsibility models are agreements that cloud providers make with their customers, wherein the cloud provider is responsible for securing some components of the cloud environment and its customers are responsible for others.
From the perspective of network security, shared responsibility models require cloud providers to secure the physical network infrastructure, like switches and routers, that provide connectivity to their cloud infrastructures. But the task of securing any virtual networks that customers configure and the traffic that enters and exits the cloud environment by traversing those virtual networks falls to the customers.
To put it bluntly, your cloud provider isn’t going to save you if you accidentally leave vulnerable cloud-based VMs unpatched – but a good Intrusion Prevention System would mitigate this risk. It’s on you to manage cloud network security risks like these by adopting the right set of tools and solutions – whether they are cloud vendors’ own security tools, self-built DIY solutions or products from cybersecurity vendors – to secure your cloud.
Cloud network security challenges
In some ways, cloud network security resembles conventional network security. It involves ensuring that access to cloud assets is restricted using firewalls, that vulnerable ports are left closed, that suspicious network traffic can be identified and blocked and so on. But in other respects, cloud network security presents some unique challenges, including:
- Cloud network complexity: Cloud networks tend to be more complex than on-prem networks. They may include a wide range of subnets, virtual private clouds (for example, Amazon VPC), overlay networks and possibly even interconnects between multiple clouds. Identifying and remediating security risks is harder given this complexity.
- Less visibility: In the cloud, businesses can’t directly access physical network infrastructure, which means they have less visibility into what’s happening on their networks.
- Dynamic nature of cloud assets: On-prem assets are typically more permanent and static while cloud assets are more dynamic. In the cloud, IP addresses could change rapidly, for example, and assets could spin up or down quickly. The dynamic nature of the cloud can make it more challenging to prevent security risks.
- No clean network perimeter: You can use a firewall to segment your entire on-prem network from the Internet if you want, but you can’t disconnect your cloud in this way. This means that cloud networks have blurrier perimeters. You can use cloud vendor solutions to create some isolation between cloud-based assets and the Internet, but at the end of the day, these assets may still be exposed to network-level threats.
Managing cloud network security
For these reasons, cloud network security requires a different approach from traditional security. You can’t simply lift-and-shift your on-prem network security tools and processes into the cloud. Instead, you should deploy security solutions purpose-built for the cloud. Effective cloud network security rests on the “three Cs”:
- Comprehensive: You must be able to prevent threats across any public or private cloud network, as well as any other component of your IT estate, using a single solution.
- Consolidated: Your security tooling should be consolidated, enabling unified management and security operations.
- Collaborative: Shared threat intelligence and integrations with external tools enable teams to work collaboratively when identifying and preventing cloud network security risks.
When your cloud network security strategy delivers on each of the Cs, you are in a position to prevent cloud network security risks as efficiently and effectively as possible. Beyond deploying the right security tools, following best practices like these can further strengthen cloud network security:
- Zero Trust: This security model includes not allowing resources that join a cloud network to interact with other resources until they are vetted and determined to be secure.
- Least privilege: By restricting cloud entities to the least privileges necessary, you can reduce the risk and scope of security breaches due to insecure permissions settings. The least privilege methodology also brings context to network security by helping admins establish which role each user is supposed to have.
- Segmentation: Segmentation means restricting communication between virtual networks within the cloud, which reduces the risk of breaches spreading between networks.
(About the author: The author works as Cloud Security Product Marketing Manager with Check Point Software Technologies and the views expressed herein are his own and does not necessarily reflect those of the publication.)