Gary McGraw started an interesting meme on a SC-L posting on Getting Started with software security in an organization that references a recent article of Gary's on Dark Reading. The article posits four main ways you can get started with software security in your organization:
A top-down framework approach...perform a gap analysis between where you are and where you want to be from a software security perspective. Then build a plan to address the gaps....
The portfolio risk method takes a more business-oriented approach to the software security problem. The idea here is to assess the entire application portfolio according to some risk criteria agreed on in advance. ...
The training first approach to software security is more grounded in the technical world. This approach helps developers who love to do the right thing but just don’t know what the right thing is when it comes to security. ...
The lead with a tool approach, meanwhile, makes sense for an organization that has already purchased and attempted to roll out a security analysis tool....
I have been involved with all these methods as well, and each can work well depending on what you are trying to do, your company culture, and the people's skills who are working on software security. Being a bottom up guy, I will throw my hat in the ring for a fifth approach, that can be paired with any of the above delivery methods - namely decentralized specialized teams, or centers of excellence in PHBspeak.
Each thing we are trying to push for in secure coding these days requires mastery, Cardspace, static analysis, threat modeling, web service security, and friends are very deep individual domains, and when applied to an enterprise they get wide as well. Let me underline that - to deploy any of the current cutting edge stuff in software security at scale, requires technical depth and deployment width. This automatically limits your resource pool of who can deliver this stuff.
So what I have seen work well is using a decentralized, specialist team approach with a very specific agenda and goals. Note the team can be very small, 2 or 3 people even if they are empowered. The decentralized pairs with the delivery methods from Gary's list. Some examples:
* a roving specialized threat modeling team that works with many groups to help develop threat models, attack patterns, tests, and so on. the team must be deep enough to understand how to build effective threat models quickly, how to apply threat models across projects, technologies and deployments, and how to get something actionable out of the threat models like security requirements, architecture, test cases, and so on.
* a roving team that focuses on build secure web apps and cuts across groups for specialized tasks for secure coding in a specific domain like secure web app dev. tired of using username/password in your web apps? me too. using saml, cardspace and so on is the way forward, but requires a lot of domain knowledge to build sso/slo, and of course it must be integrated with your app.
* security as a service - use the tools and platforms to deliver security to your organization. xml security gateways are vastly underutilized in most enterprises in this regard.
Once you figure out what your strategic goals are for security - threat modeling, cardspace, static analysis, secure web app dev, etc. You can use Gary's portfolio to focus the team on the right stuff (remember its a small team and they can't be everywhere), and/or use the training approach as roving advisers to educate and lead, and/or use the tool approach - arm them with a tool or technology like XML Security gateway or static analysis tools to make a small band more effective in a large organization.
Gary likes the mix of top down and bottom up
"that approach often leads with the creation of a special ops execution team that becomes the software security group. By far, this is the most impressive approach in terms of results and the one that is the most effective in well-run enterprises."
Yup, given a small, motivated smart team, with some executive buy in on specific goals; and you will be surprised what positive changes can happen. The thing is - we are at a point where we finally have _some_ good software security tools and techniques, the biggest challenges now are engineering and deployment. We can learn from software developers in that iterative, incremental delivery is the way to go.