More on Security Development Lifecycle

In a previous blog, I talked about the methodologies and maturity for a security development lifecycle (SDL).  This is only one piece of the SDL program, and it takes people, process and technology to implement a SDL.  When we looked at these aspects, we tried to come up with a staged approach so we could implement security in our development process but in a way that didn't overrun people.

People
On the people front, we looked at the number of people and their roles for a centralized SDL team.  We quickly found we needed:

• 1-2 FTE for 1 yr to write the process and training materials
• 1 FTE for training coordinator
• 1 FTE for security tool administration (1/2 FTE for admin, 1/2 FTE for BA)
• Security buddies (Microsoft term) to help R&D groups take ownership of SDL in their business units

Because of that last one, we knew we needed to have more help from the business units and this would take a lot more people.  We also saw, that as we added business units, this could increase the number of people in the central roles, so we would assess our work as business units came on board.

Process
For process, it was defining what security means in each of the stages of the software development lifecycle.  The things we looked at for the major points of the lifecycle include:

• Requirements
• Include security non-functional requirement documentation that cover:
• access controls
• deployment consideration
• authentication
• authorization
• input validation
• logging & auditing
• error handling
• Design
• Threat model the design
• Include trained business unit security liaisons (BUSL) and whoever wrote the security non-functional specification
• Development
• Perform security checkpoint reviews after agreed upon code completion time
• Security review reports
• Static code analysis with training best practice
• Testing
• Dynamic code analysis with training best practice
• Deployment
• Determine how corporate security is integrated or help external customers with their application security checks

Technology
We have static and dynamic security testing tools, so it was a matter of rolling those out to all the business units and providing a central offering for those without the expertise.  This was probably the easiest of the pieces to tackle only because of what we currently have.

Deployment
To deploy this in a phased approach, we looked at the tasks for people, process and technology and grouped them into what we could accomplish without too much disruption.  With that, we came up with this model to help us plan our work.

*STRIDE approach is the Microsoft approach to threat modeling using Spoofing, Tampering, Repudiation, Information disclosure, Denial of service and Elevation of privilege.

How did it go
So how did it go after we planned all this?  Most of the items are being rolled out but I'm not sure it is as coordinated as I would do it.  Being in the tool business, my main focus was on technology and we have the static and dynamic code analysis tools in place, but we are assessing their value and determining if we need to replace or promote the tools.  I feel pretty comfortable in our space, and I'm sure the development groups are getting more comfortable putting SDL practices in place with their work.