Understanding and Addressing the Threat
Just days into 2018, news broke of two significant vulnerabilities that have been lurking in CPUs for nearly two decades. The public identification of Meltdown and Spectre are sobering reminders that even the highest quality technology can contain flaws. In fact, such vulnerabilities are practically inevitable. So, too, are the hackers who will try to exploit these vulnerabilities to their advantage and to your institution’s detriment.
In order to address vulnerabilities properly, it helps to have a thorough understanding of the different types that exist.
Known Versus Unknown Vulnerabilities
Vulnerabilities are unintended flaws in either hard or soft technology that unauthorized users can exploit to their advantage. There are individuals who make careers out of trying to find these flaws, many of whom begin their search into new technology as soon as it is released. Some are good guys, such as the researchers who discovered and publicized Meltdown and Spectre. But there are many others who either exploit the flaw themselves or sell knowledge of it to other cybercriminals.
Known vulnerabilities are categorized based on how, or with whom, the flaw is shared:
- CVE-assigned: A vulnerability that has been discovered and reported to the non-profit organization MITRE, which assigns it a Common Vulnerabilities and Exposures (CVE) identifier (a combination of the discovery year and a unique number). For example, Spectre was assigned CVE-2017-5753 and CVE-2017-5715 and Meltdown was assigned CVE-2017-5754. Most vulnerability scanners search for CVE-assigned vulnerabilities.
- Internet-disclosed: This vulnerability has been disclosed on the Internet but does not have a CVE. These are typically less serious flaws; either not getting exposure or being shared only within a closed community. In any event, cyber attackers definitely know about them.
- Open Database-stored: A vulnerability that has been published by other security-related organizations, such as Red Hat. Security news source CSO Online indicates that, “A vulnerability in an open database is nearly as known as those with a CVE. It’s stored in a public location that is available to defenders and attackers both, and informs both about the risk involved.”
- Known But Not Disclosed: These are typically vulnerabilities that are newly discovered by the technology developer but not yet publicly disclosed.
Unknown vulnerabilities fall into two categories: not yet discovered, or discovered by a hacker but only shared (i.e., sold) on the darknet. The latter is often referred to as a zero-day vulnerability.
Most Breaches Derive from Known Vulnerabilities
Intuitively, it may seem that an unknown vulnerability poses the bigger threat. However, most security experts warn the opposite is true. For example, CSO Online indicates that, “zero-day vulnerabilities definitely matter, but the likelihood of attackers using them (before they’re made publicly known) is far lower than truly known vulnerabilities.”
In an opinion piece for The Hill, Guy Podjarny, CEO of Snyk, a company that finds and fixes vulnerabilities in open source code, explains why known vulnerabilities pose such a threat. Most hackers avoid the arduous and costly task of finding flaws themselves, and instead wait and watch for a vulnerability disclosure, the moment Podjarny calls pivotal. Yes, the disclosure “makes defenders aware of the problem, and offers them a chance to fix it. However, it also informs attackers it exists, giving them a chance to find and exploit this flaw.” He likens the disclosure moment to the starting bell of a race: Attackers compete to exploit the flaw before it can be patched, while defenders work to try to patch the flaw before it can be exploited.
Unfortunately, the attackers appear to be winning this race far too often, and by a significant margin. Rene Gielen of Apache Struts, an open-source web application, noted in Wired that, “Most breaches we become aware of are caused by failure to update software components that are known to be vulnerable for months or even years.”
Recent Examples of Known Vulnerability Exploits
Two of the biggest news stories of 2017 were related to cybersecurity, and they bear out Gielen’s point. Rik Ferguson, vice president of security research at Trend Micro, agrees. Infosecurity quotes him saying that, “Many devastating cyberattacks in 2017 leveraged known vulnerabilities that could have been prevented had they been patched beforehand.”
See for yourself:
- WannaCry Attack: In mid-January 2017, the United States Computer Emergency Readiness Team (US-CERT) advised that a vulnerability had been discovered in the Microsoft Windows SMB Server. In March, the flaw was designated CVE-2017-0144 and posted on the National Vulnerabilities Database. Two months later on May 12, a massive ransomware attack was launched. It spread through 150 countries and exploited this vulnerability in the computers of 200,000 unsuspecting victims, who either did not know about the flaw or failed to act upon knowledge of it.
- Equifax Breach: In early March 2017, a vulnerability within Apache Struts was disclosed as CVE-2017-5638. Apache released a fix that same month. We now know that from mid-May to July, cybercriminals successfully exploited this flaw within Equifax’s systems, compromising 143 million records. This means that at least four months elapsed after the vulnerability’s disclosure during which Equifax did not apply the available patch. That is simply too long compared to the urgency with which attackers operate.
The Spectre and Meltdown vulnerabilities are harbingers of things to come this year. In fact, Ferguson warns that the 2017 trend of increasing vulnerability exploits will continue “as corporate attack surfaces expand and expose more security holes.”
Protect Your Institution from Known Vulnerabilities
It took the hackers who attacked Equifax two months from disclosure to exploit, but this was an exception to the norm. Attackers usually exploit a flaw within days, or even hours, of a vulnerability disclosure. Failure to act upon known vulnerabilities is an unnecessary exercise in risk. Protecting your institution requires the following proactive and reactive measures:
- Limit your exposure: Bad guys cannot hack what is not available. On a regular basis, conduct a thorough inventory to identify technology that is not needed or used, along with any that is no longer supported by its manufacturer. Then, remove such hardware from your environment and uninstall—or at least deactivate—such software applications and plugins as quickly as you can. In addition, create strict policies and procedures for approving the installation of new hardware and software within your institution.
- Scan for and remediate vulnerabilities: Routinely scan your network for known vulnerabilities. Once identified, determine an action plan for mitigating your risk from the vulnerability. In some cases, the developer may not have released a patch for the vulnerability in its technology, and therefore your information technology staff will need to either devise an interim workaround or temporarily discontinue use of the system, depending on the vulnerability and the criticality of the system involved.
- Perform timely patch management: Hardware and software developers release patches frequently. Make sure you have an effective process for actively identifying such releases for the technology in use at your institution. That identification should generate the patch’s application, testing and ongoing monitoring to ensure the vulnerability has been effectively fixed.
- Stay informed: This measure should be both proactive and reactive. Closely follow the primary groups that monitor and provide general information on known vulnerabilities, such as MITRE, US-CERT, and the Financial Services Information Sharing and Analysis Center (FS-ISAC). Also, keep in close contact with the developers of technology in use at your institution. This will ensure that your institution is poised to act as quickly as possible to the news of a vulnerability. On the reactive side, these resources should be consulted during the remediation process. For example, the Meltdown and Spectre vulnerabilities are so extensive that new information and advice for effectively and efficiently dealing with them will likely continue to be issued by these groups and individual developers in the coming weeks and months.
A Never-ending Race
Over the last several years, our industry has improved its ability to avoid exploits of known vulnerabilities through patches and remediation plans. Unfortunately, these advances are still not enough to outpace attackers. Podjarny correctly warns that, “For attackers, vulnerability disclosures are an amazing asset.” Indeed, there is ample evidence that attackers pounce on newly disclosed flaws at light speed in order to win the race. It is time for the defenders within financial institutions to up their games and think of disclosures in the same way the hackers do. Only then do our defense and remediation efforts stand a chance of coming out on top in this never-ending race.
Steve Sanders is vice president of Internal Audit for CSI. In his role, he oversees the evaluation and mitigation of risks associated with IT, financial and operational systems. Steve is a CISA, CRISC, CRMA, and CTGA, and he speaks regularly on information security, cybersecurity, IT and IT audit topics.