Putting software security in the hands of the buyer

For far too long, businesses have been at the mercy of software suppliers for ensuring that critical applications are secure

For far too long, businesses have been at the mercy of software suppliers for ensuring that critical applications are secure.

At best, businesses have to rely on the software supplier’s assurances that the software has been tested and that it has passed those tests.

But as cyber attackers shift focus from operating systems to exploiting weaknesses in business applications, secure coding has never been more important.

It is widely recognised in the security industry that any commercial organisation that values its security is well-advised to perform a security test of any software before deployment.

For this reason, many in the security industry believe the time has come for a shift in power from supplier to buyer, but for this to happen, security professionals within organisations need to ensure that security testing becomes part of the procurement process for all business software – and therein lies the challenge.

Procurement and security are uneasy bedfellows, mainly because commercial teams want things to be done quickly, simply and as cheaply as possible, while security introduces delays, complexity and cost.

So what is to be done? How can security professionals ensure security testing is part of procurement?

Raise security awareness and control testing

Security should mandate testing, and advise as to why this is necessary, says Robert Newby, an analyst and managing partner at KuppingerCole UK. 

"Procurement should be seeking to lower risk to the business in their processes, but sadly, a lack of awareness of security may make this a difficult task," he says.

Software is a seemingly benign way to gain absolute access to your network – an open window even when your doors are firmly locked

Robert Newby, KuppingerCole

Therefore, 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," says Newby. 

He believes security professionals can communicate with the business by talking in terms of risk, and this can translate simply to commercial teams in terms of cost.

"Software is a seemingly benign way to gain absolute access to your network – an open window even when your doors are firmly locked," says Newby.

"The cost of not treating this is simple, it could cost you everything you hold electronically within your company network, all IP, customer records, credit card information, designs, processes and developments, not to mention brand and reputation," he says.

Conversely, the cost of addressing this in a procurement cycle can be low, and if companies state it as a requirement, says Newby, many software houses will meet the cost of security checks themselves.

Security professionals therefore need to be more business aware, he says, and not assume that their colleagues have the same grasp of the technical details.

"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," says Newby.

Software code must be secure at the procurement stage

Another key strategy for information security professionals is to ensure they are plugged in to the procurement process, says Peter Wenham, committee member of the BCS Security Forum strategic panel and director of information assurance consultancy Trusted Management.

"Security professionals need to work tirelessly to ensure that when projects are mooted – that is before they are actually funded – that they are well and truly plugged into the purchasing and/or tendering processes," he says.

Recommendations from Corporate IT Forum members

  • Implement and maintain a secure software development process.
  • Subject new software development commissions to a risk assessment – for example, the type of data being processed and the impact of a potential breach.
  • Get the development team and business sponsor to identify threats at the beginning of the process.
  • Train developers (or certify that they are trained) in secure coding and make sure they have a secure standard to work to.
  • Review code manually and, as a final check, carry out a supplementary automated review. Subject third parties and any OS (operating system) element to review. Repeat through the cycle of development
  • Carry out testing at each development phase. Pen-test internet-facing apps as a final action. Pen-test internal apps if required by the data being processed.

According to Wenham, this applies equally if software code is created in-house or purchased from an external supplier. 

"Where code is to be developed externally, the security professional needs to ensure that clauses are included in the contract of supply that call for the code to be developed using current accepted industry good practices for the delivery of secure code and outlining the acceptance/rejection process for that developed code," he says.

For internally developed code, Wenham says the security professional should ensure that internal procedures call for code to be developed with security in mind and is well documented.

"On the project side, the security professional needs to ensure that all code received, irrespective of it being bespoke, commercial of the shelf (COTS) or internally generated, is passed through a 'sheep dip' process to test for viruses and malware," he says.

Wenham believes the code should be checked by two different commercial antivirus products during this sheep dip process, and that the security professional should also ensure that the project allows for a test environment where code can be run as if it were in production to ensure that it is “well behaved” and not doing anything that would compromise security.

While large and complex projects may well have multiple test environments to undertake basic testing, check integration with other project components, and test performance and user acceptance, Wenham points out that small projects may have to rely on good and well documented back-out procedures so that any received and sheep dipped code can be run directly in production.

"Finally the security professional needs to ensure that any project has appropriate and effective mechanisms in place to reject faulty code, together with metrics that clearly define the accept/reject parameters which should tie back to a contract or internal project specification," he says.

To bring about a real shift in the balance of power, customer organisations need to make it clear they will not buy unless their security standards are met, says Vladimir Jirasek, managing director of Jirasek Consulting Services.

Due diligence should include testing

Most organisations rely on software developed by someone else, but Jirasek suggests that as a standard part of any due diligence process, every application should pass a few tests.

First, it must fit the overall enterprise application architecture; second, it must meet business continuity requirements; and third, it must meet security requirements.

The problem is that many organisations do not have an enterprise architecture function established and do not involve their security team in testing new external applications

Vladimir Jirasek, Jirasek Consulting Services

"The problem is that many organisations do not have an enterprise architecture function established, have not done business continuity testing, and certainly do not involve their security team in testing new external applications," says Jirasek.

A review of the due diligence process is a good place to start, says John Colley, European director for (ISC)2

