Understanding the Most Common Secure Coding Standards with Arthur Hicken

Five, four, three, two, one.

Drop that.

Welcome to the Test Guild Security Podcast. We're all getting together to learn more about security testing with your host, Joe Calantonio.

Hey, it's Joe. And welcome to another episode of the Test Guild Security Testing Podcast. Today we're going to be speaking with Arthur Hicken, all about understanding the most common secure coding standards in use today. Not sure if you know, but I started running an online conference dedicated 100% to security testing last year called Secure Guild. And this is actually an excerpt from one of the sessions that was given at the 2019 Secure Guild by author. So really great stuff, especially if you're just getting started with security and you're kind of overwhelmed with all the different security standards out there, which ones you should be using, and maybe some tips and tricks on how to actually implement some of this information. You don't want to miss this episode. Check it out. It's no secret that the number and complexity of applications are growing. But what is alarming is that 90% of security incidents result from exploits against defects in software. The need for better application security has never been higher and Micro Focus Fortify is here to help. Fortify is the recognized market leader in application security and it is the most comprehensive and scalable application security solution that works with your current development tools and processes. With Fortify, you can start security applications in a single day, including custom code, open source or commercial components and scale as your needs grow with an on premise as a service or hybrid implementation. Check them out, head on over to micro focus.com app security.

Hey Arthur, welcome to the Guild. Before we get into it, could you just tell us a little bit more about yourself?

My name is Arthur Hicken. I'm also known as the code Curmudgeon. I've been working at Parasoft for over 25 years on a whole bunch of different things around software development, security. A couple of the fun things you might enjoy are my halls of shame about SQL injection, hall of shame and the IoT hall of shame.

So Ata, how would you explain what is software security?

Now, software security is more than just what we think about with system security. It's not antivirus, malware, firewalls, things like that. It's about building software correctly in the first place so that it can't be penetrated. So to do that we use coding standards and static analysis is how you enforce coding standards. Now, there's a lot of different kinds of static analysis and it's important to understand because some static analysis things are either runtime or similar to runtime. Some are what they call flow analysis or data flow analysis, where the application kind of simulates what's happening without actually executing. And then there's really preventative standards as well.

Cool. So, Atha, can you give an example of this?

So, for an example on how this works, a runtime tool might find out that I have uninitialized memory because the application's running and I was monitoring it. A flow analysis tool will look at the code and pretend to execute it and say, oh, look here, you might be using some memory that's uninitialized. Now, it won't catch everything, and sometimes it's wrong, but it's pretty cool because it does a bunch of work for you without any effort. Now, the pattern methodology means that I'm going to create a rule in static analysis that doesn't allow memory to be uninitialized. So, for example, my rule might say that when you declare a variable like an integer, that you must assign it as soon as you declare it. And that way it's never uninitialized. So just recognize that some coding standards are designed to detect problems, to look for bugs. Kind of an earlier testing and pen testing exercise. And other static analysis strategies are designed to prevent problems by enforcing proper behavior rather than looking for improper behavior.

So, Arthur, what would the workflow look like for using static analysis to help you with your security?

The first thing is you want to detect the error, right? What problem am I having? Maybe I'm leaking connections to the database. So now I'm looking at, well, why is that happening? Well, open connections aren't being closed, so there's resource leaks. So eventually I run out of connections. So we look where it happened. Where's the developer who forgot to close these connections? Or where's the process that's supposed to sweep through and close them periodically? And now we can put in a coding standard that says, hey, let's make sure that each open connection is closed before we exit or before we go out of scope, or before we leave a function or before we log out. And maybe we have to put that into a finally block so that if some kind of an error condition occurs, that connection doesn't leak. Now, we can use static analysis to enforce this standard, and we can keep in place our test to make sure that it isn't happening. But the tests are there, hopefully to validate that we've done the right thing, not to find error.

Cool. Sotho, do you have any examples of this?

Heartbleed is a great example, right? A couple of years ago, Heartbleed swept through the whole Internet because everybody uses open ssl. And there were no tools that would find Heartbleed at the time because it was a brand new kind of very interesting bug. But it turns out there were a bunch of different static analysis standards. I've got a few on the screen here from Misra and cwe, any one of which, had it been followed as a good practice, as an engineering practice, would have prevented Heartbleed in the first place. So there's a whole bunch of these different secure coding standards, and it gets a little crazy. And what I want to do today is help you understand what they are and how we can go about approaching them.

So, Arthur, being new to security myself, it just seems like there's a lot of different standards you need to be aware of with security. So what may be some of the most common ones you think everyone should know about if they're getting into security testing?

