Security Processes for Connected Devices – Revisiting AppSec

We can learn a lot from the application security space when it comes to building out product security processes for connected devices. While apps and devices are fundamentally different things, some AppSec approaches translate well into the product security world provided you have the tooling and expertise specific to connected devices and embedded systems.

Before we dive into the processes themselves, let’s briefly take a look at why traditional AppSec tools don’t work on connected devices.

While an app is a singular program, a device is an entire system that may contain hundreds of programs along with hundreds or thousands of configuration files and settings. It relies on a technology stack (including hardware, bootloaders, OS components, and drivers). 

What this means for device manufacturers is that your job is to secure everything from the programs to the hardware. AppSec tools were not designed around these problems. You may think that these tools might be able to solve part of the problem (e.g. for first-party software within the firmware of these devices), but in order to glean the data you need to secure your device, you need tooling that is compatible with the entire system, not just individual files. Furthermore, most of these tools don’t have the ability to analyze and support the embedded system architectures, tools, and binary formats that form the foundation of modern devices.

Familiar AppSec processes that we need to revisit when dealing with connected devices

1. Shifting left in device security. This isn’t a defined process, but rather a best practice that saves time and resources and is likely to result in much more secure products. Put simply, “shifting left” means testing and mitigating vulnerabilities much earlier on in the development process and focusing more on prevention than detection of security issues.
   
   It’s much, much more difficult to make changes and react to new vulnerabilities once your product or firmware has already been deployed.  Furthermore, device development life cycles typically include multiple, distributed teams and potentially multiple vendors with integration happening later in the cycle.  That integration and system level configuration can introduce vulnerabilities later in the process, so it is important to shift security left as much as possible while also ensuring you always test the final builds.
   
   
2. Software Composition Analysis (SCA). Software composition analysis allows your engineering, product, security, and legal teams to understand your dependence on third-party software components and manage any risks with that software. Most existing SCA tools identify open source dependencies within your source code repositories, and a few other tools can analyze file systems in containers or virtual machines to find third-party code.  If we consider the device development cycle, the final system firmware image will have a combination of compiled binary code; first- and third-party code written in interpreted languages like Python, Javascript, and Ruby; and binary packages and archives containing other code.Due to the uniqueness of  architectures, file formats, and build tool chains, existing SCA tools simply don’t work for device firmware.  These complexities require a comprehensive solution that is designed from the ground up to support embedded systems and firmware.(Note: here at Finite State we have adapted this process for connected devices. We call it Device Composition Analysis, or DCA.)
   
   
3. Static Application Security Testing (SAST).  Static Analysis tools tend to be a foundational capability in many modern AppSec approaches.  These tools will identify potential vulnerabilities, weaknesses, or risks in your source code as your development team is writing it and/or during the build process.  This is a great practice and should continue within the connected device development cycle.  However, it is important to recognize that the first-party code that can be tested by traditional SAST tools usually only makes up 20% or less of the software in connected device firmware image.  Much of the code is third-party, and it can even include proprietary software from your suppliers delivered only in binary format.  In order to conduct comprehensive security testing, you need tooling that can analyze these third-party binaries, and that tooling must support the diverse operating systems and instruction sets common in connected devices and embedded systems.

At the end of the day, we don’t have to reinvent the wheel when it comes to product security. We can draw on the lessons we’ve learned in the AppSec space and continue to improve upon them using tooling and skillsets specific to connected devices.

Looking for a comprehensive product security tool for connected devices? Check out the Finite State Platform and request a demo from our team of experts.