In my past life, I was an auditor and performed hundreds of cybersecurity readiness assessments. These were sometimes called “gap analysis” and the essential purpose of these assessments were to provide organizations with the answers to the test for their upcoming official assessment. One of the first questions I would ask and observations I would perform is whether all privileged users enabled multi-factor authentication (MFA) to access the production AWS accounts.
Like the rest of the world, the majority of my clients were hosted on AWS. One of the first items I would ask for is the AWS IAM credential report to review the MFA status of all users with access to the production account.
Unfortunately, it was common to see multiple users without MFA enabled. This issue presented itself during official or formal assessments as well, resulting in deviations or findings being displayed in their reports. These reports are presented to prospective customers and current customers during vendor due diligence activities.
This finding is avoidable, specifically on AWS and I am sure on the other major CSPs. These organizations cared, they were great security people. They culturally required MFA in most cases, users would sign acceptable use policies and information security policies that say they must use MFA.
The problem is they left the decision to enforce this configuration up to their users. A recurring cybersecurity threat will always be humans and often the humans in your organization. Some organizations have flexible policies that allow new users to configure MFA within their first week or no defined time frame at all.
New users are eager to get to work and sometimes miss key items like enabling MFA, I do not think they are to blame.
Security teams should implement the basics to set their users up for success.
On AWS you can reduce this risk by configuring a Force MFA IAM policy that requires all users to sign in to the AWS console with MFA. If they do not sign on with MFA, they will have their normal permissions revoked and only be able to enable MFA.
In this 10 minute video below, I demonstrate how to implement this force MFA policy on your AWS account (watch on 2x and it’s only 5 minutes).
If you are not a video type, check out this AWS blog that outlines step by step instructions to implement this crucial security configuration (however, the policy in this link is missing a required action element for the policy to work).
Why does this matter?
Alleviating the administrative burden of managing MFA for all new users helps your system administrators and security engineers focus on things that matter. Chasing down new users to enable MFA might work when you are a team of 10 or 20.
However, as you scale your organization you will have to automate security best practices and use technology to enforce your policies. This IAM policy is an example of taking an automated approach to security best practices and eliminating the human threat vector associated with MFA misconfigurations.
Compliance assessments are not fun, they are often draining and cause a lot of heartburn. This discomfort is exacerbated when these assessments result in a “failure” or “deviation” identified because of preventable security flaws.
Wherever you can reduce or eliminate the potential for a finding in your assessment, you should immediately take those steps. This policy helps reduce evidence requests from your auditors as well, freeing up your team to protect your systems instead of capturing outdated screenshots.
