By Robert Albach
What are the security boundaries of your systems? How much control do you really have?
These are the questions a good number of pipeline, electric utilities and more found themselves asking this April when a small but critical data exchange company in Dallas was attacked.
Pipeline customers found themselves unable to respond in a timely manner to service requests they traditionally had. Fortunately, nobody was in imminent danger – the physical pipeline was fine and under control (despite some misleading headlines to the contrary). But the bottom line was energy providers and customers could not coordinate their needs well and others could only “estimate” what customers owed them.
As we work to improve efficiency and eke out that extra 0.5 percent cost reduction or top line contribution, you have to consider what that might mean to the boundaries of your threat/risk model. A quick review of the SEC mandated 10-Q for one of the publicly traded pipeline companies impacted finds a mention of “risk” 81 times. None of those were found to relate to any problematic cyber incidents however.
The U.S. Security Exchange Commission gave the following guidance less than two months earlier: “it is critical that public companies take all required actions to inform investors about material cybersecurity risks and incidents in a timely fashion, including those companies that are subject to material cybersecurity risks but may not yet have been the target of a cyber-attack.” The good news is at least one of those effected entities managed to list cyber attacks as a risk. It was the last of 25 different items named.
So, there is part of the answer to the opening question regarding security boundaries: Any reliance on a system that makes you subject to material cybersecurity risk. Not just breached, but at risk.
But let’s expand because yes there was a hack of a small acquisition by a larger company that provided services to critical pipelines – but what about those pipeline customers? And might any other groups have been impacted? In this case, there were electric utilities in play and one of them, Duke Energy, acted very swiftly by cutting ties with the attacked company. Might the long-term application of NERC CIP mandated security standards contributed to the speed of reaction? Such a rapid response would certainly make sense for an organization that participates in regular security exercises whose scope extends beyond the most distant meter.
What can you do to be as ready to act as quickly and decisively as Duke? Let’s assume their actions were not a random knee jerk reaction but part of a previously defined plan. The kind of plan assembled through a “tabletop” exercise with appropriately scoped “what if” scenarios of which this incident type should be included. The result is an appropriate “run-book” of response plans to an incident.
For some industries these are required activities, some of which will relate directly to the operation of your ICS/DCS/SCADA dependent system. But look further than your pumps, gateways, and storage sites. It might be good to revisit prior exercises and decide if your scope was broad enough to include third party brokers. If not then it is time to update those exercises.
Another recommendation relates to any and all contracts your organization enters into with third parties whose interoperation can impact your operation and security. First, review those contracts for statements of cyber security obligations, responsibilities, and liabilities. Second, get in front of ongoing/pending contracts – ensure there are clear obligations and remediation plans to properly secure your data and operational readiness. But don’t stop there. Consider the concept of “flow down” contractual conditions that apply to subcontractors and subsidiaries.
A good guide is in DFARS clause 252.204-7012. And there should be no exceptions – after all – the largest fine levied as a security failure in the U.S. Grid this year was because a security firm contracted to test a utilities defenses was found to have themselves been insecure with sensitive information. Forewarned is forearmed.
Robert Albach is senior product manager for industrial security at Cisco.