PaulDotCom mailing list archives
Re: Agile SDLC
From: Pat <nutjob.ie () gmail com>
Date: Wed, 27 Feb 2013 15:11:25 +1100
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 usefulinceating 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 areabout15% the size of MS. I'm looking for: How do we include security requirements in Agile, do we use User StoriesorAcceptance 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
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)