Data Loss Prevention

 View Only

Chapter 2 - The Concept of DLP - Monitoring and Blocking Confidential Data 

Jan 06, 2010 05:44 PM

Chapter 2 - Monitoring and Blocking Confidential Data

In this chapter I will be focusing on these following question:

I found confidential data, now what?

Well, now that we have found confidential data we need to categorize the data, and decide on the actions that will be taken in order to protect that data.
In order to do so, first let me define the three types of data we can define within the Vontu DLP System:

  • DCM – Described Content Matching, refers to regular expressions (masks, wild cards), words.
  • IDM – Indexed Data Matching, Vontu DLP uses a special algorithm that indexes documents that unlike DB's has no structure. when we are referring to IDM we will focus on:
    Word documents, TXT files, PDF files and so on.
  • EDM – Exact Data Matching, when we are referring to Exact Data we are talking about every type of file that is in a structured format (tables) for example:
    Excel, Oracle DB, Microsoft SQL, Access.
Secondly we need to decide what is the severity of exposure of the data, in order to do so I have made a table (shown in figure 1) that could help decide what is the severity:
Figure 1
 

This table is not always correct  because it will be unique to every organization, but you can use it as a baseline, an explanation of this table is in order:
  • DCM exposure is not that terrible most of the time because those are words that have been espoused, its correct that we can use DCM rules in order to find credit card numbers but as you will see, the more correct rule to use for credit card numbers is the EDM rule. most often, the exposure of words won't have a big impact on the organization.
  • IDM exposure could be serious depending on the amount of information that is being transferred. As you will see when we analyze an IDM incident, you will know how much of the file has been sent (in percentage). When we look at the risk of exposure, IDM exposure means that a document has been exposed. Of course, that document has classificationd and the more classified the document, the more serious the exposure. For that, there is another table (shown in figure 2) that should be considered.  This table will be different in every organization and should be defined with the help of the customer: 
Figure 2:
 
This table could define the severity of an incident. it should be combined with the first table in order to receive a complete overview of the incident.
  • EDM exposure would be serious most of the time. Most organizations keep their most valuable information in tables, for example: list of employees and salaries, list of costumers, list of credit cards and much more. The risk of exposure is major.  It could be that any cell exposed means trouble. As you will see, we will be able to define which cells are important to the organization, and in which order. For example: first name, last name and credit card are forbidden, but first name and last names are fine.
After we categorized our confidential data and decided what is the risk of the exposure. we can start designing the basic rules for the system.  Because rules are something that will be different between clients, I want to keep these articles on the conceptual side.  I will help with the conceptual design of rules.

First, let me give a quick review of the system and its components, in order to make it simpler later.

The Vontu DLP system is a complete all around solution, and by that it means that, we will need one then one server. the type of servers that are available for our use are:
  • Vontu Enforce - the enforce server is the heart of the system. This is the main console of the system where we will define all the rules, control all of the servers, treat incidents and generate reports. (This server is mandatory)
  • Vontu Endpoint Server - the endpoint server is responsible to deploy policies to the endpoints on our network. The endpoint server is the server that all clients report to.
  • Vontu Discover/protect - the discover/protect server is responsible for scanning the databases and fileservers in the organization. The discover server only has the option to alert on confidential data the is found.  The protect server has the ability to do something about the information. The server can either copy the file to another location (still keeping the file in the same location) or quarantine the file, and leave a marker file that will point the employee to the security department.
  • Vontu Network:
  1. Network Monitor - we talked about this server before in Chapter One. This is a server that "taps" in to our network (using mirror/SPAN port) and then analyzes the network traffic.
    It should be mentioned that the server is completely passive and has no proactive abilities, it will provide us with valuable information, but it won't stop the data flow.
  2. Network Prevent (Web) - web prevent has the ability to analyze and block/alter traffic that is going out to the internet/intranet (depending on the location being used).
    The server receives traffic using the ICAP protocol from a proxy server.
  3. Network Prevent (Mail) - mail prevent has the ability to analyze and block/alter mails sent from the organization. The mail prevent server receives mails from the organizational
    MTA (Mail Transfer Agent).
