Jan 22, 2013

Agile and Secure (and II)


As we talked in the previous post, we are going to analyze how to use the Agile software development methodology and produce secure software. Security needs to be included in design and coding work from the beginning. To achieve this goal the organization can take into account different ingredients. 

The development team needs software security training early on so that they understand secure design problems and risks going in, and so that they can take care of them by making the right design and platform decisions. It could be delivered formal training for developers and WA teams, either online or in person and addressing common problem areas like most common security problems in your code.  

Secure Architecture: All begins with a Secure Architecture. Depending of the different project needs you could use different approaches in inter-tier communications, authentication methods, data protection, etc. If your architecture is insecure at least you should identify stories to make it more secure and prioritize those alongside other requirements.

Verification. Static Testing & QA automation: Many Agile teams rely on automated unit testing and acceptance testing to prove that the code works. But incremental, in-phase functional testing isn't enough in itself to build secure and reliable software.

At some point you should pen test the running system. With iterative, incremental development, the system is a constantly moving target, changing every week or two. You can't pen test the system at the end of each time box — there isn't enough time. But you don't have to. Schedule a baseline pen test when there is enough key functionality in place to be worth testing, but early enough that you can learn from it and before you have built too much software that may need to be changed. And any time after you have made a big change to the architecture or the attack surface, based on risk.

Verification. Penetration testing: It is convenient to use more than one technique to verify secure software. Besides static analysis you can use penetration testing (in-house or by a third party) to double check your software.

Pen tests and other security reviews don't fit nicely into time boxes, but they don't have to — they can be run as parallel engagements especially if you are bringing in someone from outside to do the work. The team members who are needed to help out will need some time buffered from their sprint commitments, in the same way that some teams need to buffer time for support work.

Any problems found in security reviews and pen testing need to be added to the team's backlog and dealt with like any other bug. If it's a serious enough problem, it should be reviewed by the team as part of their retrospectives — not just how to fix the problem, but what it means to how they develop software, what changes they need to make to how they design, code and test software to prevent problems like this from happening again.

Fuzzing complements the methods we saw by introducing dynamic testing that finds the unknown vulnerabilities. You can find more details about fuzzing and agile development in the Codenomicon’s paper: ‘Fuzzing As a Part of Agile Software Development Project’.

The different testing approaches, (static code analysis, dynamic scans, pen tests and even the fuzzing), should be included into a continuous integration (CI)* process that periodically runs these suits of automated tests against your software. With the automated tests you could improve the quality of your applications in terms of security. There are opinions regarding the quantification of this improvement, even thoughts talking about the 80/20 rule. Personally I found difficult to give an exact percentage of improvement but what I am sure is that you will focus your efforts just in the critical ones.

[*]Probably we will talk about security and CI in future posts.

There's no reason that Agile development has to be equal as Security Fail. The technical work, the commitment to quality and detail that is required to build secure software is the same, regardless of what development approach a team follows.

0 comments:

Post a Comment