Security Think Tank: If cost is king, security suffers

How can security professionals ensure security testing becomes part of the procurement process for all business software?

The answer to ensuring security testing becomes part of the procurement process for all business software is a business one and not a security one – disassemble your procurement stategy and see if cost is king, writes Mike Gillespie.

If that is the case then expect significant additional cost to come from security attempting to secure insecure (cheap) software that has been insecurely purchased. This is a false economy. A bit like buying a burglar alarm then having to pay for manned guarding because, once it was installed, you discovered it only works upstairs.

Having a security presence in the boardroom absolutely ensures that security becomes an embedded process throughout an entire organisation. Until this happens and security is involved in all relevant purchasing activity, then firefighting and additional expense from playing security catch-up will continue.

Software may be found in all areas of a business and in all functions. It may be procured centrally, or  de-centralised. Either way there are opportunities  for rogue or unfit for purpose software to slip under the radar.  

This will be down to organisational culture and attitude toward security and purchasing. It is well-acknowledged that things such as security patch installations, failing to use antivirus and failing to lock down a  user environment are some of the main areas of poor security practice – and therefore increased risk – in business. 

But this is on systems we know about. What about the ones that do not flash quite so brightly on the radar, such as the building management systems, for instance? How well are we procuring and protecting those?

As security professionals we need to be in a position to bring pressure to bear on the supply chain. This would encourage accountability and we should insist software is secure at purchase, not seen as a premium and therefore up-priced. All software should be going through decent factory acceptance testing before it gets to market.

Security needs to be involved in the procurement process at both ends of the transaction and beyond. For instance, the relationship of buyer to seller must be expanded to include the seller security person talking to the buyer security person. This can then cover off key risk areas in an appropriate manner and the buyer knows precisely what they are buying before money changes hands. 

An IT health check should be an integral part of the commissioning and testing process for new software, regardless of its function. If we then get security at the buyer side covering questions with security from the supplier on the results of testing, the way forward starts to look far more clear, logical and secure.

The "most economically advantageous" approach to procurement may be OK for buying mugs or toilet rolls, but it really doesn't work with software.

Mike Gillespie is director of cyber research and security at the Security Institute.

Read more on Application security and coding requirements