PaulDotCom mailing list archives
Re: Agile SDLC
From: Kevin Shaw <kevin.lee.shaw () gmail com>
Date: Tue, 26 Feb 2013 22:19:12 -0500
Dark side? They call me Jedi all the time! :^) On Feb 26, 2013 10:04 PM, "Matt Konda" <mkonda () jemurai com> 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 Pauldotcom () mail pauldotcom com http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom Main Web Site: http://pauldotcom.com
_______________________________________________ Pauldotcom mailing list Pauldotcom () mail pauldotcom com http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom Main Web Site: http://pauldotcom.com
Current thread:
- Agile SDLC Megan Mauch (Feb 25)
- Re: Agile SDLC Josh More (Feb 26)
- Re: Agile SDLC Pat (Feb 26)
- <Possible follow-ups>
- Agile SDLC Matt Konda (Feb 26)
- Re: Agile SDLC Kevin Shaw (Feb 26)
- Re: Agile SDLC Josh More (Feb 26)