Re: Agile SDLC

[Pat <nutjob.ie () gmail com>]

My experience and 2c.

Take with a pinch of salt.


Code review and unit testing other peoples code yielded me some whoppers of
security bugs over the years. This may have been because I knew what to
look for.

There is more than just sqli, xpath, command injection, csrf and script
injection. Up there with most dangerous ones iv found were application
logic flaws.

*Step one is educate them.* Show them a demo of SQL to Shell and XSS to
chaining an exploit on a customers intranet with shell. Iv had the
conversation where a permanent XSS script injection was not as impotent as
a Hackersafe report with no warnings. If they know enough on what not to do
it helps.

Then play bug hunt with a bounty as a cheap way of finding bugs. Cash works
and is a cheap way of making sure the lessons stick.

If you want to build a metric into the exit criteria for a sprint that the
code is reviewed, has unit tests and has been looked at by a second dev for
security bugs your sailing.

One word of caution though, unless there is a rewards structure and time
allocated it will get dropped. Devs deal with constantly
shifting priories and often do not have time depending on the
work environment. Unless its actually scheduled and
enforced management will always push for more faster and the first thing to
get dropped is all the best practice.

No dev wants to hear you didn't deliver something working  when priorities
have shifted 4 times and the timeline moved up or scope increased which in
my experience is the norm unless your in a large mature org on 2 year
release cycles. They will usually focus on get something working and
drop everything else.

*You also need to educate your tester*. He/She is your stick to beat devs
with. If they get slack the tester should be able to beat them down. Again
time plays a huge factor here. Most testers iv seen
are overloaded massively and don't have the time to in depth test. Often
there is a 6:1 Dev:test ratio stretched across testing production sites,
dev bugs, staging/demo environments...

*Finally Management Education also*
You need buy in here. We need this in 6 weeks do what it takes is fine but
they need to drive to have a full cycle of Dev, test, unit test, security
test, code reviews that fits in that window with buffer and make sure that
cycle becomes routine, not just a once off until a firefight or priority
shift. Anything that adds weight to a process incurs a cost and if its not
hitting the window either more resources are needed/a bigger window
or efficiency gains ......


Then somehow you need to get all parties to sit down agree the approach and
run with it. With the understanding that to get it to work the first few
sprints may overrun. (never popular)



I could be getting old and cynical though. :)







On Wed, Feb 27, 2013 at 12:58 AM, Josh More <jmore () starmind org> wrote:

> Meg,
>
> Agile transitions and frameworks don't work very well together.  You
> can put security frameworks into long-running Agile teams, but during
> a transition, you don't know where you're going to end up, so any
> framework is going to limit the team. This is counter to the Agile
> concept itself and will engender extreme resistance on the part of the
> developers.
>
> The best thing you can do is have a presence in every sprint kick-off
> meeting, every retrospective and in every daily standup. If personas
> are being used, create a couple for attackers so the developers can
> start to think about what people should NOT be able to do as well as
> what they should.
>
> Do not hold your security assessment reports to the Go/NoGo stage.
> That'll just irritate everyone. Think smaller, more iterative
> assessments. Work the bigger infrastructure stuff into the
> long-running QA process so security issues show up in the Defect
> Tracking system (whatever you use).  For the sprints, think of the
> OWASP Top 10 and Binary Risk Analysis. When your developers are adding
> a feature set during a sprint, consider using your time to
> exhaustively test the application against SQLi and SQLi only.  Maybe
> the next sprint will be CSRF.  You have to be as agile as your team.
> Whether you use user stories, acceptance criteria or something else
> will depend more on how your team works than any "right" way to do it.
>
> If your team is leveraging test-driven development, write hooks for
> the source control system to reject obviously bad code. Start small,
> as this is a really good way to screw things up, but little rules like
> "no SQL in the mid-tier apps, only in stored procedures" will do
> wonders over the long term.  If you do nightly tests, look at doing
> automated tests with arachni and skipfish so you get rolling security
> metrics on the app.
>
> If you want more exploration of this idea, feel free to poke me
> off-list.  I mostly focus on business-level and infrastructure stuff
> in the Lean/Agile security space, but my friend Matt Konda does a lot
> on the development side of the house.  (Not sure if he's on this list,
> but I'll poke him.)  He can probably weigh in a lot more on this than
> I can.
>
> -Josh More
>
>
>
> On Mon, Feb 25, 2013 at 6:29 PM, Megan Mauch <oneilme77 () gmail com> wrote:
> > Hello,
> >
> > My company is looking to move from Waterfall project framework to Agile.
> > Does anyone know of any good resources or examples that would be useful
> in
> > ceating a security framework for Agile. I've seen Microsoft's, its really
> > good but maybe a little overkill for the size of our company. We are
> about
> > 15% the size of MS.
> >
> > I'm looking for:
> > How do we include security requirements in Agile, do we use User Stories
> or
> > Acceptance criteria?
> > Examples of highlevel security gates and program overview.
> > Since Agile is so lean and documentation is sparse, do folks create a
> > security assessment reports for the final project Go/NoGo?
> > Work flow examples?
> > Does anyone do self-service security assessments for smaller projects?
> > Given that Agile is a lean process, what security project documentation
> > besides requirements should be created?
> >
> > Thanks,
> > Meg
> >
> > _______________________________________________
> > 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
_______________________________________________
Pauldotcom mailing list
Pauldotcom () mail pauldotcom com
http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom
Main Web Site: http://pauldotcom.com