So let's look at some of the biggies here. Right? Cwe. You commonly probably hear cwe top 25. It's short for Common Weakness enumeration, meaning it's supposed to be a common way for us to discuss vulnerabilities in software. So that when vendor from tool A and tool B say that they're finding something, we know that it's the same thing. It's got this complex hierarchical tree of weaknesses, and it's really mostly symptom oriented because it's designed to describe problems. Now, the top 25 are the most common, most dangerous things. There's a secondary thing beyond the top 25 called the CUSP, or on the CUSP. And these are the 16 additional rules that didn't quite make the top 25. I think of them as the honorable mentions. And then there's this whole 800, as I mentioned. Now, one interesting thing about CWE is that each of these items are broken down into something called technical impact. This helps you understand if this type of weakness is exploited or what can happen to me. Does it lead to denial of service, loss of data, execution, unauthorized privileges, et cetera. So it's a really great way to help me prioritize what's going on. So this sort of scoring and technical impact is known as the cwraf, the Common Weakness Risk Analysis Framework. And the actual score is cwss, the Common Weakness Scoring System. If you've been doing pen testing, red teamwork, things like that, you might be familiar with cvss, which is a vulnerability scoring system. The trick with a weakness scoring system is that we don't always have enough context to understand exactly what happens. So there's not a lot of tools out there that really implement cwss. In fact, nobody implements this whole framework at the moment for static analysis while they do for cvss. But basically again, it breaks down to things like denial of service. Read write data could lead to loss of permissions on off execution. And the cool thing is this really maps very well to ISO 27010 if you're not familiar with it. Basically it breaks down these various buckets of kinds of problems that software can have and these blue ones are really core security issues. So reliability is going to lead maybe to denial of service or unavailable service performance Efficiency can tie things up various security specific issues like confidentiality, privacy, loss of data, unauthorized access and maintainability. So this is a really great way for us to rigorously look at not just hey, I have a thing and it found CWE130. Do I care? Should I care? Do I need to care? Now we can look at it in terms of its impact.

So, Athar, I'm sure most people are familiar with OWASP as a security standard, so could you just tell us a bit more about your take on OWASP?

OWASP has a thing called the top 10. Again, it's not designed to be comprehensive. It's the 10 things that are most commonly occurring out there. And you can see number one is injection, which in this day and age is completely preventable, thus my hall of shame. But there's 10 items here, they're not all statically analyzable. Number nine in particular is really about using components with known vulnerabilities or software composition analysis or component transparency. And basically it means I'm tracing known CVEs, known vulnerabilities in open source libraries that I'm using or open source code that I'm using. So the latest version of this is 2017. They change it every few years, so it'll change from time to time, but a lot of the items stay the same. And there is again a risk scoring system that comes with it. And it has four key data points. One is exploitability. How hard is it for someone if I have this particular weakness to take advantage of it prevalence? How much are we seeing it in the wild? Does it happen at all the time? Is it happening? Rarely. Detectability. If I have this weakness, can they find it? Because if they can't find it and it's hard to exploit, maybe I don't have to worry as much. And then these technical impacts is it Severe, is it moderate, is it minor? And so putting them together, I get a really great risk matrix that helps me understand, hey, these things are low, these things are high. This is what I should work on first. If you've used static analysis for cybersecurity before, you're well aware that you generally get way more information than you want. There's just too many things to fix. And so this is yet another way, like technical impact of assessing what you have and working on what's most important.

So another one I've heard about is the SEI CERT Secure Coding Guidelines. Any info on that?

It's a community assisted development of a standard. There's a URL of securecoding.cert.org you can go there, you can read info, you can join the wiki, you can contribute, you can ask questions. It's really focused a lot on engineering and prevention. So where CWE says what does a weakness look like? CERT says what does hardened code look like? So it's a really great standard to help you produce code that is safe and secure. It's used a lot, especially in apac, around devices and automotives and device security, functional safety and things like that. It's got secure coding guidelines and there's a whole bunch of static analysis rules. Unlike CWE and owasp, it's very language specific. So there's a standard for C, there's a separate one for C, there's one for Java, one for Perl, and even one for Android. Inside of each particular language there are two standards. One is rules and one is recommendations. The rules are basically strict things because they lead to big problems and it's possible to analyze them in a way that I'm confident that I'm correct. Recommendations are either less dangerous or no way to know for sure that I've really caught it or really missed it. There's also some really practical risk scoring. What I like to call this risk bullseye. And if you go to the secure coding website and look up risk, you'll see this. In fact, there's a recent blog post earlier this year by David Svoboda about this. And in fact David and I did webinar last year that you can find on the CERT website talking about this. But basically you take into account what is the likelihood that this kind of weakness can be exploited? What's the cost of keeping it from being exploited. In other words, if I have a problem, maybe I chose the wrong framework, it can be very expensive to deal with it, or maybe I have a Simple buffer overflow. And it's very cheap to deal with it. And then the severity, or again, when I think about impact, what happens if it gets exploited? And they take these numbers and they multiply them together, really simple, and you get these priority levels. And so if you look at this bullseye, basically the things in the middle with the highest priorities, high severity, inexpensive, and lead to pretty nasty problems, you know, that you don't want to have. So that's a great way to work with cert. And I really like. It's very pragmatic, very practical, very easy to use.

