Data Loss Prevention

Hello!

In early stages of fine tuning 2 policies.

I wanted to add an exception for incidents that are Info severity and HTTP and thought this would be simple but when I go to add exception in the policy I can select the protocols but I do not see where I can select AND a particular severity.

Am I missing the way to acheive this, or starring right at it?

Any direction appreciated.

Thank you.

Exclusion is not possible based on severity.

I would personally add a custom attribute, and create an automated response rule with the following filters;

Conditions;

• Seveirty is Info
• Protocol is HTTP

Action;

• Set status to "Tracking"

Then add this response rule to the policy/s.

I'm assuming you want to do this across all policies?

All the best!

Hello,

As first poster mentioned thats not possible.

IMO something is strange in your request. Why should you want to add an exception for a severity if you are in first place specifying in the detection rules to detect something and apply that severity?

Anyway, what you want to achieve can be done if you tear down the detections and specific the protocols, leaving out the HTTP.

I understand is not so quicker as creating exceptions...

Best,

Morgado

Just to pile on here...

I agree with the both responses.  It's seems odd to filter *out* something you configure.  In this case a certain severity level.

Here's another thought.  You have the severity level of Info set to some value, Low set to another and so on.  Lets say in this case, you have Info set to 1 match.  It's your safety-net.  The catch-all.  If you want to exclude these incidents, configure the Match Counting setting to only report incidents with a value greater than your severity level for Info.  In our example, we want that to be two.  See the screen shot.

Now only those incidents with 2 or more matches will be reported.  No more level Info reported.  Of course you'll need to use the values that are appropriate for your situation.

If we've missed the boat here, feel free to post additional details of what you're trying to achieve.

Good luck!

Hello All

thanks for the responses so far.

The reason I was hoping to exclude and no apply a response rule is I don't even want to track these Info/HTTP

For example these info for the policy, lets say its looking for CC#. Just to gather data we were looking at all numbers. Generally we may not be concerned with any under 2, but we see that there maybe be perhaps some broken business process that we want to address that only fall into the SMTP and 1 match.

What I am seeing for the same incident and HTTP and 1 match 99% of the time is this garbage false positives with these arbitrary numbers (and keywords from data identifiers) in the web address, many of which are ....\postback

I was trying to tune out those false positives

Open to other suggestions on how to accomplish this. This probably has to be on a policy level as I dont know how it would effect future policies

J.

The suggestion I posted needs to be applied to each rule.  So, you could set the reporting level at greater than 2 (or 3) for that particular rule, yet leave any other rules in a particular policy untouched.

So a policy rule can be configured to match on a Data Identifier (like CC#'s), and also matching on a Protocol (HTTP) but only report incidents if matches are at least 3.

Make sense?

OR...

Create a report that filters out the noise.  You'll still hve the actual incidents.

Yes thanks Will That does make sense and I do see I can certainly make a response rule to filter this out the problem is I wanted to reduce the amount of data even coming into the DB and system to start

additionally we did originally want to not even have this Info and not see matches of 1 but while configuring and looking at the data we see that under the 1 match and SMTP especially there are areas for education and addressing business processes

additionally since I only want to exclude 1 match/http but I want to see 1/smtp/ftp etc and http et al for above that

maybe I need to look at it a different way and see if there is a way to filter out on a global level these false positives that are these random http redirect strings and postbacks