Security Think Tank: Procurement and security are uneasy bedfellows

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

The risks posed by software these days can be severe and numerous. 

Back doors in software can put customer and employee data at risk; poorly coded software can cause outages, brand damage and loss of data; viruses and Trojans in unchecked downloads can cause havoc and untold damage, including handing access to malicious third parties who then have unfettered access to systems.

This is not to say that all software is dangerous, or that software should not be used – that would be taking things too far.

However, a properly implemented secure software development lifecycle can be of real value to a development company, not least a properly documented process which is adhered to. 

Where a software sales representative can point to a well-known process for assurance, a purchasing company would be well advised to take this into account.

Some software developers may argue that if the required functionality is present, the customer should be on the lookout for the vulnerabilities themselves before deploying. In many cases, it is holes in the customer's infrastructure that will allow the attacks after all. 

Content checking can be done at the boundary of the network, before the applications are even reached. A wise customer will do everything they can to avoid this situation.

Security testing in the final stages of a product should only be testing the configuration of hardware and software, not the security of software. It is already too late if you are at this stage

Robert Newby, KuppingerCole UK

Security testing in the final stages of a product should only be testing the configuration of hardware and software, not the security of software. It is already too late if you are at this stage.

Any commercial organisation which values its security is well-advised to perform a security test of any software before deployment, but how simple is this to bring forwards into the procurement process as a result?

Unless it is a specific requirement of the application under development, security will most likely be superseded by other functionality – functionality which creates business benefit, rather than pure cost as security often (always?) does.

Lock software doors and windows

Procurement and security are uneasy bedfellows. Commercial teams require things to be done quickly, simply and as cheaply as possible. Security introduces delay, complexity and cost.

Security should mandate testing, and advise as to why this is necessary. Procurement should be seeking to lower risk to the business in their processes. Sadly, a lack of awareness of security may make this a difficult task. So it is security’s task to mandate testing and raise awareness. This can be done via policy, but also by campaigns, communication, contact and relationships.

Security can communicate with the business by talking in terms of risk, and this can translate simply to commercial teams in terms of cost. Stated simply, the risk posed by rogue software is very high in these days of viruses, Trojans, botnets, advance persistent threats (APTs) and state-sponsored attacks.

Software is a seemingly benign way to gain absolute access to your network – an open window even when your doors are firmly locked. The cost of not treating this is simple – it could cost you everything you hold electronically within your company network, all intellectual property (IP), customer records, credit card information, designs, processes and developments; not to mention brand and reputation.

Build security into the procurement cycle

This is not FUD (fear, uncertainty and doubt), but a very real state of affairs. 

I was recently at GCHQ for a presentation by a gentleman who runs the operations team. He talked about an attack where malware had been placed at a company’s internet service provider (ISP), on its website, and locked via IP such that only addresses coming from the company’s IP range would get malware sent down to them, thus obscuring the attack. Once the payload was delivered, information was sent back to a hidden endpoint on the internet.

When the company found the malware on its systems, it removed it and blocked the malware at the gateway. Two weeks later, the malware was back on the systems via a subsidiary company connected by virtual private network (VPN).

The cost to remediate against this is therefore quantifiable. Addressing this in a procurement cycle can be cheap – state it as a requirement and many software houses will meet the cost of security checks themselves. 

Wait until the software is deployed, and not only do you face testing the software already in place on your infrastructure, and the complex testing cycles that involves, particularly in production environments, but you also face the cycles of fixing bugs. Development waits for no man, and taking developers off current tasks to focus on bug fixes is not a simple resource management job.

Raise security awareness and understanding

As security professionals, therefore, we need to be more business aware, and not assume that our colleagues will know the technical detail we do.

Raise awareness with your commercial teams, but talk in business terms, state the risks in realistic terms, give examples, work with them to state the costs at each stage, and talk about realistic measures to mitigate. Above all, create awareness and understanding.

Robert Newby is an analyst and managing partner at KuppingerCole UK.

Read more on Application security and coding requirements