Five Best Practices to Reduce OT/ICS Cybersecurity Risk | #hacking | #cybersecurity | #infosec | #comptia | #pentest | #ransomware

Five Best Practices to Reduce OT/ICS Cybersecurity Risk

Industrial control systems (ICSs) ingest and automate thousands of variables to control dangerous processes that commonly use high temperatures and volatile raw materials to produce the final output. The safety and reliability of these systems is paramount to meeting the industrial facility’s health, safety, and environment (HSE) objectives, efficient production, and no unscheduled outages. These systems were never designed to be cyber-secure and for decades were considered air-gapped and unable to be reached by cyber attackers.

The evolution of OT/ICS risk

That is no longer the reality. With the adoption of digital transformation technologies to increase efficiency and lower costs, industrial facilities, which most often operate in these sectors, are now connected cyber/ physical systems. Asset owner/operators are therefore operating a “connected plant” and have found that their critical systems are vulnerable to cyber-attacks. With the continuous drip of successful attacks on critical infrastructure making headlines, risk management has become a common topic in boardrooms around the globe, resulting in greater pressure placed on security and operations teams to ensure that defenses are put in place, and should a successful attack occur, consequences will be minimized to an acceptable risk level.

Best practice 1: See it, manage it

The foundation to any operational technology (OT)/ ICS cybersecurity program is a full, in-depth asset inventory, which must include all the details of what systems and endpoints are running in the industrial environment. You must be able to “see it” before it can be protected. As unique as control logic is across various sites, asset inventory also comes in many different shapes and sizes.

To effectively use asset inventory information throughout a cybersecurity program, knowing that a distributed control system (DCS) is communicating with a programmable logic controller (PLC) or a server is talking to a switch is not adequate to reducing risk. That level of detail is easily achieved by monitoring and analyzing the network traffic to build an inventory. This method provides a detection benefit but is also limited in that it can only provide asset inventory information down to Level 2 of the Purdue Model and therefore does not achieve a full inventory, as it cannot detect endpoints at Level 1 and Level 0, in addition to “islanded” assets that are operating in a closed, or “air-gapped,” network but are still susceptible to attacks from insider threats.

What does an in-depth asset inventory look like (Figure 1)? The technology must be able to provide detailed asset information, including the manufacturer, model, version, and serial number for every piece of hardware, firmware, and software, whether connected to the network or not, across the industrial control system environment. To reduce cybersecurity risk in an ICS environment, asset inventory information must encompass every DCS and controller, input/output (I/O) cards, communication modules, and the version of the firmware loaded into each of these devices, as well as the same level of detail for PLCs, safety instrumented systems (SIS), and human-machine interfaces (HMIs), etc. The only method to achieve this level of visibility is to collect and analyze the native control system configuration files, which will enable you to confidently answer the important questions that are common in vulnerability management, asset lifecycle management, and asset migration planning, including:

  • “Do I have that asset?”
  • ​“How many are in the ICS environment?
  • “Where are they?”

Figure 1: Summary view of inventory in a typical industrial control system.

In Hexagon’s experience, working with customers around the globe, we have typically seen far more than 100 components per DCS, more than 45 for an SIS, and more than 40 for PLCs. In addition, for each computer, engineering workstation, operator station, etc., there may be considerably more than 450 inventory items. For refineries specifically, it’s common to identify more than 6,000 inventory endpoints that must be managed and protected from cyber threats.

Best practice 2: Ensure configuration data integrity

Obtaining a comprehensive asset inventory is Step 1, but unplanned downtime can still occur. Using configuration analysis is a method to lowering risk and improving business resiliency with a proven track record of preventing and shortening unplanned downtime. Each industrial environment is unique. There are certain types of changes that may occur in the configuration files that can indicate a high probability of an imminent threat. To gain visibility into these indicators, software is available that automates the process of comparing configuration files and alerting on any changes that might impact safety and/or security of operating environments. This method provides the visibility to substantially reduce the consequences of a cyber or operational incident, and therefore the overall cybersecurity and safety risk in an industrial facility.

To ensure configuration data integrity, a baseline—or snapshot of the configuration as it stands today—of the “known-good” configuration of all assets must be generated and continually monitored for any deviations on a time-based cadence. A good configuration baseline tool allows ICS engineers to define different property values across asset types, asset criticalities, or different parties that are responsible for the asset operation. The configuration management tool can alert the relevant parties based on the type of deviation so that the mean time to respond is decreased. For example, the security system must be notified if certain registry settings are changed in a control system server, as it could indicate unauthorized credential access has been gained and settings within the control system could be manipulated. Another example where ICS engineers need to be notified for immediate response is if suddenly the firmware version of several PLC cards changes.

