IoT security begins with building secure software. Learn how to embed security into your SDLC to avoid becoming an easy target for hackers.
Kicking off 2021’s National Cybersecurity Awareness Month, we’re focusing on 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.
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.
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.
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:
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.
Just what it sounds like. Writing software code to fulfill the design requirements.
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.
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.
And a solution like Intelligent Orchestration can manage all those AppSec analysis tools without slowing development down. By using predefined risk policies set by each organization, it triggers the right security tests at the right time. The result is the right information delivered to developers and security teams to ensure compliance with their policies across all pipelines.
This stage involves the development team packaging, managing, and deploying releases across different environments.
The software is released into the production environment.
The software is used in the production environment.
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.
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 across various verticals. The most recent report, BSIMM12, did in-depth analysis of the SSIs of 128 participating organizations.
The report noted that security teams are lending resources, staff, and knowledge to DevOps teams to ensure security efforts are built into the path for software delivery. BSIMM12 also observed that security testing in QA automation doubled over the past two years—a move by many organizations to gather data and drive improvements and efficiency in their SDLC or governance processes.
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.
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.
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.
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.
*** This is a Security Bloggers Network syndicated blog from Application Security Blog authored by Taylor Armerding. Read the original post at: https://www.synopsys.com/blogs/software-security/embedded-iot-security/
Vaguely relevant but very cyber image from Dall-EOne pattern I spotted after looking at the evolution of IT and security organizations…
The takedown this week of a massive phishing-as-a-service (PhaaS) operation spanned law enforcement agencies from both sides of the Atlantic…
Security operations centers (SOCs) are the front lines in the battle against cyber threats. They use a diverse array of…
Authors/Presenters: *Sina Sajadmanesh, Ali Shahin Shamsabadi, Aurélien Bellet, Daniel Gatica-Perez* Many thanks to USENIX for publishing their outstanding USENIX Security…
FBI, CISA, EC3, and NCSC-NL issued an urgent advisory highlighting the use of new TTPs and IOCs by the Akira…
The newest version of the European Union Network and Information Systems directive, or NIS2, came into force in January 2023.…