I was waiting for something to inspire the March Monthly Checkup topic and the OPC Server Vulnerability Notes / Patching discussions came through just in time. Here are your check-up tasks for this month:
1) Verify management accepts the risks and approves your patching policy
Your patching process will implicitedly include an acceptance of risk. For example, the window from the time the patch is released and the time the patch is deployed is a period of vulnerability. This could be days, weeks, months or in perpetuity. During this time period management is accepting risk. However, a policy that allows immediate patching without testing or a phased deployment is accepting different risks.
Too often this acceptance of risk is made by System Administrators and other individuals without the authority to accept risk. So this month make sure the appropriate level of management has reviewed, understands and approves the patching process.
What is a patching process? Your mileage may vary, but here is an abbreviated write up of typical process for control systems:
- System Administrators must subscribe to vendor security bulletins for all systems and applications they manage
- Information Security Officers (ISO) must subscribe to US-CERT / CERT bulletins
- When a security bulletin arrives, the System Administrator must determine if the security bulletin applies to the systems they manage
- If the security bulletin applies, the System Administrator and ISO determine if there are any immediate compensating controls that should be applied and run these through the change control process (note: everything goes through change control)
- If the security bulletin applies, the System Administrator determines if the affected vendor has tested and certified the patch will work with system or application
- Deploy the patch in a test environment and verify proper operation
- Deploy the patch on a subset of the affected systems in a manner that won’t cause an outage if the patch causes a problem
- Run the patch for a set period of time (one week?) on the subset of affected systems and verify continued proper operation
- Deploy the patch on remaining systems
- If the patch cannot be deployed due to vendor or asset owner testing, write up an exception and present it to the appropriate management level for approval
- If the patch cannot be deployed in the time period specified in the process, write up an exception and present it to the appropriate management level for approval
Lather – rinse – repeat
2) Do a selective audit of your approved patching process
Identify a couple of security patches that were issued about three months ago and follow them through the approved patching process. Was the appropriate action taken at each step?
If you are running your control system applications on Windows, definitely select an appropriate Microsoft patch. I recommend you also select a non-Microsoft patch. Perhaps an Oracle database patch, Java security patch, ICCP patch, or something else that is applicable to your environment. We have seen many asset owners who, to their credit, have the Microsoft patch process under control, but have ignored vulnerabilities and patches from other application and component vendors.
We typically write a policy audit document concurrently with the information security policy so an audit plan is available, but it is easy enough to audit even without a plan.