At some point, you’ve likely seen markings and icons on an electronic device, its user manual or the box it came in. If you’re unsure what these markings are, they are almost certainly some type of certification.

Some time ago, we started testing goods for safety before they hit the marketplace. The reason was simple: to mitigate risk. We do this today with many electronic devices, testing for things like radiation and to make sure the battery-powered widget doesn’t catch fire in your hands.

But what about connected devices?

While we do test internet of things (IoT) and other connected devices for the aforementioned safety hazards, what we don’t test for is cyber safety.

Good Code Is Not Cheap

Connected devices typically go through a series of hardware checks and certifications before they hit the market. In virtually every part of the world, they have to, whether it is to make sure the device doesn’t have any toxic materials or that it isn’t operating on a prohibited frequency. From a safety perspective, we’re doing relatively well; it’s the software side that is cause for concern.

Let’s face it: Good code is not cheap. Exact figures are difficult to find, but as an estimate, well-written code could end up costing 5–10 times more than poorly written code. From a business perspective, figures like that can throw your entire cost model out the window and shut you out of a market. It’s also quite likely that it will take longer to develop the code, adding yet another delay to market deployment. These are the kinds of things that make business leaders shudder.

But let me tell you some good news: The industry gets that this is a problem, especially in the IoT space. So we are not asleep at the helm, but rather, we’re looking for ways to figure this out.

For example, the major telecommunication providers recognize that all these connected devices will likely touch their network at some point, so they’re taking steps to protect themselves. They’re doing this by working together with certification houses to make sure devices are safe to operate on their own networks. It’s a type of self-protective measure, since it will be the telecom companies freaking out when the army of controlled IoT devices decides to unleash distributed denial-of-service (DDoS) attacks over their infrastructure. So it’s a good move on their part, especially since 5G means we’re going to have a lot more devices to worry about, and a certain endpoint security disaster if mismanaged.

The Unicorn Connected Device

Wouldn’t it be fantastic if we could pick up a mobile device, straight out of the box, and have confidence that there are no software vulnerabilities? Imagine how much easier endpoint security would be! Of course, that hasn’t happened, and the reason is simple: Secure code-writing doesn’t operate at the speed of business. That’s why we have these things called updates and, for all you seasoned security pros, you know keeping devices updated across your enterprise is a difficult task even on the best of days.

The task will only get more difficult because mobile usage is on the rise. This could come across as oxymoronic, but connected devices today are mobile, and these mobile devices are vulnerable points of entry into a network.

This simple fact even compelled the U.S. Federal Trade Commission in 2016 to issue an order to mobile device manufacturers to produce information on how they handle security updates. The sobering 2018 follow-up to the order stated:

“[S]upport periods, the time during which a device receives operating system updates, and update frequency vary widely, even among devices that cost the same, are made by the same company, or are serviced by the same carrier. A device may receive security updates for many years — or, in some instances, may not receive any updates at all.”

In other words, it’s all over the place. With devices of all types multiplying at dizzying rates, endpoint security — at least in the near future — is going to become that much more important.

Short-Term Endpoint Security Solutions

It all comes back to well-written code, and there is a case to be made that today’s code is not written using security-by-design principles and methodologies. I can say this with a high level of confidence, because if these principles and methodologies were being used for connected devices, we’d have a whole lot more secure systems.

Therefore, short of a sudden change of heart in which all developers and manufacturers decide to uniformly and voluntarily adopt NIST’s “Special Publication 800-160, Systems Security Engineering” for all of their development, we’re going to need to think of a better way to keep these connected devices from mucking up networks.

How do we do that? Here are a few options to get started:

• Endpoint security until whatever comes next. Endpoint management services and products, along with smooth functioning security information and event management (SIEM) and security orchestration, automation and response (SOAR) solutions, are your best near-term friends. There are just too many endpoints out there, and it’s worthwhile to rethink how we go about endpoint security management. What do I mean here? Instead of being reactive and waiting for a device to do something bad, maybe we should just prevent the device from doing it at all. Of course, this will not be an easy discussion in most organizations, which is why it is imperative for the security team to learn the business language of leadership.

• Rigid policies for connected devices. It’s pretty simple: Limit the types of devices that are allowed to touch your network. Again, expect pushback here for a variety of reasons, but if you can make the appropriate business case, you may find that buy-in you’re seeking.

• Uniformity of connected devices. Yes, this sounds pretty boring, and different business needs have different technology requirements. But if resources are stretched, until a better solution is found, try to use the shortcut.

Fixing the Problem at the Source (Code)

Time for my preferred and favorite option: The cybersecurity industry joins together to create a certification consortium or body with the sole purpose of mitigating risk that exists in code. NIST 800-160 is a good place to start, but it may not be for everybody.

This is obviously a long-term solution, but it is neither unheard-of nor undoable. You see it in other industries and you can easily make the case that it’s good business, especially in the long term. I’ll even suggest we’re in a good spot right now because next-gen tech is still in the early stages of deployment, and we can perhaps avoid our past follies of building and building and building upon inherently vulnerable systems.

Is this proposal hard? Yes. Impossible? Absolutely not.

Ultimately, if only certified devices make it to the legitimate marketplace — think UL-type certification for software — then the pressure is on the developers and manufacturers to release a quality product. If that can happen, you’re addressing the problem right at the source: the code. And that’s an excellent way to protect our connected devices and networks all in one shot.