‘Men occasionally stumble over the truth, but most of them pick themselves up and hurry off as if nothing ever happened.’ — Winston S. Churchill
The Internet of Things (IoT) has brought us to a precipice that we have seen before: a new wave of software development is beginning to form that will crest in size beyond our ability to forecast. We saw it as applications moved onto the Web, and, more recently, as applications moved to mobile devices. In both cases, we did not stop to consider security until the toothpaste was already out of the tube and could not be easily put back, says Jim Ivers, CMO, Cigital.
IoT will create a surge in software development that will be unprecedented in scope and reach. Why? It’s simple.
First of all, a connected device is, by definition, connected to the Internet. Anything connected to the Internet can be discovered and potentially infiltrated. Secondly, for the device to function with any degree of intelligence, there must be software. Software not designed and constructed to be secure will contain vulnerabilities that can be exploited to gain access to the device. Finally, 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 this data. Infiltration of a device provides hackers a pivot point to reach other targets. For example:
- For consumers, the access to the home router may provide a path into the home’s alarm system.
- For businesses, intrusion into a HVAC system may provide a path to POS systems, such as what happened at Target.
The bottom line is that software is an immutable part of the equation, as is all of the associated security issues. Many of the industries building IoT devices and embedded systems do not have the same experience level with software security as their counterparts in financial services and may not have mature software security initiatives. One problem is that the developers writing the IoT software will assume the developers writing the back-end application are handling security. Meanwhile, the back-end application developers are assuming the mobile application developers are handling security. And so it goes.
In other words, we are doomed to repeat the sins from web application development and mobile application development. Somewhere the ghost of Churchill smiles wryly. So how do we not pick ourselves up and hurry off as if nothing ever happened?
We build security in. We start by making a commitment to security by building a software security initiative (SSI) to demonstrate that commitment and by standing up a software security group (SSG) so someone is responsible and accountable. Doing so sets the tone for the developers and management, and is a visible indicator to customers and other stakeholders.
We integrate security into every aspect of the SDLC. 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. We apply sound security practices to architecture, eliminating 50% of the vulnerabilities at the source. There are companies that have successfully eliminated the OWASP Top 10 completely from their software.
We educate developers. We want to make sure they understand their role in the security process so they don’t repeat the easily identified and well-understood mistakes of the past. We incent those developers to integrate security into their mindset. We look for tools that live in their environment and identify vulnerabilities in near-real time so they can be fixed in the moment, eliminating interruptions to the development process. We insist that they never assume that security is someone else’s responsibility.
We perform threat modeling. This enables us to see the vulnerabilities that live in the cracks between the components. We partner with application testing partners that provide us the elastic capacity to execute tests as needed to not slow down the development process. We insist that these vendors create findings of high fidelity so developers do not waste their time running down false positives, or worse, ignoring the finding 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.
The phrase, “Those who do not learn history are doomed to repeat it,” is not from Churchill, but it nonetheless fits here. IoT related development will grow exponentially and we need to choose to learn from history or repeat it. To stumble over the truth and, instead of hurrying off, recognise it as truth and apply the wisdom attached.
The author of this blog is Jim Ivers, CMO, Cigital.
Comment on this article below or via Twitter: @IoTNow_ OR @jcIoTnow
