- By Alexandre Peixoto & Lee Neitzel
- May 06, 2021
- Emerson Automation Solutions
Five proactive steps help secure your systems against malware and malicious use.
The industrial control system (ICS) touches nearly every element of manufacturing and the process industries and is therefore a vital point for cybersecurity protection. The key to properly protecting your control system from cyber threats is knowing where to start. The first line of defense involves five security measures, each normally implemented as a combination of system security features and site-specific configuration and operations procedures.
Finding a solution
Many industrial sites know control system cybersecurity is a problem, but may not know where to start, what to do, and how much to do—with different answers to these questions depending on the background of the responder.
For some, the answer is simple. Perform a security risk assessment, rank the risks, and then create a prioritized implementation plan for mitigations. Assessments are important, but security risk assessment results are often dependent on who performs them, as are the resulting recommendations. Further, recommendations often do not include the timeframe in which mitigations will be effective or address the cost of operational disruptions that may result from their implementation.
Another issue arises regarding the time it takes to implement a solution. The longer it takes to complete mitigations, the greater the chances the fixes may be obsolete, or require additional strategies to fix the same problem. Bad actors will not wait for cybersecurity plans to be completed before they attempt an attack.
A second answer is to pick a cybersecurity standard and implement it. However, cybersecurity standards are an excellent and comprehensive source of requirements, but they are intentionally abstract to keep them from favoring a particular vendor or implementation. Consequently, they do not imply or recommend how to implement security, nor do they focus on the specific security needs of individual systems or provide a roadmap for implementation. With standards, the questions of where to start, what to do, and how much to do remain open.
A more practical approach is to recognize the primary objective of cybersecurity is to reduce the chance threats will succeed and disrupt or compromise the system. This approach starts by identifying how threats enter a control system and how they work their way through it to their end targets, and then placing defensive measures in the appropriate places (Figure 1).
While there are many possible threats, malicious code injection and user interface attacks are the most likely to occur and cause harm.
Establish a security perimeter
The first step in defending against cyber-attacks is providing barriers around the ICS using both physical and electronic strategies to thwart an attacker.
The security perimeter should cover interfaces that connect the control system to external networks, device connections to ICS networks, and wireless device access points, such as laptops and smartphone hotspots. The strongest security perimeters will ensure only authorized devices can be connected to the control system, and only authorized traffic from external sources is permitted to enter (Figure 2).
Firewalls are a basic level of defense, used to mediate communications. At a minimum, they should be configured with rules identifying source and destination addresses and ports, and the protocols used to communicate between devices in the network. The use of addresses for devices directly connected to the internet should be restricted by these rules, requiring all communications to and from devices on the internet to be mediated, if allowed at all.
More sophisticated rules and capabilities are needed for protocols that dynamically assign ports when they establish connections between the source and destination. When practical, these types of protocols typically employ cryptographic mechanisms to protect their data from inspection or corruption.
Similarly, Ethernet switches can control access based on switch port and device Ethernet addresses, employing a device authentication protocol such as IEEE 802.1X. A key security practice is to lock or disable unused ports, with attempts to connect unauthorized devices blocked and reported. Moreover, laptops that have been used outside the site should be prohibited from subsequently connecting to ICS networks; when that is not feasible, they should be thoroughly scanned before being allowed to connect.
Security standards, such as IEC 62443, focus on network segmentation and device authentication, both of which are key to establishing a security perimeter, but device authentication implemented by a Windows Domain Controller, or similar, may not always be supported by network equipment. When more limited network equipment does not perform authentication, unauthorized devices may be able to send or receive packets on the network, even though they are not allowed to participate more fully in the system.
Protect exposed interfaces
The second step in defending an ICS is to protect operating systems and interfaces against threats.
Administrators can reduce attack surfaces by removing or disabling software and communication ports, such as unused TCP/UDP ports, and by limiting the number of computers accessible through external interfaces. Application gateways, such as jump/proxy servers, are great for this task.
Another important strategy is to limit the use of authorized local media devices, such as removable media, smartphones, and CD/DVDs. Smartphones provide a unique threat since users often connect them to their computer USB ports to recharge them and forget that they are also computers that can carry infected/malicious files.
Finally, to detect intrusion attempts, canary/honeypot software can be used to listen on unused ports and report attempts to access them. This is a simple, low cost, and low overhead mechanism for detecting attacks.
Another way to protect exposed interfaces is to harden the interfaces to make them more resilient to attacks.
During development, designers should validate inputs. In addition, most organizations use anti-malware packages to protect against infection through insertion of malware. Digital signatures can be used to authenticate software installed on the system, however, their use at runtime should be carefully administered to protect against denial-of-service issues.
Security standards include requirements for secure development, but these generally apply to the developers of software and hardware, and not to developers of the operating system and open -source software used in a control system. In addition, secure development requirements are generally applied to new development projects, but much, if not most, control system hardware and software was created before ICS secure development requirements were published and put into practice.
An excellent strategy for protecting systems without impacting production when testing these interfaces and their associated security patches is to use test rigs or take advantage of downtime—for example during turnarounds and shutdowns. Fuzz tests should be employed to exercise Ethernet interfaces to improve confidence in their ability to handle malformed packets and flooding attacks. Vulnerability tests can be run using hacker tools designed to exploit vulnerabilities. Finally, security patches for high-risk interfaces should be installed in a timely fashion, but only after being tested for compatibility and non-interference with operation.
Decouple the ICS from the business systems
Because the control system runs at a higher trust level than the business system, it should be separated from the business systems and from other external systems, and it should operate entirely independently from them.
Since operating systems and their supporting software are the primary targets of many attacks, the control and business system operating systems should be independent. Firewall rules should be created to block network traffic targeting the ICS operating system. This protects the ICS not only from infections propagating through the business system to the control system, but also from attacks originating in the business system.
Independence also includes separation of control system users from business system users, along with separation of ICS devices from business system devices. It also means the control system should have its own cybersecurity policies and a separate IP address space. All devices connected to the control system network, including non-ICS devices, should be part of the ICS domain, and should be access-controlled by switches and domain security.
Decoupling the control system from the business system in this manner removes visibility of ICS devices from the business system and prevents users from accessing the control system using their business system credentials. Attackers who have gained a foothold in the business system can neither see ICS devices nor use business system user credentials to access the control system.
While single-sign-on from the business system is an attractive operational feature, it would enable lower-trust infected business system software to issue login attempts to the higher-trust ICS operating system. This unnecessarily exposes ICS operating system interfaces to the business system, opening the control system to serious attack.
Many security standards focus on network segmentation and separation of duties from a privilege-level perspective, but these standards are silent on ICS operating system independence. Overlooking operating system independence can lead to improper implementations and sacrifices the benefits just discussed, making it much easier for attacks to be launched from the business system.
Minimize use of operating system administrator accounts
A primary goal of malicious code injection is to gain operating system administrator privileges, which happens immediately if the malware is inserted into software that is already running under an operating system administrator account. In these cases, the malware’s abilities are practically unlimited. For example, it can create new users, delete or modify properties of existing users, access restricted files and data, change security settings, and execute code and applications.
However, if malware is inserted into software running under a more restricted operating system account, the inserted code will not have the privileges it needs to achieve its objectives. In most cases it will give up and terminate the attack.
Non-administrative users, including engineers and operators, and software services (software applications that run in the background without a user interface) should be assigned to their own restricted operating system accounts, and should never be assigned as members of administrator groups/accounts. In addition, keeping network administrator accounts separate from operating system accounts prevents attackers who have breached a workstation or server from gaining access to the network administrator account and removing network device firewall rules.
This measure protects against both injected malicious code, which runs with the same privileges as the software into which it was injected, and against attackers who have been able to acquire control system user credentials such as username and password. With proper implementation of this measure, the attacker is only able to execute code, run programs, and access files authorized for that specific restricted user, significantly restricting the attacker’s capabilities.
ICS security standards address this problem by requiring users and software to run with the least privilege or functionality needed to do their job. While this is a best practice, the problem is more subtle, since software applications often need privileged operations to operate properly.
For example, if an application needs a specific log file to operate, it may check for that log file at startup and create it if necessary, which may require administrative privileges. As a result, users who need to run this application might need to belong to administrator groups/accounts. Because there is a need, the principles of least privilege and least functionality are not violated so long as privileges are closely monitored.
Software services and desktop applications should run under restricted operating system accounts and be given only the capabilities needed. In general, privileged calls should be moved from desktop and software services to installers or special privileged services that can be called at runtime as needed.
Log critical user activities
The final step in defending against attacks is to log user activities because this information may be needed during forensics to trace a security event back to its source. This is typically called the non-repudiation requirement because it keeps a user from denying responsibility for an action.
For typical desktop applications, it is relatively easy for an application to determine its user and create an event record that contains the time, action, and username. However, for software services invoked by a desktop application it is not so easy.
Services run under their own account, so when they need to obtain the invoking (calling) user identity, they must make a specific call to the operating system if the calling desktop application does not securely pass the user identity to it. Once a service obtains the user identity, it can create the appropriate event record. Unfortunately, however, not all services are designed to do this.
In addition, if the initiating user invokes the service through a series of intervening services, normally only the first service in the series will be able to obtain the identity of the initiating user from the operating system. Since services run under their own account, and not under the account that invoked the service, only the initial service in the series will be able to determine the identity of the initiating user.
In these cases, not only is the user identity lost, but the service typically runs at a privilege level high enough to support all users that invoke it, effectively increasing the privilege level of all but the most privileged users.
A comprehensive approach
The most common network attacks target the operating system, and many of these attacks attempt to propagate themselves to other computers in the system. User-based attacks are also common, some intentional, and some the result of user error. In both types of attacks, the level of privilege that can be attained is directly proportional to the level of compromise that can be achieved.
The best protection against these and other attacks is a defense-in-depth strategy that combines attack surface reduction with privilege level restrictions for users and software services. However, as with many operational improvements in industrial plants and facilities, cybersecurity cannot be a set-and-forget endeavor, and instead must be reviewed on a regular basis.
For more information, see the website.
All figures courtesy of Emerson
Did you enjoy this great article?
Check out our free e-newsletters to read more great articles..Subscribe