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.

Troubleshooting

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.

• The total number of endpoints covered in the report is less than the department has. Remember that data from DoIT security tools is used to generate the report. Endpoint that do not have Qualys, Amp, or Spirion will not show up at all. If this is your first Security Focus Report, there could also be a problem with the scope. UDDS codes or Spirion tags could be missing from the request, which is easily corrected before the next report.
• Report includes computers from another department. Open a support ticket at Cherwell user portal to let cybersecurity know. The problem is with the scope of the report, and is easily corrected.
• A computer's data shows a drive that isn't part of that machine. Spirion scans a mapped drive along with the computer is is mapped to. So if an external drive is mapped to a computer at the time of a scan, any matches found on the mapped drive will be entered into the Spirion database with that computer, even after the drive is unmapped. If there are matches on the mapped drive, they are likely to be high risk data somewhere in the same department. As with any true positive, this data needs to be located and secured. File paths, especially users/userID, can help identify who is responsible for the data.
• Too few (or too many) machines appear for a specific tool, most often Spirion. Now that Spirion 11 is retired and there is only one source of Spirion data, this problem should disappear in 2024.  If it persists, open a support ticket at Cherwell user portal .
• How can one computer have over 200 vulnerabilities? When this happens, it is usually an obsolete operating system, although any End Of Life software may have 100 or more recognized vulnerabilities. If the OS version or application is not maintained, patches will not be available (except in rare cases). Upgrade or replace machines with obsolete operating systems if at all possible. They not only put the computer and the data on it at risk, they can also provide an attacker with toehold into the network that can be used to target other systems. Obsolete applications should also be removed or upgraded. In the case of embedded systems that can't be upgraded, run the machine off the network to protect it, because it is extremely vulnerable.