“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 code and connect to the internet, they promise great new capabilities and functionality, but also increase the chances for a bad actor to penetrate our systems and even our home lives.
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 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.
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” that should be followed, and “recommendations,” which are less critical and/or less capable of sound analysis. This helps quickly trim the static analysis findings to the most critical.
In addition, CERT has created a risk assessment framework that helps further prioritize the static analysis findings for particular guidelines, taking into account 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, 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.
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:
I recorded a quick overview of the security dashboard for CERT to show you some of the workflows possible with the reports and widgets in the built-in compliance configuration:
All of this works in the way that the developers actually need it. Parasoft fully integrates with build and CI systems, with a web UI for everyone to see the results. More importantly, it integrate right into the developer IDE (i.e. Eclipse or Visual Studio), keeping the developer working where the code is for the quickest feedback possible.
If you’ve tried static analysis security tools in the past and struggled because they were too noisy or didn’t really harden your code, now is a great time to take a look at Parasoft.
Arthur has been involved in software security and test automation at Parasoft for over 25 years, helping research new methods and techniques (including 5 patents) while helping clients improve their software practices.