Archive for June, 2014

Toilet-My SATISSo, you thought IoT stood for “Internet of Things,” right? A reference to the instrumentation of all sorts of previously stand alone devices like refrigerators, washers, dryers, thermostats, implantable medical devices, cars, etc., in such a way as to make them accessible from via the Internet. Cool stuff … when it works. When it doesn’t? Not so much …

How about a high tech toilet that lets you use your Bluetooth enabled phone to as a remote control to:

  • raise and lower the seat
  • flush
  • turn on the bidet feature (for the uninitiated, this means a stream of water is sprayed at your private parts)
  • and who knows what else?

I guess it could be interesting if you really get bored in the bathroom but, even as someone who loves technology, I’m just not sure that this sort of confluence of water, electricity and sensitive body parts should be brought that close together, if you know what I mean.

What if said toilet had a security flaw that allowed essentially anyone within Bluetooth range (which is supposed to be about 10 meters but can be extended substantially if you know what you’re doing) to control all these functions remotely without your permission?

And what if robo-potty also kept records of all your, let’s say, “activity” for reasons I’m not sure I even want to know?

Well, that’s the case with the My SATIS “luxury” toilet, where it turns out that the Bluetooth code for all the devices is hardcoded as “0000” and can’t be changed, according to a report from the BBC. That means that anyone with an Android phone can download the app, connect to your porcelain convenience and have a grand ole time at your expense.

Take it all one step further and make it part of a “connected home” ecosystem, which, thankfully, hasn’t been done yet and you could imagine the range for these attacks going global.

Brave new world? I certainly hope not …

Advertisement

Recycling great, except for when it isn’t. To see what I mean, take a look at my post on securityintelligence.com.

It’s all about speed these days — quicker deployment, shorter time to value, instant gratification. Historically, though, one of the friction points in IT has been the invisible wall between Development, who writes the code, and Operations, who supports the real world implementation. DevOps is concerned with knocking down that wall and greasing the skids, as it were, in order to achieve a more agile and responsive software development and deployment cycle.

But what is sacrificed in the process? What risks are introduced by this amped up mode of operation?

If you aren’t careful, the answer is security.

So, some of my colleagues and I put together a brief overview on the Security considerations for DevOps adoption which was just published over on the IBM developerWorks web site. In the paper we discuss some of the issues that need to remain top of mind so that you can still realize the benefits of DevOps without killing security in the process.