Threat Hunting – Remedia Security

Industrial Control System Vulnerabilities

Posted by Dustin Smithon September 26, 2021September 26, 2021in UncategorizedLeave a comment

ICS Cybersecurity Vulnerabilities

What is Vulnerable?

Previously, ICS interconnections focused primarily on enabling communications between the processor and controller, and were isolated. The introduction of modern information technologies and operating systems into the ICS environment has provided much needed system integration capabilities, but at the cost of exposing ICS to security threats previously known only to IT systems.

Consider a simple situation where a globally popular operating system is used as the foundation for deploying mission-critical ICS software applications. Each and every time a vulnerability is found in that operating system, the ICS using it is also vulnerable. As more ICS migrate toward using ubiquitous IT solutions, the risk of having critical infrastructure systems vulnerable to the same types of threats as IT systems rises.

Open Systems Interconnection

Well-known vulnerabilities exist in each of the seven layers of the Open Systems Interconnection (OSI) model. As ICS migrates away from traditional and proprietary protocols, the use of new and efficient operating systems can make them vulnerable to attacks.

The vulnerability lies with the transparency of the OSI model, as opposed to the obscure proprietary ICS frameworks known only to those who had designed them, or to those with specialized training.

As we leverage well-known IT communications protocols (which can be insecure) and use them in a manner that takes advantage of current networking functionality (which can also be insecure), we expose critical infrastructure systems to attack.

ICS Attack Targets

Any hardware or software processing, storing, or transmitting information digitally is vulnerable to cyberattack. Whether the system can be compromised is dependent on whether the vulnerability is exploitable. In other words, any system can be attacked, but not every attack will be successful. In control system environments, several types of digital assets can be targeted by a cyber adversary:

Networking devices
Programmable logic controllers (PLCs)
Remote terminal units (RTUs)
Human-machine interface (HMI) workstations
Data acquisition servers and historians
Engineering workstations
Remote access devices
Authentication and authorization servers

Even integrated safety systems could be vulnerable, and there is risk if connected directly to the control system network.

There are many pathways to communicate with an ICS network and its components using a variety of computing and communications equipment. These pathways can be used by anyone knowledgeable in process equipment, networks, operating systems, and software applications to gain access to the ICS.

Poor Code Quality

One of the primary causes of security vulnerabilities in control system software and firmware is the use of poor programming techniques. Most developers do not intentionally write code with security flaws. However, ICS are developed with a focus on system availability and resiliency. When the requirement for high availability is the top priority, security is often not considered during the development lifecycle.

Code issues are often exacerbated in control systems that may be decades old, and running code that has not been updated since its installation. Changing coding practices or rewriting the source code for a flagship product can be expensive for vendors and customers, and applying patches in an operational environment is often difficult.

ICS owners should request that vendors certify their developers are trained in, and use, secure coding practices as part of their quality control process. ICS owners should also ensure they create the necessary communication paths needed to quickly learn of any code-based security problems, and to receive and deploy patches in an effective way.

Increasing cybersecurity awareness and its importance in the system and software development life cycle helps asset owners and vendors understand the need to proactively build security into the system, which will significantly increase the security of their ICS products.

Network Design Vulnerabilities

ICS networks are typically designed to support real-time data communications. It is common for security best practices to be excluded when designing ICS architectures. The network infrastructure environment within the ICS is usually developed and modified based on business and operational requirements, with little consideration for the potential security impacts of the changes.

Some ICS network architectures use flat networks with no zones, no port security, and weak enforcement of remote access policies.

To compound this problem, ICS networks may be directly connected to corporate environments without firewalls and zones, or allow direct connections to the Internet. Over time, security gaps may have been inadvertently introduced. Without remediation, these gaps introduce vulnerabilities into the ICS.

Web-Based and Remote Service Vulnerabilities

Improvements and modifications to control system functionality are usually the result of customer demand. Embedded Web services, remote diagnostic tools, reporting features, and other value-added capabilities traditionally not used in control system solutions are increasingly being seen in the field. While Web-based and remote services allow ICS operators to more efficiently manage, monitor, and control the systems, this approach may introduce significant security vulnerabilities into the control system architecture.

For example of this, many control system vendors meet the demands of their customers by integrating easy-to-use interfaces for managing equipment. An example is incorporating simple and inexpensive Web services directly into their field devices. This allows operators to control and administer critical equipment from anywhere through a Web or Internet browser. Without a proper security analysis of that Web interface, it could be used as an attack vector into field equipment.

