Cybersecurity lessons from Rogue One: A Star Wars Story
SPOILERS AHEAD! — if you haven’t seen the movie, maybe hold off on reading this.
[Update: after years of R&D on the world’s first moving target defense data protection platform with federal agencies and Fortune 100 R&D labs, we are productizing & commercializing CryptoMove’s moving target data protection platform as Tholos Key Vault, a product for managing keys and secrets. You can check out our private beta here.]
No security industry professional could watch Rogue One: A Star Wars Story and not lament the Empire’s woefully inadequate data protection. Why is the most powerful regime in the galaxy using tape? Why are the Death Star plans not protected by even rudimentary full disk encryption? Or better yet, why aren’t the most sensitive crown jewels of the empire fragmented, distributed in multiple locations, and dynamically moving and mutating so that the rebels can’t plan an attack at their leisure? Don’t these guys have the power of the dark side of the force? Have they not heard of active defense?
Beyond obvious data protection issues, however, there are security lessons in Rogue One that run the gamut — including insider threat, user-behavioral analytics, backdoors, secure development, false positives, and incident response, among others.
UBA (User behavioral analytics)
Both the rebels and the empire could have benefited from some sort of UBA technology on more than one occasion. Effective UBA establishes a baseline of behavior and can sound the alarm when an application, user, or asset begins to deviate from expected behavior. When the rebels approach Scarif in a stolen imperial craft, they convince local air traffic control to let them land after some fumbling around. An effective UBA might have picked up that this craft was deviating from its standard flight path as well as standard communications protocols. The same goes for the rebels, when the volunteers left for Scarif in the first place. Apparently, making up “Rogue One” as a callsign is enough to get take-off clearance from Rebel Alliance HQ. A bright spot here is when K-2S0 gets called out by Storm Troopers on Jedha as the re-programmed droid attempts to pass off Jyn and her compatriots as his prisoners. However, there was no technology here, just Storm Troopers being naturally skeptical.
Insider threat
Without question, the empire has a major insider threat issue. Lets forget for a second about the risks Palpatine is taking with his #1 henchman (Darth Vader) being the father of the Rebellion leadership (Luke and Leia) — risks that ultimately lead to an electrifying fall. There is obviously a major risk when the CTO of your planet-killer initiative has Jedi ties and is a former rebel. Perhaps some precautions should have been taken beyond just believing Galen Erso had a change of heart. Bodhi Rook is another insider without whom the death star might never have been destroyed. Better monitoring and training of high-risk insiders, or better access controls might have prevented Bodhi from being in a position to transmit the message from Galen in the first place. Lastly, imperial droids can easily be re-programmed, which creates another vulnerability, as demonstrated by K-2SO’s ability to search through Death Star plan metadata. What a mess. Empire needs to go back to the drawing board here.
Backdoors
Backdoors are often found in security or weapons systems to allow unfettered access or introduce vulnerabilities. In 2016 backdoors in Juniper and Cisco products were both discovered that allowed decryption of information, for instance. Recently there were startling backdoor discoveries in certain Android phones — affecting hundreds of millions of devices — as well. The Death Star does not necessarily have a backdoor in the sense that it can be controlled remotely, but it does have a vulnerability in the reactor core — one that gets exposed just a few episodes after Rogue One. Perhaps had Orson Krennic instituted secure development principles and better red-teaming during the Death Star’s construction, such a weakness might have been uncovered despite Galen Erso’s best efforts to hide it.
False positives
Imperial forces are not the only ones with security issues highlighted in Rogue One. Galen Erso’s tragic death is arguably caused by an issue plaguing many security departments: false positives. In the fog of war, Rebel HQ thought that Galen himself was a threat and must be destroyed at his location at the imperial research facility. This was not true, and only served to needlessly kill a hero of the rebellion and nearly compromise the entire death star mission. As often can occur with false positives, this unfortunate event undermined partner team (e.g. Jyn) trust in Rebel HQ and Cassian Andor’s security methods, nearly derailing the mission.
Incident Response
Why does the empire allow so much time to elapse between massive security breaches? Why is the response to a Death Star security breach to move the Death Star directly into danger? Why were Galen Erso’s communications logs not monitored until after he got a message out to Saw Gerrera? Why was reviewing those message logs viewed as a difficult task? Were there no automated review mechanisms that used AI/ML (artificial intelligence / machine learning) to spot anomalies? Why blow up the site of a major security breach, after you know a transmission already went out and the plans are likely leaked, instead of actually conducting a post-mortem?
With all these unanswered questions, there is one thing we know for sure, given what we know about Vader and Palpatine’s leadership style: Not a fun time to be the Empire’s Chief Information Security Officer (or the next CISO, given what we know is about to happen in Episode IV: A New Hope)…
