Regulations Surrounding Third-Party Software Security Are Increasing: How to Stay Compliant

Developers are increasingly being pushed to create more code faster. As the speed of development increases, it becomes less feasible to create every application from scratch. In turn, the reliance on third-party applications and code increases as well. But this “short cut” comes with risk. Third-party applications and open source components frequently contain vulnerabilities, leaving organizations at risk of breach and, increasingly, regulatory fines. As breaches proliferate through third-party applications and code, regulators are taking notice. Here’s a sampling of current regulations surrounding third-party software, and this is certain to be only the beginning.

Regulations That Will Look at the Security of Open Source Components

There are several industry regulations and security frameworks that require that you find and patch known vulnerabilities in your applications, including:

• PCI DSS 6.1/PA-DSS 7.1: Requires the establishment of a process to identify security vulnerabilities, using reputable outside sources for security vulnerability information, and assign a risk ranking (for example, as “high,” “medium” or “low”) to newly discovered security vulnerabilities.
• Financial Services Information Sharing and Analysis Center (FS-ISAC): In its guidelines, "Appropriate Software Security Control Types for Third Party Service and Product Providers," this Working Group recommends financial services member firms adopt three control types. Control 3 is “policy management and enforcement for consumption of open source libraries and components.” In addition, it recommends a bill of materials that clearly identifies the open source code libraries that are part of a commercially developed software package offered to financial service firms. The Group states that it “believes that each of the three control types is required for financial institution member firms to achieve third party software security.”
• NIST 800-53 Security and Privacy Controls for Federal Information Systems and Organizations (SA-12, Supply Chain Protection).
• NIST 800-161 Supply Chain Risk management Practices for Federal Information Systems and Organizations (CM-8, Information System Component Inventory).
• HITRUST CSF v8 (Control of Technical Vulnerabilities): The HITRUST CSF was developed to “address the multitude of security, privacy and regulatory challenges facing healthcare organizations.”
• OWASP Top 10 compliance (referenced in compliance criteria such as those put forth by PCI Council, NIST, HIPAA, SOX, FTC, ISO 27k, DoD, etc.): Requires organizations to maintain an inventory of third-party components and libraries and monitor that inventory for known security vulnerabilities.

Regulations That Will Look at the Security of Third-Party Applications

There are also several industry regulations and security frameworks that require that you assess the security of applications your purchase. These regulations include:

• NIST special publication 800-161: “Information and communications technology supply chain risk assessment should be integrated into the overall enterprise risk assessment processes throughout the organization.”
• PCI 3.2, Requirement 6.3 extends the secure software development mandate to include all custom, third-party developed software.
• OCC: Asks banks to effectively manage the risk associated with the use of third parties.
• FS-ISAC: Control 2 recommends the use of binary static analysis for an assessment of third-party software products.
• MAS, Monetary Authority of Singapore: Section 5 calls for management of IT outsourcing risks. This section states that service providers should implement security policies, procedures, and controls that are at least as stringent as for their own operations.
• EU General Data Protection Regulation (GDPR) Article 26: This article states that, in choosing a data processor (outside vendor), “the controller shall select a processor providing sufficient guarantees to implement appropriate technical and organisational measures and procedures in such a way that the processing will meet the requirements of this Regulation and ensure the protection of the rights of the data subject.”
• New York DFS Cybersecurity Regulations Section 500.11 Third Party Information Security Policy: This section includes the requirement that “Each Covered Entity shall implement written policies and procedures designed to ensure the security of Information Systems and Nonpublic Information that are accessible to, or held by, Third Party Service Providers. Such policies and procedures shall be based on the Risk Assessment of the Covered Entity and shall address to the extent applicable.”
• HITRUST CSF Control 10.a, Level 2 outlines that “specifications for the security and privacy control requirements shall include that automated controls be incorporated in the information system…Commercial products sought to store and/or process covered information shall undergo a security assessment and/or security certification by a qualified assessor prior to implementation (Not applicable to operating system software).”