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
Od kart perforowanych do hasła. Historia logowania
Jak zoptymalizować budżet na cyberbezpieczeństwo w 2026 roku
Jak zmienić nieznane/zapomniane hasło Administratora na Windows?
Nowy poziom bezpieczeństwa. Android 16 wzmacnia ochronę przed kradzieżą – co to oznacza dla Twojego smartfona?
Uwaga na PDFSider – nowy zaawansowany malware używany przez grupy ransomware
