As DevOps has become mainstream, many organizations are going further and adopting DevSecOps, and integrating security into their SDLC. This often raises many practical issues, especially concerning implementation strategies for the specific CSPs (Cloud Service Providers) being used.

Two years ago, we wrote about using DevSecOps on AWS, which is an important part of AWS security. While most of those strategies are still solid choices, additional capabilities have naturally become available since then. 

In this article, we’ll build upon our previous articles and discuss some other approaches you can take to secure your AWS cloud infrastructure from potential attackers and dangerous misconfigurations.

AWS Organizations

Master Account

In AWS Organizations, you can choose an AWS account to be your master account, which can then spawn multiple other AWS accounts that are subject to that first master account. This means that all the workloads of your organization can be split into single AWS accounts, which would then be shared by teams working in the same part of an organization. 

This strategy improves your overall security posture. Although it won’t actively prevent security incidents, it can limit the blast radius of breaches (like compromised AWS keys) to a small part of the infrastructure, stopping potential attackers from privilege escalation.

Policy Types

AWS Organizations also allows your DevSecOps engineers to create different types of policies. These include service control policies (SCPs) and management policies. 

SCPs allow you to limit the actions that members of an AWS account (users, groups, and roles) can do. While this still requires IAM policies to be attached to these members, it can limit what these policies are and what they do, providing granular control over services inside every account under your master.

Management policies can be divided into backup policies, tag policies, and AI services opt-out policies:

• Backup policies help in managing and applying backup plans to any AWS resource located in the organization’s accounts. 
• Tag policies assist in standardizing tags attached to those resources.
• AI services opt-out policies allow you to opt out of data collection when using some of the AI-powered AWS services, like Textract, Polly, Translate, and Lex, among others.

AWS Control Tower

It might seem that dividing and managing multiple AWS accounts might consume more time than the benefit gained, but AWS has addressed this concern. AWS Control Tower can act as a hub for all of your different accounts, creating a “landing zone” to help you create and manage new AWS accounts in a couple of clicks, making sure they all adhere to previously configured org-wide policies.

AWS Systems Manager

AWS Systems Manager serves as “the operations hub” for all of your organization’s AWS applications and resources. The unified UI lets your DevSecOps team analyze your environment, investigate and remediate issues, or provide your infrastructure with a centralized store to manage configuration data, among many other things. For this article, we’ll focus on Incident Manager and Change Manager.

Incident Manager

Inside the AWS Incident Manager’s console, you can create and customize response plans that take effect whenever there are performance, availability, or security issues with your application or workflow. This can be useful if any new change in the environment presents a security vulnerability that needs immediate addressing.

Incident Manager can then execute those plans to inform first responders via SMS or email, roll back any breaking changes to their latest working version, and log any relevant metrics. Plus, it can provide suggestions for post-incident actions to take, such as adding a new alert or automating a step in the runbook.

Change Manager

AWS Change Manager simplifies the way you can implement changes in your account’s configuration and infrastructure, providing a way to create “change templates” that help avoid unintended results while making operational changes (like changing IAM policies). It can provide increased accountability by alerting your DevSecOps team to any intended but potentially dangerous changes within the account. This way, no such changes can make it through the predefined workflow, which helps prevent potential security breaches.

Shift-Left Linting and Testing

To “shift-left your security” means to integrate security earlier in the development cycle and not just leave it as the last part of the process. There are various strategies for this, such as having developers use secret-detecting tools and alarms in their code-editing software; integrating code-scanning and secret-scanning tools (like GitHub’s CodeQL for GitHub Enterprise users); utilizing AWS CloudFormation Guard, which lets you create and implement rules that enforce compliance locally and in the CI/CD pipelines; and implementing permission-boundary policies that provide a maximum set of permissions an IAM entity can grant to another entity.

To go along with this, you can utilize an open-source tool like Checkov to scan your infrastructure as code (IaC) and detect security-breaking misconfigurations before they’re deployed. The good thing about Checkov is that it works with AWS CloudFormation IaC templates, as well as Dockerfiles for Amazon ECS and ECR, Terraform files, and Kubernetes configurations for Amazon EKS—meaning you have plenty of flexibility when it comes to choosing the best way to deploy your application environment.

Bastion Solution for Server Access

Also called an SSH jump host or jump server, this solution requires little set-up and delivers more robust security, along with less attackable surface area within your environment.

A jump host consists of a public server that acts as a gateway to your other servers or microservices. This way, you can create a network of EC2 instances in a private VPC subnet that can be accessed via SSH from a public VPC subnet, where your bastion host will live. The best practice here would be to have this server isolated from any other public resource that needs to live on a server and reserve it solely for proxying authorized requests to your private network.

This solution requires minimal set-up, and there is no need for extra dependencies since you’ll most likely already have everything you need inside your EC2 instances. You’ll only have to make sure that your public SSH keys are well-configured and distributed inside your environments, and you’re good to go. 

If we assume your jump server is proxy.example.com and the VPC is hosted at 10.0.0.2, then all you need to do is run this command:

$ ssh -J proxy.example.com 10.0.0.2

The -J flag tells the OpenSSH client inside your instance to use the first host as a jump for the second host. 

Next, you would need to harden the access to the jump server for regular users by not letting them execute commands inside it, thus disabling interactive sessions and forcing the jump to the private network. This can be done by modifying the /etc/ssh/sshd_config or ~.ssh/config files inside your instance. The latter can also house host lists for easier and faster command line access. You can learn more about how to do this here.

Another way of hardening the access to the jump server is leveraging Session Manager, a feature of AWS Systems Manager. One of the benefits it provides is managing whether inbound ports into your host are open or closed, freeing the user from managing SSH keys and the bastion host itself. Another benefit is that it uses policies to control via IAM who can SSH to instances and which instances they can see. This solution is provided by Amazon EC2 Instance Connect officially, or by aws-ec2-ssh’s public repo.

Summary

Not all of the above DevSecOps strategies will be suitable for everyone and all needs. But knowing about them and how to combine them will result in a more secure AWS infrastructure for your organization—with easier monitoring, better logging, faster reaction times, and fewer security breaches. You can also combine all of these strategies with those described previously in our articles on AWS security.

Along with these tactics, it’s also important to use a WAAP (web application and API protection) solution for your workloads. Reblaze is a fully managed protective shield for sites, web applications, and APIs, providing a web application firewall for AWS and running natively on it. 

Reblaze is a comprehensive solution, providing a full suite of security technologies based on multivariate analysis (including a next-gen WAF, DDoS protection, API security, Account Takeover prevention, and more). It excludes hostile traffic with whitelisting, blacklisting, fine-grained ACLs, behavioral analysis, and UEBA based on machine learning, all in a fully managed service. Use Reblaze to protect your workloads, so you can focus on growing your business, not on having to defend it.For more information or to get a demo, contact us here.