InTech

MAY-JUN 2017

Issue link: http://intechdigitalxp.isa.org/i/833037

Contents of this Issue

Navigation

Page 29 of 53

30 INTECH MAY/JUNE 2017 WWW.ISA.ORG AUTOMATION IT controls should be used to allow configu- ration by authorized network administra- tors and review of the configuration by authorized maintenance personnel. Communication paths that are not authorized by the configuration should be rejected and logged, or at least logged if rejection is not practical. When possible, configure intrusion detection capabilities of perimeter security devic - es to inspect for known attacks and sus- picious traffic. Additionally, traffic flows to and from an ICS are predictable, and deviations often are indicative of an at tack. Therefore, traffic flows should also be inspected for potential attacks. Lack of an industrial perimeter security device or deficient configurations can allow unauthorized communications to enter and leave the ICS. Perimeter security devices should be connected externally only to DMZs that reside between perimeter security devices and plant networks, as shown in figure 2. DMZs are buffers that protect ICSs from being directly accessed by exter - nal systems. Perimeter security devices should be configured to allow only DMZ devices to communicate with the ICS workstation networks. All external devic - es, including wireless workstations (e.g., laptops), should have their communi - cations with the ICS mediated by the DMZ by terminating them in the DMZ, validating them, and then reestablishing them between the DMZ and the ICS. In addition, remote desktop access to the ICS should require a pair of re - mote access connections, one from the remote device to the DMZ, and the other from the DMZ to the ICS that is mediated by an ICS perimeter security device. If the remote device is external to the plant, a VPN connection to the plant network should also be used. The perimeter security device should be configured for each remote access connection, and also specify when and for how long remote access is allowed. Finally, the ability to configure and maintain perimeter security must be con- trolled and must be performed only from authorized HMIs within the ICS. External HMI access to perimeter security devices should not be allowed. All configuration Microsoft Windows domain). Further, trusts should be prohibited between ICS domains and non-ICS domains, includ- ing those used for demilitarized zones (DMZs). Trusts between domains gen- erally allow users logged into one do- main to access a second domain with- out supplying credentials for the second domain. Plant system users who need to access the ICS should be given their own ICS OS account. All other plant system users should not have access to the ICS. Perimeter security devices Perimeter security devices are network security devices used to segment ICS networks from external networks. Perimeter security devices include firewalls and routers (e.g., those with access control lists), and mediate com - munications between external devices and the ICS. They can be used to gain entry to the ICS by discovering and exploiting weaknesses in rules that forward au- thorized messages to the ICS and block unauthorized messages. Entry is also possible if the attacker is able to gain configuration access to a perimeter se curity device and change its rule. Defensive measures: Perimeter secu- rity devices designed specifically for industrial applications should be used to protect the ICS from external access. Network security devices designed for industrial networks provide visibility and defense against ICS-related proto- cols and traffic, which are significantly different from traditional IT traffic. Perimeter security devices should be physically protected from tampering and from having unauthorized devices connected to them. This is often done by placing them in locked closets or locked cabinets and using conduit to protect network cabling. Perimeter security devices should be configured to allow only communica- tions with devices that are essential to the operation of the ICS. This configuration should explicitly authorize or whitelist inbound and outbound communication paths in terms of their source and destina- tion network addresses, application end points (e.g., TCP/UDP port), protocols, and allowed content. Role-based access installed software, changing system set- tings, or otherwise manipulating pro- tected OS resources. It is also highly recommended that the built-in OS administrator account be removed or renamed if removal is not possible. Instead of using this built- in account, administrators should be given unique user names without any indication of their administrator sta- tus and be assigned to administrator groups. This will make it more difficult for attackers to target well-known ad- ministrator accounts. When selecting user-authentication mechanisms, it is important to pro- vide authentication for all logins. Guest and anonymous logins and user logins to service accounts for server appli- cations should not be allowed. When passwords are used, password poli- cies should be configured for adequate password length and complexity, pe riodic password changes, and rules against password reuse. Multifactor authentication, such as smart cards and a PIN, should be used for all HMIs that are in open areas or that can connect from a remote loca- tion. For remote access, a secure chan- nel, such as a virtual private network, and an intervening perimeter security device (e.g., firewall) should be used. Mutual authentication should be used for website and server application logins. Mutual authentication requires websites and servers to additionally provide their identity to the user to pro- tect the user from giving login creden- tials to an attacker pretending to be the desired website or server. Kerberos is used in Microsoft Windows environ- ments for mutual authentication, while websites often rely on public key infra- structure (PKI) technology. Note that although PKI supports the use of self- signed certificates, their use is discour- aged because their authenticity cannot be easily verified. Finally, ICS OS accounts should be defined and managed independently from other OS accounts, such as plant IT accounts. This is typically accom- plished by the ICS having its own user account directory, which is more com- monly referred to as a domain (after the

Articles in this issue

Links on this page

Archives of this issue

view archives of InTech - MAY-JUN 2017