Shifting Left: Building Security into IoT Devices at Earlier Stages

Shifting Left: Building Security into IoT Devices at Earlier Stages

As the software development lifecycle(SDLC) begins to compress and development teams adopt Agile or DevOps techniques, there is talk of the need to “shift left” with quality assurance and security testing processes. Shift left is a practice intended to identify and eliminate defects and vulnerabilities early in the software delivery process.

Few modern applications today are built in the traditional “waterfall” style of development, where there are definite and linearly sequential stages of development. Those stages include gathering and documenting user requirements; design the application; coding and unit testing; performing system testing; performing user acceptance testing; fixing any issues; and delivering the final product. One stage ends before the next stage begins.

One obvious drawback of waterfall development is that user requirements can change from the time they are defined and the time the final product is delivered. Another important problem is that quality and security issues aren’t addressed until developers are almost ready to deliver the final product. Fixing such issues can be rushed (or not done at all) if there is an urgent business need to get the application out the door and into production.

In the Agile or DevOps style of development, some of those stages are done simultaneously to speed up the work.What’s more, it’s an iterative, team-based style of development, where the work is broken up into small functional components delivered in short time periods called “sprints.” Each sprint has a list of deliverables that are prioritized by business value as defined by the customer. An important element of Agile development is regular interaction with the customer who is paying for the application. This way, if requirements change midstream, they can quickly be incorporated into the next sprint.

Agile development lends itself nicely to the “shift left” movement because of the interactive style of work. Quality and security testing can be done much earlier in the software development process than what has been done in the past. Testing may still happen at the end of product development, but the process will be shorter and faster because, hopefully, many problems will have already been found and addressed early in the SDLC. Shift left doesn't exactly move testing closer to the beginning of a release cycle; rather, it becomes part of each step and each iteration.

The financial incentive to shift left

It makes sense to think that the sooner a problem can be discovered, the sooner (and easier) it is to fix it. If a coding defect or a security vulnerability isn’t discovered until the code is compiled and the application is ready to be released, it’s a significant disruption and burden in terms of time and money to have to go back to make the fix, retest the application, perform user acceptance testing again, and so on.

The chart below shows the increasing cost of finding and fixing a defect in software at various stages of the development lifecycle. It shows that every development team has a great financial incentive to find and address problems as early in the lifecycle as possible.

The danger of not shifting left: unchecked vulnerabilities

If a security vulnerability isn’t discovered until after the application is in distribution to users, then the next step in the cost escalation could be the potential costs associated with putting out a product with a serious defect or vulnerability that causes harm to customers: lawsuits, reputation damage, loss of business, stock decline, etc.

Two recent supply chain attacks illustrate how software applications with embedded malware made it to market. Had security checks been done earlier and more often in the development process, the malware likely would have been identified and the threat removed before the production stage. As it happened in these two examples, the malware was “baked in” before the companies signed digital certificates to indicate their software was supposedly trustworthy.

A supply chain attack is one in which at rusted, widely distributed product is infected by a malicious code before the product is sold to the customer or when a software or firmware update is distributed by the manufacturer. Attackers cast a wide net through supply chain attacks, sometimes affecting millions of computers. Several high-profile cases have come to light in recent years, shaking the trust that businesses and consumers have in their technology providers.

One notable attack involved CCleaner, the very tool that many people rely on to clean old software off their PCs to make them less vulnerable to performance and security issues. Forensic research on the attack indicates that that the CCleaner code had a backdoor implanted before the application was digitally signed to ensure trust and then made available for download. The corrupt version of CCleaner was installed 2.27 million times before behavior irregularities caught the eyes of security experts. In the meantime, the malware subsequently planted second stage malware on 40 targets, all of which were technology and enterprise IT organizations.

It’s thought that one of these 40 targets could have been ASUSTek Computer (ASUS), one of the world’s largest manufacturers of computers and components. Just as in the CCleaner attack, the ASUS Live Update Utility was corrupted and distributed to users through the application’s own update mechanism. And like the CCleaner attack, the ASUS software had been digitally signed with security certificates after the corruption. This indicates that hackers had access to ASUS's code signing and update infrastructure. Also, the malware distributed via the ASUS infection targeted systems with specific MAC addresses, meaning this was a sophisticated plot to get into very particular targets.