Vulnerabilities unique to such remote services are now built into many control system vendor solutions. If exploited, such vulnerabilities can reveal significant information to an attacker or provide them with access to the device itself.

Vulnerability Factors

The convergence of IT and ICS creates new pathways that can be used to exploit a large number of cyber vulnerabilities.

For instance:

Requirements for rapid information exchange, such as data moving from plant operations to executive decision makers, can limit the effectiveness of adequate defense-in-depth strategies or recommended best practices for ICS cybersecurity.
Requirements for near real-time accessibility to critical operations may facilitate the use of remote access solutions focusing on availability and not necessarily security.
To optimize performance and resiliency, asset owners often provide direct access to the operational environment for their vendors and integrators, thus opening possible channels of attack.

Root Causes of Vulnerabilities

Legacy Control Systems

Because replacing an aging control system can be expensive and disruptive to operations, the life cycle of many control systems is 15 years or longer. These legacy systems are not designed to provide protection from modern-day attacks, or may not be updated to provide the protective mechanisms developed since being placed in service. Ongoing assessments, independent cybersecurity research, and self-disclosure from vendors suggest there are inherent security vulnerabilities in ICS that are residual from past engineering and development activities.

These did not start as vulnerabilities, as they were originally system features designed to facilitate the efficient and safe operation of mission-critical systems required to be available all the time (high availability). They were also designed to be used on systems isolated from untrusted networks.

Today, many of these same features could be used to seriously damage the system if used by operators who have become disgruntled, or if an adversary or attacker is able to acquire the role of the authorized user.

Legacy Systems: Plain Text Traffic

Few ICS manufacturers and vendors deploy data obfuscation and cryptography to prevent traffic eavesdropping, and plain text protocols are ubiquitous across almost all control systems. ICS protocols were originally designed for use in isolated environments, and because availability was the highest priority, there was no need to defend these systems from data theft. More importantly, plain text makes it easier to integrate disparate systems. As owners, vendors, and integrators push for interoperability, plain text traffic remains common. Plain text protocols are also simpler and faster to troubleshoot than encrypted protocols.

Adversaries with access to control system networks can potentially perform real-time traffic analysis, as well as harvest network traffic for offline security testing. Considering the trust relationships in control system environments (e.g., between operator consoles and field equipment, or database-to-database), an attacker who has captured a plain text password can exploit these relationships by impersonating trusted cyber assets or injecting data into the data stream, causing an undesirable event.

Access to control traffic in plain text allows a threat actor to execute numerous attacks–including denial of service, man-in-the-middle, session hijacking, and other network-based attacks, ultimately impacting integrity and availability.

Legacy Systems: Hard-coded/easy passwords

Password management is a fundamental component of any security program. However, few ICS operators have provisioned their systems with unique passwords supported by robust security policies, such as routine password changes—especially default passwords. Because ICS are always on, most ICS asset owners use an easily remembered, shared password for all operators; or the default passwords are never changed after installation. While this ensures operators can quickly access the system, it also makes it easy for an attacker to do the same.

Some vendors have designed their systems with hard-coded or unchangeable passwords. Hard-coded passwords are used internally by ICS programs needing authorization to communicate with other computer resources, such as databases, or are used to simplify software installations and program configurations.

For example, initial authentication credentials are exchanged between ICS historians using hard-coded passwords. It is trivial to discover most hard-coded passwords: they are passed in plain text across the network, or openly published in equipment manuals or the vendor website. Advanced malware has been developed to exploit hard-coded passwords in conjunction with other vulnerabilities, leaving systems using them at risk.

Legacy Systems: No Least Privilege

Coding methods previously used by ICS vendors emphasized availability because these systems were historically isolated. Availability, not security, was important for the associated applications and system, so they were run with unlimited privileges. This essentially gave operators complete administrative control of the system.

When the system is operating with administrator-level privileges, both vital and non-vital applications are running with a high level of authority. If threat actors compromise the system, they have administrative privileges to control and damage the applications and processes.

Many processes found in ICS do not need to run with unbounded privileges. Applying the principle of least privilege means running systems, processes, and applications with the minimal amount of authority needed, thus restricting the level of system access should the system be compromised. Typically, this is accomplished by having the user log into the system with a user level vs. administrator-level account, restricting which permissions are available to the user.

