So basically was your implying is the deployment Management
Team at this stage has done their work.
They have successfully integrated the patch to the system
and I have to assume the implementation of the patch met or was below the risks
factor identify earlier during the planning of the Software Life Cycle. If problems
were counter the self-healing built-in process of Windows packages will “fix” any
outstanding dll which will be generated or replace. While following these
guidelines we need to take for certain that whatever NESSUS application finds,
it will either be a missing patch or not implementing the latest plug on NESSUS’
part. We have found in some cases, NESSUS is not smart enough or probably is
not in sync with patch update and it will flag problems such as path changes (Apps
location) on the register. Sometimes it will flag issues on features in question
which are disabled on the host.
In conclusion, What I need to understand, NESSUS tool will provide me with a general diagnose
of the host and it will require from my part to do research to verify if those finding
apply to the host or not. If conclusions
do not apply, create the RAD report and explain why we will accept the
vulnerability. Otherwise follow the abstract
of the patch from vendor to mitigate the problem. Use features from the OS to
gather data (audit tracks from the register) to see what patch alter on the system
(before and after settings) or create measure reports as baselines, this is
what I mean by being pro-active and expects this to be a continuous effort to meet
the zero-day patch.
thanks for the insight