Over the past two decades, there has been a significant proliferation of computer software. This has allowed the organization to become more efficient and streamlined, eliminating the reliance on paper based processes and the need for phone based information and support. Over the last decade, this software shift has continued to evolve towards web based applications. This most recent shift has further increased organizational value and reduced costs by enabling the end consumer to be self sufficient. However, with this explosion of computer software has come both complexity and security concerns.
While software proliferation and complexity has been explosively driven by business need and market demands, security testing has not kept pace. A relatively small group of individuals, usually found within the IT organization, has voiced their concerns and attempted to implement controls to assess the risk or lack of security within the software. Over the past decades we have seen the shift in security testing. Let’s consider the stages of automated security testing and the value the organization receives in deployment, development and design.
The first types of software security testing looked at the deployment of the software. Underlying all software, web based or not, was an underlying infrastructure that supported the deployment. Security assessment technology first gave rise to the tools that addressed the need for patch management and remediation. There has been a specific trend from negative based deployment assessment tools (looking for missing patches and poor configurations) to positive based assessment tools (ensuring the compliance of the infrastructure by enforcing defined policy). Open source tools such as Nessus have provided value to the organization by looking at the underlying infrastructure and reporting on security deficiencies.
When applied directly to web based applications, security assessment tools such as IBM Rational AppScan became an important part of the organizational security landscape by performing security assessments on web applications in deployment or immediately prior to deployment. Over the past 10 years, this type of security assessment has brought, and continues to bring, tremendous value to the industry by shining a light on one of the weakest links in the defenses of the organization. It highlights the fact that most web applications contain critical vulnerabilities and the need for more and better software security education and awareness.
These first security tools, which required a running application, also focused a light on another need – to address security earlier in the software development lifecycle (SDLC). Many, if not most of the issues being reported, were vulnerabilities introduced during development. By finding and remediating these issues earlier in the SDLC, research has proven that this could lead to as much as a 100X reduction in operational cost.
While security assessments have evolved from deployment to development, this has occurred on several different fronts. Firstly, there has been an evolution towards introducing security tools to a group of people whose primary concern is building and testing software – development. This introduction has required the security industry to face two changes: security tools must not require an expert in the field to run them, and they must communicate in the language of their user. Over the past five years, this evolution in security assessment tools has become very evident. It is a trend that has expanded the number of potential resources the organization has to address the application security risk.
Secondly, automated security assessment tools could not continue to wait for a running application in order to perform the assessment. While a running application could emerge well before deployment, the industry recognized that performing assessment on the source code itself could allow for much earlier detection of vulnerabilities. The past five years have also given rise to source code analysis tools such as IBM Rational AppScan Source Edition. While there might be the mistaken notion that source code analysis tools have superseded the traditional dynamic analysis tools, the reality is that these tools are very much complimentary. While this paper is not intended to cover the strengths and weaknesses of each approach, this industry shift has brought increased value by delivering broader vulnerability coverage and bringing the development teams directly to the line of code where the vulnerability can be found.
Thirdly and lastly, we have seen another shift in the development space. In the past two to three years, application security assessment tools have become a seamless part of the SDLC process. The value this trend brings to the industry is not to be underestimated. Development teams need to be focused on development. To the extent that security tools impede this effort or distract the development teams, is the extent that it will increase organization costs and cause pushback by those that it is intended to help. With the introduction of purpose-built automated tools such as IBM Rational AppScan Build Edition, these security assessments can be performed during the development cycle in a completely seamless fashion – from the running of the security assessment, to the pushing the defect into the defect tracking system, to the re-analysis of the security issue during the next development cycle.
These three trends have been growing in momentum over the past five years until almost all enterprise organizations with an in-sourced or outsourced software development group have introduced some level of security automation during development. This momentum continues to ripple out to the medium and small business world as they recognize the need for security in deployment and development. These security tools have done an exceptional job at detecting implementation and deployment issues and continue to improve over time. However, there continues to be a deficiency in the software production space in one last area – design.
An entire class of issues have continued to exist that have not been addressed by existing security tools. These issues have to do with the design of the application and have been referred to as business level or logical security issues. As a simple example of a design level security issue, the application that allows you to reset your password by providing your username and email address is easily compromised. The traditional response to design level security issues is that automated tools are not sufficient to address these problems. I submit to you that there are multiple technologies that can aid in this third and final area of security problems, and that bring significant value to the organization.
Let’s begin with the very simply concept of prioritization or something known as the predictive threat index (PTI). Knowing that resources are limited within the organization and that not all applications represent an identical level of risk, it is important to introduce a very simple way to scale the relative risk. This can be done with a very simple 5 question survey that anyone is able to complete asking very basic questions:
- Does this application contain sensitive information?
- Does this application connect to third party systems?
- Is this application exposed to external parties?
It is expected that these questions would probably be largely dependent upon the industry vertical that the organization was part of. The resulting score is an important piece of metadata. It represents relative risk. Using an asset management system such as Rational Asset Manager, allows the organization to attach the PTI and other critical pieces of metadata to the application such as owner, security contact, languages, etc. Before a project is even in the design stage, these should be very simple pieces of information to assemble and record in a central repository.
Next in the design phase comes the concept of threat modeling. This concept derives from the need to delineate the specific threats that an application will face, and correlate the relevant countermeasures to each threat. The use of Rational Method Composer or free tools in the development space allows these models to be created and then reused for similar projects. Value is derived at the enterprise level in the explicit threat definition by allowing the testing teams to test specifically for these threats.
Threat modeling naturally leads to an often missed aspect of secure design – security requirements. Many software projects begin with an almost humorous requirement of, “the software must be secure.” What does this mean? How does one test for this? How does one automate the testing of this requirement? The use of tools such as Rational Requisite Pro allow the team to explicitly define security requirements in the areas of great concern – input validation, authentication, authorization, encoding, error handling, logging, etc. These requirements management tools often allow the use of templates so that the wheel need not be invented each time a project is begun, but that the design teams can quickly choose the areas that are most relevant and attach these requirements for the development teams. However, security requirements fundamentally address an area we have talked of earlier – logical security flaws. By introducing security requirements in the business logic (often stemming from the Threat Modeling), we now have specific issues to test for outside of the implementation vulnerabilities.
As many of the implementation security requirements are similar, the reuse of architectural and component level assets again becomes an essential piece of the design phase – elevating once more the need for an asset management system. The value of the Asset Management system cannot be underestimated for the enterprise. It brings efficiency to the organization by allowing them to focus on the areas where the development team could not use a proven secure architecture or component when it comes time for automated testing or code review. We have seen significant improvements to the security of software by the simple introduction of validation into some of the more common development frameworks such as .NET and Java Struts. To the extent that these secure APIs can be introduced into the common development frameworks, we will see tremendous improvement in the security of new applications being designed, developed and deployed.
Secure design will be the space in which the software community will need to move over the next three to five years. This will require collaborative enterprise environments that do not put together many different silos of technology that are unable to communicate without customization, but an application lifecycle management system that seamlessly moves the software from design, through development and into deployment – understanding and communicating the aspect of security and risk along the pathway. Only then will we deliver the high quality, compliant and secure applications that our clients demand.