Evaluate Safe Code user stories

[jlyon]

http://safecode.org/publications/#safecodepublications-192

Spend ~1hr looking at these stories against the stories we've written and add some observations of them vs ours. Whether they suggest anything about the stories we've written. Add to #11

[aschmoe]

Thoughts:

• A/D/T seems like a useful type of designation for the user stories. Maybe could be extended to include O - organization, or C - CIO/whatever for tasks that are like "Ensure we have a policy" or whatever
• Furthermore approach of "O - Write access control policy, C - Keep logs showing access control, A - Ensure systems have access control, D - follow access control policy" seems to make the broadness of most of the NIST issues a little less daunting
• Having more consistent/frequent example lists seems like a big win (is happening in some places)
• Smaller granularity seems useful
• Occurs to me that perhaps system / application packs might be useful. I'm adding a new service -> Is this service covered by the access control policy ->Frst get CIO to create new draft -> What users need to be on the new system? -> Are these users outside the organization? etc

[jlyon]

• CWE instead of NIST
• Helpful concrete examples

Other Sources

• SAFECode’s Fundamental Practices for Secure Software Development
• CWE/SANS Top 25 Most Dangerous Development Errors
• OWASP Top 10

While SAFECode’s Fundamental Practices for Secure Software Development already lists a set of engi- neering tasks for creating more secure software, it may not be readily apparent to Agile development teams how best to incorporate these tasks into their unique environments. This section breaks down the Fundamental Practices into familiar Agile “stories” focused on security and derived from the issues most commonly seen by SAFECode members in their environments. Both the CWE/SANS Top 25 Most Dangerous Development Errors list (plus the 16 weaknesses on the cusp list) and the OWASP Top 10 list were also consulted to ensure broad coverage.