What the heck is ISO-TSAP?

This great blog post criticizes this grossly incompetent advisory by the US DHS CERT. Both mention “ISO-TSAP”? What is “ISO-TSAP"?

Just TCP, the same protocol that carries Internet traffic.

That’s what makes the DHS advisory incompetent, because it blames TCP’s lack of encryption for the problems in the Siemens industrial controllers. But a protocol like TCP isn’t supposed to encrypt data, it’s just supposed to carry traffic between two end-points. If you want encryption (like SSL), you are supposed to layer that on top of TCP.

So if ISO-TSAP is just TCP, why is it called by a different name?

That answer is a bit more political. The Internet as we know it wasn’t the Internet the government designed. Instead, they designed a competing Internet known as either “OSI” or “ISO”.

The government first created a blueprint, called the “OSI Model”. That model defines seven layers, where each layer is responsible for a specific task. Layer 1 defines how bits are sent onto the nearest wire. Layer 2 defines how packets are sent only as far as the next hop (to the other end of the wire). Layer 3 defines how packets go hop to hop across the world wide network to the destination computer. Layer 4 defines how the packets reach the destination application on that target computer, whether it be the web browser, iTunes, Skype, etc.

TCP fits in layer 4, but not precisely as OSI defines it. Mostly, it’s a terminology difference. For example, the OSI/ISO standard might say “disconnect” the connection, but TCP/IP might say “close” the connection. The ISO-TSAP standard is mostly just a translation between this terminology, showing how if somebody writes code that conforms with the OSI/ISO Layer 4 standard, how it will work when run over the TCP/IP standard.

There is one important difference. TCP/IP sends data as a “stream”. Yes, even though the underlying IP sends packets, the TCP on top reassembles this back into a stream of bytes, so that applications see no boundaries between packets.

But the OSI/ISO Layer 4 standard defines a boundary between packets. Therefore, the ISO-TSAP standard adds 4 bytes to each TCP packet to include a “length” field, so that applications can discover the original packet boundaries that are hidden by TCP. Therefore, if you were to ask about the precise protocol differences between ISO-TSAP and TCP, it would be the addition of the following header to each packet:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      vrsn     |    reserved   |          packet length        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

So this OSI stuff has been obsolete for over 20 years, why the heck is the Siemens controller still using it?

Well, that’s the problem with industrial-control/SCADA systems: they are 20 years out of date. It’s the way that industry works. They expect to install a piece of equipment and have it run unchanged for decades.

And that, not “lack of encryption in ISO-TSAP”, is the cause of the Siemens vulnerabilities. The system was created using cybersecurity concepts that are 20 years old, that haven’t caught up with the radical change in cybersecurity that we’ve seen in the last 10 years.

Indeed, the reported Siemens vulnerabilities are just the tip of the iceberg. If a system is using ISO-TSAP instead of raw TCP, it’s probably using all the other dumb stuff from ISO/OSI. The most egregious is something called ASN.1, which is a way of abstractly defining fields in packet. When you “concretely” define fields in packet, the lengths tend to be fixed. For example, you might have a username field that is precisely 16 bytes long. When you “abstractly” define fields, they can be any length. A programmer might make a “safe” assumption that a username couldn’t possibly longer than 1000 character, and might reserve a buffer in memory of that length. But, of course, a malicious hacker can exceed that, and provide a username 2000 bytes long, overflow that buffer, overwrite other parts of memory in such a way that allows the hacker to break into the system. Such “buffer-overflows” are significantly less common on today’s networks -- except in those places that are still behind the times using things like ASN.1.

I know of at least one vendor’s implementation of ICCP (Inter Control Center Communications Protocol) that also runs on ISO-TSAP and uses ASN.1 that if full of such buffer overflows.

It is this problem of being 20 years behind the times that it likely the cause of the grossly incompetent DHS advisory. It was probably written with input from the Siemens engineers who explained the problems, and the Siemens engineers are working with 20 year old concepts. The DHS employees probably did little of their own analysis, and certainly, they never talked to the guy who discovered the problems.

Conclusion

The grossly incompetent DHS advisory is just a reflection of the fact that the industrial-control/SCADA systems are grossly out of date. This is demonstrated by the fact that I have to roll back the clock to a time before many readers of this post were born (RFC 1006) in order to explain what the heck is going on.