OK, I’m a bit stuck here, by my own design. Had intended to start elaborating the all-encompassing IoT Audit work program (as per this post), but the care and feeding one should give to the methodology, bogged me down a bit too much … (?)
As there have been
- The ridiculousness of too much top-down risk analysis (as per this) that may influence IoT-A risk analysis as well;
- An effort to still keep on board all four flavours of IoT (as per this), through which again one should revert to more parametrised, parametrised deeper, forms of analysis;
- Discomfort with normal risk analysis methods, ranging from all-too-silent but fundamental question discussions re definitions (as per this) and common approaches to risk labeling (as per this and this and others);
- Time constraints;
- General lack of clarity of thinking, when such oceans of conceptual stuff need to be covered without proper skillz ;-] by way of tooling in concepts, methods, and media.
Now, before jumping to yet another partial build of such a media / method loose parts kit (IKEA and Lego come to mind), and some new light bulb at the end, first this:
[One by one …, Utrecht]
After which:
Some building blocks.
[Risks, ∆ [Consequences] of If(NotMet([Quality Requirements]))]
Which [Quality Requirements]? What thresholds of NotMet()?
[Value(s)] to be protected / defined by [Quality Requirements]]? [Value] of [Data|Information]?
[Consequences]?
[Threats] leading to [NotMet(Z)] with [Probability function P(X) ] and [Consequence] function C(Y)?
([Threat] ∆ by the way as [Act of Nature | Act of Man], with ActOfMan being a very complex thingy in itself)
[Control types] = [Prevent, Detect, React, Respond (Stop, Correct), Retaliate, Restore]
[Control] ∆ …? [ImplementationStrength] ∆?
[Control complex] ∆ UnlimitedCombiOf_(N)AndOrXOR(Control, Control, Control, …)
Already I’m missing flexibility there. [ImplementationStrength(Control)] may depend on the individual Control but also on (threat, Threat, …) and on Control’s place in ControlComplex and the other Controls in there. Etc.
Which should be carried out at all abstraction levels (OSI-stack++, the ++ being at both ends, and the Pres and App layers permeating throughout due to the above indetermination of CIAAEE+P for the four IoT development directions, and their implementation details with industry sectors. E.g., Medical doing it different than B2C in clothing. Think also of the vast range of protocols, sensor (control) types, actuator types, data/command channels, use types (primary/control, continuous/discrete(ed)/heartbeat), etc.
And then, the new light bulb as promised: All the above, when applied to a practical situation, may become exponentially complex, to a degree and state where it would be better to attach the security ‘context’ (required and actual) as labels to the finest-grain elements one can define in the big, I mean BIG, mesh of physically/logically connected elements, at all abstraction levels. Sort-of data labeling, but then throughout the IoT infrastructure. Including this sort of IAM. So that one can do a virtual surveillance over all the elements, and inspect them with their attached status report. Ah, secondary risk/threat of that being compromised… Solutions may be around, like (public/private)2 encryption ensuring attribution/non-repudiation/integrity etc. Similar to but probably different from certification schemes. Not the audit-your-paper-reality type, those are not cert schemes but cert scams.
OK, that’s enough for now. Will return, with some more methodologically sound, systematic but also practical results. I hope. Your contributions of course, are very much welcomed too.
