5 Infrastructure Security Tasks Your Developers Can Automate

That’s unfortunate, because the cost of securing code up front is always less than the cost of downtime, the time required to patch vulnerabilities, and doing damage control after a breach has occurred. To save time in the long run and go fast while deploying secure, cloud-native applications, you need the right tools, processes, and, of course, automation.

Here are five manual cloud security tasks that every developer of back-end and infrastructure-related software should automate to produce secure, quality code.

1. Remediate misconfigurations in open source code

It’s common for developers and DevOps teams to lean on open-source modules to scale cloud-native applications and infrastructure quickly. Terraform modules, CloudFormation templates, and Kubernetes Helm charts are all examples of infrastructure-as-code (IaC) building blocks that can be easily shared for reuse.

• Terraform has become one of the leading provisioning frameworks for multi-cloud development. The Terraform Registry, which had just 50 modules in June 2019, has grown to contain over 6,500 modules as of this writing.
• Helm is a top choice for managing Kubernetes applications, reducing the need for manually written and managed Kubernetes YAML. In the Cloud Native Computing Foundation Survey 2020, 63% of respondents said Helm was their tool of choice for packaging Kubernetes applications.
• CloudFormation is AWS-native and allows you to modify AWS resources in a controlled and predictable way. Using the newer AWS CloudFormation Public Registry, you can leverage third-party extensions to automate the provisioning of infrastructure and application resources without the need for custom scripts or manual processes.

Although open source is a huge benefit of leveraging IaC, it does come with some downsides. When IaC components are shared publicly for reuse, they’re optimized for functionality and ease of use. Unfortunately, in many cases, they’re not designed with security in mind.

In our own research, we found that nearly half of open-source Terraform modules contained misconfigurations. Additionally, when we scanned Artifact Hub, we found that 71% of the 618 scanned Helm repositories contained misconfigurations, and 46.5% of 2,300 scanned Helm charts contained misconfigurations.

Using open-source resources makes it easier for developers to spin up and modify IaC. But, again, the name of the game is speed and efficiency. In a perfect world, a developer could just grab any old Helm chart out of Artifact Hub or GitHub and know right away if it was secure. There should be clear disclaimers or guidance on what needs to be done to secure the module if it isn’t.

IaC scanning tools were designed exactly with this in mind. A great deal of scanning tends to happen locally, pre-commit. To unlock the real power of automation, you can embed automated checks and guardrails right into your build pipeline, which leads us to our next point.

2. Integrate security guardrails across the pipeline

The secret to security automation is to leverage the tools and processes you already have in place. Chances are if you’re leveraging DevOps or agile methodologies, you’re on the right track to embedding security in your day-to-day workflows and maximizing automation.

A mature security automation strategy should be embedded across the entire software development lifecycle, but integrating security guardrails into just one checkpoint is a great start.

Perhaps the easiest place to embed organization or team-wide automation is your continuous integration and deployment (CI/CD) pipelines. Adding automated checks to the pipeline that all your developers are pushing code through is the best way to ensure that only well-written code ends up in your repository.

The great thing about embedding security scanning here is that you can leverage open-source tools such as Checkov and fully customize the output to be as passive or blocking as you see fit. For example, you could configure builds to fail only if critical security flaws are detected, but pass for everything less critical. Alternatively, you could begin with just alerting for training and educational purposes but not actually block builds until all developers know what to expect.

Use all your tools to their fullest

Your version-control system also has some hidden security automation superpowers. For example, you can save a little time by integrating with a service that scans your code prior to running in your CI/CD pipeline when new commits or pull/merge requests are created. Waiting for builds to finish only to have them fail isn’t a great use of time, so pushing security guardrails earlier allows for more iterative feedback.

If you want to shift security feedback as early in the process as possible, there are ways and tools to do that without having to scan code manually. Encourage developers to scan their files or directories before code leaves their local workstations. Several IDE plugins do this natively.

Although these guardrails are harder to enforce across a team, getting developers accustomed to security automation on their own terms is a great way to foster security champions and encourage secure coding.

Regardless of where you add guardrails into DevOps processes, security automation will help you automatically block vulnerable or insecure code and ensure that only code that passes all checks and is compliant with all policies can be deployed. In this way, you can bypass the endless cycle of ticket creation and implement fixes where they need to happen: in the source code.

3. Identify compliance violations

