Real world application security in five easy steps Business white paper Table of contents Introduction..................................................................................2 Executive summary..........................................................................2 Step One: Build the business case to get funding........................................2 Step Two: Prioritize the important applications to assess first.........................3 Step Three: Find and build the resources to implement your program...............5 Step Four: Now that scanning is complete, what s next? (Fixing vulnerabilities)....6 Step Five: Building security into the software development lifecycle..................7 Conclusion....................................................................................8 For more information.......................................................................8
Introduction If your organization is not taking a proactive, systematic approach to securing your Web applications, then you are leaving your infrastructure and sensitive data vulnerable to the most common, rapidly growing vector of IT attacks today. Web-based attacks often result in significant costs due to lost revenue, theft of sensitive customer information, and non-compliance with government and industry mandates. Unfortunately, more than three-quarters of all system attacks today are aimed directly at insecure Web applications. Recent headlines show the danger associated with Web application security flaws. Last year, a federal grand jury indicted a number of hackers for allegedly breaching systems that belonged to many well-known retailers and large credit card payment processors. According to the U.S. Department of Justice, more than 130 million credit and debit cards were stolen. And, according to court documents, while the perpetrators visited store locations to monitor certain point-of-sale systems, it was security-related application attacks, notably SQL injection, that made it relatively easy to plant malware on the victims systems and then commit widespread, ongoing theft. Fortunately, SQL injection flaws, like most Web application security flaws from buffer overflows to cross site-scripting errors are avoidable. Now, if the programming mistakes that create these vulnerabilities are preventable, why are Web application attacks on the rise? The answer is simple: Many companies have yet to put into place the people, processes, and technology necessary to build their Web applications in a secure and sustainable way. Because so many types of attacks target Web applications, if consistent precautions are not taken, then it is not a matter of if an organization will be breached on the Web but when and to what extent. Unfortunately, when the breach does occur, more often than not, the security managers and security teams find themselves in the hot seat trying to answer the how and the why this could have happened. While the security professional must answer to management following a breach, it is management that s ultimately answerable to customers, shareholders, and business partners. Executive summary By taking a few simple steps, organizations can considerably increase the security of their Web applications while cutting costs and improving regulatory compliance. This white paper explains how. It provides the guidance necessary to help your organization get started with a sustainable Web application security program from building the business case to instilling the proper processes for success. Step One: Build the business case to get funding To avoid Web-related breaches, organizations need the resources to make certain that Web applications are designed, built, and maintained with security in mind to mitigate business risks. And, to get the funding for developer training and the technology necessary to build an effective Web application security program, a strong business case must be presented to management. Not surprisingly, questions about how to go about making a winning argument for a Web application security program are among the most common questions existing customers and prospects ask of HP Application Security Center consultants. Fortunately, a strong case for Web application security can be made. Before delving into the details about how to build that business justification, let s cover one of the most common mistakes security managers make when they present the case for security funding to business managers. Their presentations tend to focus too heavily on the technical risks and benefits associated with Web application security. That is a big mistake: Most non-it managers do not necessarily understand or relate to the technical details of security. They are not always familiar with buffer overflows. They have probably never heard of cross-site scripting or SQL injection. And, frankly, in most cases, they do not want, or have the need, to know. What they do need to understand, more than ever, is that Web application security vulnerabilities create substantial risk to data breaches, cause regulatory non-compliance, and jeopardize customer loyalty. Understanding this is crucial to build the business case necessary to obtain the funds you need to put a Web application security program in place. 2
Here s how: Demonstrate the frequency and the cost of security breaches First, make it clear that data security breaches are on the rise and that they are costly and how the data shows that security breaches are getting more expensive all the time. In fact, the cost of suffering a breach is probably much steeper than most business executives assume. The Ponemon Institute recently released its annual study, The Cost of a Data Breach 1, and found that the average cost per breached record reached $204 in 2009, up from $182 in 2006. Because most breaches involve thousands, if not tens of thousands of records, it is easy for a single security incident to set an organization back hundreds of thousands, if not millions of dollars. According to Ponemon, the total cost per breach, per organization, ranged from $613,000 to $32 million. Illustrate the security requirements of regulatory compliance Secondly, regulatory compliance calls for adequate data security. There has been much discussion in recent years about Sarbanes-Oxley, the Health Insurance Portability and Accountability Act (HIPAA), the Payment Card Industry Data Security Standard (PCI DSS), and the myriad of statewide financial data breach disclosure laws. These mandates have had a significant impact on enterprise IT security initiatives. Failure to comply with such regulations can lead to significant penalties levied against both the corporation and personally against its directors fines and even criminal prison sentences. This makes it vital that organizations are fully attentive to the information they hold about employees, customers, and suppliers. They need to know how this information is being used, stored, and shared, as well as the regulatory burdens. For instance, PCI DSS mandates that all Web applications be built based on secure coding guidelines, such as those provided by the Open Web Application Security Project (OWASP). This includes reviews to find vulnerabilities such as non-validated inputs, cross-site scripting, poor session management, and others. The costs associated with regulatory fines are high, as are the costs of data breach notifications. Customers, partners, and suppliers expect secure operations Third, security is no longer a nice-to-have, or a should-have aspect of doing business. Security simply is part of doing business today, and it is a primary concern of customers, business partners, and suppliers. When it comes to business-to-business relationships, it s increasingly common for partners and suppliers to want to review security policies. In some cases, they even ask to conduct their own security reviews of applications and infrastructure especially when connecting networks. That is why, to build your business argument for Web application security, you also may want to visit an often overlooked department: marketing. Talk to product managers and the business owners of Web applications, and ask them for examples of partners, customers, and prospects who have asked about the organization s security program. Collect anecdotal evidence regarding customers and partners asking to review security policies and security reviews. Finally, it s time to bring your argument close to home. The best way to achieve this is to take all of the business drivers for Web application security discussed above regulatory compliance, customer demand, and cost of breaches and map those realities to the current state of your Web application security. That is accomplished best by assessing an application, or set of applications, and then explaining the results to management. The next step highlights how to get started. Step Two: Prioritize the important applications to assess first With Web application security assessment software in hand (if your organization does not have a Web application assessment tool, there are plenty of demonstration versions readily available), it s now time to find a few business-critical Web applications and servers and conduct the assessment. In addition to building your business case, there are many reasons why your organization may need to conduct a Web application assessment. It could be to check the security status of a new Web application, before deployment, or as part of a regulatory review, or simply to run an overall checkup on the security posture of the Web applications throughout the organization. Whatever the case, if the assessment will involve more than a handful of applications over time, you will need to prioritize what applications to assess first. 1 2009 Annual Study: Cost of a Data Breach, Ponemon Institute, January 2010 3
Figure 1: Example of Application Security Priority Matrix Application Confidentiality Integrity Availability Total Registration High High High 27 E-Store Med High High 24 Blog Low Low Low 9 Catalog Low Med High 18 In order to create your business case, and for the sake of all-around security, start with the highest priority applications. However highest priority is subjective and often depends on the type and size of the organization. For a retailer, for example, the highest priority (for security purposes) could be applications and servers that help to support credit card transactions. A health care provider might be most concerned with all applications that touch patient health data, to meet HIPAA mandates. In these cases, the scope of the assessment would be for PCI DSS compliance or for HIPAA review. For an organization that is not regulated, determining the assessment scope could be as simple as scanning the most used applications, or applications that handle the most sensitive data. Depending on the size of your organization, it could be that even trying to limit focus to the high priority applications will not adequately limit your scope. So, it may be necessary to prioritize applications even within that scope. Below is a chart inspired largely by the National Institute of Standards and Technology method for prioritizing applications for review. It is based on the traditional CIA (confidentiality, integrity, and availability) model. The idea is to rank applications based on the importance of confidentiality (HIPAA, employee records), integrity (financial data, such as used in financial reporting and inventories), and availability (e-commerce shopping cart, trading desk). A common strategy is to take the applications that ranked highest first, assess them, and then work down. But it s not always this straightforward. Higher priority applications may need a more thorough analysis than an automated security code review. The application may require penetration testing from a skilled ethical hacker who has little to no knowledge of what the application does (known as a black-box test). Or, the assessment is conducted where the evaluator has limited knowledge of the application to which the attacker would have limited access, and is sometimes even given credentials to the applications (known as grey-box testing). The important thing to remember in this step is to bring systematic methodology to your Web application security assessments, and prioritize all the applications in the organization so that none are left out, and the most important are evaluated first. By using the same assessment toolset to measure the risk, you can start tracking real vulnerability statistics across your enterprise. Having a consistent way to measure this risk is crucial to creating a benchmark so that a security policy can be created. If you find yourself in the situation of a stillunderfunded Web application security program, gather all the data you can about the security of your Web applications both commercially bought and those developed in-house. As you find sensitive data, put it in your reports and make it clear that outside attackers also could get hold of these data. Nothing drills the importance of Web application security home to executives more powerfully than seeing confidential corporate information in the reports. This exercise should go a long way in helping you get the additional budget you need. 4
Figure 2: Cost to fix security defects 100X 1X 6.5X 15 X Design Development Testing Deployment Step Three: Find and build the resources to implement your program Application security is a team effort. Companies that have successful programs in place have high-level executive sponsorship and it is not just the security teams that are involved. Application developers, QA, compliance, and audit teams all should be part of it. With high-level executive sponsorship, you are more likely to be able to get the people and resources you need for success. How do you get that sponsorship? Explain to executives why Web application security is in their best interest. Like many people, executives are keen to look out for their own as well as their companies interests. If you can convince them that their image and the health of the business would be damaged if your applications were infiltrated, then you can hold their attention. That means your best bet is to explain how security issues can damage the executive s position and the company. Take the overall business case, previously discussed, and explain to a number of executives the very real-world risks to them, as well as to the organization, that could result from inadequate Web application security. These executives will most likely care about how Web application security (or lack thereof) can affect downtime, as well as lost business and the costs to recover from a breach. Be certain to use recent breaches and regulatory fines as examples. As you make your case, highlight all the good things the security program has achieved already: Blocking efforts to lock down the network, keeping out malware, and rapidly putting operating system patches in place because upwards of 75 percent of attacks now are targeting Web applications. Stress how Web application security will increase availability for sales, and protect privacy, confidential customer and corporate data, and intellectual property. Then, explain how security defects should be treated and fixed in the same way as functional defects. That helps ensure that security problems are caught early in the development cycle, when they cost less much less to fix (see Figure 2). Saving money, reducing risk, and making it easier to achieve regulatory compliance should help you win the executive sponsorship necessary to get the budget you need to make your program succeed. Another powerful resource for your program is the developer community within your organization. Rather than assessing applications and demanding that developers fix the flaws that are uncovered an approach that only will build animosity over time it is better to co-opt the development and quality assurance groups. Have them sent to security conferences where application security is discussed. Provide members of the development teams with Web application security training. There are lots of conferences and training opportunities, from SANS (SysAdmin, Audit, Network, Security) Institute to OWASP and others. Once developers understand how security actually undermines the functionality of their applications, they can be partners in ensuring success in driving security adoption throughout the application development lifecycle. 5
Figure 3: Ingredients for application security success Application security is everyone's responsibility 4 Groups/Teams of people: People Business Development QA Security Action Educate and Empower Process Build security in Repeatable and predictable Best practices Enterprise policies and standards Technology Enterprise security platform Automated solutions Built in security knowledge Communication Another ally you want is the quality assurance (QA) team. Get the QA team armed with tools that help it test for security defects as part of regular QA testing. By bringing developers and QA into the fold, you are helping to bridge the gap that typically exists in organizations between the security development and QA teams. Training these groups, and giving them the tools they need to find security defects, will go a long way to closing that gap. Developers and QA will no longer feel that security issues simply can be tossed to the security group and be forgotten. They will come to realize that they are actually responsible for a good part of the organization s security. Step Four: Now that scanning is complete, what s next? (Fixing vulnerabilities) This section assumes you already have conducted a scan on one or more of your critical applications. There are many resources available that provide guidance on running a Web application assessment. Consider reading Web application security guides, such as the OWASP Testing Project Guide for more information. Once the scan is complete, the next stage is to categorize and prioritize the vulnerabilities uncovered. In this process, you first list your most critical vulnerabilities with the highest potential of negative impact on the systems that are most important to your organization. Then, list other vulnerabilities in descending order based on risk and business impact. Once you have categorized and prioritized vulnerabilities, the next step is to estimate the effort and the resources needed to implement the fix. The idea is to fix the highest-risk vulnerabilities first, and structure your remediation efforts to capitalize on time: such as beginning to fix flaws that could take the longest to repair (so they don t hold up production) and duplicate vulnerabilities so that efforts are scaled. The time or difficulty estimates can be as simple as easy, medium, and hard. Remediation work will begin not only with the problems that pose the greatest risk, but also those that will take the longest time to correct. For instance, get started first on fixing complex vulnerabilities that could take considerable time to fix, and wait to work on the half-dozen medium defects that can be rectified in an afternoon. By following this process, you would not fall into the trap of having to extend development time or delay an application rollout because it has taken longer than expected to fix all of the security-related flaws. This process also enables ample opportunity for collaboration and ongoing contact with application auditors and developers. You now have an attainable roadmap to track. When developers have mended the vulnerabilities, it is time to verify the security posture of the application with a reassessment, or regression testing. For this, it is crucial that the developers are not the only ones charged with assessing their own code. They already should have completed their own verification. It is vital that an independent entity, whether an in-house team or an outsourced consultant, review the code to ensure everything has been done right. Also, another set of eyes will provide a fresh perspective on the security of your applications. 6
Step Five: Building security into the software development lifecycle It is clear that organizations can mitigate an enormous amount of risk by strengthening Web application security through secure design and development. A safe application development reduces the cost of fixing security vulnerabilities and maintenance (by catching them early). It also reduces the costs associated with data breaches. The secret to success is not in the one-time assessment, but in building security into the software development lifecycle. A secure Software/Systems Development Lifecycle (SDLC) means having the policies and procedures in place that consider and enforce secure development from application conception through defining functional and technical requirements, coding, quality testing, and the life of the application in production. With a new application design, SDLC means bringing the security group at least someone who is familiar with Web application security into the discussion at the onset. This way, the application can be modeled properly. And when IT security has input throughout the process, security issues are much less likely to surface later in the lifecycle and that helps ensure that small problems do not become big security events. For secure SDLC to succeed, developers must code securely. They need to be trained to incorporate security best practices and checklists in their work. For databases, they must check query filtering. For application fields, they must validate proper input handling. Putting these types of procedures in place can improve security dramatically during the development process. Having developers check field inputs and look for common programming mistakes as the application is being written also will make future application assessments flow much more smoothly. Despite developer training and secure coding practices being followed, no application is developed perfectly. That s why the next major phase of the SDLC is crucial that is when the entire application, or a module, is sent for formal QA testing. While most organizations test for functional requirements and availability at this stage, organizations employing the secure SDLC will add security testing that will be conducted by quality assurance and security assessors. Some people tend to skip processes when deadlines and pressures loom. That is an area in which technology can play a significant role. The right tools will help to automate many of the tasks developers, security teams, and QA must do to conform to secure development practices. The right tools also will make certain that the application development and management framework is in place to maintain a portfolio of secure Web applications. How the right tools help reinforce and maintain secure development: While many application security vendors offer solutions to some pieces of the secure development lifecycle, such as application security assessments, only HP Application Security Center brings all of the pieces together. It helps your developers, QA teams, and security professionals to assess application security risks quickly by detecting and correcting security vulnerabilities. HP Application Security Center security testing applications provide common security policy definitions, automated security tests, centralized permissions control, and Web-based access to security information. These applications and services include: HP WebInspect: HP WebInspect performs Web application security testing and assessment for today s complex Web applications, built on emerging Web 2.0 technologies. HP WebInspect delivers fast scanning capabilities, broad security assessment coverage, and accurate Web application security scanning results. HP WebInspect identifies security vulnerabilities that are undetectable by traditional scanners. With innovative assessment technology, such as simultaneous crawl and audit (SCA) and concurrent application scanning, you get fast and accurate automated Web application security testing and Web services security testing. HP QAInspect: HP QAInspect enables you to manage and conduct functional testing and Web site security testing from a single platform without the need for specialized security knowledge. HP QAInspect also features deep and intuitive integrations, helping you test Web applications for security without leaving the QA environment. It finds and then prioritizes Web application security vulnerabilities and presents detailed information and remediation advice for each vulnerability. With this software, you can incorporate fully automated Web site security testing into the overall test management process without affecting aggressive product release schedules. 7
HP Assessment Management Platform (AMP): A standard for advanced, global security programs, HP AMP is a distributed, scalable Web application security testing platform that helps you address the complexities of today s Web application security testing and scanning programs. It lets all constituents get information about application security vulnerabilities and participate in the assessment and remediation process without losing centralized control. With HP AMP, organizations can perform unlimited automated Web application security testing and assessments, while consolidating information into a real-time, high-level dashboard view of the enterprise s current risk posture and regulatory compliance. This consolidates and summarizes the organization s application security status so that you easily can assess and remedy security vulnerabilities in your applications. Application Security Center on HP SaaS: As organizations continue to grapple with smaller IT security staffs, leaner budgets, and new regulatory compliance mandates, the demand for reliable, cost-effective security Web application audits and assessments increases. An efficient Software-as-a-Service (SaaS) assessment platform helps to address all of these challenges. HP SaaS brings the experience, technology, and processes necessary to help you start and maintain an enterprise-class application security program. Conclusion HP Application Security Center offers application security technologies and services that enable your organization to stay protected from costly security breaches, remain compliant with government and industry regulations, and even reduce the long-term costs associated with application maintenance. It is crucial that application security is addressed throughout the entire lifecycle. HP and the HP Application Security Center have the expertise and tools Assessment Management Platform, WebInspect, QAInspect to get you there. For more information For more information on the HP Application Security Center, contact your local HP representative or visit www.hp.com/go/securitysoftware This is an HP Indigo print. Get connected www.hp.com/go/getconnected Get the insider view on tech trends, alerts and HP solutions for better business outcomes Technology for better business outcomes To learn more, visit www.hp.com/go/securitysoftware Copyright 2010 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein. 4AA0-1273ENW, February 2010