Legacy Systems: No Authentication

System functionality facilitating the addition of new applications without security checks is a common problem. ICS downtimes are few, and it is critical that local and trusted entities be allowed to install applications without delay.

However, as requirements and capabilities for control systems have matured, new and complicated third-party applications are integrated into the control systems, and not all can be trusted.

The malware group, Havex, replaced the normal installation files of third-party software with tainted copies. They surreptitiously installed a remote access trojan (RAT) on the computers of targeted companies through the ICS used to automate everything from switches in electrical substations, to sensitive equipment in nuclear power plants.

Legacy Systems: No Check

Data integrity checks ensure the ICS information an operator is monitoring is correct and has not been modified. When ICS were isolated with limited connectivity, there was little doubt the readings were accurate. As more ICS become interconnected, risks of critical operation data being altered increases.

For example, if an HMI is compromised, it could indicate to the ICS operator that a critical valve is closed, when it is actually open. The false information displayed by the system could cause a catastrophic incident. Ensuring data integrity in the HMI is of vital importance, especially as ICS are becoming more interconnected, escalating the risk of compromise.

Legacy Systems: Guaranteed High Availability

The primary focus for ICS, especially mission-critical ICS applications, is high availability. Unfortunately, coding a system for high availability differs from one designed to be secure. Designing high-availability systems often creates vulnerabilities easily discovered by an attacker.

Vendors do not want security vulnerabilities in their products any more than users and asset owners do. Yet a vendor may be slow to fix a vulnerability because of the level of effort required. As a result, the application may be vulnerable when the system or application is not designed to, for example, check for abnormal data inputs, which can be exploited using attacks such as denial of service, buffer overflow, or data injection. The public availability of easy-to-use exploit code increases the number of potential attackers by including those who are unskilled, thereby increasing the severity of the vulnerability.

Legacy Systems: Easy Connectivity

As corporate entities and peer locations have a need to obtain real-time control system or process information, new methods for exchanging information between a trusted control system and an untrusted enclave are developed. An organization’s ability to obtain real-time data is important, because it provides management with accurate and timely information to make better decisions regarding the operations of their critical infrastructure systems.

While there is no doubt that interconnecting ICS with business systems has improved productivity, every data channel creates a potential vulnerability, increasing the risk to the control system. This includes database sharing, peer-to-peer communications, VPN access, remote vendor access, and any other conduit allowing direct access to mission-critical control system activities.

Often, postmortem analysis of cybersecurity incidents indicates these information-sharing channels are often the vectors used by malware, or to facilitate unauthorized remote access.

Device Programming

The functionality and capability of control system equipment, specifically field devices, have increased tremendously. Many vendors embed additional services in their control systems, including Web, file transfer protocol (FTP), simple network management protocol (SNMP) services, and other types of functionality designed to enhance operations.

While these features provide many easy-to-use services and increased functionality, they also introduce new vectors for an attacker to remotely configure and program these devices, or to modify the firmware. While this is not an issue for all vendors, it does pose a significant cyber risk. These devices are connected directly to ICS components, which monitor and control process equipment, creating a target-rich environment.

Current device programming technologies used include:

Network enabled
Remotely programmable
Onboard I/O servers and Web servers
FTP and SNMP enabled
Physical cybersecurity devices
Next generation directions

Device Programming – Field Device Issues

Historically, field devices have been deployed in a manner that assumes they will be placed in a secure environment, one not allowing for unauthorized access to the device in any way. If there is no risk of unauthorized access, the devices often use protocols devoid of authentication and authorization.

Why would you need authentication and authorization if the only people accessing the device were trusted users? This lack of access security is an artifact from the legacy control system environment where there really wasn’t a need for access across the network. As a consequence, ICS don’t always support access control.

In many architectures, any host can communicate with, and send commands to, any other device, provided they both use the same protocol. The design of some ICS uses a polling system. By design, a device’s onboard processing power may be insufficient to handle large amounts of data.

As a consequence, field devices are vulnerable to catastrophic failures because of data storms, packet flooding, malformed data, or other events caused by regular behaviors. The breakdown of such a critical piece of equipment can result in failure to deliver critical process information and loss of control.

Connectivity and Network Architecture

