Real security – Safety vs. Liberty

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.

Read the article here:

http://www.schneier.com/crypto-gram-1012.html

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.

K

Requirements are key

I see project after project take longer than it should and have a considerably more complex design phase than is necessary.  This is often, but not always, down to a combination of poorly defined and / or changing requirements.

Things change, but this should be in a controlled manner.  For anyone working in the architecture, solutions, or indeed development space do yourselves a favour and try not to start detailed design and development work until the requirements are clearly defined, understood, signed off and change controlled.

This will make your life a lot easier and actually lead to solutions that better meet the needs of your business as the requirement(s) will be well thought out and clearly defined.

Challenge the requirements! Along with ensuring requirements are clearly defined, challenge them, are they genuine requirements, do they clearly meet business / regulatory etc. needs, are they requirements or ‘nice to haves’.

All designs should be requirements led; Solid requirements enable the right solutions.

K

The minimum technology to meet the requirements

The heading from this post is actually an idea stolen from a Microsoft article.

Many of us love technology and genuinely want to solve the problems we are presented with.  The challenge comes in ensuring the love of technology is tempered with keeping the requirements, and local skill sets etc. in mind.

The ‘perfect’ solution with the best performance, highest resilience, quickest recovery etc. may actually be far more than is required.

The perfect solution for the requirement in hand is the one that uses the minimum technology and is the simplest, while still meeting all the requirements.

So for all you architects and solutions guys and girls out there, whenever you have a problem or agreed set of requirements, make sure you meet them, but make sure you keep it simple as well.

K