There is one thing that should be kept in mind before we continue, endpoint computers can only block DCM rules. We will be able to block masks (Regular Expressions),
and by that we will also be able to block EDM related rules with DCM. I have made a work flow that will help you in the creation of policies (as shown in figure 3):

Figure 3
 

This table shows a work flow in which we need to work in order to create a good policy.  Let me explain what we see here:
  • Policy Type - Here we have our three policy types, DCM, IDM and EDM. The regulatory enforcement policy type should be considered as a DCM policy, but I consider it to be a "stand-alone" policy type because we have predefined regulations built in the system.
  • Information Type - which type of information will be in use?
  1. If we scanned the network locations and found confidential data (and also indexed the data) then it would be "Indexed File Profile".
  2. If we scanned and indexed structured  data (Databases, Excel files etc.) we will use "EDM Profile"
  3. If we are using custom words/Regular Expressions (DCM) or the Regulatory Enforcement policy type then it would be " words/Regular Expressions"
  • Severity - what is the severity of the broken rule? A broken rule could have some levels of severity depending on the  amount of times the rule was broken in the same incident (for example: A credit card appeared 15 times in a sent file will be defined as critical, but a file sent containing 2 credit cards will be defined as medium severity incident). The customer can add as many severity levels as desired.
  • Action Needed - What is the action that will be taken when the rule is broken.
    A broken rule could have more than one action depending on the severity of the incident (for example: severity low - would be notify, and severity high - would be block).
  • Incident Treatment - Which person/group is responsible to treat the incident?
    In order to create a better organizational workflow the customer can create groups that will treat the incident. The incident could be transferred to a group depending on the rule broken, severity, or by the entire policy.  The customer can add as many groups levels as desired, and can create an escalation oriented workflow (for example: Help Desk receives an incident, then escalates the incident to the interrogation team).
After the policy is defined, it is ready for enforcement. I would suggest that the enforcement step would come after some testing time in order to see that the
policy is configured correctly and that there are no false-positives.

This is the end of the second chapter.
In the next chapter, I will discuss on the importance of worker education and the various ways of education.

Best Regards,
Naor Penso
Security Engineer
Netcom Malam-Team

Statistics
0 Favorited
30 Views
1 Files
0 Shares
8 Downloads
Attachment(s)
pdf file
Chapter-2.pdf   135 KB   1 version
Uploaded - Feb 25, 2020

Tags and Keywords

Comments

Mar 22, 2012 12:47 PM

Great document. I especially like the graphic in Fig.3.

 

I have one question regarding the use of DCM and EDM on endpoint. I always assumed endpoints can not block or notify whenever there is a server side rule such as EDM. Is this correct?

Mar 22, 2012 12:44 AM

Hi Penso,

Vey informative article, Thanks for sharing.Ther are some blank spaces in between contents, r they images or what.?

Regards

Kishorilal

Jan 31, 2012 03:35 PM

Hi! we have a need for:

1 - Find credit card numbers in excel file on share drive and replace it with just the last 4.

2 - Find credit card data in Oracle DB.

Has anyone done this before? If so, how complex are they - especially #1?

Apr 15, 2010 04:39 PM

Thanks for the material, it will come very handy.

Feb 08, 2010 03:26 PM

First of all,
Thanks for the support.
Secondly,
I have uploaded the article as a PDF to this article.

Kind Regards,
Naor Penso

Feb 08, 2010 01:24 PM

Perahps the author would be willing to forward the original file over to you.  I believe he could also post the file to this article as an attachment.

Thanks,

Eileen
Online Community Manager
Storage and Clustering Community

Jan 29, 2010 09:12 AM

For some reason I cannot see the pictures of this page... not sure why. Is it published in PDF somewhere?

Jan 11, 2010 02:07 PM

You can use then but please consider 2 things:
1) Symantec are by no means obligated to the pictures, and they wont take responsibility over them even if they are correct.
2) Please credit the author.

If you want the picture in bigger size contact me and I will transfer them to you.

Kind Regards,
Naor Penso

Jan 08, 2010 11:01 AM

can i re use them in a presentation, they are great 

Related Entries and Links

No Related Resource entered.