We thought we should take a closer look at ICS-CERT’s publications on the Beresford vulns. The result is, well, disturbing. The following relates to ICSA-11-223-01, dated August 11, 2011. All paragraphs in italics are quotes from the advisory. (Long post, grab a cup of coffee before starting to read the details, and be ready to read through additional referenced technical documents.)

A. Flawed vulnerability analysis

The advisory makes multiple references to the ISO-TSAP protocol, as in the following example, suggesting that the design decision to use this standardized, interoperable protocol was a root cause for vulnerabilities.

“Because of the design decisions made in control system industry in the past to foster inoperability (sic), it will not be possible to provide near-term patches for all the reported issues.”

While vulnerabilities may in fact lead to inoperability, we assume that this is just a typo in a document that seems to be created in a rush. Anyhow the way ISO-TSAP is used by Siemens is not interoperable at all. By excusing vulnerabilities with the use of a standardized, interoperable protocol, ICS-CERT in essence indicates that they did not fully understand either the protocol stack or the vulnerabilities.

 “ISO-TSAP was not designed to be a secure protocol and is open to analysis. A PLC, its supporting engineering workstation software, and other tools are required to conduct this analysis.”

Anybody who wants to analyze ISO-TSAP doesn’t need a PLC, but only the protocol specification, which can be downloaded from the Internet. It’s the transport layer that Siemens uses on Ethernet. The application layer that Siemens uses on top of ISO-TSAP is usually referred to as the S7 protocol. It’s proprietary, and its specification is kept confidential by Siemens. It’s not open, and it’s not interoperable. It has nothing to do with ISO-TSAP and actually is used identically by Siemens on other transports as well (MPI, Profibus). Anyhow to analyze the application layer not much Wireshark time is required either. Any attacker worth his salt would start out with Libnodave, an open source protocol implementation.

“If the PLC is not configured with password protection, any command that can be sent from the engineering workstation can be captured, modified, and replayed to the PLC.”

This statement is actually nonsensical because while true, the opposite is also true: “If the PLC is configured with password protection, any command that can be sent from the engineering workstation can be captured, modified, and replayed to the PLC.” ICS-CERT completely misses the point made by Dillon Beresford — that Siemens’ password protection really is much less of a protection than advertised. Anybody who intercepts the communication between a PLC and an engineering workstation, either by tapping network traffic or by using libpcap on the engineering station will be able to capture, modify and replay commands, no matter if the connection is password-protected or not. The authors of the ICS-CERT advisory seem to assume that password protection would mean encryption, which it does not. The only data item that is encrypted for a password-protected connection is the password itself. An attacker could now brute-force the captured password (the password encryption algorithm in Simatic Manager can be cracked easily) in order to obtain the clear-text version that might be used to understand the victim’s password schematic, or he could simply re-use the encrypted password to send arbitrary commands to the PLC. It is also important to understand that the S7 project password protects only a subset of available commands anyway; manipulating data blocks (translate: variables), timers, counters, and markers never requires authentication/authorization. An attacker who manipulates any of these memory areas (no insider knowledge required) will easily achieve more damage than by messing with the integrated web server or telnet server. For example, slight changes of counters and markers will usually de-sync actuators, and changes of data block content will usually affect recipes (translate: product quality).

“The ability to read and write PLC memory is allowed due to the design decision made to use ISO-TSAP, an inherently open protocol.”

“The ability to send commands to the PLC is allowed due to the design decision made to use ISO-TSAP, an inherently open protocol.”

“Although this is commonly referred to as a vulnerability, ICS-CERT does not see this as a vulnerability in the protocol itself because the protocol was never designed to provide security or obfuscation.”

ISO-TSAP (translate: RFC 1006), the standardized, interoperable transport layer protocol, has nothing to do with any of the security issues in question because it’s just the transport layer. It’s as secure or insecure as TCP or UDP. ICS-CERT’s assessment would be similar to blaming FTP’s vulnerabilities on the usage of TCP. The point is, most security issues come into play at the higher (application) level, or level 7 in ISO/OSI speak. The application-level protocol that a system designer uses on top of the transport layer can certainly be designed in a secure manner. Ironically, the application-level protocol implemented by Siemens (translate: S7 protocol) was actually designed with security in mind, which is implemented in the ability to make parts of the protocol functionality lockable by an eight-byte password. Certainly not a penetration tester’s dream, but at least a rusty nail that Siemens didn’t get tired to refer to over a course of two decades as a key item in their security philosophy, called “S7 protection levels”. As Dillon Beresford has demonstrated, the actual protection offered may be lower than Siemens and their customers expected.

B. Irrelevant, impractical and misleading mitigation advice

It shouldn’t surprise that any advice based on flawed analysis will hardly reflect the best, or even an appropriate, problem solution. Let’s look at some specifics.

 “Changes necessary to improve protocol security could negatively impact interoperability and performance.”

“Because of the design decisions made in control system industry in the past to foster inoperability, it will not be possible to provide near-term patches for all the reported issues.

