APPLICATION SECURITY FOR OPEN SOURCE SOFTWARE - THE NEW IMPERATIVE

APPLICATION SECURITY FOR OPEN SOURCE SOFTWARE - THE NEW IMPERATIVE Donald J. Fergus Intekras, Inc. 21515 Ridgetop Circle Suite 260 Sterling, VA 20166 (703) 547-3500 www.intekras.com April 2010

Information Assurance Technical Services Workforce Development WHITE PAPER Table of Contents Application Security for OSS...1 The Benefits and Pitfalls of OSS...2 Why Application Security for OSS is a Critical Component...4 Mitigating the Risks of OSS Vulnerabilities...7 Conclusion...9 About Intekras...10 About Palamida...10

1 Application Security for Open Source Software - the New Imperative Today, developers increasingly use open source software (OSS) components to provide critical functionality inside their applications and also to meet tight deadlines with smaller budgets and often with reduced staffs. Such applications, particularly those that are web-based and externally-facing, represent a significant opportunity to reduce cost and increase productivity. However, the use of OSS is not without risk. According to the most recent Ponemon Institute s fifth annual U.S. Cost of a Data Breach Study, the cost of a data breach is $204 per compromised record, with the average total cost of a data breach amounting to $6.75 million. So, even for a small organization with 5,000 records, that s over one million dollars. And the fines and legal actions associated with data breaches can put businesses in jeopardy. Additionally, compromised sites and databases can frighten users and lead them to seek out alternative providers. And yet most organizations are not focusing on securing their applications. The main reason continues to be lack of understanding and knowledge, and a false sense of security. Many IT professionals still believe that having a network firewall, IDS, SSL certificates, and so on will protect them from hackers attacking their web sites or databases. It s like having locks on your front door but leaving your windows and side doors wide open and hoping that burglars will only try to come through the front door. The 2009 Data Breaches Investigation Report from Verizon found that attacks targeting applications, software and services are by far the most common. In the data breaches they investigated in 2008, attacks against the application layer represented an alarming 79% of cases. This supports research compiled by the National Institute of Standards (NIST) which found that up to 92% of all security vulnerabilities are now considered application vulnerabilities and not network vulnerabilities. Currently, federal government organizations are not particularly focused on application layer security. The major reason behind this is that federal organizations are driven primarily by compliance-related pressures. While FISMA presents a comprehensive approach to managing risk associated with information security, the actual security controls defined within the NIST FISMA guidelines stress traditional network and platform security far more than application security. A recent survey of federal Chief Information Security Officers (CISO s) conducted by Cisco and (ISC)2 found that 48% of CISO s view external attacks as the biggest threat, with insider threats and software vulnerabilities following at 26% each. So, where does application security stand in terms of risk mitigation priorities? The banking industry view is a common one: in a recent study performed by BankInfo Security of 100 banking/security leaders, 57% of respondents said they are somewhat or very confident in their own applications, and 90% said application security is somewhat or a significant part of their overall information security programs. However, when it comes to applications developed or managed by third-party service providers, 81% are only somewhat or not at all confident in the security, and this faith erodes even further with large institutions ($2 billion or more in assets under management), where 91% are only somewhat or not at all confident. Worse, only 55% of respondents test their application security controls annually, with the rest testing on no set schedule (28%), before a regulatory exam (10%) or don t know or not at all (7%). And only 51% of respondents have an effective, recurring process to monitor, identify and remediate these issues. Just as in the commercial sector, application developers in the federal government have embraced the use of open source software (OSS). In his October 16, 2009 memorandum, Clarifying Guidance

