ISO 27001 coraz częściej pojawia się jako obowiązkowy wymóg w ramach przetargów na oprogramowanie obronne w całej Europie. To, co kiedyś było pożądanym wyróżnikiem, stało się standardem bazowym: dostawcy bez aktualnej certyfikacji ISO 27001:2022 są wykluczani z list przetargowych jeszcze przed oceną techniczną. Zrozumienie, czego naprawdę wymaga standard — a nie tylko jak wygląda certyfikat — jest niezbędne zarówno dla dostawców ubiegających się o certyfikację, jak i dla oficerów zamówień oceniających oferty.

Niniejszy artykuł analizuje wymagania ISO 27001:2022 w kontekście organizacji zajmujących się tworzeniem oprogramowania, istotne zmiany wprowadzone w rewizji z 2022 roku oraz praktyczne znaczenie certyfikacji dla procesów rozwoju, składu zespołu i realizacji projektów.

Czym jest ISO 27001:2022 i co się zmieniło

ISO 27001 to międzynarodowa norma określająca wymagania dotyczące Systemu Zarządzania Bezpieczeństwem Informacji (SZBI). W przeciwieństwie do technicznych standardów bezpieczeństwa, które nakazują konkretne środki kontroli, ISO 27001 wymaga od organizacji identyfikacji ryzyk bezpieczeństwa informacji, wdrożenia odpowiednich środków kontroli i utrzymania cyklu ciągłego doskonalenia.

Rewizja z 2022 roku zastąpiła ISO 27001:2013 i wprowadziła istotne zmiany do Załącznika A, zawierającego zestaw referencyjnych środków kontroli. Wersja z 2013 roku zawierała 114 środków kontroli w 14 domenach. Wersja z 2022 roku zrestrukturyzowała je do 93 środków kontroli w 4 tematach: środki organizacyjne, personalne, fizyczne i technologiczne. Ponadto wprowadzono 11 nowych środków kontroli bezpośrednio istotnych dla organizacji zajmujących się tworzeniem oprogramowania:

  • Analiza zagrożeń (5.7) — organizacje muszą gromadzić i analizować informacje o zagrożeniach istotnych dla ich kontekstu
  • Bezpieczeństwo informacji przy korzystaniu z usług w chmurze (5.23) — wyraźne wymagania dotyczące zarządzania użytkowaniem chmury
  • Gotowość ICT do zapewnienia ciągłości działania (5.30) — planowanie ciągłości musi uwzględniać zależności ICT
  • Filtrowanie stron internetowych (8.23) — kontrole dostępu systemów do zasobów internetowych
  • Bezpieczne kodowanie (8.28) — formalne wymagania dotyczące praktyk bezpiecznego wytwarzania
  • Maskowanie danych (8.11) — wymagania dotyczące maskowania wrażliwych danych w środowiskach nieprodukcyjnych

Dla dostawców oprogramowania obronnego szczególnie istotny jest środek kontroli 8.28 (Bezpieczne kodowanie). Standard z 2022 roku wymaga teraz wprost, aby organizacje stosowały zasady bezpiecznego kodowania — co oznacza, że praktyki bezpiecznego wytwarzania muszą być udokumentowane, przestrzegane i podlegać audytowi.

Kluczowe środki kontroli istotne dla tworzenia oprogramowania

ISO 27001 nie nakazuje konkretnych technologii ani metodologii wytwarzania. Wymaga strukturalnego podejścia do identyfikacji i zarządzania ryzykami bezpieczeństwa informacji w całym cyklu życia oprogramowania. W praktyce przekłada się to na kilka kategorii wymagań wpływających na funkcjonowanie organizacji.

Kontrola dostępu (8.2–8.5). Standard wymaga zarządzania dostępem do systemów, repozytoriów kodu i infrastruktury wdrożeniowej na zasadzie minimalnych uprawnień. Dla obronnego tworzenia oprogramowania oznacza to, że deweloperzy nie powinni mieć dostępu do środowiska produkcyjnego, przegląd kodu musi kontrolować scalenia do chronionych gałęzi, a uprzywilejowany dostęp do systemów wdrożeniowych musi być ograniczony czasowo i rejestrowany.

Kryptografia (8.24). Organizacje muszą mieć politykę regulującą środki kryptograficzne: które algorytmy są zatwierdzone, jak zarządzane są klucze i kto odpowiada za decyzje kryptograficzne. Dla oprogramowania obronnego zazwyczaj oznacza to zgodność z krajowymi standardami kryptograficznymi.

