SecurityWeek has reached out to several companies that offer products and solutions designed for protecting industrial control systems (ICS) against cyber threats and asked their experts to share some interesting stories from the field.
The stories they have shared not only make for a good read, but they can also provide useful information and insight for practitioners.
And the stories begin…
Kaspersky Lab ICS CERT team:
#1 “Industrial enterprises often expand their business by acquiring facilities from other owners. This can create a heterogeneous infrastructure that is often difficult to maintain, manage and secure. While performing a cybersecurity assessment of a food and beverage facility in Europe, Kaspersky Lab ICS CERT experts noticed that, in addition to the plant’s office network being accessible from its ICS (and vice versa), so were the networks of dozens of other facilities in other parts of the world, from the Far East to North America, including some that had been sold to a competitor and no longer belonged to that company. The most surprising finding was that the ICS network was also accessible from a terminal in the plant’s canteen, which was located outside the plant’s perimeter and offered breakfast and lunch to outside visitors.”
#2 “Another case in which Kaspersky Lab ICS CERT experts encountered an industrial network security problem, was an industrial facility that was part of a large industrial group. While penetration testing the plant’s network, experts found that the internal processing systems of a bank, belonging to a different owner, were accessible from the plant’s ICS. It turned out that the group had had a banking structure of its own, which it had sold to a national-level bank at some point. However, the change in ownership was not followed up by the relevant and proper changes to IT connectivity and security. As a result of this, the large bank’s internal systems could be accessed from the plant’s network (and vice versa).”
#3 “Vulnerable communication channels connecting enterprises to their remote facilities pose another major threat. Instead of using and maintaining their own channels, many enterprises use channels offered by telecommunication service providers. A good example of this was provided by the management of a power distribution enterprise. They had identified a fault in the operation of an auxiliary data channel between two substations belonging to the enterprise. The channel was used to synchronize the substations’ operation in some complicated situations. When attempting to identify the reasons for the loss of communication between two facilities in the power infrastructure of a large city, the telecom operator’s specialists assigned to the case found that the source of the problem was a router that was physically located in a high-rise residential building. In the process of building a wide-area data transmission network, the telecom operator had acquired the networks of smaller providers serving some of the city’s residential areas. It is obvious that ensuring the necessary information security level in this kind of legacy infrastructure is virtually impossible.”
Mille Gandelsman, CTO, Indegy:
“While performing an audit of a manufacturing facility that uses hazardous materials, a regulator conducted a physical inspection of the operational systems and compared the findings with an inventory list provided by the plant operator. All of the facility’s ICS (industrial control system) devices were from a well known, tier-1 provider, except for one PLC (programmable logic controller) which was from an obscure supplier and was not on the inventory list.
When the regulator asked about the rogue device, he was told “Oh, yes, this is not on the list. It was purchased because one customer asked us to use this specific PLC to produce their products so their engineers can connect remotely and modify its configurations”. This solitary, undocumented PLC had been capable of breaching the security of the operational network and the entire plant. It was replaced per the recommendation in the regulator’s report.”
Hear More Interesting Stories at SecurityWeek’s ICS Cyber Security Conference
Paul Smith, director, product research and strategy, Nozomi Networks:
“The main priority for operators in the midstream oil and gas industry is to keep their product flowing through pipelines in a secure and safe manner. It is also critical that operators have visibility to mitigate any cybersecurity issues and detect any potential outages which could have an impact on their services. When visibility into what is really happening is reduced, significant problems and costs can arise.
This is unfortunately what happened with a major pipeline organization when a PLC went down and caused the company $1.9 million in lost revenue and downtime.
In this case, the problem with the PLC was that it suffered from “ghost drift”. This is when a device slowly and quietly slips out of scope over such a long period time that no one ever notices. When the PLC started to fail, it skewed the numbers ever so slightly that it was not noticeable, and it was only once the real damage was done that the problem was finally spotted.
This scenario highlights the importance of operators of critical infrastructure deploying solutions which have the capability to detect when devices start to drift or operate incorrectly. Today’s ICS network monitoring solutions alert the operator that it’s time to take a closer look before another unplanned downtime incident wracks up a $1.9 million loss. These solutions help oil and gas operators around the world see and secure their critical industrial control networks and provide real-time visibility to manage cyber risk and improve resilience within these environments.”
Yehonatan Kfir, CTO, Radiflow:
“We certainly have encountered a number of interesting incidents over the past year.
The first incident that stands out happened at an ICS operator. This particular operator maintains a very good security practice for its network with highly developed security policies. However, one of the network administrators temporarily connected a router with known vulnerabilities to the Internet for maintenance purposes. This network administrator configured the main firewall to limit the access from the Internet to a specific PC. Unfortunately, the network connectivity of the router to one of the SCADA switches was incorrect and it resulted in it accidentally opening a highly vulnerable, new attack vector to this switch and from it to the entire ICS network!
In this incident, our industrial IDS system protecting this ICS network immediately detected this new routing path. Shortly after, our system quickly identified multiple servers across the Internet that were trying to scan the operator’s network. The purpose of this scan was to look for open ports and open services in the accessible devices and to identify vulnerabilities within those services.
Furthermore, within a few hours these attackers were able to identify the industrial nature of some of the devices and immediately attempted to exploit embedded vulnerabilities in the OS used by this router device.
The second incident that comes to mind relates to a policy violation on another well secured and monitored network. In this case, the operator also has strict security policies in place, including policies for patching, monitoring, remote access and so on. Many of those policies were automatically self-learned by our IDS solution. After a few months, our system alerted to a TeamViewer communication in the network, which is defined by the operator as a known policy violation. Apparently, one of the third party subcontractors working in this facility installed a TeamViewer application on one of the PCs to ease their remote operations. As the software tried to communicate, our IDS system quickly detected it and alerted on this policy violation. After this incident, the customer requested to add prevention capabilities to our solution, which of course we did, in order to prevent any sessions of such remote access tools.
Both these incidents demonstrate that even with strict security policies in place, it is still important to monitor policies at all times: mistakes can happen as well as intentional violations. In the first incident, we can see how quickly a simple configuration mistake can be leveraged into an exploit and a penetration method if undetected. In the second case, we see how important it is to have a flexible solution that can start with detection only and upgraded to provide prevention as well.”
Chris Sistrunk, Principal Consultant, FireEye:
“A plant (not big enough to be under NERC CIP) had a very old switch on their DCS network fail while we were onsite – not caused by us or them. The switch power supply simply failed and they didn’t have a spare. The plant could still run on the redundant switch, but if that switch also failed, the plant would be forced to shut down.
Because the switch was very old, they ad to buy one off of eBay and have it ‘hotshotted’ (shipped) overnight. Further, the client didn’t have critical spare equipment or a plan to upgrade out-of-support critical equipment.
They had a small team of three ICS security personnel, that operated more as ‘firefighters’, making it impossible to get ahead of the constant problems they faced. We were reviewing the main firewall configuration that protected their ICS and we discovered numerous ANY-ANY rules (which is a huge hole in the firewall). They had a written policy that forbid ANY-ANY rules and they thought that they didn’t have any. One of the security team members got up immediately and deleted the ANY-ANY rules from the firewall.”
