## Customizing Rules

Rules define how you want to communicate with other systems on the LAN. For example, one rule can define how to communicate with a file server using specific security settings. Another can define an entire group of systems for which communication will always be allowed without security.

The rules in your System Policy are listed in the Policy Editor.

The order of the rules is significant, since they are evaluated from top to bottom. If a more general rule is above a more specific rule, the general rule will take effect if it matches a given IP packet. If this is not the desired behavior, then you should move the more specific rule above the general rule.

How do I view the Policy Editor?

### About Rules

In order to understand the elements of a rule, we can look at a rule listed in the Policy Editor called Finance Group.

This rule was created to provide security for all communications with members of the finance group. When the administrator developed a plan for deploying Intel Packet Protect, she decided that because of the value of the information handled by members of the Finance Group, a special rule with higher security was required. To meet that need, the "FinanceGroup" rule was created. All the members of this department use this rule. Each member of the department must have the exact same rule in their System Policy to ensure secure communications between members of this group.

### About the FinanceGroup Rule

#### Rule Name

When you create a rule, you must give it a name that is unique to the LAN. Click Intel Packet Protect Naming Conventions for rules about naming rules, destination workgroups, and security actions.

#### Destination Workgroup

A special Finance destination workgroup was created. This workgroup names all the members of the Finance department who need to communicate securely using this rule. You can view the details of the destination workgroup:

The Finance destination workgroup has three members. When the administrator created this destination workgroup, she added each of the systems used by these members. Systems can be added by IP address, system name, or a combination of both methods.

It is important to remember that members of the Finance destination workgroup are authenticated based on the system as named in this window and not by user IDs. For example, Bill Walters uses WALTERS-DESK1 as his primary system. If he was using another system temporarily, he would not be able to communicate securely using the FinanceGroup rule, because the other system is not named as being in the workgroup.

#### Security Action

The administrator could have used one of the pre-defined security actions, such as the Default Action or Deny Communication. Instead, she created a special security action for this rule and named it FinanceSecurity1.

For this customized security action, the administrator changed some of the defaults. Instead of a time limit of 8 hours, she decided to use a limit of only 5 hours. By customizing the time limit, security associations that use this security action will last for a shorter period time (as compared to the default of 8 hours). Thus, there is less time for an intruder to attempt to subvert the communication before the limit is reached and a new security association is negotiated. Click for more information about security actions and security associations.

#### Fallback action if the rule fails

The administrator wanted to make sure that there would be no possibility of allowing communication without security. Thus, if the rule fails, communication is denied.

#### Rule Authentication

As an extra precaution, the administrator decided that each member of the Finance destination workgroup will use an Entrust/Entelligence* certificate for their communications. Certificates offer a higher degree of security than the default pre-shared key.

### Conclusion

This example shows how a rule was created to ensure secure communications between members of a workgroup. This particular rule is too complex and can be thought of as "overkill" for most communications in a LAN. But it does illustrate some of the issues that are considered when creating rules.

Developing the Deployment Model contains some guidelines that you can use for developing your own plans for creating rules in Intel Packet Protect for your organization.

Copyright © 2002 Intel Corporation. Legal Information