Dark side? They call me Jedi all the time! :^) On Feb 26, 2013 10:04 PM, "Matt Konda" <[email protected]> wrote:
> Hey Meg, > > Josh just pointed me to this thread so I apologize if the info is late or > out of context. Feel free to contact me directly to talk about this more. > I'm a 15+ year developer with lots of agile PM experience who got turned to > the dark side of security and started my own thing to try to help > developers do a better job with security in general. I'm not sure I'm > succeeding, there are a lot of things I don't know and I apologize in > advance for any bad assumptions or poorly phrased statements. :) > > To start, I wrote some blog posts about this that might be interesting (I > hope): > > - This is specifically about different ways of integrating security > into an Agile SDLC: http://www.jemurai.com/security-sdlc.html > - This is a series looking at agile generally in the context of > security. http://www.jemurai.com/agile-security.html > > Ultimately, I think you want to start by understanding how your teams are > using agile. Are they having daily standups? Are they using story cards? > How do they handle performance and things like validation rules? How do > they do QA? How do they do deployments? One of the biggest mistakes I > have seen is not taking the time to get *into* the process with the > developers. You should be a respected part of their team, like a > stakeholder, or it won't work. > > Perhaps the best thing you could do is to sit with a development team and > ask them how they think they can fit security into their process. > > In response to your specific questions: > > > >* How do we include security requirements in Agile, do we use User Stories > >or*>* Acceptance criteria?* > BOTH. Some security requirements justify their own stories. In most > stories, security is an aspect of the acceptance criteria for the story, like > validation rules and performance expectations. > > Often, new security issues get created as their own story. This works > sometimes, but it can also be counterproductive because we really want the > developers to build security into their conception of "done". So for example > when I find issues during a Sprint, that just keeps the existing story open > because it should not be considered completed. > > >* Examples of highlevel security gates and program overview. > * > > Depends on how your agile system works. Are you deploying every 10 minutes? > One key thing to think about is that you don't want to constrain yourself or > the developers to rare points in time where the review happens. You want to > learn how to do the security work incrementally along the way. A great > example is code review. Developers have adjusted to do incremental code > reviews, they just don't always look at security. Having someone who can do > secure code review incrementally is a great way to plug a control that works > into a process in such a way that everyone benefits. Also it can be helpful > to change thinking about when a security issue has to be found. If you have > 10 deploys a day, and you let a security issue get out but you find it within > an hour and can reasonably expect to do another deploy in an hour or two with > a fix, that's a much better position to be in that to have stopped everything. > > The blog post above includes a number of things you *can* do in Agile to > improve security. * > * > > * > *>* Since Agile is so lean and documentation is sparse, do folks create a*>* > security assessment reports for the final project Go/NoGo? > * > What I've done is to see major pen tests done at major release milestones and > other things built in continuously along the way. Part of the release > process might be a checklist that just ensures that the agreed upon controls > have been done. I think that having large deliverables of documentation is > counter to agile, so you have to find a way to flag or track the things you > are doing along the way so that you can document them if need be. > > >* Work flow examples? > > * > > Work flow might be that as you write a story, you do: > > * Pair programming for security > > * Security unit tests > > * Abuse cases on a story > > When you finish a sprint: > * Code review > > * Checklist (or metrics) that you have done the things you agreed ... (see > blog post)... etc. It really depends a lot on your dev process.* > * > > The really important thing is that the work should not be saved until its > time to do the release.* > * > > * > *>* Does anyone do self-service security assessments for smaller projects? > * > > Not sure what you mean here, but you definitely can have developers learn how > to do security along the way.* > * > > * > *>* Given that Agile is a lean process, what security project > documentation*>* besides requirements should be created?*> > > Agile is all about stories and code being self documenting. So if the > security tests (unit tests or otherwise) and stories can be self > documenting, that's awesome. As mentioned above, being able to search for > stories or subtasks within stories that are tagged with security can help > to build a trail if you need that. Honestly, as a developer, I think that > more documentation just means more documentation people won't really read. > > I hope this makes sense...I didn't intend to make assumptions about what > you might or might be doing or how things should work that won't fit for > you, but that's inevitable in trying to participate in a low context > conversation like this. ;) > > Good luck!! > Matt > > -- > Matt Konda > > > _______________________________________________ > Pauldotcom mailing list > [email protected] > http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom > Main Web Site: http://pauldotcom.com >
_______________________________________________ Pauldotcom mailing list [email protected] http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom Main Web Site: http://pauldotcom.com
