It is a fact of IT life that new application vulnerabilities are created and discovered every day.
On the one hand, the increasing complexity of software and the software supply chain makes it almost impossible to guarantee that software is vulnerability-free. On the other hand, application security testing has become so much better, cheaper and easier that software suppliers have no excuse but to test their offerings to avoid the proverbial "holes so large you could drive a truck through them".
Ensuring appropriate testing of all software is not a trivial matter.
The category of business software covers a wide area: from desktop tools to enterprise resource planning (ERP) suites; from file-sharing services to software as a service-based (SaaS) customer relationship management (CRM); and from e-commerce platforms to other customer-facing applications that may even include wearable technology and "smart-something" devices.
Similarly, acquisition encompasses a variety of off-the-shelf and outsourced sourcing models.
Given all this complexity and variation, it is vital to set the right expectations and create a solid process when acquiring business software. The following are important technical and non-technical tasks:
More from Computer Weekly's Security Think Tank
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 is not completely off-the-shelf is a candidate for in-house testing, even if only to validate the supplier's tests. Some security problems will not 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 backup. To come full circle, it can also help to identify previously unknown security vulnerabilities.
Given all the help available, there is simply no excuse for buying software with shoddy security
Ramon Krikken, Gartner
Whatever the type of software and sourcing model, application security testing is vital when acquiring business software.
Information on structuring these testing activities is becoming more comprehensive. Look to organisations such as the European Union Agency for Network and Information Security (ENISA), the US National Institute of Standards and Technology (NIST), the US Department of Homeland Security (DHS), the Software Engineering Institute (SEI) at Carnegie Mellon University, and the Open Web Application Security Project (OWASP) for presentations and documents on software supply chain assurance, software assurance for acquisitions and related topics.
Given all the help available, there is simply no excuse for buying software with shoddy security.
Ramon Krikken is a research vice-president in Gartner's technical professionals' security and risk management team.
This was first published in November 2013