SCADA vendors place their money and effort developing features that are demanded by potential clients in RFP’s. At least that is the thought behind the effort by the Multi-State ISAC / SANS / INL funded by DHS NCSD to develop cyber security procurment language for control systems. Draft 1.5 is out this month, and we gave it a thorough read and review.

If you are developing a RFI or RFP, this is a useful document. So the authors and organizations have met their goal. In fact, you will see this effort in our 2006 Top Ten list in December. lf you are a loyal blog reader I’m sure you know we have a few comments and suggestions. 

Comments

• Pre-Award vs. Post-Award - Many of the sections require the vendor to provide information Post-Award that is essential for determining who should be awarded the contract. Look at Section 2.1 System Hardening as an example. ”The vendor shall provide documentation detailing all applications utilities, system services, scripts, configuration files, databases, and all other software required and their appropriate configurations …”. If one vendor requires large number of ports/services, applications with a poor vulnerability history, weak configurations, etc. I want to consider that in the scoring pre-award rather than learn about it after I own the problem. Section 2 is only one example of this pre-award / post-award problem. The firewall ruleset in Section 3.1 is another potentially huge post-award problem. Consider changing post-award to pre-award when using the suggested language throughout the document.
• Missing Requirement Levels - All requirement sections are at the same level when clearly some are absolutely critical and others might be nice to have but not necessary. For example, Section 3.3 Canaries (honeypots), NIDS anomaly detection, or Section 4.6 Single Sign On may not be critical for all control systems. NERC’s CSSWG has a nice way of dealing with this separating requirements into Foundational, Intermediate and Advanced categories. You will need to apply the requirement levels yourself without this guidance.
• Low Bar on Scanning - The document appears to find it acceptable that simple scanning will crash a control system device. From 2.1.3, “Note the port scans can rarely be used on production systems. In most cases they will disrupt operations.” Shouldn’t asset owners be purchasing systems that are robust enough to handle scans in the “Safe” category such as simple port scans and “Safe” Nessus plugins? If we expect a web server or email server to exhibit this robustness why not an OPC server, historian or realtime SCADA server. If you are purchasing a new SCADA device or system make sure it will withstand a scan on an active system for many reasons we will detail in a white paper this week.
• Patching  - Section 2.6 covered patching after delivery and was not very specific and a bit weak. Given the criticality of the patch issue this section should be strong and detailed. “The purchaser shall negotiate a patch management process with the vendor to include policies and procedures for the system after installation.” As I said a bit weak, and this negotiation is recommended Post-Award. You should have your patch support requirements in the RFP and responses considered as a key component in the award.
• OS Support - The community has struggled with the loss of Microsoft support for NT and 2000, with other OS to follow. You should insure your procurement contract requires the vendor to have a version of the software running on a supported OS. If they balk at this or the time period is too short, consider software escrow so you have the option of having someone else modify the product for the new OS. You should never run a control system on an unsupported OS.
• Secure Design - Section 5 Coding Practices needs a bit of work. One important area that is completely ignored is the vendor’s Quality Assurance (QA) program. Coding standards are great to have, but QA will tell you if they have actually been implemented. The QA program, test plans and test results are often the best place for a potential customer to look to determine if the development process is under control.

Less Critical Comments

• Section 2.5 Heartbeat Signals should be removed. This information will be provided in Section 2.1. It is simply another application / service that needs full documentation. 
• Section 2.3 Changes to File System and OS Permission would be better integrated into the Section 3 Account Management sections. In fact, most of the Section 2.3 requirements are already covered there in more detail. 
• The initial section on Security Objectives does not belong in this document. This probably flies in the face of some other comments because it was added in this version. One of the problems we see in many standards and community efforts is lack of focus, and the perceived need to develop an all encompassing document. For instance, you see this in AGA 12 Annexes and API Appendices as well. 
• Section 3.2 NIDS and Section 3.3 Canaries are not perimeter protection.  If this is a forward looking document, why is there nothing on IPS? In terms of technical acceptability for SCADA systems it is on a par with HIDS today - - generally not recommended. Although we have had some clients use selected HIPS signatures on a perimeter security device as a compensating control for a system that could not be patched.
• The definition for Role Based Access Control (RBAC) in Section 4.5 is poor.  Roles are created and assigned privileges. Then Users are added to the appropriate roles. It makes it much easier to assign and manage consistent and appropriate authorization rights. Also, the document states “RBAC” is not common on legacy systems”.  This is not our experience, but in any event RBAC should be a prioirty in your new system.