Recommended Practice for Using Security Focus Reports

Use cases for Security Focus Report data, including some advice on best practice and troubleshooting. All information in this document is recommendation, not rules or standards.

Recommended Practice for Using Security Focus Reports

Note: Reports are provided as a service, with no specific requirements on how a department uses the data. What follows is advice on how to use the information in the report to reduce IT security risks quickly and effectively.

When applied carefully, the steps presented here will help a department comply with UW Madison endpoint management and data security policies, including those linked below for reference:

Endpoint Management and Security Policy
UW-Madison - IT - Cybersecurity Risk Management Implementation Plan

Some departments may develop their own workflows, often applying the steps given here in a different order, according to department needs. However, reviewing the guidelines given here may help an IT staff member use available data more effectively.

Security Focus Report data is sometimes used for additional projects, especially tracking the number and age of vulnerabilities in order to assess the effectiveness of patch management. Such use is beyond the scope of this document. All recipients are encouraged to give priority to endpoints that hold high risk data (restricted or sensitive according to UW Data Classification), as that is what Security Focus is intended to emphasize.

An effective workflow to reduce risks based on Security Focus Report data.

  1. Start with the Brief.


    The security tool deployment numbers and associated graph make a good starting point. Check to see if the deployment figures are as expected. If so, move on. In cases where the numbers given do not match the scale of security tool deployment in your department, troubleshooting will be needed. The steps are covered in the last section of this document.

    After the graph, there are usually recommendations from the Security Analyst, emphasizing high risks and what can be done to remediate them. Typically, this is a machine with a large amount of high risk data that is vulnerable in some way, and how to make it more secure. Limited deployment of a tool may be mentioned here as well.

  2. Look at the vulnerability summary tables. If you have an application that is vulnerable on most hosts in your department, pushing out the most recent patches (with a tool such as BigFix) have a widespread impact. Any End-Of-Life software should be removed or upgraded if possible, but obsolete operating systems are especially serious because of the number of vulnerabilities and potential impact if exploited. The last table lists individual hosts with very serious vulnerabilities, usually because of missed patches going back a year or more.
  3. Look at machines with a large amount of high risk data (restricted or sensitive), if applicable. There are two questions to be asked here. What is the data and is it really high risk? If yes, what can be done to secure it? If it is on a workstation, the end user usually knows what the data is, if it is sensitive or a false positive, and if it is needed for essential business purposes.

    • If the data is actually low risk (internal or public), tag it as false positive. See KB 43638. While improvements in the Spirion application have greatly reduced the number of false positive results, it will never be 0.
    • If the data is high risk, and necessary from business purposes, the machine becomes a priority for patching. Any severity 5 vulnerabilities should be fixed ASAP, and severity 4 vulnerabilities should be fixed promptly. There may be other options, depending on the purpose of the data. Old records that must be retained can often be archived offline. Some data can be moved to a secure server or Box folder, and downloaded to a workstation only when actively used.
    • High risk data that is not needed should be deleted securely! Don't just click "delete" as the file will remain in the recycle bin, when either the user or an adversary can recover it with ease. Even emptying the recycle bin is not secure, because only the directly entry is actually removed. The data is still on disk until it is overwritten, and it can be recovered with specialized software.


      Spirion has a Shred untility that will irreversibly delete a file. See KB 14443 for more information on this, and other actions you may want to take on high risk data. Use these features with caution, but if you no longer need a file with restricted data, simple deletion is not enough.

    The same basic steps apply to most servers. The difference is they are usually more secure then workstations, making them a good place to store high risk information the department needs. In such cases, the server must be the department's first priority for patching. It is also a good practice to limit what software is on such a server, as that means less to patch and reduced risk of error.

    File servers will contain data from multiple users, and it is often unrealistic to track down every file with Spirion matches. In such cases, the best practice is to assume that some of the data is high risk and keep the file server patched accordingly.

  4. Use the list of vulnerabilities to help with patch planning. The second tab on the Excel report covers the entire department, regardless of data classification. Sorting, filtering and pivot tables can be used to focus on specific issues that might not be covered in the summary tables.


Beyond false positive results (see above) there are several issues that may need to be addressed. Ones that have been observed previously are covered here. For other cases, open a self-service support case at Cherwell user portal.