aboutsummaryrefslogtreecommitdiffstats
path: root/polish/News/2004/20040406.wml
blob: cd1d0570b0ad68d66aa3077e61e9cdd67796198c (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
#use wml::debian::translation-check translation="1.4"
<define-tag pagetitle>Zbiorowe o¶wiadczenie dot. bezpieczeñstwa w systemach
GNU/Linux</define-tag>
<define-tag release_date>2004-04-04</define-tag>
#use wml::debian::news

# Joint Statement about GNU/Linux Security

<h3>Podsumowanie</h3>

<p>Dystrybutorzy systemów GNU/Linux: Debian, Mandrake, Red Hat i Suse stworzyli
wspólne o¶wiadczenie dotycz±ce raportu Forrestera zatytu³owanego 
,,Is Linux more Secure than Windows?'' (w t³umaczeniu: 
,,Czy Linux jest bardziej bezpieczny ni¿ Windows?''). 

W raporcie starano siê przedstawiæ i oceniæ reakcje dystrybutorów na luki w
bezpieczeñstwie. Jednak autorzy traktuj± wszystkie luki jakby by³y sobie
równe, nie uwzglêdniaj±c jaki maj± wp³yw dla u¿ytkownika. W wyniku tego 
uproszczenia, wnioski p³yn±ce z raportu Forrestera znacznie odbiegaj± 
od rzeczywisto¶ci, zani¿aj±c praktyczny czas naprawy powa¿nych luk 
bezpieczeñstwa.</p>

<h3>Pe³ne o¶wiadczenie</h3>

<p>Zespo³y odpowiedzialne za bezpieczeñstwo w dystrybucjach systemów GNU/Linux
Debian, Mandrakesoft, Red Hat i Suse pomog³y Forresterowi w zbieraniu i
uzupe³nianiu danych dotycz±cych s³abych punktów w swoich produktach. Zebrane
informacje pos³u¿y³y do opracowania raportu zatytu³owanego  ,,Is Linux more
Secure than Windows?'' (w t³umaczeniu: ,,Czy Linux jest bardziej bezpieczny
ni¿ Windows?''). Pomimo i¿ przedstawione w raporcie dane s± w miarê poprawne,
wnioski z nich wyp³ywaj±ce wymagaj± sprostowania. Dlatego te¿ Debian,
Madnrakesoft, Red Hat i SUSE (w dalszej czê¶ci tego dokumentu okre¶lane jako
,,my'') opublikowa³y wspólne stanowisko w tej sprawie. </p>

<p>Uwa¿amy, ¿e w interesie naszych u¿ytkowników i ca³ej spo³eczno¶ci Wolnego
Oprogramowania jest zaprezentowanie zbiorowego o¶wiadczenia dotycz±cego
raportu Forrestera:
</p>

<p>Zostali¶my poproszeni przez Forrestera w lutym 2004 roku o pomoc w
uzupe³nieniu danych. Forrester zebra³ informacje dotycz±ce 
luk w bezpieczeñstwie
systemów GNU/Linux z okresu od czerwca 2002 do maja 2003 i sprawdzi³ ile czasu
zajê³o nam dostarczenie odpowiednich poprawek dla u¿ytkowników.
Po³o¿ono du¿y nacisk nie tylko na to, aby zebrane dane by³y prawid³owe, ale
zbadano równie¿ wszystkie techniczne zagadnienia zwi±zane z reakcj±
producentów na potencjalne zagro¿enie.
Stosowane przez nas metody zajmowania siê problemami bezpieczeñstwa doceniane
przez naszych u¿ytkowników zosta³y równie¿ pozytywnie przedstawione w
ekspertyzie Forrestera. 
Niestety ich warto¶æ zosta³a zignorowana podczas ostatecznej analizy 
w efekcie doprowadzaj±c do b³êdnych wniosków.
</p>

<p>Poszczególne zespo³y do spraw bezpieczeñstwa, oraz organizacje o du¿ej reputacji
zajmuj±ce siê bezpieczeñstwem (takie jak: CERT/DHS, BSI, NIST, NISCC)
wymieniaj± miêdzy sob± informacje o mo¿liwych lukach w bezpieczeñstwie.
Poszczególne zespo³y wspó³pracuj± ze sob± stosuj±c ró¿ne procedury zale¿ne
wielko¶ci analizowanego problemu. 
Ka¿da luka w bezpieczeñstwie jest oddzielnie przegl±dana i oceniana. Jej
wp³yw na bezpieczeñstwo sytemu (wa¿no¶æ) jest oceniana przez poszczególne
zespo³y na podstawie potencjalnego ryzyka oraz wp³ywu, jak
równie¿ innych technicznych aspektów.
Wa¿no¶æ poszczególnych problemów ma wp³yw na priorytet z jakim pracowaæ
bêd± zespo³y bezpieczeñstwa nad jego poprawieniem. Nasi u¿ytkownicy wiedz±, ¿e
w przypadku krytycznych punktów systemu jeste¶my w stanie odpowiedzieæ w
czasie kilku godzin. Nadawanie priorytetów oznacza, ¿e mniej wa¿ne problemy
s± pozostawiane do rozwi±zania na pó¼niej, a wa¿niejsze s± badane w pierwszej
kolejno¶ci.
</p>

<p>Pomimo i¿ Forrester twierdzi inaczej, wcale nie dokonywa³ rozró¿nienia
podczas pomiaru czasu pomiêdzy publiczn± informacj± o b³êdzie, a dostêpno¶ci±
poprawki dystrybutora. Dla ka¿dego z dystrybutorów wyliczono zwyk³± ¶redni±
nazywan± w raporcie ,,All/Distributions days of risk'' (,,Wszystkie/Ca³kowity
czas ryzyka w dystrybucji''). Takie uproszczenie daje odbiegaj±cy od
rzeczywisto¶ci obraz. 
Wyliczaj±c ¶redni± traktuje siê wszystkie luki w bezpieczeñstwie jakby by³y
sobie równe. Oczywi¶cie nie ka¿da podatno¶æ na naruszenie bezpieczeñstwa ma
taki sam wp³yw na ka¿dego u¿ytkownika. 
Próbowano dokonaæ pewnej klasyfikacji wykorzystuj±c dane z
oddzielnych/zewnêtrznych organizacji. Jednak dokonany tam podzia³
,,high-severality'' (du¿a-wa¿no¶æ) nie jest wystarczaj±cy. Samo zg³oszenie
b³êdu przez zewnêtrzn± organizacjê, czy mo¿liwo¶æ wykorzystania luki przez
sieæ (zdalnie) wcale nie musi oznaczaæ, ¿e istniej±ca podatno¶æ na naruszenie
bezp. jest bardzo powa¿na.
</p>

<p>Naszym zdaniem dostarczyciele Wolnego Oprogramowania i producent
oprogramowania zamkniêtego nie byli w raporcie potraktowani w równorzêdny
sposób.
Wolne Oprogramowanie jest znane ze swojego zró¿nicowania i mo¿liwo¶ci wyboru w
okre¶lonych standardach. Wiele implementacji tych standardów jest dostarczana
zarówno dla u¿ytkowników komputerów biurkowych (tzw. ,,desktopów''), jak i dla
rozwi±zañ serwerowych. Daje to mo¿liwo¶æ wyboru oprogramowania w zale¿no¶ci
od przyjêtych przez u¿ytkownika kryteriów, a nie kryteriów narzuconych przez
producenta. Otwarto¶æ, przejrzysto¶æ rozwi±zañ i ³atwo¶æ namierzania problemów
w kodzie ¼ród³owym jest kolejn± zalet± istniej±cej du¿ej grupy pakietów
oprogramowania.
Stwierdzenie, ¿e jeden z producentów oprogramowania naprawi³ w okre¶lonym
czasie 100% b³êdów powinno byæ zachêt± do szczegó³owej analizy takiego
stwierdzenia i wyci±gniêcia odpowiednich, logicznych wniosków.
</p>

<p>podpisali,
<br>Noah Meyerhans, Debian
<br>Vincent Danen, Mandrakesoft
<br>Mark J Cox, Red Hat
<br>Roman Drahtmüller, SUSE</p>

<h3>Dodatkowe informacje:</h3>

<p>Javier Fernández-Sanguino Pe&ntilde;a <a
href="http://people.debian.org/~jfs/debconf/security/data/">przygotowa³</a>
<a href="http://lists.debian.org/debian-security-0112/msg00257.html">\
zestawienie</a> na rok 2001, z którego wynika, ¿e zespo³owi ds. bezpieczeñstwa
w Debianie naprawienie b³êdu zajê³o ¶rednio 35 dni. Jednak, ponad 50% z nich
zosta³a naprawiona w przeci±gu dziesiêciu dni, a ponad 15% zosta³o naprawione w
dniu wydania porady dotycz±cej bezpieczeñstwa! W tej prostej analizie
wszystkie b³êdy by³y traktowane na równi.</p>

<p>Javier przygotowa³ swoje zestawienie na podstawie danych o 
b³êdach odkrytych w okresie od 1 czerwca 2002, do 31 maja 2003. Obliczenia 
wykaza³y, ¿e mediana opó¼nienia pomiêdzy odkryciem b³êdu, a wydaniem porady z
odpowiedni± poprawk± wynosi³a 13,5 dnia (¶rednia 31,10 dnia). Równie¿ w tej
analizie wszystkie porady by³y traktowane na równi.
</p>

© 2014-2024 Faster IT GmbH | imprint | privacy policy