Written by Bill Gerba

Published: 23 June 2015

I don't speak German or Dutch or whatever language this funny commercial was produced in, but that doesn't stop me from getting the punchline loud and clear: when it comes to security and the Internet of Things, anything less than the best is going to have some very real-world repercussions:



Normally it's easy to find lots of flaws and gross exaggerations when reviewing a consumer-oriented advertisement that's trying to explain a complex and highly technical concept. In this case, though, I have to admit that virtually everything that happens to the lucky criminals looks not only plausible, but totally reasonable.

So while my first impression was "hah... funny," it was immediately followed by "uh... scary."

Written by Bill Gerba

Published: 27 May 2015

 

Considering how poorly our industry has handled security out of the gate. Here we are, 20+ years after the birth of the "modern" web and its tried-and-true protocols for securing electronic systms, and hardly a day goes by without hearing about another vulnerability discovered in an electronic lock, home automation gateway or cloud-based command-and-control system. It's gotten so bad that a Google engineer recently posted a video of himself removing and tossing out all of his Nest equipment because it has such severe security vulnerabilities (and keep in mind this was after Google bought Nest). Getting security right is hard, no doubt, but the majority of exploits out there today don't come as a result of security being hard. They come because the software industry in general has never taken the view that software security should come first. I'd be willing to bet that the vast majority of recently exploited software systems in the IoT world would fit into one of three buckets:

1) The NIH Bucket (which could also be called the "I'm more clever than you are" bucket)

Fifteen or twenty years ago you could probably make a good argument for developing your own security infrastructure. Open source initiatives were nowhere near as mature as they are today, and were still looked at with some skepticism. Many large manufacturers had enterprise-grade security options, but if they were available to license, they cost a pretty penny. And, of course, few even thought about software security the way they do today (hell, it took the payment card industry well into the 2000s before they got serious about it, and they handle billions of dollars of transactions every day).

You can pretty much imagine how that has worked out...

Unfortunately, while there are some extremely strong, well-proven and largely bug-free security models and implementations available for free, it seems that there are still lots of companies (and consumer-focused IoT startups seem to be the worst offenders here) who simply feel that they must roll-their-own. This is definitely not the right place to try and leave a mark (unless you're the NSA, maybe).

2) The Invisible Features Bucket

Time is money, and even the largest organizations don't have truly unlimited resources. Consequently, as time and bugdet constraints kick in, program managers start looking to their software people to perform miracles. Unfortunately, when push comes to shove, often the first features to get shelved are the invisible ones -- those critical background processes that make the product work, but aren't flashy or shiny, or, often, visible at all to the end-user. While I wouldn't go so far as to say that companies are shipping products entirely devoid of a security infrastructure, the unfortunate truth is that there is a huge difference between a working security model and an almost-working one. You know that old addage "the perfect is the enemy of the good?" Yeah, that's not true when it comes to computer and network security.

3) The Hand-me-down Bucket

Times change, and so do technologies. What might have been a best practice years ago when your product reached version 1.0 might be known as a buggy, exploitable mess  today. And while it's often impractical or even impossible to bring everybody up to the latest-and-greatest security standards, companies serious about selling M2M and IoT solutions need to at least be willing to upgrade newer devices and make sure that future devices use the most up-to-date security practices and protocols. Unfortunately, there are plenty of examples of even large organizations skipping this step, probably in the name of time/budget limitations or perhaps for the mundane reason of keeping the server-side architecture simple.

So what's the solution?

The problem is real, and not just sensationalism. Network World actually has a Network World IoT security article on it. The good news is that the solution is already at hand, and it's free (as in beer) and free (as in speech). I'm of course talking about the open and established standards that our good friends in the open source community have put together, along with the RFCs and standards published by the Internet's various governing bodies. Even ultra low-powered devices are now capable of encrypting and decrypting packets using the AES cipher, and most can handle TLS3, the web's most up-to-date encryption scheme that puts the "S" into "HTTPS." One-way ciphers can easily be computed using large block size SHA encryption, and most devices today (and virtually all tomorrow) are computationally capable of X.509 certificate based client authentication. Simply put, there is no good reason to develop in-house security protocols and mechanisms anymore. Virtually every single part of the software security stack is now available for free, as highly-reviewed, well-documented source code libraries, most of which are further licensed under very business-friendly terms. What's more, there are a large number of verifiable experts-for-hire out there who can have tremendous experience working with these libraries, and a vibrant ecosystem of researchers and supporters making constant code tweaks and contributions.

In short, it's a great time to be developing software and services that need to connect to the cloud securely.

So why do we still seem to be having so much trouble with it?

 

Written by Bill Gerba

Published: 24 April 2015

Smart home company Wink had a bit of a bump in the roat last week when an errant software upgrade accidentally brickeed a fair number of users' home automation hubs. According to Engadget, the root cause was an expired authentication certificate, which at least suggests that the company's taking a sane approach to security (indeed, their original announcement about the problem explained that the hubs were made to become "so secure that it is unable to connect to the Wink servers."

Fortunately for Wink users, the company was able to recover the majority of the devices with another software update. Unfortunately, it does seem that some of the hubs were well and truly bricked, so the company has offered not only to repair/replace them, but is also giving inconvenienced owners a $50 credit at the company store. Home Depot has pulled the devices from their stores for now, but they'll presumably be back on the shelves once the devices get updated and confidence in the company is reinstilled. This does raise a couple of interesting questions, though, chief among them:

• Do Home Depot and other big box stores pushing home automation, etc. have plans in place for supporting the customers that come back to them when something goes wrong?
• Will Wink and others that have cloud subscription models wind up escrowing some or all of that money to handle the occasional screw up, or will it simply be a new cost of business going forward/
• Will companies like Wink have to share some of their subscription money with their retail partners to help them offset the damage that occurs when system-problems happen?
  

and finally...

• Doesn't Wink test their stuff before deploying?