Published: 15 Aug 2013
The importance of information security has permeated many enterprises to varying degrees, yet software security—and in particular Web-based software development— remains a vexing challenge for chief information security officers.
It’s a great understatement to say that Web development teams have not traditionally been focused on security. Their incentives, and consequently their priorities, have been tied to implementing new features and meeting deadlines. Many development teams aren’t even aware that what they do affects security; instead they view security as a job handled not by developers, but by products such as firewalls and antimalware systems.
However, the changing threat landscape and increasing frequency of Web application attacks has forced security-focused organizations to address Web application security through secure software development. The simple truth is that security measures that are “bolted on” after the software development process is complete have proven to be powerless in countering Web application attacks. For instance, firewalls only control the traffic allowed to pass over networks, but Web applications must be exposed outside the firewall in order to be accessed by legitimate users. Antimalware is similarly ineffective; it only looks for malicious code, not problems with legitimate applications.
Attackers have come to learn that nearly all Web applications can be exploited via the mistakes developers made when building them. Using any one of a long list of common Web application vulnerabilities, an attacker can make the software misbehave in any number of ways, including granting access to unauthorized data.
For CISOs, countering Web application attacks through secure software development is often a daunting proposition. While the scope of many CISOs is growing and often includes C-level access and influence, in few cases does that reach extend into the software development organization. Affecting a fairly significant set of changes to the way in which applications are developed requires not only evangelism to make the case for secure development, but also pragmatism in providing effective tools and training. Security managers must seize the opportunity to position themselves as trusted resources to foster secure software development within their organizations.
Evangelizing the need for secure Web development
In order to take on this role, security managers must be able to work hand-in-hand with development teams. However, developers can be wary of outsiders attempting to impose standards and behavior on them.
To enable security teams to have a positive impact on software security in their organizations, it is critical that the security professionals build and maintain credibility with developers.
More on secure software development
Adobe turns software developers into security ninjas
Does Web application security explains software security flaws?
Incorporating security into the software development life cycle
The problem is that most information security professionals do not come from a strong development background—especially backgrounds in modern Web application development environments. This makes it challenging for them to effectively communicate with the development team. For that reason, security professionals shouldn’t be afraid to say “I don’t know” when discussing highly technical issues, yet they can’t let developers brush them off or obfuscate important issues with technical mumbo-jumbo. Evangelism is, therefore, a balancing act.
Security professionals can improve their credibility with developers by providing information on real-world threats and security-related business demands that is customized for the organizations and development team needs. Companies fall under a variety of regulatory and compliance requirements, ranging from the Payment Card Industry Data Security Standard (PCI DSS) for those accepting credit card transactions, Health Insurance Portability and Accountability Act (HIPAA) for those dealing with personal medical information and the various customer data breach notification laws. Providing the developers with data that demonstrates the negative impact to organizations that have suffered a breach or compliance failure provides valuable context that enables the developers to understand the importance of incorporating security into their development process.
There are a number of sources available that provide this kind of detail. For example, vendors WhiteHat Security and Veracode report on their application testing efforts and the prevalence and longevity of different classes of software vulnerabilities. In addition, the annual Verizon Data Breach Investigations Report (DBIR) describes the types of attacks being used in actual breaches. Security teams that curate and distribute this information internally can help the development team focus on the most relevant and critical security concerns.
Providing security tools and training
Security pros must understand the tools used by the development team in order to better integrate security into their work flow. Security tools are a valuable component of any software assurance program, and security professionals can support development teams by understanding how developers use their tools while looking for ways to augment and tune those toolsets.
In addition, when putting security tools such as automated security code analysis tools or dynamic Web security scanners into developers’ hands, security teams must remember that these tools need to be configured and tweaked, and that the Web developers will use these types of tools differently than the security team would. These tools can be a great help in identifying common—and dangerous—Web application flaws like cross-site scripting (XSS) and SQL injection, but can overwhelm development teams with information that lacks relevance and can be hard to understand. For example, default rule sets and reporting are geared toward penetration testers and other security professionals.
However, before exposing the developers to these tools, security teams need to ensure the rules being used focus on high-impact vulnerabilities with signatures that have a low likelihood for false positives. Failing to properly tune the security testing tools like this can result in output that the developers find overwhelming, irrelevant and even detrimental, forcing them to waste time chasing after false positives.
Also, each tool’s reporting capabilities need to be modified to include information that helps the development team locate vulnerabilities in software code, as well as include specific remediation recommendations that make those reports more actionable. Some Web developers will be more comfortable with source code security scanners because they show the specific lines of code responsible for the bad application behavior. Other Web developers might be more comfortable with dynamic Web application scanners because offer working example payloads showing how a vulnerability might be exploited. Security professionals need to get a feel for how their Web development teams work and tailor tool recommendations accordingly.
The objective of putting new tools in developers’ hands should be to transition vulnerabilities into software defects. Vulnerability data might be of some interest to developers, but typically what they really care about are software features and defects they need to address to alleviate security concerns. This may seem like a subtle difference, but it is an important one because it reflects the way that developers plan and manage their workloads and can highlight the lack of understanding that many security teams have about the internal operations of development teams.
The need for ongoing collaboration
Tools should also help facilitate communication between security pros and developers. When a security analyst emails a lengthy PDF report detailing found vulnerabilities to the development team, that can be perceived as a hostile or standoffish way to communicate. A more effective approach is to use the systems developers are already using, namely defect tracker tools, to demonstrate that they understand the software development process and want to work with development teams. Rather than simply emailing out impersonal reports, security professionals should use the results from security testing activities as an opportunity to sit down with development team leads to discuss the findings and begin the process of using vulnerability data from the report to identify Web application software defects. This collaborative approach to resolving vulnerabilities provides better opportunities for security teams to work hand-in-hand with Web development teams to address flaws in production Web applications, and mutually improve the security of future Web application deployments.
Security teams can also identify security champions within the development ranks to maintain lines of communication. These champions are developers who gain special recognition for his or her commitment to security by taking on additional security duties in the way of training, communication, or evangelism. There are a variety of reasons a developer might want to be recognized as a security champion: some may see it as an opportunity for career differentiation and professional development, while others might have a personal interest in software security. Regardless, this is a great way to scale the software security efforts beyond what the security team can manage alone.
Seeding each development team with a programmer who serves as a go-to security resource facilitates the information flow from security teams to development teams. These security champions help developers implement and improve secure development processes, and can escalate complicated or important issues back to security teams. These ongoing personal relationships help both the security and development team members take a long-term view that is less focused on the results of a particular assessment or the status of a specific vulnerability, and more focused on the ongoing process of securing the organization’s software.
For a CISO to successfully facilitate Web application software security, developers cannot see security as a tax levied on them. Instead of being a roadblock to development team success, security teams instead need to make themselves a valuable resource for developers. Just as effective security professionals act as a risk management resource for managers and executives, they need to act as security enablers for development teams, helping them build secure Web applications with minimum hassle. Secure software does not happen overnight, but by taking a long-term, relationship-based view of the process, the security team can ensure a harmonious, team-focused effort, which ultimately will result in Web applications developed with far fewer security flaws.
About the author:
Dan Cornell has over twelve years of experience architecting, developing and securing web-based software systems. As a Principal of Denim Group, he leads the organization's technology team overseeing methodology development and project execution for Denim Group's customers. He also heads the Denim Group application security research team, investigating the application of secure coding and development techniques to the improvement of web based software development methodologies.