5 lessons IT can learn from 'Rogue One: A Star Wars Story'

Rogue One isn't just a Star Wars story. It's an information security story.

"Rogue One: A Star Wars Story" isn’t just a tale of scrappy rebels fighting against an evil Empire. With the issues it raises, including device authentication, asset management, and privilege control, it’s also a story about information security. Well, more like a cautionary tale.

The Empire we love to hate has exhaust-port-size holes in the way it conducts its secret affairs. Seriously, it’s no wonder the Empire’s efforts to keep its plans secret were defeated by a bitter ex-convict with daddy issues. We spoke with technologists who identified five of the security flaws in "Rogue One" and offered advice on how to better run a system in the here and now.

Daddy issues are optional.

(Note: No Bothans died in the making of this article. Because that was "Return of the Jedi." But there are spoilers, if you haven’t seen the movie yet.)

The Empire didn’t secure K-2SO

K-2SO, an Imperial battle droid, was captured, reprogrammed to work against the Empire, and turned into a snarky-comeback machine.

So why didn’t this expensive piece of military hardware brick itself like a poorly jailbroken iPhone the moment the Rebellion tampered with it?

An Imperial shuttle shows up where it’s not expected: Scarif, the off-site backup of all the secret knowledge of the Empire. ... They should have been challenged somehow, even if it’s 'Tap your access badge and enter a PIN.'

Stephen Wadlowsenior security architect

It’s for the same reason not every device is bricked in the here and now. As principal network protocol architect Ted Lemon explains, “No hackability means no fixability. What you want is upgradability and verifiability. The basic idea is that you want to make sure that the only updates your droid takes are your updates. And you do that with code signing.” Code signing is a process that authenticates the author of software and certifies that the code hasn’t been tampered with by a third party.

Secured hardware has a built-in fixed list of authors from which it will install updates; only those authors have the necessary keys to prove that the software really came from them. If you’ve ever had Windows block you from installing unsigned device drivers, you’ve seen this in action.

“Any device you buy that will install unsigned updates is risky,” says Lemon. “But you can have a secure boot ROM that can be programmed with a key that you provide, as well as a key the vendor provides. You have reason to feel secure if you use hardware that verifies that the software it is running is the software you intend it to be running, and not some hacked version that acts against your interests.”

Especially if your hardware is controlling a kill-bot.

Can a company have too much IT security?

Security lesson: Use code signing to ensure your devices accept only legitimate software updates.

The Empire did not track its assets

Bodhi Rook and the crew of Rogue One fly to Scarif in a cargo shuttle stolen by the Rebellion. When they arrive, the traffic controllers say, “You’re not listed on the arrival schedule.” Bodhi answers, “We were rerouted from Eadu Flight Station.”

Had the Empire kept track of its assets, it would have known its previously missing shuttle had appeared as unexpectedly as Obi-Wan Kenobi’s force ghost.

Asset management is so important that the Center for Internet Security made it the first step in a laundry list of priorities. In a secure system, assets come appended with credentials, which restricts users based on their security levels.

If you don’t track your assets, you can’t control the associated policies. Among them: “Don’t use Dropbox or other file-sharing services on your office computer” and “Meet the approach of an unauthorized shuttle with a flight escort, followed by a trip to a debriefing/detainment room.”

But security isn’t just about the assets themselves. It’s about expected behavior. According to senior security architect Stephen Wadlow, “An Imperial shuttle shows up where it’s not expected—Scarif, the off-site backup of all the secret knowledge of the Empire. Let that sink in for a moment."

Security lesson: Trust, but verify. Anomalies happen, but it’s vital to determine whether they are innocent or malicious.

Jyn and Cassian have too much access to the Empire’s facility

Jyn Erso and Cassian Andor steal the uniforms of officers who work on what appears to be the loading dock. That may earn them entrance to the Empire’s cargo bay and the officer’s mess hall. But their privileges should stop right there. Instead, our rogue heroes make it all the way up to the doors of the data vault. Says Wadlow, “They should have been challenged somehow, even if it’s ‘Tap your access badge and enter a PIN.’”

