Back in April we reviewed Version 1 of the WIB/Wurldtech/Shell Process Control Domain – Security Requirements for Vendors. While it was a useful guideline document, it had major problems that needed to be solved before it could be used for a vendor certification program as planned by WIB. This month WIB issued Version 2 of the document.
In this blog entry we will analyze the document changes in Version 2, and then try to dig into the certification program in future blog entries. If you don’t want to read this lengthy post, the short answer is Version 2 is dramatically better and addressed a lot of the flaws identified in Version 1.
First, Version 2 is longer. 52 pages as compared to 33 in the first document. There is more structure to the document with 35 Process Areas grouped in four categories: Organizational, System Capability, System Acceptance Testing and Commissioning, and Maintenance and Support. Each Process Area then has multiple Base Practices. For example, PA07: Secure Account Management has eight base practices including Multiple Default Passwords, Removable Default Accounts, Minimum Password Strength, Password Lifetimes and Reuse Restrictions, Persistence of Special Accounts, Role-based Access for Network Devices, Unified Account Management, and Maintain Account Logs. The organization, structure and presentation of Version 2 is a definite improvement. There is also better and more complete content for the requirements.
Version 2 also introduces the concept of certification to bronze, silver and gold levels – like the medals. Each base practices is designated at one of those three levels. Ambitious, but helpful if they can pull off a three level certification.
Certification Issues
My main criticism of Version 1 is that there were Principal-specific requirements so it would be impossible for a Vendor to be certified as meeting Version 1. (Remember that a “Principal” in the document is the SCADA or DCS owner/operator – – the Vendor’s customer.) The majority of the Principal-specific requirements have been removed, and certainly the most egregious are gone. A few problems remain such as:
BP.07.04 Password lifetimes and reuse restrictions RE(2) The Vendor’s system shall log and report unsuccessful login attempts in a timely manner to an interface specified by the Principal. … RE(3) The Vendor’s system shall restrict use of shared passwords except for shared passwords approved by the Principal.
How will the certification organization know a future Principal’s specified interface or if a Principal will approve a specific shared password?
BP.07.06 Role-based access for network devices RE(4) Where required, the Vendor’s system shall provide the capability to enforce two-way authentication of all network traffic.
How will a certification organization know where two-way authentication is required?
BP.12.01 Approved standards RE(1) The use of proprietary and non-standard protocols shall not be used unless approved by the Principal.
This exception can’t be tested for a vendor certification.
There were more problems like this, but again much fewer and less serious. With a little change in text or creativity in certification procedures they can be dealt with.
A more common issue throughout the document are requirements that can’t be proven except on a project basis. My guess is that certification to these requirements will be based on whether a vendor has a policy requiring these actions, and perhaps providing some audit evidence that the policy has been followed in the past. Just a few examples:
BP.01.05: Competent personnel The Vendor shall ensure that competent security leads are assigned to the Principal’s projects.
BP.01.06: Confidentiality and user agreements Confidentiality and user agreements (following applicable standards and procedures) shall be signed by any persons having access to the Principal’s ASD.
BP.05.03 Virus-free equipment The Vendor shall provide evidence that all equipment has been checked to be free of malicious code prior to shipment to the Principal.
BP.06.04 Prompt patch notification The Vendor shall inform the Principal about approved, not approved and not relevant software patches within 30 days after release by the manufacturer of the software.
Better Content
I probably should write a whole post on the much improved requirements, but maybe you should just read them. The PA:04 Harden the system requirements have addressed this deficiency in Version 1. PA:13 Fortify SIS Connectivity is unique. I don’t remember seeing such detailed requirements for connecting Safety and Control Systems anywhere else.
Vendor specific solutions
Vendor specific solutions are still in Version 2, and I have to wonder why? The worst:
2.2 To demonstrate compliance of the equipment, systems and services, [Supplier/Seller/Contractor] shall provide to [Purchaser/Buyer/Company], on acceptance of order at no cost to [Purchaser/Buyer/ Company], a Wurldtech Achilles Practices Certificate (APC), level is required, is prefered (sp).
Wow. This is in the Procurement Language section. Why would you not have [WIB Approved Testing Organization] rather than Wurldtech Achilles Practice? What are the 3rd Party testing requirements? Is Wurldtech the only testing body? They are a fine company to do the testing, and have contributed mightily to the document, but why would they be specified in this document. [FD: Wurldtech is a past Digital Bond client]
Other examples:
- An accepted vendor / product list of remote access solutions in BP.14.01
- BP.05.01: Support anti-virus software The Vendor’s system shall support use of anti-virus software. Note 1: Symantec or McAfee anti-virus solutions are preferred.
- BP.06.03 … preferably compatible with Microsoft Windows Software Update Service
These company specific references are just unnecessary and inappropriate for the way that WIB is positioning the document.
Up Next: Certification