path: root/polish/News/2004/20040406.wml

#use wml::debian::translation-check translation="534d1b782cfb92f46dc41fd064f779fffc329b12"
<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 
<q>Is Linux more Secure than Windows?</q> (w tłumaczeniu: 
<q>Czy Linux jest bardziej bezpieczny niż Windows?</q>). 

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  <q>Is Linux more
Secure than Windows?</q> (w tłumaczeniu: <q>Czy Linux jest bardziej bezpieczny
niż Windows?</q>). 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
<q>my</q>) 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 <q>All/Distributions days of risk</q> (<q>Wszystkie/Całkowity
czas ryzyka w dystrybucji</q>). 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ł
<q>high-severality</q> (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. <q>desktopów</q>), 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="https://people.debian.org/~jfs/debconf3/security/data/">przygotował</a>
<a href="https://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>