Securing IoT and Embedded Software With Static Analysis

The SEI CERT secure coding standard is a great choice for securing your code, especially if your application is embedded or safety-critical. In this post, I discuss how to use static analysis to implement this standard for security by design.

"Although the notion of protecting software is an important one, it’s just plain easier to protect something that is defect-free than something riddled with vulnerabilities."

- Gary McGraw, Cigital

The proliferation of embedded software and IoT devices is increasing the risks of security attacks on a daily basis. In my IoT hall-of-shame, I see regular attacks against everything from water treatment plants to cars to children’s toys. As “things” get more advanced and connect to the Internet, they promise new capabilities and functionality, but they also increase our chances for a bad actor to penetrate our systems and even our home lives.

The Problem With IoT and Embedded Security

Studies show that even cars can have over 100 million lines of code in them. The days when a few developers could manually review the code are gone. With such large, sophisticated systems, we have to start taking software security seriously. Luckily, in the sense that strategies to address problems can be the same, the coding problems that affect secure software are often the same as those that affect safe and reliable software.

Numerous safety standards (ISO 26262, DO-178B/C, FDA, etc.) have shown that software safety and reliability can be greatly enhanced through the use of coding standards and static code analysis. Static analysis is the best way to consistently harden your code and move from a “test security in” to a secure-by-design mentality. Meaning, we can’t leave cybersecurity to a separate team, but we must begin to address it as soon as we start planning and coding. Coding standards move us from the “build, pen-test, fix” cycle back into a “design, build, deliver” cycle with high quality, safety, and security.

So, which coding standard to use? There are many out there, even if you only take into account the security aspects. CWE, OWASP, and CERT are common secure coding standards, just to name a few. You may have requirements that tell you which standards to use, and if so, you should follow them. But, I’d like to make the case that CERT is a great choice for securing your code, especially if your application is embedded or safety-critical.

Why CERT for Securing Your Code?

So, the obvious question is “Why CERT?” Isn’t CWE more popular? Or, OWASP? Well, in the first place, OWASP (Open Web Application Security Project) or the OWASP Top 10, is intended to be a starting place — not a full, rigorous application security process. Also, as its name says, it’s primarily for web applications.

CWE (Common Weakness Enumeration) has a Top 25 list of issues. Again, while this is a great starting place, it’s not enough. Also, CWE in a sense is a symptomatic standard — it’s designed to describe code that leads to specific vulnerabilities, such as those found in CVE (Common Vulnerability Enumeration). While this is a useful and important task, it is reactive by its very nature.

I like the SEI CERT secure coding standard for several reasons. First, it’s much more focused on secure coding practices rather than just the symptoms (e.g. always, always validating input is a secure coding practice, while SQL Injection is a symptom). CERT has analyzed which guidelines are most critical and can be analyzed soundly and then separated into “rules” and “recommendations,” which are less critical and/or less capable of sound analysis. This helps quickly trim the static analysis findings to those that are the most critical.

In addition, CERT has created a risk assessment framework that helps to further prioritize the static analysis findings for particular guidelines, taking into account the inherent severity of the guideline, the difficulty of exploiting such an item, and the cost of remediating it. With this, you get very granular prioritization that helps you focus on what is most important, rather than dealing with a deluge of static analysis violations.

I realize that other standards like CWE also have risk frameworks, but to date, no one has fully implemented them for static analysis because it’s extremely difficult to do. For example, we have taken into account the CWE “technical impact” scores, which is helpful, but the CERT scores go much deeper toward automated prioritization.

The thing about these risk frameworks is that, until now, they’ve been either an academic exercise; they are interesting to talk about but not something you can use in the field, or they’ve been an entirely manual and somewhat subjective process. So, we took the CERT system and implemented it right inside our static analysis reporting system. More on that shortly.

Why Use one Static Analysis Tool Over Another for Secure Coding Enforcement?

So, I'm the Parasoft Evangelist. But why use us? Aren’t all static analysis tools basically the same? Of course, the answer is no, they’re not. And for the CERT C secure coding standard, Parasoft C/C++test is the most complete solution, which helps you get ahead in three main ways:

1. Built-in support for CERT C rules. We’ve implemented every CERT C rule, and we’ve also added the majority of the recommendations, with the rest coming soon. Simply put, we’re the only vendor with full coverage for CERT C rules, and we also cover the most recommendations of any vendor. So, if you care about the CERT guidelines, Parasoft C/C++test is objectively the best choice.
2. Your ability to do more than just talk about risk scores. Our implementation of the CERT risk framework is unique because they’re embedded in every widget and report we have for the standard. This means that you can choose between rules and recommendations, select priority scores, levels, and categories, and see the changes instantly.
3. Ease with audits and compliance reports. Parasoft provides all the usual bells and whistles one expects from static analysis tools (user customizable dashboards, PDF reports, histograms, etc.), along with dynamic risk widgets. But where you get unique value from Parasoft is that we've wrapped all of this into our standard compliance framework, so you can easily produce reports to prove what you’ve done when you’ve done it, how you mapped Parasoft to CERT, and all the other collateral necessary for security audits. Your security officer will thank you, and so will your customers.

All of this works in the way that the developers actually need it. Let us know what you think in the comments below!