"Within security we lament an inability to be more involved in the software and systems development lifecycle, but with third parties playing a significant role in what is very often a complicated supply chain, a lot can be achieved in reviewing the quality of due diligence that is applied," he says.

Security professionals, says Colley, have the ability to review and understand providers’ overall software development process, their approach to security, testing and requirements analysis in the design.

"We can specify expectations in these areas or pose questions that are often missed, around their use of code libraries, other third parties or their appreciation of misuse, as well as use cases, professional credentials for security in software, and the like," he says.

When procuring off-the shelf packages, Colley says the ability to apply due diligence is more limited, but research can still be done. 

"Take a look at customer forums and comment, or ask for and speak to references, so you can learn about and assess the complications they may have faced post implementation," he says.

Security professionals must get involved 

Jirasek laments that often the first information security professionals learn of a new application is through internal communication stating the application’s launch date. But there a several things a security professional can do to ensure security testing is done before implementation, he says.

First, security professionals should update procurement policies and processes to include security team involvement.

"Most procurement teams are remunerated based on the discount they negotiate. A security manager could argue that the company should get a discount, based on the number of security issues discovered in the application software. That way, procurement is more likely to involve the security team; indeed no security is without faults, so some discount is going to be found," he says.

An IT health check should be an integral part of the commissioning and testing process for new software, regardless of its function

Mike Gillespie, The Security Institute

Second, information security professionals should partner with an application testing company that is set up to test applications written in different programming languages, says Jirasek.

"If the software supplier has already tested its application, perhaps the testing partner can work with it to normalise the test results. The outcome from this step is a score that is passed to procurement," he says.

Finally, Jirasek recommends that information security professionals update security policy so applications that score outside the desired value are not allowed on the enterprise network.

Having a security presence in the boardroom absolutely ensures that security becomes an embedded process throughout an entire organisation, says Mike Gillespie, director of cyber research and security at the Security Institute.

"Until this happens and security is involved in all relevant purchasing activity, then fire fighting and additional expense from playing security catch-up will continue," he says.

Gillespie also believes that security professionals need to be in a position to bring pressure to bear on the supply chain to encourage accountability and insist that software should be secure at purchase.

"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 expanded to include the seller security person talking to the buyer security person," he says.

This approach can cover key risk areas in an appropriate manner and the buyer knows precisely what they are buying before money changes hands, says Gillespie.

"An IT health check should be an integral part of the commissioning and testing process for new software, regardless of its function," he says.

If security at the buyer side covers questions with security from the supplier on the results of testing, the way forward starts to look far more clear, logical and secure, says Gillespie.

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

Benefits of security-aware procurement

In summary, KuppingerCole UK’s Newby says a properly implemented secure development lifecycle can be of real value to a development company, and 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 serious account.

(ISC)2's Colley says security professionals must always understand that commercial imperatives may outweigh their own. “But until we take the steps to become better informed about the risks that are being taken, no one can be in a position to make this assessment,” he says.

And pointing to the increasingly comprehensive information that is available on structuring software testing activities from organisations such as Enisa, Nist and Owasp, there is no longer any excuse for buying software with poor security, says analyst firm Gartner.

Tips on acquiring new software

Given all this complexity and variation, it is vital to set the right expectations and create a solid process when acquiring business software, writes Ramon Krikken, research vice-president in Gartner's technical professionals security and risk management team. The following are important technical and non-technical tasks:

  • Commit to making security a part of the acquisition. As with in-house development, business users first have to want security as a required aspect of overall quality. A critical part of creating this commitment is communicating with them about risks and rewards, and establishing mutually agreed goals.
  • Find the right process touch points. Mandatory security checkpoints in project management, contract review and sourcing are a must. But since the availability of free and pay-as-you-go software makes it easy for individual business users to acquire software by themselves, additional tools will probably be needed to discover installed software and cloud application use.
  • Tailor testing activities to the software and sourcing type. All software should be security-tested at least once before it goes into production, but not all software needs be tested equally often or in equal depth. Look for some combination of the following: supplier process and testing evidence; third-party testing evidence; third-party certifications and validations (for what they are worth); in-house testing during coding and testing (for some outsourcing); pre-release in-house testing; and testing of software once deployed in production. In all cases, test against documented requirements.
  • Put your expectations of the supplier in writing. Except for full off-the-shelf products or SaaS, create specific contract clauses for the following: the security requirements; how the supplier will show evidence of software security testing processes and outcomes; the security go/no-go criteria for acceptance; in what way, and how quickly, the supplier will communicate discovery of non-trivial vulnerabilities; the allowable time-to-fix for non-trivial vulnerabilities; and the penalties for non-compliance.
  • Gear up for in-house security testing. Organisations should be ready to perform their own application security tests, whether they use a product or a service to do this. Any deployment that isn't completely off-the-shelf is a candidate for in-house testing, even if only to validate the supplier's tests. Some security problems won't show up until deployment into an organisation's staging or production environment, so such testing is very desirable.
  • Prepare mitigation tactics. Since most software cannot be guaranteed to be vulnerability-free, and most discovered vulnerabilities cannot be fixed overnight, the ability to isolate vulnerable assets, block attacks or at least detect attacks is essential as a back-up. To come full circle, it can also help to identify previously unknown security vulnerabilities.

Read more on Security policy and user awareness