The technology environment in almost every business is composed of an amalgamation of dozens, if not hundreds, of technology products. These products may be traditional software packages, open source software, hardware products, IoT devices, cloud services, etc.
A security vulnerability in any one of these products may create a risk not only for that particular product, but for the business’ entire network.
As an example of this “weak link” problem, consider recent attacks on IoT devices. In 2016, the largest DDoS attack ever launched was based on an IoT botnet. This attack led to substantial portions of the internet going down.
The complexity and interdependence of systems and networks will only increase in the future. One means of better addressing the risk presented is to ensure product vendors use best practices to ensure information security is integrated into those products from their inception.
All too often, however, information security is relegated to limited testing after a product has been manufactured.
In purchasing a technology product, businesses should at least consider discussing these four areas with vendors and potentially incorporate them into final vendor agreements:
1. Viruses and other harmful code
Anti-virus and harmful code warranties are now common in the industry. Almost every technology agreement should be drafted to include, at minimum, a warranty that the vendor will use industry best practices to scan and remove malware from their products prior to delivery.
2. Orphan software
The use of open source software in commercial products is widespread. Many commercial products include dozens of such applications. Security researchers have found that “orphaned” open source (i.e., open source that is no longer actively supported or under development) can pose a serious security threat. In some instances, open source applications are being used that have not been updated in years.
Orphan software can also refer to commercial applications that have reached end of life and are no longer supported by their developers (e.g., an outdated version of Windows). Given the risk presented by using such software, businesses should consider including a warranty in their vendor agreement preventing the inclusion of such unsupported code.
3. Best practice development
Consider ensuring the vendor commits to a development environment for its code that represents best practices for assessing and testing security. For example, the vendor may be required to either (i) use a third-party, nationally recognized firm specializing in code reviews to conduct the foregoing security assessments; or (ii) conduct the security assessment review itself, provided that the vendor personnel performing the review are experienced in conducting reviews of this kind, hold an industry-recognized certification in security assessments for software (e.g., Certified Secure Software Lifecycle Professional or GIAC Secure Software Programmer certification), follow industry standard best practices for such assessments and ensure assessment results are promptly shared with the customer for review and approval.
4. Vulnerability testing against known databases
This is a new critical area of protection. The vendor may be required to warrant conformance with specified standards and testing procedures designed to assess the overall security/vulnerability of the product. At its most basic level, this is an obligation to check the product against the most common security vulnerabilities by recognized organizations in the security industry (e.g., OWASP Top 10 Vulnerabilities; CWE/SANS Top 25 vulnerabilities). This is done through testing the product on a routine basis for any vulnerability or exposure identified in Mitre’s Common Vulnerabilities and Exposures and having a Common Vulnerability Scoring System score of, say, 4 or higher.
While not all these areas may be applicable in every acquisition of new technology, they should be considered at least as a checklist for discussions with the vendor. Vendors who offer products with few or none of these protections should be closely scrutinized.
[Disclaimer: The information on this blog or article is provided without any warranty or guarantee, does not provide legal advice to the reader, and does not create an attorney-client relationship with the reader. Any opinions expressed in this blog or article are those only of the author and do not necessarily reflect the views of the author’s law firm or any of the author’s or the law firm’s clients. In some jurisdictions, the contents of this blog or article may be considered Attorney Advertising.]
This article is published as part of the IDG Contributor Network. Want to Join?