IoT security begins with building secure software. Learn how to embed security into your SDLC to avoid becoming an easy target for hackers.

In this, the final week of 2020’s National Cybersecurity Awareness Month, the focus is the future of connected devices. 

And some things about that future are pretty easy to predict. 

There will be more devices—billions more. As some experts started saying several years ago, the Internet of Things (IoT) is rapidly becoming the Internet of Everything (IoE), since everything is becoming a computer—your thermostat, stove, refrigerator, washer, dryer, vehicle, door locks—even things like lawn mowers and vacuum cleaners.

The growth of IoT

Indeed, the number of connected devices has exploded in just the past three years, from about 7 billion to an estimated 30-plus billion. That growth shows no sign of slowing.

What’s more difficult to predict is what that will mean for society. If the state of security and privacy of connected devices continues on its current trajectory, it could be a dystopian future. Supposedly “smart” devices will be riddled with vulnerabilities that hackers will exploit to steal credentials and identity, and extort or blackmail users by threatening their physical safety. Expanded data collection by Big Tech will make smartphones even more intrusive surveillance trackers than they are now.

Stronger IoT security

But it doesn’t have to be that way. It could be a world where the software that powers all those devices has security and privacy controls built into it. It could also be designed to allow updates and patches as vulnerabilities are discovered and threats evolve. 

It won’t make IoT devices bulletproof—nothing will—but it could make them much more resilient. Better software security could be the digital version of seatbelts, airbags, antilock brakes, lane assist, and other safety features in cars. They don’t eliminate accidents, but they help drivers avoid them and offer more protection when they do happen.

And that’s possible. The tools, technology, and methods exist to make the software running connected devices much more secure and resilient. They just aren’t getting used nearly as much as they should be.

One reason for that has been widely reported: users don’t care about security—at least not yet. They are primarily focused on the features and price of devices. Security is barely an afterthought—it’s not yet a “differentiator” for consumers. So manufacturers give them what they want—cool features and a good price—without thinking much about IoT security.

Tim Mackey, senior security strategist within the Synopsys Cybersecurity Research Center (CyRC), said another reason so many recently connected devices are insecure is their lifespan, which is years longer than those of apps, laptops, and smartphones that get updated or replaced in as little as months to a couple of years.

Major appliances like stoves, refrigerators, dishwashers, clothes washers and dryers, and so on have a lifespan of 10-plus years, he said. 

They are also built by companies that are experts in making quality hardware, but don’t have much depth when it comes to software security, especially for the long term. “What does it mean to have designed something 10 years ago to the best practices of that time but that now needs to deal with today’s cyberthreats?” Mackey said.

A paradigm shift toward security

It takes a paradigm shift to plan for that reality. Which, as noted above, is difficult but possible. The way to make the future IoT safer is to build security into the software development life cycle (SDLC).

Those who are part of a software company are likely long familiar with the SDLC. But for those who have more recently moved into the world of connected devices, here’s a brief tutorial. 

The standard SDLC has eight stages, running from the gleam in the eye of an entrepreneur to maintaining a product throughout its useful life. Those stages are: 

1. Plan

This stage includes defining requirements for what the software will do, and estimating the costs, scheduling, procurement needs, and staff needed to do it.

But it should also include a security component: Threat modeling. Sometimes referred to as “thinking like a hacker,” the goal is to go beyond the standard list of known attacks and identify possible threats that are unique to how your system is built or to what your application or device is intended to do. 

Good threat modeling includes highlighting assets, threat agents, and controls to determine which components attackers are most likely to target. And then setting out remediation measures to reduce those threats.

There are multiple benefits of threat modeling, but among the most important is that it can save time and money. Looking for potential problems early, before a single line of code is written, can catch design flaws that traditional testing and code review might miss. Fixing or avoiding them early is cheaper and faster.

2. Code

Just what it sounds like. Writing software code to fulfill the design requirements.

3. Build

