ConfidentialityTo 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.
IntegrityAlthough 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).
AvailabilityIt 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?
OpennessWhat 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.