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 …

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.

By now one would hope that the worst of the Heartbleed crisis is behind us. All the servers should be patched, new certificates generated and passwords changed, right? The answers are: probably, hopefully and unlikely, respectively. Compromised passwords are still floating around in the ether so if you haven’t fixed them, do so.

But what about the next Heartbleed? One thing that is about as sure as death and taxes is that there will be another massive vulnerability that will, no doubt, expose millions of user accounts. So, do we just sit tight and wait for the oncoming storm or is there a preemptive strike you can make now to less the likelihood it will impact you in a big way?

I think there is and it’s the subject of my recent post to the IBM Security Intelligence blog. Take a read through it and stay safe.

 

 

 

 

 

Here’s a link to a posting I did for IBM’s Security Intelligence Blog on the perils of ignoring the whole Bring Your Own Device (BYOD) trend. Enjoy …

http://securityintelligence.com/byod-why-you-better-not-ignored-it/

 

 

A quick “heads up” that I will be presenting on the topic of Social Media Threats on Friday, March 7, at the Delaware Valley Chapter of the Information Systems Security Association. Here’s a link for more info:

www.issa-dv.org/meetings

Also, I’ll be presenting on Access Management and Federated Identity Management on Thursday, March 20, at the Harrisburg (PA) Chapter of ISACA (previously known as Information Systems Audit and Control Association). Link below:

www.isaca-harrisburg.org

So if you’re looking for some CPE’s and will be in the area, please drop by and say “hi.”

An update to my post from last week regarding vulnerabilities in WiFi access points …

Team Cymru, a non-profit security research organization, recently reported that some TP-Link wireless routers had been compromised in such a way as to redirect the DNS (Domain Name System) requests to a couple of suspicious IP addresses.

Without going into the technical details of what this means the effect would be that a hacker could reroute traffic from those home networks to a destination of his choosing. In other words, a user types “www. google.com” into their browser and ends up instead at “www.hacked-google.com” or some such. Scary stuff since we all depend on the DNS to get us to the correct web sites, connect to our email and so forth.

Team Cymru then updated their findings this week to reveal that they have identified more than 300,000 such home routers that have been compromised and the list includes not only TP-Link models but also those from D-Link, Micronet, Tenda and more.

My previous post focused on Linksys equipment so, as you can see, the larger problem of vulnerable WiFi access points and routers runs across the various manufacturers. In other words, don’t think you’re safe just because your particular make and model hasn’t been explicitly listed so far. It’s probably just a matter of time.

So now that we know the risk is real and not just theoretical, what should you do? Here’s some good advice from Team Cymru as summarized by PC World:

“Team Cymru researchers advise users to disable remote management over the Internet on their routers and to keep their firmware up to date. If remote administration is absolutely necessary, steps should be taken to restrict remote access to only particular IP addresses. Other recommendations include: changing the default passwords, not using the default IP address ranges for a LAN, logging out every time after accessing the router interface, checking the router’s DNS settings frequently to ensure they haven’t been modified, and using SSL (Secure Sockets Layer) to access the router’s Web interface if the option is available.”

Hopefully, one day all our routers and access points will be able to securely patch themselves as we have done with Windows, OS X and others, but until that happens, you now at least know what to do.