IoT / IoE: When It’s Got an IP Address, It Will Get Hacked

Given the recent debate and increased attention on the subject, I’d like to make a couple of points for the (hopefully) greater good of the security community. Currently, most experts envision the Internet of Things (IoT) / Industrial Internet / Machine-to-Machine / Internet of Everything (IoE) as the next big wave that will come and connect together all our various systems; devices; networks; machines; cars; airplanes; ships; trains; plants; factories; and more. While I agree that connectivity is great and adds a lot of value, interoperability and functionality features, there is an oftentimes underestimated risk in putting the whole world (well, the whole internet) directly in front of any system or device and connecting to it by giving it a routable IP address. In the past, decision-makers have all too often taken the path of fast forward, easy going, least resistance, and maximum financial gain without caring much about longer-term effects on security, stability, privacy and the like. This is a bold statement, but when you look at how things are going wrong by the day—how companies continue to be breached, how customer data continues to be stolen by the hundreds of millions of records, and how easy it is to bypass system security in almost all environments—you may come to the same or a similar conclusion: it is always easier to create things without doing a full analysis or solving complex problems by ignoring the side conditions. This is true for mathematics and science, and it certainly is true for technology. But this is neither acting responsibly nor serving our long-term interests. As someone who cares about the problem, which will only get worse with each new cycle, I’d like to make a couple of points that I as a user / consumer / customer want to see in any IoT-enabled system. I would strongly encourage everyone to push for the same types of measures and to make wise and informed choices when it comes to buying and accepting any new products, regardless if you make these decisions for yourself, on behalf of a company (purchasing department), or any other third-party. These points are relatively simple to understand, and they sum up the various needs for security and privacy as they have been more or less addressed in other instances in technology. Let’s start with the typical CIA triad and then move into other subjects:

Confidentiality

To protect this property, it is important to use encryption with secure key management. The common well-known and accepted encryption algorithm is AES256 and this should be the choice in all cases allowing for symmetric encryption until proven otherwise. For cases that involve many users / keys, use asymmetric RSA 2048 bit. For key exchanges over insecure channels, use the Diffie-Hellman protocol. Encoding (e.g. BASE64) is NOT encryption, as the decoding function can easily be used for reverse results.

Integrity

Although some may think encryption is enough, that is not necessarily the case. Imagine if someone has access to the encryption / decryption keys and can change the content of the message (the supervisory control protocol, the values, the parameters, the content – you name it) without the true recipient (the valve, the control, the actor, etc.) being “aware” of those modifications. This could become a big issue. Alternatively, imagine an accidental change of the encrypted message without knowing the actual keys. How can the recipient system make sure the received message / command has not been tampered with in any way? Using secure hashes (a cryptographic hash function like SHA-2, SHA-3) helps solve this. A CRC protects against only transmission errors and not intentional changes. So dear designers, please require the use of secure hashes or even better the use of digital signatures to attain non-repudiation (see below).

Availability

It is important to think about the required availability of the system / data at hand. Therefore, a true and deep analysis of the use cases and a clear definition of backup solutions, high-availability (full double pathways) specifications, and potential 24/7 implications for patching and updates mechanisms need to be developed and specified / documented. Consider alternative power sources, network sources, storage sources, compute sources, etc. Remember to look at the whole meta-system, as each node adds another factor into the probability equation (80% * 80% * 80% ≡ 51.2% and not 80% for the total system). What kind of emergency response feedback should the system provide to add to the sustainability of the overall system?

Openness

What kind of open interfaces and ports are required, and what does this mean to the attack-surface? Remember, for example, the USB port / protocol. It was a wonderful improvement to the former adapters / busses / protocols / (E)ISA / ATAPI / SCSI slots etc., but at what price? You can take over a machine by connecting a malicious USB stick to it. Does that attack vector work for your product, too? And regarding the open (easy accessible) standard: this is basically interoperability versus perceived security (by obscurity – which doesn’t work long). It’s similar to the publicly discussed encryption algorithms (not the keys itself though!). When anyone (capable) can verify their design, this is better than some implementation that is kept secret in the dark because it suffers from certain issues. Is your system secured by design, or have you outsourced this responsibility to others at a later stage? (Guess what, it might never be addressed just by experience from the past.) Resilient system design requires fail secure, not fail open. But keep in mind that the overall system must be safe for humans. Due to length constraints, I have cut this article into a little series. In the next piece of it, I will discuss several additional mandatory security design considerations for the IoT / IoE world, such as secure system & SDLC, the 4 A’s, as well as non-repudiation and others.  

Image

About the Author: Michael Oberlaender has a broad, global, diversified background in various industries and markets, 27 years of IT including 17+ years full time security experience, and a strong focus on IT & security strategy. Michael is a globally recognized thought leader, book author (“C(I)SO – And Now What?”), publisher, and has written numerous articles for security magazines, and also has been frequent speaker, panelist and moderator at security conferences. He holds a master of science (physics) from the University of Heidelberg, Germany. He is member of (ISC)², ISACA, ISSA, and InfraGard (FBI). 

Image

Michael is currently serving as the Chief Information Security Officer of a larger corporation across the US, Canada and the UK. His expressed statements and opinions are that of his own and do not reflect on any current or prior employer or customer. To find out more about Michael´s book, “C(I)SO – And Now What?”, click here. You can also follow Michael on Twitter here, and connect with him on LinkedIn here. Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.