Checking cybersecurity vital signs

• By Lee Neitzel
• Special Section

Summary

Industrial control system cybersecurity

By Lee Neitzel

How secure is your industrial control system (ICS)? Conventional wisdom says a comprehensive security assessment is required to answer this question. A detailed assessment may be overkill if you are just trying to get a first look at where you are on cybersecurity. Although a security assessment is a valuable tool, it is most often used for an in-depth look at threats, vulnerabilities, losses, and potential countermeasures.

So, what if you only want a checkup, not a full physical? There are 10 vital signs for self-checking your ICS-representing security capabilities that address common ICS threats, such as network attacks, connection of unauthorized devices, malware, and threats from inside the organization.

This self-check is like a checkup you get from your doctor, with the exception that there are no empirical measurements, like temperature or blood pressure, for an ICS. Because of this, and because this self-check is for your own use, scoring is left to you. Each vital sign is presented as a question (in no particular order). You can simply answer with "yes" or "no," but most answers will be a matter of degree, so scaling your answer (e.g., 0 to 10) may be more useful. Use what is practical for you, because it is not the actual score that is important; it is the insights you gain when answering the questions. Once complete, you should have a good feel for the strengths and weaknesses of your ICS cybersecurity readiness.

Vital sign #1

Is cybersecurity ingrained into your organization's culture and day-to-day operations? The answer to this question can be found in the work practices and behavior of personnel involved in the operation of the ICS, from management to operators. Are they security aware? Is the organization committed to keeping the ICS secure? Has it provided training and guidance for security best practices? Are there disciplinary measures for failing to observe them? And, for the more security-conscious, does the organization have security-certified personnel?

This vital sign should be easy to assess. Just look around. The way USB memory sticks are handled is a good place to start. Are there rules, formal practices, or polices defined for their use? Does ignoring or violating them go against the culture of the organization?

Vital sign #2

Do you maintain an inventory of all hardware and software in the ICS, and do you follow a formal process for controlling changes to them? For this vital sign, look for documentation that describes hardware and software components, when they were installed, and what changes have been made to them, including who approved the changes and who made them. It is important that all components and their change histories are documented. This vital sign makes it easy to determine if a device and its software are authorized, and if their updates (patches and upgrades) are current.

Vital sign #3

Are only necessary inbound and outbound communications between your ICS and other plant systems allowed? Unnecessary traffic has the potential to flood the network, attack internal ICS software, and otherwise disrupt operations of the ICS. Here, you are trying to identify all connections of the ICS to the plant network and beyond, and then determine if each is protected by a properly configured network security device. Typical network security devices that can be configured to control network access are firewalls, intrusion detection systems, and intrusion prevention systems.

Also, check if a demilitarized zone (DMZ) is used between the plant network and ICS network security devices. The DMZ is an intermediary/buffer zone between the plant network and the ICS that prevents direct communications between the two.

Vital sign #4

Are network access controls in place to prevent unapproved devices from being connected to the ICS? Vital sign #3 protects against unwanted traffic entering or leaving the ICS, while this vital sign lets you determine if someone can walk up and connect a device to your ICS network. For this vital sign, check if (1) network devices (e.g., switches, routers, and patch panels) are in locked cabinets, (2) unused ports of network devices are locked down, (3) the network is periodically monitored or scanned to look for newly added devices, and (4) network device ports are configured to limit the devices able to communicate through them to specific devices and to a specific number of devices.

The first two capabilities protect against plugging a device into an open port on a network device, such as an Ethernet switch, and then listening or transmitting. The third capability is used to find unauthorized devices, but network scanning should be done with care because it can flood the network or interfere with device operations (e.g., if devices are scanned too rapidly). Testing scan rates before putting them into operation is recommended.

The fourth capability protects against someone connecting an unauthorized device to the network. For example, attackers may try to connect an unauthorized laptop to a wireless access point, or they may unplug an authorized device from the network and then connect their own device or network device in its place.

