4

Background:

I just attended a talk on the security of critical infrastructure. The speaker spoke a bit on how adding the TCP/IP protocol to functions usually taken care of by dedicated protocols open up some security holes.

The example he gave was the SS7 protocol for the telephone infrastructure. He gave figures (can't remember the exact numbers) on how adding TCP/IP functionality onto the protocol, SS7OIP, increased the number of threats against the telephone infrastructure. One of the reasons he stated was that it opened up the telephone network to the wider internet, and no longer required insider access to the SS7 network to perform attacks.

Question:

In the case of critical infrastructure - telephone, electricity, water to name a few, what does adding a TCP/IP layer accomplish?

Is the threat real? Does adding a TCP/IP layer expose such systems to significantly more risk?

If there is a real threat, is the added functionality (if any) worth the added risk?

AviD
  • 72,138
  • 22
  • 136
  • 218
  • It sounds like most of the additional risk is from connecting (incautiously) these systems to public networks. The increased risks from that would seem to outweigh any protocol associated risks. – adric Aug 24 '12 at 13:26

4 Answers4

5

TCP/IP is a best-effort protocol. It is very efficient at maintaining connectivity in adverse conditions (including use of nuclear weapons). It offers no guarantee of communication, but, when you come down to it, no system can (all communication systems involve using some kind of hardware, which may fail).

The problem with TCP/IP is not with TCP/IP itself, it is with the others ("Hell is other people"). One very interesting aspect of TCP/IP is that it is what the Internet runs on, so, if you do TCP/IP, you can easily use the Internet infrastructure, rather than having to build your own. A transoceanic cable is a bit expensive... so switching to TCP/IP is a cost-killer. Unfortunately, you are not alone on the Internet. If you use the Internet infrastructure for your communications, then, necessarily, you expose your communications to whoever roams on the Internet. As some security specialists like to say, you have "enlarged your attack surface". Cryptography (i.e. SSL) can help to keep your data confidential, but TCP/IP is such that denial-of-service are possible (if only by clogging the tubes).

So it is not really a question of TCP/IP or not. It is a matter of sharing the infrastructures, vs using dedicated links. For instance, the Internet2 is a TCP/IP-powered network which is separate from the mainstream Internet. Sharing infrastructure makes your more vulnerable -- but dedicated links cost a lot. Choose your poison: risking to see your communications disrupted, or not being able to communicate because you wanted dedicated links but could not afford them.

(In the Inca Empire at the beginning of the 16th century, there was a network of roads with dedicated lanes for messengers from the central power. Building dedicated lanes and guarding them -- trespassers could be beheaded -- was very expensive, but the Inca still found it worth the effort. Your question about TCP/IP is really the same situation, only with 400 years of additional technology.)

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
3

It's difficult to know exactly why the organisations that handle critical infrastructure choose to implement TCP/IP into such networks, but here are a few of my best guesses at their requirements for networking their control systems together:

  • Need a reliable and maintainable way to interface with infrastructure equipment remotely.
  • Need a way to address large amounts of equipment across a huge geographic area.
  • Must be able to interface with existing computer control systems.
  • Must be extensible, so that new devices can be added to the network easily.
  • Must be cross-platform, so that embedded devices, different OSes and different computer systems can communicate properly.
  • Must have low latency and high throughput for strong performance during critical tasks.

As far as choosing TCP/IP goes, it has a lot of good qualities:

  • TCP/IP is mature, stable, fully documented, and one of the most analysed communications protocols in existence.
  • TCP/IP provides strong packet ordering, corruption detection (checksums), spoofing resistance, client identification, addressing, etc. with relative ease.
  • TCP/IP is patent free, and there are hundreds of open source implementations, for a large range of different processor architectures, under a variety of licenses.
  • TCP/IP is available on almost every modern computer device and operating system.
  • Existing network infrastructure is cheap to use, mature, reliable and self-healing.
  • There are thousands of pre-existing application layer protocols that sit on top of the TCP/IP stack.

In terms of security, SSL and IPsec are two existing protocols that are designed to work with TCP/IP to provide endpoint-to-endpoint security, and both can be implemented with relative ease.

Now, to perform a proper risk assessment on such a huge block of infrastructure, I'd need some specifics. Since I don't have any, I'm just going to make a guess. At this point I'm working on conjecture alone, so don't assume my conclusions to be accurate.

Introducing networking into the infrastructure provides a huge benefit in terms of:

  • Monitoring the status and health of equipment without visiting the site.
  • Updating and configuring equipment remotely in a centralized fashion.
  • Immediate alerting and logging on equipment failure.
  • Reduced downtime of equipment due to ability to predict failure.
  • Reduce maintenance and inspection costs due to centralization of data.
  • Better planning through more accurate supply/demand and load statistics.
  • Integration of services for better consumer experience.

The security implications are as follows:

  • Every device becomes a potential security vulnerability.
  • Potential for snooping in telecommunications channels.
  • A hostile entity (terrorist group, enemy nation, etc.) might exploit vulnerabilities to cripple the country's infrastructure.
  • Possibility for citizens to abuse/hack the system, e.g. free phone calls, free power, etc.

Part of the perceived security of the system is through obscurity. These machines are likely to run on their own proprietary control systems, and are likely to be interfaced using custom application layer protocols. Furthermore, their addresses are not catalogued or distributed anywhere. It would take a team with strong reverse engineering / pentesting skills, specialised equipment and insider knowledge to identify and break the systems. Of course, we know this has happened before with Stuxnet and SCADA control systems.

Assuming the control systems run custom embedded systems or *nix, the potential for strong security controls is there. One would hope that a multi-billion pound (or dollar) industry would consider proper security and engage in active and frequent security reviews, but sadly this is often not the case. Without access to internal company information, there's no way to tell if such precautions have been taken.

All in all, I think the benefits do warrant the potential security risks. Having working power, gas and water is critical, and 99.9% of the time we're not going to be in a war-time situation. During normal operation, we need the ability to monitor and control everything as quickly and reliably as possible, to ensure proper operation and minimal failure rates. On the security front, the obscurity factor is a useful time delay, and any real security that has been implemented is likely to be more than enough to determine all but the most advanced persistent threats.

Polynomial
  • 132,208
  • 43
  • 298
  • 379
2

Adding TCP/IP to critical infrastructure is usually as a result of a cost saving exercise. By going with a standard communications protocal (and standard sockets) this reduces the IT costs because we all know that IT staff are well aware of how TCP/IP works...

Also the vendor can start using off the shelf components reducing manufacturing costs.

As for adding to the threat, there are probably a couple of schools of thought on this one. If you have no TCP/IP and you are using "Propriatary" protocols, then you can rely on security by obscurity. Seriously who has the time to learn these archaic protocols... But then again a quick ebay search will find you plenty of old scada equipment with connectors and operating manuals going dirt cheap.

If you do add TCP/IP then you have to be aware that you should not be connecting your devices directly to the internet. I recommend reading this news article and the linked to paper for an indication of how often this happens.

So yes the threat is real, is it worth it. Depends on what risk you are prepared to take on

Colin Cassidy
  • 1,880
  • 11
  • 19
0

Yes adding TCP/IP will always add risk. Nasty hackers have been exposing loop holes in any type of protocol.

Its what you do with it that matters.

2600 is famous since good old Captain Crunch did his thing with a free toy from Captain Crunch Cereal and found that the frequency was just right to get free calls on the American Telephone System.

Hackers have been using and securing TCP/IP for a very long time. Its probably the most peer reviewed protocol in existence and some would argue more secure because of it.

If you leave an attached unprotected device to a TCP/IP network (aka internet), it will get compromised.

Attach a couple of distinctly different firewalls and its near on safe.

Oh and educate the wet bit using it. Since putting a connected device into a secure underground bunker with levels of firewall/IPS/IDS will not stop them opening the latest nude photos/you have won $100000000 type virus laden emails.

What do you accomplish with adding TCP/IP other than

Hackers have been using and securing TCP/IP for a very long time. Its probably the most peer reviewed protocol in existence and some would argue more secure because of it.

You get a bunch of

  • people that know it (skills = cheaper)
  • products for it (cheaper)
  • being able to talk about it (understanding)
  • api's that just do it (programming is easier)

Oh and look up the pro's and cons of Security by Obscurity and make your own mind up about how insecure v secure not being on the "inside" is. I think you will guess where I stand on it ;)