Posts Tagged ‘multiplatform’
Monday, October 25, 2010 @ 04:10 PM gHale
By Paul Hunkar
When Tom Burke walks to the podium to give a talk at a conference or even when he first gets on the telephone for an interview, some of the words that usually spill out within the first few sentences are OPC UA and security.
“The vision of OPC is to provide the best specifications, technology, certification and process in support of our suppliers developing best-of-breed products and services that consistently exceed the expectations of the end-users for multivendor multiplatform secure reliable interoperability,” says Burke, the executive director and president of the OPC Foundation in describing the OPC Unified Architecture (UA). “OPC UA was designed to meet the industry requirements of cross-platform, scalable, and enterprise-level data modeling. The OPC Foundation’s UA standard provides the next generation architecture for truly secure interoperability.”
This standard allows developers and users to move away from COM in favor of cross-platform capable Web Services and SOA (Service Oriented Architecture). OPC UA also opens up OPC to non-Microsoft platforms, unifies the OPC data models (DA, A&E, HDA) into a single set of services and it allows for information model extensions to extend OPC beyond its typical markets into the enterprise and down to the devices. All of these features further enhance the requirements related to security.[private]
In a world where open and interoperable are more than just buzzwords, they are reality, the OPC UA specification thought about security from the outset. With the set of specifications that comprise OPC UA, OPC wanted to solve the fundamental problem of moving data and information across corporate firewalls. This set of specifications also works toward solving the existing problem of the spaghetti nightmare of hundreds of millions of interfaces currently required for inter enterprise communication. This communication includes the communication at the Device Integration level (FF, Profibus, HART, etc), subsystem Integration, enterprise integration (ERP, asset management, advanced diagnostics, etc.). OPC UA works between components in the operation of an industrial facility at multiple levels: From high-level enterprise management to low-level direct process control of a device. OPC UA for enterprise management involves dealings with customers and suppliers. The information exchanged includes typical high speed data exchange, event information, historical data and custom information. The information can contain proprietary information or it may be public information. Administrators, engineers and operators with a variety of privileges may be using the systems. The security concepts incorporated into OPC UA have to be adaptable enough to work over this wide range of levels and features.
When discussing OPC UA security, the first steps would be to identify some of the common security issues that face various applications. OPC UA addresses the common threats that face today’s plant/industrial environments. These threats include message flooding, message alteration, rogue servers, eavesdropping and Denial of Service Attacks (DOS) to just mention a few.
Security threats facing users on a daily basis.
At the enterprise management level OPC UA may be an attractive target for industrial espionage or sabotage and may also face threats through untargeted malware, such as worms, circulating on public networks. Disruption of communications at the process control level could cost the manufacturer thousands if not millions of dollars not to mention consequences to employee, public safety or environmental damage. This could be an attractive target for those who seek to harm the enterprise or society.
OPC UA will go to work in a diverse range of operating environments, with varying assumptions about threats and accessibility, and with a variety of security policies and enforcement regimes. OPC UA, therefore, provides a flexible set of security mechanisms. These mechanisms make use of industry standards whenever possible.
Some OPC UA clients and servers are on the same host and are easier to protect from external attack. Some clients and servers are on different hosts in the same operations network and might undergo protection from the security boundary shields that separate the operations network from external connections. Some OPC UA applications run in relatively open environments where users and applications might be difficult to control. Meanwhile, other applications embed into control systems that have no direct electronic connection to external systems.
Fundamentally, information system security reduces the risk of damage from attacks. It does this by identifying the threats to the system, identifying the system’s vulnerabilities to these threats, and providing countermeasures. The countermeasures reduce vulnerabilities directly, counteract threats, or recover from successful attacks. The user ends up achieving system security by meeting a set of objectives. These objectives have been refined through years of experience in providing security for information systems in general and they remain quite constant despite the ever-changing set of threats to systems.
OPC UA security works within the overall Cyber Security Management System (CSMS) of a site. Sites often have a CSMS that addresses security policy and procedures, personnel, responsibilities, audits, and physical security. A CSMS addresses threats; they also analyze the security risks and determine what security controls the site needs. Resulting security controls commonly implement a “defense-in-depth” strategy that provides multiple layers of protection and recognizes that no single layer can protect against all attacks. Boundary protections may include firewalls, intrusion detection and prevention systems, controls on dial-in connections, and controls on media and computers that come into the system. Protections in components of the system may include hardened configuration of the operating systems, security patch management, anti-virus programs, and not allowing email in the control network.
The security requirements of a site CSMS apply to its OPC UA interfaces. That is, the security requirements of OPC UA interfaces deployed at a site are site-specific, not by the OPC UA specification. OPC UA specifies features so conformant client and server products can meet the security requirements expected at sites where they will undergo deployment. Those who are responsible for the security at the site should determine how to meet the site requirements with OPC UA conformant products.
OPC UA security features
OPC includes support for transport security, application security, user level security and traceability. This multilevel approach is not tied to any single security mechanism and it can easily undergo configuration as required at in installation site.
When constructing the OPC UA specification the working committee realized it should not invent anything with regard to security, it also realized it would be best to have security experts assist with the design and implementation of OPC UA security. This resulted in a specification that makes use of industry standard security process and a specification and code that has been review by independent security experts.
At the transport level OPC UA supports multiple transports and it is easy to expand the list of transports. They include a HTTP/soap transport with XML and a TCP/IP transport. For the HTTP transport, the Industry standard WS-* specifications were used for security, in particular the WS Secure Conversation specification.
Transports and security.
For the TCP/IP transport no readily excepted security standard existed, thus the WS Secure Conversation specification was adapted to TCP/IP. the WS-* specifications ensure the communication between a client and server is secure. They provide for encrypted communication using standard PKI based security. The actual security algorithms are defined as part of a security profile. It is expected that new security profiles will be created as new security algorithms are introduced and other security profiles will become obsolete with time. The use of profiles allows for future enhancement to the algorithms without having to change any other part of an application. These algorithms include algorithms for message authentication such as SHA256, signatures and handshaking such as RSA-SHA1, symmetric message encryption such as AES-128, for asymmetric encryption such as RSA-OAEP, for Session key generation such as P-SHA1 and the use of X.509 certificates for authentication (both application and user). The WS-* standards always allow some variation on choices of algorithms and methods used.
Additional security algorithms.
OPC UA defined a fixed set of choices to ensure applications that support the same profile will interoperate with ease. Part of these selections also include ensuring peak performance. For example Asymmetric encryption and Symmetric encryption vary greatly in performance, so the former is used to exchange the required information to enable a session and allow the utilization of the faster encryption for the duration of the session.
When deploying OPC UA application in a plant environment, it is essential from a security point of view to ensure only applications that you want to deploy in the given environment end up deployed. OPC UA uses certificates to allow applications that intend to communicate to identify each other. Each OPC UA Application Instance has a Digital Certificate (Application Instance Certificate) assigned that are exchanged during Secure Channel establishment. The receiver of the Certificate checks whether it trusts the received certificate and based on this check it accepts or rejects the connection form the sender. OPC UA supports the standard Certificate Model that is common in all desktops and heavily used by web browsers for security.
The UA Certificate Model defines three principal actors: the Application Instance certificate, the Application Administrator and the Certificate Authority.
The Application Instance Certificate is an electronic id card. The card includes information that identifies the holder, the issuer and a unique key used to create and verify digital signatures. The syntax of these certificates conforms to the X509 specification, as a result, these certificates are also known as “X509 Certificates”. The Application Instance Certificate is either self signed or signed by a Certificate Authority (CA).
A Certificate Authority (CA) is an administrator or organization responsible for creating Certificates. The Certificate Authority must verify information placed in the Certificate is correct and add a digital signature to the Certificate used to verify the information has not been changed. Each CA must have its own Certificate with which it creates the digital signatures.
An Administrator is a person that configures each applications list of trusted certificates or trusted CA’s. The administrator may also configure other aspects of an OPC UA Application, such as transport protocols. The concept of an administrator, either Domain or System administrator, is a standard concept in all security systems and OPC UA does not vary from it.
The Application Instance Certificates secret keys are used by the application to create secure communication channels in addition to identifying peers and blocking communication from a peer if it is not authorized.
Since not all sites require the same level of security, OPC UA allows for the application to select various tiers of application level security. These security tiers include “No Authentication,” “Server Authentication,” “Client Authentication” and “Mutual Authentication.”
“No Authentication” allows any client and servers with valid certificates to communicate. In this mode the client and server automatically accept valid certificates even if they have not been explicitly added to the trust lists managed by the client and server applications. This mode cannot ensure the privacy of any information transmitted, including user credentials. This mode would only be appropriate in a system that has guaranteed security in some other manner, such as a physically secured and isolated system or where communications is secured via VPN or other such transport layer security. It would also be appropriate in a situation where all information is public and access to it is open.
With “Server Authentication,” the server allows any client to connect. Clients, on the other hand, must undergo configuration by the administrator to trust the server. This mode is similar to Internet banking applications where the bank’s web server has a certificate issued by Certificate Authorities like Verisign that are automatically placed in the browsers trust list by the Windows operating system. It provides fairly good security but the server cannot restrict the client applications.
In “Client Authentication,” the server only allows trusted clients to connect, but clients will connect to any server. Discovery services use this mode when they need to ensure that only authorized applications have access to them but clients don’t care if the server is legitimate.
“Mutual Authentication” is when the client and server only allow trusted peers to connect. It offers the highest level of security but requires client and server configuration in advance. This is the recommended mode for any public or semi-public deployment of OPC UA or for deployments where security is a primary concern. This is the default security mode for OPC UA.
OPC UA user security includes authentication and authorization support. As part of session establishment OPC UA includes establishing the identity and authenticating the client. The client identification includes support for industry standard methods such as Kerberos, X.509 certificates and username/password. The identity of a user can change without affecting the other activities such as subscriptions that may be active. The identity switch can occur via the Activate Session service. This user identity switch performs the same user authorization performed as part of the initial session establishment.
The user identification that results from the Active Session remains stored as part of the session and can be used for other actions including authorization of user access or tracing user activities. To provide a standard method of displaying User Authorization OPC UA includes attributes for Access Level and User Access Level. The Access Level provides information as to the type of access allowed on a given object or variable in the OPC UA address space. The User Access Level further refines this to indicate the access level the currently connected user has. The actual implementation of how these attributes populate is server specific, but the standardized attribute allows all clients to access the information in a generic manner.
OPC UA supports traceability, via defined auditing. Auditing is a feature of OPC that generated OPC UA defined audit messages for user actions. These actions include session establishment and user verification. They also include any operator actions that would change the state of a control system, such as writes or method activations. They also include security related errors or warnings. These standard audit events can be received from a server by any authorized OPC UA client via the standard OPC UA subscription services. The server may also log them to typical event logging systems. The support for event based audit records allows any authorized client to act as a security event logger.
Security in mind
The OPC UA specification makes use of industry standard security procedures and algorithms, you can configure it as required to support a site specific security plan and it supports all standard security features including application authentication, user authentication, encryption and auditing. OPC designed the standard to include the probable obsolescence of security algorithms. Under the tutelage of security experts throughout the industry, it makes use of existing technology and practices.
Behind the byline
Paul Hunkar is executive director and owner of DS Interoperability LLC, a training and consulting service provider. He is a key contributor and presenter at OPC conferences and involved in OPC classic and OPC UA standards. You can email him at TechnicalDirector@dsinteroperability.com.[/private]