Transcript Robert`s presentation - ISSA

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
Definition of Vulnerability
(in respect to Risk Management and its sub-components)

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)

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,
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?