The Insider Threat that Took Down the Death Star

This post has been updated since it’s original publication of December 15, 2017.

Forces of stormtroopers, councils of Jedi, and squadrons of Alliance/Resistance pilots flocked to theaters to watch the latest installment in the Star Wars series: The Last Jedi back in December of 2017.

As expected, the internet subsequently lit up with rumors, theories, and speculation. What was the intent behind specific character actions, and interactions? What could possibly happen next? Will Jar Jar Binks ever return? (OK, maybe they didn’t wonder that.)

Cybersecurity experts were no different.

With each addition to the expanding Star Wars cinematic universe, IT security bloggers scramble to use the Galactic Empire (now the First Order) and the Rebel Alliance (now the Resistance) as analogs for companies and hackers. And why not? The saga that brought us the Jedi and Sith to teach us about good and evil, right and wrong, hope and despair, provides a wealth of lessons learned for security experts.

Over the years, the Galactic Empire has been picked apart – smeared for its lack of network segmentation, accused of having unsecured ports and unlimited data access, shoddy firewalls, and, of course, terrible security awareness training.

We’d like to submit that the Galactic Empire, for all its enormous cybersecurity gaps, did not lose the death star because of phishing, hacking, or lackluster physical security. In our eyes, it was an insider threat that took down the largest space base of its time (before the First Order upped the ante in The Force Awakens).

Warning – the following content contains spoilers for Star Wars films released in and before 2017. Do not continue reading if you do not want to spoil the films for yourself!

A Simple Bug, or an Intentional Flaw?

For 39 years, between “A New Hope” and “Revenge of the Sith,” we believed the Death Star had a flaw built into it due to an oversight, a bug found and exploited by the rebel alliance.

However, with the release of “Rogue One: A Star Wars Story,” we learned an insider by the name of Galen Erso, purposefully sabotaged the Death Star’s design in a way that would make it possible to destroy the entire space station. (This is akin to a disgruntled principal architect at a major device manufacturer purposefully enabling access to the root superuser account without a need for a password.)

So, let’s dissect the situation for a moment.

A high value resource (Galen Erso) was coerced (meaning: against his will) to work on the most pivotal military project the Empire had ever embarked upon (the Death Star). Immediately, alarm bells should have gone off.

This situation was an insider threat incident waiting to happen. However, the Empire suspected nothing, because Erso indicated that he was nothing but a model employee. In fact, the Death Star (DS1) project would be nowhere without him.

What should the IT security manager have done?

Insider Threat Management & The Death Star

First, they should evaluate the current processes associated with their system development life cycle.

It is almost impossible to complete a full risk and security assessment on a galactic scale, but in this case it’s easy. The DS1-Project — to use a business analogy – is a “Key top-secret plan with buy-in and visibility from the upper echelon of the Empire.”

The assets Erso was working on would be categorized as “hyper-sensitive.” In this case, encryption, lease privilege, and data masking are all great for keeping confidentiality of the top-secret project. But how do you make sure a determined and irreplaceable insider, who has been given legitimate access, is not undermining the integrity of the project he’s working on?

The answer is relatively simple: mandatory vacations, peer review, and security as part of the system development lifecycle.

1. Mandatory Vacation Time

   First, send Galen home to his farm periodically — he needs a few weeks to rest and mourn while his plans are reviewed and simulated by an impartial audit team.

2. Peer Review

   Second, make sure the entire project is reviewed on a regular basis. Perform risk assessments on existing designs and provide alternatives.

3. Maintain Security Throughout the Project

   Third, maintain security throughout the design process, not just upon completion. From the initial implementation phase, security teams should be doing code reviews, simulations, and red/blue exercises to identify and eliminate vulnerabilities.

Is Insider Threat Prevention Possible?

Was there anything the Galactic Empire could have done to prevent Galen Erso from becoming an insider threat in the first place?

Sure. Realistically, they should have started with building a culture not bent on world domination, and with a tendency to murder spouses and children. Human Resources (HR) likely had to make the best of a tough situation.

The HR team should have talked with Erso about the loss of his wife and daughter and brought in a new Director of Operations. It also probably wouldn’t have hurt to send Orson Kennic to employee sensitivity training. The number one reason for disgruntled or disillusioned employees are direct managers and leadership. Senior leadership and security teams should always be aware of tensions or grievances employees may have toward their upper management.

Takeaways

In closing, Galen Erso should never have been made principal architect of the DS1-project and his designs should have never made it past the planning stages.

Identifying and eliminating insider threat is not just about technology, it isn’t only about stopping data leakage. Insider threat should be treated as another attack vector and assessed within the same risk models organizations use today for external threat. Confidentiality is important but maintaining integrity of your intellectual property through proper monitoring and review should be a top priority for any organization.

May the Force be with you.

To Learn More about Insider Threats:

Download EBook