Our current standard of living is made possible due to the massive scale of critical infrastructure that supports our needs as a society. Electricity, Oil, Gas, Water, and Security are a few of the well-known industries whose infrastructure is managed by Industrial Control Systems (ICS). Few systems have the potential for catastrophic consequences from a security incident as is possible with an ICS breach.
The term “nation-state actor” is commonly used to describe the most sophisticated adversaries, typically state-sponsored intelligence agencies who primarily operate to further the interests of a government. ICS has shown to be a primary strategic target of intelligence agencies with several past incidents demonstrating active operations against critical infrastructure. The ability for a nation to directly impact the critical infrastructure of another while maintaining plausible deniability through a well-orchestrated cyber operation is a powerful diplomatic tool. Unfortunately, in many cases, the security of ICS relies on outdated technology and obsolete security practices, leaving them vulnerable to the most dangerous threat actors in the world.
ICS has several unique attack vectors that the standard IT environment has evolved past, largely centered on the protocols used by Programmable Logic Controllers (PLC) and Remote Terminal Units (RTU) to communicate with Human Machine Interfaces (HMI). Many common ICS protocols do not implement authentication or encryption, allowing an attacker to send commands to these devices once they have achieved a foothold on to the network. Many ICS protocols were defined in the ‘70s and ‘80s, with the pretext that they would be used in closed networks and that any traffic would be legitimate.
As networking evolved in general, enterprise networks crept into closed ICS environments eliminating the “air-gap” that may have existed at one time. The exploitable attack surface to gain entry into an ICS environment is constantly growing, and once penetrated, the amount of damage that can be caused is significant.
In addition to weak protocols, the equipment in some cases can remain vulnerable for years depending on the practices of a given company. The high cost and long lifetime of many ICS devices make replacement infeasible, leading to persistent vulnerabilities if patching isn’t conducted regularly.
Depending on the motivations of the adversary, attacks against ICS are typically designed to disrupt or degrade service. The impact to a company can range from financial loss to loss of life depending on what is specifically targeted in a network. The famous example of a cyber attack against an ICS environment is STUXNET, where Iranian centrifuges were targeted with the intent of degrading productivity. Many attack scenarios exist that can have second and third order effects on an ICS network without necessarily targeting the “crown jewels” of a company’s infrastructure.
A commonly overlooked ICS attack surface is building facility infrastructure (HVAC, Elevators, Hot/Cold Water, Air filtration, access controls). Example attack scenarios could be falsifying the values returned from an air filtration system to reflect non-contaminated air when in fact it is, overpressurizing a boiler causing flooding in an oil processing facility rather then attacking the oil processing equipment directly is another example.
Critical infrastructure typically has built-in fail-safe mechanisms that will trigger under certain conditions. Often times triggering a fail-safe is enough to temporarily disrupt service, and at a minimum cause a financial loss to a company. Many times this can be as simple as sending an unauthenticated packet to an HMI with a sensor reading outside of a safety threshold, triggering an automated shutdown response.
The practice of moving security to the perimeter is no longer sufficient to protect these critical environments. Assuming a breach will happen and proactively putting process in place to detect, contain, and evict an adversary can enable a company to recover quickly without loss of service.
Download: Industrial IoT Security Maturity Model (SMM) Practitioner’s Guide
We are contributors to the Industrial Internal Consortium SMM Practitioner’s Guide, which provides detailed and actionable guidance for industrial IoT stakeholders to assess current security state, set appropriate security targets, regularly measure against them and prioritize investments accordingly. Learn more →
ICS Security Assessment Overview
Conducting a security assessment of an ICS environment requires a number of special considerations typically not present in a standard enterprise network penetration test. The typical “Red Team” exercise consists of gaining access to a corporate network, usually through some form of social-engineering or vulnerable external asset. Once a foothold is achieved, engineers will attempt some form of lateral movement in the environment and subsequent privilege escalation to get to a point where they can reach a predefined objective in the network. These types of engagements usually have relatively low risk of causing impact to the company in the event an internal asset is negatively affected. For example, if a Red Team operator accidentally takes down a server, a typical recovery time is measured in hours and minimal financial loss to the company is accrued.
In contrast, a miscalculation during an ICS assessment can lead to physical damage of equipment and facilities causing major financial impact to a company. Black Box assessments of ICS environments are highly discouraged due to the risk involved. The planning and execution of an ICS assessment requires close collaboration between the security engineers, and the ICS engineers of the company under test. An ICS assessment should be broken into three discrete phases as described below.
Phase 1: Threat Modeling Corporate and ICS Networks
Phase 1 should be a threat model of the corporate and ICS networks to review the security controls that were implemented, specifically to separate the enterprise from the ICS environment. This phase should take roughly a week and involve providing the security engineers with network diagrams, firewall rules, and any other pertinent information for review. The security engineers will conduct multiple interviews with corporate IT personnel to identify any potential attack vectors into the ICS environment from the corporate network. Collection of information regarding ICS protocols, equipment vendors, and any security applications that are in use will be critical for successfully executing phase 3.
Phase 2: Identify Attack Chains to Gain Foothold
Phase 2 consists of two parts, both with the goal of gaining access to the ICS environment. Security engineers will conduct an internal assessment from the corporate network with the intent of bypassing any security controls that were identified in the threat model to gain a foothold in the ICS network. The second part involves a physical penetration test of any remote sites that have connectivity into an ICS network. Remote sites are typically overlooked in security planning and sometimes, insufficiently secured from physical intrusion. The objective of phase 2 is to identify attack chains that lead to a foothold into the ICS network.
Phase 3: Coordinate Exploitation Safely to Demonstrate Risk
Phase 3 begins once a foothold is established into the ICS network with the goal of identifying attack vectors to disrupt and degrade service of the customer. This phase of the assessment requires the most coordination with the customer to prevent unintended effects on ICS infrastructure. The ideal testing environment involves a security engineer on site, sitting side by side with ICS engineers who can approve any operational activity on the network to prevent disrupting service. A customer ICS engineer should be able to approve/disapprove methods of scanning, attempted exploits of specific devices, and identify if a target device is critical. Once a potential attack vector is identified, the customer ICS engineer will decide if the security engineer can proceed with the exploit.
Additional Considerations
A number of attack vectors will be considered in phase 3 by the security engineer once ICS network reconnaissance is complete. Authentication between the PLCs and HMI will be assessed to determine if an engineer can send commands to controllers, possibly actuating motors, pumps, compressors, etc. as well as attempting to send false sensor readings to the HMI. Should the security engineer successfully send false readings to the HMI, the customer ICS engineer can identify the impact and course of action that would follow.
The threat model phase should include the ICS equipment models and versions to assist security engineers in phase 3 to determine if equipment vulnerabilities are available for exploitation. If a device is identified as vulnerable but risk is deemed too high to attempt exploitation, a similar device in a test environment is acceptable to demonstrate the attack. Once vulnerable devices are identified, determining all instances of them in an ICS network is critical for remediation.
Denial-of-service attacks within an ICS network are especially dangerous due to the need for near real-time sensor readings in many environments. A few methods exist for dropping or degrading PLC to HMI communication. Especially in networks using TCP-based protocols, classic networking attacks like ARP poisoning can disrupt communications. Testing the effect of network based denial-of-service attacks should not be done in a production environment due to risk of unintended effects, but should be identified due to their simplicity to execute.
The authentication of engineers to the HMIs and control servers should be assessed to determine how difficult it would be for an attacker to access privileged functionality should they establish a foothold in the ICS network. This can involve classic IT penetration testing methods to exploit identity management services. Over privileged engineers or default credentials on any of the ICS control servers can lead to a quick compromise of the network and should be evaluated early in phase 3.
The conclusion of the assessment culminates with a report detailing any vulnerabilities that were discovered and possible attack chains that could be leveraged to disrupt the company. Due to the collaborative nature of the assessment and heavy involvement of the customer ICS engineers, the findings are well-known and understood by the time the report is delivered. The report should provide a well documented means to help develop a roadmap for remediation and enhance the overall security posture of the customer.
Learn how Praetorian helps secure ICS environments to improve the safety, reliability, privacy, and resiliency of industrial controls in today’s hyperconnected world: Learn more →
