Most firms have learned the importance of protecting their code.  They train their staff to navigate through phishing attacks and social engineering traps, and cybersecurity measures like encryption and password hygiene have become industry standard.

But there’s one element that can undermine all security efforts if left unchecked — the code itself.

In-house code developing for specific tasks can save a lot of time and money, but sloppy code can introduce security vulnerabilities right from the get-go. It’s not worth saving money on outside coding contractors only to risk losing it all to hastily written code riddled with potential back doors for a would-be attacker.

Here we’ll examine ways that security vulnerabilities can find their way into code and what steps businesses can take to prevent those vulnerabilities from being introduced in the first place.

Do Your Research

Research is the first step to understanding secure code for your business.

In this case, you’ll want to have a firm grasp of the existing industry standards. Lean on the coding community, for a start.

The old joke about faking your way through IT via Google is based on a simple truth: Someone, somewhere, has probably already encountered your problem, solved it, and bragged about it on the internet.

Standards agencies and organizations regularly publish their findings in reports and newsletters, and secure coding conferences aren’t hard to find.

Familiarize your team with the publications in your specific language and field.  Standards are always evolving — make research an ongoing part of the coding process. This can pay huge dividends down the road, saving you from costly backtracking and bug-chasing.

Get Down to Coding Practices

When it comes time to sit down and pound out the actual code, focus on security just as intently as the code’s eventual end use.

Think about it.  You’re crafting a tool that may potentially see years of use— you’ve gotta make sure it’s not broken from the start.

Carnegie Mellon University’s Computer Emergency Readiness Team, or CERT, recommends the following guidelines be followed to keep security vulnerabilities at bay:

  • Check your input. Properly validating input from any and all untrusted data sources is the number-one thing you can do to eliminate potential security vulnerabilities and code securely. Always double- and triple-check external data sources – particularly those dealing with external input or network interfaces.
  • Don’t ignore compiler warnings. It can be tempting to shove these under the rug but keep your compiler warnings set at the highest available warning level.
  • Build security into the architecture. The architecture of your software itself should reinforce your security policies. A good example is splitting the system up into intercommunicating systems with distinct privilege sets if multiple tiers of privileges are needed throughout the system.
  • Don’t bloat. Keep-it-simple-stupid, or KISS, works wonders in all facets of secure coding. The simpler and more elegant the code, the fewer opportunities there are for vulnerabilities to be introduced. It’s much harder to break into a basement apartment with a single door than a sprawling mansion filled with windows and extraneous doors.
  • Make denial your default. Most decisions within your software should be based on permission, not exclusion. This effectively locks up the code and makes access denial the default. This might seem cumbersome, but it’s worth the hassle in the long run to keep unwanted visitors out of your system.
  • Use the least-privilege principle. The guy who empties the garbage cans at your office shouldn’t have a key to the CFO’s office. Likewise, only dole out privileges on a need-to-have basis. Consider setting time limits on certain elevated privileges – or, at the very least, set an expiration date for them.
  • Keep it clean. Sanitize any and all data transmitted to other systems or sub-systems to keep SQL, command, and similar injection attacks at bay.
  • Build smart defenses. The idea of defense-in-depth is an old one. Rather than a single wall that can be breached or circumvented, defense-in-depth provides multiple layers of protection. Should a would-be attacker scale your wall – or firewall – make sure there are redundant systems in place. Cover your gaps well and anticipate their defeat with yet more defenses. Which bring us to the last point…
  • Test your defenses. If you’re sure that you’ve followed proper secure coding practices up to this point, put your money where your mouth is and test it. This is a facet of quality assurance that’s just as – if not slightly more – important than end-user testing. Source code audits and penetration testing should be conducted, and these tests should ideally be conducted by outside, independent entities that had no part in the code-writing process.

 

Keep at It

Secure coding is both a method and a mindset.  It begins with initial research into the potential vulnerabilities in both your language and your field, and that ongoing research never really stops.

Would-be attackers are constantly hunting for new and novel vulnerabilities, and code itself is ever-evolving to meet new tasks. Your business ought to be positioned to evolve its defenses right alongside them.

Sticking to industry best practices when it’s time to write is a great start, but the real trick is maintaining a culture of security. Developing this secure coding mindset will not only safeguard your systems in the present, but potentially for the full duration of your code’s usable life.

 

References:

1. https://www.sei.cmu.edu/research-capabilities/all-work/display.cfm?customel_datapageid_4050=21274
2. https://wiki.sei.cmu.edu/confluence/display/seccode/Top+10+Secure+Coding+Practices
3. https://developers.redhat.com/topics/secure-coding/

Back