Jak chronić produkcję oprogramowania?

W zeszłotygodniowym artykule pisaliśmy o bezpieczeństwie kodu systemu – 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 systemu z punktu widzenia bezpieczeństwa, dodawanie funkcji bezpieczeństwa oraz utrzymywanie bezpieczeństwa systemu i infrastruktury bazowej” – pochwalili się autorzy raportu.

Poradnik, który ma mieć zastosowanie do wielu scenariuszy, zawiera praktyczne zalecenia dotyczące bezpiecznego cyklu życia systemu (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ć, iż 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 systemu jest odpowiedzią na ostatnie światowe wydarzenia. Rok 2021 można określić jako rok ataku na łańcuch dostaw systemu – 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, iż pojedyncze naruszenie, kompromitacja lub luka w rozproszonym kodzie może prowadzić do wielu – choćby 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 systemu 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 systemu i zaufania do dostawców celem rozpowszechniania złośliwego systemu 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 systemu typu open source w 2021 r. upewnia nas, iż pozostaną one istotną 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.