Skip to main content

Security Policy Guide 24.2.20 and 24.2.10

Rules for Application Policies
Override Deny Rules, Allow Rules, and Deny Rules

Illumio allows or denies traffic between applications using policies that you write. To write application policies, you must create rules for the policy.

You can define and manage rules to control and secure communication within and between application groups.

Illumio has the following types of rules for application policies:

Override Deny Rules

Note

Override Deny rules require VEN release 22.3.0 or later.

These rules have the highest priority and block all traffic, regardless of the position of other rules in the policy.

Because they have the highest precedence, they can't be overridden by another rule, such as any implemented Allow rules. If an administrator creates an Allow rule by mistake, the Override Deny Rule, which denies such communication, acts as a safeguard.

They are used to stop traffic completely, especially during a security breach.

Create an Override Deny rule:

  1. Go to Policies and click Add.

  2. Select Override Deny Rule and then click Add Rule.

  3. In Sources, select one or more sources.

  4. In Destinations, select one or more destinations.

  5. In Destination Services, select one or more services.

  6. Click Save.

Override Deny rule implementation.

There are various implementations for Override Deny rules, such as:

  • Blocking all traffic between your Production and Development environments except over splunk-data (9997TCP)

  • Additionally, blocking all traffic between all workloads over SSH with no possible exceptions (highest precedence)

To satisfy these requirements, proceed as follows:

  1. Add a Deny rule specifying 'Production' as the source and 'Development' as the destination, blocking all services.

  2. Add an Allow rule specifying the same source and destination, permitting traffic over splunk-data (9997TCP).

  3. Add an Override Deny rule blocking all traffic between all workloads over SSH. Because this rule has the highest precedence, it cannot be overridden by an Allow rule.

Allow Rules

Allow rules have the second highest priority, after Override Deny rules.

They allow traffic to and from specific workloads. They act like security guards, permitting only registered or authorized traffic, and are used to define explicitly permitted traffic.

Deny Rules

Deny rules increase security by allowing only known, trusted traffic. They reduce the risk of unauthorized access or data breaches.

Deny rules temporarily block specific traffic, often during initial setup. They are useful for blocking known problematic traffic while determining what should be allowed.

In the Allow List model transition, Deny rules are gradually replaced with Allow rules, which specify precisely which traffic is permitted.

Deny rules can be applied with different labels and groups. This makes them powerful for blocking traffic in one or both directions. By deploying VENs (Virtual Enforcement Nodes) on all workloads and setting the correct environment labels, you can easily block traffic between different environments.

Implementing Deny Rules During the Transition to Allow Rules

Start with deny rules to block risky traffic.

  • Monitor traffic patterns to understand what needs to be allowed.

  • Create the Allow rules for essential, trusted traffic.

  • Gradually remove deny rules as the Allow rules are established.

Once the Allow rules are fully enforced, all traffic is denied by default unless explicitly allowed by an Allow rule. Full enforcement of Allow rules ensures a secure and controlled network environment.