Agile SDLC

[Matt Konda <mkonda () jemurai com>]

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