So another standard you cover is PCI dss. What's that all about?

PCI dss. It's credit card stuff, basically. If you take credit cards, store credit card data, charge credit cards, then you need to comply with it. It's an entire framework. It has some specific static analysis coding guidelines in section 6.6.5.1, where it says develop and maintain secure systems and applications. So there are some very specific guidelines you want to follow and probably you're going to get audited against these 12 requirements. And so it's important to make sure that you have a static analysis rule set where you can be sure that you've actually met not just these 12 items, but the sub items in section 6.5.1 that are specifically about how you write your code.

So another one I've been hearing more about is UL 2900.

UL 2900 is an emerging standard. It's been out for about a year and a half now, but basically it comes from Underwriter Laboratory. We all know them. There are little stamps on all of our electronic devices that tell us they're not going to shock us. And this is cybersecurity for network connectable products. So there's a variant of it for medical devices, there's a variant for nuclear devices, and it's actually been recognized by the FDA for security. So basically the FDA is not saying you have to use UL 2900, but if you are using UL 2900 and you are certified, not just user it and saying you use it, but you're actually demonstrating compliance and you've been audited against the standard, then it's kind of prima facie evidence that you've done the right thing. One of the things you have to do with the FDA is show them, hey, I have a plan and I'm doing it and it's a good plan. And UL 2900 is basically accepted as a good plan. Now there's a bunch of information in there talking about what's the right way to build software. But at a coding standard, it breaks down to three simple things. It's the CWE top 25, it's the CWE cusp, and it's the OWASP top 10. So basically you add those three together and you have UL 2900. So it's a pretty good way to start again. You have to demonstrate compliance. So this isn't something like, hey, I want to use owasp, I'm running it, I check stuff, I fix some stuff. This is designed to be compliance standard, meaning I have to know what static analysis checker is used for, which cwe, when did I run it, and when did I allow a suppression or a variation against that standard?

I guess the most common one more folks have been hearing about lately is gdpr.

Gdpr, we hear a lot about it. Not as much in the us, but basically it's about protecting consumer data for European citizens. So if you have customers in Europe, if you have customers that are European citizens and live in the US and you're storing their data, it applies to you and it's got actual fines. They can be up to 4% of your parent company annual revenue. So it's good to be sure whether or not it applies to you. And basically it means be a good citizen with people's data. So why not comply with it? Protect user data, don't share without notice. In other words, don't give it to people. And when someone asks, remove their data from the system. Now, there's no specific coding standards for it. It doesn't get that granular. But I feel like looking At OWASP top 10 A3, which is sensitive data exposure, is a really good way to demonstrate that you've tried to do GDPR and There's at least 19 CWES. If you want more info, ask. I've got a blog I wrote about this a while back that gives you a very good list of these specific items. A couple of interesting things about GDPR is that it requires specifically in the document, in the regulations, privacy by design and security by design. Meaning that in the past I've seen organizations say things like, hey, do we need to encrypt this data? Is it okay not to encrypt that data? And the default is all data is stored in plain text. And then we argue about whether or not a particular piece of data should be encrypted. This is the opposite of privacy by design. Privacy by design says, I'm going to encrypt all data that I'M storing and we can argue about which pieces are safe no matter what, to not be encrypted. So by design, meaning the basic state is secure and private. It's a very good idea. I think about it like a fail safe or fail secure. Now it's funny because fail safe normally means, hey, this is the state I want to be in. But in the world of cybersecurity, we have to remember that safe and secure aren't necessarily the same item. So if we think about a door lock to my house, maybe it's a, you know, electronic door lock. An Iot door lock fail safe means maybe that the door is unlocked so I can get in and out when the electronics fail. I don't want to be locked in my house or out of my house or out of my car. Whereas fail secure means that if the system fails, it's locked. So it's a tricky thing and you want to make sure that your security is really fail secure, that when systems fail that things are still secure. You know, this is a classic. There's a ton of heist movies where the thieves are going to set up a scenario where the electricity is removed from the safe and then boom, the safe opens. Right? That's a horrible, horrible way to build a safe. You want to build the safe so that if there's no power, it's closed, it's locked. A secure by design methodology is going to fail into a secure mode.

