As the ever-shifting security and threat landscape continues to evolve, it can be tough to distinguish security fact from fiction. Some common data breach misconceptions can seriously misinform your organization’s security strategy.
In this post, we’ll touch on three of the most common data breach myths, and share some information on why they don’t hold up.
Let’s dive in.
Myth 1: Technical vulnerabilities are the leading cause of data breaches
Our first myth is that technical vulnerabilities cause the most data breaches. In this scenario, the hacker targets your infrastructure with a novel attack vector that exploits a zero-day vulnerability.
Reality: Attacks targeting credentials are a much greater concern than technical vulnerabilities
Let’s take a look at Verizon’s 2017 data breach investigations report. Here are the actual leading causes of data breaches
In total, 81% of the data breaches involved stolen or weak credentials. Only six attacks were caused by exploiting new novel vulnerabilities, while 653 breaches were caused by good old-fashioned phishing. And in 91% of these phishing attacks, the target was credentials.
Part of what makes credential-based attacks so dangerous is the fact that so many users re-use the same passwords. In the TeleSign 2016 account security report, 73% of the passwords were found to be duplicates. This means a single breach in one place could result in passwords becoming widely available for attackers to test against other sites en masse.
TLDR; Credential-based attacks pose a bigger threat than technical vulnerabilities. Invest in strong password policies, anti-phishing training, and other identity related best practices to defend against some of the most pervasive threats.
Myth 2: Adding any form of 2-factor authentication will keep your accounts secure
The second myth is that simply adding another factor to a login sequence will defend against all attack vectors. Credential-based attacks are one of the primary threat vectors, so applying MFA should take care of that, right?
Reality: Not all factors are created equal
I’d never discourage anyone from deploying multi-factor authentication. Some kind of MFA is definitely better than none at all, but be aware that some factors are more effective than others.
The fastest and simplest way to implement a second factor is to deploy a factor that everyone has. Everyone has a cell phone, which makes SMS as a second factor very popular.
However, bad actors can hijack SMS using an SS7 signaling system, or even do SIM card swaps without too much difficulty. Another popular method, one time passwords, can also be hacked by man-in-the-middle attacks.
When adding an additional factor to the login sequence, it’s important to take a look at the assurance level of your authentication pairs. Passwords and security questions are the most basic and easiest to deploy, but they have the lowest assurance levels.
At the high end of the scale you can deploy security keys and built in device-authenticators using Universal Second Factor (U2F) , Biometric-based factors, or the new WebAuthn standard, which are virtually phishing-proof.
In the case of U2F and WebAuthn, the actual credential that's being checked is cryptographically tied to the genuine site’s SSL certificate. This means that the user can't give up that information even if they want to. Even if a user ends up on a phishing site that looks completely genuine and they’re willing to give up the U2F token code, it won’t work.
TLDR; Adding MFA is never a bad idea, but not every type of implementation my necessarily stop a breach. It may simply change what the attacker needs to do. Universal Second Factor (U2F), WebAuthn and Biometric-based factors are a major step up from SMS-based authentication. Choose your MFA methods wisely by evaluating the assurance levels of your MFA options.
Myth 3: Strong MFA in front of everything will fix all my problems
The third myth is that putting strong MFA in front of all apps, every time, will secure all your users, apps, and data. Organizations that have been compromised and are in breach response mode will often deploy MFA in front of every system.
Reality: Not all users and apps need the same MFA policies
This strategy only “works” if usability isn’t an issue and users can be forced to comply. “MFA Everywhere Always” may work in some corporate settings, but when considering the broader ecosystem outside of employees—including partners, contractors, and customers—this isn’t a viable strategy. Security must be balanced with usability and deployability.
The best way to balance security, usability, and deployability is to build a system that allows the user to authenticate only when necessary. This is where contextual access management comes into play.
When looking at context, there are a few questions to ask:
- Application Context: What application are they accessing, and does this app have sensitive data?
- User Group Context: What kinds of privileges and rights does the user have? Are these employees, customers, or contractors?
- Network Context: Is this a new IP or a familiar one? Has the user already authenticated onto the office wifi or are they on the public wifi in a coffee show?
- Device Context: Is the user on a managed device where we know we’re running the latest OS and malware detection tools?
- Location Context: Are they logging in from an unusual or completely new region? Are they logging in from California at 3pm PST, but their last login was in New York at 2pm PST (signaling impossible travel)?
- Response: Based on the context above, we can deny access for risky logins, or even enable a passwordless authentication flow for safe logins.
All of these signals provide full context for access, and allows us to establish an appropriate level of trust before granting access to that resource. We can qualify if this is a high-risk login where we might respond appropriately with a biometric factor or even deny access, or a low-risk login where a push verification via phone or even a passwordless experience is appropriate.
Contextual access management allows you to improve usability while finding the most secure solution for your organization where deployment is a manageable task.
TLDR; MFA everywhere, every time may be overkill if you want to strike the right balance between security and usability. Consider investing Contextual Access Management in order to prompt users with an appropriate response during each authentication attempt.