Policy authoring best practices

Products

• Data Loss Prevention Enforce
• Data Loss Prevention

Issue/Introduction

Background

This article is designed to give an outline of best practices when designing your policy structure. It is important to consider the impact that each rule and exception will have on the complexity and resource use of each policy. It is also important to consider what components you will be deploying a policy to.  A policy designed to be deployed on a network monitor often should not be deployed on an endpoint server.

 

Resolution

The Policy Matrix

When policies are loaded onto a detection server they form a matrix made up of a number of rows. The total number of rows is exponentially proportionate to the amount of conditions and exceptions. This can cause seemingly simple policies to consume a lot of resources, take a long time to load, and extend detection times.  If they get too large they can cause certain detection server components to fail, such as FileReader. The following is an example of the error you might see:

com.vontu.messaging.FileReaderSetup initialize
SEVERE: (DETECTION.3) Failed to initialize Detection
java.lang.OutOfMemoryError: GC overhead limit exceeded
 at java.util.LinkedHashMap.newNode(LinkedHashMap.java:256)
 at java.util.HashMap.putVal(HashMap.java:631)
 at java.util.HashMap.put(HashMap.java:612)
 at java.util.HashSet.add(HashSet.java:220)
 at com.vontu.policy.loader.execution.ComponentTypeSelection.setMatchTypeEnabled(ComponentTypeSelection.java:87)
 at com.vontu.policy.loader.execution.ConditionUseState.fromConditionUseState(ConditionUseState.java:564)
 at com.vontu.detection.execution.ExecutionMatrixGenerator.generateRow(ExecutionMatrixGenerator.java:101)
 at com.vontu.detection.execution.ExecutionMatrixGenerator.generate(ExecutionMatrixGenerator.java:75)
 at com.vontu.detection.ExecutionUpdater.getExecutionMatrix(ExecutionUpdater.java:147)

Consider how the policy matrix is built when designing your policies. The following shows how you can estimate how large a policy is when loaded into the policy matrix:
Total number of rows = (number of matching conditions) * (number of rules in excep1) * (num of rules in except2) * ... * (num of rules in exception n)

Example Policy:

Keyword Policy

• content matches - keywords  "hello", "bye" AND keywords "what", "why"
• matches - regex "[a-z]"

Exceptions

• matches - keywords  "root", "admin" AND ssn 111-99-3023 
• matches - keyword "everyone" AND regex "99*"
• matches - keyword "abc" AND keyword "def" AND keyword "zyx"

Number of matching rules = 2 (Note compounded rules don't make much of a difference of matrix size)

number of rules in exception 1 = 2

number of rules in exception 2 = 2

number of rules in exception 3 = 3

Number of rows in execution matrix for the policy = 2 * 2 * 2 * 3 = 24

What is the relationship between policy structure and size of each row?

The size of each row is directly proportional to the total number of rules in a policy. Adding another rule does not increase the size of each row by much, but it can cause a big change in the total number of rows, after considering exceptions.

How does the type of detection server affect my policies?

When pushing a policy out to a detection server, you must consider the type of detection server you are pushing the policy out to.  Will this policy Pushing a large matrix to the endpoint agents? This can cause issues in the network and also high memory usage on the endpoints.