Engineers can easily bridge ICS networks and business networks with the adoption of IT designs and architectures. While the benefits may be significant, this push to integrate networks also creates one of the most significant sources of ICS vulnerabilities. ICS networks that were previously physically and electronically isolated may now be integrated and connected with other networks, including the Internet. As a result, exploits previously accessible by physical proximity only can now be delivered to a control system from anywhere in the world.

Many asset owners establish an electronic security perimeter around their ICS to protect from a cyberattack. This perimeter creates a trusted environment within the ICS network and protects assets from direct exposure to untrusted domains.

Historically, the level of trust between ICS domains mirrors the trust level between corporate operations and the Internet. However, as corporate requirements for real-time monitoring and analysis of ICS have become more common, the architecture must be designed to support a more trusted relationship.

To facilitate better communications, we see architectures built with a transitive trust between ICS and corporate networks. This relationship creates a need for more robust protection mechanisms and assurance that an attacker who has a presence on the corporate network cannot use this trusted path to access the control system network.

Connectivity – Trusted Connections

A DCS is not the only system that can be attacked by piercing the electronic perimeter. Any remote access providing engineers and technicians the ability to access the control system from an external network extends the electronic perimeter. Typically, VPN connections (the primary method for establishing remote communications), if properly installed and configured, are often safer than firewall exceptions. However, because the perimeter has been extended to a remote location, the network engineers do not have as much control over the end device as they do with workstations located on company premises.

One final point about trust: just like in the corporate environment, databases and third-party applications (such as document viewers) can be important components in an ICS. However, these third-party applications, if not properly secured and patched, can provide an exploitable vector. Attackers can also exploit the trusted relationship between databases replicating data between the control network and the business network.

Top Vulnerabilities

The vulnerabilities listed below are repeatedly seen during site assessments, CISA Incident Response Investigations, and CSET^® assessments.

Credentials management: Includes weak password policies (no passwords, no enforcement of strong passwords, and use of default user names and passwords) and insufficiently protected passwords.
Network design weakness: No security perimeter defined and lack of network segmentation.
Lack of formal documentation: No security policy and procedures, and poor security documentation maintenance.
Weak firewall rules: Firewall bypassed, firewall rules not tailored to ICS traffic, and specific ports on host not restricted to allowable IP address.
Audit and accountability: Lack of security audits and logging.
Permissions and privilege access control: Improper user permissions, open-network shares, and poor security configuration.

Industrial Control System Cybersecurity Threats

Posted by Dustin Smithon September 26, 2021September 26, 2021in UncategorizedLeave a comment

ICS Cybersecurity Threats

Finding the appropriate balance of effective countermeasures that don’t impact control system operations can be challenging, and in many cases asset owners need to identify levels of acceptable risk to their systems.

Understanding the threat helps asset owners:

Understand the realistic profile of a cyber adversary that could target specific control systems.
Make better informed decisions regarding what assets to protect and how.
Have the right information to fine tune cybersecurity training for specific personnel involved in control system operations.
Define the cybersecurity criteria to be met during system design and when the system is fully operational.
Understand what countermeasures can be deployed to escalate cyber defenses beyond the capability of recognizing adversaries.
Design appropriate security monitoring strategies addressing threat aspects with the greatest contribution to cyber risk.

What is a threat?

A threat is any person (threat actor), circumstance, or event with the potential to cause loss or damage.

It is important to consider threat relative to capability, opportunity, and intent. From a defensive perspective, if we know the capability of our adversaries and the vulnerabilities that would most likely provide them opportunity to attack, we can create countermeasures removing those opportunities. We can also create defenses requiring capabilities beyond the adversary’s ability to compromise.

If there is a certain condition associated with compromising a control system, and we create countermeasures forcing the adversary to work at a level beyond that condition, the economics suggests the attacker may abandon the attack altogether. Ultimately, understanding capabilities and motives should help improve security postures to create countermeasures appropriate to the risk, while minimizing impacts to business operations.

Attributes

It is important to understand attributes because they are interdependent when it comes to determining whether an adversary may execute an attack. Attributes also allow defenders to create strategies that may thwart attacks.

Alignment of all three attributes—capability, intent, and opportunity—may indicate an attack is imminent. Alignment greatly impacts the probability that a threat actor can execute a successful attack.

As we will see, influencing an adversary’s intent is rarely possible, but improving defensive and detection capabilities to render an adversary’s capability insufficient is always possible. Deploying security countermeasures has a direct effect in removing or changing adversarial opportunities to attack control systems.

