Top
5 misconceptions about open source in government programs
Posted 21 May 2013 by
Adam Firestone
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
- 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, from 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
alternatives, 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 alternatives, 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 from 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 insert 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
- 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 from 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 from 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 from support and
consulting associated with those products.
Government
information assurance policies prohibit OSS
This
misconception derives from 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 from 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 alternative 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 from 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 from 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 insert 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 from 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. From 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
Không có nhận xét nào:
Đăng nhận xét
Lưu ý: Chỉ thành viên của blog này mới được đăng nhận xét.