Information Security: from Human Factors to FIPS
Posted by Steve Lay
Last year I wrote about Keeping up with Software Security and touched on the issue of cryptography and the importance of keeping up with modern standards to ensure data is stored and communicated securely. In this post, I return to this subject and dive a little deeper into maintaining information security and the role that software plays in it.
The first thing to is that software can only ever be part of an information security strategy. It doesn’t matter how complex your password policy or how strong your data encryption standards are if you allow authorised individuals to share information inappropriately. Amongst all the outcry following the information disclosed by Edward Snowden, it is surprising to me that the focus hasn’t been on why an organization that plays such a crucial role in security (in its widest sense) was so easily undone by a third-party contractor. According to this article from Reuters news agency, one of the techniques Snowden used to gain access to information was simply asking co-workers to give him their passwords.
The computing press will sometimes try and persuade you that there is a purely technical solution to this type of problem. It reminds me of the time my son’s school introduced fingerprint recognition for canteen payments, in part, to allow parents to check up on what their children had been spending — and eating! It wasn’t long before the phrase, “Can I borrow your finger?” was commonplace amongst the pupils.
I hope my preamble has brought home to you the basic idea that these ‘human factors’, as the engineers like to call them, are just as important as getting the technology right. Earlier this week I had to go through my own routine security testing as part of our security process here at Questionmark, so this stuff is fresh in my mind!
Information security, in this wider context is covered by a whole series of international standards commonly known as the ISO 27000 series. This series of standards and codes of practice cover a wide range of security processes and computer systems. To an engineer looking for a simple answer it can be frustrating though. ISO 27002 contains advice on the use of cryptography, but it runs more like a policy checklist. It won’t tell you which algorithms are safe to use. In part, this is a recognition of how dynamic this field is. The recommendations might change too fast for something like an ISO standard which takes a long time to develop and is designed to have a fairly long shelf-life.
For more practical advice to engineers developing software, help is at hand from the Federal Information Processing Standards (known as FIPS). FIPS was developed by the U.S. government to help fill out the gaps where externally defined standards weren’t available. It ranges across many areas of information processing, not just security, but one of the gaps FIPS fills is specifying the details of which cryptographic algorithms are fit for modern software and, by implication, which ones need to be retired (FIPS-140). This standard has become so important that the word FIPS is often used to refer only to FIPS-140! It isn’t restricted to the U.S. either; it is being freely adopted by other governments including my own government here in the UK.
FIPS 140 also has a certification programme. The purpose of the programme is to certify the implementation of cryptographic code to check that it does indeed correctly implement the security standard. Microsoft have a technical article to explain which parts of their platform and which versions have been certified. There is even a “FIPS mode” in which the system can be instructed to use only cryptographic algorithms that have been certified.
Concentrating the cryptographic features of an application into a small number of modules that are distributed with the underlying operating system rather than having each application developer individually implement or incorporate the code themselves will, over time, make it easier to make use of appropriate cryptography and to implement policies such as those described by ISO 27002.