Connecting a network device in place of an original authorized device extends the network. Attackers not only can plug one or more of their own devices into the network, but can also reconnect the original device, so users will not notice a change in connectivity. When the additional network device has wireless capabilities, attacker devices can be located anywhere within wireless range. However, having capability four helps administrators find them and take corrective action.

Vital sign #5

Are your workstations and other devices hardened for security? You should check to make sure that (1) they have been stripped down to only necessary software, (2) anti-malware software is running and current, and (3) security patches are regularly installed. Security patches close vulnerabilities that attackers often successfully exploit using free hacker tool kits downloaded from the Internet. Capabilities of vital sign #2 above can be used to ensure that anti-malware updates and patches are current.

To verify that devices are stripped down, ask your vendors if they removed unnecessary software before delivery, and then look for software that may have been loaded after the device was installed. It is all too common for malware to install itself onto a computer and for users to copy their own programs to a workstation, not realizing that these programs may interfere with control system software or have vulnerabilities that can be attacked.

To find nonessential software, examine the programs in the start menu (or equivalent), and use an administrative tool, such as control panel, to check the installed programs and services. You may also search the file system of the device for executables and DLL files that should not be there. Check to make sure games, email programs, and other unnecessary or unauthorized applications are not present.

Vital sign #6

Does your supply chain program require product developers in the supply chain (suppliers, their suppliers, etc.) to use security best practices? Security best practices for developers are embodied in security additions to their development and product support processes.

Upgraded product development processes are standardized in ISA/IEC 62443-4-1 and are commonly referred to collectively as a Secure Development Lifecycle (SDL). Although not all developers have upgraded their development processes to a full SDL, many follow a good number of SDL best practices. So, instead of asking the product developer if it has implemented an SDL, ask about the security practices in its current development process.

The key components of an SDL that are of interest are: (1) documenting security capabilities provided by the ICS in which the product will be used, (2) identifying security threats to which the product is expected to be exposed, (3) documenting and tracing product security requirements through design and implementation, and (4) specifying the types of security tests to which the product will be subjected.

The first two address the environment in which the product is expected to be used. The third and fourth address the security features of the product, including assurance that those features were implemented correctly and completely. The fourth, should, at a minimum, include testing of security requirements, testing for known vulnerabilities, and exhaustive testing of invalid inputs, also known as fuzz testing. Additional testing, such as threat testing and penetration testing, can provide greater confidence that the product has adequate security. Of course, no amount of testing guarantees an absence of security flaws.

Security best practices for product support are equally valuable, and are often incorporated into SDL practices. They include security patching, vulnerability handling and reporting, and security-related documentation that describes how to harden, configure, use, and securely decommission products.

Vital sign #7

Is confidential ICS data protected from disclosure, and is critical data protected from tampering? For example, are communications carrying confidential data encrypted? Are programs, configuration files, run-time parameters (e.g., set points, alarm limits), logs, and backup data protected from tampering?

Transmitting confidential data-like recipes, trade secrets, production data, and other control system information-in the clear makes industrial espionage easier. Similarly, program files, configuration files, and critical parameters/data that are not protected from unauthorized access are susceptible to being changed or even replaced by attackers. Leaving this data unprotected from tampering gives attackers an opening to insert spyware into files or to change the way the system operates.

To assess this vital sign, first look to see if ICS data is categorized or classified according to its security needs. Second, make sure that user access controls are set to prevent unauthorized reading of confidential data and unauthorized writing/updating of files and critical data. Third, for highly confidential data, like passwords and trade secrets, verify that additional protections are used. Examples include cryptographic mechanisms (encryption and digital signatures), system partitioning 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 authorized 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; access 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 control 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 recommended, 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 users access only the resources they need? Are administrator privileges given only to administrators, and are administrators 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 parameters and functions. Control system accounts, on the other hand, define access to control system data and operations, such as who can download a controller, 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 administrative privileges. Similarly, control system privileges should not be given to administrators. 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 administrators from making changes to the process or factory floor.