2 Regarding Open Source Software, acting DoD CIO David M. Wennergren provided guidance that effectively opened the floodgates for using OSS across the Department of Defense. However, he cautioned that the use of any software without appropriate maintenance and support presents an information assurance risk and it is important to understand both the specifics of the open source license in question and how the Department intends to use and redistribute any DoD-modified OSS. Unfortunately, few other specifics were provided. Following this announcement, a Ponemon Institute and Computer Associates survey of 217 seniorlevel federal IT executives noted that a significant area of information security risks includes the growth of OSS usage across the government, with 57% of those polled believing that the use of open source applications increases security risk within their organizations. And yet, organizations are only beginning to understand the abundance of open source software components now being used inside internally-developed enterprise applications. The rate of open source adoption is now so rapid that it has outstripped the ability for most organizations to adequately manage its use. In today s world of 24/7 and persistent network access, developers across the globe can include open source, freeware, public domain, and evalware (demos of commercial software) into the code they write without triggering any alarms because of a lack of effective management. Without these controls, the open source is unlikely to be detected, monitored, and tracked. As a result, IT organizations are unaware of exactly what comprises their code base. In recent studies, Palamida, an open source scanning provider, found that applications written within the last five years contain 50% or more open source code, by a line of code count. Of that 50% or more open source code content, 70% was undocumented. It is imperative that organizations manage the newly-emergent and informal software supply chain through which open source regularly enters their code base. They should also implement a straightforward authorization and monitoring system for open source usage; one that minimizes version proliferation, ensures compliance to license terms, ensures usage of the most recent releases, and guarantees awareness of any associated vulnerabilities. Not doing so leaves organizations open to data breaches, legal issues, and other serious risks. The Benefits and Pitfalls of Open Source Software Open source software development is one of the greatest drivers of IT innovation today. Almost every home, business or government agency uses open source software applications - from the server to the desktop. The Linux operating system, Apache server, MySQL, OpenSSL, and zlib are examples of widely-used open source software that is either employed in a standalone fashion or is integrated in a custom application. Open source harnesses the power of peer review and process transparency and, as such, offers the potential of better quality, higher reliability, more flexibility, and lower cost. However, the use of open source software is not without risks, and many organizations considering its use need to take appropriate mitigation steps. Firstly, organizations need to consider open source license obligations and restrictions that apply to those custom-built applications leveraging open source software. Such intellectual property (IP) risks can be mitigated through a structured protocol that identifies, assesses, and manages open source license and copyright issues related to the IP that is incorporated inside the enterprise s mission-critical applications and software products. By not properly managing these IP issues and not

3 complying with the terms of the open source licenses, the organization will be exposed to copyright infringement lawsuits. Secondly, open source software like any other software is subject to security weaknesses. This security risk is increased if an inventory of open source is not properly maintained and if the open source is not included in an organization s patch management processes. While some say that the open source community fails to adhere to security best practices, others suggest that, since a large development community contributes to and scrutinizes open source code, security holes are less likely to occur than in proprietary software, and can be caught and fixed more quickly. In either case, open source software undergoes patches, upgrades, and other modifications as the software evolves in the community. Keeping track of open source usage and maintaining the latest versions are critical components of an application software security protocol. Today s software developers don t need to reinvent the wheel. Often, innovation results from combining successful software projects with new components in creative ways. Leveraging open source code reduces costs, accelerates development cycles and enables innovation. However, in fast-paced development environments, assessing the risks associated with using third-party intellectual property can be easily overlooked. Most organizations believe they have adequate application security solutions in place because of their significant investments in firewalls, web-based authentication, intrusion detection, and identity management systems. While important security layers, these solutions are securing the perimeter by managing traffic to the applications. None focus on analyzing the software code itself for the identification of third-party code that could have security defects or vulnerabilities that put the applications at risk. Additionally, there are legal considerations around the use of others intellectual property that must be assessed. Software security vulnerabilities are often caused by defects in specification, design, and/or implementation. It is becoming very clear that decisions made during the software development lifecycle will significantly impact the likelihood of security incidents and the success in responding to them. The issue is that, unlike commercially-supported third-party products, only one out of every ten open source projects has a vendor offering commercial support for it. As a result, development organizations that use open source components are largely on their own when it comes to patches, upgrades, vulnerability assessment and similar tasks that are part of a normal commercial service contract.

