The MGM hack this past week shows just how fragile people can be as a vector of attack. Although much of what I’m about to discuss is speculative, my proposed solution could potentially address what I believe was the issue at MGM and perhaps at other companies as well.
Hackers claim that they breached the system with just a 10-minute phone call. Prior to that there was some sleuthing done on LinkedIn to find a person to impersonate. With just those two pieces of information, it’s easy to speculate as to how the attack went down.
Impersonator: “Hi I’m [Employee Name] and I’ve lost my phone so trying to set up a new one and get 2FA configured. Can you help?”
Help Desk: “To confirm you are [Employee Name] could you let me know your department name and manager”
Impersonator: “Sure it’s…”
Help Desk: “Great, and your date of birth?”
Impersonator: “Yep, it’s MM-DD-YYYY”
Help Desk: “Thanks! Alright, I can help reset your 2FA – could you give me a good phone number.”
[Additional conversation continues]…
You get the idea, and I’m sure this is how many help desks at large businesses operate. Given the impracticality for the help desk to recognize every employee, and considering our increasingly remote work environment, in-person resets are also unfeasible.
So, then, how can this be made more secure? For these rare, typically isolated events requiring a full reset, I propose a two-person authentication system.
Two-Person Authentication (2PA)
While a help desk cannot know every employee personally, that employee’s manager can.
A hacker could easily find a target to impersonate and gather every piece of information they might be asked if given enough time. Social security number, managers name, kids names, spouse names, last vacation, how long they’ve worked there, even spoofing the phone number. The list is extensive. However, hackers would find it challenging to impersonate a second individual.
In the case of two-person authentication, a user is locked out. They call the help desk to explain their situation. The help desk can then contact the user’s manager or other trusted peer to verify the story and gain approval to reset the locked out user’s credentials.
This slows down the process, yes, but it also adds a significant hurdle for the attacker. Now their attack vector must also find an absent-minded manager who approves everything, or somehow work to impersonate that manager down the line too.
Given that a complete reset of a user’s credentials could be a massively compromising event though, the additional wait and slowdown in the process might be worthwhile. It’s especially worthwhile when the alternative is having guest locked out of rooms and a $30M fee to put things right.
Thinking Through The Policy
I should mention that at the time of writing, this is more of a “quick thought” rather than a thoroughly considered idea. Still, I can’t see any obvious flaws outside of time-to-restoration and an out-of-office manager.
Let’s start with the simplest scenario—an out-of-office manager. It should be relatively simple to find a close peer or manager of the manager to escalate this to. We’re talking about a locked out employee, something that should infrequently occur – so it shouldn’t end up adding tremendous burden onto others.
If restoration time is a concern, one could argue that the real solution lies in not forgetting or misplacing credentials so frequently.
The issue of restoration time could also be addressed through a Service Level Agreement (SLA). Perhaps it’s 1 hour. If no response within an hour from the manager, note that, and provide access to the locked-out individual.
The approval itself would be rather simple. A quick message to the manager saying, “X lost their access—do you approve restoration?” could be swiftly answered with, “No, they didn’t; I’m with them right now.”
Even if not with the employee right now, a manager could text, possibly Slack, or even call the employee just to be on the safe side before giving the green light.
Is this completely flawless? No, but it does give companies an additional layer of protection against nefarious actors.
Would what I’ve written have prevented the MGM attack? Speculatively, there’s potential it could have based on what we know so far. Even if you assume a 1% chance of preventing a $30M ransom, you’re looking at an expected value of $300,000 and that’s not even factoring in the reputation cost of what this company is going through.
All-told, I don’t think it would have hurt to have this in place, and I think we’re going to have to see companies move to something like it. No matter what questions you ask to verify someone’s identity, a capable attacker could have figured them out. Introducing a second person into the process adds a layer of complexity that can deter attacks.
If you have feedback, or can think of any obvious flaws, I’m all ears 🙂