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:
|
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 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 © 2000, Intel Corporation. All rights reserved.
Intel Corporation assumes no responsibility for errors or omissions in this document. Nor does Intel make any commitment to update the information contained herein.
* Other product and corporate names may be trademarks of other companies and are used only for explanation and to the owners' benefit, without intent to infringe.