Tài liệu Red hat -Why Open Source Software pptx

Why Open Source Software Can Help Create a More Secure IT InfrastructureEvaluating the state of IT security and associated market statistics, it is apparent that traditional operating en

Expert Reference Series

Written and Provided by

Why Open Source Software Can Help Create a More Secure IT Infrastructure

Evaluating the state of IT security and associated market statistics, it is apparent that traditional operating environments have not consistently provided acceptable levels of security to enterprise computing Security-related exposures, liabilities, and losses are rapidly increasing, while conventional computing (hardware, system software, and network bandwidth) costs are all decreasing strongly year over year Most of the operating

environment vendors do not embrace a holistic approach to security - it is clearly an afterthought There are major systemic flaws in their approach to security - and users are suffering the consequences every day

" I'm not proud We really haven't done everything we could to protect our customers-Our products just aren't engineered for security"

Brian Valentine, senior vice president, Windows Development, Microsoft 1

1Berger, Matt "Lead Windows Developer Bugged by Security" InfoWorld September 5, 2002.

Table of Contents

Introduction 3

The Proprietary Software Position 4

The Open Source Position 6

Performance Analysis: Separating the Wheat from the Chaff 9

But Does Open Source Really Work in the Real World? 11

Summary 13

The open source security position challenges the failing status quo Increasing security issues underline the fact that the proprietary "hide-the-code" approach is not working

Red Hat asserts that open source operating systems are inherently more secure than proprietary alternatives

The objective of this white paper is to present the requirement for ubiquitous, affordable security It forwards the open source security position and presents empirical evidence, comparative methodology analysis, and references user experiences to support this position

The whitepaper reviews the contrasts between proprietary and open source software

in the following areas:

Universal Commodity Security

Hidden/Open Code

Vendor/User Alignment

Vendor Responsibility

Security Management

Performance Analysis

Real-world User Experience

In 1843, Oliver Wendell Holmes

startled U.S physicians by

publishing a paper asserting that a

disease killing as many as one in five

mothers, and in some hospitals

every new mother over a period of

months was not only contagious, but

borne to its victims by the very

doctors who sought to cure it.

According to the Harvard Gazette,

"Holmes' denunciation of the medical

profession as a carrier of a plague

rather than a deliverer from disease

marked a milestone in both Holmes'

medical career and in the prevention

of the illness." Could it be that

computer and information security is

being compromised in a similar

fashion by the very software

companies who are promising to

make their systems "trustworthy"

Could it be that the software industry

is today as wrong about effective

security procedures as doctors were

about causes of infections in the

mid-19 th century?

The Proprietary Software Position

Universal Commodity Security: No Organization is an Island

In today's pervasive Internet-connected computing environment, security must be ubiquitously available and affordable to provide true universal assurance Proprietary operating system practices for establishing secure and resilient enterprise systems are built

on multi-level, multi-product approaches This approach is cost prohibitive - and the cost trajectory of security technologies ensures the widening of the gap between the "haves" and "have nots"

Considering the pragmatic position, beyond availability, security must be an organizational priority in development and operations/management Any organization's failure to remain current compromises not only its own security, but that of its collaboration and trading network The total cost of ownership for proprietary security management is significant due

to the requirement for constant attention This too is a significant obstacle to ubiquitous, commodity security

In addition to cost obstacles to universal commodity security, organizations often reject proprietary security investments based on the fact that they are ineffective and inflexible

As a consequence of expense and functional shortcomings, organizations are inclined to under invest In summary, proprietary approaches limit the path to universal commodity security

II Hidden / Open Code: The "Dark" Security Science

The number-one issue with the security of proprietary operating system software is that users are denied access to the source code Proprietary vendors apply the logic that hidden is secure The sensational IT security newspaper headlines of the last five years have underlined the fact that this "dark science" is not effective

An organization would never move into a facility without an understanding of the placement

of the doors and windows If an organization rented a physical facility and was not informed of a hidden building vulnerability of which the facility provider was aware, and its business was compromised by that vulnerability, this would clearly provide grounds for a lawsuit This practice of hiding known vulnerabilities is the norm for proprietary providers of operating systems that fulfill mission-critical software infrastructure functions The reality is that it is impossible for organizations to proactively assess vulnerabilities and develop appropriate responses with proprietary operating systems

Considering highly sensitive security environments, in cryptography circles the maxim is that the security of an algorithm should not depend on its secrecy For example, the Clipper chip, RIAA digital watermarks, and ebooks all used cryptography developed in

secrecy, through code that was never audited In each circumstance, the code was successfully cracked Closed, or proprietary software can be reverse engineered and protocols can be (and have repeatedly been2) cracked through analysis Secrecy or obscurity is not an effective security approach

III The Vendor/User Alignment: The Conflict - What is "Need to Know"?

There is a fundamental user/vendor conflict that exists in the proprietary operating system security "need-to-know" position Proprietary vendors frequently hide behind the "user interest and exposing customers to great vulnerability" argument to withhold information on vulnerabilities that are known to the operating system developer Customers that rely on sole source providers are subject to the vendor's priorities, timelines, and business plans/objectives

IV Vendor Responsibility

It is apparent that a huge number of organizations run their businesses on proprietary operating systems The developers of these systems have often failed to assume responsibility in assuring the security of their products In addition to pushing out flawed products without adequate code review to understand the vulnerabilities that they are handing on to customers, these vendors frequently fail to publicize system vulnerabilities -either at the time of discovery or thereafter As a result patch penetration is low - systems with known vulnerabilities go unpatched for months, even years For example, the CERT®

CC reports that 60,000 hosts are still compromised by Code Red and are actively scanning

14 months after patches were first made available

V Security Management: When the Cure is Worse than the Disease

