After reading the announcements and hearing the presentation from Wurldtech and Shell at ICSJWG, I was eager to read the WIB document Process Control Domain Security Requirements for Vendors. My understanding going in was this document was going to provide Vendors with security requirement for development process and their control systems, and in the near term Wurldtech, and perhaps others, would certify Vendors as to meeting these requirements.
Let me start off with two positive comments. First, this document is a useful reference document for an owner/operator to use for developing a RFP, much like the MSISAC procurement language project. There are many useful security requirements for a project presented in a structured format with Shalls and Shoulds. Second, the idea of an asset owner or even better a group of asset owners using their procurement power to drive vendors to improve security is great. Vendors are a business and respond to customer demand. Part of the problem is control system owner/operators have not been demanding or even asking for security.
Unfortunately, my expectation from the public announcements, blog entries and presentations did not match reality. I expected that this document to form the basis for certification of a vendor’s security practices related to the development and delivery of a system. Owner/operators could then say we require all Vendors selling to us meet this certification for the Vendor and System. Vendors could get this certification for one or more systems and then use this certification as proof of some level of security practices for all clients and prospects. After reading the document, I don’t see how it could possibly be used for a Vendor or System certification. It could only be used for a specific project certification.
The main problem is the document is littered with requirements that require action by the “Principal”, the documents name for the owner/operator. How can a Vendor be certified to a requirement that requires a Principal action? Here are just a small number of examples.
2.2.3 The Vendor shall ensure that competent personnel are assigned to Principal’s projects. Vendor personnel shall complete training in PCD security measures, as specified by Principal, prior to being authorized access to the Principal’s PCD or PCAD. [Comment: Beyond the vagary of competent personnel, each Project will have different personnel, and each Principal specifies the training.]
2.2.4 Confidentiality agreements and user agreements to follow applicable standards and procedures shall be signed by all persons having access to the Principal’s PCD. [Comment: This is a project requirement]
8.2.1 All users other than operators and service groups shall have individual user names and passwords. Individual passwords shall not be divulged to other persons. [Comment: This is a Project Implementation requirement]
Section 9 Backup, Restore and Disaster Recovery has requirements that meet “the Principal’s backup and recovery plan”
10.6 Modem connections to systems in the PCD shall not be allowed. [Comment: This is a project issue. How can a vendor stop a modem connection to an owner/operator network. This requirement, as many of the others could have been reworded to require something specific of the Vendor.]
11.1 Proprietary protocols shall not be used unless approved by the Principal.
There are many more requirements in the document that would be project specific and impossible to write a vendor certification around without substantially deviating from the document. The certification methodology would need to be creative and try to find ways to meet the spirit of each requirement while not involving the Principal. This is possible, but it would be a stretch to say a Vendor was certified to this document, and information on the accreditation of certification bodies and the certification itself is not available.
A second oddity of this document is it actually mentions, and in some cases mandates, specific security solutions. Take anti-virus as an example. 4.1 requires anti-virus on all products, which can be considered good although this may soon change. Perhaps protection from malware would be better. Later, 4.6 states McAfee and Symantec are preferred, this is quite odd for a standard. The section on patch management mandates the use of WSUS “where possible”. There is a list of approved remote access vendor solutions in Appendix 3. And in a few places requires testing from “reputable third party, e.g. TUV, Exida, or Wurldtech”. Very odd for this type of document.
As mentioned earlier, the document has value as input for a RFP. In fact it reads like it was an RFP that was enhanced and massaged. Some sections are quite strong, such as the Patch Management section with well written requirements for patch identification, testing, deployment, support and more. Another quality example is “2.2.7 The Vendor shall have a policy and procedures for security testing, approval and maintenance of third party software installed on the Vendor’s system.”
You can imagine that with our passion for Bandolier, I took a close read of Section 6 System Hardening. This section was missing some basics such as requiring a list of the security parameters, default settings and recommended settings. It also lacked a requirement for a list of the minimal required ports and services. These are items we add to all RFP’s, are increasing being required in standards and regulations, and are necessary for firewall configurations.
In summary, I don’t see how this document can be used for a Vendor certification. It is useful RFP guidance, but even with that requires some significant review and editing in my opinion. I started to write down comments, but they were filling pages. Read it yourself, and let me know what you think. You can request a copy from the WIB web site, and to their credit I had it in thirty minutes.
Then there are the more process and political question of why WIB? Why such an odd process? Who actually wrote and reviewed the standard? Why not ISCI? … These questions would probably be moot if there was a stellar result that met the expectations set by the document’s proponents. But that is a different blog post.