I recently got a US patent application granted by the US Patent and Trademark Office. The patent bears the title “System, Device, and Method of Managing Trustworthiness of Electronic Devices​”.

On July 12^th, I was interviewed on Security challenges of organizations deploying IoT. The recorded (and transcribed) video interview can be found here. For those who prefer a written abstract, here is the outline of what I said in reply to a short set of questions about the security challenges with IoT deployment, and the approach followed at Pelion to overcome them.

On May 12^th, the Biden administration issued an Executive Order that was written to improve the overall security posture of software products that the government buys from the private sector. Recent events, such as the SolarWinds hack, contributed to the realization that such a move is necessary.

This Executive Order is a big deal. Of course, nothing will change overnight, but given the size and complexity of the software industry, as well as the overall culture behind software security (the culture of: “If the customer doesn’t see it — don’t spend money on it”), an Executive Order can probably yield the closest thing to immediate improvement that we could reasonably wish for. The US Government is a very large customer, and all major vendors will elect to comply with its requirements rather than cross it all off their addressable markets.

A lot has been written on how important it is for the government to use its buying power (if not its regulatory power) to drive vendors into shipping more secure products. Product security suffers from what could best be described as a market failure condition, which would call for such regulatory intervention.

To not overly repeat the mainstream media, I would like to focus on one unique aspect of the current Executive Order, and on how it can ignite a new trend that will change product and network security for the better. I’ll discuss true machine-readable security documentation.

I have been saying that one of the challenges with securing IoT is that IoT device makers don’t have the necessary security background, and the security industry does not do enough to make cyber-security more accessible to manufacturers. We should therefore not be surprised that 150 years of experience in making robust safes and transferring money securely, did not help Brinks once they introduced a USB slot into one of their new models.

Today I attended CyberDay 2015, where I delivered a lecture titled “Challenges in Securing IoT”.

Some of the lecture was devoted to discussing the issues mentioned in this post. Other issues were discussed as well.

As much as there is hype about the Internet of Things (IoT) and protecting it, there is no such thing as “IoT Security” per se. There is just the usual security engineering that is applied to IoT. Security engineering is about determining assets, threats to assets, and cost-effective means of mitigation. There are many models and ways for carrying out such analysis, but for the most part they all boil down to those key elements. Such security analysis applies to networks, it applies to servers, it applies to cars, and it also applies to IoT. That said, security engineering in IoT does pose a few unique challenges, which I would like to discuss now.

An article and interview with me by Byron Acohido of ThirdCertainty about why surveillance cams are trivial to hack. The discussion also covers the stance of IoT security in general.

The Poodle flaw discovered by Google folks is a big deal. It will not be hard to fix, because for most systems there is just no need to support SSLv3. Fixing those will only imply changing configuration so not to allow SSL fallback. However, this flaw brings to our attention, again, how the weakest link in security often lies in the graceful degradation mechanisms that are there to support interoperability. Logic that degrades security for the sake of interoperability is hard to do right and is often easy to exploit. Exploitation is usually carried out by the attacker connecting while pretending to be “the dumbest” principal, letting the “smarter” principal drop security to as low as it will go.

All this is not new. What may be new is a thought on what such types of flaws may imply on the emerging domain of the Internet-of-Things.