Best Practices for Tuning
There are many ways to tune a policy, and often there are multiple variations of policies that can accomplish the same tasks. It is often stated that there is no wrong way to tune, but there are definitely some advanced issues you should consider before choosing to tune any rule. Some of the issues to consider include: ease of migration of consistent policies among multiple environments (development and production), ease of transition during CSA MC software upgrades, and the flexibility and strength of the policy.
Understanding Importing and Upgrading
When you design your policy and make changes to the default policy included with the CSA MC, it is important to understand how any changes you make can impact the amount of effort it takes to exchange policies between your production and development environments and also when you upgrade minor or major revisions of the CSA product.
When you import objects you have exported from another CSA MC (or a previous export from this CSA MC), you should understand which items are duplicated and renamed and also which items replace the original. Additionally, you should understand that part of every CSA software upgrade, such as moving from CSA v22.214.171.1248 to CSA v126.96.36.1999, also includes an import process as part of the upgrade.
During software upgrades on the CSA MC, the imports compare each individual imported objects against the current objects to see if there is a match by name. If there is a match, the system determines if the object is an exact match or not. If it is an exact match, the new object replaces the old object and the old one is removed. This means that any policy that uses this object now includes the new object version automatically. If the object is not an exact match and some of the parameters have changed with the upgrade, the new object is imported and displays the new version number, but it does not automatically replace the object in the current policy. You need to perform compares on the new and old object to see what changed in the newly upgraded object and determine if you would like to incorporate the changes.
During an import of an object that is not part of an upgrade procedure, the objects are also compared. If the object name already exists, the system creates the new object being imported but appends to the name to differentiate the newly imported object. The appended name contains an underscore character followed by a portion of the name of the import process you created to import this object, such as _import-name. You need to compare and apply these new objects as necessary using a manual process. Of course, if the new imported object does not match any existing objects, it simply adds the object to the system without changing the name of the object.
You can see that the previous two types of imports can cause you to perform manual tasks upon completion to apply the policy you want and to clean up the post upgrade and import environments. This can be a tedious task. Ensuring that you make as few changes as possible that cause the post-import tasks to grow in number greatly simplifies your job as an administrator. For this reason, it is important that you think about the objects you edit before you make the changes. At first, it might seem like a better idea to edit the settings in default objects, so that you do not have to create an additional rule to add the functionality you are attempting to add. However, if you do this you actually ensure that any imported or upgraded policy does not match and results in duplication that requires manual cleanup. You should always attempt to leave the default objects simple and unchanged if possible. This is not always the case because there are exceptions to the rule, but if you attempt to make this part of your decision-making process, you will have much simpler administrative tasks in the future.
Variable and Application Class Usage
When creating policy, many types of objects are available to you. Often, because many of the fields available to the administrator allow literal values to be entered along with variables, the administrator enters the value into the fields rather than creating a new variable (such as File Set, Network Set, and so on) or application class. It is recommended that you attempt to create variables and classes as often as possible to allow your future policy to deploy more rapidly. Any object that can be reused later in the software life-cycle simplifies your policy development and also ensures consistency among multiple administrators.