AWS Security Best Practices

AWS is the biggest player in the public IaaS (Infrastructure as a Service) market and a critical component of the hybrid-cloud infrastructure in many enterprises. Understanding how to secure AWS resources and minimize the impact of any breaches that do occur has become more important than ever. For this reason, after closing 2018 with Infection Monkey & GuardiCore Centra’s integration into AWS Security Hub, we decided to open 2019 with a crash course on AWS security best practices.

In this piece, we’ll dive into some of the basics of AWS security, provide some tips to help you get started, and supply you with information on where you can learn more.

#1 AWS security best practice: Get familiar with the AWS shared responsibility model

Understanding the AWS security paradigm at a high level is an important part of getting started securing your AWS infrastructure. AWS uses the shared responsibility model to define who is responsible for securing what in the world of AWS. To help conceptualize the model, the public cloud infrastructure giant has come up with succinct verbiage to describe what they are responsible for and what you (the customer) are responsible for. In short:

AWS is responsible for “security of the cloud”- This means select software, hardware, and global infrastructure (think racks in physical data centers, hypervisors, switches, routers, storage, etc.) are AWS’s responsibility to secure.

Customers are responsible “for security in the cloud”- This means customers are responsible for ensuring things like customer data, applications, operating systems, firewalls, authentication, access management, etc.

Worded differently, AWS gives you the public cloud infrastructure to build upon, but it’s up to you to do so responsibly. It is expected that not everything you need will be baked into any given AWS solution. Third-party security tools like Centra can help fill those gaps. Understanding the shared responsibility model and what tools can help will allow you to ensure you’re doing your part to secure your infrastructure.

#2 AWS security best practice: Use IAM wisely

AWS Identity and Access Management (IAM) is a means of managing access to AWS resources and services, and is built-into AWS accounts. In a nutshell, IAM enables you to configure granular permissions and access rights for users, groups, and roles. Here are a few useful high-level recommendations to help you get started with IAM:

  • Grant least privilege – The principle of least privilege is a popular concept in the world of InfoSec and it is even more important to adhere to in the cloud. Only grant users and services the privileges necessary for the given set of tasks they should be legitimately responsible for, and nothing more.
  • Use IAM groups – Using groups to assign permissions to users significantly simplifies and streamlines access management.
  • Regularly rotate credentials – Enforcing expiration dates on credentials helps ensure that if a given set of credentials is compromised, there is a limited window for an attacker to access your infrastructure.
  • Limit use of root – Avoid using the Linux “root” user. Being conservative with your use of root access helps keep your infrastructure secure.
  • Use MFA – Multi-factor authentication (MFA) should be considered a must for users with high-level privileges.

#3 AWS security best practice: Disable SSH password authentication

If you’re familiar with Linux server administration in general, you’re likely familiar with the benefits of SSH keys over passwords. If you’re not, the short version is:

  • SSH keys are less susceptible to brute force attacks than passwords.
  • To compromise SSH public-key authentication used with a passphrase, an attacker would need to obtain the SSH private-key AND determine (or guess) the passphrase.
  • While SSH keys may require a little more work when it comes to key management, the pros far outweigh the cons from a security perspective.

#4 AWS security best practice: Use security groups

First, to clear up a common misconception: AWS security groups are NOT user groups or IAM groups. An AWS security group is effectively a virtual firewall. If you’re comfortable understanding the benefits of a firewall within a traditional network infrastructure, conceptualizing the benefits of AWS security groups will be intuitive.

AWS security group best practices

Now that we’ve clarified what a security group is, we’ll dive into a few AWS security group best practices to help you get started using them.

    • Minimize open ports – Unless there is a highly compelling argument to do so, only allow access to required ports on any given instance. For example, if you’re running a cluster of instances for a web-server, access to TCP ports 80 and 443 makes sense (and maybe 22 for SSH), but opening other ports is an unnecessary risk.
    • Don’t expose database ports to the Internet – In most cases, there is no need to expose the database to the Internet – doing so puts your infrastructure at risk. Use security group policies to restrict database port (e.g. TCP 3306 for MySQL) access to other specific AWS security groups.
    • Regularly audit your security group policies – Requirements change, rules that were once needed become liabilities, and people make mistakes. Regularly auditing your security rules for relevance and proper configuration help you minimize the likelihood that an outdated or misconfigured security group creates a network breach.

This is just the tip of the iceberg when it comes to AWS security group best practices. For more information, check out the AWS Security Groups User Guide and our Strategies for Protecting Cloud Workloads with Shared Security Models whitepaper.

#5 AWS security best practice: Leverage micro-segmentation

One of the most important components of securing public-cloud infrastructure, particularly in hybrid-cloud environments, is micro-segmentation. Micro-segmentation helps limit both north-south and east-west movement of breaches when they occur, which helps mitigate the spread of threats from one node to another. Further, Guardicore’s intelligent micro-segmentation solution can limit one of the biggest drivers of breach impact: dwell time. If you’re interested in learning more, check out this blog post for a crash course on micro-segmentation best practices.

How micro-segmentation complements AWS security groups

Security groups are an important part of AWS security, and micro-segmentation is excellent way to complement them and round out a hybrid-cloud security plan. A micro-segmentation solution like Guardicore Centra helps ensure you are able to implement micro-segmentation seamlessly both on-premises and in the cloud. Specific benefits of using Centra to complement AWS security groups include:

  • Enhanced visibility – Centra is able to automatically discover applications and flows, use its AWS API integration to pull labels and asset information, and provide granular visibility and baselining for your entire infrastructure.
  • Application aware policies- Next Generation Firewalls (NGFWs) are a big part of on-premises security, and Centra helps bring the same features to your AWS cloud. You wouldn’t compromise on application-aware security in a physical datacenter, and with Centra you don’t have to in the cloud either.
  • Protection across multiple cloud platforms & on-prem- It is common for the modern enterprise to have workloads scattered across multiple cloud service providers as well as physical servers on-premises. Centra is able to provide micro-segmentation for workloads running in AWS, other IaaS providers, and on physical servers in corporate offices and data centers. This helps enterprises ensure that their security is robust across the entirety of their infrastructure.

If you’re interested in learning more about the benefits of Centra for AWS, check out this solution brief (PDF).

Putting it all together: a holistic approach to AWS security

As we have seen, there is no single magic bullet when it comes to securing your AWS infrastructure. Understanding the AWS shared responsibility model enables you to know where to focus your attention, and leveraging built-in AWS features like security groups and IAM are a great start. However, there are still gaps left unaccounted for by AWS tools, and 3rd party solutions are needed to address them. Guardicore Centra provides users with micro-segmentation, breach detection & response, and application-level visibility that help round out a holistic approach to AWS security.

Want to learn more?

For more on how Guardicore Centra and micro-segmentation can help you keep your AWS resources secure,  contact us today or sign up for a demo of the Centra Security Platform.

Interested in cloud security for hybrid environments? Get our white paper about protecting cloud workloads with shared security models.

Read More

Looking for a Micro-segmentation Technology That Works? Think Overlay Model

Gartner’s Four Models for Micro-Segmentation

Gartner has recently updated the micro-segmentation evaluation factors document (“How to Use Evaluation Factors to Select the Best Micro-Segmentation Model (Refreshed: 5 November 2018).

This report details the four different models for micro-segmentation, but it did not make a clear recommendation on which was best. Understanding the answer to this means looking at the limitations of each model, and recognizing what the future looks like for dynamic hybrid-cloud data centers. I recommend reading this report and evaluating the different capabilities, however for us at Guardicore, it is clear that one solution model stands above the others and it should not be a surprise that vendors that have previously used other models are now changing their technology to use this model: Overlay.

But first, let me explain why other models are not adequate for most enterprise customers.

The Inflexibility of Native-Cloud Controls

The native model uses the tools that are provided with a virtualization platform, hypervisor, or infrastructure. This model is inherently limited and inflexible. Even for businesses only using a single hypervisor provider, this model ties them into one service, as micro-segmentation policy cannot be simply moved when you switch provider. In addition, while businesses might think they are working under one IaaS server or hypervisor, the provider may have servers elsewhere, too, known as Shadow IT. The reality is that vendors that used to support Native controls for micro-segmentation have realized that customers are transforming and had to develop new Overlay-based products.

More commonly, enterprises know that they are working with multiple cloud providers and services, and need a micro-segmentation strategy that can work seamlessly across this heterogeneous environment.

The Inconsistency of Third-Party Firewalls

This model is based on virtual firewalls offered by third-party vendors. Enterprises using this model are often subject to network layer design limitations, and therefore forced to change their networking topology. They can be prevented from gaining visibility due to proprietary applications, encryption, or invisible and uncontrolled traffic on the same VLAN.

A known issue with this approach is the creation of bottlenecks due to reliance on additional third-party infrastructure. Essentially, this model is not a consistent solution across different architectures, and can’t be used to control the container layer.

The Complexity of a Hybrid Model

A combination of the above two models, enterprises using a hybrid model for micro-segmentation are attempting to limit some of the downsides of both models alone. To allow them more flexibility than native controls, they usually utilize third-party firewalls for north-south traffic. Inside the data center where you don’t have to worry about multi-cloud support, native controls can be used for east-west traffic.

However, as discussed, both of these solutions, even in tandem, are limited at best. With a hybrid approach, you are also going to add the extra problems of a complex and arduous set up and maintenance strategy. Visibility and control of a hybrid choice is unsustainable in a future-focused IT ecosystem where workloads and applications are spun up, automated, auto-scaled and migrated across multiple environments. Enterprises need one solution that works well, not two that are sub-par individually and limited together.

Understanding the Overlay Model – the Only Solution Built for Future Focused Micro-Segmentation

Rather than a patched-together hybrid solution from imperfect models, Overlay is built to be a more robust and future-proof solution from the ground up. Gartner describes the Overlay model as a solution where a host agent or software is enforced on the workload itself. Agent-to-agent communication is utilized rather than network zoning.

One of the negative sides to third-party firewalls is that they are inherently unscalable. In contrast, agents have no choke points to be constrained by, making them infinitely scalable for your needs.

With Overlay, your business has the best possible visibility across a complex and dynamic environment, with insight and control down to the process layer, including for future-focused architecture like container technology. The only solution that can address infrastructure differences, Overlay is agnostic to any operational or infrastructure environments, which means an enterprise has support for anything from bare metal and cloud to virtual or micro-services, or whatever technology comes next. Without an Overlay model – your business can’t be sure of supporting future use cases and remaining competitive against the opposition.

Not all Overlay Models are Created Equal

It’s clear that Overlay is the strongest technology model, and the only future-focused solution for micro-segmentation. This is true for traditional access-list style micro-segmentation as well as for implementing deeper security capabilities that include support for layer 7 and application-level controls.

Unfortunately, not every vendor will provide the best version of Overlay, meeting the functionality that its capable of. Utilizing the inherent benefits of an Overlay solution means you can put agents in the right places, setting communication policy that works in a granular way. With the right vendor, you can make intelligent choices for where to place agents, using context and process level visibility all the way to Layer 7. Your vendor should also be able to provide extra functionality such as enforcement by account, user, or hash, all within the same agent.

Remember that protecting the infrastructure requires more than micro-segmentation and you will have to deploy additional solutions that will allow you to reduce risk and meet security and compliance requirements.

Micro-segmentation has moved from being an exciting new buzzword in cyber-security to an essential risk reduction strategy for any forward-thinking enterprise. If it’s on your to-do list for 2019, make sure you do it right, and don’t fall victim to the limitations of an agentless model. Guardicore Centra provides an all in one solution for risk reduction, with a powerful Overlay model that supports a deep and flexible approach to workload security in any environment.

Want to learn more about the differences between agent and agentless micro-segmentation? Check out our recent white paper.

Read More

CVE-2019-5736 – runC container breakout

A major vulnerability related to containers was released on Feb 12th. The vulnerability allows a malicious container that is running as root to break out into the hosting OS and gain administrative privileges.

Adam Iwanuik, one of the researchers who took part in the discovery shares in detail the different paths taken to discover this vulnerability.

The mitigations suggested as part of the research for unpatched systems are:

  1. Use Docker containers with SELinux enabled (–selinux-enabled). This prevents processes inside the container from overwriting the host docker-runc binary.
  2. Use read-only file system on the host, at least for storing the docker-runc binary.
  3. Use a low privileged user inside the container or a new user namespace with uid 0 mapped to that user (then that user should not have write access to runC binary on the host).

The first two suggestions are pretty straightforward but I would like to elaborate on the third one. It’s important to understand that Docker containers run as root by default unless stated otherwise. This does not explicitly mean that the container also has root access to the host OS but it’s the main prerequisite for this vulnerability to work.

To run a quick check whether your host is running any containers as root:


#!/bin/bash

# get all running docker container names
containers=$(docker ps | awk '{if(NR>1) print $NF}')

echo "List of containers running as root"

# loop through all containers
for container in $containers
do
    uid=$(docker inspect --format='{{json .Config.User}}' $container)
    if [ $uid = '"0"' ] ; then
        echo "Container name: $container"
    fi
done

In any case, as a best practice you should prevent your users from running containers as root. This can be enforced by existing controls of the common orchestration\management system. For example, OpenShift prevents users from running containers as root out of the box so your job here is basically done. However, in Kubernetes your can run as root by default but you can easily configure PodSecurityPolicy to prevent this as described here.

In order to fix this issue, you should patch the version of your container runtime. Whether you are just using a container runtime (docker) or some flavor of a container orchestration system (Kubernetes, Mesos, etc…) you should look up the instructions for your specific software version and OS.

How can Guardicore help?

Guardicore provides a network security solution for hybrid cloud environments that spans across multiple compute architectures, containers being one of them. Guardicore Centra is a holistic micro-segmentation solution that provides process-level visibility and enforcement of the traffic flows both for containers and VMs. This is extremely important in the case of this CVE, as the attack would originate from the host VM or a different container and not the original container in case of a malicious actor breaking out.

Guardicore can mitigate this risk by controlling which processes can actually communicate between the containers or VMs covered by the system.

Learn more about containers and cloud security

Operationalizing Micro-Segmentation to Get You Started

It seems like the idea of micro-segmentation is everywhere today. Considering that the modern corporate perimeter is vastly different than that of the past, with our dependence on cloud based resources, mobile devices and third party vendors, what worked to protect it back then is no longer sufficient. It’s becoming clear that micro-segmenting networks is the way forward in a security landscape where traditional tools are failing to protect whatever is left of the disappearing perimeter.

In Forrester’s 2017 Gauge Your Zero Trust Maturity report, they detail how micro-segmentation has become a crucial element in any security architecture, but they aren’t the only ones praising the model. The concept is garnering more and more attention by leading security experts because it’s one of the most effective means of preventing lateral movement within networks and it’s time and cost effective too — a typical VLAN segmentation deployment for a small number of applications can take many months months and eats up hundreds of hours of IT staff time; a properly deployed micro-segmentation deployment of similar parameters takes about a month and consumes far less time to set up.

Getting it right, the first time

Before you begin your micro-segmentation journey however, there are some aspects to consider. Establishing a solid micro-segmentation deployment isn’t a 1-2-3 process. It needs to be approached with deliberate forethought and cannot be slapped together. Doing it the right way the first time ensures that your micro-segmentation project will remain cost and time effective when viewed against other extended projects that don’t effectively segment, let alone secure, networks.

Here are some of the most important things you need to think about as you embark on your micro-segmentation project. This post will focus on the ‘before implementation’ stage to help facilitate your journey to a successful micro-segmentation deployment.

Micro-segmentation considerations – Before deployment

Understand what you want to segment:

Before you do anything, decide what needs segmenting and why you want to segment it. This is critical because what you are going to segment will impact how you do it. For example, if you need to comply with industry regulations like HIPAA, SWIFT or PCI, your micro-segmentation project must start with ensuring that the areas in which those asset are housed are ringed off immediately. On the other hand, if you’re considering micro-segmentation with an end goal of general risk reduction, you’ll need to start with segmenting your most sensitive assets first and then move on to segmenting the less sensitive areas in a phased approach.

Go after short term, then long term, priorities:

Yes, you already know that your long term priority is improving your overall security posture and reducing your organizational risk. But to get there, you need to prioritize your segmentation goals. Start with simple micro-segmentation tasks which significantly reduce risk (for example, blocking insecure protocols such as telnet or FTP, or forcing SSH traffic through a specific jumpbox), and then proceed to a more thorough policy (such as application and tier segmentation).

So start with identifying and prioritizing and prioritizing your goals — then you can put the plans to implement them into action.

Build a picture of your environment for visibility:

Building a clear visualization of your environment will help you roll out your robust micro-segmentation implementation. The initial picture of what you think you have running and connected is inherently limited — so be aware, as you build out that detailed plan, you’re likely to discover connections and dependencies you had not thought of before. With this in mind, you may need backtrack just a bit to incorporate the aspects that were initially missed to create that comprehensive and accurate map. Once you’ve got this picture, you can begin to map all your dependencies which will help you understand where you need to create and enforce rules.

Decide which labels you’re going to use:

Based on the goals you established, figure out which labels you need. Labels are snippets of metadata attached to workloads, which provide context regarding that specific workload. For example, a server might be labeled with “Production Environment”, “PCI compliant” and “ERP application” labels.

Properly labeling your workloads is critical to the success of your microsegmentation deployment. Thus, it’s important to have flexibility in this process, instead of trying to force yourself into existing, limited options. Labels can and should be adapted to your specific organizational needs — for example, if you need application segmentation, use the “Application” label type. Need to segment your PCI compliant machines from others? You probably need a “PCI compliant” label. The important part is that they can be augmented to reflect your unique business requirements.

ID your information sources:

Identify the sources of information from which labels are going to be imported to your micro-segmentation solution. Labels can be found in various places: Public Cloud instance tags, Kubernetes labels, orchestration platforms, CMDB systems and more. Once this is done effectively, you can plan (and later implement) a way to extract the information from these sources into your micro-segmentation solution. At first this might be a semi-manual process, but long term, the goal is to create a fully automated, reliable solution here.

Further considerations for a successful micro-segmentation deployment

Congratulations – you’ve laid the groundwork out for your micro-segmentation project. But there is more to be considered to make sure your deployment is solid and seamless. Want to find out about the next set of key considerations for ensuring micro-segmentation success?

Download our white paper now and learn how to nail down all the considerations for your micro-segmentation deployment.