Using Shift-Left to Find Vulnerabilities Before Deployment with Trend Micro Template Scanner

By Tim Robinson, Well-Architected Geo Solutions Architect for Asia at AWS

Business agility is one of the principal benefits you expect when moving your business to the Amazon Web Services (AWS) Cloud.

Those who have moved to the cloud are, indeed, deploying applications faster. However, to accommodate that agility, DevOps methodologies have had to evolve. Among the most important of those methodologies is Shift-Left.

To understand Shift-Left, it helps to visualize the process of developing and deploying an application as a pipeline through which code moves from Left to Right. That pipeline is often referred to as a continuous integration/continuous deployment (CI/CD) pipeline.

Shift-Left simply means to perform tests and validations earlier in the CI/CD pipeline. Effectively, to shift them Left. Shift-Left has helped companies like Mecca identify vulnerabilities earlier, reducing both their time to market and cost of deployment.

This post explains how to combine two of the technologies that make Shift-Left possible. The first is AWS CloudFormation, which represents infrastructure as code (IaC). The second is Trend Micro’s Template Scanner, which checks your IaC to make sure it conforms to AWS Well-Architected Framework design principles and best practices.

Trend Micro is an AWS Partner Network (APN) Advanced Technology Partner with AWS Competencies in Security, Government, and Containers. It recently acquired Cloud Conformity and its Template Scanner.

You can deploy Trend Micro’s Template Scanner in three different ways. I will explain the pros and cons of each, and provide instructions to help you deploy them yourself.

I’ll summarize how DevOps teams use AWS Well-Architected, and describe how Trend Micro helped Mecca use Template Scanner to align their planned infrastructure to AWS Well-Architected.

How DevOps Teams Use AWS Well-Architected

AWS developed the Well-Architected Framework to help cloud architects build secure, high-performing, resilient, and efficient infrastructures for their applications.

Based on five pillars, the framework provides a consistent approach for customers and partners to evaluate architectures, and implement designs that scale over time.

The five pillars AWS Well-Architected are:

Operational excellence
Security
Reliability
Performance efficiency
Cost optimization

Using the Well-Architected Partner Program, DevOps teams can work with APN Consulting Partners to ensure their architectures are aligned to the Well-Architected Framework. Last year, we ran over 3,500 reviews worldwide within our partner network, which resulted in risk reduction and alignment to best practices.

AWS architects also conduct Well-Architected Reviews with customers as a way to improve eﬃciency and reduce risk.

The Well-Architected Framework becomes particularly useful with the IaC that AWS CloudFormation produces. In fact, creating a template of their intended environments using infrastructure as code is one of the central recommendations AWS architects make to customers in our Well-Architected Reviews.

Infrastructure as Code in AWS CloudFormation

The entire purpose of IaC is to save time and money. By representing the infrastructure that will host your application or service as code, you can test and validate it faster and at lower cost than you could with a live infrastructure.

To begin with, you don’t incur charges for compute, storage, and network resources you are simply testing. And you can make changes to the code much faster than you can to the physical infrastructure.

AWS CloudFormation provides a common language to model AWS and third-party application resources in a cloud environment. You can model and provision, in an automated and secure manner, all the resources needed for your applications across all regions and accounts.

To make the process easier, AWS has created a set of templates representing typical infrastructures, which it maintains within a GitHub repository. By using those templates, you get a head start on your IaC project.

However, because the templates are a starting point intended to apply to a wide variety of deployments, they do not always represent best practice for a particular customer. AWS expects you to modify the template to suit your particular needs and align to appropriate best practices according to your requirements.

This means that, until now, you had to conduct a Well-Architected Review with a partner or AWS Cloud Architect trained in the framework. That may still be the right approach for you, but Trend Micro now provides an autonomous solution to check for common best practice issues.

Trend Micro Template Scanner

Trend Micro’s Template Scanner checks AWS CloudFormation templates against aspects of the AWS Well-Architected Framework. Template Scanner is a rule engine with automated checks that are aligned with the Well-Architected Review process. It examines a template and identifies all the places in the IaC that do not comply with the best practices of the framework.

For example, the Template Scanner can examine the IaC for an Amazon Simple Storage Service (Amazon S3) bucket and identify any security best practices not in place. You can then put those best practices in place before the S3 bucket is deployed into a production environment.

The Template Scanner is capable of running as a standalone service in an integrated development environment (IDE). However, you get the most value if you use it with GitHub post-commit hook, or as part of a CI/CD pipeline.

For instance, as part of a CI/CD pipeline, it could generate JIRA Service Desk tickets to remediate failures, or simply interrupt the build activity until a minimum architectural bar has been reached.

