InTech

JAN-FEB 2018

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

Contents of this Issue

Navigation

Page 36 of 53

INTECH JANUARY/FEBRUARY 2018 37 secrets, verify that additional protec- tions are used. Examples include cryp- tographic mechanisms (encryption and digital signatures), system par- titioning architectures, and physical means, such as surveillance cameras, fences, locked rooms and cabinets, and conduits for network cabling. Vital sign #8 Are all users authenticated and autho- rized using credentials (e.g., name and password) that follow best practices? For this vital sign, you are checking if all users are required to log in before they can use the system—no exceptions and no ability to circumvent the access controls. Access to your ICS should be like access to your bank account; ac- cess should be restricted to authorized personnel only. There is often more than one way to log in, so check them all. Desktops and laptops often provide separate logins for the operating system and the con- trol system, and potentially for control system databases. Further, if desktops or laptops are in areas where non-ICS personnel can gain access to them, multifactor authentication is recom- mended, such as using a smart card and personal identification number. In addition, applications with web browser interfaces should also provide a login screen to users when access to the web server application should be restricted and when authentication is not provided to the application by the operating system. Vital sign #9 Once they have gained access, can us- ers access only the resources they need? Are administrator privileges given only to administrators, and are administra - tors restricted from performing control system operations? The primary goal of this vital sign is to see if the concept of "least privilege" is applied to both operating system accounts and control system accounts. Operating system accounts define access privileges to program and data files, and to operating system param- eters and functions. Control system accounts, on the other hand, define ac- cess to control system data and opera- tions, such as who can download a con- troller, who can write run-time values, and who can calibrate a device. Operators and engineers should be given only control system privileges that they need to perform their tasks, which should not include administra- tive privileges. Similarly, control system privileges should not be given to ad- ministrators. Administrative privileges should be given only to administrators. This separation of roles is important to keep operators and engineers from administering the operating system or control system, and keeping admin- istrators from making changes to the process or factory floor. Finally, an advanced application of least privilege is making sure that opera - tors and engineers use operating system logins that do not have administrator privileges. It is not uncommon for op - erator stations to go through an initial operating system login after a reboot, and then have all operators use this operating sys - tem login session when logging into the control system for their shifts. Without operators shar- ing this operating system session, the on-duty op - erator would have to log off, which would terminate all displays. Then the new operator would have to log in and reestab - lish the displays, causing a lack of continuity be - tween the two. You should check to ensure that this initial login is not done by someone with administra- tive privileges, since all opera - tors would then inherit administra- tive privileges during their shifts. This restriction may not be supported by all control systems today, but over time this practice should be discontinued as control systems evolve. Vital sign #10 Is the control system capable of detect- ing security breaches, and are there formal processes for handling breaches and associated security vulnerabilities? Breaches generally occur when protec- tion mechanisms—such as those just discussed—are not present, are over- come, or are circumvented. Detecting breaches is most com- monly done through a combination of manual and automated activities. Many are detected by users who no- tice unusual or suspicious behavior from their workstations or the con- trol system. Others are detected by programs and devices that are constantly monitoring the ICS for threats, such as SPECIAL SECTION Convert Your Mobile Device into a HART Communicator … with our Advanced HART-based Products C O N N E C T > C O N F I G U R E > D O C U M E N T Complete DD-based HART Communicator for any device - PC, Tablet, Phone. Your choice! Complete DD-based HART Communicator for any operating system - Windows, iOS, Android. Your choice! Full line of registered HART Modems - USB, RS232, Bluetooth, Bluetooth Low Energy Your choice! Use your own host device or one of our complete systems. Hazardous area options available. Significant cost savings • Mobile convenience • Satisfaction guaranteed NEW! iOS Version now available!

Articles in this issue

Links on this page

Archives of this issue

view archives of InTech - JAN-FEB 2018