5 sự hiểu sai hàng đầu về nguồn mở trong các chương trình của chính phủ

Top 5 misconceptions about open source in government programs

Posted 21 May 2013 by Adam Firestone

Theo: http://opensource.com/government/13/5/top-5-misconceptions-open-government

Bài được đưa lên Internet ngày: 21/05/2013

Lời người dịch: Khi khu vực chính phủ nói về phần mềm tự do nguồn mở (PMTDNM), rất nhiều người viện tới các câu chuyện hoang đường, thường được chính các các hãng phần mềm sở hữu độc quyền hoặc các 'bề tôi' của họ cố ý thêu dệt lên. Các câu chuyện hoang đường đó thường là: (1) PMNM không được sử dụng rộng rãi trong các chương trình của chính phủ; (2) PMNM không tương đương với phần mềm thương mại; (3) Các chính sách đảm bảo thông tin của chính phủ cấm PMNM; (4) PMNM ít an ninh hơn so với phần mềm sở hữu độc quyền; (5) Dễ chèn mã độc hơn vào PMNM. Bài viết này lần lượt phân tích các khía cạnh của những câu chuyện hoang đường đó. Bạn có thể học được từ những lý luận đó nhiều điều.

Ngày 15/03/2013, ComputerWeekly.com, “nhà cung cấp hàng đầu về tin tức, phân tích, ý kiến phản hồi, thông tin và các dịch vụ cho cộng đồng CNTT nước Anh” đã xuất bản một bài báo của Bryan Glick với tựa đề: Chính phủ bắt buộc 'ưu tiên' cho nguồn mở. Bài báo tập trung và sự phát hành Sách chỉ dẫn thiết kế dịch vụ Chính phủ, mà, từ tháng 04/2013, sẽ đưa ra việc điều hành các tiêu chuẩn cho các dịch vụ trực tuyến được chính phủ Anh phát triển để sử dụng công khai.

Có lẽ phần thú vị nhất của tài liệu mới này là một phần có tựa đề: Khi sử dụng nguồn mở. Thú vị đối với tôi, ít nhất là như vậy. Nhiều năm tôi đã và đang bảo vệ cho sự sử dụng các sản phẩm nguồn mở cho các dự án trong các cộng đồng tình báo và quốc phòng của Mỹ. Nên, hãy tha lỗi cho tôi về việc đi hơi xanh với sự đố kỵ khi tôi đọc thứ sau đây trong phần đó:

Sử dụng phần mềm nguồn mở (PMNM) ưu tiên hơn so với sở hữu độc quyền hoặc các lựa chọn nguồn đóng, đặc biệt cho các hệ điều hành, phần mềm kết nối mạng, các máy chủ web, các cơ sở dữ liệu và các ngôn ngữ lập trình.

Tuyên bố không để lại nhiều chỗ cho thảo luận hoặc nghi ngờ. Khi có một sự lựa chọn giữa các lựa chọn thay thế so sánh được, thì nguồn mở thắng. Chấm hết. Thật sáng tỏ!

Trong các chương trình của chính phủ Mỹ, trong khi sử dụng PMNM không là bắt buộc, thì nó là vừa dễ dãi và thường được khuyến khích. Tuy nhiên, vì bản chất tự nhiên kiểu kiến trúc Byzantine của việc kiểm soát các luật, qui định, chính sách và chỉ dẫn (LRPG) cũng như một số sự hiểu sai phổ biến, các kiến trúc sư, kỹ sư hệ thống, và các lập trình viên thường gặp phải những phản ứng trải từ sự không quen thuộc cho tới sự kháng cự khi khuyến cáo sử dụng PMNM. Đối với phần còn lại của bài báo, chúng tôi đã sửa lỗi cho 5 trong số những hiểu sai phổ biến nhất. Đặc biệt, chúng tôi nói về những câu chuyện hoang đường rằng:

• PMNM không được sử dụng rộng rãi trong các chương trình của chính phủ

