Lifecycle and prioritization seem like a key to successful implementation of Security Engineering.

Why lifecycle?

Imagine, that some application written by very seasoned developer – there is a good chance that no vulnerability was introduced in it – hypothetically. Now imagine that the same app’s architecture assumes that authentication is done on client part and the server accepts messages blindly – it is very common architecture security flaw (vulnerability).

Now imagine for a moment that everything is peachy – architecture, design, and the code are bullet proof – but the deployment not that secure. For example, web.config includes sensitive information, the application runs under System account, no URL authorization defined, validateRequest=”false”. Although validateRequest is pretty easy to bypass, here is better approach for input validation and another one, and some more:

• How To: Prevent Cross-Site Scripting in ASP.NET
• How To: Protect From Injection Attacks in ASP.NET
• How To: Protect From SQL Injection in ASP.NET
• How To: Use Regular Expressions to Constrain Input in ASP.NET

That means each development cycle phase must pay attention to proper security activities.

Why prioritization?

What are you after? What are you short on? What you are optimizing? I presume each and every software shop has its own priorities – budget, features, time to market, skills, requirements, etc.

While one approach of security activities during development cycle may differ from another I found the following are essential:

1. Inception Phase
   • Get senior management support. Here at MS we have it – as a quick example take a look at the quote on the cover of “Writing Secure Code, Second Edition”. Here is another.
   • Conduct Security Workshops for the whole team – including biz analysts, testers, developers, architects, even project managers. While security technical stuff can be boring for some members each team member will understand who is responsible for what during what phase with regards to security.
2. Planning Phase
   • Compile security engineering guidance doc and place it in easy to fetch location – say team web site.
   • Conduct Threat Modeling (more here - Threat Modeling Big Chunks). This one is the most important. It helps identifying problems in design up front, before even single line code was written.
3. Development Phase
   • Conduct security code inspection. Dedicated one – do not mix with other security inspections like naming conventions or other.
4. Test Phase
   • Offload some security testing to QA team. Funny, but it is uncommon that QA teams do check for security stuff. I am not talking about penetration testing rather simple checks for input validations, sensitive information handling etc.
5. Deployment Phase
   • Conduct deployment inspection – even most secure app can be deployed very insecurely.

JD talked about High ROI Security Activities some time ago – worth reading.

There is no need to jump on Security Engineering wagon at once (here are some more Security Approaches That Don't Work). Start small according to your priorities and find what works best and then add activities incrementally.

Need help? Try Security Developer Center: Security Development Lifecycle for IT

Enjoy