Tag: safety

Reading Bruce Schneier’s Crypto-gram from December 2010, this echoes conversations I have had many times. How much of the extra checks and surveillance we go though at airports etc. actually improves our safety, and how much is for appearance to make us feel like governments are taking action.

These same sentiments can and should (must) be applied to IT security in the workplace as well. To often it is easy to be swayed by the hype of the latest products and fear of risks that are in reality extremely unlikely to actually occur. Rational security and a clear understanding of the actual risk should be the drivers for any security requirements.

In a given scenario the cost of implementing the security measure (technology and process costs) should not be greater than the likely hood of issue X occurring (e.g. once in 10 years) * the total cost if the issue occurs (lost business, reputational damage etc.).

This situation is not helped by the security industry itself, it must be remembered that they companies selling IT security products and services are in the business of selling these products and services! In order to do this it is in their interests to hype the risks and generate a culture of fear.

Of course I am in no way suggesting that there are not a myriad of threats from viruses / worms / trojans etc. to organised crime, botnets and of course the insider threat. But these should be assessed in a balanced and rational manner that seeks to understand the risk to the actual system and data that is being protected.

This brings me back around to my favourite topic (read soapbox); requirements and architecture / design. I firmly believe that making the right design choices early on in a systems life-cycle will minimise any security risks and also minimise the challenges associated with securing a system further down the line. This is one of the main reasons moved into working in Architecture from working in the purely IT security field, as so many of the issues we solve in security every day can be resolved / designed out with the proper consideration at the design face of implementing a system / solution.