Unlike the risk equation, the individual attributes of threat are summed, not multiplied. This means adversaries with a strong intent or motive can still be a threat, even though they may not have the capability or opportunity to launch an attack. Over time, they may acquire or create the capability and opportunity.

Threat is often the least understood and most difficult to quantify because human behavior can be unpredictable, and involves diverse capabilities, intent, and opportunities. Unpredictable behavior creates situations where static countermeasures may not be adequate to protect critical systems.

Hazards vs. Threats

Threats are not predictable in the same way as hazards, meaning cybersecurity cannot be assessed in the same way as safety. Defense-in-depth strategies can help compensate for the diversity of threat actors and their wide range of capabilities. As such, it is important to recognize that as the threat landscape changes, so must our ability to defend the systems.

Hazards

Hazards are considered situations possessing inherent and known dangers. Examples of hazards include electrical, confined space, or flammable. The failure of a piece of electronics that causes a chamber filled with acid to overflow is also an example of a hazard. In general, this acid overflow hazard falls into the category associated with safety. In safety studies, we have proven historical data about equipment failures that is tied to known dangers and risks, and we can calculate probabilities on when undesirable events might happen. In some cases, we can calculate the actual average time it will take for a system or device to fail based on environmental factors and past use cases. But the data used to do this are based on predictable behavior.

The field of industrial automation has historically collected information on hazards that are used to develop safety guidelines. Databases of hazards and historical events are used to determine the probability of a dangerous event occurring. This in turn allows professional certification of systems to meet measurable safety requirements. Things to consider include system lifetime, mean time between failures, and other measurable attributes that can help system owners proactively manage the safety and resiliency of equipment while optimizing performance.

Hazards can be categorized. Certain attributes are associated with different hazards. These attributes offer analysts information that may be used to develop fairly precise forecasting of different types of events, allowing analysts to plan for certain incidents related safe operation.

Threats

Threats are not predictable. Cyber attackers, weather, animals chewing cables, personal events, or falling trees are all examples of threats. If a threats are not man-made, it is still hard to accurately predict how and when they will occur. We don’t have data or granular information to help us determine if and when a threat-based event will happen. For human threats, this can be difficult as we usually cannot define the combined value of capability/opportunity/intent. Safety and security have significant roles in the resiliency and reliability of ICS. Safety and security are complementary, but the disciplines themselves are different. It is important to calculate security risk for control systems, and even more important to calculate appropriate proactive and reactive security mitigation strategies.

Threats are also not predictable even when historical information exists. Being able to categorize threats and predict associated incidents with precision is difficult because people do unpredictable things. This unpredictability is often driven by a multitude of factors beyond the control of even the threat actor (i.e., weather, politics, personal events).

Threat Actor Categories

By better understanding the capabilities, intents, and opportunities of human threat actors, we can better design defenses for ICS. The types of threat actors can roughly be divided into three categories: mainstream; organized; and terrorist and nation state.

Insider Threats

Can the security of an ICS be threatened by a trusted insider (an employee or vendor) who has specific knowledge of, and access to, the ICS?

Absolutely!

Even though an insider may not have intent, they certainly have substantial capability and opportunity, which may make them a significant threat.

Unintentional Threats

Based on known ICS cyber incidents to-date, the most likely ICS attacks originate from an insider, or from an external adversary who has acquired credentials to operate as a trusted insider.

An insider could be acting alone or as a member of a group, or the more serious Terrorist/Nation State attack. The attack may be unintentional or intentional. The causes of an unintentional incident include:

Deceived – social engineering, phishing
Mistakes
Poor training
Careless, taking shortcuts, fatigued

A mistake or failure to follow adopted policies can also cause a cyber incident on an ICS that is as severe as a deliberate attack. A well-trained system administrator is crucial to protecting an ICS from cyber attacks.

Intentional Threats

Motivations for launching an intentional attack on an ICS could be related to those cited earlier, but may also include:

Recruited – blackmailed, bribed, embedded
Revenge – disgruntled, terminated
Curiosity
Financial

As an example of revenge, Mario Azar, an IT consultant for Pacific Energy Resources, successfully disabled an offshore oil platform’s leak-detection system remotely, using his company’s virtual private network (VPN) over the Internet. After receiving his last payment for contract work, Azar petitioned to continue work as a full-time employee, but Pacific Energy Resources declined to hire him.

