• Embed Doc
  • Copy Link
  • Readcast
  • Collections
  • CommentGo Back
 
Table of contents
Introduction................................................................................................................2 Why the old security paradigm no longer applies..........................................................2Changing the paradigm..............................................................................................3The costs of failing to build secure applications..............................................................3 Application Security is a quality issue...........................................................................3 Why insecure web applications are the norm................................................................4The result...................................................................................................................5Creating a better, more secure application development process.....................................5 Application Security—The new frontier for QA...............................................................6Conclusion.................................................................................................................7
Pillars of Application Quality:Security, Functional, and Performance Testing
 An HP Software Next Big Thing in QA White Paper
 
Introduction
Historically, application developers and qualityassurance (QA) teams have not focused on security. Why? They haven’t focused on security because wehave not asked them to. IT Management typically asksdevelopers to achieve two goals—build innovativefeatures and see that the project is completed ontime. For QA teams, the expectation is to see thatthe application functions as intended and that it canscale effectively and perform under load (functionaland performance testing). At no point during thedevelopment and QA phases does managementtypically expect that any real form of security testingwill take place. In fact, security testing is oftenviewed as an initiative that works in opposition to theaforementioned goals, as it can extend the alreadylengthy development and testing phases. Far toomany organizations treat security as an afterthoughtas opposed to being integrated throughout thedevelopment process. In addition, most developersand QA professionals do not consider themselvesresponsible for application security—assuming thatsecurity will be managed while the application is live.
 Why the old security paradigmno longer applies
 When organizations were forced to invest in networksecurity due to the increasingly interconnected natureof the Internet, they tackled the problem by hiring oroutsourcing security talent and empowered them to solvethe problem of securing the organization for externaland internal security threats. To a large extent, securityteams have and still do work in organizational silos. Thisapproach, while it is not the most effective, worked sincededicated security teams had both, the skills to identifyproblems, as well as the ability to implement solutions.Take, for example, a situation where a security auditdiscovers that a server housing sensitive informationis unnecessarily exposed to the Internet. In this case,the security team is able to identify the risk posed bythe exposed machine and mitigate the threat by writinga firewall rule to restrict access. While this approachmay work for network security, it breaks down asorganizations shift their focus to application security. According to industry analysts, 75% of attacks byhackers now occur at the application layer, not thenetwork layer. This shift has occurred for a few reasons.Enterprises have decreased the time between softwaresecurity-patch releases to reduce the window ofopportunity for attackers and known vulnerabilitiesto reach the public domain. At the same time, customweb application development has exploded as newtools and development frameworks have decreased thetime and level of skill required to develop web-basedapplications. This is combined with the fact that mostenterprises fail to emphasize security testing duringthe development and QA phases of the softwaredevelopment lifecycle (SDLC). As a fall out, attackershave adapted to target IT’s softer underbelly—theweb-based applications.The old paradigm of empowering a security team totest applications and networks after development orimmediately preceding deployment no longer works.In this new world, while security teams may have theskills to identify vulnerabilities in applications, they arenot empowered to implement a solution because thesolution must be done at the code level. Security teamsmust go back to developers who have not been trainedin security best practices and request a fix for discoveredsecurity vulnerabilities. This cycle results in a conditionwhere the same security vulnerabilities are embeddedwithin applications over and over again.
2
 
Changing the paradigm
In order to break this cycle, we must change the waythat we fundamentally approach application security.Gone are the days when anyone involved in applicationdevelopment can say “Security is not my responsibility.”Security is everyone’s responsibility as it has severeimpact on the business if not taken seriously. We mustintegrate security throughout the SDLC, not just hastilyadd it to the end. This integration will only occur if weinvolve developers, QA teams, and the managementin security. Making such a fundamental shift will nothappen overnight, but it is essential if we are to stem thetide ofapplications riddled with security vulnerabilitieswhich offer multiple attack vectors and leave enterpriseswide open to attack.
Costs of failing to build secureapplications
Today, the Internet has become an easy target forattackers. With as many as 85% of web sites vulnerableto attack
1
, it is no wonder that the attackers have shiftedtheir focus to web applications as an entry point intocorporate networks. This, along with the fact that theweb has evolved from being an online, accessiblepresence to now delivering mission-critical applications,means that web-application security is now a criticalcomponent of the overall enterprise security. Despitethis fact, traditional development and QA cycles forbuilding web applications do not incorporate securityinto existing processes. This inability to test and rectifyvulnerabilities before an application goes into productionleaves confidential data within a web application at riskfor attack or misuse.The costs of a security breach can be significant. The2007 CSI Computer Crime and Security Survey
2
foundthat the average reported loss among survey respondentsamounted to $350,424, which was more than a two-foldincrease from the previous year. Additionally, thePonemon Institute’s 2006 Annual Study, Cost of a DataBreach, found that the average cost per lost customerrecord amounted to $182. This amounted to an overallaverage cost of $4.8 million per breach. While thesestatistics are not exclusive to web application attacks,corporate web applications are a common attack vectorfor accessing confidential data.Industry analysts estimate that the failure to identifyand repair security vulnerabilities during the softwaredevelopment process can carry extra costs. Removing adefect after software is operational can cost betweentwo and five times as much as correcting the error withinthe development and QA process.Moreover, by incorporating security testing by QAteams, the following opportunities to reduce the costsof vulnerability remediation exist:•Defect correction during code and unit tests canreduce the cost impact by a factor of between threeand 20 percent.•If 50 percent of software vulnerabilities were removedprior to production use, enterprise management costswould be reduced by 75 percent. Add increasing accountability for proof of regulatorycompliance due to government and industry mandates,and the need for integrating methodical securityassessment into the application quality or deliveryprocess becomes clear.
 Application Security is a quality issue
Many—if not most—businesses deploy web-basedtechnologies under the assumption that gateway securitymeasures such as firewalls and intrusion detection andprevention systems (IDS/IPS) are sufficient to protect webapplications from attack or misuse. This is a dangerousassumption. Web applications, by design, are exposedexternally or to predefined internal populations, generallyon port 80 (HTTP) or port 443 (HTTPS). A firewallwill do nothing to protect a web application fromvulnerabilities at the application layer; it can only beused to restrict who can access the application in thefirst place. IDS and IPS systems on the other hand relyon signature-based rules to detect anomalous behavior. Web applications are custom applications, not off theshelf software components. Due to customization andever-changing nature of web applications, it isextremely difficult to write IDS/IPS signatures that willdo anythingmore than detect the most basic attacks.The majority of vulnerabilities in web applicationsreside in the custom business logic of the applicationitself. Compensating controls provided by externalproducts are temporary solutions which seek to hidethe vulnerability. It is typically only a matter of timebefore an attacker identifies an alternate entry pointor is able to encode an attack in such a manner thata signature-based technology is unable to detect theattack packet. Only by correcting the vulnerable codeis it possible to fully protect the application. It is for thisreason that developers, QA teams, and the managementmust share in the responsibility of developing securecode. Auditing a web application either prior to orfollowing release into production simply is not sufficient
3
1
http://www.webappsec.org/projects/statistics/
2
http://www.gocsi.com/forms/csi_survey.jhtml
of 00

Leave a Comment

You must be to leave a comment.
Submit
Characters: ...
You must be to leave a comment.
Submit
Characters: ...