By Eric Murphy, Advanced Architecture System Design Engineer, MatrikonOPC
Security is once again on top of everyones mind. Incidents such as the Heathrow plot renew focus on the possible vulnerabilities of critical infrastructure, such as those in the power, oil and gas, manufacturing and other industries. One key area of concern deals with SCADA infrastructures using communication protocols such as OPC. The question being raised to these industries is, Are we doing everything possible to ensure the security of industrial process control systems? According to several security analysts and government reviews, the answer today for many installations would be, Far from it.
Historically these sorts of systems have been isolated from the outside world, or used specialized or proprietary interfaces so security was not a key design issue. However with increased demand for efficiency, system integration and globalization, more and more of these systems are using open protocols and have connections to the business world. For years the security risk matrix for SCADA communications, including OPC, focused on the probability of attack not the possibility. The reality of today is that many threats are becoming increasingly more probable.
Since OPC is used extensively in the control industry, and allows open access to a myriad of proprietary protocols, it becomes a natural focus for security concerns. As with many interface standards or protocols developed for the process industry, the OPC specifications do not mandate security. Rather they rely on operating system (OS) based security such as Windows and DCOM security, which is no longer considered sufficient.
Although a companion OPC security specification which offers an increased security option does exist, it has had limited adoption in the marketplace. One of the main reasons additional measures are not implemented is SCADA systems are typically designed for performance and reliability, where response time is often a critical factor. This criteria needs to be balanced against adding security features such as cryptography or additional authentication that may adversely impact performance.
Securing these vast and varied OPC installations is no simple task. It is hampered by the ever present question of what is considered secure enough? On one side is the government and corporate management levels who shoulder the responsibility of not allowing anything to happen. On the other, operations and financial levels fear that mandated security will be so restrictive it impedes the very process it is protecting.
Regardless of where someone sits in an organization, or their opinion on how much security is too much of a good thing; the one point most people agree on is the process control industry as a whole needs to address the security issue. The good news is that people are working on it.
There are several open, collaborative groups such as the Process Control Systems Forum (PCSF) and Process Control Security Requirements Forum (PCSRF) working at improving the IT security of process control systems. They have representation from end users, vendors, system integrators, and industry, government, and academia. In addition, there are several SCADA security standards being driven by the oil and gas, electric, manufacturing and other industry groups. Groups like these know it is possible to create secure systems that are also reliable and performant. For many end users of control systems, safety is paramount and is an integral consideration in system design and operation. The same sort of thinking can be applied to security.
As foreboding as the current state of affairs sounds, it does not mean that all OPC installations are insecure. End users that are security aware are using a combination of IT network security practices, proper OPC architecture and OPC products that incorporate security features to successfully create robust systems. An experienced vendor, working closely with the end user, incorporating network assessments and security evaluations, can produce a secure OPC architecture. However, not enough installations have followed such a rigorous process.
A common problem companys face is that although several draft specifications exist, no one industry organization can guarantee that following a set of guide lines or requirements provides complete security. There is wide variability among vendor and system integrators IT security experience, and there is a lack of in-depth knowledge and understanding between many control engineers and the IT security professionals. The end result is the need for due diligence on the part of the end user in understanding their OPC security requirements.
If it is not possible or practical for a company to be part of the various organizations that are addressing security in OPC and the process industry, then they should ensure their vendor or system integrator is. Important aspects to consider are:
- Experience with OPC and implementing secure OPC architectures
- OPC Products that incorporate security features
- Support of the OPC UA specifications
- Active membership in SCADA security organizations
As the various industries focused specifications become finalized and adopted, and secure implementations continue to grow, SCADA security best practices are beginning to solidify. In addition, the recently released OPC UA specification has security as a main component. This will make it easier for those who are responsible for site security to determine how best to meet their particular requirements with OPC UA conformant products.
Although the need for the end user to be involved in the process will never go away, steps are being taken to lessen the time commitment of this requirement. In the meantime, end users will need to continue being an integral part of the solution and be confident in those they choose to secure their OPC communications.
Eric Murphy, BSc, PEng (Alberta), is a chemical engineer with a process control specialization and an OPC expert. Eric has been a part of the OPC community since its early beginnings in the mid-1990s. He is heavily involved with the OPC Foundation and currently acts as the chair for the OPC Historical Data Access (HDA) working group. Eric is also a member of the OPC Technical Steering Committee (TSC) and an active member of the OPC Unified Architecture (UA) working group. Visit Eric at his Blog theOPC Exchangeto follow the latest trends and discussions about OPC technology, orclick here for free downloads.