Granting physical access to more sensitive areas only to those who actually need it minimizes the footprint of privileges that an organization has to track and manage. Whether you’re managing building security or network security, restricting permissions helps keep you secure.

Actually, security could be even stricter. David Campbell, an IT lead, had to take several steps when he visited a data center operated by a German global megacorporation. It turns out that the visit was far more threatening than a visit with Darth Vader.  

“First, I had to arrange my access a week in advance, with managers communicating with each other, explaining why I needed to be there,” says Campbell. When he entered, he had to pass his backpack and computer through an airport-style X-ray machine. “I had to pass through an explosives detection device,” he adds. “And then I walked through a man-trap, a room that I could not get out of, unless the guard pushed the button that lets me out.”

But there’s one good thing Campbell said about the experience: “I can say with reasonable surety that our customer’s data was quite safe.”

Security lesson: Limit privileges.

The data Jyn and Cassian find is readable

Jyn and Cassian make their way to a massive data vault and grab the right file, which they then upload (more on that, below) to the Rebellion, whose line-of-business staff are immediately able to read it.

Pity the Empire didn’t use encryption utilities such as TrueCrypt, VeraCrypt, BitLocker, or Gnu Privacy Guard. The software is easy to use, difficult to hack, and perfect for users, businesses, and reigns of terror alike. But encryption is not enough; you also need a place to store the decryption keys. To minimize any possibility of codebreaking, that place should not be the same place the encrypted data is stored (for example, on a USB key itself protected by a password).

Just encrypting a file is entry-level stuff, though. For real security, split up the file, too. According to Wadlow, people who are serious about cryptography use algorithms like Shamir’s Secret Sharing to encrypt and split a file into separate parts. For example, DNSSEC’s root key has been divided into seven parts, which means a minimum of five keyholders need to meet in the same location in order to decrypt the file. Wadlow also says he would keep the decryption keys far away from the data.

That same method, applied to a map of the galaxy, kept Luke Skywalker hidden for 15 years in "Star Wars: The Force Awakens."

The top emerging technologies that will shape our future

Security lesson: Encrypt your data, and keep your data separate from your decryption keys.

Jyn could transmit the Death Star plans off-world

In what can only be considered a catastrophic security failure—and let’s not forget Scarif is meant to be tighter than Emperor Palpatine’s fist—Jyn reaches the broadcast antenna to transmit the Death Star plans off-world,

Imperial project managers on Scarif could have blocked Jyn from turning the information free as in beer by requiring simple authentication before she was able to hit “Send.” (Although this is another example of the granular access control problem that got Jyn into the base in the first place, it’s also a question of providing extra protection around the most critical parts of the infrastructure.)

Any broadcast from this secure facility should require multifactor authentication. Using an access card and entering a PIN is a form of two-factor authentication; you need the card (a physical object) and you also need to know the PIN (something you memorized).

These three different forms of identification are beyond needing to know two passwords or enter your thumbprint twice: They’re different types, or factors, of identification. IT professionals colloquially characterize these as “something you have,” “something you know,” and “something you are.” For example, you know the answer to a challenge question, you have a near-field communications token, and you have a fingerprint. Having more than one factor makes attacks harder for intruders, because they need to use different techniques to try to compromise the system.

Still, in the here and now, our debit cards take PIN numbers, logging into our office terminals from home requires an NFC token, and our iPhones use fingerprints. It seems a little strange that in a galaxy far, far away, a Galactic Empire with lightspeed doesn’t ask for a password.

At least Jyn had to use an Imperial officer’s handprint to enter the data vault.

Security lesson: Use authentication, preferably multifactor, on your internal networks. Require more authentication for actions that should require more privileges.

May the Force be with you, in your data center and in the cloud.

Thanks to Steven Wadlow and Alex Kreilein.

This article/content was written by the individual writer identified and does not necessarily reflect the view of Hewlett Packard Enterprise Company.