Tag: IoT

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)

DSCN8578
[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.

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)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.

Hiding or in plain sight (IoT dev’t)

In IoT development, there seems to be a disconnect between the hype and the underlying developments. By which I mean that of course, the hype will not play out according to itself, but according “We overestimate short-term impacts and underestimate the longer-term ones”. But moreover, I also mean that there’s a variety of development speeds for IoT. Since there is various types, categories of IoT developing.
As in this here one of my previous posts.

Oh right away:
DSCN8649
[Your office ‘life’, Zuid-As again]

So… what we’re seeing, is certain differences in speeds:

  • B-inhouse IoT develops rapidly; after some decades of slow introduction of robot-driven factories, we’re on the verge of a breakthrough at less than light speed where the same factories will be linked up to form semi-small, mid-size ‘local’ 3D printing warehouses. Maybe. But certainly, the factories will go the way of data centers, that can be anywhere around the world with only rump staffing locally and control being … anywhere else around the world. With the premise that in the ‘Western’ world, there will be sufficient sufficiently educated staff to control the factories elsewhere. So that ‘manufacturing’ may ‘return’ to the West its origination (Industrial Revolution and since). Nearness of production cutting the costly transport now that labour costs become less relevant, and leaving the most pollutive production where locals still don’t have the economic power to fight the externalities. Short-changing economic development in many places where it had barely started in earnest (no ‘trickle down’ yet). Unbalancing global power developments. We’ll see… Or not; these ‘secret’ in-house developments (in particular, within large conglomerates that can pilot) may not be too visible before their join-or-die breakthrough.
  • B2B IoT: Same, somewhat. Moving ahead with cutting out the middle men, DACcing all around. Pure economics (power play by big corp’s; ROI et al.) will determine speed(s) here. Join-or-die aspects play here, too; less in outright competition but more in missing out in cooperation, being left in the dust.
  • C2B IoT: Out in the open, where all the hype is. No concern – as for secrecy of developments; heaps of concerns re e.g. privacy ..!! Critical Mass (as defined in Yours Truly’s seminal graduation thesis of, already, 1990 (on office automation incl e-mail, where it played then) yes a great many years before it was to be called) Network Effect, or – Tipping Point may be the key point for development fits and starts in this one; in publicity, actual adoption and fruitful use.
  • C-internal: Same. Slower due to legacy. I.e., houses already out there. Some have been around for centuries. Massive update ..? [Edited to add: this here toytoolset seems helpful in this area]

We’ll see…

Flavours of IoT

In my on-going attempts to get a grip on IoT, I recently developed a first, for me … Being a broadest of classification of IoT deployment, with characteristics yet to work on:

  • B-internal; the ever more intelligent, ever more (visually) surroundings-aware robots in factories, replacing extorted laborers thus taking away the last options to life they had. On the other hand, freeing humanity of toils at last ..? If not when there’s a Hegelian end…
  • B2B; having near-AI ‘machines’ as the new middlemen, if at all or incorporated on the sell- or buy-side.
  • C2B; as with most lifelogging e.g., through wearables. You didn’t really think your health data was for your private consumption, did you!? If so, only as a weak collateral product of insurer’s ever better reasons to turn you down the more you need them. No escape.
  • C-internal; maybe, here and there, with domotics. And with this; will already a blend with the previous, probably.

To which I would then add some form of mapping to the various layers of discourse (as in:
blog-iot-security11
but then, much more stacked with OSI-like layers and elements performing various functions like collection, aggregation, abstraction. Seems relevant to do a risk analysis on all those levels and points/connections.
Yes, it’s rather vague, still. But will work on this; to see whether the classification can shed some light on various speeds of adoption, and where privacy concerns et al. may be worst. Your comments, additions and extensions are much welcomed.

I’ll leave you for now, with:
Photo21b[From an old analog to digital time, still SciFi ..?]

Not yet one IoTA; Auditing ‘technology’

[Apologies for the date/time stamp; couldn’t pass.]
First, a pic:
20140226_113554
[Classy classic industrial; Binckhorst]

Recently, I was triggered by an old friend about some speaking engagement of mine a number of years back. As in this deck (in Dutch…).
The point being; we have hardly progressed past the point I mentioned in that, being that ‘we’ auditors, also IT/IS auditors!, didn’t fully adapt to the, then, Stuxnet kind of threats. (Not adopt, adapt; I will be a grammar and semantics n.z. on that.)
As we dwelled in our Administrative view of how to control the world, and commonly though not fully comprehensively, had never learned that the control paradigms there, were but sloppy copies of the control paradigms that Industry had known for a long time already, effectively in the environment of use there. As in this post of mine. Etc.

But guess what – now many years later, we still as a profession haven’t moved past the administrative borders yet. Hence, herewith

A declaration of intent to develop an audit framework for the IoT world.

Yes, there’s a lot of ground to cover. All the way from classification of sensors and networks, up to discussions about privacy, ethics and optimistic/pessimistic (dystopian) views of the Singularity. And all in between that auditors, the right kind, IS auditors with core binary skills and understanding of supra-supra-governance issues, might have to tackle. Can tackle, when with the right methodologies, tools, attitude, and marketing to be able to make a living.

Hm, there’s so much to cover. Will first re-cover, then cover, step by step. All your comments are welcomed already.
[Edited to add: Apparently, at least Checkpoint (of firewall fame oh yes don’t complain I know you do a lot more than that yesterday’s stuff; as here) has some offerings for SCADA security. And so does Netop (here). And of course, Splunk). But admit; that’s not many.]

