Sometimes it really is easier to buy software off the shelf. When faced with an automation requirement, there are two basic options: buy or build. If there is a commercial off-the-shelf (COTS) product that meets the requirement, buying off the shelf often seems like an easy decision.
COTS solutions can reduce development time, because components or applications can be purchased or licensed instead of being built from scratch. This helps the bottom line via significant savings in procurement and maintenance costs.
COTS software can be tested and proven in other organisations before you make your adoption decision. A COTS product’s reputation for quality and effectiveness could be a major reason why you should consider it for inclusion in your enterprise.
In recognition of the steep cost of software development and maintenance, COTS is being mandated across many government and business programs, so the buy-or-build decision may not be an option. COTS software can also be more vulnerable, because it is better known to software hackers.
Can you maintain security when buying off the shelf?
Even in software, off the rack doesn’t always mean ready to wear. With COTS solutions, you don’t have control of the source codes, or of the software development process, and you are at the mercy of the vendor’s schedule and willingness to provide updates and fixes.
Integrating COTS components into your environment can cut into the initial savings in development time. But what will you do if the vendor significantly changes the function of the product, doesn’t support features you need in the future, sells it to another vendor or possibly even goes out of business?
COTS software can also be more vulnerable, because it is better known to software hackers. A single security bug is all it takes to compromise your enterprise data—and hackers will hunt for that bug until they find it. The more locations where software is installed, the larger the payoff for the hacker who finds the security hole.
Checklist when verifying COTS:
- Perform an enterprise-wide baseline audit of all your COTS assets to determine your current risk vulnerability. Be certain the audit includes a risk analysis and threat assessment for each application that relies on them and ensures that the software undergoes security review
- Establish clear security standards and metrics for approving any new COTS applications as part of the procurement process itself (not as a security review after products have been chosen)
- Review the patch history, security certifications and track record of a vendor before settling on a solution. Reject vendors that do not fix known security vulnerabilities in a timely manner
- Determine whether the application vendor prioritises security bugs in their software over quality bugs. You should formally demand proactive, swift and rigorous policies from the vendor for correcting security vulnerabilities after deployment
- Formally require vendors to make available the results of both static and dynamic binary security scans of their code
- Set up a security patch management policy and review process with clear metrics that demonstrate that patches and updates are tested for security vulnerabilities before they are accepted and applied
- For mission-critical applications, formally require that the vendor put the source code into a trust administered by a third party (escrow), in case the vendor goes out of business or other failure of service or support occurs
- Be aware that customisations you make to off-the shelf software that is itself secure could introduce vulnerabilities. Create a security architecture and engineering review board to vet and approve code that modifies or interacts with COTS applications
- Implement a Secure Development Life Cycle to ensure that applications are built with security as an explicit requirement. Require your vendors and partners to do the same.
Many of these steps include a formal requirement. This means that this requirement should be formalised in your legal purchase agreement with the COTS vendor. Many COTS vendors refuse to modify purchase agreements for small- or medium-sized customers. If you cannot get vendors to legally agree to these requirements, consider starting a user’s group where multiple customers with the same requirements can speak to the vendor as a single organisation with a larger purchasing power.