avatarTeri Radichel

Summary

Teri Radichel discusses strategies to mitigate the lack of multi-factor authentication (MFA) enforcement when switching roles in AWS SSO (Identity Center), emphasizing the importance of MFA and segregation of duties to secure sensitive assets.

Abstract

In a recent article, Teri Radichel addresses a significant weakness in AWS SSO (Identity Center) concerning the absence of mandatory multi-factor authentication (MFA) when switching roles. This oversight can potentially allow attackers to access multiple accounts if they gain control over a user's SSO session. Radichel, through her experience with IANS Research customers, highlights the convenience of AWS SSO for managing numerous accounts but also points out the security risks associated with it. She suggests interim solutions such as requiring separate MFA-protected logins for sensitive assets and designing processes that enforce segregation of duties. Radichel also explores the use of AWS IAM for enforcing MFA and considers alternative identity providers like Okta. The article emphasizes the need for a comprehensive approach to security that limits the impact of compromised credentials and prevents the exposure of sensitive assets.

Opinions

  • Teri Radichel values the insights gained from customer interactions, which help her address security aspects from different perspectives.
  • She acknowledges the convenience of AWS SSO for managing multiple accounts but is critical of its security shortcomings, particularly the lack of MFA enforcement during role switches.
  • Radichel is in favor of using AWS IAM for its ability to enforce MFA when switching roles, which is currently not possible with AWS SSO.
  • She advocates for the use of separate logins with MFA and short session durations for sensitive assets, despite it partially undermining the SSO concept.
  • Radichel promotes the principle

Getting Around One of the AWS SSO (Identity Center) Weaknesses

ACM.225 Designing AWS Identity Center Permission Sets and Policies

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

⚙️ Check out my series on Automating Cybersecurity Metrics. The Code.

🔒 Related Stories: Cloud Governance | IAM | AWS Security

💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I love all the questions I get on consulting calls with IANS Research customers because it helps me see things from different angles I may not have clearly addressed before. Although I’m not using AWS SSO (Identity Center) in this series, I’ve written about it before and a lot of people are, so I wanted to address this one.

Let’s say that you are using AWS SSO. It is nice to be able to click on a dashboard and get to any account to which you have access. I’ve managed upwards of 70 accounts in the past so having that cross account access definitely makes your job easier.

However, along with that positive comes a downside. There’s no MFA requirement when you switch roles. The issue is that an attacker who gains access to your browser or your SSO session in general can also switch to any other account.

I wrote about various attacks that leverage IAM in prior posts.

One good aspect of this account switching is that you can only access one account at a time. If you switch to another account you are reauthenticated to the new account. However, if you leave that session active and go off and do something else an attacker with access to your SSO session can switch around between accounts and access the full set of permissions you have across all accounts.

Similar concepts appear in the latest Circle CI and LastPass breaches. Access to a developer machine alone granted broad access including production resources. There is, at the time of this writing, no mechanism for you to control the trust policy and enforce MFA when switching between roles. Hopefully AWS will fix that soon.

I’ve shown you in this series how I enforce MFA when switching roles using AWS IAM. It’s also easy for me to enforce MFA for cross-account CLI access using AWS IAM and that’s currently not possible with AWS SSO.

In the meantime, let’s say you are stuck with AWS SSO or you like some of the benefits it offers. You want to continue to use it. How can you address this weakness?

It’s not ideal but you can require users to have separate logins for your most sensitive assets. You require them to login with MFA to access those sensitive assets and make sure the session is very short. That kind of defeats the purpose of SSO right? But you can use SSO for things that are less critical and limit this requirement to your most sensitive assets.

You may also design processes with segregation of duties as I’ve shown you how to do in this series. Design your processes to require two people to carry out a sensitive action. I showed you in prior posts how to design a process to create a new account that requires two separate sets of permissions, for example.

You could also take steps to limit concurrent sessions with access to production and non-production resources. How? The easiest solution from an implementation standpoint would be to have the developers login to a separate machine on a different network to access production resources. You could use bastion hosts, including the concept of a developer bastion host as I wrote about here and then a separate bastion host in a different account and/or network for production assets.

The key when architecting solutions is to consider:

  • What can an attacker access if they obtain a set of credentials?
  • How can you establish trust boundaries so access to one set of credentials does not offer up the keys to your kingdom?

Various security controls have pros and cons, strengths and weaknesses. The trick is to understand how they work and design accordingly to prevent successful compromise of one security control from exposing sensitive assets.

For the moment, I’m still exploring simplification of the use of IAM to enforce MFA when switching roles. I’m also exploring Okta but not through assessing Okta security. The solutions in this post on AWS Identity Center work arounds do not help me enforce third-party MFA upon role assumption using the AWS CLI. I wrote about that issue here:

I also don’t like the way AWS SSO works with the AWS CLI for the reasons described above.

Based on the questions I got today, I definitely have some more thinking and writing to do on related topics!

Follow for updates.

Teri Radichel | © 2nd Sight Lab 2023

About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight Lab
Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation
Follow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab
AWS
Identity Center
Sso
Permission Sets
Roles
Recommended from ReadMedium