Re: Agile SDLC

[Kevin Shaw <kevin.lee.shaw () gmail com>]

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