How to Achieve More ‘Agile’ Application Security

Application security has become a critical component of all software development efforts. It includes all measures taken throughout the software development lifecycle to prevent programming flaws from being exploited. The flaws that creep in during the requirements, design, development, deployment, upgrades, or maintenance stages of applications become the basis of cyber attacks.

Lack of security built into applications coupled with poor programming techniques are routinely exploited by hackers and has helped contribute to massive monetary losses attributed to data breaches and theft of intellectual property. That is why security must be an integral part of the application development methodology and the Agile process is no exception.

The Agile process is said to have been born back in November 2001. This approach to software development has been gaining ground in recent years. The Agile process is focused on iterative discovery and development that aligns development with customer needs and company goals. That said, I have found that the basic characteristics of Agile tend to push security off till after the business functionality has been built. I have found that many times security is not included in the initial release of functionality, thus making Agile security bolted on rather than built in.

In the examination of application security issues, I tend to group them into two categories — business logic flaws and technical vulnerabilities. It has been recognized that security must be built into applications rather than bolted on at the end. This presents a challenge when using the Agile methodology. It also has caused great debate about the suitability of Agile for applications that involve sensitive security information or applications that could provide a covert pathway (aka backdoor) into other systems.

I like many believe the Agile processes are unsuitable for security-sensitive software applications. This is primarily due to the lightweight, informal, build-as-you-go nature of Agile processes. Security must be built in, not bolted on; therefore, it must be integrated throughout the Agile process.

Security starts before the project. The security strategy and objectives must be established at the very beginning. After that and during the project definition step, high-level security requirements and objectives must be established, documented and communicated to the development team. Once we have these cornerstones of security set, we must assess what is necessary to meet these objectives. In the scoping and estimation step, time must be allocated to review the evolving requirements and refine the security requirements and objectives. After the scope of security is defined and the level of effort estimated, high-level security plans are developed. When you are developing these high-level security plans, you must establish security coordination activities that evaluate the security measures at each point along the iterative development effort and make sure those measures are considered. Now the foundation has been established and we can move on to security within the Sprints.

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.

Capturing lessons learned is the process of gathering, documenting and analyzing feedback that has been received during the Sprint. This is critical so subsequent Sprints can benefit from this experience. This is critical because capturing security lessons learned gives the team members a chance to reflect on tasks, events and activities during the Sprint that contributed to security short-comings. In addition, capturing lessons learned requires a retrospective examination of the risk management implement and documenting successes and shortcomings.

Putting it all together, all the software developed to date must be integrated and validated together. Once this is done, it must be validated to ensure proper function. Monitoring and tracking are required in the short term to make sure all the software and systems components are working together properly and do not create security vulnerabilities. Interactions between systems must be tested from a security standpoint. New security test scenarios must be developed and executed within this step.

In addition, as discussed earlier, increased attention in terms of testing must be given to cross-site scripting, information leakage and SQL injection. Once everything is working together properly and is secure, it is ready to be released into production. Release Management (RM) is the relatively new part of all software development methodologies and projects. RM becomes the liaison between all the business units and IT to guarantee smooth transition to the new system. Finally, the time has come to move to the next Sprint. The wrap-up step results in the Sprint being officially closed. In addition, this step creates the project artifacts and ensures proper documentation and the backup and archive of the code. This step often requires changes to security monitoring processes and capabilities that are in place at the business.

Conclusion

The security industry has given 2008 the dubious distinct honor as the “data loss year” due to the significant number of sensitive information security breaches that occurred. In congressional testimony by Director of National Intelligence Dennis C. Blair, he stated that last year global companies may have lost over $1 trillion worth of intellectual property to data theft in 2008. Software vulnerabilities represent one of the leading causes. This should concern everyone involved in application development regardless of methodology. It should also be seen as a warning to Agile development projects that they need to ensure proper security is built in, not bolted on.

Kevin G. Coleman is a 16-year veteran of the computer industry. A Kellogg School of Management Executive Scholar, he was the former Chief strategist of Netscape. Now he is a Senior Fellow and International Strategic Management Consultant with the Technolytics Institute — an executive think-tank. For six years he served on the Science and Technology advisory board for the Johns Hopkins University, Applied Physics Lab, one of the leading research institutions in the United States and served for four years on the University of Pittsburgh Medical Center’s Limbaugh Entrepreneurial Center’s Advisory Board. He has published over sixty articles covering security and defense related matters including UnRestricted Warfare and Cyber Warfare & Weapons. In addition he has testified before the U.S. Congress on Cyber Security and is a regular speaker at security industry events and the Global Intelligence Summit.