How to Choose the Tools for Securing Cloud Environment

It is important to pick the right tools for anomaly detection, incident response, and policy enforcement in cloud environments. The use of microservices, cloud-native workloads, and serverless architectures complicates the selection process by limiting the techniques and tools available to achieve security and compliance objectives.

In this blog post, we’ll discuss key things to consider when choosing and implementing cloud security tools. We’ll also highlight the strengths and weaknesses of specific tools.

What Should We Consider When Selecting Cloud Security Tools?

Based on our extensive experience helping clients implement cloud security tools, here are what we have found to be the most important considerations for tool selection.

• Roles and responsibilities. In today’s cloud environments, security and compliance responsibilities are shared between the Cloud Service Provider (CSP) and the CSP customer. For example, Amazon Web Services (AWS) uses a Shared Responsibility Model in which customers are responsible for security functions such as identity and access management, firewall configuration, and data encryption. AWS is responsible for securing the cloud infrastructure that runs the software offered in the AWS cloud (e.g., hardware, software, networks). When selecting cloud security tools, be sure to understand the functions your tools will be performing in the context of your CSP’s shared responsibility model.
• Security controls. Make sure that the tools you select will help you demonstrate that your expected security controls are in place and can be monitored. For example, if your organization needs to comply with ISO 27002, choose tools that will enable you to demonstrate compliance with this standard. It’s also important to pick tools that can be deployed as code, so they are capable of scaling with the environment (see below for more on this).

Many of our clients have had good results using Palo Alto Network’s Prisma tools for validation and monitoring security controls. These tools not only alert when failures are detected but provide detail on the failures and guidance on how to remediate. They also have the benefit of mapping to compliance standards, including PCI, HIPAA, GDPR, SOC2, NIST 800-171, NIST 800-53, NIST CSF, ISO 27002, CCPA, and CCM.

We’ve also found that AWS provide a great way to evaluate what is currently in production. They do need to be updated from even their compliance baselines, but they will alert and provide the necessary detail on failures (e.g., X bucket has failed the encryption check, to remediate perform X actions).

We’ve had good luck using Terraform’s Sentinel Policy to provide clients with preventative controls that ensure security and compliance requirements are not violated during the deployment phase. This can also save compute costs that would otherwise be flagged during a conformance run.

eSecurity Planet’s Twistlock product has worked well for clients that need to provide full lifecycle control for containerized environments.

Clients have achieved favorable results using SaltStack for configuration management.

A couple of years ago, tool providers began advertising “auto-remediation” functionality. In our experience, most products are still not able to achieve full auto-remediation due to the complexities and nuances of each client’s environment. Our advice would be to assume that a substantial degree of manual remediation is still going to be required with the current generation of tools.

• Security Operations. Consider selecting cloud security tools like TensorFlow that facilitate and streamline the activities of your security operations team. As environments scale up, so does the volume of log data, making it harder and harder to find that needle in the haystack. Tensorflow offers an end-to-end, open-source machine learning platform that our clients use to dump CloudTrail and flow logs to identify any potential risks within an environment. Tensorflow’s ability to pull flow logs is a valuable feature not offered by many competing products. This capability enables clients to translate outside traffic flow to the microservice.

Distributed tracing tools like OpenCensus understand the flow of traffic from the internet to a microservice. We first saw this tool used within operations teams to understand if there was a bad deployment. For security purposes, this tool can also be used to identify malicious individuals/activity within an environment. 

• Control planes. Your cloud security tools should be able to pull data from all control planes. This includes control planes from your organization’s systems as well as those from your CSP’s cloud infrastructure components.
• Cloud security tools should be standardized across all groups and environments to ensure parity and consistency in how security is demonstrated.
• The right tools and technology for securing your cloud environment will be dependent on the makeup of your workload. Be sure to consider your current workload and the workload you expect to see in the next few years.
• Deployable as code. We recommend selecting cloud security tools that can be deployed as code and do not require manual provisioning when a new environment is created. This reduces the risk that security vulnerabilities will be introduced due to manual provisioning errors and streamlines the provisioning process. We suggest checking out the Terraform Registry to gauge if a new tool or piece of technology can be provisioned as code.

How Should We Implement Cloud Tools?

We suggest clients take a multi-phased approach to implementing cloud security tooling and technology. While the sequence of implementation may vary somewhat based on unique client requirements, the general approach below works for many clients.

1. Compliance as Code. Implement “Compliance as Code” tools such as Terraform’s Sentinel Policy to ensure all deployed code aligns with security requirements. It’s important to get this in place before provisioning begins. These tools have the added benefit of being declarative (human-readable) so that most groups can review policy implementations to validate they are working as intended. Terraform also enables portability of workloads between IaaS providers, thereby preventing vendor lock-in.
2. Preventative Controls. After the environment is provisioned, you can shift focus to implementation of preventative controls. To maintain security and compliance, implement absolute stops that prevent certain high-risk activities from occurring (e.g., logging in as root, changing security group rules, disabling logging). These preventative controls have the flexibility to be a hard stop and roll back, or a notification that there is drift. They are generally deployed in the form of a step function.

We Can Help

If you have questions about cloud security tools or would like help implementing them in your environment, Tevora’s team of cloud security specialists can help. Just give us a call at (833) 292-1609 or email us at sales@tevora.com.

About the Author

Clayton Riness is a Principal Consultant at Tevora. 

Christopher Callas is a Sr. Manager of Cloud Security at Tevora.