, , , ,

Lately it seems like the news is full of a new security vulnerability with a catchy name every few weeks. We had Heartbleed disclosed last April. Then Shellshock disclosed at the end of September. Now it’s POODLE (Padding Oracle On Downgraded Legacy Encryption) disclosed earlier this week by researchers at Google.

All three of these share the common feature of having a good catchy name, making it easy for them to get airplay in the technical (and even mainstream, in some cases) media.

These (and the many, many more bugs without good PR) all raise the natural question: “How worried should a developer be?”. But with good PR and wider coverage the question may well widen to “How worried should an ordinary person be?” which for those of us who are the go-to source for all questions about technology from friends and family can be paraphrased as “what do I tell my mother?”.

So, what do I tell my mother?

This question has a fairly easy answer: “Not very, assuming you keep your PCs, phones, and other devices patched.” Of course, the devil is in the details. The PCs, phones, and tablets are the easiest to deal with.

Their vendors should be providing security (and just plain bug fix) patches.

And they should already be applying them.

Every update, every time. If possible, the updates should be applied automatically. This has been good advice for quite a few years now. A Windows PC bought off the shelf from a big-box store arrives with Windows update set to “fully automatic”, and for most home users there is no reason not to leave it that way. (Mac users are on their own, I assume Apple provides security updates. Apply them.)

Aside from that, the remaining advice just boils down to “don’t be stupid” and “don’t panic”. Feel free to adjust wording to suit the audience, of course.

Should I worry myself?

If you design software for a living, then yes you should probably worry a little bit. If your software gets deployed widely, then worry a tad more. Primarily, worry enough to make sure you (really the party doing the wide deployment) have a plan and process that allows for field updates of that software. Even if none of these three issues relate to your product today, there is always something that could be discovered in the future.

If your software is deeply embedded firmware that has no connection to the real world other than the direct effect of the device it operates, then there is likely little to do other than a good job.

But do remember that recent too smart light bulb that provided a way to register and control a room full of them from your mobile device and turned out to have a bug that leaked the home network WiFi key. So pay attention to the larger system your software is involved in, ask dumb questions, and if needed get security professionals involved.

If you are developing anything playing in the Internet of Things space, it is probably a really good idea to get security professionals involved. When a stolen WiFi can lead to theft of personal data stored or transmitted on the otherwise secure network, you really don’t want to be the one that produced that bug.

With the price of the Raspberry Pi floating around $40, and industrial modules with similar capabilities running well under $200, it is becoming common to drop complete Linux-based computers in places where a custom deeply embedded system might have been the norm just a few years ago. But that complete Linux carries with it a much broader attack surface. So should you be worried?

Again, not really. But you should stay patched, and that includes keeping the Linux distribution you use for those devices patched as well.

But of course you are fully patched and up to date already, right?

(Written with StackEdit.)