Three Rules for Programming Security Effectively
Wanted to post this while still fresh in my head.
Security is an often overlooked facet of a successful project. The simple fact of the matter is, not every programmer can be a security expert and they shouldn't have to be to do their job. I would go so far as to say that most programmers should not even have to think about security on a daily basis. The problem is, how do you simultaneously maintain these two lofty ideals: making highly secure software while keeping your programmers focused on their specific functional tasks?
1. The average programmer should not have to consider security issues on a daily basis. This should be delegated to a member of the team that focuses part or all of their time on security. They need to have this time allocated and blocked. They can interrupt for critical situations, but cannot be interrupted by other critical situations because security is a core concern equal in severity to availability.
2. Security is built into the framework by the dedicated security team member. This team member proactively seeks to improve security in the allocated time and reactively corrects any new issues at the framework level whenever possible.
3. Other programmers will find security issues and issues caused by security measures. When this happens they need to involve the security team member. Not all security fixes can be integrated into the framework, but most can. By using the framework to automatically handle most security issues, programmers can more confidently focus on their assigned functionality.