There are two things that I hate in the world this morning: the term ‘IoT’, and the fact that ICS slave devices are the ones which run server software. Sometimes, two bad thoughts do make a good one. This morning is one of those times.
A common architectural theme in IoT devices is that they establish connections to a central service, usually a web application, for instructions on how to behave. In well-designed IoT devices, the connection is initiated by the device(0).
Contrast this to the standard ICS architecture, wherein the field device runs a listening service (often, more than one). The device awaits the connection from master systems, which then pull the information out of the device. This approach uses the opposite of good sense: it does not follow the same design principle which causes us to architect the corporate-to-control perimeter in the way that we do. It is asking the least capable, and also the most critical, device to do the most resource-intensive communication task when it comes to both security and reliability.
This security and reliability antipattern is a direct cause of most, if not all, of the ICS-CERT advisories concerning field devices over the last decade. Every backdoor, every protocol parsing error, and every denial of service bug would be either eliminated, or have its exploitability reduced to ‘local network’ if this antipattern stopped being a standard operating procedure.