A solid configuration management process must include an automated collection and comparison of asset configuration information to defined baselines. Simple file comparisons or notification of a download event isn’t adequate for defining baselines because a single configuration file may contain normal operational values as well as security or system reliability information. One would expect that the process operation values will change on a regular basis, so alerting on those doesn’t make sense. In addition, the responsible parties are likely different for a security change event compared to a system reliability event. So, the solution needs to understand exactly what changed in the file to alert the appropriate parties about acting. No action is required if these types of deviations aren’t detected. However, if deviations are detected in the comparison, the changes must be assessed, verified, and either documented as a new baseline value or rolled back to the previous configuration.

Best practice 3: Evaluate risk based on the environment

Evaluating OT/ICS risk is a multidimensional challenge whereby several sources of information are needed to provide holistic context, including consideration of environmental, vulnerability, and temporal impact factors. Environmental information includes a comprehensive asset inventory and topology maps (Figure 2) to show the entire environment and the connections between assets. Once a full view is achieved, assets can then be logically grouped to evaluate if a particular known vulnerability affects other assets in the environment. Logical grouping of assets further builds on the initial visibility needed to more effectively secure high-risk assets.

Figure 2: Topology map with various groupings.

Next, it is important to see the attack surface (Figure 3) and know the vulnerabilities that exist within the asset inventory. This information can come from a source such as the U.S. National Vulnerability Database, known vulnerability exploits, and independent threat analysis. It’s at this point where an automated process that ingests vulnerability data and runs it against the asset inventory to determine if the vulnerability that exists in the environment makes life a lot easier and helps to determine what mitigation is appropriate.

Figure 3: Example of an attack surface.

The third area of context required to evaluate and build a better risk score is incorporating temporal impact factors that are specific to a sitelevel OT/ICS environment or enterprise. Risk comes in many shapes and sizes, and by incorporating temporal impact scoring, users achieve a level of risk specificity that is unique to their environment. Impact factors can be sensitivity, connectivity, criticality, safety impact, and others. The key is that these are specific to your environment.

Assume a new vulnerability with a common vulnerability scoring system (CVSS) score of 8 gets published (Figure 4) and you want to know what assets are affected. Incorporating temporal impact factors might change the risk score to 9 or move it down to 6.5. If it moves down, based on this increased level of context, there may be more important vulnerabilities to focus on first, or if it goes up, it may be prudent to move it to the top of the list for remediation/mitigation. The benefit is that you’ll better understand which vulnerabilities are the most important and why, based on your specific environment.

Best practice 4: Use forensic analysis of configuration changes

There are many bad actors out there, and without spreading fear, uncertainty, and doubt (FUD), it’s important to have a healthy respect for the threats that exist in our rapidly expanding connected world. You may never experience an attack, but to reduce risk, you must have a cybersecurity program that is built on the assumption that you will. As an analogy, we may drive thousands of miles a year not thinking that we’ll get into an accident, but we always, or should always, use the seatbelt just in case one occurs.

Playing this analogy out further, assume your plant has a fenderbender (i.e., incident). Knowing the severity and how it was caused allows steps to be taken so it doesn’t happen again. With forensic analysis of configuration changes, you will be able to improve incident response by pinpointing the logic changes that occurred for more informed analysis. This information greatly aids incident responders in fully understanding the composition of the incident and decreasing the mean time to recover.

Best practice 5: Backup, backup, backup

Ransomware and other types of cyberattacks are increasingly common in OT/ICS environments, and we must assume that we’ll be attacked. Again, not FUD, but healthy respect for the reality we live in. Therefore, your ability to recover from operational or cyber incidents, whether malicious or not, is critical to your business’s success.

When considering your backup strategy, a “two is one, one is none” approach is recommended. A single trusted restore point or process isn’t sufficient for critical OT/ICS cyber assets. If your industrial facility is attacked (or any serious event occurs that might force a shutdown, such as a catastrophic event like an earthquake or hurricane), being able to confidently restore your process back to the state that it was in before the cyber or operational incident is crucial to meet your recovery time objective, and maintain safe and profitable operations.

This feature originally appeared in AUTOMATION 2022 Volume 4: Cybersecurity & Connectivity.

About The Author

Chad Elmendorf is marketing director for Hexagon’s PAS OT Integrity platform designed to secure complex, multivendor OT/ICS environments by reducing your attack surface, remediating vulnerabilities, strengthening cyber resiliency, and lowering enterprise risk. He holds a BS in Marketing and MBA from the University of Wyoming.

Did you enjoy this great article?

Check out our free e-newsletters to read more great articles..



Click Here For The Original Source.

National Cyber Security