Coding Culture Will Ruin Your Audit…and Your Security
Developers do not follow secure coding guidelines, but it’s not entirely their fault.
 |
| By: Brand Barney |
Now, I hate to bash on coders/developers. Some of my best friends are
Here are five reasons coders might ruin your audit…and your security.
1. Coders regularly have heavy deadlines that may lead to scrappy quality
From a business standpoint, it makes sense to push product as fast as possible in order to beat competition to market. Well, from a security (and coding) standpoint, that is an absolutely ridiculous idea.Coders don’t have the luxury to take their time with secure code. They have bosses, product managers, directors, and VPs harping them to push code as fast as they can. The faster code is pushed, the less time is spent making it secure, and the more mistakes are likely to be made.
2. Coders don’t always use proper documentation
Each developer in your team probably comes from a different background and has a variety of skills and coding languages up his sleeve: PHP, Java, C, C++, Perl, Ruby, etc. Newbies, veterans, and job jumpers are all familiar with different code. The problem is, they are collaborating on similar projects.Consider this very common scenario.
A developer is assigned to add a function to an existing product. He writes the function in an hour. Then, he finds a problem with the code written by one of his predecessors, and his function won’t work until he fixes the problem. So he goes hunting for broken code that he has no idea how to fix. No documentation exists that tells him who wrote the code, when it was written, or why it was created. Because his team never had a formal policy on code writing, he just wasted six hours to push that function (One hour writing the function, and five hours to fix the problem).
The majority of the time, developers write comments in the code, which I highly recommend. However, if comments are literally the only code change documentation, all it takes is one accidental line deletion and that “documentation” is gone forever.
Check out these hilarious comment examples taken from real code.
// Dear maintainer: //// Once you are done trying to 'optimize' this routine, // and have realized what a terrible mistake that was, // please increment the following counter as a warning // to the next guy: //// total_hours_wasted_here = 42 //
/** You may think you know what the following code does.* But you dont. Trust me.* Fiddle with it, and youll spend many a sleepless* night cursing the moment you thought youd be clever* enough to "optimize" the code below.* Now close this file and go play with something else.*/
//This code sucks, you know it and I know it.//Move on and call me an idiot later.
// If this comment is removed the program will blow up
// I am not sure if we need this, but too scared to delete.
//I am not sure why this works but it fixes the problem.
/* after hours of consulting the tome of google i have discovered that by the will of unknown forces without the below line, IE7 believes that 6px = 12px */ font-size: 0px;
3. Coders aren’t magicians
It’s probably safe to say that no developer knows every library and language framework out there. If you ask a web developer to create a scrolling, randomizing function that works on mobile devices in C++, what does he do? He’ll likely Google it.Developers are living, breathing Google machines. The problem is, half the solutions they find on the Internet (and then implement in product and web code) are 10 years old, or have since proven to be insecure!
4. Coders code on personal, unencrypted machines
Many companies hire temporary developers during a product launch or for a new website. Usually those developers code on their personal machines. All it takes is one stolen, unencrypted laptop for a hacker to have your entire web code to himself.5. Coders experience burnout
Coders truly are artists. They wish to create beautiful secure code that’s well-organized and designed. But good code rarely makes it into work projects. Good code is what your coders do in their free time. It’s what they look at when they’re feeling depressed at work.Why? Like I mentioned above, most companies don’t give them license to use good code. The stress of yesterday’s (and tomorrow’s) deadlines slowly beat them down. They start staying long hours to get work done. Then they come to work the next day with a new pile of requests.
Burnout is the eventual fate of many great developers. The more burned-out a developer is, the less likely he will care about his code being secure.
How do you break the cycle?
Yes, I just made some serious accusations. Many organizations deny these problems happen on their team. “We have too large of a budget for this to happen!” or “My third party does all my coding. No way they have a problem with this!”Well, that’s where you’re wrong. I guarantee that at least one of the above problems happens in 99% of organizations, regardless of size, budget, or team.
Before you begin to fix it, you must get the C-level to understand it’s happening. It’s not enough just to hire more developers or fire everyone and start over. Remember, this is a cultural problem that transcends your own organization.
If management and development members don’t understand the costs and damage insecure/sloppy coding can have on the business, it’s time to educate them on the benefits of secure coding practices.
TweetStart secure coding practices
Following coding standards makes it simple to focus on security, rather than spending time fixing problems in code. If coding standard guidelines are spread across your organization, coders will easily finish each other’s work while constantly maintaining secure code.If your coders don’t come from a security background, ask them to review the OWASP Top 10, and NISTguidelines.
Here are my recommendations to include in your secure coding practices methodology.
Test outside of production
Making changes in a production environment is one of the most insecure actions a developer could ever perform. Unfortunately, it’s extremely common. Product managers need a quick product change so they push development to release it as fast as possible. In this case, fresh, untested code is allowed into the wild … along with any accidental vulnerability. Ensure your methodology requires that developers test code outside of production to avoid these situations.Code review
I hear this all the time, “Our guys are testing their own code, no worries!” I applaud those who test their own code, but that’s not enough. Code should always be reviewed to catch mistakes through external and internal vulnerability assessment testing. For bigger code releases such as product releases or a new website, it’s imperative to receive a penetration test to ensure your organization is secure and safe from malicious entities.SEE AlSO: Code Reviews: A Method to Reveal Costly Mistakes
Patch management
I attended a talk at DefCon 2014, where a white hat SQL researcher discussed how he exploited Oracle’s SQL database for years. He then reported the flaws to Oracle…who would leave the problems for years before fixing them. This unfortunate company is a great example of bad patching practices. Security best practice is to always patch code flaws immediately. If you are participating in compliance mandates, you may have deadlines to consider as well.SEE ALSO: Cross-Site Scripting, Explained
Code documentation
Not only will proper documentation ensure your success as a team, but it also helps drive the team to understanding the prioritized needs of the entire project. As I suggested above, don’t let code comments become your only form of documentation.
I recommend that you follow and disseminate a properly outlined software development lifecycle. This will help your organization and developers create and maintain your applications in a secure manner.
This lifecycle should include development methodology, training, vulnerability testing, change control forms, etc. For instance, anytime code is changed, developers should use change control forms to document how the change will impact customers, how it might change functionality, how it impacts security, if there are any back out procedures, etc.
Summary
The vast majority of developers do not following secure coding practices. It could result from poorly managed development teams, or just poor product planning in general. Until your plan contains documented, formalized, and secure coding practices, problems will continue to happen. Businesses will continue to lose data. You will fail your security audit. Start changing your coding culture today!Have coding security questions? Ask away!
Brand Barney (CISSP, HCISPP, QSA) is a Security Analyst at SecurityMetrics, has over 10 years of data security experience, and will totally geek out if you mention Doctor Who. Brand loves to play jazz piano and daydreams about being as great as Dave Brubeck or Thelonious Monk. Connect with him on Twitter or check out his other blog posts.
