Great question.
First, the "minimum" you quoted refers to Microsoft's minimum requirements policy, not necessarily the "industry best practices" minimum. Not that I'm saying its wrong, but the MS-SDL itself does go on to say that their SDL is not necesarily fitting for any organization outside of Microsoft... In fact the MS-SDL architects, such as Michael Howard is oft-quoted saying:
Don't do what we do, do what we did.
Which is to say, its not so much the prescribed requirements as they specifically appear in the document (though they might be mostly very good), but they repeatedly performed studies, including risk-based analysis, historical metrics comparisons, trend analysis, root-cause analysis, trials in different teams to see what "takes", etc.
There is not a well-defined, simple SDL you can just download install and go be secure. That point from MS is spot-on - you really need to tailor your SDL according to your specific organization, your teams, their proficiency, the types of products they're building, the current development process, the risk profile, etc etc. And that's really the best solution to "try out"...
Moreover, SDL is not a one-time thing, or even a question of defining and implementing the correct policy. Building an SDL is itself an ongoing process, which admittedly can take several years to implement completely. Microsoft did quite a few iterations till their SDL reached something exemplary... And it took another couple years to get it really ingrained in (most of) their developers. You can't really "try out" an SDL, because the benefit will typically not show within the first month or two - it really is a long term investment.
So, for orgs just starting out, and looking to define their SDL - I would suggest taking it slow, have someone with experience guide them in the process:
- Start by mapping out the current situation, process, teams, experience, flexibility, etc.
- If the teams + management are not 100% convinced of the need for SDL, and security in general, consider doing an initial security review just to drive home the problems... A pentest is often most useful here, simply because it can be quite visual (NOT because its needed for the SDL itself at this point).
- Ensure at this point you have buy-in - both from an executive sponsor, and from the teams themselves. Without either, the SDL is doomed to failure.
- Training! Developers like to do things right, if they know how.
- Slowly add minimal additional security activities, according to the benefits you will receive for them, as compared to the effort invested - and the disruption to the dev teams. Remember, the point of the exercise is to get EVERYBODY involved in security, and not turn them off right away.
- Set up security expertise, either in your team (as a security champion) or in a central team that everyone can talk to - and get them talking. Better yet, is a hybrid model of both (as in the MS model).
- According to your capacity for additional security investment, in each cycle add minimal additional activities, on top of the previous ones. The point is to get them so used to doing one-two small li'l things, that it becomes second nature (almost) and it no longer "takes so very long to do this security stuff". Then you'll have bandwidth for more...
- Gather metrics along the way, so you can tell what is working and what is not, and also to show the benefit from the SDL investment to management.
- More training!
Now, the real problem is that list above, looks like a lot.
But it really isnt, since most of those bullets are "meta-activities". Some of them should probably be done by an experienced security guy/gal/consultant, with experience in implementing SDL in a similar type of environment as yours. Admittedly, still not so simple, but when I do this I put the emphasis on minimal disruption and ongoing investment. It can be done lightweight.
