Achieving DevSecOps using AWS Cloud Native Services

July 3, 2019

In our previous article Achieving DevSecOps using Open-Source Tools we explored what “DevSecOps” really meant and how that can be achieved using simple Open-Source tools integrated into an existing DevOps pipeline orchestrated with Jenkins and deployed on docker in an ad hoc on-premises architecture.

In this article Rohit Salecha and Anand Tiwari explain how DevSecOps can be achieved for an environment which is completely operated on AWS and their native offerings.

Before jumping on to DevSecOps let’s list down an all native DevOps environment in AWS.

Illustrative DevOps on AWS

AWS DevOps

The above diagram illustrates the various native AWS services that can be used for CI/CD automation on AWS

AWS Services Detailed:

Integrating Security in AWS

AWS provides a lot of security tools in native cloud format, however, those tools generally focus more on monitoring and reporting, thus, requiring us to deploy and use and our own tools to address other areas.

Integrating security in an AWS environment will take similar steps as required in an On-prem environment like integrating a code analyser tool in SAST (static application security testing) or a dependency checker in the SCA (software composition analysis) as also seen in the previous post.

The configuration of various tools in AWS environment for execution will be different.

In an on-prem model tools can be downloaded at will and executed in a script or a docker container. However in cloud, as billing is generally on usage, download incurs extra charges and hence the strategy with using these tools in AWS would be to create a tools repository using an S3 bucket and referencing this S3 bucket in each “buildspec.yml” file. Each stage will have its own “buildspec-<stage>.yml“ wherein the tools would be fetched from the internal S3 bucket and executed. Below is a sample “buildspec-sca.yml” file for the SCA stage performing dependency-checks.

buildspec.yml

These tools will be needed to be updated regularly for which we can employ a Lambda function which would periodically check for new versions.

If the tool is compatible with the AWS Lambda specifications, then converting the tool as a Lambda service would be an exceptionally great task and for vulnerability management that is exactly what we have done. We have deployed Archery as a Lambda service which is activated only when a tool requires to push vulnerability data into it.

The below diagram is an illustrative example of an AWS DevSecOps pipeline.

AWS DevSecOps

Due to the shared responsibility model (shown below) a large chunk of responsibility lies with the service provider, however,  there are a few areas which remain with the tenant. In all essence most of the vulnerabilities associated with the environment would tend to originate from misconfigurations.

Cloud Shared Responsibility

In addition to these security misconfigurations there are other issues associated with AWS services like AWS access key compromise and exploiting billing caps. Let us understand the complete AWS Threat landscape in more detail.

AWS Threat Landscape

Below are the issues describing the complete AWS threat landscape

Access-Control Security Misconfiguration

In AWS, access control is managed through the IAM Policies. A policy is an object in AWS that, when associated with an identity or resources, define their permissions. If an EC2 object needs to access an S3 bucket, specific permissions are needed. An oversight or granting of excessive privileges can lead to various scenarios where S3 buckets have public access leading to a possible leakage of sensitive information. A curated list of all S3 Bucket leaks can be found here https://github.com/nagwww/s3-leaks

Another instance was where a single administrator user was configured to access all the AWS resources which upon falling in the wrong hands lead to complete wipe out of that company.

These issues arise due to lapses in access control policies and permissions.

It is extremely necessary to regularly check for the permissions assigned to each resource.

PMapper tool, a utility that enables users to view IAM permissions in AWS, can be utilised to provide a graphical representation of all the permissions assigned to different resources and users. We ran this tool on our AWS DevSecOps lab and the graphical result is shown below.

PMapper

Other than that , AWS S3 Inspector is a tool which can be easily integrated into your DevSecOps process which would check and alert if any S3 bucket in your account is having a public read/write access.

Below user guide consists of best practices recommended by AWS. This is worth practising.

AWS IAM Best Practices

Network Security Misconfiguration

The diagram below shows a typical flow of network traffic and the different places where it can be tapped. Security Groups are like host-based firewalls for individual EC2 instances. Network Access Control Lists (NACL) can be configured for a group of EC2 instances. Route Tables are configured for routing traffic amongst different networks and finally we have VPC’s which are the final overarching network segmentation module connected to an Internet Gateway.

AWS Network Security Configuration

It is very much possible to have misconfiguration in such complex infrastructure. For Ex: A ThreatStack report states that of all the companies they analysed, 73% of companies had SSH port open over the internet.

Securely managing the configuration issues be it network configuration or permissions is not something that can be done with a click of a button. It requires mix and match of different tools and dedicated resources. Below section focuses on various tools offered by AWS as well as some other open source tools that can be utilized.

AWS Security Tools and Services

Below table describes various tools and their purpose.

AWS Security Tools

Updated Illustrative AWS DevSecOps Diagram

AWS DevSecOps Pipeline

AWS IAM Keys Leakage

In AWS if an EC2 instance needs to access an S3 bucket, proper IAM roles needs to be configured. IAM roles are permissions between AWS services which are different than user permissions. Hence if a service needs programmatic access to AWS resources then it needs a set of AWS access keys which can be obtained from this metadata URL https://169.254.169.254/latest/meta-data/iam/security-credentials

There are two ways in which these keys can be leaked/exposed

AWS IAM keys leakage can be prevented by employing pre-commit hooks like Talisman which detect for such information before developers can commit changes into a repo.

Alternatively, tools like truffleHog could be employed periodically to check for any exposed credential in a code repository.

Some best practices around protecting the AWS access keys can also be employed like rotating the keys, deleting previously used keys, limiting access to resources etc.

Exploiting Billing Caps

If your AWS keys are compromised the very first thing that attackers would do is setup EC2 instances and start bitcoin mining.

AWS Billing

Not just that but let’s consider the cost of running DevOps on AWS

AWS Pricing DevOps

Here is the cost breakdown of using S3 Buckets.

AWS S3 Bucket Request Pricing

The key point to understand here is that it is not just storage costs, but also “Per Request” costs that need to be considered.

One of the best practices while using AWS is to create billing alerts for your AWS accounts so as to protect yourself from being overcharged.

We have reached a point where we have implemented most of the security controls in the DevOps pipeline, leveraging most of the cloud native features provided by AWS and augmenting them with open source tools where required. This can help cloud native organizations to get a better understanding of how DevSecOps can playout in their environment. This obviously is not the only solution and different organizations can tweak this to their own preferences. Also cloud service providers can come up with new services in the future which can negate the need of open source solutions.

Checkout our Video giving a running snapshot of our discussion on the blog.

<marketing>

We cover this as well as on premise solution in much more detailed format in our DevSecOps class https://www.notsosecure.com/hacking-training/devsecops/. If you or your organization is interested, feel free to contact us for in house trainings or attend our upcoming public classes details of which can be found here https://www.notsosecure.com/hacking-training/DevSecOps/#upcoming

We also provide bespoke consultancy to help organisations adopt DevSecOps practice. To find out more please get in touch:

https://www.notsosecure.com/contact/

</marketing>

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Trackback