Star Wars: A New Hope (or Episode IV if you prefer) is more than just an epic tale of the galaxy-wide struggle between the Galactic Empire and the Rebellion, and the triumph of good over evil. It’s also a great example of how a series of basic infosecurity mistakes can cost even a massive, powerful (but evil) organisation like the Empire dearly.
As the Empire’s executive leader, Darth Vader certainly didn’t lack resources. He had huge teams of trained, highly-motivated personnel at his command, not to mention some state-of-the-art security hardware. He also knew what assets needed protecting – all of which are fundamental to an effective security strategy.
But ultimately, the Empire was compromised by a fatal combination of weak security policies and poor practice. It’s a classic example of investing in a seemingly powerful security technology or product, then building policies based around that technology – rather than starting with a policy that covers what’s critical to the business, then acquiring and deploying solutions that map to it.
Let’s take a look at some of the key security mistakes made by the Empire, how those mistakes were exploited, and how you can learn from them.
In the opening sequence of the film, Darth Vader and his Stormtroopers board a Rebellion vessel to recover intercepted blueprints of the Empire’s new terror weapon, the Death Star. So far, so good: the Empire had detected a potentially dangerous data leak, and acted swiftly to contain it.
However, the Empire’s good intentions were let down in the execution: their search of the ship was too focused. The stolen data was loaded onto a consumerised device (the droid, R2D2), which escaped the captured ship in a lifepod. Even though Imperial forces detected the lifepod’s launch, they let it go: at that time, it wasn’t a droid they were looking for.
The lesson is that there are multiple vectors for data loss – USB flash drives, consumerized devices, email, IM – whether the data is Death Star schematics or customer financial data. So organisations can’t afford to focus on one possible data loss vector while ignoring another. All possible vectors should be considered, in addition to the security policies developed to cover them and the solutions that enforce those policies.
No product is infallible: not even a Death Star
The intercepted blueprints were put to use by the Rebellion to create a highly targeted attack on the Empire’s main security appliance, the Death Star. However, at the Imperial board meeting convened to discuss the ramifications of the data breach, Imperial executives were more concerned with point-scoring and squabbling with each other, instead of working together to find and close off possible vulnerabilities.
Darth Vader warned Admiral Motti not to be too proud of the technology the Death Star represented; and Motti retorted that Vader’s knowledge and use of The Force had not located revealed the stolen data. Vader found Motti’s lack of faith disturbing, but he should have been more concerned that the meeting failed to find a way to resolve the problem and fix the vulnerability.
Neither had grasped the fact that it doesn’t matter how strong you believe your security infrastructure to be; there are always vulnerabilities introduced through simple human errors or poor planning. Keeping networks and data secure requires both a clear, business-led policy and coordinated effort across IT and security teams. The product alone is not enough.
Poor authentication gives access all areas
When the Millennium Falcon is captured in a tractor beam and brought into the Death Star, the Empire fails to properly inspect the vessel for payloads that could present a risk. Then the rebel crew exploit the Empire’s weak visual authentication test by stealing Stormtrooper uniforms, which gives them unchallenged access to the Death Star’s interior, networks and defence systems.
These scenes highlight two very common security issues: first, without strong user authentication, it’s easy for a potential attacker to appear familiar and trustworthy. Simple visual checks (are you wearing an Imperial Stormtrooper uniform? Permission granted) are not enough. Security policies should take account of users’ credentials, and only grant access to users who can authenticate their identity, ideally with a 2-factor method. Second, it’s not appropriate to give all members of staff, contractors and third parties full access to all your network resources and data. Organisations should assess what information is business-critical, and ensure that data is only accessible by those authorised to use it.
The dangers of BYOD
Having passed the Empire’s weak authentication systems on board the Death Star, R2D2 is able access confidential data on the Death Star itself, simply by plugging into an easily accessed wall port. What’s more, R2D2 isn’t just a portable storage device, but a self-propelled, intelligent robot that could not only take data anywhere, but then use that data selectively. This creates a real BYOD (Bring Your Own Droid) problem for the Empire.
Consumerization, or ‘bring your own device’, can offer benefits, but once again needs a coherent policy to control it within an organisation. The policy needs to be supported by technologies including port or device management, data encryption, and remote lock and wipe capabilities.
In conclusion, while the Empire had clear strategic goals (i.e. ruling the Galaxy), and enormous technological and manpower resources at its disposal, it failed to apply proper policies to help manage and utilise those resources effectively. In fact, the exposed exhaust port on the Death Star was the least of the Empire’s worries. ?The security lessons we can take from this are simple: focus on creating security policies that will help you reach your strategic goals, then deploy the appropriate technologies to support and enforce that policy. Do, or do not, there is no try.
And may the enforcement be with you.