December 2010
Security and the Software Development Lifecycle: Secure at the Source In its research on Securing Your Applications: Three Ways to Play (August 2010), Aberdeen found that companies leverage three distinct strategies to address the security threats and vulnerabilities that are latent in their currently deployed portfolios of application software: find and fix, defend and defer, and secure at the source. Taking all factors into consideration, should the primary means of achieving secure applications be inspection, additional layers of protection, or prevention? The answers to these questions are one part context, one part business judgment, and one part philosophy. This Research Brief represents the third in a three-part series in which Aberdeen analyzes current users of each approach to provide additional insights into the benefits and tradeoffs of these three high-level strategies for securing Internet-facing enterprise applications.
Business Context: Three Ways to Play – Part Three Is application security actually "free"? Aberdeen's benchmark research in Securing Your Applications: Three Ways to Play (August 2010) confirmed that the total annual cost of application security initiatives is far outweighed by the benefits of fewer actual security-related incidents, fewer audit deficiencies, and faster time to remediate. Based on current practices, Aberdeen found that companies leverage three distinct strategies to address the security threats and vulnerabilities that are latent in their currently deployed portfolios of application software: •
Find and fix – i.e., the use of application vulnerability scanning and penetration testing solutions to identify the security vulnerabilities in the applications currently in production, to be addressed subsequently by the application developers.
•
Defend and defer – i.e., enhancing the security of applications currently in production through the use of web application firewalls or application-level proxies, to reduce or defer the need for security vulnerabilities to be addressed by the developers.
•
Secure at the source – i.e., the integration of secure application development tools and practices into the software development lifecycle, to increase the elimination of security vulnerabilities before applications are deployed.
At the heart of the discussion of which approach to application security to take is the question of where in the canonical software development lifecycle (SDLC) – analysis, design, implementation, testing, release, deployment and ongoing support – one feels application security vulnerabilities are most © 2010 Aberdeen Group. www.aberdeen.com
Research Brief Aberdeen’s Research Briefs provide a deeper exploration of the principal findings derived from primary research, including key performance indicators, Best-in-Class insight, and vendor insight. Determining the Best-in-Class To distinguish Best-in-Class companies (top 20%) from Industry Average (middle 50%) and Laggard organizations (bottom 30%) in application security, Aberdeen used the year-over-year changes in the following: √ Number of application security-related vulnerabilities √ Number of audit deficiencies related to application security √ Average time to remediate one critical application vulnerability Over the last 12 months the top performers also experienced fewer actual data loss or data exposure incidents, as well as fewer audit deficiencies, related to application security. Companies with top performance based on these criteria earned Best-inClass status. For full details, see Securing Your Applications: Three Ways to Play (August 2010). Telephone: 617 854 5200 Fax: 617 723 7897
Security and the Software Development Lifecycle: Secure at the Source Page 2
appropriately identified and remediated (Figure 1). Is developer time better spent addressing high-risk vulnerabilities identified by proactive application vulnerability scanning and penetration testing, fine-tuning a web application firewall (WAF), maturing a secure SDLC process – or adding features and accelerating release dates? Does deployment of a WAF buy an organization more time and data to address application security vulnerabilities more effectively, or does it effectively ensure that they will never be addressed? Are secure SDLC models merely academic, or can they truly serve as practical guidelines? Are they within the reach, both financially and technically, of any but the largest companies? The answers to these questions are one part context, one part business judgment, and one part management philosophy – taking all factors into consideration, should the primary means of achieving secure applications be inspection, additional layers of protection, or prevention? Figure 1: Securing Your Applications – Three High-Level Strategies
Source: Aberdeen Group, September 2010
In fact, all respondents in Aberdeen's Securing Your Applications study, from Best-in-Class to Laggards, experienced a positive return on their annual investments in application security. The clear takeaway is that application security initiatives of any kind represent extremely good business value. To provide additional insights into the benefits and tradeoffs of the three high-level strategies which companies have adopted for securing their Internet-facing enterprise applications, Aberdeen has analyzed current users of each approach in a series of three follow-on Research Briefs: •
Application Scanning and Penetration Testing: Find and Fix (Later)
•
Web Application Firewalls: Defend and Defer
•
Security and the Software Development Lifecycle: Secure at the Source
This Research Brief represents the third and last in the three-part series. © 2010 Aberdeen Group. www.aberdeen.com
Telephone: 617 854 5200 Fax: 617 723 7897
Security and the Software Development Lifecycle: Secure at the Source Page 3
Current Practices in Application Security
Fast Facts
Based on Aberdeen's Securing Your Applications study of more than 150 organizations, the average respondent supports over 130 deployed applications, which are in turn supporting an average of approximately 6,800 end-users – part of an overall end-user population (including employees, contractors, business partners, and customers) that is growing at an estimated 6.5% per year. More than 2 out of 5 (43%) of these applications are classified as likely to have a serious adverse affect on the business or its end-users in the event of a loss of its confidentiality, integrity or availability.
The average respondent: √ Supports over 130 deployed applications, the origin of which ranges from internal development to outsourced development, systems integrator development, open source, Web 2.0, and commercial / off the shelf
The average respondent annually invests nearly $400K on application security initiatives, an estimate which includes not only the technologies but also the "people and process" aspects of securing their Internet-touching enterprise applications. On average, respondents estimate that about 4 out of 5 (82%) of application vulnerabilities are discovered and remediated before deployment – which of course means that roughly 1 out of 5 are not. Figure 2 shows the distribution of application security vulnerabilities that are discovered and remediated, by phase of the software development lifecycle. Best-in-Class companies remediate more (88.3%) before deployment than Laggards (76.6%) – and experience two-thirds fewer incidents as a result.
√ Spends nearly $400K per year on application security initiatives (includes all technology, people and process) √ Estimates that about 82% of application vulnerabilities are discovered and remediated pre-deployment
The problem is not necessarily that 20% of application vulnerabilities are not discovered and remediated until after the applications have been deployed. The problem is that the total cost of remediating an actual application security-related incident is so high – about $300K, across all respondents. In other words, successful prevention of a single occurrence nearly offsets the total annual cost of the average organization's application security initiative. A high probability of occurrence, multiplied by a high cost per occurrence, is what gives credence to the argument that application security is "free."
√ Estimates the total cost of remediating an actual application security-related incident at about $300K
Figure 2: Discovering and Remediating Application Security Vulnerabilities (all respondents) Best-in-Class
Cumulative % of Vulnerabilities Discovered and Remediated (last 12 months)
100% Incidents Avoided
Incidents Not Avoided
80% $300K / incident 60%
Laggards
> 130 applications
40% $400K / year total cost of initiative
20% 0%
All Respondents
Analysis
Design
Implementatio n
Testing
Release
Deployment / Support
15.6%
30.8%
44.5%
71.7%
82.2%
100.0%
Source: Aberdeen Group, September 2010
© 2010 Aberdeen Group. www.aberdeen.com
Telephone: 617 854 5200 Fax: 617 723 7897
Security and the Software Development Lifecycle: Secure at the Source Page 4
Market Trends: Web Applications are Most Vulnerable As noted by Aberdeen in Web Security in the Cloud (May 2010), industry sources report that nearly half of all identified vulnerabilities are related to web applications; surprisingly, however, at end of 2009 about two-thirds of known web application vulnerabilities had no vendor-supplied patch available. In one typical eight-week period between May and June 2010, for a more specific example, more than 800 new updates and vulnerabilities were identified – not only for Windows platforms, but also for Mac, Unix, Linux, cross-platform, network devices and web applications (Figure 3). There were more than 3-times more vulnerabilities in third-party Windows applications than in Windows, Microsoft Office and other Microsoft products combined – underscoring the importance of a comprehensive approach to vulnerability management, even for Microsoft-only shops. (For additional insights on this point, see Aberdeen’s December 2010 Research Brief Managing Vulnerabilities and Threats: No, Anti-Virus is Not Enough.) Figure 3: New Updates and Vulnerabilities Identified over 8 weeks Mac, 5 Unix, 16 Windows, 8
Linux, 24
Microsoft Office, 5
twork devices, 23
Cross-platform, 203
Other Microsoft Products, 8
Windows, 86 Web applications, 455
Third-Party Windows Applications, 65
New Updates and Vulnerabilities Identified during 8 weeks in May-June 2010
Source: Qualys, in partnership with SANS
Nearly 60% (455) of the new vulnerabilities identified during this particular period were related to web applications, and of those more than 60% (284) were examples of SQL injections or cross-site scripting – in spite of the excellent collaborative work of the Open Web Application Security Project (OWASP) and the widespread publicity regarding the OWASP Top 10 web application security threats (Table 1), in which injections and cross-site scripting are number one and number two. Clearly it will continue to require more education, time and focused effort to eliminate these and other vulnerabilities from the fastest-growing category of applications. Be watchful also for growth in application vulnerabilities for mobile platforms! © 2010 Aberdeen Group. www.aberdeen.com
Definitions For this Research Brief: √ Web security refers to web-borne malware; blended threats, drive-by downloads, or social engineering exploits involving web URLs; and monitoring / filtering of webbased applications √ Web application security refers to vulnerabilities and exploits related to web applications and their supporting frameworks, application servers, web servers, database servers, and computing platforms √ An application-level proxy / application-level gateway facilitates the exchange between clients and application servers, enabling incoming packets and data to pass through the network firewall using selected ports and protocols. Proxies are typically configured in the client application to be accessed specifically in place of the target application server, whereas gateways typically operate transparently by intercepting and evaluating network traffic. √ A web application firewall (WAF) is specifically designed for web applications, applying a set of rules to web-based traffic and defending against known web application security vulnerabilities and exploits, such as those identified by as defined by the collaborative work of the Open Web Application Security Project (OWASP) Telephone: 617 854 5200 Fax: 617 723 7897
Security and the Software Development Lifecycle: Secure at the Source Page 5
Table 1: Web Application Security Threats – OWASP Top 10 for 2010 Category
Web application security threats
Examples
Commentary
Injections
Injections (e.g., SQL, OS or LDAP injections) occur when an attacker sends hostile data to an interpreter as part of a command or query, tricking it into executing unintended commands or accessing unauthorized data.
Cross-site scripting
Cross-site scripting occurs when an application sends untrusted data to a web browser without proper validation, allowing attackers to execute malicious scripts in the end-user’s browser.
Authentication and session management
Flawed implementations of user authentication and session management can allow attackers to compromise passwords, keys, session tokens, or exploit other implementation flaws to assume end-user identities.
Direct object references
Direct object references occur when attackers are able to manipulate direct references to an internal implementation object (e.g., a file, directory or database key) to access unauthorized data.
Cross-site request forgery
A cross-site request forgery attack occurs when an attacker forces an end-user's browser to generate forged HTTP requests – including the user's session cookie and any other automatically included authentication information – which appear to be legitimate to a vulnerable web application.
Security misconfiguration
Attackers can exploit vulnerabilities from undefined, unimplemented or out-of-date security configurations for web applications, frameworks, application servers, web servers, database servers, and platforms.
Insecure cryptographic storage
Attackers may be able to access or modify poorly protected information such as cardholder data, authentication credentials, or other personally identifiable information to conduct credit card fraud, identity theft, or other criminal activity.
Failure to restrict URL access
Failure to check access rights before rendering protected links and buttons may allow attackers to forge URLs to access these hidden resources.
Insufficient transport layer protection
Flawed implementations of transport layer authentication and encryption can compromise the confidentiality and integrity of sensitive network traffic and expose it to attackers.
Unvalidated redirects and forwards
Improper validation of redirect and forward requests enables attackers to redirect end-users to phishing or malware sites, or use forwards to access unauthorized pages.
Source: Open Web Application Security Project, OWASP Top 10 Application Security Risks – 2010
Market Trends: Adoption of Enabling Technologies For the majority of all respondents, manual source code reviews represent the most common technique or technology for the secure at the source approach to application security, at 54% (Figure 4). Roughly just 2 out of 5 companies are currently using static source code analysis, dynamic source code analysis, secure software development tools, and software security testing tools. © 2010 Aberdeen Group. www.aberdeen.com
Telephone: 617 854 5200 Fax: 617 723 7897
Security and the Software Development Lifecycle: Secure at the Source Page 6
The proportion of current evaluations, however, along with planned use in the next 12 months, indicates very strong market interest and near-term growth in all of these areas. Figure 4: Current Use, Planned Use, Current Evaluations for Selected Enabling Technologies (all respondents) 13%
Source code review (manual)
Source code analysis and verification (static)
54%
20%
Source code analysis and verification (dynamic)
49%
25%
Secure software development tools
38%
23% Evaluating
16%
20%
41%
18%
Software security testing tools
14%
37%
21%
27%
Current
Planned
Source: Aberdeen Group, November 2010
With the exception of manual code reviews, however, the leading performers are moderately to highly differentiated from the lagging performers in their use of technologies associated with the secure at the source approach (Figure 5). For companies adopting the secure at the source approach to identifying and remediating application security vulnerabilities, these solutions are used in combination with a corresponding commitment to secure application development practices – with superior results.
Industry Average
Laggards
32%
48% 35%
31%
20%
37%
30%
38%
43%
52%
54%
55% 46%
40%
58%
Best-in-Class
42%
60% 59%
Percentage of Respondents (N=132)
Figure 5: Current Use of Enabling Technologies, by Maturity Class
0% Source code review (manual)
Source code analysis and verification (static)
Source code analysis and verification (dynamic)
Secure software development tools
Software security testing tools
Source: Aberdeen Group, November 2010
© 2010 Aberdeen Group. www.aberdeen.com
Telephone: 617 854 5200 Fax: 617 723 7897
Security and the Software Development Lifecycle: Secure at the Source Page 7
In Figure 6, the absolute adoption by Best-in-Class organizations is plotted against the relative adoption by the Best-in-Class compared to that of Laggards. By inspection: •
Technologies associated with the defend and defer approach are seen to be baseline;
•
Technologies associated with the find and fix approach are seen to be the strongest differentiators of Best-in-Class performance;
•
Technologies associated with the secure at the source approach are seen to be maturing, beginning the transition from the early adoption phase by Best-in-Class companies towards broader, mainstream use.
Figure 6: Adoption of Application Security Technologies by Bestin-Class Organizations (absolute adoption vs. relative adoption)
Relative Adoption (ratio of adoption by the Bestin-Class compared to that of Laggards)
Find and Fix
Defend and Defer
Secure at the Source Best -in-Class Dif ferent iat ors
Security testing Secure dev't
Ethical hacking Application scanning App-level proxy
Dynamic analysis Source code review
New / Emerging
1.0 0%
Static analysis
WAF
Baseline
50%
For this Research Brief: √ Baseline refers to high adoption by the top performers, as well as relatively high adoption by all others. Baseline technologies are widely viewed as foundational for success, although taken by themselves they do not differentiate Best-in-Class performance. √ Emerging refers to modest adoption by the top performers, and relatively low adoption by all others. √ Early Adoption refers to modest adoption by the top performers, but high adoption by the leaders relative to that of all others.
2.0 Best -in-Class Early Adopt ion
Definitions
√ Differentiators refers to high adoption by the top performers, and high adoption by the leaders relative to that of all others.
Pen testing Netw ork scanning Web m/f IDS/IDP
Netw ork firew all
100%
Absolute Adoption (% of Best-in-Class indicating current use)
Source: Aberdeen Group, November 2010
Security and the Software Development Lifecycle: The Microsoft SDL Model As one of the world’s largest software developers, Microsoft has invested heavily in improving the security and privacy of its software and services, with the objective of reducing application security risk for its customers. Dating back to 2004, the Microsoft Security Development Lifecycle (SDL) model has been a company-wide initiative and mandatory policy governing the company’s software development process. By embedding security and privacy throughout its software development lifecycle, Microsoft has also reduced its total cost of development – and generously provided a © 2010 Aberdeen Group. www.aberdeen.com
Telephone: 617 854 5200 Fax: 617 723 7897
Security and the Software Development Lifecycle: Secure at the Source Page 8
comprehensive and practical framework that other organizations can leverage for their own application security initiatives. Table 2: Secure Application Development Practices, by Phase of Software Development Lifecycle Analysis
Design
Implementation
Testing
Release
Application development teams receive appropriate training to stay informed about security basics and recent trends in security Analysis of security requirements is performed at project inception Minimum security requirements for the application are specified Minimum acceptable levels of security quality are established (e.g., quality gates or bug bars that define the severity thresholds of security vulnerabilities) Security risk assessments identify functional aspects of the application that require deep review
Functional specifications accurately and completely describe the intended use of features or function Functional specifications describe how to deploy the feature or function in a secure fashion Techniques are employed to reduce the attack surface (e.g., shutting off or restricting access to system services, applying the principle of least privilege, employing layered defenses) Application development teams have a structured process to consider, document and discuss the security implications of application designs in the context of their planned operational environment (e.g., threat modeling)
Application development teams have defined and published a list of approved tools and their associated security checks Application development teams use the latest version of approved tools (e.g., to take advantage of new security functionality and protections) All functions and APIs that will be used in conjunction with a software development project are analyzed for security risk Functions and APIs that are determined to be an unacceptable security risk are prohibited Code is checked for the existence of prohibited functions and APIs Prohibited functions and APIs are replaced with safer alternatives Manual code reviews Static code analysis Penetration testing
Dynamic code analysis (i.e., runtime verification to ensure that functionality works as designed) Deliberate introduction of malformed or random data to induce failure (i.e., fuzz testing) Re-review of attack surfaces Re-review of threat models
Defined incident response plan (e.g., identification of the appropriate development, marketing, communications, and management staff to act as points of first contact in the event of a security emergency) Final review of all security-related activities performed on the application prior to approval and release Archival of all pertinent information required for postrelease support
Note: adapted from Microsoft’s “Simplified Implementation of the Microsoft SDL", February 2010 Source: Aberdeen Group, November 2010
© 2010 Aberdeen Group. www.aberdeen.com
Telephone: 617 854 5200 Fax: 617 723 7897
Security and the Software Development Lifecycle: Secure at the Source Page 9
As part of its benchmarking process for Securing Your Applications: Three Ways to Play, Aberdeen adapted a simplified version of the Microsoft SDL as a yardstick for measuring current practices (Table 2). To be clear, few companies may be in a position for full-scale adoption of the Microsoft SDL framework – nor would they necessarily want to do so. In Aberdeen’s view, the pragmatic approach is to leverage the best of the Microsoft SDL as it applies to your organization, just as one would leverage the best of any other time-tested industry standards and best practices. Discard the rest.
Drilldown: An Analysis of Organizations Adopting the Secure at the Source Approach to Application Security Aberdeen's analysis of 42 organizations currently identifying themselves as pursuing the secure at the source strategy for application security provides further insights into the success and tradeoffs of this approach.
Quantifying Business Value: Cost Avoidance, Cost Savings For the purposes of assessing the business value of securing public-facing, networked applications, Aberdeen uses the following simple equation:
The denominator includes the total annual cost for the organization's application security initiative; also in the denominator, however, are the total costs from application security incidents that were not avoided in the last 12 months, in spite of the investments that have been made. In the numerator are the best estimates for the total costs of application securityrelated incidents that were avoided in the last 12 months as a result of the organization's investments – these may be difficult to come by, and imprecise at best. For this reason, the most general way to think about this simple analysis is that any investments in technologies and services that lower the total cost of the initiative (efficiency) and cause a greater shift from the denominator to the numerator in terms of incidents avoided (effectiveness) will have a strongly positive impact on the overall return on annual investment.
© 2010 Aberdeen Group. www.aberdeen.com
Telephone: 617 854 5200 Fax: 617 723 7897
Security and the Software Development Lifecycle: Secure at the Source Page 10
Table 3: Balancing Efficiency and Effectiveness to Maximize Annual Returns Secure at the Source
Industry Average
Application vulnerabilities identified and remediated prior to deployment
83.9%
81.7%
Application security-related incidents experienced in the last 12 months
6.9
6.3
Annual cost of application security initiatives ($K) (includes all related costs for people, process, and technologies)
$620
$330
Return on annual investment from application security initiatives
4.0
3.8
Assessing the Business Value Derived from Application Security
Note: The average total cost of an actual application security incident for participants in this study was estimated at $300,000 Source: Aberdeen Group, November 2010
Aberdeen's analysis of 42 organizations currently using the secure at the source strategy for application security is summarized in Table 3. The good news: companies adopting the secure at the source strategy realized a very strong 4.0-times return on their annual investments in application security, higher than that of the Industry Average and higher than that of both the find and fix and defend and defer approaches. In spite of investing 1.9-times that of the Industry Average annually in their application security initiatives (including all related costs for people, process, and technologies), companies adopting the secure at the source strategy realized a higher return on their annual investment, because more application vulnerabilities were identified and remediated prior to deployment. As previously noted, given that the average total cost of remediating an actual application security-related incident is so high (about $300K, in Aberdeen's study), successful prevention still outweighs the undeniable benefits of proactive detection and defense. The counterbalance: the secure at the source approach is the least common to be currently implemented, but as previously noted it is seen to be maturing and transitioning from early adoption to mainstream use. Figure 7: Secure Application Development Practices, by Phase of Software Development Lifecycle
Percentage of Respondents (N=132)
100% 85% 80% 71% 71% 71%
60%
Industry Average 76%
71%
68% 68% 68%
66% 65% 67% 68%
60% 61%
75%
53%
53%
40%
34%
Analysis
Design
27% 20%
42% 33%
42%
38%
28%
56%
49% 51%
34%
26%
Implementation
64%
63%
58%
44%
40%
70%
69% 63% 55%
38%
53%
46%
20%
Secure at the Source
77%
46% 37%
30%
27%
Testing
35%
22% Release
0%
Source: Aberdeen Group, November 2010
© 2010 Aberdeen Group. www.aberdeen.com
Telephone: 617 854 5200 Fax: 617 723 7897
Security and the Software Development Lifecycle: Secure at the Source Page 11
In Figure 7, the current capabilities and practices that were listed in the simplified version of the Microsoft SDL (see Table 2) are plotted for the 42 organizations currently using the secure at the source strategy for application security, with the Industry Average from Aberdeen's Securing Your Applications: Three Ways to Play benchmark study also plotted as a reference. For example, in the Design phase of the software development lifecycle, 77% of the secure at the source users indicated that functional specifications accurately and completely describe the intended use of features or function for their applications, compared to just 53% of the Industry Average. The high-level takeaway is that the secure at the source users are more consistent and more mature in their adoption of these secure application development practices. Readers who are actively evaluating their secure application development practices may wish to use Table 2 and Figure 7 to make a careful comparison of the biggest differences, as well as their own current capabilities, for each of the analysis, design, implementation, testing and release phases. Aberdeen has also implemented a complimentary interactive assessment tool based on this data that may help you go more quickly in this regard.
Case in Point: International Financial Services Provider An international provider of financial services and investment resources identifies a commitment to continuous improvement, state-of-the-art technology, and customer service as the keys to evolving and adapting to meet the changing needs of its customers. The company annually reinvests a substantial portion of its revenues into technologies and practices to deliver new products and services to its clients. One of those investment areas has been in security and the software development lifecycle. "Software has become an integral part of everything we do," noted the organization's CISO. "Quite often, software is essential to our customer's perception of the 'quality' of a new financial product or service." The CISO views the Microsoft SDL as a useful framework and set of principles by which they and other companies can establish their own secure software development initiatives. The company has quantified the significant benefits of fixing vulnerabilities earlier in the software development lifecycle; as always, the tradeoff is time-to-market and the opportunity cost of applications being available as quickly as possible. Helping to tip the scales, however, is the fact that "tolerance for downtime has gotten smaller and smaller. We just can't tolerate the risk of outage. We absolutely have to have confidence that the code we deploy can meet our requirements."
"Success starts with the developers … not in punishing them or trying to change their incentives, but in enhancing their skill sets. It's about deputizing them to care about security in the code they build." ~ CISO, international financial services provider
Solutions Landscape (illustrative) Solution providers associated with the secure at the source approach to application security range from service organizations to specialists to © 2010 Aberdeen Group. www.aberdeen.com
Telephone: 617 854 5200 Fax: 617 723 7897
Security and the Software Development Lifecycle: Secure at the Source Page 12
integrated application security suites from multi-billion dollar corporations; Table 4 provides an illustrative list. Table 4: Solutions Landscape for Security and the Software Development Lifecycle (illustrative) Company Armorize Aspect Security Coverity Electric Cloud HP
IBM Rational Klocwork QMetry
Web Site www.armorize.com www.aspectsecurity.com www.coverity.com www.electric-cloud.com
Solution(s) CodeSecure, SmartWAF, HackAlert Implementation, Verification and Management services Static Analysis, Dynamic Analysis, Build Analysis, Architecture Analysis ElectricCommander, ElectricAccelerator, ElectricInsight
www.fortify.com www.hp.com
Fortify 360, Fortify On Demand DevInspect, QAInspect, Assessment Management Platform
www-01.ibm.com/software/rational/
AppScan Source, AppScan Build, AppScan Tester
www.klocwork.com
Insight
www.qmetry.com
QMetry Enterprise
Replay Solutions
www.replaysolutions.com
Replay DIRECTOR
TOMOS
www.reachsimplicity.com
TOMOS Application Lifecycle Management
Veracode
www.veracode.com
Veracode SecurityReview Source: Aberdeen Group, November 2010
Summary and Recommendations Aberdeen's analysis of companies adopting the secure at the source strategy – i.e., the integration of secure application development tools and practices into the software development lifecycle, to increase the elimination of security vulnerabilities before applications are deployed – found that they realized a very strong 4.0-times return on their annual investments in application security, higher than that of the Industry Average and higher than that of both the find and fix and defend and defer approaches. Although the secure at the source approach is currently the least common to be implemented, Aberdeen's research confirms that it is maturing and transitioning from early adoption to mainstream use. Whether a company is trying to move its performance in securing its applications from Laggard to Industry Average, or Industry Average to Bestin-Class, the following general steps to success will help to drive the necessary improvements. •
Identify your application portfolio. The average respondent currently supports a portfolio of over 130 deployed applications, which is growing year over year. So is the overall end-user population (including employees, contractors, business partners and customers) for these applications, combining to increase significantly
© 2010 Aberdeen Group. www.aberdeen.com
Telephone: 617 854 5200 Fax: 617 723 7897
Security and the Software Development Lifecycle: Secure at the Source Page 13
the number of potential attack vectors for Internet-facing enterprise applications. •
Identify the greatest risks. The classes of applications, or the specific applications, which represent the greatest risk should be give the highest priority. Respondents ranked legacy applications with web-based front-ends, .NET-based and Java-based web applications, and Web 2.0 applications as the highest in their current assessment of application security risk. Aberdeen looks for mobile applications to jump to the top of this list in the near future.
•
Establish clear ownership. Having an executive or team with clear ownership and accountability for an important enterprise-wide initiative such as application security is consistently correlated with the achievement of top results.
•
Be deliberate in your strategy. For each application or class of applications, determine where in the software development lifecycle your organization feels that application security vulnerabilities are optimally identified and remediated – the average respondent estimates that about 82% of application vulnerabilities are discovered and remediated prior to deployment. This will lead to one of three high-level strategies, as outlined in this Research Brief: find and fix, defend and defer, and secure at the source.
•
Prioritize remediation. Few organizations can invest the resources to fix all vulnerabilities with equal priority, so an efficient system of triage is essential. The greatest risks, as a function of potential impact and likelihood of occurrence, should be remediated first.
•
Train the developers. Unfortunately, education and training in application security policies and best practices is an area where there is virtually no distinction between the three maturity classes, which represents an immediate opportunity for improvement. Don't just keep telling the developers that they're doing something wrong; make them aware of how to do it right.
•
Communicate. Regardless of which of the three high-level strategies are being employed, well-defined communication channels between IT Security, operations and software development teams will improve both the efficiency and the effectiveness of identifying and remediating application security vulnerabilities.
•
Measure and monitor. Management must not only establish application security as a priority, but also allocate the tools and resources necessary to pursue it successfully. By providing the management team with visibility into actual application security incidents and the time and cost to remediate them, business leaders will have the information and insights they need to ensure that resource allocation is consistent with stated strategy.
© 2010 Aberdeen Group. www.aberdeen.com
Telephone: 617 854 5200 Fax: 617 723 7897
Security and the Software Development Lifecycle: Secure at the Source Page 14
Aberdeen's benchmark study on Securing Your Applications: Three Ways to Play (August 2010) found that all respondents – from Best-in-Class to Laggards – experienced a positive return on their annual investments in application security. The clear takeaway is that application security initiatives of any kind represent extremely good business value. For more information on this or other research topics, please visit www.aberdeen.com.
Related Research HP Acquires Fortify Software, Strengthens Managing Vulnerabilities and Threats: No, Anti-Virus is Not Enough; December Application Security Assurance; August 2010 2010 Web Security in the Cloud; May 2010 Web Application Firewalls: Defend and Defer; October 2010 IT Security: Balancing Enterprise Risk and Reward; January 2010 Application Scanning and Penetration Testing: Find and Fix (Later); September The 2009 PCI DSS and Protecting Cardholder Data Report; November 2010 2009 Securing Your Applications; interactive assessment tool (complimentary) Application Security; June 2008 Aberdeen Group / IT Security Channel; Securing Your Applications: Three Ways to Play; August 2010 complimentary webcasts Author: Derek E. Brink, Vice President and Research Fellow, IT Security (
[email protected]) Since 1988, Aberdeen's research has been helping corporations worldwide become Best-in-Class. Having benchmarked the performance of more than 644,000 companies, Aberdeen is uniquely positioned to provide organizations with the facts that matter — the facts that enable companies to get ahead and drive results. That's why our research is relied on by more than 2.2 million readers in over 40 countries, 90% of the Fortune 1,000, and 93% of the Technology 500. As a Harte-Hanks Company, Aberdeen plays a key role of putting content in context for the global direct and targeted marketing company. Aberdeen's analytical and independent view of the "customer optimization" process of HarteHanks (Information – Opportunity – Insight – Engagement – Interaction) extends the client value and accentuates the strategic role Harte-Hanks brings to the market. For additional information, visit Aberdeen http://www.aberdeen.com or call (617) 723-7890, or to learn more about Harte-Hanks, call (800) 456-9748 or go to http://www.harte-hanks.com This document is the result of primary research performed by Aberdeen Group. Aberdeen Group's methodologies provide for objective fact-based research and represent the best analysis available at the time of publication. Unless otherwise noted, the entire contents of this publication are copyrighted by Aberdeen Group, Inc. and may not be reproduced, distributed, archived, or transmitted in any form or by any means without prior written consent by Aberdeen Group, Inc. (010110)
© 2010 Aberdeen Group. www.aberdeen.com
Telephone: 617 854 5200 Fax: 617 723 7897
![Security Development Lifecycle for Agile Development - Black Hat [PDF]](https://m.moam.info/img/260x300/security-development-lifecycle-for-agile-developme_647d6dbb098a9e71558b461f.jpg)
