Patchwork security through the PATCH Act [Commentary] The government has responded to the recent WannaCry ransomware outbreak, which used stolen NSA cyber tools – EternalBlue and DoublePulsar. On May 17, 2017, a bipartisan group in the Committee of Homeland Security and Governmental Affairs introduced the PATCH Act of 2017, short for the Protecting our Ability to Counter Hacking, with the aim of adding transparency to the U.S. government’s process for disclosing flawed or vulnerable computer code found in commercial products, services, applications, or systems. The PATCH Act codifies the circumstances in which government agencies are required to disclose any of their zero-day vulnerabilities. In theory, it sets up a consistent and transparent process for decision-making. It promises to create new oversight mechanisms to improve accountability, while enhancing public trust in the process. The government will be required to alert vendors and the public if any of its zero-day attacks become publicly known. Since zero-days attacks are unknown, it’s hard to say what this act actually covers. As it is written, the PATCH Act states that a classified vulnerability will not be considered “publicly known” if it has been “inappropriately released to the public.” This means that a stolen NSA tool can circulate widely among third-parties without triggering any sort of mandatory disclosure. This is clearly a flawed approach. In addition to overlooking attacks such as WannaCry ransomware, the bill excludes cases where a third-party provides a “black box exploit.” There are many concerns pertaining to the proposed Patch Act. First is perception of neutrality, since currently it is handled by NSC. Secondly, it is not clear whether the project can receive sufficient funding given partisan politics in D.C. And lastly, the legislation does not provide for a staff or a secretariat for the board, and there is a large workload to manage that is not accounted for. No one questions the authority of intelligence agencies to conduct lawful surveillance of computer systems and endpoints; the question is whether these agencies must be required by law as the PATCH Act mandates to function as the equivalent of commercial quality assurance teams- in other words, whether taxpayers should subsidize the work of software and hardware vendors. A more prudent approach would be to require vendors to test for vulnerabilities as part of the product development lifecycle through static and dynamic code analysis. This can be further enhanced by mandating timely fixes to discovered vulnerabilities and requiring mid-sized to large companies to deploy vulnerability assessment and patch management solutions. Here’s how we can address both known and unknown vulnerabilities in products: Software developers should be required to test products during the product development lifecycle so that vulnerabilities can be discovered and handled before product release. Early in the code writing process, static code analysis can play a pivotal role. Before a product is released in the market, tools like automated fuzzing and protocol analysis can significantly reduce the potential for security problems discovered after release. End users of software products may have to be mandated to deploy vulnerability assessment and patch management solutions in their operating networks and make commercially reasonable efforts to discover vulnerabilities and patch them in a timely manner. To believe that mere legislative action will assure cybersecurity is a fool’s errand. We have learned by now that cybersecurity is a layered defense involving technology, people and processes. All we can aim for is to minimize our security exposure surface, thus choose your people and technology providers carefully. Hamid Karimi has extensive knowledge about cybersecurity and for the past 15 years, his focus has been exclusively in the security space covering diverse areas of cryptography, strong authentication, vulnerability management, malware threats, as well as cloud and network protection. He is the VP of Business Development at Beyond Security, a provider for automated security testing solutions including vulnerability management, based out of Cupertino, CA.