Patch Management By Robert Hawk Driving Factor If

Patch Management By Robert Hawk

Driving Factor If the business decides to utilise Risk Management as a major component driver then patch management will fall into the scope of the Risk Management strategy.

Risk Management Components Threat Management Malicious Code Management Vulnerability Management Patch Management

Components Definition of Vulnerability (in respect to Risk Management and its sub-components) n An internal weakness or defect that can be exploited to perpetrate harm or damage. Definition of Management (in respect to Risk Management and its sub-components) n The process of detecting, assessing, and finally mitigating Risk and Risk Sub-Components.

Considerations It is noteworthy to mention that there is: 1. 2. 3. No such thing as bullet proof code. An Operating System or Application that will never need to be patched. To mitigate vulnerabilities in any code, the patch for the indicated vulnerability has to be applied to the system. If one is available.

Managing Vulnerabilities Detection: Usually found by a hacker, a third party lab, or even the code developer. Keep in mind the channel by which you receive patch announcements is legitimate.

Managing Vulnerabilities Assessment: When the code manufacturer releases the patch, it is your responsibility to acquire the patch and assess it. To find out whether your environment requires the patch or not.

Managing Vulnerabilities Some of the logic that you can utilize in your assessment is Do we currently use the code that the patch is for? If you do not have the code installed then do not install the patch. What is the impact level of the patch? Is it low or critical? Will you depend on the code manufacturer’s assessment or will you conduct an assessment of your own? Will the patch have any adverse effects on the environment? The only way that this can be answered is by testing, testing…

Managing Vulnerabilities Mitigation: How will the patch be implemented into the environment? Will you utilize SMS, SUS, or a third party manufacturer’s solution? How will other systems be dealt with: Like AIX, HPUX, Sun Solaris, the Mainframe, and the Cisco switches and routers?

The Grand Question… To patch or not to patch, that is the question? The whole concept of a network being a “crunchy shell with a soft chewy center”, meaning that the network perimeter is well guarded and the internal network is collapsing and caving in on itself.

Consequence of not Patching The simple fact is: The patch will safeguard the environment and should be installed, or the patch whacks the environment and cannot be installed. If you are dealing with the latter, there is a choice that needs to be made. To not patch the system and risk the vulnerability being exploited and the environment being taken down, or that the effected system will need to be upgraded, recoded, or otherwise changed to accept the patch, so as to mitigate the vulnerability.

Microsoft Specific Environments For larger environments SMS is the best choice. There is more granular control and reporting on the outcome of the process.

Microsoft Specific Environments For smaller environments SUS is the best choice. The “Microsoft Baseline Security Analyser” should be used to audit the success of the process.

Microsoft Specific Environments For multi-site environments either an SMS or SUS hierarchy can be setup to facilitate the control and distribution of patches.

Options It is always possible to utilize a third party patch management utility to facilitate the acquiring, installation and auditing of Patch Management tasks.

The End Questions?