4 An application security strategy for open source requires processes, training and tools. It also requires a partnership between security and engineering teams. The nature of the partnership is based on two key requirements: * An accurate inventory of open source components in use. This may be more challenging than it appears, since most large applications have had many different developers over a period of years, each with the potential to utilize open source components. And, as stated earlier, most of these components are undocumented. * A system to associate the open source projects in use with known and published vulnerabilities and intellectual property licenses. The good news is that, with new awareness coupled with robust tools for open source management, both elements can be addressed successfully. Why Application Security for Open Source Software is a Critical Component While application security is a vital component to mitigating risk, application security for open source is particularly crucial. The key issues to consider include: Open Source Software is Largely Unsupported Open source represents more than Linux and other commonly-used packaged open source enterprise applications for which support may be available (e.g. SugerCRM, Pentaho, Open Office). It is the tens of thousands of unsupported open source components that are far from household names that are cause for security concern. These open source components are at the heart of most applications today. They relieve developers from having to reinvent the wheel. Why develop software for object relational mapping when you can use Hibernate? Why create compression software from scratch when you can utilize zlib? Open Source is Here to Stay Even without commercial support, the benefits of OSS are readily apparent open source reduces the cost of development, shortens development cycles, and can lower the overall total cost of ownership of your applications if managed well. Developers, long at the forefront of open source use, have seen a growing awareness and an acceptance among their organizations that make the adoption of open source components less of a black art and more of a common practice. Open Source is Often Neglected after Adoption Often times, the philosophy of spend small, think small prevails for IT organizations. Unless an organization is rolling out a large open source project such as Linux, special resources are not being allocated to the management of open source adoption. The result, as previously stated, is the use of significant amounts of undocumented code that may put the organization at risk because one cannot manage what one is not aware of. Organizations need to be certain of the software composition for their business-critical applications. What third-party code is embedded inside of them? Where did they get that code? Who wrote it? What are the legal obligations surrounding its use? What vulnerabilities exist in the code? Who on their team is responsible for monitoring it? Enterprise Applications are More Vulnerable than Ever As so much of open source code goes undocumented, its existence within enterprise applications

5 threatens the security of these assets. In the past, if developers wanted to incorporate third-party code into their applications, a joint development agreement or in-bound licensing contract would be negotiated. Involved in the process would have been developers, development management, a procurement person, and a lawyer. In order to remain competitive today, complex and lengthy processes have disappeared in many development organizations. As a result, these organizations are unable to answer the following important questions which ensure the safety and security of their most important assets - their software applications: - What s in my code? - Where is the OSS located? - Are there vulnerabilities associated with the identified OSS? And as engineering departments adopt richer, interactive environments - especially as they embrace Web 2.0 capabilities - they become even more susceptible to vulnerabilities (e.g. SQL injections, cross-site scripting attacks, etc.). Initially introduced by developers via the inclusion of open source, vulnerabilities are easily exploited by knowledgeable outsiders. With Web 2.0 as the new software ecosystem, relying on perimeter controls alone is grossly insufficient. Externally-facing, missioncritical software applications, must have security features baked in from the start. Organizations must now manage the newly-emergent and informal software supply chain through which open source regularly enters the development environment. It is also in their best interest to ensure that they have a transparent authorization and monitoring system that enables them to minimize version proliferation, guarantee that they are using the most secure releases, and are aware of any vulnerabilities within their applications. Otherwise, an organization can be left open to data breaches, legal issues, and financial business exposure. Where does Application Security Fit within Your Information Assurance Program? In its Consensus Audit Guidelines of 20 crucial controls (CAG 20), SANS and the Center for Strategic and International Studies assembled a powerful consortium including NSA, US CERT, DoD JTF- GNO, the Department of Energy Nuclear Laboratories, Department of State, and the DoD Cyber Crime Center to establish a prioritized baseline of information security measures and controls that can be applied across federal enterprise environments. Of the twenty specific technical security controls that were identified as effective in blocking currentlyknown high-priority attacks, as well as those attack types expected in the near future, Critical Control 7 - Application Software Security was included. In its guidance, CAG 20 noted that application software that does not properly check the size of user input, fails to sanitize user input by filtering out unneeded but potentially malicious character sequences, or does not initialize and clear variables properly could be vulnerable to remote compromise. Attackers can inject specific exploits, including buffer overflows, SQL injection attacks, and cross-site scripting code to gain control over vulnerable machines. In one attack in 2008, more than one million web servers were exploited and twenty-five were turned into infection engines for visitors to those sites using SQL injection. During that attack, trusted websites from state governments and other organizations compromised by attackers were used to infect hundreds of thousands of browsers that accessed those websites.

