Security Think Tank: Risk of software procurement cannot be ignored

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

The procurement and development of software are risks to the enterprise, writes Ollie Ross, and – like all risks – must be assessed and classified: Will the application or service be located internally or externally? Will it be protected by enhanced security systems? Should it be subject to full penetration-testing (preferably conducted by an external security specialist)?

To ensure software security testing becomes standard for procurement, Corporate IT Forum members recommend making sure security is part of the MoSCoW or equivalent analysis to reach a common understanding with stakeholders and writing security in to any contractual agreements, possibly supported by a third-party review for high-risk applications such as card or sensitive data processing.

Buy applications designed to a security standard or confirm a supplier holds an appropriate standard as part of their credentials – the payment card industry data security standard (PCI DSS) asks some good questions as part of the requirements to assess a company against.

Assuring security testing for in-house development requires close engagement between security professionals, the procurement function and, ideally, the business analysts working on the capability. Good stakeholder management goes a long way towards getting security "baked-in at the start" and ensuring appropriate, non-functional requirements around security testing are brought into scope for the task assurance. Identifying a standard to which testing should be completed will help to bake it in properly.

Corporate IT Forum members make the following recommendations:

  • 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 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 operating-system element to review. Repeat through the cycle of development;
  • Carry out testing at each development phase. Penetration-test internet-facing apps as a final action. Penetration-test internal apps if required by the data being processed.

Ollie Ross is head of research at The Corporate IT Forum

Read more on Application security and coding requirements