Started: 5/22/2009 8:41 AM | | |
|
 | Style for "Vendor patch-testing" Informations Vendors of "Process-Control"- and "SCADA"-systems should provide informations about compatibility of new OS- or 3rd party-patches, for software, runs on there PC/SCADA-systems.
A similar style from all vendors whould be very helpfull for the customers to handle these informations in there systems.
Bruce Honda and I worked on a example how these sytle could look like. When we do these we basically have Microsoft patches in mind, but I think it could also used fpr other patches.
The files are also availabel in the patchgroup document, but I also attach them here.
Please write comments and ideas. |
|
Posted: 5/22/2009 9:58 AM | |
|
| My pet peeve is to have patch status info as soon as a patch is released. If a vendor is going to test the patch let's communicate that! This helps me to not only assess if I should be testing but it provides me with the ammunition to go back to our IT Security team and let them know. No status is the worst status. Providing status update later at testing completion is fine if I know that patch was being tested!
my two cents |
|
Posted: 7/29/2009 10:31 AM | |
|
|
Bob Mick sends this to me, and I think he is right we should have a look on it..
Florian,
Here is a Cisco response to the recent Microsoft ATL vulnerability. http://www.cisco.com/warp/public/707/cisco-sa-20090728-activex.shtml
This situation is very similar to (if not exactly the same as) the one our industry suppliers are in. I think this might serve as a good check list for identifying elements that must be, should be, would be nice to be … in our reporting standard. If you would like me to process this further let me know and I will try to find a little time.
I am not suggesting at this point that the standard include all of them. I agree with your start simple approach, but we should include a useful set. Additionally, it is not good to change it too quickly – we should make it worth the vendors investment and not force them to work in changes too frequently.
I will trust your and Bruce’s knowledgeable filtering of my inputs J
Bob |
|
|
| The Cisco advisory is easy to consume on a per patch basis.
Whereas the current working group proposal targets a summary roll up, ideally patch status information in a single file per vendor.
It's interesting for the ATL vuln that US Cert is attempting to combine status for all vendors in a single VU.
|
|
|
| I agree that we should not go for everything that we can think of but we do want to avoid too simple of a format that we will have to update right away. I will bring the topic up at the next meeting on Aug 11th.
|
|
|
| These comments are older but I thought here would be a good place to collect them:
Hi ! Another issue that we frequently come across is the requirement to "roll-back" (contrary to uninstall) a patch or an update in case of problems/ regression issues. How should we address this? In some cases it may not be possible to roll-back a patch or an update. Best regards, Swarandeep ABB
| <Marnix.Haije@shell.com>
12.05.2009 08:07
|
Please respond to
"SP99.06" <sp99-06@isa-online.org> |
|
|
To
| "SP99.06" <sp99-06@isa-online.org>
|
|
cc
|
|
|
Subject
| [sp99-06] RE: Vendor Patch Information Project |
| All, Some input into the meeting. I'm sorry never being able to dial in, but I am in the 'wrong' time-zone (Europe, Netherlands) and have small children. If we only consider Microsoft patches, all the reporting functionality that I require is in the WSUS server.
Groups can be created and per group (Vendor/OS/platform/application) patches can be configured to be 'needed' or 'not needed'. This gives the Vendor specific information in the reporting. Naturally, WSUS also know which of the 'needed' patches are actually installed. All the major PAS/DCS vendors deliver their information in a format that is currently good enough me me. It enables me to update my WSUS server with the latest Vendor specific info. If this job is done regularly, this is no big deal. My companies biggest challenge lies in the fact that this information needs to be entered into all WSUS servers. There are about 50 in the process control environments. Because this process is manual, it is error prone. Unfortunately, Microsoft does not help us in this area (yet), because it is (still) not possible to import 'profiles' into WSUS. When this import functionality becomes available, we can easily start directing Vendors to deliver us information in the WSUS format. Many of our sites are already 'managed' by vendors, so they have the same incentive as we do. I hope this is useful input into the discussion. If you have any questions, please don't hesitate to ask.
Marnix G. Haije
Senior DACA Engineer
Shell Global Solutions International BV
P.O. Box 38000, 1030 BN Amsterdam, The Netherlands |
|
|
| More on the topic:
Even when Microsoft rates a patch important we evaluate the reasoning and have bumped up a patch to critical in our environment at times because the assumptions Microsoft used did not apply to us. So the risk assessment in your own environment not only is based on how you've secured your process control network and how IT has secured the corporate network but also what applications and user behaviors might put you at risk. e.g. some apps require admin privs due to how it interacts with the O/S.
|
|
|
|
I submitted the Cisco example because of its large content, but the actual vulnerability is very interesting too.
This is a different kind of 3rd party (ISV, vendor ...) problem - typically OS patches might change the behavior of an application. This one actually puts a vulnerability into your delivered code - DCS, HMI ... (if you use the ATL). Has anyone (vendors) looked into this?
From: Bryan Owen
Posted: Wednesday, August 05, 2009 9:06 AM
Subject: Style for "Vendor patch-testing" Informations
The Cisco advisory is easy to consume on a per patch basis.
Whereas the current working group proposal targets a summary roll up, ideally patch status information in a single file per vendor.
It's interesting for the ATL vuln that US Cert is attempting to combine status for all vendors in a single VU.
From: Florian Ott
Posted: Wednesday, July 29, 2009 10:31 AM
Subject: Style for "Vendor patch-testing" Informations
Bob Mick sends this to me, and I think he is right we should have a look on it..
Florian,
Here is a Cisco response to the recent Microsoft ATL vulnerability. http://www.cisco.com/warp/public/707/cisco-sa-20090728-activex.shtml
This situation is very similar to (if not exactly the same as) the one our industry suppliers are in. I think this might serve as a good check list for identifying elements that must be, should be, would be nice to be … in our reporting standard. If you would like me to process this further let me know and I will try to find a little time.
I am not suggesting at this point that the standard include all of them. I agree with your start simple approach, but we should include a useful set. Additionally, it is not good to change it too quickly – we should make it worth the vendors investment and not force them to work in changes too frequently.
I will trust your and Bruce’s knowledgeable filtering of my inputs J
Bob |
|
Posted: 8/10/2009 6:04 AM | |
|
| some general infos, comments
- we did not only focus on Microsoft, but the original sample comes from MsMUG and there the focus was only Microsoft
- de did not focus all patches, only security relevant patches
At the moment I am working on the XML- and XSL-files, to bring them in a commen style to fit all security patches, not only Microsoft. I also try to implicate our comments and insert some new columns. |
|
Posted: 8/13/2009 4:48 AM | | |
|
|
comments send tome via email from Dale Stipe:
see also attached file...
-------
As for our using the agreed upon XML style, I assume we would make every effort to use it when communicating with our customers each month, as a minimum, once it becomes an agreed to standard. As additional motivation for us to do so, several of the comments that I will be including are for optional entries so that a single file could be used for all of the tools that we currently support that needs that specific data. Currently we have very similar data in at least four different types of files so a single unified approach would make our job easier and less error prone. That would be our end goal but it will take time and additional effort so this is a very good start if we can get all venders to agree.
I did look into the possibility of one of our tools having already defined an XML style for this particular data as an action item from the teleconference and to provide a sample of that data. Interestingly, none of the current files use XML so there is nothing I can share other than Excel spread sheets, Word documents and internally defined flat files. Sorry.
I look forward to working with this group more in the future. |
|
Posted: 8/13/2009 4:56 AM | | |
|
| I have updated the data format (see attached XSD file). In my last mails and posts I sometimes talk about XSL file, that was a mistake, I ment XSD, the schema file. Sorry about that.
I also write a new bigger sample XML file, I hope some somments and questions are answered with these files. |
|