Azar continued to remotely log into the leak-detection system, which was used to monitor three offshore oil platforms near Huntington Beach, CA. This resulted in impaired computer system monitoring for leaks on all three offshore platforms.

Threats

As ICS developers began to leverage interoperability and open-system connectivity, they moved away from isolated architectures. However, during this transition, many of the systems were still dependent on legacy hardware and software, and the requirements for availability often prohibited asset owners from taking their systems offline for long periods for updates. As a result, appropriate security defenses were not installed, and the ones that were installed often did not provide sufficient defense against modern-day attacks.

ICS defenses have not evolved as quickly as those in the corporate IT world, and in many cases the average ICS is still years behind current levels of cybersecurity found in non-ICS technology.

Because of the rapid integration of technology and networks between corporate IT and control systems, there is a huge push to protect legacy ICS from modern-day attacks. As many of the security countermeasures were developed for environments that set confidentiality as a primary focus, deploying such security mitigation technology into ICS environments (where both availability and integrity are primary objectives) can actually have a negative impact productivity.

Current Trends

What are the current threat trends? As mentioned previously, Stuxnet was a game changer in that it was the first publicly known malware developed to target a specific ICS, as well as a specific process. After Stuxnet, new variants of the malware have surfaced, in addition to other ICS-specific attacks. For example, Havex malware sought control systems using a specific protocol unique to industrial automation.

The emergence of Advanced Persistent Threat (APT) is a trend that cannot be ignored. APT typically refers to cyber threats from nation states. As the name suggests, this type of threat employs advanced techniques to deploy sophisticated attacks that compromise systems, help advance an attacker’s goals, and avoid detection to stay resident as long as possible. The attacks are not necessarily limited to cyber methods of compromising a target. They may be combined with other intelligence resources to reach a specific goal or objective.

This persistence toward reaching a specific goal is different than the objectives of more opportunistic types of attacks where attackers are looking for any information to exploit for financial (or other) gain. Because these are specific attacks, adversaries execute unique, customized code to achieve a specific objective. These threat actors have extensive resources (capability) and motivation (intent) to reach their goals.

Attacker Tools and Techniques

The phases of the attack life cycle include:

Reconnaissance/targeting
Vulnerability assessment
Attack/penetration

Just like a carpenter uses a variety of tools to build a house, an ICS threat actor also uses a number of different tools and techniques to execute an attack.

Specific tools are designed for each specific phase in the attack life cycle. Some tools research the target, some gain and maintain access to a system, and others launch an attack. Part of successfully defending a system depends on understanding your opponent’s capabilities.

Evolving Attack Tools

Many modern ICS threats and exploits are due to the rapid research advancement of more complex attack techniques. There is growth in the number of activities correlating to the system attack life cycle, such as:

Reconnaissance/targeting

Cynsys
EternalBlue
Shodan

Vulnerability assessment

Sniper
Ettercap

Attack/penetration

Metasploit
Gleg Agora, Nessus Scripts, Immunity Canvas

Control System Vulnerabilities

Because we are dealing with industrial automation, control system vulnerability discussions cannot take place without considering the consequences and impact on critical infrastructure. This makes ICS targets appealing to a broad audience and will attract interest from adversaries in all threat actor groups.

Finally, there is a notable increase in the interest in ICS cybersecurity because asset owners are introducing training and compliance efforts to their personnel. This, in turn, drives demand for briefings, conferences, and academic activities—all of which create literature that is available to the community at large.

Industrial Control System Cybersecurity Risk

Posted by Dustin Smithon September 26, 2021September 26, 2021in UncategorizedLeave a comment

To define the cybersecurity risk to industrial control systems (ICS) we need an understanding of the equipment to be protected. While there are similarities between the computing technologies that support both IT and ICS, operational requirements require careful consideration when implementing cybersecurity measures for ICS.

Managing cybersecurity risk is fundamental to protecting assets. Whether securing assets in the IT or the ICS domain, finding the right approach to applying cost-effective risk mitigation solutions is vital. In order to do this properly, asset owners should understand how to define risk in the context of their own information infrastructure. Unlike IT domains where the practice of deploying broad security countermeasures is commonplace, ICS assets are best protected when the mitigation strategies include careful consideration of the system’s operational uniqueness and availability requirements.

It is also important to understand how a system can be attacked and the potential consequences.