The proprietary vendor approach to significant infrastructure vulnerabilities is the new upgrade Organizations are asked to install and pay for "fork lift" updates that frequently drive broader changes in their operating environments As such, organizations are sometimes reluctant to update their systems as the impact may prove disruptive on the broader scale

2Clipper chip, Four forms of digital watermarking, etc.

The Open Source Position

The fundamental nature of open source development provides a higher degree of responsiveness and faster resolution to security vulnerabilities than proprietary operating system vendors can provide The combination of open code accessibility and the leverage associated with the large number of developers using and testing the software provide critical differentiators Collaboration, peer review, and rapid feedback are enabled in global real time through the open source development model Considered together, these factors accelerate resolution times for critical security vulnerabilities

I Universal Commodity Security

The open source community asserts that for operating system security to become truly ubiquitous, it must also be highly accessible through commodity hardware and software

As the TCP/IP protocol, World Wide Web, Apache web server, and Linux operating system have shown, when good technology has a low acquisition cost, it displaces inferior

solutions that cost more When the acquisition costs are low and all interfaces and implementations are published, such technologies can become standards Standards, in turn, drive both direct and indirect adoption (the network effect) The growth of the Internet, World Wide Web, Apache, and Linux provide dramatic testimony to the power of the network effect and the popularity of the open source distribution model

The big-picture goal is universal commodity security - enhancing security across all nodes and users, thereby creating a less hostile security context for each machine or user Open source security is uniquely positioned to lead and sustain a new network effect that the industry so much needs today

II Hidden/Open Code: Open Disclosure and Superior Development Methodology

Open source software, by definition, includes any program or application in which the programming code is open and visible Open source users recognize significant security benefits that flow from the accessibility of the source code The open source development model is underpinned by the assurance that source code for an open source project will be made generally available

Open source projects are typically developed on the basis of meritocracy and have a central person or body that approves developed code for "official" releases, making them widely available to the larger open source development community This basic

development methodology is markedly distinct from proprietary software development

Code access provides the ability to analyze and review the source code In the case of Linux over 125,000 users and developers from around the world have participated in the process When users team with vendors to become part of the solution, then "black hat" crackers are at a disadvantage Code access dramatically improves the software development process, which is not possibly achievable by proprietary software vendors

The code accessibility that defines and reinforces the open source development model supports the creation of standards, a more responsive development process, and faster vulnerability disclosures

III Vendor / User Alignment: Eliminating the Vendor/User Conflict

Open source pressures developers and vendors to fully disclose vulnerabilities and accurately reveal their impact, allowing customers to analyze the vulnerability and look at the effect that it would have on their systems and the consequences of applying a fix

Open source software is generally provided and supported by a number of competing vendors Fixing security issues occurs without the impact of business and financial drivers This forces vendors to accelerate the timetable for fixes and promotes the elimination of vulnerabilities even in the absence of known threats

IV Vendor Responsibility

The fact that there are so many vulnerabilities posted in many different places makes staying current on security a complex and time consuming undertaking The open source community asserts that operating system security is the inherent responsibility of vendors The industry needs to take a proactive stance in assisting users As Red Hat provides a single source for a number of open source programs, it takes a responsible position by providing a single source for security notifications and updates

Software vendors need to be accountable for software assurance, innovative in their approaches to software design to enable and respond to security, and support industry standards for reporting and addressing vulnerabilities Ultimately, security must be able to pay for itself, not only in averting worst-case scenarios, but also in dealing with the many issues of real-world day-to-day operations.3

3In 1982, Philip Crosby published the book "Quality Is Free" His perspective and industry examples showed that in fact quality could pay for itself when it

was an enabler of the process, not merely a hoped-for by-product.

V Security Management: Overcoming Complexity and Overhead - Assuring Relevance

Open source minimizes security management complexities and overhead through preciseness of software changes and back porting of fixes Back porting ensures that security updates contain only the security fixes and not any additional features or bug fixes that could affect system stability

Open source vendors provide mechanisms to quickly and easily apply security patches to users' environments through automated alert and update services like Red Hat Network, Ximian Red Carpet and Caldera Volution Red Hat Network tracks user software

installations for over 600,000 subscribers As Red Hat tracks security vulnerabilities, it applies a relevance filter, and alerts users only of issues relevant to their environment Red Hat Network empowers organizations to automatically update their IT systems - even without user interaction if preferred

Performance Analysis: Separating the Wheat from the Chaff

No operating system is immune to security vulnerabilities According to BUGTRAQ Vulnerability Database Statistics (www.kbeta.com/securitytips/vulnerabilities/), both open source and proprietary operating systems have varying numbers of reported vulnerabilities year to year The increasing complexity of software development, coupled with the growing deployment of system software within consumer as well as business and public sector markets, has resulted in greater volumes of vulnerabilities reported each year

Numbers of vulnerabilities in a given operating system can correlate to many factors, including:

Number of installed images

Code accessibility

Number of features or embedded applications within an OS

As such, it is more useful to evaluate vendor responsiveness to security vulnerabilities, rather than comparing net numbers of vulnerabilities for a given operating system

Security Portal Study: Bug/Security Fix Response Times

Security Portal conducted an independent analysis in 2000 to determine comparative open source vs proprietary operating system bug/security fix response times The results:

Red Hat had the best score, with 348 recess days on 31 advisories, for an average of 11.23 days from bug to patch

Microsoft had 982 recess days on 61 advisories, averaging 16.10 days from bug to patch

Sun proved itself to be very slow, although having only 8 advisories; it accumulated 716 recess days, a whopping three months to fix each bug on average”

(source: Security Portal, 2000 http://old.lwn.net/2000/0120/security.php3)