AWS Security: Make Sure Your Share the Responsibility

When evaluating the security of your infrastructure in the AWS cloud, it’s important to understand the security measures AWS implements and the security measures you are responsible for with their Shared Responsibility Model. What many businesses think they are doing versus what they actually do can be very different—and may actually be at odds with each other.

That’s because even if you understand the security aspects you are responsible for, executing correctly on those defense measures is a complex task. You may be leaving a huge gap in your security defenses without even realizing it.

The Shared Responsibility Model: What Does AWS Do? What Should You Do?

While AWS manages the security of the cloud itself, the security of the applications and the data in the cloud is the responsibility of the customer.

While AWS provides many security tools to choose from like IAM, CloudTrail, Certificate Manager and Security Groups, their implementation is optional. Customers need to take the necessary steps to protect their content, platform, applications, operating systems and networks no differently than they would in an on-site datacenter. It’s tempting to think that moving to the cloud freed you of these worries, and it’s true that you do get a lot of benefit from Amazon’s security measures. But much like how you’re responsible for the security of, say, your actual credit card, you are still responsible for contributing to the security of your IT infrastructure.

Before signing up for our Managed AWS Cloud service, one of our clients deployed a Jenkins open source automation server in their AWS environment. They soon forgot about it after a few months and did not realize it was running an outdated version of Jenkins. A hacker gained access through this vulnerability and hijacked the server to mine for bitcoins.

Jenkins servers in particular require up-to-date security because they are used to manage other servers and often have access permissions to those servers. In this particular case, ingress traffic was open to the Internet on port 8080, allowing outsiders to access the OS. Fortunately for our client, all the hacker tried to do was mine for bitcoins, as opposed to stealing data or compromising their infrastructure. During our initial monitoring of the client’s system, we immediately caught the security hole and patched the server before any further damage was done.

Cloud Security Guidelines: Full Length & Cliffs Notes

To help customers fulfill their responsibilities in the Shared Responsibility Model, AWS has published a 99-page white paper identifying the necessary steps for each AWS service. Working your way through this lengthy document may cause headaches, but as a starting point, we recommend five high-level best practices:

1. Apply major security patches regularly
2. Update operating systems on an ongoing basis
3. Use encryption to protect data in-transit and at-rest
4. Verify your backups work properly
5. Lockdown security groups to allow access only to authorized users

Unless an application is user-facing, there’s no reason to open any security group to the Internet, which gives anyone access. Surprisingly, many businesses do this without realizing it by misconfiguring their VPCs.

Tips to Make Sure You Share Your AWS Security

For additional help in simplifying your role in AWS security, here are a few other high-level tips to follow:

Any user-facing applications should connect to a load balancer—not directly to a server. This enables you to detect and manage unusual behavior before it becomes an issue.

When it comes to encrypting data, server-side encryption is important, but also be sure to apply client-side encryption, where you manage a local key and encrypt data before it’s stored on AWS. The key can then be used again when a user pulls the data down to decrypt the data.

Another powerful security tool in the AWS arsenal is Identity Access Management (IAM)—if it’s used correctly. It’s still up to you to make sure users have only as much access as they need and don’t have extra workload permissions.

It’s also up to you to configure the groups and roles for server access. If something goes awry and a hacker gains accesses to a server, database or memory cache, it’s critical to make sure they do not have access to everything on your network and can’t add/delete users and privileges. You also need to make sure they don’t have access to root accounts.
With IAM, it’s possible to block all this from happening—but you gotta get it right!

Tap Into the Right Cloud Security Expertise

There are several other protective measures you can take—such as deploying a web access firewall—but it usually comes down to relying on the right expertise. AWS security requires a specialized set of skills that most software developers are not trained in.

One of the more common security holes we come across is developers leaving port 22 open to the Internet on the secure shell protocol servers they often use to transfer files, tunnel traffic and mount remote file systems. Hackers who find these servers can use scripts to send thousands of requests to the port in order to try to log in or crash the server.

Security in the cloud differs somewhat from security in on-premises data centers. and knowing where those specific differences are is essential. You need to finding a partner that specializes in security in the cloud as they are key to protecting your AWS infrastructure today and in the future. Be sure to team up with one that really understands the entirety of the AWS Shared Responsibility Model!