Improving Security in the Cloud with Micro-Segmentation
By Sharon Besser, VP of Business Development at Guardicore
What is a cloud shared responsibility security model and why is it important? Why do you need to use micro-segmentation in the cloud? After all, cloud providers go to great lengths to ensure they offer a secure platform for customers to develop and host their applications.
At Guardicore, an AWS Advanced Technology Partner with the AWS Security Competency, we see the shift to public cloud challenges the status quo in many areas—IT deployments, technology landscapes, jobs, and how organizations balance opex and capex in their budget.
It also challenges the status quo in application security; many decisions on controls implementation now reside with developers who are outside the regular security function’s management.
With this in mind, cloud service providers (CSPs) like Amazon Web Services (AWS) have implemented built-in security controls. These are meant to ease cloud adoption and improve the way organizations can apply security quickly and at scale.
However, some questions still remain, namely:
- What is a shared responsibility security model, and why are organizations required to manage the overall security of their systems, even when using the cloud as an infrastructure?
- What tools do companies use today to help support a shared responsibility security model?
- How do you implement micro-segmentation in a shared responsibility security environment and how will it benefit you?
Let’s address these questions one by one.
What is a Shared Responsibility Security Model?
In general, cloud service providers like AWS can only do so much to protect their customer cloud assets. Why? Because those assets do not belong to them.
A recent survey shows 60 percent of security and IT professionals believe security is the leading challenge in cloud migration. At the same time, they are not clear about who’s responsible for securing cloud environments. That’s why it’s important to understand the details of how the shared responsibility security model works.
A shared responsibility security model is a framework that CSPs use to help explain a customer’s obligations when using the CSP’s services. It ensures user accountability and helps both parties work together for full security coverage.
At a very high level, the main separator between responsibilities is the environment. In other words, you need to draw a line between the cloud infrastructure itself and what is hosted on that infrastructure, such as a customer’s virtual private cloud (VPC). Sometimes that’s referred to as “what’s in the cloud.”
AWS is responsible for securing the cloud—all software, hardware, and related infrastructure used to deliver its core platform services. This includes elements such as physical data centers, hypervisors, switches, routers, and storage.
As an AWS customer, you are responsible for securing what happens in your portion of the AWS Cloud or your VPC. This can be your specific service and resource usage, including customer data, operating systems, applications, firewalls, authentication, and access management.
Figure 1 – AWS shared responsibility security model.
Some important elements of security are managed by the internal AWS security team, while the customer-specific elements like data, configuration, access, and permissions, are managed by the customer’s own teams.
A detailed example about the shared responsibility security model is included in this Guardicore ebook.
Figure 2 – Details about the AWS shared responsibility security model.
What Tools Can Support a Shared Responsibility Security Model?
It’s important to understand that if you don’t implement the security measures your business requires, you may be left with a general-purpose security posture that does not suit your needs.
In recent years, service providers—mostly AWS—added integrated tools and services you can use to address your own areas of ownership under the AWS Shared Responsibility Model. In other words, AWS has secured its part of the cloud, but also offers solutions you can use to secure your part of the cloud.
Many of these features complement the capabilities of commercial solutions like network firewalls, Security Information and Event Management (SIEM) software, web application firewalls, and other basic security products. In other areas of security, more advanced technologies and capabilities are required.
Basic controls might be suitable for some organizations depending on their risk tolerance, but not for everyone.
Alex Amorim from Cogna Educação in Brazil, the largest private educational company in the world and a Guardicore customer, said:
“I can’t trust anything nowadays. I can’t trust my device, which is capable of stealing what is inside my network; I can’t trust a third-party, who comes with a notebook and connects it to my network; I can’t trust the notebook that an employee takes home; and so on. The context is Zero Trust.”
Cogna’s security team is responsible for data access, segmentation, access control, and data protection. For its part, AWS provides the basic functionality that protects the infrastructure on which Cogna’s critical assets are installed.
How Do You Implement Micro-Segmentation?
Micro-segmentation is a security best practice that offers a number of advantages over network segmentation and application segmentation.
Network segmentation splits a computer network into subnetworks, or network segments. This reduces the attack surface so that if a host on one network is compromised, the hosts on the other network segments are not.
Application segmentation performs a similar function to limit the ability of attackers to damage other segments of an application when they gain access to one segment.
The added granularity that micro-segmentation offers is essential for cloud migration, and when new deployment options like containers make traditional perimeter security less relevant.
Micro-segmentation policies can take many forms, including controls based on environment type, regulatory scope, application, and infrastructure tier.
Micro-segmentation also makes it possible to apply the principle of “least privilege” more extensively across data center and cloud environments. This provides a more effective defense posture than traditional network-layer controls alone.
AWS provides segmentation capabilities using built-in security groups. The key for successful implementation of micro-segmentation is to understand and address the specific micro-segmentation challenges that are related to the AWS environment.
Let’s take a look at how to use micro-segmentation to address two specific areas:
- Asset, application discovery, and visualizing the environment.
- Enforcing micro-segmentation controls on different applications within the same environment.
Asset, Application Discovery, and Visualizing the Environment
AWS provides basic visualization capabilities with VPC flow logs and third-party or open source tools, but it’s labor-intensive to implement and maintain. It also provides limited granularity and customization. Moreover, there is no linkage to policy creation.
Guardicore’s micro-segmentation solution picks up where AWS leaves off by providing rich, out-of-the-box visibility and telemetry in an easy-to-deploy platform. You can also use VPC flow logs as an additional data source.
Guardicore offers application-level detail with customizable views based on AWS, custom, or dynamic labels. Labels, as the name suggests, are virtually attached to any object and provide information about it. Guardicore’s method uses labels to describe infrastructure, applications, and process in business-logic terms.
Using labels makes your work easier and more efficient and enable you to group assets that share common attributes. This simplifies the process of creating and managing micro-segmentation policies.
For example, you can categorize assets by role, application, location, business need, environment, or anything else that’s relevant for your policy definitions. Even when you have many assets of the same type, you can quickly identify a specific asset based on the labels you’ve assigned to it.
With labels, you can move from visualization to policy definition in a few clicks.
Enforcing Micro-Segmentation Controls on Different Applications within the Same Environment
There are several ways to enforce micro-segmentation controls on different applications within the same environment. For example, it’s possible to use the built-in network segmentation capabilities of AWS security groups and add application-level control with AWS WAF.
If you do, however, you have to take a few things into account:
- Expressing policies in multiple tools breaks down at scale. It’s also problematic when you have multiple VPCs and use a hybrid approach.
- The lack of visualization makes it difficult to align policies with specific security goals.
- There are limitations due to sizing. For instance, there are limits on the number of security groups per VPC. These limits may create management challenges and would restrict support for use cases more advanced than, say, “Separate 50 servers in VPC1 from the other 50 servers in VPC2.”
To address these challenges, Guardicore provides a single tool to create both network- and application-level policies. It offers a streamlined experience from visualization to policy definition, shortening policy creation time and maintenance overhead.
The Guardicore approach with comprehensive visibility makes it easier to understand the effect of suggested policies. It also provides greater policy flexibility, including support for compound policies and both allowlist and denylist policies.
Furthermore, Guardicore does not have built-in limits due to the type and number of interfaces or number of policies per VPC.
There are additional micro-segmentation requirements that are important for businesses who are migrating only some of their applications to the cloud, or are in the process of a long migration. Managing a hybrid cloud requires additional security capabilities to maintain visibility, visualization, and security policy consistency across hybrid- and multi-cloud.
Guardicore provides a unified view of hybrid- and multi-cloud architectures, with consistent security posture management across on-premises and cloud environments.
The solution also provides support for a wide range of operating systems and deployment models, including legacy, bare metal, all major hypervisors, containerized services, and cloud instances.
Micro-segmentation is a building-block of the shared responsibility security model and makes your security measures more effective. Understanding of the shared responsibility security model is imperative for successful, secure cloud and digital transformation projects, as well as the future growth of public cloud infrastructure.
Security of virtual machines and containers (and code in serverless PaaS) is the customer’s responsibility, not the cloud provider’s. Like virtual machines and containers in enterprise data centers, the optimal place for security visibility and control is within the workload itself.
Implementing micro-segmentation as part of that process will help you maintain a more secure environment than simple traditional perimeter security.
Once you have established the right sharing processes and policies, you’ll be in a position to ensure the highest levels of security for all parties involved.
Learn about the AWS Shared Responsibility Model, or read the full story of Cogna’s secure data center migration and how they implemented their controls with Guardicore.
The content and opinions in this blog are those of the third-party author and AWS is not responsible for the content or accuracy of this post.
Guardicore – AWS Partner Spotlight
Guardicore is an AWS Advanced Technology Partner and innovator in data center and could security. Guardicore’s solution provides L7 micro-segmentation, real-time visibility, detection, and response to active breaches.
Contact Guardicore | Partner Overview | AWS Marketplace
*Already worked with Guardicore? Rate the Partner
*To review an AWS Partner, you must be a customer that has worked with them directly on a project.