Introduction
Historically, application developers and quality assurance (QA) teams have not focused on security. Why? They haven’t focused on security because we have not asked them to. IT Management typically asks developers to achieve two goals—build innovative features and see that the project is completed on time. For QA teams, the expectation is to see that the application functions as intended and that it can scale effectively and perform under load (functional and performance testing). At no point during the development and QA phases does management typically expect that any real form of security testing will take place. In fact, security testing is often viewed as an initiative that works in opposition to the aforementioned goals, as it can extend the already lengthy development and testing phases. Far too many organizations treat security as an afterthought as opposed to being integrated throughout the development process. In addition, most developers and QA professionals do not consider themselves responsible for application security—assuming that security will be managed while the application is live.
Why the old security paradigm no longer applies
When organizations were forced to invest in network security due to the increasingly interconnected nature of the Internet, they tackled the problem by hiring or outsourcing security talent and empowered them to solve the problem of securing the organization for external and internal security threats. To a large extent, security teams have and still do work in organizational silos. This approach, while it is not the most effective, worked since dedicated security teams had both, the skills to identify problems, as well as the ability to implement solutions. Take, for example, a situation where a security audit discovers that a server housing sensitive information is unnecessarily exposed to the Internet. In this case, the security team is able to identify the risk posed by the exposed machine and mitigate the threat by writing a firewall rule to restrict access. While this approach may work for network security, it breaks down as organizations shift their focus to application security.
According to industry analysts, 75% of attacks by hackers now occur at the application layer, not the network layer. This shift has occurred for a few reasons. Enterprises have decreased the time between software security-patch releases to reduce the window of opportunity for attackers and known vulnerabilities to reach the public domain. At the same time, custom web application development has exploded as new tools and development frameworks have decreased the time and level of skill required to develop web-based applications. This is combined with the fact that most enterprises fail to emphasize security testing during the development and QA phases of the software development lifecycle (SDLC). As a fall out, attackers have adapted to target IT’s softer underbelly—the web-based applications.
The old paradigm of empowering a security team to test applications and networks after development or immediately preceding deployment no longer works. In this new world, while security teams may have the skills to identify vulnerabilities in applications, they are not empowered to implement a solution because the solution must be done at the code level. Security teams must go back to developers who have not been trained in security best practices and request a fix for discovered security vulnerabilities. This cycle results in a condition where the same security vulnerabilities are embedded within applications over and over again.
Changing the paradigm
In order to break this cycle, we must change the way that we fundamentally approach application security. Gone are the days when anyone involved in application development can say “Security is not my responsibility.” Security is everyone’s responsibility as it has severe impact on the business if not taken seriously. We must integrate security throughout the SDLC, not just hastily add it to the end. This integration will only occur if we involve developers, QA teams, and the management in security. Making such a fundamental shift will not happen overnight, but it is essential if we are to stem the tide of applications riddled with security vulnerabilities which offer multiple attack vectors and leave enterprises wide open to attack.
