Data Loss Prevention

 View Only
  • 1.  DLP and Credit Card Data

    Posted Jan 18, 2013 03:26 PM

    I currently monitor CC information through email prevent in DLP. What do you do when you see a user emailing personal credit card information that is not related to the business. When a user emails CC info for business they are flagged as in progress and worked. What do you for these? Any and all help would be greatly appreciated.



  • 2.  RE: DLP and Credit Card Data

    Broadcom Employee
    Posted Jan 18, 2013 10:00 PM

    What kind of business workflow you wanted if such incidents generated?



  • 3.  RE: DLP and Credit Card Data

    Posted Jan 19, 2013 06:16 AM

    For Personal User , You should educate the user that it is not safe to send his Credit card number out there like this and than dismiss the incident with your comments .

    For official user , If it is for business and you can see in the email than no Problem .You should acknowledge it and close the incident .

    Another thing that you can try  is to use a Gateway encryption solution and it should encrypt the email if it finds credit card data .This will ensure that credit card data will not go out in clear text .



  • 4.  RE: DLP and Credit Card Data

    Posted Jan 20, 2013 11:04 PM

    @subhani .. I do educate the user. So you do or would not do anything else? I like your idea.

     

    @yang_zhang...I currently do not have one in place, as I am working on one now. Any thing you could recommend?



  • 5.  RE: DLP and Credit Card Data

    Posted Feb 06, 2013 04:48 AM

    I appreciate the comments of subhani also refer below]

    U can decide the no of occurences of CC while sending the file. There may be lasrge occurence limit while in bussiness  cc tranfer. like max 10 match of cc should not genearte incidents.



  • 6.  RE: DLP and Credit Card Data

    Posted Mar 07, 2013 12:56 AM

    Hi Mssudd,

    Either u can define in ur policy that no. of matching of CCN should be <5 or <10 then it should not generate incident, and if user sent more than this count then this will generate incident. this way u can reduce the above possibility which u asked.

    Also u can dismissed such cases even after auto escalation. u will get match count setting in policy list->policy .......

    Educate the use to avoid such instances in office which reduce the unnecessary attention.

    As i was worked in incident mgmt and policy tune , I recommend u to this.I hope this will help u.

    Also refer below some thread for understanding purpose

    https://www-secure.symantec.com/connect/forums/false-positives-policy-modification

    https://www-secure.symantec.com/connect/forums/fine-tune-credit-card-policy

    https://www-secure.symantec.com/connect/forums/detecting-credit-card-number

    https://www-secure.symantec.com/connect/forums/masking-credit-card-number-incidents



  • 7.  RE: DLP and Credit Card Data

    Posted May 02, 2013 02:34 PM

    If your Privacy / Compliance area is going to allow transmission of CC number via email I recommend encrypting the message whether it is for business OR personal use.  You should consider a response rule to reply back to the sender informing them why the message was encrypted.

    Additionally, I would create a different severity level for messages that have more than 1 or 2 matches beacuse that to me whould be a different situation than a purchase over email.

    As a side conversation, what types of conditions are you using in your policy rules to detect CC numbers?  ie. keyword matching, regular expression, DI or combination of the aforementioned?



  • 8.  RE: DLP and Credit Card Data

    Posted May 15, 2013 04:34 PM

    I feel like if you just notify them that you encrypted the message for them, they're less likely to pay attention to what content they're sending to the outside world in the future because they'll just assume you're there to take care of it.  We block the message and send a message back indicating the typed of data they should be sending securely.  It's annoying to them to have to resend the message, but it's really a teaching opportunity.