Internet of Things – Page 6 – Maverisk / Étoiles du Nord

ICShape

Doing some pondering, digging and backtracking on the issue of IoTA. But, … already got stuck when considering how to (best?) model the architecture at lower levels. Would a classical picture, or a somewhat-less classical picture work best to gain understanding of the risk areas ..? As in:
Industrial control cycle
[Own pic]
Or
open-standards
[Plucked, adapted from the site linked below]
Where the former is from the industrial, process-oriented engineering world, and the latter from the digital networking world.

Yes I’d really like your advice on how to ‘marry’ both to be able to optimally visualise where the risks are; the potential, intentional or not, noise on the signal, or the wrong signals altogether. What might cause that, how to protect against that, etc.
Yes, taking into account the work already done here – which is impressive, but somewhat (?) protocols-oriented, not architecture-/risk-oriented. Yet. Something like
SCADASmartGridEfficacy_Page_2_Image_0002
[plucked off a simple search] is what I’m after.

But the other work, too. All, to overlay with risk lists on all surfaces at all levels… Then, to see how to protect that all against the (generic?) risks, and how one would audit sufficient (?) protection is in place. Not ‘controls’ – those are the losers’ weak retreats, the “didn’t want a cookie anyway” fig leaves. Taking into account this breakthrough though.
But for now, again already, leaving you with:
DSCN2075
[Life in stead of straight angles, Barça]

Your Things’ Id, Ego, Super-Ego

Just putting it out there; my pres at the very successful IDentity.Next conference last week in Noordwijkerhout. Though it is without any actual speaker notes, you may still get the points – or we may have a discussion about certain uncertainties therein.
I’ll stop now; too much in the unwind mode still, due to the great discussions on the spot.

So, here it is. And this:

[Things creeping up on you; Zuid-As]

IoTA mutiplication; old style, is the new new

Apart from the previously established focus on Integrity, in particular to have Data plane integrity from which actual Information could be derived, through integrity in the Control plane, there’s of course a need for other aspects as well, like Confidentiality, Availability, and Effectiveness and Efficiency.
[Oh that previous Integrity signal is here.]
Though the latter two, we’ll diss straight away as most secondary, at best, along with the even further irrelevant Auditability et al. That take a devastatingly distant back seat to ensuring the first three objectives are met; not to interfere by mention, even.

Intermission:
DSCN5611
[Onto itself, good enough; Papendorp]

And, we’ll square the three foremost information/data/systems/elements quality aspects with the great many objects one can outline in the IoT sphere. Leading to very interesting new combinations of various corners and angles of objects and aspects in all sorts of abstraction levels – multiple, not necessarily constant, consistent or complete when studying for certain overall audit objectives.

And, let’s not forget, we do have OSSTMM for more traditional objects, and may (have to) enhance that to incorporate the ‘new’ more technically oriented objects of sensors and actuators (including a need to understand and probe them, e.g., at the AD/DA-converter and pure signals levels).
But we also need to incorporate the vast blue (rather, muddely grey) ocean of People, as controls and to be controlled elements.
Only then, can we have a full systems view on the to be controlled and to be audited phenomena.

But we dreadnought and fear not; for we have a number of building ~~blocks~~ bricks, even if at Lego size. Like the security suites springing up and spreading, Splunk et al and al. of the proprietary hardware-vendor types.

To Be Continued in extenso, including including these vendors their security-management-first approach which helps a lot, through logging/reporting availability and some security control, and including including the generic risk management approach that is at the limit of what common auditors’ associations seem to have as vanguard developments in lieu of actual understanding of the vast terrain to cover.

