The primary cause of data breaches today is directly related to the relationship that exists between vulnerabilities and exploits. There seems to be some misunderstanding, however, regarding these two terms in the IT industry today. Often, they’re used interchangeably or used somewhat out of context.
Hopefully, the following discussion will clear things up and help organizations better learn how to prevent a data breach.
Vulnerabilities and exploits
In its most basic definition, a vulnerability can simply be described as a weakness that exists. In the context of cybersecurity, vulnerabilities can be found in all aspects of computing. For example, they can be found in networking hardware, operating systems and applications, company practices and procedures, and in company personnel as well. The whole point of performing information security assessments is to discover, identify, quantify, and categorize the weaknesses that are found. Once they are found, measures are taken to either remove them or reduce the damage that can be done because of them.
On the other hand, those who launch cyberattacks do nothing more than exploit (take advantage of) an organization’s weaknesses, which unfortunately can come in many forms. Simply put, it’s the job of the attacker to find an organization’s weaknesses and exploit them to the attacker’s advantage. Once a weakness has been exploited by the attacker, many different outcomes are possible. Most of the outcomes profit the attacker, at the expense of the victim.
The data that organizations possess has significant monetary value to attackers, which is why it’s so important to take the necessary steps to prevent a data breach. Organizations must begin to think like attackers and identify the paths of least resistance that attackers would take in order for them to gain access to that data. “If I were an attacker, what would I do?” is a question every member of an organization’s security team must ask themselves daily.
Preventing web-based data breaches
Concerning publicly-exposed websites, and the applications organizations use to operate their websites, many vulnerabilities likely exist. Vendors that manufacture web-based applications frequently introduce new vulnerabilities, most often without their own knowledge. Open source web applications will have vulnerabilities baked in as well. It’s just a fact of life, and unfortunately this will not change anytime soon.
In addition, organizations that deploy open source and even commercial web applications are often responsible for introducing vulnerabilities on their own, because of the way they have implemented an application. One simple mistake in the way an application is deployed and/or utilized can be the catalyst for exploitation. So where does this leave organizations that are relentlessly trying to prevent a data breach?
They must understand that anything that is publicly exposed on the internet is constantly being scanned, probed, and prodded by attackers in the hope of finding a weakness. Worse yet, attackers are no longer doing this reconnaissance activity on their own. Instead, they are now using malicious bots to do much of this work for them. Since bots never tire and are more than happy to work 24 hours a day, they are the perfect recon tool for finding exploitable vulnerabilities.
Thinking like an attacker, the best way to prevent a data breach is to implement impenetrable defenses around that information and the computer systems that have access to it. Deploying technology that not only detects and blocks bots but can also impede exploitation attempts against vulnerable web applications is imperative.
When strategizing about how to prevent a data breach, anything that makes the attacker’s job more difficult is a step in the right direction. Bot management technology, combined with web application firewalls, DDoS protection, API security, and malware protection will deter attackers and their malicious bots, while protecting web applications and the data downstream. Doing so will help attackers realize there are much easier targets found elsewhere.