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?