Clustering the future

Was clustering my themes for the future of this blog. Came up with:
Future trend subjects[Sizes, colours, or text sizes not very reflective of the attention the various subjects will get]
Low sophistication tool, eh? Never mind. Do mind, to comment. On the various things that would need to be added. As yes I know, I have left much out of the picture, for brevity purposes. But will want to hear whether I missed major things before I miss them, in next year’s posts. Thank you!
And, for the latter,
DSCN0924[Bah-t’yó! indeed]

IoT starts at the right end

of the products scale. As in #5 of this post.
#1 would be no surprise, by the way.

And, I’d also not be surprised when you(r company) haven’t considered similar changes. Isn’t IoT something that would not touch your business for decades to come, until you’re blown off the market in lees than five years; either by doing something stupid which you could always do, even today, or by some competitor that has dreamt up some game changer in their garage already yesterday ..? Go ahead and sleep ’till you’re no more. Change isn’t painless, sitting still is. Or isn’t it sleep, just being burnt out (as a company) (link in Dutch) ..?

I’ll leave you with this:
20140917_092605[1]
[At The Factory, indeed, Utrecht]

IoTSec from IAM at entry to the end node

Now that you all are so busy implementing Internet of Things pilots everywhere, I mean at home like with this and this, but B2B everywhere as well (…!?) or are you doing it there not too, we may need to consider Security.
Yeah, Hans Teffer did a great piece on that (see here, in Dutch) and I blogged about that before [and many more links/posts…]. And, there’s quite some other issues with IoT. But the point here is – we haven’t thought of security before implementation.
And at the very few implementation’lets of IoT we see so far, security seems absent. Of course, you’d first want to make it work in the first place. But you’re doing it not right at the start, and you know that decisions made now (implicitly) will remain in the architecture for decades to come, in particular when today’s (almost) stand-alone implem’s become linked up into one giant uncontrolled, uncontrollable mesh.

Now, first, an intermission:
DSCN0113
[At dawn]

So, ‘we’ all have been complaining about the security risks of IoT here and there and everywhere, in particular re the current risks of all sorts of industrial control being hooked up to the ‘net without anyone knowing or caring about proper sec.
And still then, we haven’t progressed beyond this Boy Crying Wolf position. Instead of moving to provide solutions. To begin with architecture ideas, the kind that we will need in order to branch out of the simpleton pilots.

On a walk, it struck me that one major part of any solution would be with Identification, Authentication (A1), and Authorisation (A2) – in particular at each and every end node in the network, the kinds you would want to reach to transit back to the Real, Physical world of Things and which are supposed to move ever closer to some form of smart dust… Whereas now, we often have the I and A1 usually at the front door, and the A2 somewhere in the/a network usually ‘near’ the end point (which also usually, is a relatively compute-enabled ‘large’ thing like a server with data).
Clearly, with the IoT we’ll need something else. All end points may float around somewhere out there, uncontrolled, un-tied-down in the giant global mesh network architecture. We will be systemically unable to tie any A2 server to an end point or vice versa (smart dust, spread out, remember), and the IA1-part will also be much, much less definable than it is today. But then, we’ll need much finer-grained access control at the end point, and much more flex at the (IA1) entry point or we leave it all free for all and only at the end point, the destination, check IA1 (again). For this IA1A2 at the end point, we need to consider:

  • The end point(s) will very probably have very limited computing capacity; even with Moore et al., this will still lag required resource in a big way – because any type of ‘attack(er)’ will have vastly more computing power available. Hence, things will need to be really really simple at this point. We may need to consider global IoT mesh network segmentation or other pervasive and comprehensively secure forms of IA1 at entry points (how to guarantee complete coverage) or throughout the mesh (how to prevent complete coverage without even the slightest possibilities of evasion).
  • Identities… ?? Where, how to manage the I’s and maintain the I+A1’s privacy, and transparency to the A2-owners ..?
  • How to arrange A2 at all those end points, including the ability to maintain those ..? The dust (or some coarser-grained proxy, whatever) is out there, and can’t easily be uploaded all with the latest A2 tables we’d want – or that is done by some broadcast flash approach which is all too vulnerable for cracked use.

But still, we need something of that kind. And transparency built in to that, too… To ensure No Backdoors and accountability in general, as these cute little hidden holes would be exploitable by all the bad guys (official, and not). By the way, #ditchcyber.

I’m aware there’s more problems than solutions in the above. But you should be aware of the risks of letting them remain unsolved. Your suggestions, please!

And, just so you know:

Not on our / I watch ..?

OK, so I wrote about the lack of API integration (yes, double) in IoT land. Which seems about to change. Now that this has come around. Tools in their early adopter stage, gotta love ’em. Next, the breakthrough.
Of IoT, too; but in what direction? Countries’ hardware infrastructures first, how deep down to B2C channels? The other way around, home channels all the way up? SocMed to wearables to life tracking blends? We’ll see. Maybe soon.

But for one thing: That geriatric-thinking pseudoreligion time-teller will not connect to the rest of the world. Sad (??). Will become the next one down. Hopefully.

For your viewing pleasure:
20140905_201020[Heaps upon Sea, indeed]

Maverisk / Étoiles du Nord