Siemens has never put any effort on achieving interoperability of their PLC protocol — that’s a fact, not a criticism. The protocol in question (S7 protocol, not ISO-TSAP) is used by no other major vendor except Siemens. (We exclude the hand full of small vendors here that offer S7 compatible products here, such as VIPA.) Siemens even takes efforts to keep protocol details confidential as if they were some kind of trade secret like the Coke recipe. In order to mitigate the vulnerabilities addressed by the ICS-CERT advisory, one way would be to design and implement a reasonably secure protocol version that can then be made available for Siemens software and hardware products. Third-party IT products will hardly be affected as they can talk to the Siemens world through OPC, so the only component that needs to be updated is the OPC server (that’s one reason why OPC was invented in the first place). Again, any interoperability issues affect only the Siemens products and can therefore be handled because the vendor in question can supply software and firmware updates for all affected products. Besides, any discussion on security enhancements should consider that it really isn’t only about retrofits. A major problem right now is the several thousand new PLCs pouring on the plant floor every day that can either use the existing insecure design or an improved secure design. We are under the impression that some people are only concerned about the installed base when discussing technological change with its inevitable version conflicts, rather than addressing the problem of new installations that are commissioned each day and that will be here to stay for ten years or longer.

A secure protocol doesn’t need have to have any negative impact on performance, as every protocol designer knows. (Hint: Don’t assume that all online polling would have to be encrypted. There doesn’t even have to be online polling, as evidenced by Profinet’s provider/consumer architecture.) Implementing a more secure protocol version doesn’t require any architectural changes.

 “Configure and maintain user and administrative accounts using a strong account management policy.”

Even though not explicitly stated, this advice obviously relates to the Windows PCs in the automation network, as there is no such thing as account management on Siemens PLCs. If followed (which certainly isn’t a bad thing to do), PCs in the automation network will be more secure than before. However this will not be sufficient to counter malware which exploits the Beresford vulns, as such malware will likely use operating system or application vulnerabilities such as buffer overflows to jump onto a target machine and doesn’t necessarily need to escalate privilege in order to launch an attack against PLCs. All that is required is network access. With the vulnerabilities being on the PLC rather than on the IT side, every mitigation on IT can only try to limit access, with comparatively high cost and little prospect for reasonable chance of success.

“Monitor traffic on the ISO-TSAP protocol, Port 102/TCP.”

It would be interesting to learn how the authors of the advisory suggest this should actually be done. We wonder if they have ever peeked into the data traffic of a Siemens PLC’s port 102 in a real installation. For example, all the polling of process variables (by the HMI, DCS server, or OPC server) all use ISO-TSAP. To top that off, many users implement custom free-format data exchange via ISO-TSAP, using Step7 system function blocks TSEND/TRECV or AG_SEND/AG_RECV, for example for peer-to-peer PLC communication. In order to make any sense out of TCP port 102 traffic it is required to do deep packet inspection. Unfortunately, the details of the layer seven protocol that needs to be analyzed, along with certain peculiarities at layer four such as pre-defined binary TSAPs, are not documented by the vendor. So in essence what ICS-CERT suggests is that asset owners start reverse analyzing the S7 protocol in order to configure their intrusion detection systems, which seems like a far stretch. (There is one commercial IDS product on the market for several years now that does full deep level packet inspection of S7 protocol traffic, along with on-screen, email and text messaging alerts for unauthorized re-configuration and variable manipulation, web-based HMI user interface, reverse DNS of client IP addresses, criteria-based searchable audit trail database and more. It’s called Langner Total Control. We don’t assume the authors of the ICS-CERT advisory had this fantastic product in mind because otherwise they might have mentioned it.)

“Monitor traffic being unexpectedly sent outside the automation network.”

While the advice per se might not be completely wrong, we don’t see any relation to the Beresford vulns which highlight the risk of process manipulation, not the risk of industrial espionage and exfiltration of trade secrets.

“Block telnet and http traffic to PLCs even inside ICS network.”

Strangely, ICS-CERT hereby does suggest to implement architectural changes that they seem to view as impossible elsewhere in their reasoning. The installation of firewalls inside the control network, i.e. between PLCs and computers, certainly qualifies as an architectural change. While firewall vendors will applause here, we believe that the better solution would be to have the vendor provide firmware versions with eliminated or configurable telnet and http servers. Side note: Profinet users in particular will have a hard time getting comfortable with this advice, as a major selling proposition for Profinet was the ability to configure and monitor automation peripherals via http. It will be interesting to learn ICS-CERT’s position on this, if they ever considered the use case.

“Do not click on web links or open unsolicited attachments in e-mail messages.”

We believe this advice is misleading as it suggests that it could be ok to have web and email access from the process network, which certainly is not ok.


The empty quote stands for stuff that ICS-CERT did not address in their advisory. It’s the elephant standing right in the middle of the plant floor that nobody wants to see. The elephant’s name is “contractors”. In respect to both the Beresford vulns and Stuxnet-inspired copycat attacks, contractors pose the highest infection risk. While any mid- to large-size asset owner will be able to enforce a reasonable level of cyber security internally, it doesn’t help much as long as contractors can attach their potentially malware-infested notebooks to process networks or, worse, access that process network remotely via VPN or dial-in modem. So all the anti-virus software, security patches and whitelisting solutions help little as long as just one contractor has access to the process network with one potentially compromised computer.

We encourage everybody to review the advice we have given earlier on how to address the threat posed by Stuxnet-inspired malware.