Data Loss Prevention

 View Only
  • 1.  DLP Incident: debbuging\detailed logging - *logging.properties

    Posted Dec 06, 2016 05:48 AM

    Hi all, 

    I have two simple test policies on DLP (ver.14.5) (Encofce and Network Prevent for Email)

    • Policy1: raise an incident if email\smpt traffic is detected. This policy works as a charm  and incidents are being raised. 
    • Policy2: raise an incident if email\smtp traffic is detected and sender is a member of User Group. Unfortunatelly this Policy doesn't generate incidents. 

     

    So, obvioulsy something wrong with: 

    • Directory Connections (sync=OK, replication=Ok)
    • User Group. (
    • Etc. 

     

     

    I would like to see what is going on in a background when NPM processes emails against each policy. I need either detailed log (debbug). 

    Admin Guide says: 

    Debug log files record fine-grained technical details about the individual processes or software components that comprise Symantec Data Loss Prevention. The contents of debug log files are not intended for use in diagnosing system configuration errors or in verifying expected software functionality. You do not need to examine debug log files to administer or maintain an Symantec Data Loss Prevention installation. However, Symantec Support may ask you to provide debug log files for further analysis when you report a problem. Some debug log files are not created by default. Symantec Support can explain how to configure the software to create the file if necessary.

     

    Surely I can open ticket... but it will take a few days before I get an answer on this question. I am pretty sure that each DLP admin at least once faced situation when policy didn't work as expected. 

    Which *logging.properties and where I should modify to debbug policies. 

    Thanks. 

     

     



  • 2.  RE: DLP Incident: debbuging\detailed logging - *logging.properties

    Trusted Advisor
    Posted Dec 06, 2016 07:06 AM

    hello

    Does this kind of rule (protocol + user group) works with previous DLP version deployed in your company ? Does it works fine with other content criteria (keyword, IDM, ....) instead of user group ?

     

     If you want go to debug settings (take care if it is not a test environment as it may slow down your system):

    You will find list of DLP log files in following link:

    https://support.symantec.com/en_US/article.TECH220538.html

    If you want to analyze what happens with DLP policy processing you must increase log level for filereader process (filereaderLogging.properties).

    But as far as i did this kind of debug, i just get results of rule processing (1 or 0) but not reason why a rule has not match.

    Regards



  • 3.  RE: DLP Incident: debbuging\detailed logging - *logging.properties

    Broadcom Employee
    Posted Dec 06, 2016 09:08 AM

    User Groups are specific to endpoint incidents as we take the logged on user as the match condition. What you want for you use case is profiled Directory Group Matching (DGM), a related but seperate technology. For profiled DGM you create a EDM index that has email address as one of the fields (could also be IP, username in domain\user format, or IM username) which we can then match on. In this case using profiled DGM will be two tier detection so you will want to use user groups for endpoints and DGM for all other use cases.



  • 4.  RE: DLP Incident: debbuging\detailed logging - *logging.properties

    Trusted Advisor
    Posted Dec 07, 2016 04:43 AM

    Hi,

     Are you sure about this john ? I used "User group" in "sender user group" rule type with mail prevent (14.5) and it works fine (email address are highlighted in DLP incident and no incident generated for same message sent by user not included in user group).

     I agree that DGM may works also, but usually it is a full process to obtain uptodate file and then load it in the tool, so it is always easier to plug on existing company process by using active directory users.

     Regards



  • 5.  RE: DLP Incident: debbuging\detailed logging - *logging.properties
    Best Answer

    Posted Dec 11, 2016 06:51 AM

    On the Email Prevent server $installdir$\Protect\config\RequestProcessorLogging.properties

    Setting com.vontu.mta.rp.level = FINEST is probably your best bet.

    Restart Vontu Monitor after saving. This will show the increased output in RequestProcessorX.log