W H I T E PA P E R
Ten Questions You’d Better Ask to be Sure Your Company’s Assets are Secure
Ten QuesTions You’d BeTTer Ask To Be sure Your CompAnY’s AsseTs Are seCure
WWW.ForTiFY.Com 1
W H I T E PA P E R
Ten Questions You’d Better Ask to be sure Your Company’s Assets are secure
Abstract Today’s business infrastructures rely upon software applications to manage corporate assets, automate critical business processes, and store private information. What’s more, these applications operate beyond a company’s network perimeter to include customers, suppliers, and partners. And most applications today contain security vulnerabilities that can be exploited for profit or malicious use. That’s why most hackers today target the software, not the network infrastructure, in their attacks. What can you do to be certain your company’s software — and assets — are secure? Start by asking TEN essential questions.
Ten QuesTions You’d BeTTer Ask To Be sure Your CompAnY’s AsseTs Are seCure
WWW.ForTiFY.Com 2
W H I T E PA P E R
Your software is one of the single, largest exposures to risk your business faces today. It’s critical for you to have a clear idea of the impact that risk poses to your business.
1. What is my business risk exposure to software?
Most likely, your software is one of the single, largest exposures to risk your business faces today. It’s critical for you to have a clear idea of the impact that risk poses to your business. Customer goodwill, business operations, and even your brand and your standing with government regulatory bodies can change overnight with a single, major security breach. The magnitude of that risk can be determined by a careful analysis. What inherent business risk does the software in question pose? What are the possible scenarios if an adversary controlled that software system? Could your business operations be shut down? What would be the consequences of that loss of productive uptime? What critical data do your systems hold and what are the business consequences of losing that data? Could an exploit of your systems land your company on the front page of the national press? Could access to information managed by your software harm your business or that of your customers and business partners? Is fraud possible, given the role of software in your business operations, and what would be the impact if those systems were compromised? These questions must be asked for every critical application deployed by your company. Once your analysis is complete, you need to analyze the same set of circumstances for the systems in the business partners’ data centers that your company depends on to be sure your security needs are met. Conversely, you must determine if a breach in your systems could cause an important business partner or client to lose information or operational capacity.
2. How can hackers and malicious insiders use software to attack my business?
Exploiting security bugs left in the software code is unfortunately all too easy for hackers. A simple, otherwise innocuous vulnerability left in a business application could allow an adversary to: • Perform a Process Control or Buffer Overflow and use the program to launch another program, perhaps a malicious Trojan, on the host system • Perform a SQL Injection and leverage the program to access, view, and modify private data • Cause an Application Denial of Service and crash the program in order to cause damage or downtime to the business processes it supports
Ten QuesTions You’d BeTTer Ask To Be sure Your CompAnY’s AsseTs Are seCure
WWW.ForTiFY.Com 3
W H I T E PA P E R
The problem corporations face today is that the long list of common software vulnerabilities is well known to hackers and all too often a mystery for software developers.
• Exploit Information Leakage to mine the program for authentication credentials embedded within it to access systems, databases, and other services • Perform Cross Site Scripting in order to impersonate a legitimate user with that user’s privileges to view or change records and execute transactions These are just a few of a long list of well-known software attacks against common vulnerabilities found in almost every piece of software written. Fortify Software’s Security Research Group publishes a list of known software vulnerability categories (currently at 118 and growing) in conjunction with the Open Web Application Project (OWASP). The numbers of hackers who know how to exploit all 118 categories of vulnerabilities are relatively few. However, the problem for defenders is that they must “cover” all of these vulnerabilities.
3. How secure is my code?
Unfortunately, the odds are high that the software on which your company depends contains egregious security holes. The problem corporations face today is that the long list of common software vulnerabilities is well known to hackers and all too often a mystery for software developers. Compounding matters is the mistaken notion that it is only bugs, or quality problems, that a hacker can manipulate to cause harm. In fact, the level of security of an application is completely independent of the “quality” of the software — a program can perform perfectly from a functional perspective, yet still can have serious security vulnerabilities. The actual level of security of your software can be determined only by looking at the applications on which your business depends and performing the proper analysis to verify if it is built appropriately, given the risk and threat environments in which it will perform. This can be a major undertaking. However, automating this source code analysis makes it significantly faster and cheaper and the results more dependable.
4. What assurances have I been given that my software is secure?
We have found, in informal polling of developers and development managers, that their most common response to the question, ”Is your code secure?” is an unqualified — and unsubstantiated — “Yes!” The bottom line is that the company that operates an application is ultimately harmed by the security holes in it, rather than the developer who writes the code or the vendor who sells it. Given the complexity of software licensing and the protection it enjoys from our Federal
Ten QuesTions You’d BeTTer Ask To Be sure Your CompAnY’s AsseTs Are seCure
WWW.ForTiFY.Com 4
W H I T E PA P E R
The most fundamental (and typically the easiest) way to ensure that no gaping vulnerabilities exist in your key systems is to perform a software security assurance test before the application gets released to production.
Government in terms of liability restrictions, rarely can a company seek recourse, even in the most flagrant violation of security committed by a third party. It is therefore incumbent upon the party both buying and operating software, to ensure that their code is secure. A good approach is to adopt the principal used by nuclear arms negotiators in the 1960s — trust as long as you can verify. Unless your development group, whether internal or an outside firm, has put in place a process of verifying the level of security that you seek, the assurances you’ve received are likely meaningless.
5. What steps can I take to validate those assurances?
The most fundamental (and typically the easiest) way to ensure that no gaping vulnerabilities exist in your key systems is to perform a software security assurance test before the application gets released to production. Many organizations begin by requiring a single “security gate” as the software leaves development and heads to production operation. At this transition point, the security gate can be a function of the operations team, which will typically have security expertise and charter. Or it can be a function of the development organization, newly empowering some testing group to perform this critical operation. Without a “passing grade, software is not ” released to production. This “final check” for security is simple to understand and raises the visibility of security issues before release. The advantage of this approach is that it blocks insecure code from shipping. The disadvantage is that it will probably block quite a lot of code from shipping. If nothing has been done to correct vulnerabilities before final testing, most code will fail. In fact, without clear guidelines for developers to correct vulnerabilities, software will continue to be tested, fail, be fixed, retested, and fail, and be fixed again through an iterative process that will extend schedules well beyond their deadline. Though a security gate is only one step toward truly securing the software applications that manage your corporate assets, automate critical business processes, and store private information — it is a good starting point.
Ten QuesTions You’d BeTTer Ask To Be sure Your CompAnY’s AsseTs Are seCure
WWW.ForTiFY.Com 5
W H I T E PA P E R
6. Do we need to validate assurances for commercial and open source software or that of our partners and vendors?
But a single security bug is all it may take to steal private information contained in your system — and hackers will vigorously hunt for it.
In today’s complex, highly integrated data center, software security is only as good as the least secure piece of code. To secure your company’s assets, you must also consider the code developed by vendors, integrators, or code reused from open source software. Most of the commercial software products shipped today have hundreds, if not thousands, of quality bugs. Yet, users are generally content with those products, as those bugs are often in “corner cases” that many users will never encounter. The product is far from perfect, but is perfectly adequate for the needs of most users. It is likely that some of your software suppliers still mistakenly believe they can ship code with numerous security bugs, just as they do with quality bugs. But a single security bug is all it may take to steal private information contained in your system — and hackers will vigorously hunt for it. In our experience, relatively few commercial software companies (and open source projects) really understand the issue of security to the full extent. This is due in great part to the fact that their customers and constituents are unaware of the issues and are not yet demanding secure software. Exercise the power you have with software vendors. Some corporations have moved to embedding software security requirements in their contracts with outsourcers. Most vendors, once they become aware of the problem, will move to action. The issue of security in open source software is very straightforward. When you accept open source code, you inherit any deficiencies it contains, such as quality or security (unless the code is supported by a vendor, in which case you can demand that they provide secure software). It is incumbent upon your company to fix security flaws that affect your risk profile. Like software vendors, the open-source community is also subject to influence from its user base.
Ten QuesTions You’d BeTTer Ask To Be sure Your CompAnY’s AsseTs Are seCure
WWW.ForTiFY.Com 6
W H I T E PA P E R
The most effective control over software security risk is to implement a Secure Development Life Cycle (SDLC) and to demand that any partners or vendors making software you depend upon do the same.
7. Does getting control over software security risk require organizational changes?
We have yet to see a successful secure development initiative that did not have a strong, centralized, and autonomous organization responsible for software security. Be forewarned, however. Motivations within development organizations will not align with security objectives when you begin. For many developers and architects, security concerns will conflict with their desires to push the envelope with new technologies. For development managers, security concerns will seem insignificant compared to the pressures of delivering on features and deadlines. Companies that have made the most significant strides in reducing software security risk have all established a software security team that has the responsibility and authority to assign accountability for measurable improvements on the development organization.
8. What is the most effective and efficient option to get this risk under control?
The most effective control over software security risk is to implement a Secure Development Life Cycle (SDLC) and to demand that all partners or vendors making software you depend upon do the same. The term, Secure Development Life Cycle, covers a broad set of generally accepted best practices for building software. These best practices result in a deliverable that has a verifiable assurance of security for the threats that the software is likely to encounter in production. Industry leaders, like Oracle and Microsoft, are making great strides by following SDLC best practices. There are many references available that describe the best practices that make up the Secure Development Life Cycle. Microsoft is very forthcoming in their own internal practices, publishing many articles and books on the processes they use internally to achieve their own security objectives. Another good source of information on the best way to implement a Secure Development Life Cycle in your organization is the software security “how-to” book, Software Security: Building Security In, by the noted security expert, Dr. Gary McGraw. Regardless of the specific approach, successful SDLC practices include: • Training development staff on software security concepts and code-level vulnerabilities • The addition of threat modeling and architectural risk assessment during the software planning stages • Review of source code for security vulnerabilities during development using automated source code analysis technology
Ten QuesTions You’d BeTTer Ask To Be sure Your CompAnY’s AsseTs Are seCure
WWW.ForTiFY.Com 7
W H I T E PA P E R
In our experience, relatively few commercial software companies (and open source projects) really understand the issue of security to the full extent.
• Testing of software against known attacks during the QA stage • Detailed monitoring of the software and the application-level user behaviors in order to gain insight into attacks and collect forensic information
9. What are the three things I can do now?
First, assign and empower an individual to be in charge of your software security initiative — do not let it languish in the no man’s land that separates your information security and development teams today. Second, perform an enterprise-wide baseline audit of your software assets to determine the overall state of your software. Make sure the audit includes a risk analysis and threat assessment for each application and a detailed report of vulnerability findings for high-risk applications. Third, implement an SDLC to ensure that applications are built with security as an explicit requirement. Make sure your vendors/partners do the same. If implementing all SDLC best practices immediately seems daunting, then start with the two identified as the most essential by Dr. Gary McGraw and other experts: architectural risk analysis and a source code analysis.
10. Where can I go to learn more or get help?
Go where the world’s largest financial services firms and software companies looked for help getting their software security risk under control: Fortify.
About Fortify
Fortify Software’s Business Software Assurance solutions protect companies and organizations from today’s greatest security risk: the software that runs their businesses. Fortify reduces the threat of catastrophic financial loss and damage to reputation as well as ensuring timely compliance with government and industry mandates. Fortify’s customers include government agencies and Global 2000 leaders in financial services, healthcare, e-commerce, telecommunications, publishing, insurance, systems integration and information technology. For more information please visit us at www.fortify.com.
©2008 Fortify Software, Inc. All rights reserved. Fortify is a registered trademark of Fortify Software, Inc.
ForTIFY SoFTWAre InC.
More InForMATIon IS AvAILABLe AT WWW.ForTIFY.CoM 2215 BrIDgepoInTe pkWY. SuITe 400 SAn MATeo, CALIFornIA 94404 TeL: (650) 358-5600 FAx: (650) 358-4600 eMAIL: ConTACT@ForTIFY.CoM