Deploying in an Integrated Development Environment (IDE)

Let’s use the Template Scanner on an AWS CloudFormation template that represents a standard Linux, Apache, MySQL, and PHP (LAMP) stack. If you want to follow along, you are welcome to download the template. Be sure to register with CloudConformity, first.

The template deploys the stack with multiple AWS Availability Zones. While the LAMP stack this template builds uses adequate security groups and application load balancers to align with the Well-Architected Framework, it has some gaps to fill. These are visible when you run it through the Template Scanner from within an IDE.

Figure 1 – Security gaps in template uncovered by Template Scanner.

By altering the template with tags and adjusting security group configurations, you can signiﬁcantly improve the security and reliability of the infrastructure.

Embedded in a Git Hooks Code Pipeline

Uncovering vulnerabilities from within the IDE is a big win for a large percentage of DevOps teams, but it’s not enough when dealing with scale. When dealing with large infrastructures or frequent deployments, integrating the Template Scanner into an automated code build pipeline provides the greatest value.

For instance, you can configure your Git Hooks so that if the Template Scanner discovers a build doesn’t meet requirements, the pipeline automatically pulls the build.

Figure 2 – Embedding Template Scanner into an automated code build pipeline.

This approach automatically lets a DevOps engineer know the template conforms to best practices and is safe to execute in a production environment every time it’s updated.

Git Hooks allow a script to be run automatically every time a particular event occurs within a repository. You can use them to deﬁne actions that will occur at key points in the development cycle, such as sending you a message or pulling a build.

A number of diﬀerent hooks are available, and they reside within the .git/hooks directory of a Git repository.

Our procedure, following, sets up a post-commit hook that automatically calls the Template Scanner following every repository commit action.

Step 1: Create a GitHub repository

Create a GitHub repository for the AWS CloudFormation template you want to scan.

Step 2: Create an initial commit

After initializing the repository, add a README.md ﬁle in the appropriate project directory, and create an initial commit:

echo "Template scanner example" >> README.md

git init
git add README.md

git add MyBaseTemplate.json
git commit -m “My first commit”
git push origin master

This will have initialized your repository with a .git/hooks directory containing some sample hooks. We’ll use these hooks in a subsequent step to create our post-commit hook.

Step 3: Create an API key

Do this within the TrendMicro Cloud Conformity Console. From the console, log in with your user account and select User Settings. In the left navigation bar, select API Keys. At the top right of the API Keys screen, select +New API Key.

Figure 3 – Creating an API key from within the Cloud Conformity Console.

Once you have created the API Key, it displays in the console under the Key ID with a status of Enabled.

Step 4: Connect the Template Scanner

Return to your local GitHub repository and update the .git/hooks directory with this code to connect the Template Scanner using a simple post-commit hook:

#!/usr/bin/env python3
# Scans a CloudFormation template file 
# Requires "requests" to be installed

import requests import json

# Please substitute filePath, apiKey, and region 
# Cloud Conformity API Key
apiKey="XXXXXXXXX-ENTER-YOUR-API-KEY-HERE-XXXXXXXXXXXXXX"
# Path to CloudFormation template file Yaml or JSON file
filePath="XXXXXXXXX-ENTER-YOUR-CLOUDFORMATION-TEMPLATE-PATH-HERE-XXXXXXXXXXX" 
region="XXXXX-ENTER-YOUR-AWS-REGION-HERE-XXXXXXXXX"
endpoint = 'https://' + region + '-api.cloudconformity.com' 
url = endpoint + '/v1/iac-scanning/scan'

headers = {
   'Content-Type': 'application/vnd.api+json', 
   'Authorization': 'ApiKey ' + apiKey
}

contents = open(filePath, 'r').read() 
payload = {
    'data': {
        'attributes': {
            'type': 'cloudformation-template', 
            'contents': contents
        }
    }
}

resp = requests.post(url, headers=headers, data=json.dumps(payload))

json_response=resp.json()

for record in json_response['data']: 
    attributes=record.get('attributes') 
    status=attributes.get('status') 
    risklevel=attributes.get('risk-level') 
    message=attributes.get('message')
