The need for a new security framework

… I feel the need for it. A new security framework.

Because what we have, is based on outdated models. Of security. Of organisations. Of how the world turns.
Bureaucracy doesn’t cut it no more. The very idea of hierarchically stacked framework sets (COSO/CObIT/ISO27k1:2013/…) likewise, is stale.
And the bottom-up frameworks en vogue, e.g., OSSTMM (if you don’t know what that is all (sic) about, go in shame and find out!) and core work like Vicente Aceituno Canal’s, haven’t found traction enough yet, nor are they integrated soundly enough (yet!!) into further bottom-up overarching approaches. Ditching the word ‘framework’ as that is tainted.

But what then? At least, OSSTMM. And physical security. And SMAC. And IoT. And Privacy (European style, full 100.0%, mandatory). And business-organising disruption, exploded labour markets, geopolitics, et al.

OK. Who of you has pointers to such an Utopia ..? [Dystopian angles intended]

Unrelated:
DSCN6146
[Your guess. Not Nancy. But is it Reims ..?]

Ah, your home controlled by …?

In the race to grasp as much of the market as possible, which is understandable, one party jumps in to create the API of APIs we’ve all been waiting for, among others (since this) in this domotics category.
But … will we surrender even our in-house as-yet unconnected lifeblogging data to one of the parties that don’t have the best of track records re privacy …? I mean this one. With an odd name

Oh yes, I hear you suppress your fears … with empty words, given that even at chip level intrusion and (data) extrusion seems to have been possible, and in the wild, already for years.
So, this one party grabbing your data at software level may even be an ‘improvement’ for transparency … the devil you know (but still don’t see) – how’zat for self-censorship in your house? Even when with a required warrant, will (tending to casual, ubiquitous) surveillance in your own home be the future?

Well, I’ll go cleaning up. With said product (name) of course…. And:
DSCN1283
[Preferably, the non-scratching kind … London already a decade ago]

Simple link: BYOD is the New Wi-Fi

Very true. Though we may even say: BYOD was the new WiFi, as BYOD is so 2013 … but let’s await the resurrection of WiFi when IoT-in-the-shape-of-ubiquitous-computing takes off…
BYOD is the New Wi-Fi – Infosecurity Magazine.

FogAI picture

… Just to put it out there: What has happened to all the thrilling AI initiatives that flew around one after the other at the start of the year ..?
At that time, I even included some stuff in my Predictions, as so many new things were popping up. But now, … not so much. Because what?

Or have all the ‘leaks’ been thumbplugged and is development still going strong in skunk works towards a renaissance explosion sometime soon ..?

Whatev’; for you:
DSCN2101
[Its back being Mont serrat. Or so. ?]

Signalling healthy process

Yet some more cross-over ideas from the IoT world into the administrative bureaucratic office world: Streams of transactions as signals.
Of the health of the process, of course. To be defined, obviously, as the fit to the surroundings. The fit may be off, either intentionally (wanting to let the world adapt to the process, enforcing (?) change) or unintentionally left blank                i.e., having to cope with exceptions to what was envisaged as transactions’ content or form.

Now apply yesterday’s first picture of process control.
Now, too, consider what one could do with sampling theory (as a subset of ‘Shannon’, if properly elaborated, possibly skirting with ‘classical’ statistics ..?). Taking 2log(n) samples (where n is the number of transactions ..?? Just a wild guess) and being able to reconstruct the ‘signal’ then taking its integral (discrete transactions … just summing it up ..?) for the total. Or Fourier-transforming it all and … get your basic theory straight before dreaming of moving on so don’t start at the other end as ‘accountant’…! And/or treating exceptions (as e.g., found by the sort of analysis that these girls/guys are so good at; that not even being meant as a cynical qualifier) as noise to the signal. Never fully suppressable, but useful to pick up secondary signals, stacked in their variation of frequencies, amplitudes an wavelet transformations. That all tell you something, if you listen. Whether you want perfect, over-HiFi replay [intermission: Ugh I’m getting old, even knowing that HiFi was a thing…], or lively veracity, actual fullness of music. And take in again the ole’ industrial process control with its recipe / derivative function(s), et al., and be able to better control it all from the ‘dashboard’ in the control room. When all of the routine stuff, the routine 80%, of business is done by … ‘robots’. Humanoid or digital-machines, IDC.

And hey, while we’re at it, why not throw in attempts to include in bookkeeping not only discrete numbers (arbitrarily rounded to hunderds, of random currencies) but Real numbers or even Complex numbers as well ..? The latter, e.g., to indicate VAT surcharges, etc.; leading to tuples-as-single-‘numbers’ in bookkeeping. Maybe somewhat harder to track that all is booked correctly, but also maybe powerful in capturing singular transactions and some processing rules/logic, and controls, in one tuple (‘record’).

Where AI may then be applied to do sanity checks. Not on this author; no AGI or ASI would suffice…

OK, for now:
DSCN1436
[“What a shoe box” but yes that *is* the Bata shoe museum, Toronto]

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:
DSCN4777
[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 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:
DSCN3214
[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]

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]

Maverisk / Étoiles du Nord