Risk Equation definition

Risk = Threat x Vulnerability x Consequence

Let’s take this definition a step further.

Risk can be quantified using the risk equation. The equation consists of three components:

• Threat

• Vulnerability

• Consequences

Probability

We need to define one more term:

Probability – the likelihood of an event occurring.

Probability is based on the threat to the system multiplied by the vulnerability of the system. The greater the threat, the more likely the system could be attacked. And the more vulnerable the system, the greater the probability the system could be compromised.

Risk

In the context of cybersecurity, an example of a threat is a hacker. An exploitable weakness example (vulnerability) in a financial system’s computer. And the theft of credit card data is an example of a consequence.

Risk = Hacker x Financial system’s computer x Credit card data

Not all threats are intentional. Factors such as weather, material fatigue, or human error all contribute to risk and result in consequences that could be more severe than those caused by intentional threats. In this course, we will focus on intentional threats. This will give you a foundational understanding for creating unique cyber-risk reduction strategies for ICS, and for designing accurate and appropriate countermeasures for these unique environments.

Mitigating Vulnerabilities

In ideal situations, asset owners will have a program in place that makes sure they have timely information about vulnerabilities related to their ICS. Unfortunately, the availability of information specific to control systems vulnerabilities can be hard to acquire, and even harder to verify. But this is changing thanks to cooperative programs between government, ICS vendors, and the research community.

Even with accurate vulnerability information, verifying the applicability of the vulnerability to an ICS can be difficult. Mitigating these vulnerabilities can be even more complex because:

1. Extensive testing needs to be performed prior to the application of a mitigation (such as applying a patch) to ensure it does not affect critical system functions; and

2. If a patch or update is considered viable, strategic planning and downtime are required in order to implement it. In high availability control system environments, finding downtime can be challenging. Even after prior testing, the system must be monitored to ensure the mitigation is working as intended

Lessons Learned Ukraine’s power grid

In 2015 and 2016, Russian cyberattacks on Ukraine’s power grid caused two widespread blackouts. However, triggering large-scale blackouts hasn’t been the only goal of Russian threat actors. In 2018, FireEye’s cybersecurity researchers announced that Russian hackers were probing the U.S. power grid. It is suspected that state-sponsored threat actors, referred to as TEMP.Isotope, are targeting the U.S. power grid as part of an ongoing counterintelligence campaign.

The intention of these subtle attacks could be to steal trade secrets, store knowledge of vulnerabilities for future exploits, and to patiently exhaust the U.S.’s defenses. Among other tactics, Isotope uses spearphishing and infected websites to gain access to systems. This discovery is a sobering reminder that an organization’s security is only as strong as its weakest link – people –and that it is critical to offer proper training to help prevent compromise.

To read the entire report, use this URL

