Data Loss Prevention

I have a question on DLP EDM.  I have a EDM profile which has a column of 6 numeric digit, e.g. 123456.  I found that DLP matches 123,456 with it.  This is not what I expected.  How can I tell DLP EDM to match exactly 123456 only?

Raymond,

This does sound a bit off. I would suggest 2 courses of action.

1. If you can, include more than just the 6 digit numerics. The problem you may find with this in addition to the (123,456 format vs 123456), is a plethora of false positives from the numbers. Because numbers appear all over in web traffic, email headers, etc, this is prone to producing more false positives than necessary.
    
2. You may also want to open a supprot ticket for this as it sounds like there may be something off on this. Generally we only match exact details, but depending on the version they may have adapted the engine to find slight alterations in the EDM matches to detect potential intentional modification of data to circumvent DLP.
   PLEASE NOTE I'M NOT POSITIVE ON THIS STATEMENT AND SHOULD BE BROUGHT TO YOUR LOCAL SYMANTEC REP OR SUPPORT.

I don't recall the source for this information (think it was in the Admin Guide?), but I do know that the EDM disregards non-alphanumeric characters (except for space?) when matching.  I don't recall the specifics, but what you are saying is expected bevhavior in my experience.

Fortunately, it is realtively easy to fix by adding a regex pattern match exception to your policy.  For example when matching against an 8 or 9 digit account number, EDM will readily match against 8 or 9 digit currency values such as 12,345,678.  To prevent matching against numbers formated like that, I added a rule exception that uses the regex "(\d{2,3}),(\d{3}),(\d{3})" 

I hope you find that helpful.

Raymond,

Could you tell me more about the EDM policy for HTTP?  We are using a 15 column EDM and finding a low number of events occuring based on the outbound traffic monitored.

Adam

EDM is a great technology as long as you understand its benefits and limitations.

EDM is EXACT data match.    The key to its use is knowing that you can control the proximity of the individual field entries within a single record (row).  The default I think is 30.  Which means that the CCN or SSN or whatever is in your db must be within 30 words of another value like lastname or date of birth.

The greatest difficulty using EDM is that your data needs to be well formed other wise the entire record will be ignored.

Symantec's example has to do with a proper name.  John W. Smith.    In order for EDM to work, you would need to break the name into two or three parts.  Field FirstName: John  Field LastName: Smith.  Etc...

This is potentially a major effort because "normalizing" the data in this manner must be done or it will not work.

This requirement should be reviewed ny Symantec as there are other database fingerprinting technologies that do not have this requirement and function even if spaces or special characters exist within a single field.

I assume that there are other areas of the product that collapse white space, remove stop words, remove special characters before inspection is accomplished.  They should do the same for DB's.

This probably did not answer your specific use case. In fact I would not have predicted that 123456 would detect 123,456.   This part of the product needs enhancements.  Including superhashing which could potentially allow EDM on the endpoint.

Anyway, great technology with a significant limitation.

SDLP offers a great amount of access to multiple channels in an easily configured interface for the raw collection and reporting of data.

This information is well formed though integration of AD, Custom Attributes, Access Controls and Historical Analysis.

In fact I quite like the system as it is.  There is room for a great deal of improvement. But if nothing changed I will continue to recommend SDLP as a very positive part a data protection and privacy practice. 

I recemmend the use of facets (time, entities, concepts, monetary, weights & measures) into policy definitions for indications to the reviewer and reports so that content aware decisions can be made about data content and relationships.

Response rules can be effectively written and enforced especially within dynamic environments by labelling this sort of information.

Example in three easy steps:

1. Create an AD directory of users names/groups as a Data Identifiers' (AB-CCCC/DD) or EDM DB (when possible).
2. Create Domain List definitions for trusted and untrusted (MAC Address, IP Range, NAS, SAN).
3. Set Report Configuration for desired entities and let the fun begin.

From that moment monitoring rules can be defined across multiple groups (partners, competitors and co-co-opetition) as normal traffic. Abnormalities can be more easily identified in a shorter amount of time and with a higher degree of accuracy by taking advantage of the data relationships that will certainly exist.

From there you can assess the common and uncommon access to sensitive information.

Nice way to begin an SDLP project.

Another step or phase is a closer look at the web archive. Great feature.