It did, once, with the transportation of the 3,106 carat Cullinan Diamond, the world’s largest uncut diamond from South Africa to Edward VII in England. This is one of Bruce Schneier’s favourite examples in his book Beyond Fear, however the general consensus is that obscurity alone should not be used when protecting assets. The diamond crew were daring, audacious and wouldn’t be able to pull the same stunt again for some time, having revealed their covert transportation channel. A defence in depth approach using more than one mechanism may benefit from a dose of obscurity, but otherwise obscurity is a toy.
Security through obscurity is the use of secrecy to provide security. It slows down the initial reconnaissance phase of an attack, but does nothing to prevent it. If we don’t share our password to our bank website, the perpetrator has to guess it, compute it, or find the post-it note on our monitor. If we don’t talk about the bugs found during testing of our new mobileapp, the bad guys have to fiddle around until they work them out. If we SSL encrypt our data feed to our business partner’s service, using self-signed SSL certificates, the bad guys can generate their own or acquire a copy of the certificate to read it all. The repeating theme here is that nothing has been prevented, merely delayed.
With the ever increasing sophistication of reconnaissance toolkits available to the bad guys, relying on an information system vulnerability to remain hidden or unnoticed should never be part of your security policy. If you know about it, you have a head-start on the bad guys – exploit it.
Risk mitigation using the top-down design of a threat model, then a security policy and ultimately your security engineering mechanisms, can be an effective approach. However, that policy piece in the middle is often neglected and quickly becomes the weakest link.
Here’s an example of some particularly poor policy waffle:
Busted Logistics Plc – Security Policy
- This policy has been approved by the Board
- All instances of nonconformity must be reported to the Security Office
- Information shall only be available to those with appropriate privileges
- All employees shall obey this policy
The gaping holes here are “who” determines the “need to know” and how do they determine it? What do the employees have to do to obey this policy? Must the system enforce it, or is this a trust exercise? It doesn’t need to be more than a page, but it must be a clear statement of the protection objectives of a system and what it is meant to achieve. Who authorised the policy is only important to those that did authorise it, but not to the policy target readership! Having a broken policy with no clarity on who should be allowed to access what, with impeccable engineering implementation, does not result in a peaceful night’s sleep. Think about group account logins, with more than one individual knowing the password. If there’s a compromise, it was always “someone else”.
Do you have a security policy for your organisation, which is applied to your Information System? Do you believe you need one?