In response to Executive Order (EO) 13636, NIST released version 1 of "Framework for Improving Critical Infrastructure Cybersecurity" in February 2014. It says the EO defines critical infrastructure as "systems and assets, whether physical or virtual, so vital to the United States that the incapacity or destruction of such systems and assets would have a debilitating impact on security, national economic security, national public health or safety, or any combination of those matters," which is certainly potentially a broad swath of industry. Critical infrastructure is commonly assumed to be utilities, emergency responders and similar, but it could and perhaps should include all forms of manufacturing, or at least those related to the energy industry and other hazardous goods.
The EO's Framework model works somewhat like most risk management tools, developing a grid of functions (Core) versus compliance (Tiers) to determine your level of risk and compliance. A number of tools are available to assist with performing the analysis, and Table 2 in Appendix A includes a wide range of references for each of the identified functions and subcategories.
What, you may ask, does all this have to do with wireless?
Many organizations treat wireless differently than wired infrastructure, in many cases going so far as connecting the wireless networks to the control system via the DMZ. This, of course, adds more delay to the signal transit time, while also providing another opportunity to make an error in the configuration. This is despite the fact, as we've discussed in the past, that the field sensor network protocols at least contain inherent security features more rigorous than the consumer products, such as cell phones and tablets that we’re starting to use for remote monitoring (and I am confident, in some cases, control).
Additionally, much of the critical infrastructure relies on SCADA to connect widely dispersed units such as pump stations, transformer stations, etc., which, because of the distance, uses a wireless backhaul based on protocols such as DNP3 or IEC 61850. Of course, many of the SCADA systems, certainly legacy and large installations, likely use licensed spectrum, which helps with reliability. But as the saying goes, "bits are bits." So if they're being routed via standard protocols and in particular as IP packets, the security risk increases at the ends of the connection because of the same vulnerabilities as for any IP-based protocol.
Despite the importance of SCADA to infrastructure and the fact that the majority of these systems are migrating to IP-based networks, there is a surprising lack of standards to assist with and provide best practices for the design, installation and maintenance of these systems. In response to government requests to pipeline operators, the American Petroleum Institute (API) has developed a small set of standards that begin to address some of the unique requirements related to pipeline SCADA systems. I also understand that these documents will soon be up for review.
I’m also working with some folks at ISA to investigate the need for a complementary set of SCADA-related standards and/or technical reports to improve the integrity of all forms of SCADA systems with particular focus and consideration on the "gaps" not covered by existing documents that address protocol, physical layer, etc. ISA will be issuing a survey document in early February that will also be posted on the ISA website for approximately one month to confirm sufficient interest (i.e. volunteers), minimal conflict with existing documents (such as API), and, of course, input on scope and purpose.
For those readers interested in participating in the new ISA SCADA standard, please contact me. If any of you are interested in commenting on the Framework document that's been in use for almost two years, NIST is soliciting input through a Request for Information (RFI). It's open to public comment until Feb. 9.
Even though much of the process industry is exempt from the Executive Order and associated Framework document, like many things, best practices should be industry-independent. So, there are a number of useful references and tools available courtesy of U.S. taxpayers to improve the overall integrity of our SCADA and control systems. In this case, "I’m from the government and I’m here to help you" is true, provided you make the effort to determine which parts of the tools provided add value versus unnecessary documentation.