6 To avoid such attacks, CAG 20 requires that both internally-developed and third-party application software must be carefully tested to find security flaws. For third-party application software, enterprises should verify that vendors have conducted detailed security testing of their products. For applications developed in-house, enterprises must conduct such testing themselves or engage an outside firm to conduct such testing. There are two environments in which application security can be assessed: during code development, and after the project is complete and ready for deployment. Further, there are two levels of detail at which application security can be assessed: at the level of source code, and at a higher level of code modules or components. Using the Certification & Accreditation process as required in FISMA, as an example, consider the following diagram: As the System Development Lifecycle progresses, analysis occurs at the source code level during development, with static analyzers being the most widely used tool for application security. Moving to the time of deployment/implementation, code-level analysis at the point of deployment is generally considered the domain of web application security scanners. Additionally, these are tools designed to scan files to identify known malicious code that has been inserted after the development process is complete. However, there is an area of contribution that is complementary to the existing categories that of analysis at the component level during the development process. Rather than overlapping existing tool categories, analysis at this level is complementary, and brings a new set of capabilities and efficiencies to a comprehensive strategy for application security. This area is enabled by a new generation of tools specifically targeting the identification of software content, and once content is identified at the component level, it becomes possible to deliver vulnerability information about the discovered components.

7 Often, open source is included in development projects as software components. Sometimes these components are modified, and sometimes portions of them are copied into proprietary code to add functionality. None of these is a bad practice as long as the license obligations are understood and any known security risks have been evaluated and, if necessary, remediated. Therefore, analysis of source code to find third party components and their versions is particularly useful and provides critical information relative to the business risk that they pose. Once a component and its version have been identified, any license obligations and known security flaws (e.g., data breach, denial of service, etc.) can be determined. Often, a project s license can vary between versions and security vulnerabilities are very much version-specific. Ensuring the Security of Your Enterprise Applications It is the responsibility of security, development and IT teams to ensure that their developers use processes that produce secure software. Working together, these three departments can effectively insert application security for open source into the overall security strategy by: Conducting code-level security reviews in addition to penetration tests for their internallydeveloped code before deployment Insisting that code-level audits be conducted by outsourced development and business partners Ensuring that all other third-party code included in their software applications is identified and tracked for security flaws and updated version information Ensuring that applications developed internally have adequate checkpoints that enable thorough audit trails This means that development organizations must continue to acquire the high level of security expertise required, identify processes for producing secure software, adopt them, and consistently use them when they produce, enhance, maintain, and rework the software that supports a strong application infrastructure. Mitigating the Risks of Open Source Vulnerabilities Two good examples of open source projects that embody the prevalence and potential impact of open source software vulnerabilities are zlib and LibTiff. The zlib library has been a fundamental open source software component for almost fifteen years and can be found in almost every Linux and Unix system. Security flaws in earlier versions of zlib have impact beyond the scope of open source projects alone. According to the zlib project page, there are at least 756 applications from both open source and commercial vendors that use zlib. Major vendors of these applications include Adobe, Microsoft, Cisco, CA and VMWare. Should one of these applications include an unstable version of zlib, they are at risk of being exploited. The impact of open source software vulnerabilities can be felt as far upstream as popular consumer gadgets. In November 2007, Apple posted a security update (Version 1.1.) for the iphone and the ipod Touch that patched a well-known vulnerability in Libtiff. The vulnerability leads to a security flaw that can be triggered by viewing a malicious TIFF image. The attack leads to multiple stack-based buffer overflows, which can cause denial of service and the possible execution of arbitrary code, including the Jailbreakme 1.1.1 vulnerability that allows hackers root access to the iphone and the ability to read its email and install and run applications.

8 The breadth and scope of open source vulnerabilities seem consistent with their commercial counterparts. New industry regulations, along with increased market awareness, are increasing the pressure within companies to ensure that their application security policies extend to their use of open source. How to Get to Zero Undocumented Code Application security cannot be adequately addressed until application development and security teams agree to work together in understanding and managing security. Neither role benefits from a siloed existence. For instance, quality assurance and virus prevention are not mutually exclusive in application development. Development teams commonly (and mistakenly) believe that security is solely the responsibility of security professionals. For many companies, the development process has primarily focused on designing, architecting, coding and testing applications to ensure that they fulfill functional requirements. Particularly with today s strained budgets and resources, applications are often not adequately tested for coding defects, vulnerability assessment or conditions that could leave the applications exposed to external attacks. Simultaneously, the mandate for security teams has been focused on defending the perimeter against external attacks. They have made significant investment in firewalls, web-based authentication, intrusion detection, and identity management systems. Security professionals are not coders and often do not realize that decisions made during the development process may have significant material impact on the deployed applications they are mandated to protect. Therefore, neither team can adequately cover application security problems alone. Hackers, who often know coding methodologies better than security professionals and know security better than programmers, are exploiting this gap. Every Chief Information Security Officer should ask their engineering managers the following 10 key questions to ensure that both teams are working together to secure deployed applications: Top 10 Questions to Ask Your VP of Engineering 1. Where is our OSS inventory, including all versions in use? 2. How accurate is the information? What are we basing the accuracy on? 3. Where does the OSS we use reside inside our code base? 4. How are we using the OSS? What is its specific role? 5. Are there vulnerabilities within the versions we re using? 6. Are we on the latest version if not, why? 7. Have we paid for commercial support for all the OSS projects in our code base? 8. If not, who is responsible for monitoring and upgrading to newer versions? 9. How does OSS factor into our SDLC? 10. Are we compliant with and enforcing our own policies? Immediate Action Items for Your Security Team 1. Begin monitoring open source project sites and other sources for vulnerability alerts, based on existing OSS inventory. 2. Assess the relevance of alerts against internal usage. 3. Make recommendations for version or patch upgrades, as appropriate.

