What are Commercial Off-The-Shelf (COTS) Software, Services, Solutions and Hardware?
Commercial off-the-shelf or commercially available off-the-shelf (COTS) products are packaged (ready-made) hardware or software, which are typically purchased or licenced from a software vendor, and adapted aftermarket to the needs of the purchasing organization. Services associated with the commercial items may also qualify as COTS, including cloud services.
COTS solutions contrast to bespoke in-house applications that are commissioned by or developed within an organisation (or by a contractor on its behalf) typically for its own exclusive use in the form custom-made, or bespoke, solutions.
Many organisations may procure, operate and make use of a mix of both bespoke in-house and COTS web services within their estate.
What are some types of COTS Software and Services?
COTS solutions may in their broadest sense be delivered by a software vendor in any one of a number of forms including:
- "Shrink-wrapped" software distributed on media for installation on customer equipment
- Downloadable executable and binaries for installation on customer equipment
- On-premise leased or purchased physical appliances deployed in customer operated site or data centre
- On-premise licenced or purchased virtual appliances deployed in customer operated site or data centre
- On-premise container image deployed in customer operated site or data centre
- Software As A Service (SaaS) hosted by software vendor, either as a dedicated or shared instance
- Cloud (e.g. AWS/Azure) services
What are some examples of COTS Software and Services?
Some commonly encountered COTS may include:
- Platforms as a Service (PaaS) examples include Amazon Web Services (AWS), Heroku, Microsoft Azure, and Oracle Cloud;
- Infrastructure as a Service (Iaas) examples include Google Cloud Platform (GCP), Linode, Nimbus, OpenNebula, Rackspace Cloud and OpenStack;
- Common Cloud Application examples include SalesForce, WorkDay, DropBox and Microsoft Office365/OneDrive;
- Physical appliances depoyed on-premise may include network equipment (Routers, Gateways, Load Balancers), security equipment (Firewalls, IPS/IDS, VPN Concentrators), and email appliances (e.g. Sophos, SonicWall)
What are some reasons it may be unnecessary to scan COTS Software and Services?
Because COTS operates on a "build once, use many times" model, it is commercially possible to spread development and testing costs of a solution across every customer purchasing or licensing the appliance or service. This means that due to economies of scale, it is very common for vendors to invest in sophisticated and ongoing security testing of their appliance, solution or software themselves, providing some assurance that the software or service is secure as-shipped/deployed, and negating the need for scanning of a given instance by the customer (in theory).
What are some reasons it may be beneficial to scan COTS Software and Services?
While true in theory, there is a long history of vulnerabilities in COTS software and it has proven to be susceptible to security flaws - the entire Common Vulnerability Enumeration (CVE) programme is based around tracking and cataloguing all such vulnerabilities with unique IDs. It cannot therefore be assumed that just because software, service or appliance is commercially-sourced that it ships in a secure state and that scanning it might not detect vulnerabilities. Simply being COTS software or service does not necessarily imply the lack of a fault history or transparent software development process.
According to the United States Department of Homeland Security, software security is a serious risk of using COTS software. If the COTS software contains severe security vulnerabilities it can introduce significant risk into an organization's software supply chain.
Additionally, although COTS products can be used out of the box, in practice the COTS product or service instance is often customised - or at least configured - on a per-customer basis, in order to achieve the needs of the business and integrated to existing organizational systems: this configuration and customisation means that no two instances are exactly the same, and some may be configured in an insecure state. Scanning would assist in detecting these configuration flaws.
What are some of the challenges of scanning COTS Software and Services, and should AppCheck be used to scan them?
Typically if a COTS solution is located "on-premise" (that is as a physical or virtual appliance deployed on a customer site) then it is possible and worthwhile for AppCheck to be used to perform both an infrastructure scan of it, as well as a web service scan of any exposed HTTP services such as HTTP service or administrative interfaces.
However, if the COTS solution is based in the cloud or deployed as a multi-tenanted (shared) SaaS solution then there may be Terms of Service that prevent or restrict permitted scanning. In these instances, you should check with the vendor to find whether scanning is permitted, and under what if any restrictions.
How can I check if I am permitted to scan a given third-party SaaS solution?
You should always check the website of the solution in question and try and determine their acceptable usage policy or terms of service.
There is no standard location for this to be found on any given website, but the following are two common places where you can find such information:
- Firstly, many websites now use the "security.txt" file. This is a security.txt file located under the ".well-known" directory of the website - e.g. for the www.example.com domain, this file would be located at https://www.example.com/.well-known/security.txt . The file will typically contain links to information such as testing/scanning policy for that domain.
- Secondly, the website may take part in a "bug bounty" program such as HackerOne (see https://hackerone.com/directory/programs) and the program details (if listed) will often include terms and conditions on permitted scanning or security testing of the website in question.