Finally, an advanced application of least privilege is making sure that operators and engineers use operating system logins that do not have administrator privileges. It is not uncommon for operator stations to go through an initial operating system login after a reboot, and then have all operators use this operating system login session when logging into the control system for their shifts. Without operators sharing this operating system session, the on-duty operator would have to log off, which would terminate all displays. Then the new operator would have to log in and reestablish the displays, causing a lack of continuity between the two.

You should check to ensure that this initial login is not done by someone with administrative privileges, since all operators would then inherit administrative 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 detecting security breaches, and are there formal processes for handling breaches and associated security vulnerabilities? Breaches generally occur when protection mechanisms-such as those just discussed-are not present, are overcome, or are circumvented.

Detecting breaches is most commonly done through a combination of manual and automated activities. Many are detected by users who notice unusual or suspicious behavior from their workstations or the control system. Others are detected by
programs and devices that are constantly monitoring the ICS for threats, such as anti-malware software and firewalls. In addition, some software, like login applications, log suspicious behavior and issue event notifications to administrator or operator screens.

In many cases, logs need to be examined for suspicious behavior, for example, to determine if a failed login is an attack or just a typo by the user, or to correlate multiple control system events together to detect a pattern of malicious activity. Some software packages, like security information and event management (SIEM) systems, can be used to support these activities. However, many SIEMs are information technology oriented and are not equipped to examine control system logs.

Response teams are often used to verify and handle security breaches once they have been detected, and also to identify associated vulnerabilities and establish a way forward. In some cases, this involves restoring failed components from backups, reporting breaches and losses to authorities and customers, and notifying suppliers of vulnerabilities and requesting workarounds and patches from them.

Other considerations

As you perform this cybersecurity self-check, three additional factors may influence your score. These factors relate to the rigor with which your ICS implements cybersecurity. First, you can consider the strength of the security measures associated with each of the vital signs. The ISA/IEC 62443-3-3 and ISA/IEC 62443-4-2 standards formalize the strength of security measures using four security levels. Security levels represent defensive capabilities against increasing levels of attacker strength, expertise, and skill. For example, security level "1" represents defense against novice attackers, while security level "4" represents the ability to defend against nation-state attacks. For this self-check, give yourself higher scores if your system protects against attackers with higher skills.

Second, you should consider the formality of the organizational processes used with a vital sign. The IEC 62443-2-4 standard defines a maturity model for gauging how evolved (or formal) an organization's processes are. The base level in this model is for processes that the organization performs on an ad hoc basis. The remaining levels in this model are for formally defined, repeatable processes. If your organization has formal processes that it uses for a vital sign, give yourself a higher score.

Third, the degree to which your organization and its suppliers apply security can be assessed through certifications. The IECEE and other nonaffiliated test labs have formal certification programs for IEC 62443 security standards. Other certifications, such as Achilles Communications Certifications, are well known in the industry, even though they are not tied to a specific standard. Certifications provide an extra level of confidence that security is properly understood and implemented in the ICS. Give yourself higher scores for vital signs where certified devices or processes are used.

Top-level diagnostics

The vital signs represent top-level diagnostics that you can use for a self-check of your ICS's cybersecurity. Your answers to the questions about these vital signs bring valuable insights into how your ICS is poised to protect itself. This self-check can be performed periodically, and supplemented with occasional in-depth assessments, analogous to getting an annual checkup from your doctor and getting a full physical every few years. Of course, if the self-check reveals issues that need immediate attention, specially scheduled assessments can be used to investigate them.

Several types of in-depth assessments exist, such as risk assessments, vulnerability assessments, and threat models. Each has its own purpose, so you can select the ones most appropriate for your ICS. Finally, it is often advantageous to have an independent third party perform in-depth assessments to rule out bias and invalid assessments.

• Facebook
• Twitter
• Linked In