if (risklevel == 'HIGH' or 'MEDIUM and status == 'FAILURE'): 
    print('status: ',status,' risk level: ',risklevel, 'message: ',message)

Step 5: Save the file

Move to the hooks directory and save the ﬁle as either a post-commit hook, or as the appropriate hook template within the directory you want to use. This allows the hook to communicate remotely with the Template Scanner.

Step 6: Make the file executable

To complete the process make the ﬁle executable:

$mycode/.git/hooks> chmod +x post-commit

Step 7: Re-run the commit

$mycode>touch afile
$mycode>git add afile
$mycode>git commit -m "git hook testing"

running post-commit hook!
status: FAILURE risk level: MEDIUM message: Instance id EC2Instance is not using I
status: FAILURE risk level: MEDIUM message: EC2 instance EC2Instance is using defa
status: FAILURE risk level: LOW message: Detailed monitoring is not enabled for EC
status: FAILURE risk level: LOW message: Security group sg-96566228 has 1 rules wi
status: FAILURE risk level: LOW message: Elastic Network Interface eni-xfjp0yt3 is
status: FAILURE risk level: LOW message: Instance EC2Instance has [Environment, Ro
status: FAILURE risk level: LOW message: Network Interface eni-xfjp0yt3 has [Envir
status: FAILURE risk level: LOW message: Security Group sshsecuritygroup-7gsiog6zw [master 3c527956]

Committer: teratim <teratim@an-email-address.com>

Your name and email address were configured automatically based on your username and hostname. Please check that they are accurate. You can suppress this message by setting them explicitly. Run the following command and follow the instructions in your editor to edit your configuration file:

git config --global --edit

After doing this, you may fix the identity used for this commit with: git commit --amend --reset-author

1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 afile

The code executes immediately after a commit process. You can rework this example to include hooks at any supported point in the lifecycle. In-depth information is available at GitHooks.com.

Through Full Pipeline Integration (Mecca Case Study)

Full pipeline integration is best for organizations with DevOps practices that release large code bases or release code frequently, such as Mecca.

Headquartered in Australia, Mecca specializes in high quality cosmetics. In addition to an increasing number of physical stores across Australia and New Zealand, Mecca has found a high degree of success with their online presence. Mecca now employs a team of skilled DevOps engineers and developers to ensure they oﬀer the same high quality service to their online customers.

Trend Micro helped Mecca adopt Template Scanner to bake Shift-Left methodologies in the form of AWS Well-Architected best practices into its CI/CD pipeline and DevOps processes. The practices they put in place enable their DevOps team to operate autonomously, but with consistent and streamlined processes.

Mecca develops infrastructure in the same way their .NET developers develop code. Both sets of code follow the same workﬂow for development, peer reviews, build, test, and deploy. Mecca took advantage of Visual Studio Code and its extensions to write CloudFormation YAML templates more efficiently:

YAML indentation colors.
Sort lines to sort lines of text, which are useful for identity and access management (IAM) policy statements.
AWS CloudFormation Linter to detect any issues in the template, and to validate code in pull requests.

For their CI/CD pipeline, Mecca combined Atlassian Bamboo, AWS CodePipeline, and TrendMicro Template Scanner to ensure that IaC risks were detected early and mitigated appropriately.

Figure 4 – Mecca’s CI/CD pipeline.

Mecca’s pipeline is broken down into develop, build, and deploy phases:

Develop
- YAML template implemented and committed to Bitbucket.
- Pull request raised for validation and review.
Build
- Code merged to master branch following pull request approval.
- Bamboo polls the repository, detects changes, and triggers a build:
  - Validate the template for syntax errors.
  - Call Cloud Conformity API to perform security scan on the template.
- The artifact containing the template is uploaded to Amazon S3.
Deploy
- AWS CodePipeline detects a change in S3 and downloads the artifact.
- A test stack is launched:
  - If the stack fails to create, a notification rule triggers an alert via Amazon Simple Notification Service (Amazon SNS) to manually inspect the failure.
  - If the stack is created successfully, tear down the test stack.
- The pipeline then deploys to development, staging, and production environments, in that order:
  - Each environment deployment requires an approval for AWS CodePipeline to continue.

Conclusion

Shift-Left is increasingly being employed within DevOps organizations to ensure companies minimize risk early in their infrastructure as code deployment cycle. IaC services such as AWS CloudFormation make it possible to implement Shift-Left using a scanning product such as TrendMicro’s Template Scanner.

The combination of these technologies delivers immediate beneﬁt to any organization that is trying to deploy IaC with the AWS Well-Architected Framework.

For more information on Template Scanner, or how a Well-Architected Review can help your organization, reach out to your local AWS account team.

You can also visit these resources to learn more:

.

.

Trend Micro – APN Partner Spotlight

Trend Micro is an AWS Competency Partner. They help you build secure, ship fast, and run anywhere with security-as-code, continuous automation, and tools designed to secure applications across your evolving hybrid environment.

Contact Trend Micro | Solution Overview | AWS Marketplace

*Already worked with Trend Micro? Rate this Partner

*To review an APN Partner, you must be an AWS customer that has worked with them directly on a project.