Essential features of security automation for the AWS platform

DevSecOps tactics and tools are dramatically changing the way organizations bring their applications to fruition. Having a mindset that security must be incorporated into every stage of the software development lifecycle – and that everyone is responsible for security – can reduce the total cost of software development and ensure faster release of secure applications.

A common goal of any security strategy is to resolve issues quickly and safely before they can be exploited for a breach resulting in data loss. Application developers are not security specialists, and likely do not have the knowledge and skills to find and fix security issues in a timely manner. This is where security automation can help.

Security automation uses tools to continuously scan, detect, investigate, and remediate threats and vulnerabilities in code or the application environment, with or without human intervention. Tools scale the process of incorporating security into the DevSecOps process without requiring an increase in human skills or resources. They do this by automatically putting up safety rails around the issue whenever they find something that is a clear and obvious violation of security policy.

The AWS cloud platform is ripe for security automation

Amazon claims to have more than a million customers on its cloud computing platform, mostly small and mid-size companies but also enterprise-scale users. Regardless of customer size, Amazon has always had a model of shared responsibility for security.

Amazon commits to securing every component under its control. Customers, however, are responsible for securing what they control, which includes configurations, code, applications, and most importantly, data. This leaves a lot of opportunity for misconfigurations, insecure code, vulnerable APIs, and poorly secured data that can all lead to a data breach.

A common security problem in AWS is an open S3 storage bucket where data is publicly readable on the Internet. Despite the default configuration of S3 buckets being private, it’s fairly easy for developers to change policies to be open and for that permission change to apply in a nested fashion. A security automation tool should be able to find and identify this insecure configuration and simply disable public access to the resource without requiring human intervention.

Amazon added such tools in 2017 and again in 2018, yet we keep seeing headlines of companies whose data has been breached due to open S3 buckets. The security tool should communicate to the appropriate teams, but in many situations based on the sensitive contents of the data, the tool should also auto-remediate the misconfigured access policies. Teams that embrace security automation can also use this type of alerting and auto-remediation to become more aware of issues in their code or environment and, hopefully, head them off before they occur again.

What else can be auto-remediated? There are hundreds of vulnerabilities in AWS that can and should be fixed without human intervention. Here are just a few examples:

• AWS CloudTrail data-at-rest encryption levels
• AWS CloudFront Distribution logging access control
• AWS Elastic Block Store access control
• AWS S3 bucket access control
• AWS S3 bucket ransomware exposure
• AWS Simple Queue Service exposure

Essential features of a security automation tool

There are important categories of features of a security automation product for AWS. One category addresses data-in-motion with auto-remediation of API and queuing authentication and encryption. The other addresses data-at-rest with auto-remediation of database and storage encryption and backup. Security monitoring and enforcement are needed to automatically protect developers from making mistakes in how they are moving or storing data.

Here are four essential features to look for in a security automation tool.

1. Continuous discovery of shadow APIs within cloud, mobile, and web apps

APIs enable machine-to-machine data retrieval, essentially removing barriers and accelerating access to data. There is hardly a modern application today that doesn’t provide an API to integrate with other applications and data sources. A developer only needs to write a few lines of code to create an API. A shadow API is one that operates outside the purview of the security team. It’s a challenge to enforce security on code that is known only to the programmer. Thus, a security automation tool must have the ability to continuously scan for and discover APIs that may pose a security threat to prevent a data breach.

2. Full-stack security analysis of mobile and modern web apps

Before data gets taken up into the AWS cloud, it often starts at the client layer with a web or mobile app. Protecting user privacy and securing sensitive data is a continuous effort that requires vulnerability analysis from mobile to web to backend cloud services. Modern attackers often focus on exploiting the client layer to highjack user sessions, embedded passwords, and toxic tokens left inside mobile apps or single-page applications.

3. Automation fully integrated into the CI/CD pipeline with support for auto-remediation

Most vulnerability assessment tools integrate into the CI/CD pipeline by reporting what they find to systems such as Jira, Bugzilla and Jenkins. This is table stakes for assessment tools. What’s more valuable, however, is to include auto-remediation of the issues in the CI/CD pipeline. Instead of waiting for a human to make and verify the fix for the vulnerability, the tool does it automatically and reports the results to the ticketing system. This frees developers from having to spend time resolving common issues.

4. Automated vulnerability hacking toolkits for scheduled pre-production assessments

Companies often hire white hat hackers to do, basically, a moment-in-time penetration test in their pre-production environment. A more modern approach is to deploy a toolkit that continuously performs the same hacking activities. Not only is using such a toolkit much more cost effective, but it also works non-stop to find and fix vulnerabilities.

When auto-remediation may not be appropriate

Automatic remediation of some security issues isn’t always appropriate. Rather, it’s better that the tool simply discovers the issue and raises an alert to allow a person to decide how to resolve it. For example, auto-remediation is generally unsuitable when an encryption key is required, such as for a database, and for configurations that require user interactions, such as selecting a VPC or an IAM rule. It’s also not appropriate when the fix requires changes to existing code logic within the customer’s proprietary code base.

Nonetheless, some tools do aid in dealing with insecure code. One helpful feature that isn’t found in all security automation tools is the recognition of faulty code and recommendations on how to fix it with secure code. Seeing the recommended code fix in the pre-production stage helps resolve issues quickly without wasting time doing research on why the code is troublesome. Developers get to focus on their applications while security teams ensure continuous security validation.

Summary

AWS is a complex environment with many opportunities for misconfigurations and other issues that can lead to a data breach. Security automation with auto-remediation takes pressure off developers to find and fix a wide variety of vulnerabilities in code and configurations to help keep their organizations’ data safe.