Kepware Whitepaper. Leveraging KEPServerEX and Kepware s New Security Policies Plug-In to Meet Your Security Requirements. By Tony Paine.

Transcription

1 Kepware Whitepaper Leveraging KEPServerEX and Kepware s New Security Policies Plug-In to Meet Your Security Requirements By Tony Paine Market Need The ability to securely move information between software applications and hardware appliances is critical to any automated process. To make this possible, an interoperable communications platform must be layered into the control system. Today, both the designers and implementers of these systems are taking a defense-in-depth approach to securing critical infrastructure: they expect that each layer in the control system will provide the functionality and flexibility needed to meet security requirements. An additional layer of security is essential for communications between software and hardware components. It ensures that critical information will not be deciphered by non-authorized applications for malicious use, like hijacking a system or stealing intellectual property. There is also a need to limit the scope of activities that each authorized user is allowed to do and/or access in the system. Systems must be able to provide the information necessary to each stakeholder so that they may perform their responsibilities; however, by appropriately limiting access to information that the stakeholders do not require, administrators can minimize unintentional mistakes that may cause downtime or impact safety. The KEPServerEX Platform Kepware recognizes the importance of security at both the interface and user levels. Although standard interfaces have enabled us to develop secure communications between components, we had not previously developed a solution for role-based security. With KEPServerEX version 5.12 and the introduction of our Security Policies Plug-In, we now provide a complete solution to this market problem.

2 We understand that everyone thinks of security differently. Our new design will not affect the performance of existing applications that choose not to leverage the new functionality. The users that want to apply a more robust security strategy to new or existing applications will find that we have created an intuitive and easily implemented solution for what is often considered to be a complex challenge. We understand that everyone thinks of security differently. Some people want to be able to simply allow or deny access to everything, whereas others require extensive control over the information that is accessible and/or modifiable based on a user s role. Some people prefer a whitelist approach that denies all access except that which is necessary, whereas others prefer a blacklist approach that enables all access except that which is unnecessary. Regardless of preference, certain characteristics of the security strategy are undeniable: it should be implemented with the least amount of impact on performance, able to be modified on-the-fly without requiring a system restart, and provide the tools needed to deploy a tested solution into production. The KEPServerEX platform and Security Policies Plug-In make all this possible. Secure by Default Kepware approaches security based on well-known and adopted security strategies. The KEPServerEX platform provides the developmental flexibility that allows us to layer and adapt existing and future security strategies. Our approach to security in this paper is based on the whitelist model, where we will deny access by default and only allow it where it is absolutely necessary.

3 This approach allows us to focus on two key areas. The first part is identifying the types of client applications that can connect to the server and specifying those that should be authorized to do so. The second part is identifying the user that is running an authorized client and determining what access should be made available based on the user s role. Identifying and Securing Client Application Access KEPServerEX provides a set of services that can be leveraged by a wide range of client KEPServerEX provides a set of services that can be leveraged by a wide range of client applications. These clients can support interfaces like OPC Unified Architecture (UA), classic OPC Data Access (DA), Alarm and Events (AE), Dynamic Data Exchange (DDE), and many more. The level of granularity that can be specified for allowing or denying access to any of these clients depends on the underlying technology. To start, it is helpful to identify the interfaces that are required based on the types of client applications that will be connecting to KEPServerEX. KEPServerEX s Project Properties dialog provides a master switch for allowing administrators to disable each interface that is not utilized, thus preventing an application of that type from being able to connect to the server. Therefore, a simple first step in securing the communications platform is in only turning on the interfaces that will be utilized in the project. applications. By narrowing down the types of client applications that will be utilized and the interfaces they require, administrators can determine which clients of that type should be permitted to connect to the server. For example, just because OPC UA clients are allowed to connect to KEPServerEX does not mean that every OPC UA client should be able to do so. Users can limit the clients that are allowed

