By guest blogger Terry Greer-King, UK MD for Check Point
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 (like a Death Star), then building policies based around that technology — rather than starting with a policy that covers what’s critical to their business, then 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 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, consumerised devices, email, IM — whether the data is Death Star schematics or customer financial data. All possible vectors should be considered, and security policies developed to cover them and the solutions that enforce those policies.
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 testby 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 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. 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 can take data anywhere, and use that data selectively. This creates a real BYOD (Bring Your Own Droid) problem for the Empire.
Consumerisation, or BYOD, 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.