Modern software is rarely simply written by a team of developers. It’s assembled. Some components are proprietary, but others are from commercial or open source libraries. 

4. Test

This is no longer a separate stage where a security team probes software for vulnerabilities at the end of the SDLC. It needs to be pervasive, running from threat modeling before coding even begins all the way through to production. It requires multiple testing tools, including static, dynamic, and interactive testing throughout development, and software composition analysis (SCA) to find vulnerabilities or licensing conflicts with open source code. It also requires penetration testing (more on that below) before the software is deployed.

5. Release

This stage involves the development team packaging, managing, and deploying releases across different environments.

6. Deploy

The software is released into the production environment.

7. Operate

The software is used in the production environment.

8. Monitor

The team tracks the performance of the software, including system performance, user experience, new security vulnerabilities, and analysis of bugs or errors in the system. This is the stage when updates or patches are pushed out to users to close vulnerabilities or respond to new threats. 

Notice that an effective SDLC shouldn’t end when a product is shipped. It continues through that product’s useful life. Although “building security in” during development will minimize bugs and other defects, the reality is that there is no perfect software. So securing IoT devices means maintaining them.

The evolution of the SDLC

Another major key to making security a fundamental component of building software is understanding how the SDLC is evolving. Software development is faster today, by orders of magnitude, than it was even a few years ago—the digital version of moving from a horse-and-cart era to a superhighway with modern cars. 

For security to keep up with agile and DevOps delivery practices, there must be automation of both the development and testing of software. 

That is a trend noted by the Building Security In Maturity Model (BSIMM), a free annual report by Synopsys that tracks the software security initiatives (SSIs) of organizations mainly in nine verticals. The most recent report, BSIMM11, did in-depth analysis of the SSIs of 130 participating organizations.

It reported the move by numerous organizations toward DevSecOps, a system in which security is “baked in” to all aspects of the DevOps life cycle, thereby bolstering development, increasing velocity, reducing friction, and strengthening collaboration. 

eLearning for developers

But it takes more than automation for security to keep pace with the speed of development. Humans still have to run the show, so to speak. 

Building secure software at the current speed of development requires giving developers not only the tools they need but training as well—something a good eLearning program can provide. 

Synopsys eLearning provides:

• Broad coverage of fundamental software security concepts
• Real-world case studies
• Material and lessons that focus on what is relevant to the specific security problems in the code at hand
• Quick lessons that don’t slow developers down and let them get back to coding
• On-demand courses, so developers can learn when it makes sense and is convenient for them

The eLearning platform also offers guidance. When one of our software analysis testing tools identifies a defect, it will also recommend the relevant course.

With that kind of support, developers are more likely to write and assemble more secure code and do it faster.

Penetration testing

Finally, penetration testing uses a variety of testing tools and manual tests to find and eliminate business-critical vulnerabilities in running web applications and web services, without the need for source code.

It is a “last chance” to catch and fix significant vulnerabilities before exposing those applications and services to the wider world, where malicious attackers will be looking for ways to compromise and exploit them.

Obviously, it’s much better to have white-hat hackers find defects before the black hats can.
Synopsys offers two levels of pen testing, based on the risk profile of each tested application.

The essential level includes automated scans and manual testing. It focuses on exploratory risk analysis (e.g., anti-automation, complex authentication).

The standard level includes essential service plus testing time and effort to explore business logic, which covers attacks outside a predefined list or those that may not have been considered otherwise (e.g., business logic data validation and integrity checks). It also includes a manual review to identify false positives and a readout call to explain findings.

IoT security will never be perfect

As we noted at the start, there is no way to build perfect software. It doesn’t make sense to try, since that would likely mean never releasing a product. 

But it’s possible to avoid being low-hanging fruit, with an effective SSI and an SDLC that embeds security into software throughout that process. Most attackers are looking for easy targets. If your apps, services, and networks are difficult, chances are good that they will move on. 

You may never know the exact ROI of your security program. But that’s a good thing. You really don’t want to know. 

Learn more about IoT security solutions