5 IT lessons to 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.

1. 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?

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.