Recently, there was yet another exepelainificationing of ‘software defined networking’, along the lines of separation of the control plane from the data/content plane (here).
Which ties into a core problem, with IoT the subject of this post: Integrity.
Yes, confidentiality may be an issue, but singular raw data points themselves often are too granular to actually steal any information from. And Availability is of course also of the essence, especially in ‘critical’ systems. But te main point of concern is with Integrity, of the system in a wider sense, but also in the smallest sense.
Take Stux … Integrity breach as the vector space, spanned along a great number of dimensions.
Objective: Degradation of the information value; increasing the variance to a level where noise overwhelms the R2 of the signal (however far from log2(n), big if you understand), through degradation of the (well, original) software integrity.
Path: Introduction of intentionally-faulty (?) software. With use of of, probably, penny-wise correct IAM, being pound-foolish at the medium level. I mean, the level where human and other actors are unwitting accomplices in planting da bomb. That’s what you get by simpleton top-down compliance with just about every thinkable rule: To do any work, underlings will devise ways to circumvent them. And, adversaries will find, see, avenues (that wide) for riding on the backs of the faithfully compliant to still achieve the objective.
But OK, back to … separating the control plane from the data plane. Bringing a shift in efforts to disrupt (no, not of the mehhhh!! destructive, economy-impoverishing kind but in the actual signal degradation kind) from just-about any attack plane down to, mostly, the control plane. That may seem like an improvement, de-messing the picture. But it also means shifting from a general, overall view of vulnerabilities to the core, and a core which is less tested or understood, and harder to monitor and correct, than previously. Or is it ..?
So, if we take this Software Defined to IoT, we’ll have to be careful, very careful. But yes, IoT is constructed that way … With signals to actuators that will result in altered sensor data feedback. Know the actuator signals, and the actuator-to-sensor formulas (!), and you’re good to go towards full control, with good or bad (take-over) intent. Know either (or how to get into the sensor data stream), and at least you can destroy integrity and hence reliability. [DoS-blowing the signal away in total blockade or grey noise wipe-out, and your cover is blown as well. Is a single-shot or semi; you may want to have full-auto with the best silencer available…]
Hm, the above from the tinkering with the grand IoTAuditing framework promised… To turn this all into a risk managed approach. Well, for now I’ll leave you with:
[It has a glass floor up in there, you know. Blue Jays territory, ON – and yes, a very much sufficiently true and fair horizontal/vertical view picture, according to accountants]