4 to connect by creating a trusted relationship that is deployed through security certificates and further restricted by username and password. OPC DA and OPC AE users could utilize the Microsoft Distributed Component Object Model (DCOM) security model that is built into the operating system to accomplish this same task. In some cases, security may be all or nothing (like DDE). OPC UA has the most flexibility in terms of security, OPC UA has the most flexibility in terms of security, and is becoming the de facto standard within our industry for sharing information. KEPServerEX s OPC UA Configuration Manager allows administrators to configure trusted relationships with local or remote UA clients. Administrators can also enforce the type of UA transport that should be used for communications to ensure that the data being exchanged meets security requirements. Furthermore, the OPC UA Configuration Manager allows users to specify which network adapters and ports should be used in order to easily integrate with new or existing firewall constraints. and is becoming the de facto standard within our industry... OPC UA also provides the ability to restrict access to authorized users that are interacting with a trusted client application. Administrators can enforce that trusted clients provide user-level credentials by disabling the Allow anonymous login setting associated with the project. Disabling anonymous access will only allow the users that are defined within KEPServerEX s User Manager interface to have a defined level of authorized access within the system.

5 There are three built-in user groups: Administrators, Anonymous Clients, and Server Users. Securing User Access KEPServerEX s User Manager is used to manage user groups as well as the users they contain. When a security policy is assigned to a group, it will also be applied to the users belonging to that group. There are three built-in user groups: Administrators, Anonymous Clients, and Server Users. User-defined groups can also be created. To ensure that only known users of trusted client applications are accessing the server, administrators can start by denying all access to the Anonymous Clients group. To do so, simply invoke the Anonymous Clients group s User Properties and then deny all read, write, and browse access for the three tag types (I/O Tags, System Tags, and Internal Tags). This will prevent any client application that does not provide the authorized username and password from accessing the server.

6 User groups allow administrators to create specific roles for a group of individuals... The User Manager tab can also be used to provide broad access permissions to particular groups. For more granular control, administrators may want to allow selective read, write, or browse access to all or a set of channels, devices, tag groups, and/or tags in the project. This is achieved through settings located in the Security Policies tab. Users simply select the appropriate objects and then override their access permissions.

7 User groups allow administrators to create specific roles for a group of individuals, such as operators, managers, engineers, or any other group within an organization. By defining authorized users and assigning them to appropriate user groups, administrators can focus on roles rather than individuals. For the most secure solution, administrators should deny access for all permissions at the highest level and only enable access where it is absolutely necessary. For example, a manager must be allowed to monitor the system, but should not be allowed to control it. In this case, the administrator would deny write access to all tag types at the manager s user group level. Access can be given and taken away at any time by the administrator. Conversely, if managers should only be able to write to certain tags, the administrator could first allow write access for the user group and then utilize the Security Policies tab to disable access to specific objects. Alternatively, administrators could deny write access at the root level, and then select the underlying objects where write access is needed.

8 These changes can be made without requiring a restart of the server and a halt in production. Access can be given and taken away at any time by the administrator. Deployment The KEPServerEX project s security policies will only be validated once the project is put into Run Mode. If a security policy references a group that does not exist, all access will be denied in order to protect the system. Details will be provided in the form of an error message to help the system administrator diagnose the problem and remedy the situation. KEPServerEX and the Security Policies Plug-In deliver an easy to If the administrator needs to move the project from one machine to another, the User Group information can be exported as XML from the source machine and re-imported on the target machine. On export, the administrator also has the option to password protect the XML file: if utilized, the password must be entered in order to import successfully on the new machine. Once the import is complete and the project file has been copied from the source machine to the target machine, it will run as expected because the User Group information required by the project s Security Policies is available. use solution... Summary KEPServerEX and the Security Policies Plug-In deliver an easy to use solution that provides the greatest level of flexibility in securing your communications infrastructure. As the market s security needs continue to develop, our Security Policies Plug-In will evolve to meet the demands of tomorrow.