## Consider Exceptions to the Default Rule

Many enterprises find that by careful consideration of the default behavior roles, a widely published pre-shared key, and the Default Rule, they can meet their security requirements without extra effort. This model is quite workable and provides adequate security. It is also simple to deploy and maintain.

Some enterprises wish to create additional rules that govern communications between two specific systems.

Earlier, we introduced a scenario where the president and chief financial officer of a company wished to implement extra security for their communications. For this scenario, a new rule is needed. Compare a possible rule for this scenario to the System Policy's Default Rule:

##### Rule Comparison

Property | New Rule | Default Rule
--- | --- | ---
Destination Workgroup | President and CFO only | Everybody
Security Action | New Security Action: Up to 4 hours. Then, a new security association is negotiated. | Default Security Action: Up to 8 hours, then a new security association is negotiated.
Rule Failure | Deny Communication. | Allow communication without Security.
Authentication | Use certificates. | Use the System Policy's settings (Allow Communication without Security for Secure Responders and Secure Initiators or Deny Communication for Lockdown).

In addition to these rules, both the president and the Chief Financial Officer would have the Secure Initiator default behavior. The rule might also want to use more secure options, such as perfect forward secrecy, which provides a very secure negotiation of session keys. There are many other security options that can be chosen when you create a security action for this rule. See Customize Security Actions for more information on options for security actions.

By comparing the new rule and the default rule, you can see how the new rule provides an extra measure of security. The new security action is much more limited. Longer time limits or size limits on a security action can give an intruder an opportunity to intercept and possibly corrupt packets. By denying communication in case of rule failure, you ensure that communication between these two systems will never occur in the clear. Finally, using Entrust* certificates provides for more robust and secure authentication of those users.

Copyright © 2002 Intel Corporation. Legal Information