Observations on Cloud Security—Part 2

Moving on from internal access controls and IT security infrastructure, we take a closer look at cloud infrastructure and messaging between the plant and the cloud.

Aw 245007 Michaelbachelorweb 2

In Part 1 of this blog, I took a brief look at internal access controls and internal IT security infrastructure. As we explore cloud infrastructure and messaging between the plant and the cloud, I contend that cloud services are more secure than what you could do yourself.

Cloud data centers

There is a case to be made that the cloud is the strongest link in an Industrial Internet of Things (IIoT) solution. Let me try.

Google invested $30 billion into its cloud infrastructure early in 2017, and is “getting there,” according to the company. Microsoft is on a routine $10+ billion-per-year investment pace in its data centers. Amazon Web Services (AWS) is valued conservatively at about $160 billion—maybe as much as $190 billion. Amazon as a whole clears about 25 percent margin on $521 billion in revenue, and growing. A large plant can be built with $100 million in most industries. How do you even compare IT infrastructure investments? Even if you have 100 of those plants?

If trust is an issue, it is not due to infrastructure, software, redundancy, segmentation, disaster recovery or competency. Trust issues with the cloud environment itself would logically have to be based on integrity or conspiracy theories (which I won’t downplay after AWS landed a $600 million contract to build a CIA cloud). But think about that for a minute. For a few percent of what AWS is valued at, they can build a CIA cloud that is reportedly nearly invincible—an audacious claim, but one they are making.

If you think somebody is out to get you or sell you out, you might not be convinced to use the cloud. The commercial data centers certainly have the best offense and defense in the game. It’s going to come down to what you believe they are motivated to do, I suppose.

Most of us are out of their league by comparison. This is technically an area of risk. Realistically, the cloud is the strong link in the chain.

Messaging between things and the cloud

A leading IIoT cloud solution vendor will most likely use properly setup HTTPS or MQTT. That would mean you are using HTTP + SSL, or MQTT + SDP (and probably with SSL). And you have a legitimate certificate authority (CA), which adds additional defense against a man-in-the-middle (MITM) attack. SSL is there to ensure delivery of your data from your computer to a server without getting read or altered. It might get intercepted, but will still not be readable. The SSL hack alerts that have caused some concern have been thought through. Note that this does not address anything except the path between your computer and the cloud. This is handled well so long as your CA source remains uncompromised. The CA source does matter.

MQTT security is handled by using a Software-Defined Perimeter (SDP), which is also referred to as a black cloud. With SDP, Single-Packet Authorization (SPA) can be used to replace username and password access. The subject device can be made black, per se. That is, hackers cannot see it, and do not have a password to hack. Encryption with SSL or TSL can and probably should be added. Regardless of encryption, the devices are essentially invisible and a hacker cannot snag a password that was never sent.

Another option is the Constrained Application Protocol (CoAP), which applies Datagram Transport Layer Security (DTLS) parameters. You know those RSA keys that some manufacturers issue to gain remote access to work on a system? DTLS parameters will rival that security. CoAP was created with machine-to-machine (M2M) communication in mind.

Though nothing is entirely bulletproof, these are responsible approaches to secure communications. Compared with most internal network protection and access controls—as well as everything a person can click on or insert into any given port—message transport between your facility and the cloud using one of these secure methods is solid. And these communications are handled by leading IIoT solution providers. We don’t have to do anything special here.

I’d also like to point out that an IIoT software solution may likely provide a “thing” authentication register on the edge computing side of their platform that must be authorized with a key before making the trip to the cloud. This would limit what is permitted in and out of the firewall, and would add another encryption layer that requires a key to authenticate it on the other end.


There are more exhaustive details that IT security experts can provide for you. The point I will stress here is that the cloud and the message delivery to and from the cloud are risk points. However, they are well addressed, relatively low-risk points. Your internal infrastructure can and should be in good shape, but it will be a small fraction of what a reputable cloud infrastructure investment is. The greatest fear will continue to be access controls—security in spite of people, even with good hiring and training.

If you take a group of 100 companies that shun the cloud for security concerns and 100 companies that embrace it and compare the two, what would you see? I don’t have this study for reference. However, it is not unreasonable to believe that a company that embraces the cloud will on average address internal security concerns more thoroughly than a company that believes it is avoiding the risk by avoiding the cloud. The irony here is that the cloud-averse organization might be more vulnerable, and is likely at best equally vulnerable.

Michael Bachelor is president at Bachelor Controls Inc., a certified member of the Control System Integrators Association (CSIA). For more information about Bachelor Controls, visit its profile on the Industrial Automation Exchange.


More in IIoT