We have done a lot of work over the past 3 years to develop an effective software security program. We began working with Cigital’s Touchpoint model in 2006, starting with an internal vulnerability assessment. Touchpoints, described in Software Security: Building Security In by Gary McGraw, outline the required practices for secure software development. But to get real, applied value from the touch point model you have to break your own trail, or get consulting help from Cigital.
We brought consultants in from Secure Software (now part of Fortify) and Cigital’s software security practice to establish a baseline for the system and our organization, including a detailed tool-assisted code review and architecture assessment. With Cigital’s help we built a secure SDLC roadmap for the team, trained everyone in defensive coding, developed secure coding and code review guidelines, and added static analysis tools into our continuous build process.
Working with Cigital definitely kickstarted our security program. Cigital has some smart guys, and they know their stuff. However their approach became more heavyweight over time: their engagement model included assigning a practice manager and a project manager to what were otherwise small engagements, adding to cost and overhead while contributing little value. Their consulting model is clearly targeted towards bigger companies, with bigger consulting budgets and longer time horizons. We needed practical, concrete, immediate feedback; tools and deliverables that we could understand and use right away; and we worked hard with their team to get this.
As part of our security program we also work with another expert consulting firm, Foundstone Professional Services, who we contract for application vulnerability assessments and penetration tests. They have an efficient and well-defined engagement model, they are professional and thorough, and they’re fast. We get high-quality, clear and actionable feedback from their pen testing team – the results of Foundstone’s work not only validate the security of a release, they also provide a health check on the overall security posture of our team.
Based on this work, with the help of Cigital and Foundstone, we have a solid foundation in place and a high-level roadmap for continuous improvement. I am reviewing our next steps, looking to where we can get the most bang for our buck. To help with this I have been looking for a secure SDLC framework suitable for small companies – companies that cannot afford heavyweight process controls (with independent security teams and so on) and large expert consulting budgets, but still need to hold to a high standard of due diligence for secure software development and delivery.
I started working with the CLASP (the Comprehensive, Lightweight Application Security Process) framework from OWASP developed by Pravir Chandra while he was at Secure Software: Pravir then went on to Cigital (he was one of the consultants working with us) and is now independent. CLASP comes with a fair amount of resources, and is intended (as indicated by its name) to be lightweight. However it has not been well maintained since it was contributed, it is not aligned well with other OWASP initiatives; and there is little information on how to apply it and how to scale it. Just as I was growing frustrated at the amount of work it was going to take just to make CLASP useful, Pravir released “CLASP on steroids”, contributing a completely new framework, OpenSAMM to OWASP
OpenSAMM, a Software Assurance Maturity Model, offers a roadmap and well-defined maturity model for secure software development and deployment, with some good tools for self-assessment and planning. So far from my review, OpenSAMM seems more pragmatic than the “Building Security In Maturity Model” BSIMM developed out of the initial collaboration between Pravir, Gary McGraw at Cigital, and sponsored by Fortify Software.
I am working with OpenSAMM to see how it scales to small companies, with small teams using agile development methods. So far it looks promising and actionable. I have completed an internal assessment using the self-assessment tool, and I’m comparing the gap analysis findings to our roadmap plans. I will keep track of my experience with applying OpenSAMM and record my findings as I go along.
Friday, April 17, 2009
Thursday, April 16, 2009
Making Things Happen
I am reading an excellent book on project management called “Making Things Happen” by Scott Berkun, who used to run major projects at Microsoft, and then worked in their engineering excellence group. I quickly zeroed in on Chapter 13, titled “Making Things Happen” which explores what I believe project management is really about – doing whatever it takes to help the team get the job done.
How does a project manager “make things happen”?
First, one of the critical questions that should be asked when hiring a project manager, after you have checked out the candidate’s technical background, is: “If things were not going well on an important project, would I feel confident sending this person into that room, into that debate, and believe that he’d find a way to make it better, whatever the problem was?”. The team has to be convinced that the candidate can make a difference in tough situations.
The project manager’s job is to find out the priorities and manage to them. Make this list of priorities clear to everyone involved – the team must be focused on doing only what is important to success. “What wastes time on projects is confusion about which things should come before which other things.”
Set clear goals, make sure everyone understands them, followup and reinforce priorities. Everyone needs to understand what the “priority 1” list is: the list of things that must be done to succeed. Keep this list as small as possible.
Prevent miscommunications and missteps. Help people take secondary, minor things off of their plates. Resolve conflicts by driving back to the project’s priorities, the critical success factors.
Remove obstacles. Risk management is part of this of course: setup the project to minimize obstacles upfront, watch for things that could go wrong and manage them. Handle people problems. Fix the environment – make sure people can get their work done.
Be relentless. Don’t give up, don’t stop looking for alternatives. Berkun talks about the example of Apollo 13, where the team kept driving to fix unfixable problems and save the mission.
Question people (even powerful ones) and challenge assumptions. Believe that there is a solution to a problem – even if it means changing the definition of the problem. If you can’t find an answer that means that you haven’t looked hard enough.
Own the problem. Escalate, use your network, create options and alternatives. Be dead serious and fight to the end - there is always a way out.
All of this might sound over-done, over-dramatic, but I believe that this is what sets successful project managers apart – the sense of ownership, the ability, the discipline, the drive to execute.
How does a project manager “make things happen”?
First, one of the critical questions that should be asked when hiring a project manager, after you have checked out the candidate’s technical background, is: “If things were not going well on an important project, would I feel confident sending this person into that room, into that debate, and believe that he’d find a way to make it better, whatever the problem was?”. The team has to be convinced that the candidate can make a difference in tough situations.
The project manager’s job is to find out the priorities and manage to them. Make this list of priorities clear to everyone involved – the team must be focused on doing only what is important to success. “What wastes time on projects is confusion about which things should come before which other things.”
Set clear goals, make sure everyone understands them, followup and reinforce priorities. Everyone needs to understand what the “priority 1” list is: the list of things that must be done to succeed. Keep this list as small as possible.
Prevent miscommunications and missteps. Help people take secondary, minor things off of their plates. Resolve conflicts by driving back to the project’s priorities, the critical success factors.
Remove obstacles. Risk management is part of this of course: setup the project to minimize obstacles upfront, watch for things that could go wrong and manage them. Handle people problems. Fix the environment – make sure people can get their work done.
Be relentless. Don’t give up, don’t stop looking for alternatives. Berkun talks about the example of Apollo 13, where the team kept driving to fix unfixable problems and save the mission.
Question people (even powerful ones) and challenge assumptions. Believe that there is a solution to a problem – even if it means changing the definition of the problem. If you can’t find an answer that means that you haven’t looked hard enough.
Own the problem. Escalate, use your network, create options and alternatives. Be dead serious and fight to the end - there is always a way out.
All of this might sound over-done, over-dramatic, but I believe that this is what sets successful project managers apart – the sense of ownership, the ability, the discipline, the drive to execute.
Subscribe to:
Posts (Atom)