As a non-native English speaker, I always like to learn new idiomatic expressions that give color to the language. One of my favorites is to tell someone to take some information “with a grain of salt”. According to Wikipedia,
The phrase comes from Pliny the Elder's Naturalis Historia, regarding the discovery of a recipe for an antidote to a poison. In the antidote, one of the ingredients was a grain of salt. Threats involving the poison were thus to be taken "with a grain of salt," and therefore less seriously.
An alternative account says that the Roman general Pompey believed he could make himself immune to poison by ingesting small amounts of various poisons, and he took this treatment with a grain of salt to help him swallow the poison. In this version, the salt is not the antidote. It was taken merely to assist in swallowing the poison.
The Latin word salis means both "salt" and "wit," so that the Latin phrase "cum grano salis" could be translated as both "with a grain of salt" and "with a grain (small amount) of wit."
The phrase cum grano salis is not what Pliny wrote. It is constructed according to the grammar of modern European languages rather than Classical Latin. Pliny's actual words were addito salis grano.
But why am I talking about this in a Information Security blog? Because I want to say that all security advice should be taken with a grain of salt!
When I’m reading security blogs and listening to security podcasts I’m always impressed how some of my colleagues present some advice as the ultimate truth. There are a lot of “MUSTs” (in fact, a lot of “MUST NOTs”), as a magical set of rules that will allow us to easily do everything we want in a secure manner. However, all of them forget about one of the most important pieces of solution design exercises: CONSTRAINTS.
Of course we don’t want to use FTP or TELNET. Yes, 4 digit only passwords is stupid. Oh, how come you still have Java installed?
It’s not because people are stupid (well…ok, sometimes). It’s because they have, in most cases, valid constraints to be considered when security is being assessed or designed. Sometimes the only software available in the market for a specific business process is that crappy screen scraper based on TELNET. Or that hardcoded password crap is provided by the vendor of a multi-million dollars medical device that you can’t just throw away because of a security vulnerability. We should always try to apply pressure and make people aware of how security unwise those things are, but let’s be honest, if we were in the place of an executive, would you really consider a huge change to your business because of things like that? No, you would tell your security team to “be creative” or, most probably, call one of those big brand consultants to tell you what you want to hear.
So, let’s pick our battles. We’ll never be able to work under ideal conditions. We’ll have to deal with “stupid” things like FTP, Telnet, unpatched Windows boxes and unsupported software. We should keep evangelizing the IT world that security should be built-in, but we have to be prepared to bolt-on.
Next time a security curmudgeon comes with his canned “you MUST NOT” advice, ask him back: “and what if I have to?”. That’s a good way to see who is just playing to the crowd and who deals with real world, full of constraints conditions.