Star Wars: A New Hope 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) organization 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 practices. 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 an organization, 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 in Star Wars: A New Hope; 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 consumerized 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, organizations 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, 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 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 Unfettered Access
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 defense 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 two-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. Organizations should assess what information is business-critical, and ensure that data is only accessible by those authorized 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 organization. The policy needs to be supported by technologies, including port or device management, data encryption, and remote lock and wipe capabilities.
Although 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 use those resources effectively. In fact, the exposed exhaust port on the Death Star – the Achilles Heel targeted by the Rebellion – 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, and 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.
Terry Greer-King is the UK managing director for Check Point Software Technologies. He is responsible for strategic sales planning, business development, channel management and for new initiatives to drive Check Point’s UK sales and marketing leadership. He has over 10 years of experience in the IT security sector and channel sales, and more than 30 years in technology sales and management.