Share via

Security Engineering Big Rocks

  • Article

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:

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
  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

Comments

  • Anonymous
    May 09, 2007
    I always suggest conducting Threat Modeling even in advanced dev cycle stages, although it might seem
  • Anonymous
    May 10, 2007
    I witness pretty often the following antipatterns for security engineering: Initial architecture document
  • Anonymous
    May 13, 2007
    Eliaz Tobias from our DPE ( Developer and Platform Evangelism ) group was hosting Ron Jacobs lately here
  • Anonymous
    May 23, 2007
    I am not marketing guy, nor strategic one – I really do not know why I started to read this post - Why
  • Anonymous
    July 30, 2007
    Think configuring SSL for your web site is enough to protect against prying eyes? Here is how the sensitive
  • Anonymous
    January 20, 2008
    patterns & practices team maintains Design for Operations [DFO] project on codeplex . The goal of
  • Anonymous
    September 26, 2008
    You probably heard about SDL few times. This is the process that MS apply when developing its products