Security Analyst Best Practices

There are a number of ways to approach your overall tagging strategy, but the best method for your company depends on a combination of the number of templates you are working with and the number of tags that you need to best monitor the security status of the templates.

Ideally, you need to find a balance between these strategies listed below that best suit the specific settings that are deemed critical to your company’s security. Once you identify these key settings, you can create individual policies to report on the status of the most important security requirements.

1. The specific security settings you want to monitor

It’s important to determine the specific settings you deem critical to your company’s security. For example, if DES (Disk Encryption)/DOS (Disk Overwrite on delete) are important security settings to monitor, you need to identify all templates that contain these settings and then tag them appropriately. As another example, perhaps you need to ensure that device comply with certain network protocol status at all times (i.e. Telnet must be disabled on all devices), you should identify all protcols and their status (enabled/disabled) and the templates that apply those settings.

2. The number of templates containing security settings vs. the number of tags required

If each template contains only a single security-related setting, it is a simple matter of creating and applying one security tag to each template. However, if security concerns are spread across templates, you will potentially require many individual tags that you can apply broadly amongst templates. To illustrate the approach, consider the following extreme examples:

• Example One: One template to address all security concerns.

  Perhaps IPv4 protocols are very important security concerns, and you create a single template that address all network protocols. You then create a single security tag and apply it to your template, as illustrated in the diagram below.

  

  The potential problem with this approach is that it oversimplifies tagging. For example, if the following security settings are included in the IPv4 protocols template (TELNET, SSL, FTP, SFTP, RHPP), If the security needs on a particular device deviate at all from the settings in the single template, you will necessarily have to create another template to fill the need, and then you will also need at least one new tag to reflect the security settings in the new template.

• Example Two: One security setting per template.

  You could create a separate template for every individual security setting, ensuring that each template requires only one tag. However, this scenario requires you to create many templates, but also many tags and will take time and effort to tag all the templates properly. It may also be more difficult to trace which devices are out of policy and when and why.

  

• Example Three: Multiple templates, multiple tags.

  As depicted in the diagram below, the same number of tags is required, but you can apply multiple tags to a single template. This scenario requires you to create many templates and a series of tags that can be applied to more than one template.

  

3. Beware of Conflicting Policies

When applying templates to devices, it’s very important to track the security settings within the templates to avoid conflicting policies. For example, it’s possible to create one template that enables DOSS and another that disables it. If you apply both templates to the same device, and both templates are tagged in Security Analyst using two unique tags (DOSS_ON/DOSS _OFF), the device will always report as out of policy.

As a best practice, it’s important to ensure that a device is installed with only one tagged template. This practice will make it much easier to identify which template is out of date on the template, and why.