• PMNM không tương đương với phần mềm thương mại

• Các chính sách đảm bảo thông tin của chính phủ cấm PMNM

• PMNM ít an ninh hơn so với phần mềm sở hữu độc quyền

• Dễ chèn mã độc hơn vào PMNM

PMNM không được sử dụng rộng rãi trong các chương trình của chính phủ

Các thành phần và ứng dụng nguồn mở từ lâu đã được khuyến khích trong các chương trình của chính phủ Mỹ, và thường đưa ra các khả năng hệ thống cốt lõi không thể thay thế được. Nêu một ít:

• Trình duyệt Mozilla Firefox và trình thư điện tử máy trạm Thunderbird

• Hệ điều hành Android của Google cho các thiết bị di động

• Máy chủ web Tomcat và Servlet Container của Apache

• Hệ điều hành Linux

• Hệ quản trị cơ sở dữ liệu đối tượng quan hệ (ORDBMS) PostgreSQL

• Hệ quản trị nội dung Drupal

• WSO2 Enterprise Service Bus (ESB)

• Hệ thống thông tin địa lý (GIS) gió thế giới của NASA

PMNM không tương đương với phần mềm thương mại

Hầu hết, nếu không phải là tất cả, các ứng dụng và thành phần PMNM là, theo luật, các khoản thương mại. Định nghĩa này tới từ một luật của Liên bang Mỹ (41 USC 403, subsection 12) mà xác định một 'khoản thương mại' như là:

(A) Bất kỳ khoản nào, khác với tài sản thực, mà ở dạng được công chúng nói chung hoặc các thực thể phi chính phủ sử dụng tùy ý cho các mục đích khác với các mục đích của chính phủ, và rằng

(i) từng được bán, được cho thuê, hoặc được cấp phép cho công chúng nói chung; hoặc

(ii) từng được chào bán, cho thuê, hoặc cấp phép cho công chúng nói chung.

(B) Bất kỳ khoản nào mà được tiến hóa từ một khoản được mô tả trong đoạn phụ (A) thông qua những tiến bộ trong công nghệ hoặc hiệu năng và còn chưa sẵn sàng trong thị trường thương mại, nhưng sẽ là sẵn sàng trong thị trường thương mại đúng lúc để làm thỏa mãn các yêu cầu phân phối theo một sự khẩn nài của Chính phủ Liên bang.

(C) Bất kỳ khoản nào mà dành cho

(i) những sửa đổi một dạng sẵn sàng tùy ý trong thị trường thương mại, hoặc

(ii) những sửa đổi nhỏ được thực hiện để đáp ứng các yêu cầu của Chính phủ Liên bang, có thể làm thỏa mãn các tiêu chí trong đoạn phụ (A) hoặc (B).

Giải nghĩa luật này như là việc tuyên bố PMNM sẽ là 'phần mềm thương mại' từng được sự đảm bảo của Bộ Quốc phòng khẳng định từ tài liệu Làm rõ Chỉ dẫn về PMNM ngày 16/10/2009 và sự đảm bảo của Hải quân Mỹ đối với một bản ghi nhớ về chỉ dẫn PMNM ngày 05/07/2007.

Hơn nữa, Văn phòng Quản lý và Ngân sách Mỹ (OMB) đã thừa nhận bản chất tự nhiên thương mại của những thỏa thuận hỗ trợ PMNM từ đảm bảo 2003 từ bản ghi nhớ M-03-14: Giảm chi phí và cải thiện chất lượng trong các mua sắm phần mềm thương mại của Liên bang. Quả thực, nhiều công ty thương mại nổi tiếng (như, IBM, RedHat, Novell, Microsoft, …) kiếm doanh số đáng kể bằng việc hỗ trợ các sản phẩm nguồn mở. Các công ty thương mại khác, như WSO2, xây dựng các sản phẩm PMNM và tạo doanh số chỉ từ sự hỗ trợ và tư vấn có liên quan tới các sản phẩm đó.

