5 Ways to Screw Up Application Security

So much has been written about building secure code. I thought it might be helpful to document ways companies can purposefully build insecure software. Ya know, just to be sure they can, if they want to...

First: ignore your industry. Building healthcare apps? Working in financial arenas? Your first and most successful approach to building insecure software is to ignore your industry and any related regulation or compliance requirements. Remember how your dad would lecture you that ignorance is no excuse? He's right, but if you really want to mess up, ignore regulation. This is the gift that keeps on giving: not only does ignorance make your apps less secure, it also opens your firm to numerous liabilities (for instance, healthcare companies who blatantly violate HIPPA technical requirements are now being fined). But wait--there's more: it also opens your company to class action lawsuits. Why settle for government penalties, when you can expose your company to civil fines, too?

Second: don't plan security features. Expect them to take care of themselves. This is step two in the ignorance approach--you can't just ignore regulations, you also have to overlook listing any security features your users might need. Planning ahead means security can be built into the app. By ignoring features, you set yourself up for bolting them on later. We all know building security in later is horrifically expensive. The silver lining to this approach is that the high cost of "later" generally renders "later" impossible. If you wait on security, senior management will usually prioritize shipping over fixing, and you'll be off the hook.

Third: by all means don't check for security in your source code. Fixing a flaw is infinitely cheaper if it's discovered the day it's written. Static code analysis tools like Checkmarx SCA are low-cost, high return tools developers can use to detect flaws when they're introduced. Checkmarx can even be tied into the build process and used as check-in and nightly build tests. Acceptance tests and security functional tests should never be run.

Fourth: don't ask "what if" questions. This important step is tied tightly to the ignorance step (step 1). Building an app and you want some instrumentation? Looking for usage data inside of your app? There are third parties to help you do that. When you integrate these third parties' technologies, be sure to not ask questions like "what could possibly go wrong?" or "what information are we sending?" These questions usually result in discovering security issues (like the integration of botnet-like command and control channels) or compliance violations.

Fifth and most important: do not, at all costs, allow developers time to educate themselves on security. An educated developer is by far the greatest enemy of insecure code, because the developer implements the code. In addition to denying any requests for SANS training, be sure to block access to OWASP.org, BSIMM.org, SAFECODE.com and anything with "secure development" in its content. The unfortunate truth for teams seeking to build insecure code is that it's just as easy to build secure code as it is to build insecure code. Not only that, but it takes a developer almost the same amount of time to write secure code as it takes to write insecure code. It doesn't take much to keep your developer in the dark. Related to this is the idea of planning and executing penetration and security testing. By putting these tests on your product plan, you all. Ut guarantee they will happen. If they happen, they will uncover flaws. For a company striving to build insecure software, these "inspections" can be disastrous to corporate policy.

This is a tongue-in-cheek look at the most common mistakes companies take which result in insecure software. Building secure software is relatively simple, requires little up-front effort, and helps your company stand apart from the crowd of competitors. No company sets out with the goal of building insecure software, but a combination of inexperience, short delivery cycles and rapidly changing regulatory and threat environments can overwhelm even the best team. If your team needs expertise and help, reach out to Caliber Security Partners. We can come in and help you--our approach is to partner with you to build security best practices into your specific workflow (agile or waterfall). We can provide training, strategic advice, and security services to ensure your applications are increasingly secure.

John Overbaugh is Managing Director for Security Services at Caliber Security (http://www.calibersecurity.com)