9 Things to Avoid in your #AppSec Program

Application security programs are made up of three components: people, process, and technology. The process and the technology are more straight forward because they are inanimate objects, for the most part. The hearts and minds of the people are what drive a successful application security program.

To illustrate and make you think, here are nine things to avoid in your application security program.

1. Prevent input validation in your products.  Input validation is the root of most major software vulnerabilities. Input validation is the process that software goes through to ensure that input coming from outside is not an attack. Input validation is good, and all input is untrusted until proven otherwise.
2. Teach your developers to "Trust Everyone" and believe that people are inherently good. For the sake of your product or service, take the age old security stance and trust no one. This means that you must believe that everyone using your application is out to get you, and must design and code your application in such a way to insulate you from any and all attacks.
3. Roll your own cryptography. Cryptography is something that is best left to the experts. Use existing implementations and validated algorithms, and when someone on your team says "I think I can make something better", suggest that they re-direct their enthusiasm to some other topic, like input validation frameworks.
4. Think security last. Security is a property that must be built in from the very first thought about a new product. Adding security after building the product is like adding a second story onto your single story new house, immediately after construction completes. To build that second story, you must go all the way down to the foundation and re-architect the thing. It would have been easier to build security in from the beginning.
5. Punish people for doing the right thing for security. Depending on the maturity of an organization, you may go through a phase where people doing the right thing for security become the enemy. Protect instead of punish. You need these champions to guarantee your long term success.
6. Think security is someone else's problem. The age old idea of passing the buck, applied to security. In any organization today, security is part of everyone's job description. We must all do our part to secure the products and services that we build.
7. Start to test at the end. Security testing is a process best done throughout the life cycle of a product. Test early, test often, and then test again.
8. Ignore coding standards. Coding standards are directions, and nobody follows directions, but your developers must learn about the importance of properly using the languages they create with daily.
9. Shame the guilty. Shame does not motivate. Shame builds resentment. Instead of shaming the guilty when there is a security failure, consider that a teachable moment, and educate not only the guilty, but the entire organization.

I hope that these suggestions will help and resonate with you as you build your application security program.