Malfunction or cyber attack – the impact is the same and it may not be possible to know the difference

Fairuz Rafique from Galactic Security had a Linked-In note concerning a March 2018 “malfunction” in the ski lift system in the Gudauri Ski Resort in the Republic of Georgia. The lift system event injured 12 people. Officials claimed it was an equipment malfunction. According to Fairuz, the same day of the malfunction, researchers found the lift vendor’s control systems exposed on the Internet. Consequently, Fairuz asked if this was a malfunction or a cyber attack. I responded that it doesn’t matter. My response elicited a number of other responses, pro and con, including from an insurance company saying it matters to them as context is everything.

There are a number of issues at play:

- From the NIST Glossary, the definition of a cyber incident is “an occurrence that actually or potentially jeopardizes the confidentiality, integrity, or availability of an information system or the information the system processes, stores, or transmits or that constitutes a violation or imminent threat of violation of security policies, security procedures, or acceptable use policies.” The word “malicious” is NOT mentioned. In this case, the availability of the ski lift was lost due to the control systems – a cyber incident, malicious or not. The NIST definition is really an IT definition because safety is not addressed yet that is the concern in this case.

- Often, including in this case, the impact is the same whether it was a system malfunction (unintentional cyber incident) or a cyber attack. The 2008 Florida outage that blacked out about half the state of Florida for 8 hours originated from actions by an engineer in a substation. As the engineer’s actions did not involve network issues, there were no cyber forensics. The only difference between this event being an unintentional cyber incident versus a malicious attack was the motivation of the engineer – “I’m mad” or “oops”. Moreover, a sophisticated attacker can make a cyber attack appear to be a malfunction - Stuxnet. As mentioned earlier, this could have major significance to insurance companies if you can’t tell the difference between a malfunction and a cyber attack.

- In IT systems with significant cyber forensics, the time before a cyber intrusion is identified can be on the order of hundreds of days. Generally, there are minimal, if any, cyber forensics and cyber training for the engineers at the control system layer. Consequently, an incident may not be identified as a cyber attack despite potential physical damage and injuries. As mentioned in https://www.controlglobal.com/blogs/unfettered/russia-has-compromised-the-us-grid-this-year, cyber intruders were in a US electric utility for more than 7 months before they were detected. This is important because most cyber security requirements and regulations such as NERC CIP for electric utilities and NEI-0809 for nuclear plants ASSUME that cyber attacks will be expeditiously identified which may not be possible.

- These discussions also lay bare the culture gap between the network organizations (IT/OT) and the engineering/safety organizations.

It is important to do a root cause analysis of the “malfunction”. The root cause team should include representatives from engineering as well as network security. It doesn’t matter if the incident was malicious (physical or cyber) or unintentional as long as the malfunction can be identified to prevent the event from recurring.

Joe Weiss

Show Comments
Hide Comments

Join the discussion

We welcome your thoughtful comments.
All comments will display your user name.

Want to participate in the discussion?

Register for free

Log in for complete access.

Comments

  • While, I agree that root cause analysis is critical, I disagree with the premise that cause does not matter. Further, I disagree with the idea that the impacts are the same. The amount of time and resources required to mitigate the issues are vastly different. If the incident is an accident, or mis-configuration the level of effort to rectify the situation is much lower than an incident that is malicious. An accident, or mis-configuration may require some additional safeguards, a new policy, set of procedures, and some retraining. However, the technical mitigation actions are likely to be somewhat localized. A malicious incident on the other hand may require a deep forensic analysis of the entire enterprise because, you must identify all the potential points of access which have been used or newly created. Additionally, you must compare the systems current state to the baseline. By understanding the threat (capability + intent) be they malicious insider or remote actor we can determine how far we need to carry our mitigation efforts. Is this actor capable of corrupting firmware, or were they just exploiting a publicly disclosed vulnerability? Is the intent to continue to do us harm or was this a one-time action. Do we need to keep an eye on this person or group to see if their capability’s and intents evolve? The technical and other resources required to properly address malicious incidents are vastly different than those of accidents. Darin Harris

    Reply

RSS feed for comments on this page | RSS feed for all comments