Pushing Left, Like a Boss: Part 4?—?Secure Coding

As originally published on my blog, SheHacksPurple.

In the previous article in this series we discussed secure design concepts such as least privilege, reducing attack surface, failing safe and defense in depth (layered protection). In this article, we are going to talk about secure coding principles which could be used to help guide developers when implementing security controls within in software.

As we discussed before, a security flaw is a design problem, while a security bug is an implementation problem (a problem in the code). Whoever wrote that code had the best intentions, but may not have had enough information, enough time, or enough guidance on how to do it correctly.

What is “secure coding”?

Sometimes called “defensive coding”, it is the act of coding with security in mind, and guarding against accidental or intentional misuse of your application. It is to assume that your application will be used in a myriad of ways(not necessarily just the way that you intended) and to code it accordingly.

Why is it ‘secure coding’ important?

I’m not going to answer that. If you are reading this blog, you already understand why secure coding is important. I think the real question here is: “How do I explain how important it is to developers? To project managers? To executives? How do I get them to give me time in the project for it?” I’m asked this quite often, so let me give you a few options.

1. You can explain using statistics and numbers, to predict the financial implications of a major security incident or breach. You can provide a cost/benefit analysis of how much less an AppSec program would cost. I used this approach and I was approved to launch my first AppSec program.
2. You can explain the business implications of a major incident, the loss of reputation or legal implications that would result from a major incident or data breach. I tend to use this when trying to justify large changes such as creating a disaster recovery site, or an AppSec advocacy program, or giving developers security tools (that tends to scare the pants off of most management types).
3. You can create a proof of concept to explain a current vulnerability you have in your product, to show them directly the consequences that can occur. This might lose you some friends, but it certainly does get your point across.
4. You can sit down with whoever is blocking you and have a real discussion about why you are worried about your current security posture. Explain it to them like they are a highly intelligent person, who happens to not know much about security (which means respectfully, and with enough detail that they understand the gravity of the situation.) It is at this point that I would tell them that I need them to sign off on the risk if we do not correct the problem, and that I can no longer be responsible for this. It is at this point that either 1) I get what I want or 2) I know this is no longer my responsibility.

Why are users the worst?

The one thing that you should always remember when coding defensively, is that you need to assume that users will do something that you did not plan on.

Photo: https://wiki.sei.cmu.edu/confluence/display/seccode/Top+10+Secure+Coding+Practices

In the next post in this series I intend to publish a secure coding guideline. But before we continue onto that, please allow me to present my #1 advice on this topic: always use the security features in your framework. If your framework passes an anti-CSRF token for you, output encodes your data, or handles session management, use those features! *Never* write your own security control if one is available to you in your framework. This is especially true of encryption; leave it to the experts. Also, whenever possible, use the latest and greatest version of your framework — it’s usually the most secure version. Keep your framework up-to-date for less technical-debt and more cool features.

Up next in the ‘Pushing Left, Like a Boss’ series: a secure coding guideline.