In its recent Website Security Statistics Report, WhiteHat Securityi found that during 2010, the average website...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
had 230 vulnerabilities that could lead to a breach or loss of data. Other recent studies have shown that roughly 70% to 80% of Web applications contain significant vulnerabilitiesii. And in its Top Ten 2010 report, The Open Web Application Security Project (OWASP) again reported that 10 software risks were responsible for the vast majority of vulnerabilities in website softwareiii.
The key is for organizations to treat security vulnerabilities like software defects, aka “bugs.”
These reports are only the latest in a series stretching back many years, all identifying almost exactly the same problem: Websites and applications are still being published with security vulnerabilities that could be corrected relatively easily. Unfortunately, most of these security vulnerabilities are being found only after the applications and websites are published. A hoary old cliché about security is it’s easier (and cheaper) to build security in, rather than trying to bolt it on afterwards, through remediation.
Why do these vulnerabilities escape the notice of the highly skilled developers that create the applications and websites that increasingly underpin our global economy? How can we, as security professionals, achieve secure Web development and provide the developers with the tools required to reduce the number and frequency of these types of vulnerabilities? The key is for organizations to treat security vulnerabilities like software defects, aka “bugs.”
The first step in this paradigm shift, and perhaps the hardest one, is to get development managers and security officers to agree that security vulnerabilities should be treated the same way as usability or functionality bugs. Most development managers are focused on functional defects -- defects that prevent the software from working correctly. The challenge comes in getting them to understand that security vulnerabilities, if exploited, also cause the software to function incorrectly, resulting in not only downtime to fix the defect, but also in financial and/or reputational losses to the organization.
Security vulnerabilities are software defects, and need to be handled exactly the same way. It can be challenging to reach that point of agreement; development managers often don’t understand the potential impact security vulnerabilities have on a business, they don't know how to identify security vulnerabilities, and they often don’t know how to remediate them even if they could find them.
In order to support developers in overcoming these challenges, security teams can increase Web application security testing during regularly scheduled vulnerability assessments on applications and websites already in production. Web security scanning tools like those offered by IBM or Vercode Inc. can be used for this type of testing. After testing is complete, developers should be charged with creating formal remediation plans for the security "bugs" that are found. By doing this, the developers become familiar with the security testing and remediation cycle.
Once developers are accustomed to the security testing and remediation cycle for software already in production, the next step is to incorporate security testing into the pre-production QA process, again using the same tools used for security assessments. At this point, security bug tickets should start to be opened in the same way other bug tickets are opened, using the same bug-tracking systems the developers already have at their disposal.
As a next step, we can further leverage the software development life cycle (SDLC) model to ensure consistency in the way Web applications are developed and tested. Even smaller businesses that produce software strictly for internal use are establishing rigid SDLCs as a means to reduce bugs. Those same processes can be leveraged effectively to locate security bugs as well. In order to leverage those established SDLC processes, developers will likely need training to use the aforementioned tools to identify security defects. Several vendors offer Web-based platforms that can easily be integrated into an SDLC, and can allow the developers to test their code at the unit level, early in the SDLC. As an added benefit, many such tools can provide remediation advice to developers at the time of detection. Finally, most of these tools can be integrated with the bug-tracking tools that developers already use, closing the loop on treating security vulnerabilities as functional defects.
By redefining security vulnerabilities as functional defects or bugs, and providing Web developers with the tools and processes they need to identify the bugs and remediate them, security stakeholders can make security an integral part of an organization's SDLC, building security in, rather than bolting it on. And that will lead to websites and Web applications that are not only cheaper, but also more secure.
About the author:
Gil Danieli is the director of information security for a national financial institution. With more than 20 years of experience in technology and information security, Danieli's primary focus is on finding actionable, inexpensive solutions to today’s security challenges, not filling compliance check boxes.
[i] "WhiteHat Website Security Statistics Report." WhiteHat Security. WhiteHat Security, 2011. Web. 11 Nov. 2011. <https://www.whitehatsec.com/resource/stats.html>.
[ii] Veracode. State of Software Security Report. Veracode.com. Veracode, 19 Apr. 2011. Web. 11 Nov. 2011 <http://info.veracode.com/state-of-software-security-report-volume3.html>.
[iii] OWASP. OWASP Top 10 - 2010: The Ten Most Critical Web Application Security Risks. N.p.: The OWASP Foundation, 2010. N. pag. OWASP.org. Web. 11 Nov. 2011. <https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project>.
Dig Deeper on Web Server Threats and Countermeasures