Security Bulletin Patch Analysis

[Coleman Blake_2]

Is it possible to generate a list of dependent patches based on a set of patches generated by analysis of the Security Bulletins (or any other source) AND the patches installed on a given system?

Custom Patch Manager almost does this and so does security_patch_check, but neither gives us the list we develop from a manual analysis of the Bulletins. If we use this list to generate a patch list from the ITRC Patch Database, we get a large number of dependent patches, most of which are already installed.

We then need to either check the dependent patches manually or download all of them and let swanalyze do it.

Is there a better way?

Coleman Blake
Peace Corps

[jherring]

Coleman - there is no way to do this that I know of, patch DB is the best place to drop in manual list of patches, but you still get patch dependencies that are possibly on your system.

If someone has a method I would love to see it.


Jon

[Steven E. Protter]

I wish I could do this in a cron script or something.

So far the only way to deal with dependencies is to click into the database at itrc.hp.com

At that point, if i'm feeling frisky, I cut and post the web page generated into a file. Then a script I have does the old swlist -l product | grep $PATCH and reports which ones are already installed so I might unclick those boxes.

There is still no fully automated process and I thinks that is due to security concerns. I would not expose my systems to a process that can run swlist or swanalzyze. Not with information passing through the public Internet.

SEP

[Keith Buck · Accepted solution]

Actually,

Some of the functionality (security patch analysis) you are requesting was added recently to the patch assessment tool (used to be called Custom Patch Manager) here:

http://www1.itrc.hp.com/service/patch/assessSystemsPage.do

If this still doesn't meet your needs, then maybe you can clarify the "almost does this" part of your question a little more.

Security Patch Check doesn't require you to upload your system information, does tell you which patches have dependencies, and is automatable. It doesn't do the full dependency analysis (sorry).

Don't forget to still read the bulletins in case of product updates and manual actions.

I recently asked a survey question asking customers to compare the functionality of these two tools. I'd be interested in your comments as well:

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=426710

-Keith

[Coleman Blake_2]

Thanks to everyone who replied.

The patch analysis tool "almost does what I want", in that it uses information about the patches currently on my system (and other information as well) to generate a list of recommended patches and their dependencies. If a recommended patch has a dependency and that dependent patch is already on my system, the patch is not added to the list of patches to be downloaded.

I would like to have the ability to submit two files. One would be configuration file like the "*.fs" file generated by cpm_collect.sh. The second file would be a list of patches generated, for example, by manual analysis of the Security Bulletins. The result of this would be a list of the patches needed to install the patches in the submitted list.

This list would be the same list of patches I would get from the patch database by entering the patches from the second file above, minus the patches already installed.

I'll fill out the questionnaire. I remember getting it, but was too busy to fill it out at the time.

Coleman

[Keith Buck]

Coleman,

So, the second proposed list that you would send to the patch assessment tool would be

A. a list of patches that are already installed.
B. a list of preliminary patches that are installed, but not in the itrc database that the patch assessment tool uses
C. A list of dependent patches that also need to be installed
D. A list of patches which you feel that you don't need because of other mitigations (service disabled, for example)
E. Something else?

Patch assessment should already do A and C, while Security Patch Check should handle A and B (depending on how the preliminary patch and its successors were packaged).

It can be argued from a defense-in-depth perspective, that you ought to eventually install the patches in D in case the service gets re-enabled, but of course that tradeoff depends on your environment and the potential for disruption.

Thoughts?

-Keith