Bezpieczny cykl życia oprogramowania (8.25–8.31). Standard wymaga integracji bezpieczeństwa w całym procesie wytwarzania: wymagania bezpieczeństwa muszą być określone na etapie projektowania, testy bezpieczeństwa muszą być przeprowadzone przed wydaniem, a zależności muszą być oceniane pod kątem podatności. Wymaga to bezpośrednio takich praktyk jak modelowanie zagrożeń, analiza statyczna, skanowanie podatności zależności i testy penetracyjne.

Zarządzanie incydentami (5.24–5.28). Organizacje muszą posiadać udokumentowane procedury wykrywania, zgłaszania i reagowania na incydenty bezpieczeństwa. Dla środowisk wytwarzania oprogramowania oznacza to monitorowanie anomalnego dostępu do repozytoriów kodu i nieautoryzowanych zmian w konfiguracjach wdrożeniowych.

Uwaga dla zamawiających: Oceniając certyfikaty ISO 27001, należy zawsze weryfikować zakres certyfikacji. Certyfikat obejmujący wyłącznie „siedzibę główną" lub „funkcje administracyjne" nie daje żadnych gwarancji dotyczących środowiska wytwarzania, gdzie faktycznie pisany jest kod. Zakres musi wyraźnie obejmować działalność związaną z wytwarzaniem oprogramowania i wspierającą ją infrastrukturę.

Co faktycznie zmienia się w procesach wytwarzania

Organizacje uzyskujące certyfikację ISO 27001 po raz pierwszy zazwyczaj odkrywają, że wpływ standardu na procesy wytwarzania jest bardziej znaczący niż oczekiwano. Następujące zmiany są konsekwentnie wymagane i konsekwentnie niedoceniane.

Ocena ryzyka staje się udokumentowanym artefaktem. ISO 27001 wymaga identyfikacji, oceny i śledzenia ryzyk bezpieczeństwa informacji. Dla wytwarzania oprogramowania oznacza to prowadzenie rejestru ryzyk obejmującego ryzyka środowiska wytwarzania, ryzyka łańcucha dostaw i ryzyka operacyjne. Rejestr ryzyk nie jest jednorazowym dokumentem — musi być przeglądany i aktualizowany w określonych odstępach czasu.

Punkty kontrolne SDLC stają się obowiązkowymi sprawdzianami. Wymagania bezpieczeństwa muszą być uchwycone na początku każdego cyklu wytwarzania, a testy bezpieczeństwa muszą być przeprowadzone przed wydaniem oprogramowania. Audytorzy będą wymagać wyników testów bezpieczeństwa, a nie tylko zapewnień o ich przeprowadzeniu.

Zarządzanie dostawcami i zależnościami wymaga formalnego podejścia. Standard wymaga, aby wymagania bezpieczeństwa informacji były komunikowane dostawcom i aby relacje z dostawcami były monitorowane. Dla wytwarzania oprogramowania obejmuje to biblioteki open source i komponenty stron trzecich.

Wymagania bezpieczeństwa personalnego wpływają na rekrutację i wdrożenie. ISO 27001 wymaga weryfikacji przeszłości osób, których role wiążą się z dostępem do wrażliwych zasobów informacyjnych. Dla dostawców oprogramowania obronnego może to wymagać zgodności z krajowymi wymogami bezpieczeństwa.

Dlaczego oficerowie zamówień wymagają ISO 27001

Z perspektywy oficera zamówień obronnych certyfikacja ISO 27001 pełni kilka funkcji wykraczających poza same środki kontroli bezpieczeństwa.

Po pierwsze, zapewnia niezależną weryfikację. Certyfikat jest wydawany przez akredytowaną jednostkę trzecią po audycie SZBI organizacji. W przeciwieństwie do ram zgodności opartych na samoocenie, ISO 27001 wymaga, aby wykwalifikowany audytor zbadał dowody wdrożenia środków kontroli. Audyty nadzoru odbywają się corocznie; audyty recertyfikacyjne co trzy lata.

Po drugie, tworzy odpowiedzialność. Certyfikacja ISO 27001 wymaga, aby kierownictwo najwyższego szczebla było widocznie zaangażowane w SZBI. Oznacza to, że organizacja nie może wiarygodnie twierdzić, że naruszenia bezpieczeństwa były incydentami odizolowanymi od kierownictwa.

Po trzecie, upraszcza należytą staranność. Zamiast przeprowadzać szczegółową ocenę bezpieczeństwa każdego potencjalnego dostawcy, ramy zamówień wymagające ISO 27001 mogą używać certyfikatu jako podstawowego filtra. Dostawcy powinni też wiedzieć, że certyfikaty odwołujące się do standardu z 2013 roku po październiku 2025 roku są traktowane jako wygasłe dla celów zamówień.