Here we are, a week later and now following up on to the second installment of our recommended Top Ten Security Best Practices for AWS. In last week’s Account API Access Key blog post, we recommend that you make at least two, no more than three, IAM users to replace the root AWS user.
Two helping prevent you from a Single Point of Failure (SPOF) and limiting it to three keeps it from getting out of control, but that will be covered in more depth next week. This week we are going to talk about Multi-Factor Authentication (MFA) what it is, why you want it, where you need it, and why your business is at increased risk without it.
So, now that you have IAM users and disabled your root account, let’s talk about Multi-Factor Authentication (MFA.) What is MFA? Well, “…a simple best practice that adds an extra layer of protection on top of your username and password” is how it is described on the AWS MFA page.
While this is where you can learn more about how to configure it on AWS, what is it? Simply, it is a layer of security that requires more than one form of authentication. So, your password could be one form of authentication and anything in addition to that would qualify as an MFA. Security, simplified.
MFA is commonly provided by the addition of a second physical or virtual device that is separate from your username/password combo. These devices generate random values to supplement the basic username and password combination, thus helping to ensure you are you.
While it is pretty common to see physical tokens dangling on key chains in places where technology companies flourish, now many people also have an app on their mobile devices (probably because they are more likely to have it nearby and may be less likely to lose it.)
In addition to alphanumeric values, biometrics continues to gain popularity, with many devices scanning various aspects that uniquely identify us such as our retina, fingerprints, etc.
Why the extra layer of security? Ever been to an event where you sat in theater style seating with people behind you? Ever watched the person in front of you thumb their password into a mobile device while ordering a latte? What about those video cameras, seemingly everywhere, watching us now? How long before your local traffic camera can read the VIN number as you drive by, if not already?
Look around you, there is a good chance someone else can see and record what is happening. This is not just for the chance you might use the local library to check email anymore.
Basically, usernames and passwords in and of themselves are not that hard to compromise. Just look at the recent headlines of large and small companies that were impacted by the loss or compromise a username and password. This is extending to include everyone, not just people with elevated privileges, but nearly anyone or anything that has access to data.
As an example, consider what your username and password allow you to do or see? Any risk to you or your company if that were to find it’s way to the top of a popular search engine? There are also numerous accounts of both user and application credentials being caught in popular public source code controls.
Keep in mind that AWS Identity and Access Controls may provide access to not just the infrastructure, but the applications installed and the data being used.
There is also a nearly combative challenge between some more traditional security practices where the powers that be keep increasing the minimum password length, complexity requirements, shortening the time between password changes, or some combination. While these practices look good on paper, and may get you a compliance check box filled, in reality, they may drive actual users to the opposite behaviors.
Some popular examples are storing passwords in an email or text message (today’s version of writing it on the keyboard or monitor,) using a rotation pattern with a series of similar passwords, incrementing a password by just adding a number, or bracketing an easily remembered word with special characters.
These behaviors are most likely not what those powers that be had in mind. In these examples, increasing security requirements actually resulted in more security gaps, gaps that are challenging for you to identify and close before they are exploited. How many of your corporate passwords might be floating in an users personal email account, outside of your business controls?
Given the potential risk, and undesirable outcome, adding another layer of security here just makes good business sense. Let’s be honest, a realistic password policy with an added extra layer of security on top of it helps the business, the users, and you stay secure, right? So how do you do it on AWS?
In the world of AWS friendly MFA, first you need a physical or virtual device that is supported. Again, the AWS MFA page is a good starting point for a list of compatible devices. Not every MFA is supported by AWS, so check first. When choosing an MFA, consider both how it will integrate into your workflow and how to recover from its loss, as they do get lost and mobile devices do get replaced.
AWS has provided a great three part series on setting up and using MFA for:
- User Console – Securing-access-to-AWS-using-MFA-Part-I
- Programmatic API Access – Securing-access-to-AWS-using-MFA-Part-2
- S3 Versioning – Securing-access-to-AWS-using-MFA-Part-3
Please review these guides and with each layer of security you embed in your people and process, you help prevent your business name from making tomorrow’s headlines as an example. You also want to make sure you have a disaster recovery plan that includes provisions for the security options you have chosen to implement.
If you have any questions about implementing MFA, please do not hesitate to ask for help.
A quick recap of our past AWS Best Practice posts:
- Disable Root API Access Key and Secret Key
- Enable MFA Tokens Everywhere
- Reduce Number of IAM Users with Admin Rights
- Use Roles for EC2
- Least Privilege: Limit what IAM Entities Can Do with Strong Policies
- Rotate all the Keys Regularly
- Use IAM Roles with STS AssumeRole Where Possible
- Use AutoScaling to Dampen DDoS Effects
- Do Not Allow 0.0.0.0/0 Unless You Mean It
- Watch World-Readable and Listable S3 Bucket Policies