This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Data Control Not Working

Is anyone else experiencing issues with Data Control policies not working ? During an external audit, we discovered both ssn and credit card numbers were able to bypass the policies we had set in place. These policies had worked before. Now, I get to pull all emails matching the polices via Exchange. We have bank account policies that we will test next. We called Sophos, and they are going to investigate. 

 

Software engine v4.5.0.1
Threat definitions 558000.0.20190222.156


This thread was automatically locked due to age.
Parents
  • Hi,

    Its important to note that all DLP rules have a certain set of criteria that must be met to count against the qty total.  The other thing that is important is that the quantity is set to the defaults.  For example setting a quantity to low will generally result in a lot of pf, and one set to high may not be effective.

    one thing you may wish to to for testing is:

    click on the rule in question.

    under rule type, check off advanced options

    under rule config, there are several tabs.. click on the logging tab

    check off all 3 boxes

    apply/save

     

    the change will take upto 10 mins to take effect, once it does send a test email

    under the search tool, select mail logs

    locate your email (maybe by subject or what not)

    left click on it.

    scroll down until you see, view log details

    you should then see a new tab called logging with all of the hits listed

     

    important notes:

    always use country specific vs international  .. so if your looking for north american credit cards, select US and Canada not international.

    1 match means 1 instance of every required piece of information

    for example if phi means .. first last and middle name, all 3 names must match to equal 1 hit

    DLP rules are generally meant to help stop large scale leakage, they should not be relied upon to catch a single instance (unless the default quantity of the rule is 1)

     

    the "hits" may also be of use if you have opened a support case.

Reply
  • Hi,

    Its important to note that all DLP rules have a certain set of criteria that must be met to count against the qty total.  The other thing that is important is that the quantity is set to the defaults.  For example setting a quantity to low will generally result in a lot of pf, and one set to high may not be effective.

    one thing you may wish to to for testing is:

    click on the rule in question.

    under rule type, check off advanced options

    under rule config, there are several tabs.. click on the logging tab

    check off all 3 boxes

    apply/save

     

    the change will take upto 10 mins to take effect, once it does send a test email

    under the search tool, select mail logs

    locate your email (maybe by subject or what not)

    left click on it.

    scroll down until you see, view log details

    you should then see a new tab called logging with all of the hits listed

     

    important notes:

    always use country specific vs international  .. so if your looking for north american credit cards, select US and Canada not international.

    1 match means 1 instance of every required piece of information

    for example if phi means .. first last and middle name, all 3 names must match to equal 1 hit

    DLP rules are generally meant to help stop large scale leakage, they should not be relied upon to catch a single instance (unless the default quantity of the rule is 1)

     

    the "hits" may also be of use if you have opened a support case.

Children
  • Hi RW,

     

    We have a ticket open (#8651957) with you folks. I created a new rule around your suggestions, and the content is found and logged. The action is to reject. In this case I am testing against SSN. The SEA does not reject it.

     

    John

  • Hey RW,

     

    I wanted to give you an update on this. So, the offending messages were not being stopped because the quantity was set to 10. We changed this to 1 and the additional actions of the rule were triggered, but not the main action. The support folks are trying to figure out why the main trigger is not working. To clarify for those following this discussion, we adjusted for the specific rule the quantity from 10 to 1:

    * From RW: DLP rules are generally meant to help stop large scale leakage, they should not be relied upon to catch a single instance (unless the default quantity of the rule is 1)

     

    Screenshot sample below.

     

     

  • Hi John,

     

    I had a look at your appliance:

     

     

    Your issue is with rule number 3 and 4

     

    lets address number 3 first

    configuration / policy / data control / outbound 

    click rule #3

    under rule config

    select CCL tab

     

    You have 3 different rules here with varying quantity.

    ie: 3 rules for bank account numbers / information

    global credit card

    and international banking numbers.

     

    the larger issue is at the bottom where you have "2 of the ccls must match"

     

    In order for this rule to ever trigger you must match rules in its entirety... including ALL criteria. 

     

    For example:

    if bank account details needs.

    fname mnam lname address 1 address 2 postal .. etc ect ..

    with a qty of 3..

    in order for this to ever hit you must have 3 complete records... then 3 record MUST match.

     

    because you also have a qty of 2 .. that means that 2 separate rules must match completely, including all hits and required numbers. 

     

    In order to fix this..

    separate the banking / credit card and global into 3 rules.

    leave the qtys at the default 

    make sure the number of rules to match is 1

     

    I would avoid using global qualifiers as the chance of FP is higher.

    I would also avoid rejecting the mail unless you have rules on your exchange server to handle such rejection notices. (you may wish to discard or quarantine the message) then under the additional actions create a rule to notify the sender .. this will tell postmaster to actually generate a new message and deliverer it back to the user.. so exchange will see it as a "normal" message.

     

    It's important to also note, DLP rules are not designed to catch a single instance of anything.. they are more meant to help prevent data dump-age..   (doesn't mean you cant of course, but you will need to be aware that your chance for a false positive is greater, and the recommended quantities are apart of how the rule actually works) .. so if its 10, and you change it to 1.. you can expect more FP's, than if you change it to 7 or 5. 

     

    In your case the reason your dkim rule is hitting is because its tagging everything, I would expect that .. the stuff your seeing in the logs from outputting the hits are partial hits.. If ALL of the hits were noted then the "main action" of the message would hit on your DLP rules)

     

    keep in mind any change to DLP rules can take up to 10 whole mins to take effect.. if you make or change rules ensure you leave enough time for the milter to restart and the appliance to reload all of the policy.

  • In regards to rule number 4:

    the x-header you have set may not be triggering if you are using the outlook plugin.. 

     

    the field that it used to encrypt is

     

    company-confidential 

     

    if you have specifically created this header somewhere upstream, then it should work keep in mind I would only use one or the other SS type.. this will help reduce the content that is detected in one rule, but not the other and visa versa.. this would impact the overall number of hits and may not get the qty your have set in the rule.

     

    again I would use notify sender vs generating that bounce to ensure the sends spam filter or rules does not drop the message.

  • RW,

     

    Thank you for you help! I will address these issues and let you know how things go.

     

    Regards,

    John