Submitted by: Steve Mustard President & CEO at National Automation, Inc. and (CS)²AI Fellow
May 16, 2021
REGISTER HERE FOR OUR SPECIAL INCIDENT DEBRIEF THURSDAY,
MAY 20 @11:30AM - 1:00PM EST
If your incident response plan for recovering from a ransomware attack is to pay the ransom, you need to rethink your plan. Reporting indicates that Colonial Pipeline did just this, and still ended up recovering their billing system from backups.
Some voices in the ICS security community have pointed out that Colonial Pipeline’s ransomware incident involved IT, and not ICS equipment. While this is true, in a critical infrastructure organization this distinction is surely meaningless. The IT and ICS equipment is there to provide a series of services that allow the company to operate and impacting any equipment to the point where operations are shutdown has serious implications for the nation. In this case, panic buying and gas shortages across the southeast of the country, and the potential for interruption of critical services, such as airports, that are dependent upon fuel supply.
Whenever there is an attack on a critical infrastructure organization, we in the ICS security community should be concerned. We should also help organizations like Colonial Pipeline learn from such incidents to improve their response plans for all scenarios, IT and ICS.
Will this incident trigger some long-awaited action from critical infrastructure operators to improve their security posture? Back in 2005 I organized a conference in the UK on security of distributed control systems and said “Process automation systems are key to the organizations behind the UK’s Critical National Infrastructure (CNI) as they both monitor and control critical processes involved in the production and transportation of gas, electricity and water. As these systems become more ‘open’ – using Ethernet, TCP/IP and web technologies – they become vulnerable to the same threats that exist for normal IT systems”. Sixteen years later we are still saying the same thing, but given the fact that incidents like Colonial Pipeline, Oldsmar, Ellsworth, and others continue to happen, it appears we are still not adequately addressing this problem.
It is unfair to say that all critical infrastructure operators have the same security posture. Many operators are taking action, but the type of incidents we see indicate that we still collectively have a long way to go.
As cyber incidents like Oldsmar, Ellsworth, and Colonial Pipeline continue to make the news, along with non-cyber incidents like the Texas freeze, there will be increasing pressure on the government to take action. Regulations already exist in some sectors, notably electricity and chemical. Views vary on the effectiveness of the regulatory approach. Many see the approach as a check-box exercise, and even the threat of fines for non-compliance does not deter some operators – Duke Energy was fined $10M in 2019 for 127 violations of NERC CIP, many of which were easily actionable, such as providing awareness training to employees.
Reporting indicates that Colonial Pipeline’s did have cyber insurance with $15M cover. Although there is no confirmed reporting that their insurer did pay, it is likely. Perhaps this is one reason why some critical infrastructure operators are not making more effort to reduce their risk. This form of risk transfer may, on the surface, seem effective: Colonial Pipeline may have incurred little or no financial loss as a result of this incident, depending on what the insurance policy covered.
This raises the question of how long insurers will be prepared to support this transfer of risk within the current parameters. Perhaps policies will become prohibitively expensive, or even not offered, to operators who cannot demonstrate a basic level of cybersecurity preparedness, such as a good incident response plan supported by regular validation exercises.
While there may not be regulations for all critical infrastructure sectors, there are international standards that can be used to define the reasonable expectations of an operator. The ISA/IEC62443 standard, security for industrial automation and control systems, defines the requirements for a cybersecurity management system needed to manage cybersecurity risk in critical infrastructure organizations that depend on ICS equipment. Some sectors already base their internal policies on this standard, but it is clear that it is far from universal across all sixteen sectors in the US.
Some may say that the likelihood of a cybersecurity incident in an ICS environment is vanishingly small. Even if this is true, the consequences of such an incident are extremely serious, and high impact, low probability events must be properly managed – they cannot be dismissed simply because they have either never happened or seem unlikely. In many cases, even moderate expectations such as the application of basic cyber hygiene are not being met in our critical infrastructure operations. We are long past the point where this is acceptable.