7

This question is indeed targeting SDL but for Scrum. The A-SDL from Microsoft is nice, but honestly I am not even daring testing it in reality as it seems too academic. I mean what they request for, requires an army of developers! or a dedicated Scrum for Threat Modelling --in case the models are sound! So, I would be thankful if you can share feedback on any SDL approach you have used for Scrum (including A-SDL as you may prove me wrong!)

Rory Alsop
  • 61,367
  • 12
  • 115
  • 320
Phoenician-Eagle
  • 2,167
  • 16
  • 21

2 Answers2

2

Very good question... SDL and Agile are often seen to be at loggerheads, though they dont need to be.
In fact, I recently gave a talk at OWASP about this (Agile in general, not necessarily SCRUM), and met with some skepticism at first... but eventually most were convinced of the possibility, at least.

I agree about MS's SDL, while I think its one of the best models for large companies, it is "heavy" (as I said in another lightweight SDL question), and has quite a lot of overhead. (though I dont think its academic, it just doesnt apply to most of us).

Without setting up a complete SDL here, and without context of knowing your org, I would say these are some of the important elements:

  • Training (which is already a big part of most Agile practices)
  • Map SDL requirements to Agile tasks, and allow the team to complete these themselves. It's not about passing your checkpoints...
    • Non-functional stories added to backlog
    • Completion criteria (sprint / release)
    • Product security requirements -> "ab user" stories
  • Frequency based "Wedges" (not wedgies)
    • Some tasks are one-time requirements, simply need to be completed like any other requirement
    • Some tasks are for every sprint - these are designated "Sprint Completion Criteria"
    • Some are only for public releases (some methodologies seperate the two, some treat every sprint as a public release) - "Release Completion Criteria"
    • Sometimes you might want to do a "Security Spike" - a whole sprint focused on different security aspects
    • MS idea of "Bucket" requirements seems nice, though I've never implemented it and would depend greatly on the culture/needs of the org. (Set up a group of req's with the same classification, or "bucket", and each time you need to choose one from each bucket).

This is just the general outline... Let me know if you want more detail. Of course, what goes into each wedge, and what activities must be performed when/how, really depends on knowing your organization, culture, needs, risk profile, etc etc.

I find the overriding change in concept from "Classic" SDL (or "Waterfall" SDL) that needs to be accepted is:

"Classic” SDL was about control.
Agile SDL is about visibility

Community
  • 1
AviD
  • 72,138
  • 22
  • 136
  • 218
  • I would be interested to have the presentation of your talk at OWASP :)? Then regarding the Agile SDL, my concern is: -How to prioritize security features over other ones? What if the security features yielded to results that should impact the work being done, like stopping other colleague going on with the development? – Phoenician-Eagle Nov 22 '10 at 09:36
  • A security "spike" is how to involve security in the Agile process. A "hardening" sprint is what you describe. – atdre Nov 22 '10 at 21:36
  • what I described is well known as a "spike". But yes, in effect this can be seen as a "hardening sprint". – AviD Nov 22 '10 at 21:47
1

Replace Scrum with ICONIX. The only thing that works with Scrum is security-focused iteration review and ratcheting. A lot of Scrum deployments are green-blue, so it would make sense to optimize these for security as well. It would be very smart to harden the VM if managed code is used, or to watchguard a banned function list. Additionally, secure external components could be used. There's actually a lot you can do, but forget about the SDL, Touchpoints, or CLASP.

atdre
  • 18,885
  • 6
  • 58
  • 107