Security Engineering Big Rocks

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



Comments (7)
  1. alik levin's says:

    I always suggest conducting Threat Modeling even in advanced dev cycle stages, although it might seem

  2. alik levin's says:

    I witness pretty often the following antipatterns for security engineering: Initial architecture document

  3. alik levin's says:

    Eliaz Tobias from our DPE ( Developer and Platform Evangelism ) group was hosting Ron Jacobs lately here

  4. alik levin's says:

    I am not marketing guy, nor strategic one – I really do not know why I started to read this post – Why

  5. alik levin's says:

    Think configuring SSL for your web site is enough to protect against prying eyes? Here is how the sensitive

  6. alik levin's says:

    patterns & practices team maintains Design for Operations [DFO] project on codeplex . The goal of

  7. You probably heard about SDL few times. This is the process that MS apply when developing its products

Comments are closed.

Skip to main content