In a recent blog post, I discussed limitation of liability clauses in technology contracts. Given the favorable response to that post, I thought it would be of interest to discuss another misunderstood and frequently neglected area of technology contracting: information security warranties. Let me be more specific. Most well-drafted technology agreements contain specific warranties and other protections relating to the protection and security of data shared with the vendor. While clearly important, contract protections should not stop there. Rather, it is becoming a contracting best practice in the industry to also include one or more warranties specifically directed at ensuring the vendor has integrated information security into the overall development of its products. It is this area that is frequently overlooked and too often misunderstood.
These types of warranties try to address the problem of thoroughness in addressing information security whether the vendor is attempting to “bolt-on” security measures to an already developed product or has developed the product with information security in mind from the time of inception. In addition, these types of warranties are directed at ensuring the vendor hasn’t incorporated orphaned code into its products.
Those of you who read this blog regularly will recall I previously provided a checklist of information security warranties, including the kind of warranties we are discussing today. Here, however, we will talk about the specifics of those warranties in detail.
Securing Development Warranties
In the current technology environment, it is critical to ensure that vendors commit to a development environment for their products that represents best practices for assessing and testing security. The linchpin of this protection turns on conducting an appropriate code review. To that end, the warranty generally requires the vendor to use a third-party nationally recognized auditor specializing in code reviews to conduct the security assessments or allows the vendor to conduct its own security assessments, provided that the 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 [CSSLP] or GIAC Secure Software Programmer certification), follow industry standard best practices, and promptly share the results for the customer’s review and approval.
Consider one potential way this might be written as a contract warranty:
Secure Development. With regard to any Product, Vendor warrants it will use industry best practices for secure coding (e.g., the CERT Secure Coding Standards, ISO 27034, etc.), including integrating security measures into the development process, conducting comprehensive security testing of al software and other coding, and using automated code vulnerability assessment tools. Testing should include, where appropriate, but not be limited to, cross-site scripting, parameter tampering, hidden field manipulation, backdoors and debug options, stealth commanding, application buffer overflow, cookie poisoning, third-party misconfigurations, HTTP attacks, SQL injection, and other known vulnerabilities. Vendor will document all identified vulnerabilities and their remediation. Vendor shall make such documentation available to the Customer in the form of a written report.
Known Vulnerability Warranties
Closely associated with the secure development warranty, described above, is a warranty that the vendor has complied with specified standards and testing procedures designed to assess the overall security/vulnerability of its products. 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 can be accomplished by testing the product on a routine basis for any vulnerability or exposure identified in MITRE’s Common Vulnerabilities and Exposures (CVE), located at http://cve.mitre.org, and by having a Common Vulnerability Scoring System (CVSS) score of, say, 4 or higher. Vulnerabilities are labeled “Low” severity if they have a CVSS base score of 0.0-3.9. Vulnerabilities are labeled “Medium” severity if they have a base CVSS score of 4.0-6.9. Vulnerabilities are labeled “High” severity if they have a CVSS base score of 7.0-10.0. Depending on the engagement, the customer can select how much risk it is willing to take by setting the acceptable vulnerability score.
Here is an example of a warranty drafted to address known vulnerability testing:
Known Vulnerability Testing. In addition to all other security obligations under this Agreement, Vendor represents that it shall test all Products, including all embedded third-party software, in accordance with best industry practices, but in no event on less than a quarterly basis, for any vulnerability or exposure identified in MITRE’s Common Vulnerabilities and Exposures (CVE), located at http://cve.mitre.org, and having a Common Vulnerability Scoring System (CVSS) score of 6 or higher (as published by the NIST National Vulnerability Database, located at http://nvd.nist.gov). In the event such a vulnerability with a CVSS score is identified, Vendor will, at no additional charge to Customer, promptly remediate the vulnerability. Vendor shall keep complete and accurate records of its testing and remediation activities under this Section.
Orphaned/abandoned code warranties
As noted above, the other key area for security warranties is protection from orphaned or abandoned code. In particular, the use of open-source software in commercial products is now widespread. Many commercial products include dozens of such applications. Security researchers have found that orphaned code (i.e., code that is no longer actively supported or under development) can pose a serious security threat. In some instances, vendors are using code that has not been updated in years. To address this area of vulnerability, vendors should be required to warrant that no such outdated, abandoned, or orphaned code is present in their products.
A potential warranty for this type of orphaned software is as follows:
No Orphan Code/End-of-Life Products. Vendor represents and warrants that (i) no programming furnished to Customer will contain any orphaned code, as defined below, and that (ii) no hardware or software products, including operating systems and embedded software, or any component thereof, contain any hardware or software designated prior to the Effective Date as End-of-Life (i.e., no longer supported and updated by the manufacturer or licensor). For purposes of this Section, orphaned code means software that (a) has had more than one year since its last release or update; (b) does not have an identified individual responsible for supporting and maintaining the code; or (c) the identified individual’s contact information is no longer valid.
Of course, the foregoing potential warranties are merely possibilities. Specific engagements may require greater or lesser levels of protection. What these examples do provide, however, is insight into how common security standards may be incorporated into contract language to ensure vendors furnish products with appropriate information security protections.
