Securely Surfing the IoT Tsunami

Advertisement

Securely Surfing the IoT Tsunami

The IoT wave is building like a thunderous tsunami, growing larger on the horizon by the day. What is missing from the conversation, however, is how large a role software plays in the IoT equation. Plugging something into the Internet does not make it work -- it just makes it vulnerable. Value is created through the associated software. In fact, we have almost reached the point where the actual product or device and the associated software become a single logical unit to the consumer. Allow me to connect the dots.

An IoT device is, by definition, connected to the Internet. For the device to function with any degree of intelligence and value, there must be software. If software is not designed and constructed to be secure, it will contain vulnerabilities that can be exploited to gain access to the device. This means that anything connected to the Internet can be discovered and potentially infiltrated, and the associated software will be the target.

We used to do a practical test back in my days at Cybertrust. We would purchase a PC from a big box store, disable its protections, and plug it into the World Wide Web. Within minutes it would be discovered, and minutes later it would be infiltrated. The illustration was simple: anything connected to the Internet can and will be discovered and breached. There is no reason to believe that IoT devices will be any different, and most are not equipped to protect themselves from attack.

The software story does not stop with the software directly associated with the device. Connected devices collect data and send them to a collection point in a back-end application. If the device is compromised, it becomes possible to extract the device’s data, or collect credentials to attack the back-end system and the stored data. Infiltration of a device provides hackers with a pivot point to reach other targets. Many IoT devices come with a mobile application or a web application to either display information or control the device, so there are multiple layers of software in play.

You may be thinking that this is a lot of concern for software created for a smart thermostat. It pays to remember that attackers are quite adept at finding a crack, squeezing through and then pivoting to other things. At Target it was the HVAC system that was breached and used to access the Point of Sale systems. For a consumer, a thermostat could be used as the entry point to access the home security system.

The bottom line is that software is an immutable part of the equation, along with all of the associated security issues. Many of the industries building IoT devices and embedded systems do not have the same level of experience with software security as their counterparts in financial services, and may not have mature software security initiatives. History has shown that in that context, the developers writing the IoT software will assume the developers writing the back-end application are handling security. Meanwhile, the back-end application developers assume that the mobile application developers are handling security – so in the end, security is not integrated into the software development life cycle (SDLC).

If you are getting a sense of déjà vu, don’t be alarmed. You have seen this all before. We saw it as applications moved onto the Web, and, more recently, as applications moved to mobile devices. In both cases, by the time we realized what was happening we were already on a dangerous trajectory, amassing technical debt and desperately trying to bolt security onto systems after they had been compromised.

We need to build security in. That starts by building a software security initiative (SSI) and creating a software security group (SSG) to ensure someone is held responsible and accountable. Doing so sets the tone for the developers and management, and provides a visible indicator of our commitment to security for customers and other stakeholders to see.
With an SSI and SSG in place, organizations can integrate security into every aspect of the SDLC. The purpose is not to slow it down with security constraints, but to increase productivity by eliminating the need to find and fix security vulnerabilities after the fact. Organizations should apply sound security practices to architecture, which can eliminate 50 percent of the vulnerabilities at the source. There are companies that have successfully eliminated the OWASP Top 10 completely from their software.

Organizations should educate developers so that they understand their role in the security process and so they don’t repeat the easily identified and well-understood mistakes of the past. Incentivizing developers integrates security into their mindset. Another strategy organizations should consider is looking for tools that live in their environment and identifying vulnerabilities in near-real time so they can be fixed in the moment, eliminating interruptions to the development process. Individual groups within enterprises must never assume that security is someone else’s responsibility.

Threat modeling is another technique that can help organizations to see the vulnerabilities that live in the cracks between the components. Companies can partner with application testing partners that provide the elastic capacity to execute tests as needed to avoid slowing down the development process. Insisting that these vendors create findings of high fidelity helps developers avoid wasting time running down false positives, or worse, ignoring the findings because they simply have too much noise to be practicable.

None of these things are necessarily new or revolutionary. What is revolutionary is the idea of building them in at the beginning, rather than having to bolt them on after we discover the error in our ways. I can assure you that building in has far fewer consequences that bolting on. It is more efficient, less expensive and far less impactful to productivity.

Read more..

Tweet

Subscribe to receive free email updates: