Jak chronić produkcję oprogramowania?
W zeszłotygodniowym artykule pisaliśmy o bezpieczeństwie kodu oprogramowania – dzisiaj chcielibyśmy do tego nawiązać, niejako pogłębiając temat. Jest ku temu powód natury medialnej, a wręcz newsowej. Otóż trzy amerykańskie agencje rządowe – Agencja Cyberbezpieczeństwa i Bezpieczeństwa Informacji (CISA), Agencja Bezpieczeństwa Narodowego (NAS) oraz Biuro Dyrektora Wywiadu Narodowego (ODNI) – ogłosiły wydanie pierwszej z trzech części raportu zawierającego wskazówki dotyczące zabezpieczenia łańcucha dostaw oprogramowania.
Wytyczne zostały opracowane przez Enduring Security Framework (ESF). To międzysektorowa grupa robocza kierowana przez NSA i CISA, skupiająca się na rozwiązywaniu problemów zagrażających infrastrukturze krytycznej i bezpieczeństwu narodowemu.
Pierwsza część serii, Securing Software Supply Chain Series, opisuje zalecane najlepsze praktyki dla programistów, którzy chcą poprawić bezpieczeństwo łańcucha dostaw oprogramowania.
„Ten dokument dostarczy wskazówek zgodnych z najlepszymi praktykami i zasadami w branży, do których zdecydowanie zachęcamy twórców oprogramowania. Zasady te obejmują planowanie wymagań bezpieczeństwa, projektowanie architektury oprogramowania z punktu widzenia bezpieczeństwa, dodawanie funkcji bezpieczeństwa oraz utrzymywanie bezpieczeństwa oprogramowania i infrastruktury bazowej” – pochwalili się autorzy raportu.
Poradnik, który ma mieć zastosowanie do wielu scenariuszy, zawiera praktyczne zalecenia dotyczące bezpiecznego cyklu życia oprogramowania (Secure SDLC), pierwszego kroku w kierunku bezpiecznego łańcucha dostaw.
Zaleca się, by zespoły programistyczne dostosowały bezpieczny proces SDLC do konkretnych potrzeb, identyfikując procedury i polityki, których mogą użyć, aby zapewnić wdrożenie bezpiecznych praktyk programistycznych.
„Zespół zarządzający najwyższego szczebla w organizacji musi zapewnić, że bezpieczne polityki i procedury rozwoju są obsługiwane w ramach budżetu i harmonogramu oraz wdrażane i przestrzegane przez wyznaczone zespoły programistyczne” – dodano w wytycznych.
Dokument szczegółowo opisuje typowe scenariusze zagrożeń, które mogą wystąpić podczas cyklu rozwoju oprogramowania, i zawiera zalecenia dotyczące łagodzenia skutków naruszeń bezpieczeństwa. Poza tym raport jest próbą ustalenia standardów dla architektury i dokumentów projektowych, stworzenia modeli zagrożeń i planów testów zabezpieczeń, kryteriów wydania, zasad obsługi luk w zabezpieczeniach oraz oceny i szkolenia.
Wytyczne zalecają również różne procesy i praktyki Secure SDLC dostarczane przez NIST, Carnegie Mellon University, OWASP, US-Cert, OpenSSF i inne.
Próba standaryzacji bezpieczeństwa produkcji oprogramowania jest odpowiedzią na ostatnie światowe wydarzenia. Rok 2021 można określić jako rok ataku na łańcuch dostaw oprogramowania – rok, w którym afera SolarWinds uświadomiła światu skalę zagrożenia.
Oprócz SolarWinds warto przypomnieć inne ataki: Kaseya, Codecov, ua-parser-js i Log4j. W każdym z tych przypadków potężną przewagą atakującego było to, że pojedyncze naruszenie, kompromitacja lub luka w rozproszonym kodzie może prowadzić do wielu – nawet tysięcy – ofiar.
Przed niedawno opublikowanym raportem ESF pojawił się dokument poprzedzony sześciomiesięczną analizą i oceną bezpieczeństwa klientów przygotowany przez Argon (firmę Aqua Security). Raport ten dotyczył bezpieczeństwa łańcucha dostaw oprogramowania i podkreślał główne obszary zainteresowania przestępców: luki w zabezpieczeniach typu open source, problemy z integralnością kodu oraz wykorzystywanie procesu łańcucha dostaw oprogramowania i zaufania do dostawców celem rozpowszechniania złośliwego oprogramowania lub backdoorów.
Wspólnym czynnikiem jest oprogramowanie typu open source – często darzone bezkrytycznym zaufaniem i używane automatycznie przez programistów systemów.
Analiza Argon zwraca uwagę na trzy główne obszary problemów: luki w aplikacjach typu open source, zhakowane narzędzia oraz integralność kodu.
Ataki w łańcuchu dostaw podatnych aplikacji koncentrują się na dwóch obszarach: nadużywaniu luk w aplikacjach, zwłaszcza tych już szeroko rozpowszechnionych i instalowanych, oraz zatruwaniu pakietów u źródła (przed pobraniem). Przykładem tego pierwszego są ataki Log4j, a drugiego – „zatruwanie” pakietu us-parser-js.
Drugi wektor ataku to zhakowane narzędzia. „Umożliwiają hackerom zmianę lub wstrzyknięcie złośliwego kodu podczas procesu kompilacji i manipulowanie aplikacją (jak miało to miejsce w przypadku SolarWinds)” — czytamy w raporcie Argon. „Atakujący używają również rejestrów skompromitowanych pakietów do przesyłania złośliwych artefaktów zamiast legalnych. Ponadto istnieją dziesiątki zewnętrznych zależności, które można wykorzystać do uzyskania dostępu i przeprowadzenia ataków” – takich jak atak Codecov.
Trzecim obszarem ryzyka zidentyfikowanym przez badaczy jest przesyłanie złego kodu do repozytoriów kodu źródłowego. Wpływa to na jakość artefaktu i postawę bezpieczeństwa. Na podstawie wyników badań autorzy raportu zauważają: „W wielu przypadkach liczba wykrytych problemów była przytłaczająca i wymagała dedykowanych projektów czyszczenia w celu zmniejszenia ryzyka, takich jak tajne czyszczenie, standaryzacja obrazów kontenerów i inne działania”.
Powodzenie ataków na łańcuch dostaw oprogramowania typu open source w 2021 r. upewnia nas, że pozostaną one ważną częścią działalności przestępczej – zarówno dla gangów, jak i podmiotów państwowych – przez cały 2022 r. i później. Dlatego tak ważna powinna być standaryzacja bezpieczeństwa produkcji oprogramowania.
Popularne
Jak zmienić nieznane/zapomniane hasło Administratora na Windows?
Jak awaria Azure Front Door rzuciła cień na globalne usługi chmurowe
Jak poznać hasło administratora lub użytkowników logujących się do Twojego komputera?
Czego nie mówi Broadcom? Luka w VMware jest banalna do wykorzystania i korzysta z niej co najmniej jedna grupa hakerska!
Uwaga, administratorzy oraz zespoły bezpieczeństwa Splunk! Sześć krytycznych luk w Splunk Enterprise – analiza i rekomendacje
