Bezpieczeństwo oprogramowania typu open source - Open-source software security

Bezpieczeństwo oprogramowania o otwartym kodzie źródłowym jest miarą pewności lub gwarancji wolności od niebezpieczeństw i ryzyka nieodłącznie związanych z systemem oprogramowania o otwartym kodzie źródłowym .

Debata wdrożeniowa

Korzyści

  • Oprogramowanie własnościowe zmusza użytkownika do zaakceptowania poziomu bezpieczeństwa, który producent oprogramowania jest skłonny zapewnić, oraz do zaakceptowania szybkości wydawania poprawek i aktualizacji.
  • Zakłada się, że każdy używany kompilator tworzy kod, któremu można zaufać, ale Ken Thompson wykazał, że kompilator można obalić za pomocą backdoora kompilatora w celu utworzenia wadliwych plików wykonywalnych, które są nieświadomie tworzone przez programistę o dobrych intencjach. Mając dostęp do kodu źródłowego kompilatora, programista ma przynajmniej możliwość wykrycia, czy nie ma żadnych złych intencji.
  • Zasada Kerckhoffsa opiera się na idei, że wróg może ukraść bezpieczny system wojskowy i nie może złamać informacji. Jego idee były podstawą wielu nowoczesnych praktyk bezpieczeństwa i podążał za tym, że bezpieczeństwo poprzez zaciemnienie jest złą praktyką.

Wady

  • Samo udostępnienie kodu źródłowego nie gwarantuje przeglądu. Przykładem tego jest sytuacja, gdy Marcus Ranum , ekspert w projektowaniu i wdrażaniu systemów bezpieczeństwa, wydał swój pierwszy publiczny zestaw narzędzi do zapory ogniowej. W pewnym momencie z jego zestawu narzędzi korzystało ponad 2000 witryn, ale tylko 10 osób przekazało mu uwagi lub poprawki.
  • Posiadanie dużej liczby oczu przeglądających kod może „uśpić użytkownika w fałszywym poczuciu bezpieczeństwa”. Przeglądanie kodu źródłowego przez wielu użytkowników nie gwarantuje, że błędy bezpieczeństwa zostaną znalezione i naprawione.

Metryki i modele

Istnieje wiele modeli i wskaźników służących do pomiaru bezpieczeństwa systemu. Oto kilka metod, które można wykorzystać do pomiaru bezpieczeństwa systemów oprogramowania.

Liczba dni między lukami

Uważa się, że system jest najbardziej podatny na ataki po wykryciu potencjalnej luki, ale przed utworzeniem łaty. Mierząc liczbę dni między luką a jej usunięciem, można określić podstawę bezpieczeństwa systemu. Jest kilka zastrzeżeń do takiego podejścia: nie każda luka jest równie zła, a szybkie naprawienie wielu błędów może nie być lepsze niż znalezienie kilku i zajęcie trochę więcej czasu na ich naprawienie, biorąc pod uwagę system operacyjny, lub skuteczność poprawki.

Proces Poissona

Proces Poissona można wykorzystać do pomiaru szybkości, z jaką różne osoby znajdują luki w zabezpieczeniach między oprogramowaniem o otwartym i zamkniętym kodzie źródłowym. Proces można podzielić według liczby wolontariuszy N v i opłaconych recenzentów N p . Wskaźniki, w jakich wolontariusze znajdują usterkę, są mierzone przez λ v, a współczynnik, w jakim opłacani recenzenci znajdują usterkę, mierzy się przez λ p . Oczekiwany czas, w którym grupa wolontariuszy ma znaleźć błąd, to 1 / (N v λ v ), a oczekiwany czas, w którym opłacana grupa powinna znaleźć błąd to 1 / (N p λ p ).

Model Morningstar

Porównując dużą różnorodność projektów open source i zamkniętych, system gwiazdy może być użyty do analizy bezpieczeństwa projektu, podobnie jak w przypadku oceny funduszy powierniczych przez Morningstar, Inc. Mając wystarczająco duży zestaw danych, statystyki można wykorzystać do zmierzenia ogólnej skuteczności jednej grupy w stosunku do drugiej. Przykład takiego systemu jest następujący:

  • 1 gwiazdka: wiele luk w zabezpieczeniach.
  • 2 gwiazdki: problemy z niezawodnością.
  • 3 gwiazdki: przestrzega najlepszych praktyk bezpieczeństwa.
  • 4 gwiazdki: Udokumentowany bezpieczny proces rozwoju.
  • 5 gwiazdek: pozytywnie przeszedł niezależny przegląd bezpieczeństwa.

Skan pokrycia

Coverity we współpracy z Uniwersytetem Stanforda ustanowiło nowy punkt odniesienia dla jakości i bezpieczeństwa oprogramowania typu open source. Realizacja jest realizowana na podstawie umowy z Departamentem Bezpieczeństwa Wewnętrznego. Wykorzystują innowacje w automatycznym wykrywaniu defektów, aby identyfikować krytyczne typy błędów znalezionych w oprogramowaniu. Poziom jakości i bezpieczeństwa mierzy się w szczeble. Szczeble nie mają ostatecznego znaczenia i mogą ulec zmianie, gdy Coverity wypuści nowe narzędzia. Szczeble są oparte na postępach w naprawianiu problemów znalezionych w wynikach analizy pokrycia i stopniu współpracy z Coverity. Zaczynają od szczebla 0 i obecnie przechodzą do szczebla 2.

  • Szczebel 0

Projekt został przeanalizowany przez infrastrukturę Coverity Scan, ale żaden przedstawiciel oprogramowania o otwartym kodzie źródłowym nie zgłosił się do wyników.

  • Szczebel 1

Na szczeblu 1 istnieje współpraca między Coverity a zespołem programistycznym. Oprogramowanie jest analizowane z podzbiorem funkcji skanowania, aby zapobiec przeciążeniu zespołu programistów.

  • Szczebel 2

Istnieje 11 projektów, które zostały przeanalizowane i zaktualizowane do poziomu Rung 2 poprzez osiągnięcie zerowej liczby defektów w pierwszym roku skanowania. Projekty te obejmują: AMANDA, ntp , OpenPAM , OpenVPN , Overdose, Perl , PHP , Postfix , Python , Samba i tcl .

Głoska bezdźwięczna

Szereg podcastów dotyczy bezpieczeństwa oprogramowania typu open source:

Zobacz też

Bibliografia

Zewnętrzne linki