Zawartość
- Tylko fakty
- Bez błędów, bez stresu - Twój przewodnik krok po kroku do tworzenia oprogramowania zmieniającego życie bez niszczenia życia
- Rozliczanie wpływu?
- Czas zmienić system?
Źródło: BrianAJackson / iStockphoto
Na wynos:
Czas zmienić wszystko, co myślimy o ocenie ryzyka dla komponentów open source.
Opracowanie systemu oceny tego, jak poważnie społeczność programistów powinna brać pod uwagę luki, jest, delikatnie mówiąc, wyzwaniem. Kod jest pisany przez ludzi i zawsze będzie miał wady. Pytanie, jeśli założymy, że nic nigdy nie będzie idealne, to jak najlepiej kategoryzować komponenty według ich ryzyka w sposób, który pozwala nam kontynuować produktywną pracę?
Tylko fakty
Chociaż istnieje wiele różnych podejść do rozwiązania tego problemu, każde z własnym uzasadnieniem, wydaje się, że najczęstszą metodą jest model ilościowy.
Z jednej strony zastosowanie podejścia ilościowego do oceny ważności luki może być przydatne, ponieważ jest bardziej obiektywne i mierzalne, oparte wyłącznie na czynnikach związanych z samą luką.
Metodologia ta określa, jakie szkody mogą wystąpić, gdyby wykorzystano tę lukę, biorąc pod uwagę, jak szeroko wykorzystywany jest komponent, biblioteka lub projekt w branży oprogramowania, a także czynniki, takie jak rodzaj dostępu, który mógłby dać osobie atakującej zrujnuj spustoszenie, jeśli użyją go do przekroczenia celu. Czynniki takie jak łatwość potencjalnego wykorzystania mogą odegrać dużą rolę w wpływie na wynik. (Aby uzyskać więcej informacji na temat bezpieczeństwa, zapoznaj się z Cyberbezpieczeństwem: jak nowe osiągnięcia przynoszą nowe zagrożenia - i odwrotnie).
Jeśli chcemy spojrzeć na poziom makro, perspektywa ilościowa pokazuje, jak luka może zaszkodzić stadzie, skupiając się mniej na szkodach, jakie mogą ponieść firmy, które zostaną faktycznie dotknięte atakiem.
National Vulnerability Database (NVD), być może najbardziej znana baza danych podatności na zagrożenia, przyjmuje to podejście zarówno w przypadku wersji 2, jak i 3, ich wspólnego systemu oceny luk w zabezpieczeniach (CVSS). Na swojej stronie wyjaśniając swoje wskaźniki oceny luk, piszą o swojej metodzie, która:
Jego model ilościowy zapewnia powtarzalny dokładny pomiar, jednocześnie umożliwiając użytkownikom zobaczenie podstawowych cech podatności, które zostały użyte do wygenerowania wyników. W związku z tym CVSS doskonale nadaje się jako standardowy system pomiarowy dla branż, organizacji i rządów, które potrzebują dokładnych i spójnych wyników oceny podatności na zagrożenia.
W oparciu o czynniki ilościowe w grze NVD może następnie uzyskać ocenę dotkliwości, zarówno z liczbą w skali - od 1 do 10, przy czym 10 jest najsurowsze - a także kategorie NISKIE, ŚREDNIE i WYSOKIE .
Bez błędów, bez stresu - Twój przewodnik krok po kroku do tworzenia oprogramowania zmieniającego życie bez niszczenia życia
Nie możesz poprawić swoich umiejętności programistycznych, gdy nikt nie dba o jakość oprogramowania.
Rozliczanie wpływu?
Wydaje się jednak, że NVD stara się unikać tego, co możemy nazwać bardziej jakościowym miernikiem podatności na zagrożenia, w oparciu o wpływ, jaki pewien exploit wyrządził, powodując szkody. Aby być uczciwym, uwzględniają wpływ w zakresie, w jakim mierzą wpływ podatności na system, uwzględniając czynniki poufności, integralności i dostępności. Są to wszystkie ważne elementy, na które należy zwrócić uwagę - podobnie jak w przypadku łatwiejszego do zmierzenia wektora dostępu, złożoności dostępu i uwierzytelnienia - ale nie czują się oni odpowiedzialni za powiązanie rzeczywistego wpływu, gdy luka powoduje realne straty organizacji.
Weźmy na przykład naruszenie Equifax, które ujawniło dane osobowe około 145 milionów osób, w tym dane dotyczące prawa jazdy, numery ubezpieczenia społecznego i inne elementy, które mogłyby zostać wykorzystane przez pozbawione skrupułów postacie do przeprowadzenia masowych oszustw.
To luka (CVE-2017-5638) została odkryta w projekcie Apache Struts 2, którego Equifax użył w swojej aplikacji internetowej, która pozwoliła napastnikom wejść do drzwi wejściowych i ostatecznie wyjść z nich z rękami pełnymi soczystych informacji osobistych. .
Chociaż NVD słusznie przyznało mu wskaźnik ważności 10 i WYSOKI, ich decyzja była spowodowana ich ilościową oceną jego potencjalnej szkody i nie była dotknięta rozległymi szkodami, które wystąpiły później, kiedy naruszenie Equifax stało się publiczne.
Nie jest to niedopatrzenie NVD, ale część ich ustalonej polityki.
NVD zapewnia „podstawowe wyniki” CVSS, które reprezentują wrodzoną charakterystykę każdej podatności. Obecnie nie udostępniamy „ocen czasowych” (wskaźników, które zmieniają się w czasie w związku ze zdarzeniami zewnętrznymi dla podatności) lub „ocen środowiskowych” (oceny dostosowane do odzwierciedlenia wpływu podatności na Twoją organizację).
Dla decydentów system pomiaru ilościowego nie powinien mieć większego znaczenia, ponieważ analizuje szanse na rozprzestrzenienie szkód w branży. Jeśli jesteś CSO banku, powinieneś przejmować się jakościowym wpływem, jaki może mieć exploit, jeśli zostanie wykorzystany do wyłudzenia danych klienta lub, co gorsza, jego pieniędzy. (Dowiedz się o różnych rodzajach luk w The 5 Scariest Threats In Tech.)
Czas zmienić system?
Tak więc luka w Apache Strusts 2 zastosowana w przypadku Equifax powinna otrzymać wyższy ranking w świetle tego, jak duże okazały się szkody, lub sprawiłaby, że zmiana okazałaby się zbyt subiektywna dla systemu takiego jak NVD nadążać?
Zapewniamy, że wymyślenie danych niezbędnych do uzyskania „oceny środowiskowej” lub „oceny czasowej” opisanej przez NVD byłoby niezwykle trudne, otwierając kierowników wolnego zespołu CVSS na niekończącą się krytykę i mnóstwo pracy dla NVD i innych w celu aktualizacji ich baz danych w miarę pojawiania się nowych informacji.
Oczywiście powstaje pytanie, w jaki sposób taki wynik zostałby skompilowany, ponieważ bardzo niewiele organizacji może przedstawić niezbędne dane na temat wpływu naruszenia, chyba że wymaga tego prawo o ujawnianiu informacji. W przypadku Ubera widzieliśmy, że firmy są skłonne szybko wypłacić pieniądze w nadziei, że informacje o naruszeniu nie dotrą do prasy, aby nie spotkać się z publiczną reakcją.
Być może niezbędny jest nowy system, który mógłby włączyć dobre wysiłki z baz danych podatności i dodać własną ocenę, gdy informacje będą dostępne.
Po co uruchamiać tę dodatkową warstwę punktacji, gdy wydaje się, że poprzednia dobrze spełniała swoje zadanie przez te wszystkie lata?
Szczerze mówiąc, sprowadza się to do odpowiedzialności organizacji za wzięcie odpowiedzialności za swoje aplikacje. W idealnym świecie każdy sprawdziłby wyniki składników używanych w swoich produktach przed dodaniem ich do ekwipunku, otrzymywał powiadomienia o wykryciu nowych luk w projektach, które wcześniej uważano za bezpieczne, i wdrażał niezbędne poprawki samodzielnie. .
Być może gdyby istniała lista pokazująca, jak niszczycielskie mogą być niektóre z tych luk w zabezpieczeniach dla organizacji, organizacje mogą odczuwać większą presję, aby nie dać się złapać ryzykownym komponentom. Przynajmniej mogą podjąć kroki, aby dokonać prawdziwej inwentaryzacji bibliotek, które już mają.
Po fiasku Equifax, więcej niż jeden kierownictwo na poziomie C prawdopodobnie starał się, aby upewnić się, że nie mają wrażliwej wersji Struts w swoich produktach. To niefortunne, że tak wielki incydent wymagał zmuszenia branży do poważnego potraktowania bezpieczeństwa typu open source.
Mamy nadzieję, że lekcja, że luki w komponentach aplikacji typu open source mogą mieć bardzo realne konsekwencje, wpłynie na to, w jaki sposób decydenci traktują bezpieczeństwo priorytetowo, wybierając odpowiednie narzędzia do ochrony swoich produktów i danych klientów.