A company’s initiatives around regulatory compliance vary by industry, location, the type of data it collects, and so on. To maintain compliance, companies must consistently demonstrate that they’ve accounted for a prescribed list of risks. That list can be long. Compliance frameworks such as HIPAA, PCI-DSS, SOC-2, and others contain hundreds if not thousands of pages of guidelines and policies.

Putting the onus on developers to remember what level of encryption is required for a specific compliance benchmark won’t make for happy developers. Add up the time lost from performing countless manual checks against potentially hundreds of services, and you can see how easily things can get slowed down.

Automating compliance checks helps companies remain compliant while encouraging developer velocity. It’s a win for developers but also for security and compliance teams that will inevitably have to deal with auditors.

For developers, the benefits of speed and efficiency are obvious. Rather than the developers having to remember a set of compliance guidelines, an automation tool can let them know up front that they need to have encryption turned on or ensure that certain aspects of their applications are not exposed to the Internet. By relying less on manual processes, developers can do their jobs without having to worry about putting the company in a position where it must pay huge regulatory fines for noncompliance.

But there are also benefits for teams that work with internal compliance or auditors. Anyone who has ever had to go through a compliance audit knows how painful it can be. Automated tools can alleviate some of that pain by providing proof that certain boxes have already been checked.

Many tools offer dashboards and downloadable reports that compliance teams can use when they perform deeper forensics. In many cases, they even let you filter by a specific compliance framework. The lesson is that doing the work up front saves everyone time and headaches.

4. Tag cloud resources, from code to cloud

One of the first things they teach you in grade school is the importance of organization. It’s no different when managing and securing cloud resources and it’s crucial to automate cloud security. Assigning the appropriate tags to cloud resources can help you understand who has access to what so you can quickly fix an issue, assign or revoke access, define risk, and more.

Do you need to quickly identify web servers out of thousands or tens of thousands of resources in a region in your AWS account? Tags can help you do that. Or, if you want to organize multiple resources across AWS services, you can use tags to set up resource groups.

Tags can also direct operational support. If a monitoring system triggers an alarm, having tags allocated to cloud resources can help identify the team and user that modified the resource in order to resolve the issue.

This is especially the case if you’re leveraging IaC; locating the line of code that configured the cloud resource can be a nightmare. If you’re trying to fix something or limit access, it can be nearly impossible (without the right access) to sift through logs to identify the right team to help.

You could add tags manually, but doing so is tedious. And you’re likely to hit a snag at some point down the line. Different teams may use slightly different tagging and naming conventions, and doing so will incorrectly group the resources or negate your tagging strategy altogether. Sometimes you might simply forget to tag a resource.

By using an automated tool such as Yor, details such as git organization, repository, time stamps, and modifiers are automatically and continuously added as tags to all resources. This makes it easier and faster to find the developer and the line of code that caused the misconfiguration. A lower mean time to resolution—what’s not to like about that?

5. Monitor IAM permissions

Identity and access management (IAM) is a set of policies and processes to control who is authenticated and authorized to use a set of resources. It was designed to ensure that a user or system accessing a resource is who they say they are, so you can then provide the proper access rights.

IAM is often performed manually via an admin who monitors and provisions users. But users can quickly grow in number, and there are hundreds of permission specifications that an admin must sift through. Cloud admins wind up spending a large portion of their days untangling IAM sprawl. For larger companies, users often gain access via ticketing systems, which can take hours or even days.

There’s a security challenge here as well. The idea of least privilege is to give users and systems only the capabilities they need to perform their required tasks. But it’s often easier for an administrator to provide full access rather than dig into the nuances of what access is appropriate.

Using automation, you can identify unused and overprivileged roles and users and cluster similar entities by their IAM activity throughout a specified time frame. It then becomes easier to identify unused permissions and detect overly permissive access so you can remove those permissions for specific users and roles.

AirIAM is an open-source tool that examines historical user behavior, determines the exact set of permissions that user needs, and creates a Terraform file to grant them just those permissions and nothing else in order to reduce the attack surface. In this way, if a user has never spun up a virtual machine, for example, that permission is removed.

Reduce the friction

Automating security and embedding it into your existing processes provides substantial speed and efficiency benefits. Integrating security early reduces time waste and creates a sense of confidence in the final product as it heads toward completion. But more importantly, automation reduces friction between developers and the various teams they work with.

Developers can accomplish more in the long run and realize greater success in their roles when they make life easy for security, operations, and compliance team members.