Malware, Viruses, and Attackers hopping networks
Many of us in the Control System community feel pretty secure in the belief that our critical networks are not directly connected to the internet, and as such are insulated from attack. Apparently (and as oft has been stated) this is not sufficient protection, if the control systems communicates with a network that does have internet access. According to a recent article the Conficker virus was savvy enough to hop from one internet connected network segment into critical medical equipment on a non internet connected segment via an interconnect.
In Control Systems this would be comparable to the Control System and its various segments being connected to an internet connected corporate environment. In this type of common scenario, where proper protections are not in place a clever virus could possibly hop segments (as in the article) and a good attacker definitely could, leading to a compromised process.
Proper firewalling would reduce the risk of this type of cross infection but the ideal solution would be to limit the connectivity to an individual machine hanging on a DMZ attached to the firewall. The firewall should only permit that communication that is absolutely essential to operations form the Control System to the DMZ system, and from the DMZ system to the corporate environment. The first rule in the firewall should be “deny all” with only one or two exceptions for the necessary communications, usually a pathway for a historian slave.
By the proper application of security techniques the possibility of a viruses or attacker hopping segment can be greatly reduced, in turn mitigating risk. These techniques would limit the cross infection of systems as occurred to the critical medical devices as in the referred article.
Author: Kevin Lackey
Posted: April 24th, 2009 under Firewall / Perimeter, SCADA Architecture.
Comments: 2
Comments
Comment from Chris Ensey
Time: April 24, 2009, 5:53 pm
I think this post properly lends credence to the protections you would expect to satisfy most TCP/IP or proprietary based interfaces for control systems. Block all, allow only trusted. One area that people still seem to forget is that most of these systems be them SCADA or just services are mostly fronted by Web interfaces (hopefully over SSL, and on other ports than 80/443) which are rarely updated for security issues like SQL inject / XSS etc. Once this trusted channel is compromised that firewall investment is completely rendered ineffective since that attacker owns the channel. They have trusted path to the infrastructure. Boutique or targeted attacks would potentially be more catastrophic in this case. I can see this being overlooked in most security configurations unless case studies or standards and control board put policy in place.
Comment from Ralph Langner
Time: April 26, 2009, 1:45 pm
There is one point that I like very much about Kevin’s post: It does not refer to TRUSTED systems. Instead, it refers to NECESSARY COMMUNICATION. Those two items can differ vastly from another, and they often do in control system environments. For example, we see an engineering notebook from a very much trusted person, which carries malware into the PCN. If it is then determined that this notebook had actually no business connecting to some systems that were then infected, the question of which traffic is necessary gets THE guideline for ACL definition. If we acknowledge the fact that most malware enters PCNs not via direct Internet connection but via a remote access link from a contractor or via notebooks that are legitimately connected to the PCN, the concept of trusted users and systems shows its limitations.
Write a comment