Security and IT Policies

Basics

Part of security is knowing what assets exist and how they are being used. Another part of security is establishing policies for how assets can be used, and then enforcing those policies. Policies are defined using the ridgeback-server service (from the web client) and policies are enforced by the ridgeback-policy-engine service.

There are four parts to a policy:

1. Time window - the times a policy is active
2. Trigger - the conditions that define a policy violation
3. Action - the procedure to be taken if the policy is violated
4. Countermeasure - the action to be taken to correct the policy violation

An action is generic, like sending an email alert, updating a database entry, or calling a method on a remote service. Executing an action does not necessarily correct the policy violation.

A countermeasure is an attempt to correct the policy violation. It could be removing an offending person or process from the network, removing a person or processes access privileges, or reconfiguring assets in a way that prevents further violation.

Parts of a Policy

Time Window : When the policy is active.

As of version 3.2.0, the time window is defined by a naive scheduling algorithm equivalent to a Unix cron job. Unfortunately, this naive introduces many intractable problems in an enterprise environment.

A set of start/end times to define the time window. The time is be a 24-hour clock time plus a time zone offset. The window will also include days of week and days of month to allow further constraint.

Trigger : An SQL query that "triggers" a policy action.

A trigger is a query statement that returns a list of policy violations. The trigger query statement may set variables that are used by either actions or countermeasures. Thus far, Ridgeback has always used SQL to define trigger query statements.

Action : Something a policy does after a trigger event.

An action is a form of alert that can be used to notify a person or process, record an event, or initiate action by another process.

Countermeasure : Something a policy does to correct a policy violation.

A countermeasure is a procedure used to correct a policy violation. For example, if a computer is violating policy by scanning a network, then a valid countermeasure would be to isolate that computer from the network.

The host isolation countermeasure included with Ridgeback will use the variables isolate_ipv4 and isolate_mac. The variables should be set by the trigger query statement.

Here is an example trigger statement that sets the variables isolate_ipv and isolate_mac:

SELECT DISTINCT
  CoreId,
  src_ip AS isolate_ipv4,
  "11:22:33:44:55:66" AS isolate_mac
FROM NetEvent
WHERE
  remark LIKE '{"type":"Core:Network:IsolateIpv4","date":%'
  and reviewed IS NULL;

Chained Policies

Sometimes real-world requirements are more complex than what can be implemented in a single trigger. To handle more complex security requirements, consider using chained policies. Chained policies are multiple policies that depend on each other.

Example:

• Endpoint 10.10.10.101 should not communicate with endpoint 10.10.10.102.
• If an endpoint engages in unauthorized communication, isolate it.
• If an administrator approves unauthorized communication, allow the communication.

The requirements above can be implemented using two policies. The first policy flags unauthorized communication:

UPDATE NetEvent
  SET remark = 'Core:Net:Isolate,Unauthorized Communication'
  WHERE
    (src_ip = '010.010.010.101' AND dst_ip = '010.010.010.102') AND
    (remark IS NULL) AND
    (reviewed IS NULL);

The second policy isolates endpoints that have been flagged:

SELECT
  NetEvent.src_ip AS isolate_ipv4,
  '11:22:33:44:55:66' AS isolate_mac
  WHERE
    (remark LIKE 'Core:Net:Isolate% ') AND
    (reviewed IS NULL);

Combined, the two policies flag unauthorized communications, isolate endpoints that have been flagged, and allow an administrator to override the flag using the Incident Explorer user interface.