Though it’s hard to say for sure, a more rigorous and continuous process of looking for vulnerabilities in the SDLC might have prevented these supply chain attacks. As it happens, both attacks were discovered by outside companies.

What needs to happen to shift left

Several things have to happen in the development process. For one thing, the teams must focus more on quality and preventing problems from happening in the first place. The teams also must begin testing earlier than ever before, with the goal of increasing quality, shortening the test cycles and reducing the possibility of discovering defects only at the end of the development cycle.

According to Disha Rathod, DevOps Online Trainer, shifting left requires two keyDevOps practices: continuous testing and continuous deployment. Continuous testing involves automating tests and running those tests as early and often as possible, along with service virtualization to mimic unavailable systems.Continuous deployment automates the provisioning and deployment of new builds, enabling continuous testing to happen quickly and efficiently.

One measure that can be taken is to incorporate static application security testing (SAST) directly into the development environment. SAST is a set of technologies designed to analyze application source code, byte code and binaries for coding and design conditions that are indicative of security vulnerabilities. SAST solutions analyze an application from the “inside out” in a non running state, thus enabling developers to constantly monitor their code for vulnerabilities. Third-party code such as software development kits (SDKs), open source software (OSS) and application programming interfaces (APIs) are also analyzed for vulnerabilities. As issues are found, the information is fed back into theDevOps workflow so they can be corrected and security validation can be done before the software is finalized. This continuous integration process is known as DevSecOps.

Building security into the IoT

Research by Microsoft indicates there are two groups utilizing the same tools behind the CCleaner and ASUS supply chain attacks.A group known as Lead appears to have industrial espionage as its goal, as it has been targeting companies and organizations from various industries. If industrial espionage is indeed the goal, then attacks distributed by and/or toIoT devices must be in the works.

IoT devices can be especially vulnerable to security issues, given that traditional security methods can’t be applied to these devices. For example, there is no anti-virus software to check for intrusions, and there’s no way for a user to directly interact with the devices to monitor for problems. Thus, it’s time for IoT device manufacturers to shift left with their security mindset to prevent issues from happening.

It starts with trusted hardware. Ensuring that an embedded system is trustworthy begins with the first instruction on trusted hardware. An effective trusted computing strategy can include anti-tamper protection that guards against physical hardware intrusion, encryption techniques for critical data at rest, and effective cyberattack protections that ensure that a corrupted BIOS will not cause harm.

The first step to ensure that the BIOS is not corrupted is to establish the hardware “Root of Trust.” A foundational concept in cybersecurity, the Root of Trust establishes trusted functions, based on hardware validation of the boot process, to ensure that the system’s operating system is being started up with uncorrupted code. These functions are located in hardware so they can’t be changed.

Hardware security measures can be expensive so it’s likely that only high value industrial equipment will be built with these modules. Nevertheless, device manufacturers can do quite a bit with software solutions to ensure a more secure device.

Ensuring software security for its entire lifecycle

Cybeats is a critical component of the SDLC for IoT devices. Cybeats security intelligence tools automatically analyze the behavior of the device during the development process, looking for potential software vulnerabilities, insecure network operations, software supply chain attacks, device performance issues and even memory and file leaks. This provides device makers the visibility and assurance the device is secure before manufacturing.

Once the device software is in production mode, Cybeats creates a trusted device profile that defines the normal behavior of that device. Any abnormal behavior is identified and analyzed in real-time as a potential threat. The exact root of the abnormal behavior can be identified, allowing for immediate remediation to remove the threat so there is zero device downtime. In addition, Cybeats provides continuous threat intelligence to identify potential new threats that might attack deployed devices.

End users of the devices need to know that they are getting trusted updates from the manufacturer. The Cybeats management dashboard allows for device firmware to be updated in a managed and secure manner. Device manufacturers can implement policies that specify a process for approving firmware updates and orchestrate OTA updates for individual and groups of devices.

And finally, Cybeats makes it possible to integrate with existing SIEM systems to provide detailed visibility to individual devices. This level of device-specific visibility allows a SOC to quickly respond to an incident in a matter of seconds, not days, reducing the amount of device downtime.

We can expect to see more attacks like the supply chain attacks aimed at the IoT sector following the successes of the past occurrences. Manufacturers can get out ahead of this attack vector by partnering with Cybeats to shift left to incorporate security into every stage of development and the product lifecycle.

‍