A Case of Mistaken Identity and 5 Steps to Prevent It

A Case of Mistaken Identity and 5 Steps to Prevent It

Wait… Who Are You Again?

A couple of weeks ago, when I logged into a website provider’s admin panel, I found a strange user in my account with admin rights that I did not recognize! As you can imagine, this triggered all my alarms. I took a screenshot, removed their access, looked them up on LinkedIn, and contacted the provider’s support right away. They were a CEO of a boutique consultancy! Who was this person and why would they have access to my account? Very odd and disturbing at the same time. Could this be a bug with the SaaS provider’s IAM system?

Of course, 1st tier support couldn’t get me the logs or answer my question, so I asked for the security team. They kindly forwarded my request and said they would get back to me in a few days. Frankly, I didn’t expect my request to be forwarded or to hear back at all… but lo and behold, they responded (actually a Product Manager, not security)! After some authentication of my identity, they provided me the details of what transpired.

It turns out, when I invited my developer to the account, they were signed in as someone else! When they clicked the link, access was given to the account they were logged in to, not their actual account. Those pesky cookies!

Turns out, when I invited my developer to the account, they were signed in as someone else!

Root Cause

Two things went wrong here:

First, the developer was logged in as someone else. Tsk, tsk. #1 rule about identity management: no shared accounts! Every login ID should be tied to a human (if your dog or cat has their own email, please leave a comment below).

Second, the SaaS website provider does not tie the actual account access to the user. Instead, they send the user a public link, which anyone can access! This is somewhat old school and they should know better. I have since filed a bug report. Let’s see what they say.

Moral Of The Story: Trust… But Verify

5 Steps You Can Take Right Now To Prevent This

1. Ensure all user accounts are tied to an individual. No shared user accounts. Use 2FA on all accounts, or at least on higher privilege or high-risk accounts*.
2. Add notifications/tracking/audit trail whenever access is granted/removed.
3. Verify your access and permission work as desired (AWS IAM rules, for example, can be tricky).
4. Review access controls often (at least quarterly), especially for access creep.
5. Have a clean and documented onboarding and offboarding process. Standardize your roles; document and expire any exceptions (former employees and contractors can often have access for months and sometimes years).

*Shared accounts = high risk accounts.

Cloud Responsibly.

Yours,

—A

Ayman Elsawah – AWS Security Strategist

P.S. Need help trusting but verifying? Let’s chat! Email me at ayman@cloudsecuritylabs.ioand we can set up a time to talk, I love a good cup of coffee. Have a story to share? Comment below.

This article first appeared on LinkedIn on May 22, 2018.

If this article was helpful to you, consider subscribing to my weekly newsletter, where I share my latest commentary as a vCISO for high growth startups.

Check out how we help startups accelerate and level up their security programs through vCISO (CISO As A Service).