Vulnerability Scan Remediation’s

“Context -
Tracking down custom work arounds / registry updates / as well as testing and deployment can be a mind numbing experience. ”

posted Mar 23, 2018, 12:13 PM 

Overview

So I think we are all familiar with the Nessus scans and how they run monthly and our need to apply missed patches, etc.  There are on occasions however when an additional requirement beyond the patch itself is needed.  This typically comes in the form of a Registry addition and or modification.  In the example below for Plugin ID 103127 we can see the Solution outlined however to be fully compliant we need to apply the Registry entry.  This procedure is going to provide a simplified means of Deploying these Remediation’s while providing flexibility for  Testing / Exceptions / Removal.  

Deployment

If you navigate to AD Computers and Users, expand User Groups and highlight Vulnerabilities you will see the following group entries or something similar (evolving):

As you can see these Groups are created based on the Plugin ID from Nessus.  In addition a CVE and or KB is provided in the Description field to better assist you.  As you may have guessed, adding a Computer to one of these groups will apply the related Remediation.   Each of these Remediation's are maintained in one policy however being a Member of one of these Groups will provide that specific Remediation only.  This process can be used for Servers or Workstations.

The Group Policy is currently applied to the following GPO-Test OU's:

Moving a System from a Parent OU to GPO-Test and adding that System to the Group(s) will apply the Remediation.  Once we have verified that these are applied / tested / removed properly we will assign to the Domain level.  Doing so will remove the current requirement to move a System into a GPO-Test OU.  

Application of these does require a GPUpdate.  You can use the following for immediate results: gpupdate /target:computer /force /boot (Keep in mind that if you do use the syntax provided it will Restart your system)

Verification

Open an Elevated CMD prompt and type the following: gpresult /h <path>\results.html

Opening the results.html will reveal a significant amount of information.  Don't be alarmed as these waters are easily navigated.  The policy name is NessusVulScan - Registry - Computer.  If you do a search (ctrl-f) and look for Plugin ID (our example was 103127), you should find a few results.  The first is the Security Group you dropped your machine into.

The second is the Registry entry applied based on your Group membership.  

And as always its usually a good practice to make sure everything looks good in the Registry with the good ole Regedit command.

Testing / Removal / Exceptions

• Testing

  • Measuring the impact of these changes involves testing basic functionality of the operating system as well as any critical processes used by Sanmina personnel.  As a general rule of thumb, the test flow should start with GSI then FIT and trickle its way down to the User.  Some of these will break applications and its our job to identify these early on before any mass deployment.

• Removal

  • In the event an application conflict or some sort of functionality impediment is discovered post deployment, simply remove the System from the Group / gpupdate /target:computer /force /boot.
    

• Exceptions

  • In the event of a known application conflict or functionality impediment, simply do not add your System to the Group(s)

That's pretty much it unless I have forgotten something (This does seem to happen immediately after I press save). I hope this provides a means of simplifying this undertaking which can be confusing at times.