DLP in RTP with Traffic Direction Issue?

  • 3 January 2024
  • 2 replies

Badge +3


I have a policy setup to block uploads to a specific instance of an application when any DLP profile matches otherwise alert via the traffic direction functionality in the RTP. This has been working fine for a while. Today, I went to add additional instances and when I had the user test, it was still being blocked, completely bypassing that rule and going to my default deny, its not matching DLP because if it was, it would be blocked by the policy I am talking about, its sliding right by my rule... I tried a separate RTP at the top with just the instance configured the same way with no luck. The only way I could get it to work was to remove the DLP profiles.

The specific instance I was testing with was a third instance that was sharepoint.

Has anyone seen this?


2 replies

Userlevel 6
Badge +16

Hello @Natedog0024

You mentioned that you had a test policy as well which did not trigger.  Did the test policy also have the DLP profiles in it?  If it triggers without the DLP profiles then that indicates that the test data may not match the profiles that are being used.  Do you have the sample data you're testing with? 

Badge +3

Hi Sam,

The test policy also had DLP. However, the way the rule is built as you can see in the screenshot is if the file does not match DLP alert, if it does match DLP block. So the traffic not matching DLP should alert on that RTP and essentially be allowed but instead it is skipping completely over it. I am having a similar issue with the same type of rule except the rule is category based and the activity is edit. If the edit matches any dlp profile it should block otherwise allow yet its skipping the rule all together and going to the default deny. Support could not figure it out so I have a meeting to do backend captures with them on Monday. Curious on if this is related. Unfortunately on this one, it was a one time sharepoint link so I wasn't able to replicate it and i couldn't hold off for a ticket which is why I posted here.

The case for that one is 00362531.