9 Conclusion The widespread availability and use of open source has dramatically changed the nature of software development projects with substantial benefits including reduced development time and cost. However, this strategy brings with it the possibility that a large portion of a software product or internal application could be undocumented and insecure. Hackers and others with malicious intent are greatly increasing their efforts to target thousands of applications around the globe. In parallel, the cost of going to trial for IP lawsuits increases, independent of the settlement. The potential cost in terms of lost revenue, customer trust and brand integrity of even one significant security breach can be devastating. Accordingly, security and IP policies and regulatory mandates regarding the use of third-party code are placing growing pressure on IT organizations to bolster the security of the applications they create, procure, manage and deploy. With the increasing requirement for protecting information assets, the security of core applications is essential. An application security strategy requires processes, training and a spectrum of solutions. It also requires a partnership between security and engineering teams that has, until recently, been neglected. With new awareness and the use of software systems to management open source usage, the gap that has existed can be easily secured.

10 About Intekras, Inc. Intekras s Information Security Services group offers a broad suite of IT Risk Management, Information Assurance, and Cyber Security solutions designed to protect our clients most critical information assets and reduce the probability or impact of an undesirable or unexpected event. Our goal is to assist in protecting and defending information and information systems from risks that threaten confidentiality, integrity, authentication, and availability. These risks are relevant whether the information is in storage, processing, or transit, whether threatened by malice or accident, or if technical, organizational or management in nature. Customers include DHS/FEMA, DISA, HUD, VDOT, US Navy, US Marine Corps, Peace Corps, Health & Human Services, and OPM. Our unique approach - from identifying and ranking network and application vulnerabilities and threats to recommending where and how to mitigate the most serious business, operational, and technical risk exposures assures that our clients address and mitigate the most significant risks in a cost-effective manner. For more information visit www.intekras.com. About Palamida, Inc Palamida provides the industry s first application security solution exclusively for open source software. The Palamida Enterprise Edition uses component-level analysis to quickly identify and track undisclosed code and associated security vulnerabilities, as well as intellectual property and compliance issues. Using Palamida, organizations can cost-effectively manage and secure missioncritical web and other software applications. The Palamida Enterprise Edition integrates with existing engineering, security, and legal processes to enable organizations to collaborate more easily to protect applications from evolving threats. Customers include US Army, Cisco Systems, Microsoft, Sterling Commerce, Amdocs, Diebold, and Software AG, among others. For more information visit www.palamida.com. 2010 Intekras, Inc. and Palamida, Inc. All rights reserved. Intekras and the Intekras logo are trademarks of Intekras, Inc. Palamida is a trademark of Palamida, Inc. All other trademarks and registered trademarks are the property of their respective holders.

11 Conveniently located in the Loudoun Technology Center in Sterling, Virginia, Intekras is a privately owned small business, offering integrated solutions in Information Assurance & IT Risk Management, Technical Services and Workforce Development. Our executive team has over 125 years of combined experience in our core disciplines. Intekras has an outstanding track record in the public sector including DHS, DoD, Navy, Army, HUD, Peace Corps, HHS, OPM and VDOT as well as strong past performance with such companies as Northrop Grumman, Lockheed Martin, SRA International, Raytheon and others. Our private sector experience includes such Global 100 & Fortune 500 companies as Citibank, AOL/Time Warner, Bridgestone and others. Intekras: bringing insight, innovation and integrity to your business and technology challenges.