(https://www.wired.com/story/russian-hackers-us-power-grid-attacks/)

Elevated Risk

Historically, asset owners protected their ICS by physically isolating their system from other networks and using physical security measures to protect it from unauthorized access. The cyber risk, as a function of threat, vulnerability and consequence, was measurable and limited because:

The threat would most likely come from an insider. Originally, most risk was associated with insider threats, or authorized users performing unauthorized or undesirable actions on the control system.
Even though vulnerabilities existed in the ICS, the risk associated with those vulnerabilities was perceived as acceptable because of physical controls (e.g., locks) implemented to prevent unauthorized individuals from gaining access to the control room.

For known vulnerabilities, an evaluation process was used to determine whether the vulnerabilities needed to be fixed. This process assessed whether an insider could become an adversary, as well as whether fixing the vulnerability had a negative effect on production.

Cyber Risk to ICS

Over the years, the cyber risk to ICS has changed dramatically. We still have risk associated with insider threats, but business demands have evolved and now require that many of these formerly isolated systems are connected with Internet, corporate, peer, and customer networks. Although this new interconnectivity has improved productivity and optimized business, the control systems are now exposed to previously unseen threats, such as those associated with hackers, viruses, malware, and others.

A major concern associated with exposing ICS to cyber threats is that the control systems themselves, originally designed to be protected by physical countermeasures, often do not have an inherent cybersecurity capability to thwart attackers. This is especially true in older systems. Moreover, many of the protocols and communication standards were designed without any security at all. This makes it challenging to protect these systems, as significant changes intending to reduce cyber risk can create situations where the ICS no longer functions as designed.

Interconnected Networks

Fortunately, this perspective is changing. Asset owners and operators are beginning to understand that interconnected networks can create opportunities for an adversary to gain access to the control system; and, if the system is compromised, acquire the same system rights and privileges as an operator. This could create a situation where the external attacker is in the same position as a hostile insider, and that is worrisome for asset owners.

Furthermore, many ICS engineers had not perceived that there were credible cybersecurity threats that justified the added expense of securing their control systems. This was especially true when these systems were isolated (air-gapped) and running on proprietary hardware. As ICS engineers gain a better understanding of the vulnerabilities created by interconnected ICS, there is an increased awareness of the cybersecurity threats to their systems.

Increased Awareness

The general level of interest in control system cyber attacks continues to grow at a rapid pace. The concept of a cyber attack on an ICS resulting in a real-world kinetic impact makes ICS attractive targets. The growing community of interest in control system cybersecurity involves professional and independent researchers, vendors, security consultants, asset owners, and educational institutions. Excellent work continues to be done. New vulnerabilities related to specific products, protocols, or other control system components surface regularly.

Adversaries around the world have quickly begun to understand that there are significant opportunities in targeting critical ICS. The level of effort necessary for an adversary to create successful attack strategies can be remarkably low. Using cyber as an attack platform is growing in popularity because of the speed with which the attacker can operate, and the inherent anonymity they can achieve compared to a physical attack.

Terrorists and nation-states are starting to view ICS as primary targets for an attack on critical infrastructures with the intent to cause damage as severe, if not more so, than launching a physical attack. We continue to see an increase in targeted attacks against critical infrastructure entities. Historical case studies provide insight into just how damaging a cyber attack on a control system can be.

Integrated IT/ICS Networks

Security Concerns

The justification supporting IT/ICS interconnectivity is sound from a business perspective, as optimizing manual, disparate processes has the potential to result in more revenue. The downside is that it increases the exposure of ICS to new threats and vulnerabilities, which in turn increases risk. Every new domain that is connected to the control system network exposes the network to the threats and vulnerabilities associated with the newly added domain.

In order to counter these threats, we need to understand how the adversary thinks, and determine whether they are targeting specific systems or a broad set of systems within a larger corporate enclave. Understanding the intentions of the attacker is important, as it can provide intelligence as to how an ICS could be compromised and why. This is why incident information is shared after the fact—to ensure the larger community can learn from what attackers are doing now.

Availability, Integrity, and Confidentiality

This new landscape of attack vectors being created by the interconnectivity of IT and control system networks requires appropriate cybersecurity countermeasures for effective risk mitigation. Countermeasures and mitigation strategies should be proportional to the possible consequences posed by the exploitation of the vulnerability.

Many commercial solutions that aim to mitigate common cybersecurity vulnerabilities in IT systems do not have the flexibility, nor can they be customized, to accommodate the uniqueness of control system architectures.

Many of you are familiar with the CIA elements used in IT environments that states confidentiality, integrity, and availability in that order are most important. You may have heard the model is turned around for ICS environments where availability, integrity, and confidentiality are more important. It is important to ensure the integrity of the data from the safety systems.

With the focus on availability, integrity, and confidentiality (in that order.) With safety and availability we need to be cautious about how we utilize security technology developed for IT, and how we implement it into ICS environments.

Understanding potential adversaries and the level of effort would be required to execute a successful attack should help entities develop appropriate defenses for their systems. Just because a control system component or application is vulnerable does not necessarily mean that an attacker will be successful in exploiting that vulnerability.

Summary

Critical infrastructure asset owners will continue to meet evolving business requirements by integrating control systems with business, peer, and Internet networks. This interconnectivity between historically disparate networking enclaves creates attack vectors and vulnerabilities that were previously nonexistent — both of which could be exploited by an attacker to cause undesirable consequences.

The root cause of cybersecurity factors in ICS is based on both cultural and technological issues, each of which require new strategies to address.

Information pertaining to control system vulnerabilities continues to grow, as does the number of reported ICS cyber incidents and occurrences of malware targeting ICS.

ICS owners should evaluate the risk associated with a specific attack based on a specific vulnerability. This allows owners to make more informed decisions regarding the security investments that need to be made in order to prevent undesired consequences. It also provides owners with quantifiable information that can be used to ensure the implementation of a countermeasure does not have an adverse effect on the control system.