Step 2: Design and Implement Security at the Beginning

Never, ever, ever leave security until the end of the project. When people eagerly suggest, “Let’s do the features first and add security at the end,” what they inevitably mean is “Let’s not do any security work at all.” Software projects inevitably run out of time, money, or both. When this happens, security will either get cut or scaled back to a half-hearted effort. The best solution is to think of security as its own feature, or as an essential part of other features, and design and develop security along with the other components.

A second reason to tackle security at the beginning is cost. It’s far cheaper to make server-tier changes, implement SQL Server access as views, and add role-based security at the beginning of the project than at the end. Additionally, unless you install the machines yourself, write every line of code, and have a photographic memory, you never quite know what needs to be secured—it would be better to build a secure system from scratch.

Additionally, as you start designing security, you should figure out what the security level is for the system. For example, the project sponsor might want to limit the security effort to no more than 10 percent of the total development time, or she might trust the staff enough to allow unfettered access to the database. This is ultimately the sponsor’s decision, but whatever the decision is, you should explicitly state and record the security level—it will make development and feature trade-off decisions easier throughout the project life cycle.