This is How the Disney Insider Threat Incident Reframes IAM Security

Gabriel Avner

November 14, 2024

This is How the Disney Insider Threat Incident Reframes IAM Security post thumbnail

It’s not that often that a story about a Joiner-Mover-Leaver (JML) failure makes the international news. 

But throw in an insider threat actor making potentially life-threatening changes to the impacted systems, and it becomes quite the doozy. 

Especially when the company at the center of the story is Disney.

The Details of the Case

In case you missed it, a former menu production manager named Michael Scheuer was fired in June for alleged misconduct. According to the reports, his departure was not a friendly one.

Things only deteriorated from there. Scheuer is alleged to have used his credentials to the 3rd-party menu creation software that he used during his employment at Disney to make numerous changes to Disney’s menus.

And here’s the weird part. He apparently did this over the course of three months. 

While some of his changes ranged from the dumb—such as replacing text with Wingdings symbols—to the obnoxious with changes to menu prices and inserting profanity, it was his marking of items that contained peanuts as safe for people with life-threatening allergies that crossed the line into the potentially deadly. 

Luckily, none of the altered menus are believed to have made it out to the public. Scheuer currently has a criminal complaint against him in a Florida court. 

What Went Wrong?

Beyond the anger at Scheuer for putting lives at risk, my next feeling here is a bit of confusion. 

What happened in Disney’s offboarding process that allowed Scheuer to hold onto his access to this 3rd-party system for three months?

In most cases when someone leaves a company, his or her access to company information and systems is cut off. This is the correct and common practice in all cases, regardless of whether the separation is amicable. 

Especially in cases where the parting is on bad terms, this is especially important to follow through on to prevent them from stealing or damaging company data and systems on the way out.

Without knowing the full details of the case, my best guess is that Scheuer was likely disabled in Disney’s Identity Provider (IdP). Popular IdPs such as Microsoft’s Active Directory/Entra ID or Okta allow the administrator to disable a user’s access to resources managed through the IdP.

In an era of Single Sign-On (SSO), managing access to your resources via the IdP makes a ton of sense. The centralization is pretty great for admins, and users save valuable time on logging in.

But it’s not hermetic from a JML standpoint. 

Even if Scheuer’s access to the menu-creation software was disabled in the IdP, he still had his credentials that allowed him to login to a 3rd-party platform that was not owned by Disney. 

This means that Disney’s security and IAM teams did not have the visibility to see that he still had access. And more to the point, that his access there was still active. 

For. Three. Months.

To be fair to Disney’s team, this is a hard problem that their tools would not have easily solved. 

Add to this that from a standard risk perspective, ensuring that this menu creation software was locked up tight was probably not a priority.

Security Risks Are Not a Binary But a Balance

Normally when we think about risk management, we know where to initially direct our focus.

Start with the crown jewels. These are going to be resources that are:

  • Regulated data and systems handling PII, PHI, and financials 
  • Sensitive to company interests like source code or other IP
  • Production environments that impact the product

Menu-creation software, especially if it is not owned by your company, does not fall into any of these categories.

And yet, here we are talking about it.

While Disney thankfully prevented any harm from happening to their customers, this story is not great for their brand. Remember that this could have been a lot worse.

It reminds us that even those resources and systems that don’t rank as crown jewels still need to be protected. The choice is not between protecting the highest risk resources while leaving the less sensitive ones unguarded.

As we’ve seen here, all resources need at least some level of monitoring and protection.

At the same time, we don’t want to go overboard. 

Placing too much friction on access to resources can slow down productivity, which can have real dollars and cents costs on the business. 

The fact is that we need to strike a balance between making sure that workers have the access they need to get their jobs done efficiently while keeping a lock on: 

  • Who can access what 
  • What they can do with that access
  • How long they have said access

At the core of the issue is understanding that every resource presents some level of risk that needs to be managed. That risk will not always be apparent as in this case. But it still needs to be accounted for and addressed.

