Loading...
You are here:  Home  >  Data Education  >  Data Architecture News, Articles, & Education  >  Data Architecture Blogs  >  Current Article

Amazon Web Services Provides the Tools, But it Won’t Secure Your Data for You

By   /  February 21, 2018  /  No Comments

Click to learn more about author Brad Thies.

In what’s become a frighteningly frequent occurrence, another unsecured Amazon Web Services (AWS) S3 bucket has jeopardized hundreds of millions of customers’ personal data.

Companies share security responsibilities with their Cloud service providers. While AWS and other CSPs must provide identity and access management tools, among others, they can’t control how clients use those tools. They can’t stop organizations using their Cloud platforms from spilling users’ sensitive information across the web.

Often, breaches occur because Cloud clients fail to properly configure or upkeep their Cloud environments. That isn’t to say that Cloud service providers never make mistakes, but the great majority of breaches could be prevented with the following best practices.

Basic Security Protocols

  1. Strengthen Root Account Setup

Using root access might seem easier, but the risks aren’t worth it. Don’t generate an access key for your root account. You probably won’t need one, but if you do, lock away root user access keys and never use that account to access AWS. Any regular access should go through unique user accounts, which are protected by identity and access management protocols.

  1. Implement Role-based Access Control

Any Cloud security program should limit access according to the user’s role. Assign permission to groups, not individual user accounts. Generally speaking, users should only have access to the data they need to do their job.

Try a tool like Access Advisor, which can show user activity over time, highlighting which permissions are used by which accounts. Overlooking RBAC in the beginning is easy, but as the company grows, cleaning up RBAC becomes more difficult — and the consequences of a breach become more severe.

  1. Use Multifactor Authentication.

One organization recently suffered a breach on Azure, an AWS equivalent, that could have been avoided with proper MFA implementation. In fact, eight in 10 hacking breaches happen because of weak or stolen passwords.

MFA is easy to set up and keeps AWS system resources safer than single passwords. With MFA, a would-be hacker needs to acquire an accompanying phone or token device in addition to the password in order to access the account.

Make MFA an across-the-board rule for anyone accessing AWS. You can choose in AWS’ settings to enforce MFA sign-in through a managed policy rather than make it optional. Beware of using SMS-based MFA, however, which the National Institute of Standards and Technology has declared insecure.

Maintenance and Housekeeping

  1. Rotate Access Keys

Most users rarely, if ever, log in to the AWS console. Access usually goes through programmatic requests or API services. Over time, tracking access keys becomes more difficult, so rotate keys at least annually (or even better, quarterly) for both human accounts and automated services.

Some companies fail to rotate keys because they don’t appreciate the dangers overused keys pose. AWS makes it easy to trade keys, but like any security measure, it’s easier to start rotating early than to implement rotation later.

  1. Harden and Patch Infrastructure

AWS won’t set up a bastion host for you, disable root API and secret keys, or password protect .pem files that authenticate powerful accounts. You are in charge of these security steps.

Don’t assume, that a standard Linux or other third-party server image will meet your individual security requirements. The Center for Internet Security offers excellent resources on standard hardening of different infrastructures. In particular, don’t forget to regularly check for and install new infrastructure patches, which plug known holes that hackers could take advantage of.

Preventative and Detective Measures

  1. Log Resources, Especially S3

S3 storage interfaces are choice attack points. Although S3 makes it easy to connect, store, and retrieve data, those same functions make it appealing to hackers.

AWS offers tools to safeguard S3, but again, it’s up to you to use them. Implement alarms for S3 bucket changes, which could minimize accidental bucket exposures.

  1. Forbid services from Directly Accessing the Internet, Particularly Secure Shell.

SSH is often used to facilitate remote login, which can give hackers their “in.” Fortunately, AWS makes it easy to establish groups and virtual private networks within your infrastructure. Use these tools to disallow ingress network traffic from using stateful security groups.

If you must allow online traffic, allow it only from whitelisted visitor IPs and ensure transport security from a secure sockets layer. For added security, arrange for an internal virtual private network with a company-provided client certificate. Remember to add a MFA mechanism, a mobile app. Then, only allow the source IPs of the VPN server to connect to internal applications.

When used well, AWS is a highly secure platform. It’s up to you, however, to make use of the security tools it provides. Compromising millions of users’ personal data — not to mention all the fallout that follows — is an awfully high price to pay for lax Cloud controls.

About the author

Brad Thies is the founder and president of BARR Advisory, an assurance and advisory firm specializing in cybersecurity, risk management, and compliance. BARR helps cloud service providers and enterprise clients understand, meet, and communicate their shared security responsibilities. Brad speaks regularly at industry events such as ISACA conferences, and he is a member of AICPA’s Trust Information Integrity Task Force. Brad’s advice has been featured in Entrepreneur, Cloud Computing Journal, Small Business CEO, and Information Security Buzz. Prior to founding BARR, Brad managed KPMG's risk consulting division. He is a CPA and CISA. Follow Brad and BARR Advisory at: Twitter, LinkedIn

You might also like...

All Aboard the Prescriptive Analytics Express

Read More →
We use technologies such as cookies to understand how you use our site and to provide a better user experience. This includes personalizing content, using analytics and improving site operations. We may share your information about your use of our site with third parties in accordance with our Privacy Policy. You can change your cookie settings as described here at any time, but parts of our site may not function correctly without them. By continuing to use our site, you agree that we can save cookies on your device, unless you have disabled cookies.
I Accept