SwDIoT

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 R² of the signal (however far from log₂(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]

Sing-Singularity, and/or Shannon

Though we know Shannon for his contributions to ‘computer science’ (Don’t we!? If not, go study. And wash your mouth with green soap or so) – the field would hardly exist without his groundbraking concepts, on par or lower (sic) than Turing maybe – and we all do remember log2 measurements as minimum to reconstruct a signal don’t we? – I rediscovered this piece and wondered … how well you’d know it, and how fundamental to even the IoT now springing up, and … most importantly, what would the ramifications be for all of the discussions regarding the Singularity, pre-, midst of and post- ..? I mean, the discussions will tilt once the profundity of the Work is taken to heart.
I think. Now will go and study. Hard. And:

[Old analog (log2!) Zuid-As indeed]

Better IoT privacy

Oh, I’ve been outdone again, in some ways. Which isn’t a big deal; ’twill happen to you, often, too. This time, it’s about the IAM in IoT that I signalled here and here, here, and here as a generic problem. Correct: Challenge.
Which all was readable. Hopefully. For all dealing with the stuff on a monthly basis (ahum, ‘weekly’ or ‘daily’ wouldn’t make sense; you’d be ahead of me probably…) that is. For a more general explanation, one can now turn to this here piece; much better at generalpublicspeak than I’d produce when diving onto it again.
Oh well. This:
DSCN6007
[Somehow, typically Madridean ;-| / Southern European / Latin style]

Hegelian Hybris

A short post for All, and for None. Whether you like it, or not.
If you got the reference (*sigh*; here, for the outitiated)
you may read on
Else
#include <complex.h>
Endif

Where there’s a line from the Classics, the pre-Socrates ones and later literary additions (like these, and this one and this one, and many others), straight towards Hegel. Overtaking Nostra, it would appear.
(Read on below)

[Where at …?]

But appearances may be deceiving. Though all the talk about the End Is Nigh And We Should Celebrate Because It’s The Singularity (beyond the rosy picture, blindly (sic) denying the dystopian view), indeed the Singularity is what Hegel dreamed of. History as the progress of Reason; pure, abstract, everywhere; everywhere overturning the other half of the Yin-Yang that the Everything is …
But then, not only can one not shut out the original Chaos force of nature part of Everything, and of humanity or it will boomerang back in your face (the more suppressed, the harder it detonates in unthinkably gruesome ways!), the Yin-Yang comparison is apt as each of the halves has a dot element of the other half in it.
And, it’s not only Eastern (huh, that’s a relevant reference isn’t it, on a globe…?) wisdom at the core that has this, but it’s the Greeks et al. as mentioned above, too, that demonstrate these principles over and over again in aptly named tragedies. Of humanity. Where catharsis comes too late. And the careful analyst learns that it’s not human emotion that has galloped beyond humility and due (Aristotelian) care, but reason dumbed down by overconfidence in its efficacy to rule over life. Commenting Hegel down quite a few pegs, very very anachronistically.

Because he (his straight path to Reason) doesn’t take into account the Yin-Yang. Because it doesn’t truly understand Hybris. As a human trait, on any side; not only on the Dionysian but especially (it seems, these days, again…) also on the Apollo side.
[I’m done with the wiki linking. Go figure it out yourselves if (big if) you’d have to.]

Oh well. History repeats. Just don’t fall for it. Remember; you’re scared when a couple of blocks down the street there’s a big kitchen fire. You’re not scared about the Sony hack – see that you should, given that on the ‘net it’s closer to you than that kitchen ..? Same, with the jobs that will be gone in a decade (and your kids are still learning how to do them) whereas it’ll affect your current job as well. Even Uber drivers picking up the morsels handed out by algorithms à la the new middle managers, are going to be replaced with self-driving cars. Etc.
Be Prepared. (Luck favours the prepared.)
And keep an eye open for the future; you’ll have to live there. Better make it comfy – yourselves! for yourselves, for the global village that society has become (no more isolation and dropping the collateral damage elsewhere possible, with global environmental effects). Physically, and mentally. As above.

New car game, new chances

Earlier we wrote about how the self-driving cars till now, weren’t. Were more like ‘world-map programmed in, some (humanity oh dear how irrational) noise added’-navigating cars.

Now, we’ve entered new games, like the Big G possibly taking on Uber through employing self-driving cars – which would make the shrill reality of jobless growth, as predicted for the taxi industry a reality; where do all the taxi drivers go ..? And suddenly, there’s a new entrant on the other front. This one might pear fruit. If, big if, they’ve tackled the hard AI problems XOR they’re on the same lame track. [As said, the essence in this earlier post]
Or it’s just an as yet unheard of thingy for a new round of Connected Car developments. Or…

And then there’s dark horses lurking in the background. Like Tesla (/ Hyperloop?), and others you have no idea about yet.

OK, speculation, speculation, … Just wanted to note that there seems to be movement on the AI front leaking into the Real World. Or not. But there’s things a-brewin’.

DSCN6262
[Cloudy weather, dark picture. Still, let’s pray for progress ? at Colline du Haute]

IoTOSI+

In order to get proper information risk management and audit in place for IoT, on top of IoTsec, the frames of mind should be grown and extended so at least they touch, if not overlap in a coherent way.
Where IoTsec-and-IRM-and-audit is about the I and C of All Of ICT, we could do worse than to have a look (back) at the OSI stack. All People Seem To Need Data Processing, remember. (Not even a question mark but a period Or else go back and study, a lot.)
Which we should extend, clarify for IoT, and deepen in detail, downwards towards the sensors and actuators, and upwards beyond the A level into … Meaning, like, Information and stuff ..?

As an interlude, you already deserve:
20150109_145625
Heh, ‘smart’phone pic; not FLlW but Van ‘t Hoff’s Villa Henny. As here in Dutch, though that states the style would be related to FLlW only – wiping the ‘near-perfect carbon copy’ aspect under the rug…
Now here’s a few actual FLlW’s…:
000005 (6) 000023 (6)
How’zat for copying ‘in a style related to’…!
[Sorry for the pic quality; these scanned from analog…]

Now then, back to the OSI stack and the absence of Security in that. Audit is even further away; the orphaned nephew (role, function!) will be attached later to the whole shazam.
Given that the A is there for Application, do we really have anything like the function of the communications/data at that level or higher up ..? Well, it seems Higher Up is where we should aim indeed, as a starting point. And end point. Because the information criteria (being the quality criteria that information may or may not meet) play at that level. Resulting in all sorts of security measures being applied everywhere ‘in’ the OSI stack itself [as a quick Google ~~shallows~~ shows] for safeguarding these criteria at lower levels; lower in the sense of below the Meaning level i.e. A and down.

Because, the CIAEE+P (as partially explained here and here) regard quality criteria in order to ‘have’ appropriate data as medium in which Information may be seen, by interpretation, and by letting it emerge from it. (Sic, times two.) Above which we might, might possibly, even have Meaning getting attached to Information. (Big Sic.)

Oh, and, the even-below P-level implementation I’d relegate to the, usually not depicted, physical not-comms-box-but-signal-source/destination physical objects of sensors and actuators… Obviously.

So, all the Security in the picture regards the quality criteria, and the measures taken at all levels to enhance their achievement. Enhance, not ensure. Because whoever would use ‘ensure’ should be ashamed of their utter methodology devastation.
And, to be honest, there is some value in having measures at all levels. Since the grave but too common error of doing a top-down risk analysis would require that. And a proper, due, sane, bottom-up risk analysis would still also have this, in a way.
Where the conclusion is: Requirements come from above, measures to enhance meeting any requirements, should be built in as extensively and as low down as possible, only extended upwards as needed. Note that this wouldn’t mean we could potentially do without measures at some level (up), since the threats (‘risks’) would come in at intermediate and upper levels, too, not having been taken care of at lower levels ‘yet’.
Audit, well… just checking that all is there, to the ~~needs~~ whims of apparently unintelligent requirement setters…

I’ll leave you now; comments heartily welcomed…

Attached ITsec

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:
DSCN5608
[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)² 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.