Các chính sách đảm bảo thông tin của chính phủ cấm PMNM

Sự hiểu sai nay xuất phát từ việc đọc sai hoặc, chính xác hơn, một việc đọc không đầy đủ DoD Chỉ thị của Bộ Quốc phòng 8500.2 Triển khai Đảm bảo Thông tin (IA). Tài liệu này bao gồm một tài liệu kèm theo (Tài liệu kèm theo số 4) với đầu đề: Các mức Đảm bảo Thông tin Cơ bản. Tài liệu này có một số kiểm soát phần mềm với nó một hệ thống được phê chuẩn phải tuân thủ (hoặc, nếu không tuân thủ, phải nhận một sự khước từ từ Nhà chức trách Phê chuẩn Được chỉ định (DAA). Trong số chúng có kiểm soát DCPD-1 Các kiểm soát Phần mềm Miền Công cộng. Ý tưởng rằng PMNM bị cấm nảy sinh vì nhiều người chỉ đọc ít dòng đầu, nó nói:

Các sản phẩm phần mềm miền công cộng có khả năng thực thi nhị phân hoặc máy và các sản phẩm phần mềm khác bị hạn chế hoặc không đảm bảo như các sản phẩm thường được biết tới như là các phần mềm quảng cáo (freeware) hoặc phần mềm chia sẻ (shareware) không được sử dụng trong các hệ thống thông tin của Bộ Quốc phòng trừ phi chúng là cần thiết cho sự hoàn thành nhiệm vụ và không có các giải pháp CNTT lựa chọn thay thế nào sẵn sàng.

Văn bản của kiểm soát đó, tuy vậy, tiếp tục:

Các sản phẩm như vậy được đánh giá về các tác động đảm bảo thông tin, và được phê chuẩn để sử dụng đối với DAA. Sự đánh giá đó nhằm giải quyết thực tế rằng các sản phẩm phần mềm như vậy là khó hoặc không thể rà soát lại, sửa chữa hoặc mở rộng, biết rằng Chính phủ không có sự truy cập tới mã nguồn ban đầu và không có người chủ sở hữu mà có thể thực hiện sự sửa đổi như vậy nhân danh Chính phủ. (Nhấn mạnh được bổ sung thêm).

Chìa khóa cho việc hiểu đầy đủ sự kiểm soát này nằm ở câu cuối cùng, nó thảo luận các hệ quả chảy từ thực tế là chính phủ không có sự truy cập tới mã nguồn ban đầu. Sự kiểm soát (mà từng được đặt ra để làm việc với các nhị phân bị bỏ qua) rõ ràng không thể áp dụng cho PMNM vì theo định nghĩa, người sử dụng có sự truy cập tới mã nguồn!

PMNM là ít an ninh hơn so với phần mềm sở hữu độc quyền

Có một sự hiểu sai phổ biến với các dòng “vì PMNM là sẵn sàng cho thế gới để nhìn, nó dễ dàng để đột nhập”. Nói cách khác, sự xác nhận là vì nguồn mở đối với phần mềm sở hữu độc quyền là không bị mở ra, nên những kẻ tấn công không biết được về những chỗ bị tổn thương. Thực tế và cộng đồng công nghệ thông tin không đồng ý với tiên đề này. Từ những năm 1973, Jerrome Sattzer và Michael Schroeder đã viện lý trong tài liệu Bảo vệ thông tin trong các Hệ thống Máy tính rằng việc phụ thuộc vào sự ngờ nghệch của kẻ tấn công không phải là một cơ chế bảo vệ có hiệu quả. Gần đây hơn, các chuyên gia an ninh Vincent Rijmen (một trong những người sáng tạo ra Rthuật toán Rijndael mà sau này đã trở thành Tiêu chuẩn Mã hóa Tiên tiến (AES) và Whitfield Diffie (một người tiên phong về mật mã khóa công khai) đã đồng tình với ý kiến đó.

Đặc biệt nói rằng trước khi có việc áp dụng thuật toán Rijndael như là AES trong Tiêu chuẩn Xử lý Thông tin Liên bang (FIPS) 197 trong năm 2001, Viện Tiêu chuẩn và Công nghệ Quốc gia (NIST) đã xuất bản thuật toán này một cách công khai. Gần 3 năm đã được bỏ ra, trong đó các nhà mật mã học từ khắp thế giới đã được yêu câu thử đánh bại Rijndael. Cuối cùng, tất cả các cố gắng đã thất bại, và AES vẫn là cốt lõi của các phương pháp mã hóa của chính phủ Mỹ ngày nay. Về qui trình minh bạch (và đặc biệt nguồn mở), Bruce Schneier, tác giả của một trong những thuật toán thua cuộc đã nói, “Tôi không có gì ngoài những điều tốt lành để nói về qui trình của NIST và AES”.

Dễ dàng hơn để chèn các mã độc vào PMNM

Một trong những lý lẽ được thực hiện chống lại PMNM là việc bất kỳ ai cũng có thể sửa đổi nó, bao gồm cả những kẻ tấn công. Vấn đề thực tế là có được mã được sửa đổi trong chuỗi cung ứng. Tiên đề này không chỉ đòi hỏi việc lật đổ cả đối với các lập trình viên và kho tin cậy, mà nó còn đơn giản bỏ qua những thực tế làm việc với một nguồn phân tán. PMNM, hoặc được phát triển từ một cộng đồng hoặc một công ty, thường xuyên được rà soát lại từ một tổ chức giám sát khá lỏng lẻo mà gấp nhiều lần về kích cỡ của các tổ chức khả thi về kinh tế đối với các công ty của các lập trình viên sở hữu độc quyền. Hơn nữa, dải rộng lớn những người rà soát lại làm cho sự giám sát từ nhiều triển vọng khác nhau.

Kết quả là, khó hơn nhiều đối với mã bị phá vỡ để vẫn là không dò tìm ra được lâu dài. Có lẽ câu chuyện minh họa lớn nhất theo cách này là cơ sở dữ liệu InterBase/Firebird của Borland. Khi được phát triển, một cửa hậu từng được xây dựng trong hệ thống đó. Việc sử dụng tên người sử dụng 'một cách chính trị' và mật khẩu 'đúng' thì có khả năng có được sự truy cập của người quản trị tới cơ sở dữ liệu đó qua Internet. Vào lúc được phát hiện vào năm 2001, ước tính rằng cửa hậu đó đã tồn tại ít nhất là từ năm 1994. Từ quan điểm của PMNM, thú vị để lưu ý rằng Borland đã mở nguồn mã nguồn của InterBase theo Giấy phép Công cộng Mozilla – MPL vào giữa những năm 2000. Trong vòng 5 tháng của phiên bản nguồn mở, lỗ hổng an ninh từng không bị phát hiện ít nhất 7 năm đã bị phát hiện.

Kết luận

Tóm lại, trong khi chính phủ Mỹ, cho tới nay còn chưa đưa ra chỉ dẫn yêu cầu ưu tiên cho nguồn mở, thì nó rõ ràng đã chỉ ra rằng các sản phẩm nguồn mở được cho là ít nhất cũng có ưu tiên như các sản phẩm sở hữu độc quyền. Hơn nữa, các sản phẩm nguồn mở đi với một số lợi ích vốn dĩ đáng kể với sự lưu ý về đảm bảo thông tin và an ninh. Những gì điều này thực sự có ý nghĩa là các nhà quản lý mua sắm có sự lựa chọn lớn hơn và một khả năng gia tăng để đưa ra các quyết định thực dụng làm gia tăng năng lực trong khi làm giảm được tổng chi phí sở hữu. Và đó là công thức cho sự thành công ở khắp nơi.

On March 15, 2013, ComputerWeekly.com, the “leading provider of news, analysis, opinion, information and services for the UK IT community” published an article by Bryan Glick entitled: Government mandates 'preference' for open source. The article focuses on the release of the UK’s new Government Service Design Manual, which, f-rom April 2013, will provide governing standards for the online services developed by the UK’s government for public consumption.

Perhaps the most interesting part of the new document is a section entitled: When to use open source. Interesting to me, at least. For a number of years I’ve been advocating the use of open source products for projects within the US defense and intelligence communities. So, forgive me for going a little green with envy when I read the following within that section:

Use open source software in preference to proprietary or closed source al-ternatives, in particular for operating systems, networking software, web servers, databases and programming languages.

The statement doesn’t leave much room for discussion or doubt. When there’s a choice between comparable al-ternatives, open source wins. Period. How enlightened!

Within US government programs, while the use of open source software (OSS) is not mandatory, it is both permissible and often encouraged. However, due to the Byzantine nature of the controlling laws, regulations, policies, and guidance (LRPG) as well as some popular misconceptions, architects, systems engineers, and developers often encounter reactions ranging f-rom unfamiliarity to resistance when recommending the use of OSS. For the remainder of this article, we’ll debug five of the most widespread misconceptions. Specifically, we'll talk about the myths that:

• OSS isn't widely used in government programs

• OSS isn't equivalent to commercial software

• Government information assurance policies prohibit OSS

• OSS is less secure than proprietary software

• It's easier to in-sert malicious code into OSS

OSS isn’t widely used in government programs

Open source components and applications have long been leveraged by US government programs, and often provide irreplaceable core system capabilities. To name a few:

• Mozilla Firefox Browser and Thunderbird Email Client

• Google Android Operating System for Mobile Devices

• Apache Tomcat Web Server and Servlet Container

• Linux Operating System

• PostgreSQL Object Relational Database Management System (ORDBMS)

• Drupal Content Management System

• WSO2 Enterprise Service Bus (ESB)

• Apache Hadoop Distributed Computing Framework

• NASA World Wind Geospatial Information System (GIS)

OSS isn't equivalent to commercial software

Most, if not all, OSS applications and components are, by law, commercial items. The definition comes f-rom a US federal law (41 USC 403, subsection 12) that identifies a 'commercial item' as:

(A) Any item, other than real property, that is of a type customarily used by the general public or by nongovernmental entities for purposes other than governmental purposes, and that

(i) has been sold, leased, or licensed to the general public; or

(ii) has been offered for sale, lease, or license to the general public.

(B) Any item that evolved f-rom an item described in subparagraph (A) through advances in technology or performance and that is not yet available in the commercial marketplace, but will be available in the commercial marketplace in time to satisfy the delivery requirements under a Federal Government solicitation.

(C) Any item that, but for

(i) modifications of a type customarily available in the commercial marketplace, or

(ii) minor modifications made to meet Federal Government requirements, would satisfy the criteria in subparagraph (A) or (B).

The interpretation of this law as declaring OSS to be 'commercial software' was confirmed by the DoD’s issuance of Clarifying Guidance Regarding OSS on October 16, 2009 and the US Navy’s issuance of a memorandum for OSS guidance on July 5, 2007.

Moreover, the US Office of Management and Budget (OMB) has recognized the commercial nature of OSS support agreements since the 2003 issuance of memorandum M-03-14: Reducing Cost and Improving Quality in Federal Purchases of Commercial Software. Indeed, many well-known commercial companies (e.g., IBM, RedHat, Novell, Microsoft, etc.) earn considerable revenue by supporting open source products. Other commercial companies, such as WSO2, build open source software products and generate revenue solely f-rom support and consulting associated with those products.

Government information assurance policies prohibit OSS

This misconception derives f-rom a misreading or, more accurately, an incomplete reading of DoD Instruction 8500.2 Information Assurance (IA) Implementation. This document contains an enclosure (Enclosure 4) entitled: Baseline Information Assurance Levels. This enclosure contains a number of software controls with which an approved system must comply (or, if non-compliant, must receive a waiver f-rom the Designated Approval Authority (DAA)). Among them is control DCPD-1 Public Domain Software Controls. The idea that OSS is prohibited arises because many people only read the first set few lines, which read:

Binary or machine executable public domain software products and other software products with limited or no warranty such as those commonly known as freeware or shareware are not used in DoD information systems unless they are necessary for mission accomplishment and there are no al-ternative IT solutions available.

The text of the control continues, however:

Such products are assessed for information assurance impacts, and approved for use by the DAA. The assessment addresses the fact that such software products are difficult or impossible to review, repair, or extend, given that the Government does not have access to the original source code and there is no owner who could make such repairs on behalf of the Government. (Emphasis added.)

The key to fully understanding this control lies in the last sentence, which discusses consequences flowing f-rom the fact that the government does not have access to the original source code. The control (which was put in place to deal with abandoned binaries) clearly cannot apply to OSS because by definition, the user has access to the source code!

OSS is less secure than proprietary software

There is a common misunderstanding along the lines of "since OSS is available for the world to see, it’s easier to hack." Put another way, the assertion is that since the source code for proprietary software is not disclosed, attackers are unaware of vulnerabilities. Reality and the information technology community disagree with this premise. As far back as 1973 Jerome Saltzer and Michael Schroeder argued in their paper The Protection of Information in Computer Systems that depending on attacker ignorance isn’t an effective protection mechanism. More recently, security experts Vincent Rijmen (one of the creators of the Rijndael algorithm that later became the Advanced Encryption Standard (AES) and Whitfield Diffie (a pioneer of public key cryptography) echoed the sentiment.

It’s especially telling that prior to adopting the Rijndael algorithm as AES in Federal Information Processing Standard (FIPS) 197 in 2001, the National Institute of Standards and Technology (NIST) published the algorithm publicly. Approximately three years were allocated, during which cryptanalysts f-rom all over the world were asked to try to defeat Rijndael. In the end, all attempts failed, and AES remains the core of US government encryption methods today. Of the transparent (and essentially open source) process, Bruce Schneier, author of one of the losing algorithms said, "I have nothing but good things to say about NIST and the AES process."

It’s easier to in-sert malicious code into OSS

One of the arguments made against OSS is that anyone can modify it, including attackers. The reality is that ANY code can be modified; all you need is a hex editor. The real issue is getting the modified code into the supply chain. Not only does this premise require subverting both the developers and the trusted repository, but it simply ignores the realities of working with a distributed source. OSS, whether developed by a community or a company, is regularly reviewed by a loosely coupled inspection organization that is many times the size of those economically feasible for proprietary developer companies. Additionally, the wide range of reviewers results in inspection f-rom many different perspectives.

As a result, it is much more difficult for subverted code to remain undetected for long. Perhaps the most illustrative story in this vein is that of Borland’s InterBase/Firebird database. When developed, a back door was built into the system. Using the username 'politically' and the password 'correct' it was possible to get administrative access to the database over the Internet. At the time of discovery in 2001, it was estimated that the back door had existed at least since 1994. F-rom an OSS standpoint, it’s interesting to note that Borland open sourced the InterBase source code under a Mozilla Public License in mid-2000. Within five months of the open source release, the security hole that had lain undiscovered for at least seven years had been discovered.

Conclusion

In summary, while the US government has, to date not issued guidance requiring a preference for open source, it has clearly indicated that open source products are to be given at least as much preference as proprietary products. Additionally, open source products come with some significant intrinsic benefits with respect to security and information assurance. What this really means is that acquisitions managers have greater choice and an increased ability to make programmatic decisions that increase capability while lowering total cost of ownership. And that’s a recipe for success all around.

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com