Asking the Right Questions When Implementing a Data Loss Prevention Policy
Okay, raise your hand if you are scared of the word “policy.” Policy is sometimes an overused word that sounds simpler than the complex thing
it actually is, and if not properly thought out, can be a headache to implement. RSA’s
Information Policy and Classification team spends a lot of time focusing
on the accuracy of Data Loss Prevention (DLP) policies. This week, we’re
giving some hints for success and best practices that we’ve learned by
working with both early adopters and some of the world’s largest companies. We
know from experience that you can have the most accurate policy and it still
may not be the right policy for your organization. Here’s how
to figure it out...
On the first day, it can be very exciting to get a Data Loss Prevention product
with so many built-in policies! And with words like “out of the box” and “one-click,” it
seems so easy. But before you click on the switch, make sure both you and your
organization have planned out your strategy. Keep in mind that whatever
you turn on is now actionable. Simple rule: Make sure you’ve
thought it out, and ask the right questions when implementing a DLP policy: who,
what, where, when, why, and how (see below).
A Data Loss Prevention policy basically asks two questions: What
is the data that you want to protect? And how should you protect it? Sounds
simple, right? As our customers find, there are many more questions that need
to be asked upfront. Let’s start by looking at two of the biggest pitfalls
and then get into a list of questions that you should ask to get your Data
Loss Prevention policy right the first time.
#1: You’ve built a comprehensive policy that’ll
capture everything! Now, did you consider the exceptions?
Let’s say that you know you have important data that needs to be protected.
Great, you’ve passed the first step in the process. But there are still
a few more questions that need to be asked. What’s the exception to the
rules? Or rather, who is the exception to the rule? Let’s say
you’re a healthcare provider trying to figure out HIPAA, and you’ve
implemented a policy blocking sensitive health information from going out.
You’re done, right? Wrong. If your policies aren’t well-thought-out,
you’ve made a critical mistake. What if your policy just stopped a doctor
from sending out potentially life-saving information? You need to always know
the exception to the rules: it might be an individual, group or department.
You may also have exceptions if the information is going to a trusted partner.
Determine this before anything else.
#2: If there isn’t a regulatory need, IP need, and it’s
not going to impact your brand, then don’t turn it on.
Our team had a lot of internal angst (ok, ok… and fun) when we built
the Profanity policy. We wondered if it was a true Data Loss Prevention use
case. If you really want to implement a Profanity policy, get ready to
deal with a flood of incidents. Do you really want to audit every bad word?
What is the action plan to deal with the audits? Do you have the staff in place
to deal with this can of worms? You may discover that profanity could be one
policy that is better left in the corporate HR handbook. The point
here is to know what is important to your company and prioritize it, and ensuring
that your staffing plan will be able to address it.
Now that we’ve probably scared you, let’s take a deep breath and
understand that Data Loss Prevention is a process, through which you blend products
and services to help you detect sensitive data and to identify and enforce
security policies for protecting this data. It shouldn’t require any
modifications to the data itself. Plan it and use it right, and it will deliver
great results for your organization.
Implementing a Data Loss Prevention policy isn’t that hard if you’re
asking the right questions. Here’s a list of questions you should start
with:
- Who is the policy going to apply to? Who isn’t it
going to apply to? Know the individuals, groups or departments affected and
how this will impact them.
- What type of sensitive or business-critical information
are you trying to protect?
- Why are you protecting it? It might sound silly, but it’s
critical to understand why the organization feels it’s important to
protect the data. Is it a regulatory use case, or is it business-critical
data?
- Where should you protect it? Sensitive content exists
in many different states. Are you worried about data that is in
motion? What about inbound and outbound communications?
Are you worried about content at rest in the datacenter and at endpoints?
What about data in use in the endpoint? Hmm, maybe all the above?
Here’s a hint: just because it might be in all states doesn’t
mean you have to do it all at once. Phase it in. Start with
the critical.
- When should you trigger a violation? Do you want to capture
any violation no matter how big or small? You may decide to only generate
and escalate incidents for severe violations. Maybe you want to start with
the most severe, get those under control and then deal with the rest.
- How should you protect the information? Should you audit
violations, automatically encrypt them, and maybe quarantine or block them?
You should be able to tie the "When" into the "How" and
enforce different actions depending on the severity of the information.
Rush or skip the strategic questioning, and you won’t have the results
you need. Remember, this isn’t about blocking, encrypting, or auditing
all incidents; it’s about ensuring incidents don’t occur in
the first place. Your real first step should be focusing on fixing any
broken business practices. Then implement Data Loss Prevention to get insight
into your organization’s gaps in processes and where they exist. With
a strategic, well-constructed Data Loss Prevention policy, actual incidents
should decrease as the business becomes smarter.
In the end, it’s pretty simple. “Policy” isn’t a bad
word – implementing a policy without strategic thought is just a bad
idea. Be smart and be strategic and you’ll love your policies.
We do
Post A Comment