Security In Agile Plc - Practical Navigational Aid For Speed Boats
No ratings
Presented at SOURCE Barcelona 2010 by
The conventional software development lifecycle is like a ship where development requirements once agreed upon have little scope for changes at later stages. Furthermore, just as ships typically have electronic navigational devices to help pilots avoid dangerous coastlines, hazardous shoals and reefs, etc.; security requirements can help improve security assurance in each distinct phase of the development lifecycle. On the other hand, an agile development method is like a speed boat designed to handle rapid changes. Conventional software development lifecycle doesnt apply here. Also, just as speed boats cannot employ the same navigational devices used in ships due to size and structural restrictions, conventional security requirements cannot be applied as is in an agile development environment. In late 2009, we started looking at ways to transform the conventional security requirements into a granular task list which could be used in an agile environment used by multiple product teams at Symantec. Around that time, Microsoft came out with a list of security requirements that could be applied to each area of agile. In that list, requirements were classified into four categories namely: 1) Every sprint requirements 2) One time requirements 3) Bucket requirements comprised of three buckets 4) Security requirements for very risky code We looked at each requirement in the list and realized that the list was not suited for direct adaptation in Symantecs agile development environment due to the following reasons: 1) Quite a few of the requirements in existing categories could be better placed in other categories 2) Multiple requirements across given categories could be folded into a single base category 3) There was scope to add new categories with new requirements not in the original list 4) Requirements needed to be added to cover cross-platform scenarios i.e. non-Microsoft products Based on these observations, we decided to revamp the list which will be discussed in this talk. Few examples follow: 1) Multiple tasks were folded into a single base task in multiple instances. E.g. - a. In Every Sprint category, multiple compiler and linker requirements were folded into a single base task - Environment run-time and compiler requirements category . b. In Bucket A (Security Verification) category, verification tasks were analyzed, new ones added and all of them folded into a single base task - Conduct verification sprints (shorter in duration) corresponding to Security Verification bucket items -- At least thrice in a product's lifecycle (33%, 66%, 99%) . 2) New category called psg2help created detailing tasks for which a product team would typically require assistance from product security group due to the advanced security concepts used to meet them. Attendees can employ a similar approach to come up with security requirements for their agile development environments or at the very least use our list as is.