So I used to work for a large healthcare company and one standard that always came up was hipaa.

HIPAA is another interesting thing, right? It's about health data from a security perspective. Again, there are no specific standards, but it's security and privacy of patient data. So I don't have any specific guidance for you. But again, like GDPR, OWASP Top 10A3, and those 19 different CWES are going to make sure that you've done the best that you can.

Cool. How about NIST853R5?

NIST853R5? If you're not dealing with the government, you probably never heard of it. It's actually some really good information and that's freely available. It talks about the things that you should do to secure a system. So figure out where's your sensitive data, what are the permissions, how do I manage access, how do I monitor what's going on? Doesn't have anything specific at the coding standard level. So if you're going to follow 853, you still need to have something in place like CWE. Cert, OWASP, whatever makes the most sense for you, but nothing specific.

Any standards around, say, the defense industry.

DISA STIG is another one. It's a framework, it's defense industry. If you don't work in defense, you probably haven't heard of it, but if you have, you know that there are hundreds of Stigs. One of them, the DISA ASD Stig, applies to application security and development. It used to have very specific coding guidelines in V3 of the Stig, but these days in V4 there are no specific coding guidelines. And from my perspective, I would say that the big change between V3 and V4 is that V3 had a section that was very specific, static analysis, dev oriented. And V4 looks more like a DevSecOps thing where we're looking a lot of are we monitoring bad logins? Are we monitoring password behaviors? Have we made sure that we've configured the application for the right kind of encryption? So there's a lot of things to do for desistig, but static analysis really isn't one of them. I know there's some vendors out there, they're going to tell you that they have a static analysis rule set for desistig, but it's going to leave most of the items in the STIG not covered for you. So it might help a little, but it's not really your primary answer.

Satha, you covered a lot of standards, but it seems overwhelming. So what do you recommend to someone to help them get started using standards and doing secure coding?

What am I supposed to do? Right? How can I do secure coding? We'll pick a relevant standard. If you don't know what to do and you're just getting started, try the OWASP top 10. It's a great place to get started. Remember that it's not comprehensive. It's a starting point, but it's a great starting point. If you're working with government or you're working with somewhere that already requires cwe, that's great. Use that if you're trying to get ahead of the system. If you're building devices, if you're trying to work a preventative engineering type of standard, CERTA is really awesome. If you're working on a connected device and you're expecting to need compliance from Underwriter Laboratory. Anyway, for the device itself, why not look at UL 2900, make sure that you have as much of the standard covered as possible with static analysis. In other words, someone might say, hey, I do CWE top 25. But you find out that they do five of those top 25 so make sure that the items that aren't covered by a tool are covered by another tool or by manual peer review. Tune your configuration when you get ready to go, making sure that you take into account the age of the code. Do I do the same thing for old code as new code? Handling noisy rules and use risk scoring in these various standards and prioritization to work on what's most important. First, and ideally, you're going to focus on preventative rules that help you avoid problems we discussed earlier. An initialization rule to make sure that we don't have uninitialized memory. This is great if you're working with devices and if you're still overwhelmed even though you've prioritized and you've turned off noisy rules and you skipped legacy code. Start as small as necessary. Maybe make it only changed code. Maybe make it only 2 or 3 of the OS top 10 and grow toward the full top 10. Don't bite off more than you can chew in a next Sprint or a next release.

Thank you Arthur for your security testing awesomeness. For links to everything of value we covered in this episode, head ON over to testguild.com SSLIXsecurity05 and while you're there, make sure to click on the Try It Today link under the Exclusive Sponsor section to learn all about Micro Focus's awesome Fortify, which is the recognized market leader in application security. Definitely check that out. So that's it for this episode of the Test Guild Security Testing Podcast. I'm Joe and my mission is to help you succeed with creating end to end full Stack automation awesomeness. As always, test everything and keep the good. Cheers.

Thanks for listening to the Test Guild Security Podcast. Head on over to test guild.com for full show notes, amazing blog articles and online testing conferences. Make sure to subscribe to join the Guild and continue your testing journey. This has been a Joe Calantonio production.