So how could this have been handled differently?

Apono’s Approach to Managing Access Risks

Looking at this case, we run into a couple of interesting challenges:

  • How to strike a balance between legitimate access needs and security concerns
  • How to manage offboarding access to externally-owned software not (fully?) managed by Disney’s IdP
  • How to detect anomalous and potentially malicious access behavior

Let’s take them one-by-one.

Access vs Security?

So first of all, we need to break out of the binary mindset and embrace one that looks at access and security as matters of degree. This means recognizing that every resource has some level of risk, and that even lower risk resources need a level of protection. 

In this specific case, we wouldn’t want to restrict access to this software too heavily since it does not fall into the crown jewels category and was probably used all day, every day by the menu creation team. Practically, this means that we would want to make access here self-serve, available upon request with minimal friction.

However, by moving it from a state of standing access to one where the employee would have to be logged into his IdP and make a self-serve JIT request through a ChatOps platform like Slack or Teams, we’ve already added significantly more protection than we had before. 

Legitimate employees will not have to wait for their access request to be approved by a human, and provisioning would be near instantaneous, letting them get down to work. 

You can learn more about Apono’s risk- and usage-based approach from this explainer video here.

Offboarding Access to 3rd-Party Platforms

This one is tricky if you are dependent on identity-management platforms like an IdP where your perspective is one of who has access to what.

Sometimes the right question is what is accessible to whom.

Access privileges are the connection between the identity and the resource, and it needs to be understood from both directions for effective security operations.

So even if access to the menu-creation software was disabled from the IdP, the credentials were still valid from the 3rd-party’s side. 

This left the security team blind to this important fact and unable to centrally manage the offboarding from their IdP.

As an access management solution that connects not only to customers’ IdPs but also to their resources, Apono has full visibility over all access privileges, and enables organizations to revoke all access from the platform.

Access Threat Detection and Response

It is absurdly common for threat actors to maintain persistence inside of their targets’ environments for long stretches of time. But usually they use evasion techniques to fly under the radar.

Scheuer was making active changes to menus over three months. Meaning that he was regularly accessing the menu-creation software. This should have raised some flags that something was going on. But let’s put that aside for a moment.

When users connect their environments to Apono’s platform, all access is monitored and audited. This enables organizations to not only satisfy auditors for regulations such as SOX, SOC II, HIPAA, and more. It also allows them to get alerts to anomalous access requests and respond faster to incidents.

It’s a Challenging Access Management World After All

It is almost a cliche at this point, but access management in the cloud era is confoundingly challenging as teams try to keep pace with the scale and complexity of IAM controls across a wide range of environments.

Thankfully in this case, tragedy was avoided and the suspect apprehended. As someone with a peanut allergy myself, this story struck close to home. Cyber crime always has consequences, but a clear line was crossed here and the accused is lucky that he failed.

To learn more about how Apono is taking a new approach to risk-based access management security that takes on the scale of the enterprise cloud, request a demo how our platform utilizes risk and usage to drive more intelligent processes that enable the business to do more, more securely.

Related Posts

How a DevSecOps Initiative Could Have Prevented the IKEA Canada Privacy Breach post thumbnail

How a DevSecOps Initiative Could Have Prevented the IKEA Canada Privacy Breach

Earlier this week, IKEA Canada confirmed that an employee had accessed...

Ofir Stein

September 20, 2022

Top 5 AWS Permissions Management Traps DevOps Leaders Must Avoid post thumbnail

Top 5 AWS Permissions Management Traps DevOps Leaders Must Avoid

As born-in-the cloud organizations grow, natively managed Identity and...

Ofir Stein

September 20, 2022

How we passed our SOC2 compliance certification in just 6 weeks with Apono post thumbnail

How we passed our SOC2 compliance certification in just 6 weeks with Apono

We recently went through the SOC2 process and are happy to report that...

Ofir Stein

September 20, 2022