Comments on Langner post: "ICS-CERT on Beresford Vulns: Flawed Analysis, Misleading Advice"

On August 20, 2011, Ralph Langner posted a very insightful blog on the recent security work of NSS Labs' Dillon Beresford (Twitter @D1N) and the report that ICS-CERT released regarding this research. This was a very well written article, which I have to say I agree with most of the document. In particular, I am a bit disappointed in how ICS-CERT is handling these reports in general especially in the way of offering sound, practical, ICS-based guidance on dealing with these threats.

There are a couple of points that Ralph mentions that I feel deserve mention that would require more than 140 characters in a tweet to discuss!

First, I do not agree with Ralph's criticism of the ICS-CERT mitigation that states "Monitor traffic on the ISO-TSAP protocol, Port 102/TCP.” Ralph seems to think that this needs to involve deep-packet inspection (DPI) between established ICS connections. I did not interpret this requirement in this fashion, but rather, since replay attacks or other attacks that could exploit Dillon's vulns tend to be "remote attacks", that it is very important to monitor ANY TRAFFIC between UNAUTHORIZED NODES that utilize 102/tcp.

I recently presented a proof of concept paper on some research I have been evaluating in how a scaled down version of a traditional intrusion detection system (IDS) can be used to analyze network behavior and generate alerts when communication occurs between unknown or unauthorized hosts. I encourage you all to take a look at this presentation or webcast to learn more. I have submitted this abstract to ICSJWG as a potential topic to be discussed at the upcoming Fall 2011 Conference in Long Beach.

The net result is that a great deal of valuable information can be disclosed by looking for "unusual" traffic on 102/tcp. I especially want you to look at how I recommend rule generation, as I believe it is equally important to identify an "attempt on 102/tcp" as an "attack in progress on 102/tcp". This is where my strategy differs from the standard set of QuickDraw SCADA IDS signatures provided by DigitalBond, and why I look at not only established connections, but also attempted connections in the way of SYN packets destined for 102/tcp.

As many of my followers know, I am a big supporter of the implementation of both IDS and network access control (NAC) technologies within the control systems networks. Ralph's final paragraph talks about the risks associated with contractor or what I like to call "non-company" access to trusted control networks. Ralph is particularly conscience of the potential for these contractors to introduce malware due to infected hosts.

This problem is specifically addressed with NAC, and is why I am such a proponent of its use not only in local network access, but also as an additional layer of protection to standard virtual private networks (VPN) used when access trusted networks remotely. The strength of the NAC approach is that not only does it properly identify, authenticate and authorize hosts, but it also performs a "health assessment" which can be used to make sure that certain security features are active on the host prior to granting logical access to the network. This can include the implementation of security patches/hotfixes, current anti-virus software and associated signature files, and the use of host-based firewalls. NAC is available from the usual lineup of vendors, including Microsoft, Cisco, and my personal favorite - Enterasys.

I am going to be talking with Dale Peterson at DigitalBond this week about NAC and why I believe that it is one of the key features in helping to mitigate the growing risk of cyber attacks against control systems. I will provide an update once this podcast is available.