Skip to main content

Welcome to the Future!

The security police are starting to crawl out of the their bunkers once more to shout and scream about the mess that has been left behind by the enthusiastic but naive, avant garde of technology - the Internet of Things. Steven M. (I'm sure he has longer surname somewhere) has a post over at Linked-in on this titled Should I care about the Internet of Things?

Depending on your viewpoint, advocates of IoT are either leading us into a bright new shiny future where everything talks to everything else in a glossy-white plastic world where robots beep-beep their way to satisfy your every whim, fridges restock themselves before you know you've run out of milk and cars drive themselves 6 inches apart on highways made of strawberry milkshake, or, a world where killer robots are roaming free, terrorists are randomly restocking your fridge with tins of baked-beans (I really don't like baked beans) and cars spontaneously crash of their own volition, polluting the otherwise natural beauty that is the strawberry milkshake highway (which is a given fact the future holds for us!). I may have got some of that muddled up...

Anyway, as with Steven M. also, analogies with the biological world abound (and here I'll no doubt get another complaint from my brother-in-law) and I have to say I'm kind of attracted to the idea of self-organising, self-replicating (in a virtual sense at least) systems that learn and are ready to do our bidding. It will though expose us to new attack vectors we've barely begun to dream up - shit will happen my friends!

Personally I think we'll nail the sort of security issues that plague us today - code injection attacks, poor data encryption and access control policies etc. - but we're just not thinking about future issues in the right way; mainly because futurologists are full of shit (generally at least).

So if we take the biological analogy a few steps too far then what sort of risks will we face? Positive feedback leading to runaway processes? Sophisticated virtual bacteria roaming the net, consuming all resources in their path? Today it's all too easy to spin up a few hundred machines in the cloud to initiate a DoS attack - brutal but often effective and with few options to remedy - but this stuff will become so elaborate and complex in it's integration as to become something of a wonder in itself. And the less we say about it becoming conscious the better (even though I reckon that's where we're headed...). Like I said, futurologists are full of shit...

Should we care about IoT? Definitely! It's cool stuff, it's going to happen but it's not going to be as awesome as the sales guy says. The hype is over and it's time to suck-up some negativity and let reality sink in.

And mark my word! The day will come when you have to book an appointment with the doc because your house has come down with some nasty bug, is vomiting sewage into the hallway, spraying water all over the kitchen and it's 45°C inside as the central heating goes into overdrive... Welcome to the future - as shit tomorrow as it is today!

Comments

Popular posts from this blog

An Observation

Much has changed in the past few years, hell, much has changed in the past few weeks, but that’s another story... and I’ve found a little time on my hands in which to tidy things up. The world of non-functionals has never been so important and yet remains irritatingly ignored by so many - in particular by product owners who seem to think NFRs are nothing more than a tech concern. So if your fancy new product collapses when you get get too many users, is that ok? It’s fair that the engineering team should be asking “how many users are we going to get?”,   or “how many failures can we tolerate?” but the only person who can really answer those questions is the product owner.   The dumb answer to these sort of question is “lots!”, or “none!” because at that point you’ve given carte-blanche to the engineering team to over engineer... and that most likely means it’ll take a hell of a lot longer to deliver and/or cost a hell of a lot more to run. The dumb answer is also “only a couple” and “

Inter-microservice Integrity

A central issue in a microservices environment is how to maintain transactional integrity between services. The scenario is fairly simple. Service A performs some operation which persists data and at the same time raises an event or notifies service B of this action. There's a couple of failure scenarios that raise a problem. Firstly, service B could be unavailable. Does service A rollback or unpick the transaction? What if it's already been committed in A? Do you notify the service consumer of a failure and trigger what could be a cascading failure across the entire service network? Or do you accept long term inconsistency between A & B? Secondly, if service B is available but you don't commit in service A before raising the event then you've told B about something that's not committed... What happens if you then try to commit in A and find you can't? Do you now need to have compensating transactions to tell service B "oops, ignore that previous messag

Equifax Data Breach Due to Failure to Install Patches

"the Equifax data compromise was due to their failure to install the security updates provided in a timely manner." Source: MEDIA ALERT: The Apache Software Foundation Confirms Equifax Data Breach Due to Failure to Install Patches Provided for Apache® Struts™ Exploit : The Apache Software Foundation Blog As simple as that apparently. Keep up to date with patching.