This article describes the purpose of the Symantec ESM Policy to CCS Migration Utility and special considerations when using converted standards in CCS.
The Symantec Control Compliance Suite (CCS) Enterprise Security Manager (ESM) Policy to CCS Standard Migration Utility was created to streamline the process of mapping your ESM results into the CCS Standards Module via a CCS standard. The utility will create a CCS standard given an ESM policy as input. If you have multiple ESM Policies that you want to report against, you can create additional CCS standards by running the tool again for the other policies.
The created standard is a starting point for organizing and reporting results from ESM in the CCS infrastructure. Each possible ESM result will be mapped either by Message ID, or by Message String Name. Please see the ESM Policy to CCS Standard Migration Utility Users Guide (attached) for the tradeoffs to using each approach.
The resulting standard will be organized by module. You can reorganize the standard to align with your organization’s written standards and add a variety of content to aid in driving remediation and compliance.
Some ESM messages return for more than one check, the multiple messages with a shared message ID will be rolled up to a single check in CCS. This is particularly noticeable in checks that use templates that allow the assigning of given ESM messages to multiple errors (e.g. Integrated Command Engine module). This can be customized by the end user by duplicating the check in the CCS standard, and adding additional logic to separate out the results (such as a registry key or file name in the Message Name field, or detailed data that appears in the Message Information field of a given check result). Until the check logic is adjusted to separate out the various results for these ESM messages, your CCS reporting may appear not to align directly with the results in ESM. You may wish to remove checks for informational messages that are not considered pass/fail, or separate those out into separate standards depending on your reporting needs. A variety of logical and regular expression matching operators are available to provide as much granularity as is required to meet your reporting objectives.
Some ESM modules return the same message string (or message number) for multiple checks within the same module. An example would be multiple checks failing because a configuration file cannot be located. In cases such as this, the ESM console may display only one of these error messages about the file not being able to be located. However the ESM agent raw report data contains the same message for each of the checks. In this case, the corresponding CCS checks in the standard (converted from the ESM policy) will show each individual failure, resulting in multiple checks failing in CCS. This also may appear to not align directly with the ESM results. Again, the check logic in the CCS standard can be adjusted to keep multiple failures from occurring when there is a shared message string being returned by multiple checks in the same module.
When changes are made to the existing ESM policy, these changes do not automatically appear in the corresponding CCS standard. In particular if checks are added to the ESM policy, those checks will not be reflected in the CCS standard. These checks can be manually added by making use of the same logic as found in other ESM checks and utilizing the message strings that can be returned for the check selected. Refer to the Symantec Enterprise Security Manager Checks and Template Reference guide (www.symantec.com/avcenter/security/Content/Symantec_Enterprise_Security_Manager_Checks_and_Templates_Reference.chm) for the message strings or codes that can be returned by a given check. Changes such as a Security Update on the ESM agents and manager may result in an update to the ESM environment of new checks, template updates, messages, etc. When Security Updates are taken, check the release notes for any changes that may have occurred to modules in the converted policy. If additional checks have been added to a module (and you want to use these checks) or new messages have been added, then re-conversion of the ESM policy and re-import of the resulting standard is indicated. Make sure that if there is any customization (as mentioned above) in the existing CCS standard checks, that this customization is replicated in the newly imported standard. Cut and paste from the old converted standard to the new standard can be done to avoid rebuilding.
NOTE: The utility is not intended to directly duplicate the ESM reporting in CCS standards, but rather to shorten the time needed for an end-user to build customized CCS content to report against their ESM infrastructure. The majority of converted checks will work correctly.
To help in identifying the CCS converted checks that may not appear to align with ESM results, the attached spreadsheet (message-checks_Mapping.xlsx) contains a list (valid as of Security Update 40) of certain selected ESM message ID codes and the associated checks in ESM that can generate them.The set of ESM check message ID codes in this spreadsheet may only cause one failure to show inside of the ESM console for a given computer in a given module but may actually show multiple check failures in a migrated ESM-to-CCS standard evaluation (as mentioned above).
Imported Document Id
Symantec ESM Policy to CCS Standard Migration Utility User's Guide