One of the first steps for iterative development is to establish a theme for each Sprint that defines what type of capabilities will be addressed during this segment of development. As the theme of each Sprint is identified, forecasted security implications are discovered and documented and possibly stubbed in during development.
Stubbing is a technique that allows portions of the application to be developed without the entire functionality being coded at that time. Now it is important to capture security-related scenarios and details that coincide with the capabilities being defined throughout the iterative discovery and development process of the specific Sprint.
As the security requirements are uncovered, a decision on whether to include the security capabilities, stub them in or defer them to later Sprints must be made. There are two points that really frame the decision to include the security in the Sprint. The most significant influence to this decision is whether or not the software will be deployed and actively used as well as the security risks and sensitive information involved.
If it will be deployed, security must be built in and tested as part of the Sprint. If not, stubbing or deferrals are both viable options. At this point, iterative development begins. The software is developed and typically undergoes low-level testing as well as demos and code walkthroughs with the customer. These test cases and scenarios must exercise the security measures. That being said, it has been my experience that this does not happen. All security related functions and features that have been included must be exercised and demonstrated. Increased attention in terms of testing and code reviews must be given to race conditions, cross-site scripting, information leakage and SQL Injection. These four coding problems have proven to be the most common software vulnerabilities in Web applications. Once basic testing has been completed, the software can be moved to a simulated deployment environment.
The software delivered as part of the Sprint is installed into a representative operational environment. The vast majority of the time the development environment is far different from the operational environment. This can and has caused software operational problems and security issues. Deployment in an environment that mimics that of production is required so these problems and issues can be resolved. All the test cases and scenarios used previously form the basis for regression testing. The automated test script is replayed to validate proper operation in the new environment. In addition, new test scripts and scenarios are created to fully exercise the software from end to end as well as to examine and test for security vulnerabilities. Once all of these tests are successful, the software moves on to the next stage which is acceptance by the customer.
At this stage the software delivered as part of the Sprint or Sprints is demonstrated, evaluated, and verified and is accepted or rejected by the business customer. This must include the examination of security. Just as the customer has business acceptance criteria, they should also create security acceptance criteria. While it seems to be black and white, it is not. Conditional acceptance is the norm. Often time the sponsor will only accept the Sprint delivery if this, that and the other thing is changed. As identified as conditions of acceptance, the rework is scheduled. Once scheduled, the rework required to meet the conditions for acceptance is done. Once the rework is done and tested, the rework is reviewed and demonstrated to the business customer to ensure the intent of the conditional acceptance has been met.