The Need for Secure Coding

There was recently a survey published in Visual Studio Magazine that stated more than 40% of all software developers globally didn’t adhere to any secure coding practice. This really baffled me, but then again, it shouldn’t have because as a developer much before I knew anything about security, I wrote a lot of really crappy really insecure code for my employers. I believe I really did them a disservice, there is code running in production that I wrote, which could have disastrous effects for my previous employers if it was ever exploited.

No professional developer should ever be okay with a statement like that. As professional developers, we’re not okay with releasing defects in our code that could have potentially disastrous side effects if just the right set of circumstances are reached. Yet we live & work in a culture where that’s exactly what we are setting ourselves up to do. More than 40% of developers don’t employ secure coding practices, very few colleges & universities teach secure development ideas to their students, so it falls to the company & the developer to care & learn about secure development practices. The developer doesn’t have time & the company says it’s too expensive. The reality is that, today’s information security landscape sucks, attacks are becoming more sophisticated, and getting folks involved in producing the software thinking about security seems like a losing battle. It appears that until an organization suffers a significant data breach, their security processes remain largely undefined and underfunded.

Secure coding practices go beyond, what security features should we implement in our application, a good practice forces everyone involved in the software process to recognize there are security vulnerabilities in whatever software might be released and to understand the risk associated with each. Then defining a response plan to how to deal with said security vulnerabilities.

When Should I Care About A Secure Coding Process?

All the time, but first if you have any security features in your application, be it a web application, a desktop application, some hybrid. If you have security features like encryption, login, SSL, authentication, anything else. That immediately tells me that you have some information to protect. If you have information to protect, somebody somewhere at some point in time will attempt to break in, steal, change, compromise your data, in the best case scenario just because they can, in the worst case to financially harm the organization you work for, or your customers.

Is It Enough to Rely On Corporate Firewalls, Routers and Other Network Hardware?

NO! If you write an internal only application that authenticates against domain credentials that’s never exposed to the outside world, if your application is authenticating that means there’s something to protect. Therefore the application and the application developers need to take responsibility for the security in their applications as well. But why?

To answer that, let's consider the security use case of a casino for a minute. When you first enter the casino, you’re met by security to determine that you’re old enough to gain access, and you’re legally entitled to gain access. You may not know it but you’ve just passed 1 level of security, you’ve been authenticated on the domain if you will. However once you’re inside the casino, do you have free will to do whatever you want? Absolutely not, there’s security guards walking around keeping a close eye on you, there’s camera’s & security guards in a control room monitoring you, looking for any suspicious activity, any reason to revoke your access to the casino domain, in order to protect their assets. What’s a casino’s most valuable asset? It’s money, It’s also the casino’s most protected asset, even after you’ve gotten into the casino, passed numerous security checks while you’re in there, you still don’t have a chance of getting anywhere near the money. The money is usually moved by 2 -3 security guards and then another guard, guarding access to a door, once through the door the money asset isn’t considered secure, no it's locked up inside the casino’s vault.

So if you were an attacker and wanted to steal the money of a casino, you’d have to accomplish this:

1. Gain access to the casino
2. Avoid detection/suspicion of the guards
3. Take out 2-3 security guards while moving the money/avoid the rest
4. Get out without being detected OR
5. Take out 1 security guard, gain access to a locked door
6. Avoid any security guards after through the door
7. Gain access to the vault
8. Defeat the vault’s security system
9. Get out, without being detected.

The casino practices a concept of security in depth. If you can defeat 1 security guard or 1 security measure, there are still more you have to defeat. When adopting a secure coding practice, this is something that developers should think about.

If the network firewall can be defeated, are the assets, the most trusted assets that my company relies on, still secure because of my program?

If domain authentication can be bypassed/tricked, are the assets, my application and company care about still secure?

What’s our remediation plan if our security is defeated? The casino’s is a call to the police and potentially send some shady characters after you.

What If My Application Protects Nothing, Do I Still Need To Think About Security?

Without question yes, even if you’re writing a plain old boring text editor application, you still need to think about security. You may think that your application doesn’t protect any assets, however I would challenge that and suggest the customer’s computer your application is running on is an asset in and of itself. If your application has a security hole, that security hole may allow your customer’s computer to be hijacked for a botnet, or worse still, a security hole might be exploited to allow malware to run on your customer’s computer at an elevated privilege because your application requires running under elevated privilege and that malware might take, steal, or otherwise compromise other assets running on your customer’s machine.

A secure coding practice would force developers to stop and think about how some of their application could be exploited against their clients, even if it were just a text editor. How is that text editor updated, could a DLL allow a remote thread to run, and download & execute some malware. It doesn’t matter how the malware gets there, if it’s on the machine, it could run and exploit a security vulnerability, could an attacker replace one of your application DLLs to execute their own code?

A secure coding policy doesn’t necessarily need to stop all these vulnerabilities before a product is released, products are released all the time with defects in them, which are patched in updates or not patched at all, so too security vulnerabilities can be fixed at a later date if deemed not risky.

Can’t I Just Release a Product and Care About Security Later?

Sure there’s nothing that says you can’t, however there is an ideology within software circles that would suggest early defect detection, leads to cheaper, defect fixes, so too with security, a security vulnerability is just a defect, the earlier you find it, the cheaper it is to fix.

My Developers are Careful and Use Common Sense!

Do they? I spent 5 years writing software, before I knew anything about security & before I really started to study security and gain some understanding of how an application could be violated. How many other developers out there are just like me? Security wasn’t a concern, making money was! Few colleges & universities teach security, so how can the developer have common sense around security? A good secure coding policy will make it a point to train other developers, what to think and how to think about security.

I’ll Just Hire A Security Professional When My Products Gain Enough Traction

Sure, this attitude works if you’re a big company. You can bring in security consultants later to help retrofit security & add security to your product line, later hopefully before you are exploited! However the reality in Canada & many startups ism companies are small, few developers and that security consultants cost money perhaps lots of money, as well and then it becomes costly to add security after the fact.

Security Costs Money

Absolutely it does, security & secure coding practices is a lot cheaper if you build security in rather than bolt security on afterwards. You also need to balance a security cost in your application against the loss suffered of because a security hole was exploited. Without a secure coding policy, how can a company or their developers ever begin to understand what the cost of having a security vulnerability exploited is if they do not understand the risk associated with some vulnerabilities or are even aware of what vulnerabilities exist. A solid secure coding program, allow developers and companies to identify & calculate risk and make informed decisions on the security vulnerabilities in their application. Secure coding training should be part of hiring any new employee.

It’s 2013

Cyber criminals are making applications & selling them that allow computers to get infected software to get exploited. Edmund Burke said “All that is necessary for evil to triumph is for good men to do nothing” One might suggest all that’s needed for evil software to triumph is for good software developers to do nothing. Knowledge of secure coding practices, policies, should be something every software developer who calls himself a professional should develop, add to their toolkit and apply, they should also be encouraging their employers to develop formal secure coding polices & practices. Microsoft uses the Security Development Lifecycle. That may be a good starting place for your organization or it may not, there are many different secure coding practices out there, it’s time that we developers, managers, CEOs, stood up, adopted and did better for everyone.