Story of Petya ransomware was starting to calm down already after making rounds during last week. Now, however, it seems that the story isn’t over yet. In the slipstream of Petya infections in Ukraine, a new ransomware dubbed FakeCry is now spreading. The new ransomware seems to spread from the same MeDoc service which was suggested as one of the initial sources of infections for Petya.
CrashOverride – a threat to electricity networks?
July 11, 2017 at 10:30
The latest analyses of malware targeting automation systems, published in early June, are yet another reminder of the ability of such online threats to cause physical damage. While it is not new, this malware known as CrashOverride or Industroyer, has remained relatively unknown to the general public. It is thought to have made its debut in a cyber attack against a power grid in Ukraine in December 2016, causing an outage in Kiev lasting about an hour. In terms of significance and scope, this attack was more limited than the notorious cyber attack that took place in 2015 and left more than 225,000 Ukrainians without electricity for six hours. However, what makes this latest incident particularly worrying is the likelihood that it was merely a dry run carried out to test the malware’s capacity to create havoc.
The reason why CrashOverride has received less media attention than the WannaCry and Petya ransomware is that the 2016 incident is the only successful sabotage attempt attributed to the malware. It is the first-ever known case of malicious code purpose-built to disrupt power networks. The severity of the threat and the careful planning behind it are apparent in the malware’s modular framework, which consists on several modules targeting protocols typically found in electric power grids, such as IEC101, IEC104, and IEC61850. Therefore, the malware has the capability to control a power grid’s switches, which makes it particularly dangerous. Thanks to its high degree of adaptability, the malware can be used in an attack against any industrial automation environment. The U.S.-based cyber security company Dragos has published an extensive report on the malware: https://dragos.com/blog/crashoverride/CrashOverride-01.pdf
How to protect yourself against such malware and prepare for production outages caused by them?
- Restrict network traffic
External connections to the control network should be kept to a minimum, and unidirectional network connections should be built wherever two-way connections are not required. Remote access should be monitored and permanent connections should be avoided, with connections only created for specific tasks and closed once the task has been completed. Traffic in the internal network should be restricted so that only the systems that are required to communicate with each other are allowed to do so.
- Identify devices in production use
Create a whitelist of devices used for production purposes so that when an unknown device is detected it gives rise to an information security deviation alarm. All devices should be configured in a secure manner to ensure that no unnecessary connections are open and that the devices do not offer external services that are not necessary for the operations.
- Step up security monitoring
Ensure that monitoring covers points where traffic crosses from one network to another (e.g. control network, DMZ, company LAN, Internet). An alarm should be raised as soon as suspicious traffic is detected, for example when a control network device begins to communicate with the public Internet or an unknown device appears in the network. Whenever possible, any changes, such as new software versions and changes in the configuration or the network, should be monitored by technological means. For the monitoring to be efficient, all the devices, software and networks in the environment must be well-known and any changes to them must be carried out systematically.
- Always make backups
You should have such extensive backup copies of your environment that, if necessary, they can be used to restore a functioning system. Backup copies should be made of servers, workstations, and approved configurations and settings, when possible. The backup copies should be tested regularly to ensure that they function properly. Note that backups won’t be of any help if physical damage has already occurred.
- Act according to a plan if an incident occurs
To ensure the continuation of operations, it is pivotal that the facility has an action plan in place to facilitate a response to a disruption in the normal operations of the production environment due to malware or any other information security problem. This plan should cover responsibilities and tasks required to limit the damages arising from the problem and to ensure rapid restoration of normal operations. During an incident, external connections may be restricted while monitoring of critical changes should be stepped up.
In addition to CrashOverride, these guidelines apply to all the other malware too. The main thing is to realize that forward planning and meticulous preparations help to minimize damages caused by any incidents.