I was recently scrolling through a forum where the inevitable topic of creating perfect data loss prevention (DLP) regular expression (regex) queries began to simmer.
It started along the lines of this: “I need to build a regex query to look for credit card numbers within email or documents – how do I do this without an exorbitant amount of false positives?”
Turns out, many folks relate to this exact situation, and the discussion caught fire. Some are building the rules so tight and applying them to such specific users, they risk missing events that don’t fit the fold. Others are casting the net too wide and don’t have the manpower or the stamina to triage the alerts. Others have put an approval process in place, but this process slows down business. Managers end up having to approve all emails…but who has time for that?
So how can we both mitigate risk and reduce the amount of alerts DLP administrators are triaging? Food for thought from a wise man: “If you are going to eat s*t, do not nibble…”
If you make it personal AND relevant, the employee will listen
When implementing policies that encourage employees towards positive behavior and are actually relevant to them, they will be more inclined to understand and listen.
For example, you may have a company policy that prohibits employees from sending sensitive company data to their personal email. Employees will typically take this approach because they want to access documents conveniently from another location that has less security; one less hurdle to jump through when on a plane, at a hotel, or working from home.
Other times, users literally do not know that this isn’t secure, or maybe they have just come into the organization via M&A and are unaware of the policy. Instead of reactively catching this after the fact and having HR or management punish the employee, what if you could eliminate it in the first place with a prompt?
Imagine employees saw this upon sending the email:
This is an example of a Tessian warning an employee would see when they attempt to send sensitive information to a personal or unauthorized email account
Which brings us to point #2…. We have to tell employees why this is important for them to personally consider. They will relate, understand, and heed the advice the next time they are thinking about sending sensitive data to unsecure places.
You can imagine sharing additional tips on your organization’s internal Wiki or Intranet to help really drive the point home:
Home tip: This policy should be followed when you’re sending personal, sensitive information about yourself to anyone. Not just when you’re at work. Make sure you are always sending personal information like credit card numbers and social security numbers through secure methods (like sites that have a lock located by the URL) and always ask if items like social security numbers are required. You would be surprised by how many places do not need this type of information yet ask for it!
Most employees are not malicious… they just aren’t enabled to make better decisions
More and more often, we’re hearing that people are responsible for breaches:
But the problem isn’t malicious employees.
For example, if we isolate the financial services industry, the majority of breaches were caused by an accident, like sending an email to the wrong person, which represents a whopping 55% of all error-based breaches (and 13% of all breaches for the year).
This all goes to show that most employees aren’t malicious; if they were asked to take an alternative, more secure route, they would! They just don’t know how.
Well-documented tutorials can help reduce unintentional data loss and IT tickets, which means security teams are only left with tickets that are actually worth triaging.
There is data outside of your regex queries that is worth protecting. Do you know what that data is?
Although there is tablestake data like social security numbers and account numbers that need to be protected due to regulations and mandates, there is also business data that is critical to protect.
What is your vital business data? Think: M&A confidential projects, clientele lists, portfolio company research and earnings, company budget information, case strategy documents…. This is just a small list of things that – if in the wrong hands – could be very bad news for the business. Can you possibly create regex queries to identify and protect all of these types of data?
Considering the fact that organizations spend up to 600 hours a month resolving employee-related security incidents like data exfiltration or accidental data loss, I’d say no.
The bottom line is: your talented team members don’t want to spend their days combing through DLP alerts that could be eliminated in the first place. But, until we begin to enable our employees to be secure at work and at home, we will forever be salmon swimming upstream.
I encourage you to take a look at what Tessian can offer to build this positive, security-enabled culture. Check out the below resources, or book a demo to see the product in action.
