⚡ LIMITED TIME Get our FREE €500+ Compliance Starter Kit
Get It Now →

Migracja do kryptografii postkwantowej z wykorzystaniem ISO 27001

Igor Petreski
15 min read
Mapa drogowa migracji do kryptografii postkwantowej odwzorowana na zabezpieczenia ISO 27001 i NIST

Szum projektora jest jedynym dźwiękiem w sali posiedzeń zarządu. Sarah, pełniąca funkcję CISO, właśnie zakończyła kwartalną aktualizację ryzyk, gdy prezes zarządu podnosi wydruk artykułu z serwisu finansowego. Nagłówek jest bezpośredni: „Kwantowe odliczanie: czy Twoje dane są już przestarzałe?”

„Sarah” — mówi, bardziej z autentyczną troską niż oskarżycielsko — „wydaliśmy miliony na szyfrowanie. Mamy zgodność. Jesteśmy bezpieczni. Ten artykuł twierdzi, że wystarczająco silny komputer kwantowy mógłby to wszystko złamać. Czy jesteśmy narażeni? Co z danymi, które szyfrujemy i przechowujemy już teraz? Czy to tykająca bomba?”

To rozmowa, która przenosi się dziś z konferencji bezpieczeństwa do komitetów wykonawczych. Problemem nie jest już to, czy komputery kwantowe są interesujące dla badaczy. Problemem jest to, czy dzisiejsze decyzje kryptograficzne będą chronić jutrzejsze zobowiązania biznesowe.

Dla wielu organizacji uczciwa odpowiedź jest niewygodna. Szyfrowanie jest wszędzie: bramy TLS, VPN, portale klientów, tokeny tożsamości, kopie zapasowe baz danych, aplikacje mobilne, platformy płatnicze, S/MIME, SSH, integracje API, usługi SaaS, sprzętowe moduły bezpieczeństwa (HSM), chmurowe usługi zarządzania kluczami, podpisywanie oprogramowania układowego, podpisywanie kodu i umowy cyfrowe.

Na tym polega problem. Kryptografia jest wszędzie, ale często nigdzie nie wskazano jej właściciela.

Migracja do kryptografii postkwantowej nie dotyczy wyłącznie przyszłego, kryptograficznie istotnego komputera kwantowego. Dotyczy również dzisiejszego ryzyka „zbierz teraz, odszyfruj później”, w którym przeciwnicy przechwytują zaszyfrowane dane już dziś i czekają, aż przyszłe możliwości pozwolą na ich praktyczne odszyfrowanie. Jeżeli organizacja przechowuje dane osobowe, dokumentację medyczną, dane finansowe objęte regulacjami, tajemnice przedsiębiorstwa, komunikację prawną, dane infrastruktury krajowej, oprogramowanie układowe produktów albo długookresową własność intelektualną, ryzyko już dziś ma charakter ryzyka cyklu życia.

Plan migracji kryptograficznej odporny na zagrożenia kwantowe nie jest projektem paniki. To uporządkowany program nadzoru, inwentaryzacji, zarządzania dostawcami, architektury, testowania i audytu. Praktyczne pytanie dla CISO jest proste:

Jak zbudować plan migracji postkwantowej, który będzie wiarygodny dla kierownictwa, użyteczny dla inżynierów i możliwy do obrony przed audytorami?

Odpowiedź polega na osadzeniu prac w ISO/IEC 27001:2022, interpretowaniu zabezpieczeń przez pryzmat ISO/IEC 27002:2022, wykorzystaniu standardów kryptografii postkwantowej NIST jako technicznego kompasu oraz stworzeniu jednego modelu dowodowego wspierającego obowiązki wynikające z ISO 27001, NIST, COBIT 2019, GDPR, DORA i NIS2.

Dlaczego kryptografia postkwantowa należy do SZBI

Częstym błędem jest przypisanie migracji postkwantowej wyłącznie inżynierom kryptografii. Inżynierowie są niezbędni, ale sami nie rozwiążą problemu zarządczego.

Migracja postkwantowa obejmuje zarządzanie aktywami, klasyfikację danych, zarządzanie dostawcami, bezpieczną architekturę, zarządzanie kluczami, rozwój aplikacji, bezpieczeństwo chmury, reagowanie na incydenty, ciągłość działania, ryzyko prawne, odpowiedzialność regulacyjną oraz dowody audytowe. Są to obszary SZBI.

ISO/IEC 27001:2022 zapewnia ramy zarządzania. Wymaga, aby organizacja rozumiała kontekst, strony zainteresowane, ryzyka, cele, odpowiedzialności, kompetencje, udokumentowane informacje, planowanie operacyjne, ocenę wyników, audyt wewnętrzny, przegląd zarządzania oraz ciągłe doskonalenie. ISO/IEC 27002:2022 zapewnia następnie interpretację zabezpieczeń, szczególnie w obszarach 8.24 Use of cryptography, 5.9 Inventory of information and other associated assets, 5.12 Classification of information, 5.21 Managing information security in the ICT supply chain, 5.23 Information security for use of cloud services, 8.25 Secure development life cycle, 8.8 Management of technical vulnerabilities, 8.16 Monitoring activities oraz 5.30 ICT readiness for business continuity.

W Clarysec gotowość postkwantowa jest dlatego traktowana jako transformacja prowadzona w ramach SZBI, a nie jako izolowana wymiana algorytmów.

Jak wskazano w materiale Clarysec Zenith Blueprint: 30-etapowa mapa drogowa audytora, faza 2, krok 8, „Określenie zakresu aktywów, zależności i dowodów”:

„Zabezpieczeniu nie można ufać, dopóki organizacja nie potrafi wykazać, gdzie ma zastosowanie, kto jest jego właścicielem, jakie dowody je wspierają i jakie ryzyko ogranicza.”

To zdanie jest szczególnie ważne dla kryptografii postkwantowej. Zanim wymienisz algorytmy, musisz wiedzieć, gdzie są używane.

Materiał Clarysec Zenith Controls: przewodnik po zgodności przekrojowej ujmuje kryptografię jako powiązany łańcuch dowodowy, a nie pojedyncze ustawienie techniczne:

„Zapewnienie skuteczności zabezpieczeń kryptograficznych jest audytowane przez cały cykl życia informacji: identyfikację, klasyfikację, zatwierdzone użycie, ochronę kluczy, monitorowanie operacyjne, zależność od dostawcy, obsługę wyjątków i okres przechowywania dowodów.”

Takie spojrzenie na cykl życia zapobiega najczęstszej porażce: zadawaniu wyłącznie pytania „Czy używamy algorytmów bezpiecznych kwantowo?”. Lepsze pytania brzmią:

  • Które systemy wymagają migracji postkwantowej w pierwszej kolejności?
  • Które dane wymagają poufności przez okres dłuższy niż horyzont ryzyka kwantowego?
  • Którzy dostawcy kontrolują nasze szyfrowanie, podpisy, certyfikaty lub zarządzanie kluczami?
  • Które aplikacje zapewniają zwinność kryptograficzną, a które mają twardo zakodowane mechanizmy?
  • Jakie zabezpieczenia kompensujące istnieją do czasu zakończenia migracji?
  • Jakie dowody wykażą, że decyzje były oparte na ryzyku i podlegały przeglądowi?

Od zagrożenia kwantowego do audytowalnego ryzyka biznesowego

Użyteczny plan postkwantowy zaczyna się od scenariuszy ryzyka. Należy unikać ogólnych stwierdzeń typu „komputery kwantowe mogą złamać szyfrowanie”. Zamiast tego należy tworzyć audytowalne zapisy ryzyka, które łączą wpływ biznesowy, zagrożenie, podatność, aktywa objęte wpływem, obecne zabezpieczenia, ryzyko szczątkowe oraz działania w zakresie postępowania z ryzykiem.

Na przykład:

„Zaszyfrowane dokumenty tożsamości klientów przechowywane przez siedem lat mogą być podatne na przyszłe odszyfrowanie, jeżeli kopie zapasowe zostaną dziś wyeksfiltrowane, a obecna kryptografia klucza publicznego stanie się w przyszłości możliwa do złamania.”

Ten scenariusz wskazuje na okres przechowywania danych, szyfrowanie kopii zapasowych, zarządzanie kluczami, kontrolę dostępu, hosting u dostawcy, monitorowanie oraz priorytet migracji.

Inny przykład:

„Podpisywanie oprogramowania układowego dla urządzeń połączonych opiera się na schematach podpisu, które mogą nie pozostać wiarygodne przez oczekiwany cykl życia urządzenia.”

To wskazuje na bezpieczeństwo produktu, bezpieczne mechanizmy aktualizacji, możliwości HSM, bezpieczeństwo klientów, zapewnienie jakości projektu po stronie dostawcy oraz długoterminową odporność operacyjną.

Trzeci przykład:

„Zarchiwizowana komunikacja prawna zaszyfrowana dziś może wymagać poufności przez ponad piętnaście lat, tworząc ekspozycję typu „zbierz teraz, odszyfruj później”.”

To wskazuje na klasyfikację, okres przechowywania, ochronę kryptograficzną, zabezpieczenie prawne, bezpieczną komunikację oraz akceptację ryzyka przez kadrę kierowniczą.

Ryzyko nie ogranicza się do przyszłego „Q-Day”. Obejmuje trzy powiązane zagadnienia:

  1. Zbierz teraz, odszyfruj później — przeciwnicy gromadzą dziś zaszyfrowane dane w celu ich przyszłego odszyfrowania.
  2. Kompromitacja podpisów cyfrowych — przyszłe ataki podważają zaufanie do aktualizacji oprogramowania, tokenów tożsamości, dokumentów prawnych, oprogramowania układowego i transakcji finansowych.
  3. Nieskuteczność wynikająca z koncentracji kryptograficznej — szeroka klasa produktów, protokołów, bibliotek lub dostawców staje się przestarzała w tym samym czasie.

Polityka korporacyjna Clarysec Polityka kryptografii i zarządzania kluczami, klauzula 5.1, ujmuje wymaganie zarządcze następująco:

„Zabezpieczenia kryptograficzne muszą być wybierane, wdrażane, przeglądane i wycofywane na podstawie klasyfikacji informacji, wymaganego czasu ochrony, zatwierdzonych standardów kryptograficznych, własności kluczy oraz udokumentowanych decyzji dotyczących postępowania z ryzykiem.”

Ta klauzula jest krytyczna, ponieważ wymagany czas ochrony staje się czynnikiem priorytetyzacji. Krótkotrwałe dane sesyjne i długoterminowa dokumentacja medyczna nie niosą tego samego ryzyka kwantowego. Klucz do podpisywania kodu, który podtrzymuje zaufanie do urządzenia przez piętnaście lat, ma inny profil ryzyka niż krótkotrwały wewnętrzny certyfikat testowy.

Ta sama rodzina polityk, określana w materiałach Clarysec jako Polityka zabezpieczeń kryptograficznych, może również formalizować oczekiwania dotyczące przeglądów poprzez następujące brzmienie:

Klauzula 5.4: Standardy algorytmów i długości kluczy
„Wszystkie algorytmy kryptograficzne i długości kluczy używane w organizacji muszą być wybierane z zatwierdzonej listy utrzymywanej przez zespół ds. bezpieczeństwa informacji. Lista ta musi być przeglądana corocznie pod kątem najlepszych praktyk branżowych oraz wytycznych krajowych organów cyberbezpieczeństwa (np. NIST, ENISA), ze szczególnym uwzględnieniem rozwoju postkwantowych standardów kryptograficznych. Mapa drogowa migracji systemów z algorytmów podatnych na ataki oparte na technologiach kwantowych musi być utrzymywana jako część inwentarza aktywów kryptograficznych.”

Nie wymaga to niebezpiecznego, przedwczesnego wdrożenia. Wymaga świadomości, planowania, przeglądu i dowodów.

Wykorzystaj standardy NIST PQC jako techniczny kompas

Prace NIST nad kryptografią postkwantową dają organizacjom wiarygodny kierunek techniczny. NIST ustandaryzował ML-KEM do ustanawiania kluczy, ML-DSA do podpisów cyfrowych oraz SLH-DSA do bezstanowych podpisów opartych na funkcjach skrótu. Standardy te dają dostawcom i architektom podstawę do tworzenia map drogowych oraz projektów pilotażowych.

Dla CISO celem nie jest zapamiętywanie szczegółów algorytmów. Celem jest stworzenie ścieżki migracji, która pozwoli przyjmować zatwierdzone rozwiązania kryptograficzne bez naruszania usług biznesowych, zobowiązań dotyczących zgodności ani identyfikowalności audytowej.

Plan migracji zgodny z kierunkiem NIST powinien obejmować cztery ścieżki:

  1. Odkrywanie — identyfikację miejsc występowania podatnej kryptografii klucza publicznego.
  2. Priorytetyzację — uszeregowanie systemów według wrażliwości danych, wymaganego czasu ochrony, ekspozycji, wpływu na integralność i krytyczności biznesowej.
  3. Architekturę przejściową — określenie, gdzie będą testowane i przyjmowane mechanizmy hybrydowe, zapewniające zwinność kryptograficzną lub postkwantowe.
  4. Zapewnienie — wytworzenie dowodów, że decyzje, wyjątki, zależności od dostawców, testy i ryzyka szczątkowe są kontrolowane.

Szczególnej uwagi wymaga zwinność kryptograficzna. System zwinny kryptograficznie może zmieniać algorytmy, rozmiary kluczy, biblioteki, certyfikaty i protokoły bez istotnego przeprojektowania. W erze postkwantowej nie jest to luksus. To wymóg odporności.

Jeżeli API płatnicze ma twardo zakodowane biblioteki kryptograficzne i nie ma udokumentowanego właściciela, nie jest zwinne kryptograficznie. Jeżeli aplikacja mobilna stosuje przypinanie certyfikatów bez zarządzanej ścieżki aktualizacji, migracja może stać się kosztowna. Jeżeli urządzenie IoT ma piętnastoletni czas pracy w terenie i nie obsługuje większych podpisów ani bezpiecznych aktualizacji oprogramowania układowego, ryzyko ma charakter strategiczny.

Zbuduj inwentarz kryptograficzny przed wyborem ścieżki migracji

Większość organizacji nie posiada kompletnego inwentarza kryptograficznego. Mogą mieć inwentarz certyfikatów, arkusz kalkulacyjny do zarządzania kluczami, zapisy HSM, listę chmurowego KMS albo wpisy w CMDB. Rzadko mają jednak jeden widok zależności kryptograficznych.

Plan migracji do kryptografii postkwantowej wymaga kryptograficznego wykazu komponentów, czyli CBOM. Nie musi być doskonały pierwszego dnia. Musi jednak być ustrukturyzowany, mieć właściciela i być stale doskonalony.

Co najmniej należy ująć następujące pola:

Pole inwentarzaDlaczego ma znaczenie dla migracji postkwantowej
Usługa biznesowaPriorytetyzuje migrację według wpływu biznesowego
Właściciel aktywaPrzypisuje rozliczalność i uprawnienia decyzyjne
Klasyfikacja danychIdentyfikuje wymagania dotyczące poufności i integralności
Wymagany czas ochronyUjawnia ekspozycję typu „zbierz teraz, odszyfruj później”
Funkcja kryptograficznaRozdziela szyfrowanie, wymianę kluczy, podpisy, haszowanie i certyfikaty
Algorytm i protokółIdentyfikuje miejsca użycia podatnych mechanizmów klucza publicznego
Biblioteka lub implementacjaPokazuje zależności programowe i ograniczenia aktualizacji
Lokalizacja kluczyPokazuje, czy klucze znajdują się w HSM, chmurowym KMS, oprogramowaniu, punkcie końcowym lub platformie dostawcy
Zależność od dostawcyUjawnia, gdzie migracja zależy od stron trzecich
Złożoność migracjiWspiera sekwencjonowanie, testowanie i planowanie budżetu
Źródło dowodówSprawia, że inwentarz jest gotowy do audytu

Początkowy inwentarz może wyglądać następująco:

Identyfikator aktywaNazwa aktywaWłaścicielKrytyczność biznesowaUżycie kryptografiiLokalizacjaEkspozycja postkwantowaPriorytet migracji
APP-042API rozliczeń klientówZespół technologii finansowychWysokaPodpisy RSA-2048, TLS, szyfrowanie AES-256AWS eu-west-1Wysoka dla zaufania zależnego od RSA1
NET-007VPN dostępu zdalnegoInfrastruktura ITWysokaUwierzytelnianie ECDSA, IKEv2Infrastruktura lokalna i brzeg chmurowyWysoka dla uwierzytelniania zależnego od ECC1
DB-011Zarchiwizowana dokumentacja pacjentówZgodnośćWysoka przy 30-letnim okresie przechowywaniaSzyfrowanie bazy danych AES-256Lokalna baza danychNiższa dla szyfrowania symetrycznego; wysoka, jeżeli klucze są wymieniane lub opakowywane podatnymi metodami klucza publicznego2
CODE-001Podpisywanie kodu CI/CDDevOpsWysoki wpływ na integralnośćPodpisywanie kodu RSA-4096HSM i potok budowaniaWysoka dla długoterminowego zaufania do podpisów1

Ta tabela natychmiast pokazuje, dlaczego inwentarz ma znaczenie. AES-256 nie jest takim samym rodzajem ryzyka kwantowego jak RSA lub ECC, ale zarchiwizowana dokumentacja pacjentów może nadal zależeć od podatnego opakowywania kluczy, certyfikatów, systemów tożsamości lub kanałów transferu kopii zapasowych. Podpisywanie kodu może nie chronić poufności, ale chroni integralność oprogramowania i zaufanie.

W Zenith Controls kryptografia jest krzyżowo powiązana ze standardami wspierającymi, które zapewniają dodatkową głębię. ISO/IEC 27005 wspiera zarządzanie ryzykiem bezpieczeństwa informacji i pomaga przełożyć niepewność kwantową na ustrukturyzowane scenariusze ryzyka. ISO/IEC 27017 wspiera zabezpieczenia specyficzne dla chmury, co jest niezbędne, gdy usługi kryptograficzne są dostarczane przez chmurowy KMS, zarządzany TLS, szyfrowanie SaaS lub certyfikaty platformowe. ISO/IEC 27018 ma znaczenie, gdy dane osobowe są przetwarzane w publicznych usługach chmurowych. ISO 22301 ma znaczenie tam, gdzie awaria kryptografii mogłaby wpływać na ciągłość usług krytycznych. ISO/IEC 27036 wspiera bezpieczeństwo relacji z dostawcami, co jest kluczowe, gdy dostawcy zarządzają szyfrowaniem, podpisami, certyfikatami lub bezpieczną komunikacją w imieniu organizacji.

Wniosek jest prosty: nie da się migrować tego, czego nie można znaleźć.

Priorytetyzuj według wrażliwości, czasu ochrony, ekspozycji i trudności migracji

Gdy CBOM istnieje, priorytetyzacja staje się oparta na dowodach. Najlepszym punktem wyjścia jest niewielka liczba systemów krytycznych, a nie próba osiągnięcia doskonałości w całej organizacji.

Wyobraźmy sobie firmę z sektora usług finansowych z trzema systemami o wysokiej wartości:

  • repozytorium dokumentów klientów przechowujące dowody tożsamości przez dziesięć lat,
  • bramę API B2B obsługującą transakcje z partnerami,
  • platformę podpisywania kodu dla aktualizacji oprogramowania desktopowego.

Korzystając z Zenith Blueprint, faza 2, krok 8, zespół pozyskuje aktywa z CMDB, certyfikaty z platformy zarządzania certyfikatami, klucze z HSM i chmurowego KMS, klasy danych z rejestru prywatności oraz zależności od dostawców z zapisów zakupowych.

Następnie ocenia systemy:

SystemWrażliwość danychWymagany czas ochronyEkspozycja zewnętrznaZależność od dostawcyPriorytet migracji
Repozytorium dokumentów klientówBardzo wysokaDługiŚredniaChmurowy KMS i dostawca przechowywaniaKrytyczny
Brama API B2BWysokaKrótki do średniegoBardzo wysokaDostawca zarządzania APIWysoki
Platforma podpisywania koduBardzo wysoki wpływ na integralnośćDługoterminowe zaufanie do urządzeńŚredniaHSM i narzędzia potoku budowaniaKrytyczny

Repozytorium dokumentów klientów staje się priorytetem ze względu na czas wymaganej poufności. Platforma podpisywania kodu staje się priorytetem, ponieważ zaufanie do podpisów wpływa na integralność oprogramowania i bezpieczeństwo klientów. Brama API ma wysoki priorytet ze względu na ekspozycję zewnętrzną, ale przechowywane przez nią dane mogą wymagać krótszego okresu poufności.

Rejestr ryzyk powinien następnie powiązać każdy scenariusz z postępowaniem z ryzykiem i dowodami:

Scenariusz ryzykaObecne zabezpieczenieDecyzja dotycząca postępowania z ryzykiemWymagane dowody
Długookresowe rejestry klientów mogą być narażone na przyszłe odszyfrowanieSzyfrowanie danych w spoczynku, kontrola dostępu, chmurowy KMSOcenić mapę drogową szyfrowania pamięci masowej, wzmocnić separację kluczy, przejrzeć kryptografię transferu kopii zapasowychCBOM, mapa drogowa dostawcy, decyzja architektoniczna, zapis postępowania z ryzykiem
Zaufanie do aktualizacji oprogramowania może zostać osłabione przez przyszłą kompromitację podpisówHSM do podpisywania kodu, zatwierdzanie wydańOcenić gotowość do podpisów postkwantowych, strategię znakowania czasem oraz cykl życia podpisywaniaInwentarz podpisywania, raport możliwości HSM, procedura bezpiecznego rozwoju oprogramowania
Kryptografia API partnerów może być trudna do szybkiej zmianyCertyfikaty TLS, konfiguracja bramy APIWdrożyć testowanie zwinności kryptograficznej oraz przegląd mapy drogowej dostawcySkan TLS, konfiguracja bazowa, oświadczenie dostawcy

Polityka korporacyjna Clarysec Polityka bezpiecznego rozwoju oprogramowania, klauzula 6.4, przedstawia perspektywę dostarczania oprogramowania:

„Przeglądy projektu bezpieczeństwa muszą oceniać zależności kryptograficzne, cykl życia bibliotek, elastyczność algorytmiczną, postępowanie z sekretami, mechanizmy aktualizacji oraz komponenty kontrolowane przez dostawców przed zatwierdzeniem do środowiska produkcyjnego.”

Ta klauzula przekształca gotowość postkwantową w wymaganie inżynieryjne. Zapobiega wdrażaniu przez zespoły nowych systemów, których nie będzie można później migrować.

Realizuj 12-miesięczną mapę drogową zrozumiałą dla audytorów

W wielu organizacjach migracja postkwantowa potrwa lata. Pierwszy rok powinien przeprowadzić organizację od niepewności do zarządzanej migracji.

MiesiącStrumień pracWynikDowody
1Mandat kadry kierowniczejZakres na poziomie zarządu, apetyt na ryzyko i ścieżka finansowaniaProtokoły komitetu sterującego, zatwierdzona karta programu
1 do 2Odkrywanie kryptograficznePoczątkowy CBOM obejmujący usługi krytyczneEksport inwentarza, powiązania z CMDB, oświadczenia właścicieli systemów
2 do 3Przegląd danych i wymaganego czasu ochronySpriorytetyzowana lista długookresowych danych wrażliwych i aktywów o wysokim wpływie na integralnośćRejestr klasyfikacji, harmonogram okresów przechowywania, zapisy ryzyka
3 do 4Przegląd zależności od dostawcówMapa drogowa dostawcy i analiza luk kontraktowychKwestionariusze dostawców, klauzule umowne, wyjątki od ryzyka
4 do 6Ocena architektury i zwinności kryptograficznejDocelowe wzorce architektoniczne i ograniczenia migracjiZapisy przeglądów architektury, decyzje projektowe
6 do 8Wdrożenie pilotażoweTest hybrydowy lub postkwantowy w wybranym środowisku niskiego ryzykaWyniki testów, plan wycofania zmian, ustalenia dotyczące wydajności
8 do 10Aktualizacja polityk i procedurZaktualizowane zasady dotyczące kryptografii, zarządzania kluczami, dostawców, bezpiecznego rozwoju oprogramowania i aktywówZatwierdzone polityki, zapisy szkoleń
10 do 12Gotowość do audytuAudyt wewnętrzny, przegląd zarządzania i odświeżenie planu postępowania z ryzykiemRaport z audytu, działania korygujące, zaktualizowany plan postępowania z ryzykiem

W Zenith Blueprint, faza 3, krok 14, „Projektowanie postępowania z ryzykiem i własność”, mapa drogowa ostrzega przed niefinansowanymi intencjami bezpieczeństwa:

„Plan postępowania z ryzykiem bez właściciela, oczekiwań dowodowych, ścieżki budżetowej i daty przeglądu nie jest planem. To nierozwiązane ryzyko z lepszym formatowaniem.”

Właśnie w ten sposób programy postkwantowe zawodzą. Produkują slajdy uświadamiające, ale nie tworzą backlogu działań naprawczych z przypisanymi właścicielami. Omawiają algorytmy, ale nie aktualizują umów z dostawcami. Dokumentują ryzyko, ale nie testują wzorców migracyjnych.

Wiarygodna mapa drogowa tworzy zapisy decyzji, właścicieli, zależności, oczekiwania dowodowe, budżety i daty przeglądów.

Włącz dostawców do programu na wczesnym etapie

Wiele zależności kryptograficznych jest realizowanych w modelu outsourcingu. Dostawcy chmurowi terminują TLS. Platformy SaaS szyfrują rejestry. Dostawcy tożsamości podpisują tokeny. Procesory płatnicze zarządzają certyfikatami. Dostawcy sprzętu kontrolują podpisywanie oprogramowania układowego. Dostawcy usług zarządzanych obsługują VPN i bramy bezpieczeństwa.

Nawet jeżeli wewnętrzny zespół jest gotowy, migracja może zostać zablokowana przez możliwości dostawców.

Polityka korporacyjna Clarysec Polityka bezpieczeństwa dostawców i stron trzecich, klauzula 5.6, stanowi:

„Dostawcy świadczący usługi istotne dla bezpieczeństwa muszą ujawniać istotne zależności, odpowiedzialności kryptograficzne, dowody zapewnienia, procesy obsługi podatności oraz zmiany w mapie drogowej, które mogą wpływać na profil ryzyka organizacji.”

W kontekście gotowości postkwantowej należy zapytać dostawców krytycznych:

  • Jakie algorytmy, protokoły, certyfikaty i usługi zarządzania kluczami chronią nasze dane lub transakcje?
  • Czy utrzymujecie inwentarz kryptograficzny lub CBOM?
  • Jaka jest Wasza mapa drogowa postkwantowa zgodna z NIST?
  • Czy będziecie wspierać hybrydową wymianę kluczy, podpisy postkwantowe lub odporne na zagrożenia kwantowe ustanawianie kluczy?
  • Jak będą komunikowane zmiany dotyczące certyfikatów, tokenów, podpisywania i szyfrowania?
  • Jakie działania będą wymagane po stronie klienta?
  • Jakie środowiska testowe będą dostępne?
  • Jak będą obsługiwane wydajność, interoperacyjność i wycofanie zmian?
  • Czy odpowiedzialności kryptograficzne są zdefiniowane w umowie lub modelu współdzielonej odpowiedzialności?
  • Jakie opcje wyjścia lub przenoszalności istnieją, jeżeli Wasza mapa drogowa nie spełni naszych wymagań dotyczących ryzyka?

Odpowiedzi dostawców powinny zasilać rejestr ryzyk. Słabe odpowiedzi nie zawsze oznaczają konieczność natychmiastowej wymiany, ale wymagają postępowania z ryzykiem. Mogą być potrzebne zabezpieczenia kompensujące, aneksy do umów, klauzule powiadomień, planowanie wyjścia, wzmocnione monitorowanie albo zmieniona strategia zakupowa.

Jest to szczególnie istotne w świetle oczekiwań dotyczących odporności operacyjnej w DORA i NIS2. DORA kładzie nacisk na zarządzanie ryzykiem ICT i zarządzanie ryzykiem stron trzecich ICT, w tym nadzór nad krytycznymi zależnościami. NIS2 Article 21 wymaga odpowiednich i proporcjonalnych technicznych, operacyjnych oraz organizacyjnych środków zarządzania ryzykiem bezpieczeństwa, w tym bezpieczeństwa łańcucha dostaw, obsługi incydentów, ciągłości działania oraz kryptografii tam, gdzie jest to właściwe. GDPR Article 32 wymaga bezpieczeństwa odpowiedniego do ryzyka, obejmującego poufność, integralność, dostępność, odporność oraz zdolność do zapewnienia ciągłej ochrony danych osobowych.

Język regulacyjny jest różny, ale logika zabezpieczeń pozostaje spójna: znaj swoje zależności, zarządzaj ryzykiem, zachowuj dowody i działaj, zanim odporność zostanie naruszona.

Mapowanie zgodności przekrojowej: jeden plan migracji, wiele obowiązków

Silny plan migracji do kryptografii postkwantowej powinien unikać tworzenia oddzielnych pakietów dowodowych dla każdych ram. Te same podstawowe dowody mogą wspierać wiele obowiązków, jeżeli są właściwie ustrukturyzowane.

Zenith Controls mapuje temat kryptografii na ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIST, COBIT 2019, GDPR, DORA i NIS2, koncentrując się na celu zabezpieczenia, a nie na etykiecie używanej przez dane ramy.

RamyJak plan postkwantowy wspiera zgodność
ISO/IEC 27001:2022Wykazuje dobór zabezpieczeń oparty na ryzyku, udokumentowane informacje, audyt wewnętrzny, przegląd zarządzania i ciągłe doskonalenie
ISO/IEC 27002:2022Wspiera interpretację zabezpieczeń dla 8.24 Use of cryptography, inwentarza aktywów, klasyfikacji, bezpieczeństwa dostawców, usług chmurowych, bezpiecznego rozwoju oprogramowania, monitorowania i ciągłości
Standardy NIST PQCZapewniają kierunek techniczny dla przejścia na zatwierdzone algorytmy postkwantowe i planowania kryptograficznego
NIST Cybersecurity Framework 2.0Łączy działania migracyjne z wynikami Govern, Identify, Protect, Detect, Respond i Recover
COBIT 2019Dostosowuje ryzyko kryptograficzne do celów zarządzania i nadzoru, takich jak APO12 Managed Risk, APO13 Managed Security, APO10 Managed Vendors, DSS05 Managed Security Services oraz MEA03 Managed Compliance
GDPRWspiera oczekiwania Article 32 dotyczące odpowiedniego bezpieczeństwa, poufności, integralności, odporności i rozliczalności przetwarzania danych osobowych
DORAWspiera zarządzanie ryzykiem ICT, zarządzanie ryzykiem stron trzecich ICT, testowanie odporności, gotowość do incydentów i nadzór organu zarządzającego
NIS2Wspiera środki zarządzania ryzykiem bezpieczeństwa z Article 21, bezpieczeństwo łańcucha dostaw, obsługę incydentów, ciągłość działania i rozliczalność zarządczą

Kluczowe jest ponowne wykorzystanie dowodów. Inwentarz kryptograficzny wspiera zarządzanie aktywami ISO, wyniki Identify w NIST, widoczność aktywów ICT w DORA, zarządzanie ryzykiem NIS2 oraz rozliczalność GDPR. Kwestionariusze dostawców wspierają zabezpieczenia ISO dotyczące dostawców, ryzyko stron trzecich ICT w DORA, bezpieczeństwo łańcucha dostaw NIS2 oraz nadzór nad dostawcami w COBIT. Wyniki testów migracyjnych wspierają bezpieczną zmianę, testowanie odporności, gotowość do audytu i przegląd zarządzania.

O co zapytają audytorzy

Kryptografia postkwantowa nadal jest wyłaniającym się tematem audytowym, ale audytorzy już dziś mają wystarczające oczekiwania kontrolne, aby zadawać trudne pytania.

Audytor ISO/IEC 27001:2022 zwykle zacznie od ryzyka. Zapyta, czy ryzyko kryptograficzne związane z technologiami kwantowymi zostało zidentyfikowane, ocenione, objęte postępowaniem, monitorowane i przeglądane w ramach SZBI. Będzie oczekiwał dowodów, że zabezpieczenia kryptograficzne są dobierane na podstawie ryzyka biznesowego, a odpowiedzialności są zdefiniowane.

Asesor zorientowany na NIST może skupić się na widoczności aktywów, mechanizmach ochrony, ryzyku łańcucha dostaw, zarządzaniu podatnościami i wynikach zarządzania. Może zapytać, czy organizacja zidentyfikowała systemy używające podatnej kryptografii klucza publicznego oraz czy planowanie migracji jest zgodne z kierunkiem NIST.

Audytor COBIT lub ISACA często zapyta o nadzór. Kto jest rozliczalny? W jaki sposób zarząd otrzymuje raporty? Czy inwestycje są priorytetyzowane? Czy zależności od dostawców są zarządzane? Czy korzyści, ryzyka i zasoby są zrównoważone?

Audytor prywatności może skupić się na tym, czy szyfrowanie i zarządzanie kluczami pozostają odpowiednie do wrażliwości i okresu przechowywania danych osobowych.

Osoba prowadząca przegląd z perspektywy DORA lub NIS2 będzie analizować odporność, koncentrację stron trzecich ICT, ciągłość operacyjną oraz gotowość do incydentów.

Perspektywa audytuPrawdopodobne pytaniaDowody do przygotowania
ISO/IEC 27001:2022Czy ryzyko postkwantowe jest uwzględnione w procesie zarządzania ryzykiem SZBI? Czy zabezpieczenia kryptograficzne są wybierane i przeglądane?Rejestr ryzyk, plan postępowania z ryzykiem, Deklaracja stosowania, zatwierdzenia polityk, wyniki audytu wewnętrznego
NISTCzy organizacja zinwentaryzowała wykorzystanie kryptografii i zaplanowała migrację w kierunku zatwierdzonych podejść?CBOM, decyzje architektoniczne, wyniki pilotażu, backlog migracyjny
COBIT 2019Czy przejście kryptograficzne jest zarządzane, finansowane i monitorowane?Raporty dla zarządu, protokoły organów zarządczych, KPI, panele ryzyka dostawców
GDPRCzy ochrona kryptograficzna pozostaje odpowiednia do wrażliwości i okresu przechowywania danych osobowych?Klasyfikacja danych, odniesienia do DPIA, harmonogram okresów przechowywania, projekt szyfrowania
DORACzy zależności ICT i zależności od dostawców są rozumiane i odporne?Rejestr aktywów ICT, oświadczenia dostawców, dowody testów, plany wyjścia
NIS2Czy środki zarządzania ryzykiem łańcucha dostaw i bezpieczeństwa są skuteczne?Przeglądy dostawców, procedury incydentowe, plany ciągłości, zapisy postępowania z ryzykiem

Zenith Controls zaleca traktowanie przygotowania do audytu jako ścieżki dowodowej. Nie czekaj, aż audytorzy poproszą o zrzuty ekranu i arkusze kalkulacyjne. Zbuduj przestrzeń roboczą GRC, która łączy każde ryzyko kryptograficzne z jego właścicielem, aktywami objętymi wpływem, dostawcami, decyzjami, testami, wyjątkami i datami przeglądu.

Zaktualizuj polityki, aby program stał się operacyjny

Większość polityk kryptograficznych została napisana z myślą o tradycyjnych wymaganiach dotyczących poufności i integralności. Migracja postkwantowa wymaga ukierunkowanych uzupełnień.

Polityka kryptografii i zarządzania kluczami powinna obejmować zatwierdzone standardy, częstotliwość przeglądów, klasyfikację danych, wymagany czas ochrony, zwinność kryptograficzną, generowanie kluczy, przechowywanie kluczy, rotację, niszczenie, własność, cykl życia certyfikatów, odpowiedzialność za HSM, odpowiedzialność za chmurowy KMS, zatwierdzanie wyjątków, kryptografię kontrolowaną przez dostawców oraz monitorowanie przejścia postkwantowego.

Polityka bezpiecznego rozwoju oprogramowania powinna obejmować zatwierdzanie bibliotek kryptograficznych, zakaz stosowania twardo zakodowanych algorytmów bez przeglądu, śledzenie zależności, bezpieczne mechanizmy aktualizacji, testy wydajności dla większych kluczy lub podpisów, kompatybilność wsteczną, wycofanie zmian oraz modelowanie zagrożeń dla produktów o długim cyklu życia.

Polityka bezpieczeństwa dostawców powinna obejmować transparentność kryptograficzną, wnioski o mapy drogowe postkwantowe, umowne obowiązki powiadamiania, współdzieloną odpowiedzialność za szyfrowanie i zarządzanie kluczami, planowanie wyjścia oraz przenoszalność.

Procedura zarządzania aktywami powinna obejmować pola inwentarza kryptograficznego, własność, źródła dowodów, częstotliwość przeglądów oraz integrację z CMDB, inwentarzem chmurowym, zarządzaniem certyfikatami, zapisami HSM i repozytoriami kodu.

W tym miejscu biblioteka polityk Clarysec pomaga organizacjom działać szybciej. Zamiast pisać od pustej strony, zespoły mogą dostosować klauzule polityk do procedur, rejestrów, kwestionariuszy i dowodów audytowych.

Unikaj najczęstszych błędów w migracji postkwantowej

Najgroźniejsze błędy są zwykle błędami zarządzania, a nie błędami technicznymi.

Rozpoczynanie od algorytmów zamiast od aktywów. Jeżeli nie wiesz, gdzie używana jest kryptografia, wybór algorytmu nie pomoże.

Ignorowanie czasu życia danych. Krótkotrwałe dane transakcyjne i długookresowe archiwa wrażliwe nie niosą tego samego ryzyka.

Traktowanie dostawców jako późniejszego etapu. Wiele zabezpieczeń kryptograficznych jest zarządzanych przez dostawców. Jeżeli dostawcy nie zostaną włączeni wcześnie, plan może być nierealistyczny.

Zapominanie o podpisach. Planowanie postkwantowe nie dotyczy wyłącznie szyfrowania. Podpisy cyfrowe, podpisywanie kodu, certyfikaty, tokeny tożsamości, aktualizacje oprogramowania układowego i podpisywanie dokumentów wymagają uwagi.

Zakładanie, że dostawcy chmury rozwiążą wszystko. Platformy chmurowe odegrają ważną rolę, ale odpowiedzialność pozostaje współdzielona. Nadal trzeba wiedzieć, które usługi, konfiguracje, klucze, regiony i integracje są objęte wpływem.

Brak tworzenia dowodów audytowych. Plan migracji, którego nie można udowodnić, nie zaspokoi potrzeb kierownictwa, regulatorów, klientów ani audytorów.

Pomijanie testów wydajności i interoperacyjności. Algorytmy postkwantowe mogą wpływać na rozmiar ładunku, przebieg handshake, opóźnienia, pamięć masową, ograniczenia systemów wbudowanych i kompatybilność.

Wskaźniki, które CISO powinien raportować zarządowi

Raportowanie dla zarządu powinno być wystarczająco proste do zrozumienia i jednocześnie wystarczająco konkretne, aby wymuszać działania. Należy unikać szczegółowych debat o algorytmach. Trzeba skupić się na ekspozycji, postępie, decyzjach i ryzyku szczątkowym.

WskaźnikZnaczenie dla zarządu
Odsetek usług krytycznych z ukończonym inwentarzem kryptograficznymPokazuje widoczność
Odsetek długookresowych danych wrażliwych odwzorowanych na zabezpieczenia kryptograficznePokazuje przygotowanie na ryzyko „zbierz teraz, odszyfruj później”
Liczba krytycznych dostawców, od których otrzymano mapę drogową postkwantowąPokazuje gotowość stron trzecich
Liczba wysokiego ryzyka wyjątków kryptograficznychPokazuje niezarządzaną ekspozycję
Odsetek aplikacji krytycznych ocenionych pod kątem zwinności kryptograficznejPokazuje wykonalność migracji
Status ukończenia pilotażuPokazuje praktyczny postęp
Zaległe otwarte działania dotyczące postępowania z ryzykiemPokazuje ryzyko wykonawcze
Trend ryzyka szczątkowegoPokazuje, czy program zmniejsza ekspozycję

Użyteczny komunikat dla zarządu może brzmieć tak:

„Zakończyliśmy odkrywanie kryptograficzne dla 72 procent usług krytycznych. Dwa systemy mają krytyczną długookresową ekspozycję poufności, a trzech dostawców nie przedstawiło jeszcze map drogowych postkwantowych. Uruchomiliśmy projekt gotowości do podpisywania kodu oraz przegląd zależności od chmurowego KMS. Na dziś nie rekomendujemy awaryjnej wymiany, ale niepewność po stronie dostawców pozostaje największym ryzykiem szczątkowym.”

To język zarządzanego ryzyka cybernetycznego.

Praktyczna lista kontrolna na ten tydzień

Nie trzeba czekać na pełną pewność. Zacznij od kroków, które natychmiast poprawią widoczność i zarządzanie.

  1. Wyznacz właściciela kryptografii postkwantowej.
  2. Dodaj ryzyko kryptograficzne związane z technologiami kwantowymi do rejestru ryzyk SZBI.
  3. Zidentyfikuj dziesięć najważniejszych usług z długookresowymi danymi wrażliwymi lub wysokim wpływem na integralność.
  4. Zbuduj minimalny użyteczny CBOM dla tych usług.
  5. Poproś dostawców krytycznych o ich mapę drogową postkwantową.
  6. Przejrzyj polityki dotyczące kryptografii, bezpiecznego rozwoju oprogramowania, dostawców i aktywów.
  7. Zidentyfikuj systemy z twardo zakodowanymi algorytmami, przestarzałymi bibliotekami, ręczną rotacją certyfikatów lub słabą odpowiedzialnością właścicielską.
  8. Wybierz jeden pilotaż niskiego ryzyka do testowania zwinności kryptograficznej.
  9. Zdefiniuj wskaźniki dla zarządu i częstotliwość raportowania.
  10. Zaplanuj audyt wewnętrzny skoncentrowany na zarządzaniu kryptografią i dowodach.

Najważniejszym krokiem jest przekształcenie niepewności w zarządzane działania. Ryzyko kwantowe może dotyczyć przyszłości, ale dług kryptograficzny istnieje już dziś.

Kolejne kroki z Clarysec

Migracja postkwantowa będzie jedną z najbardziej złożonych transformacji bezpieczeństwa następnej dekady, ponieważ obejmuje tożsamość, szyfrowanie, podpisy, dostawców, chmurę, oprogramowanie, urządzenia, archiwa i dowody audytowe. Organizacje, które zaczną od nadzoru i inwentaryzacji, będą działały szybciej niż te, które zaczekają na wymianę w ostatniej chwili.

Clarysec może pomóc zbudować plan migracji kryptograficznej odporny na zagrożenia kwantowe, wykorzystując:

Najlepszy moment na rozpoczęcie planowania postkwantowego jest zanim regulator, audytor, klient lub członek zarządu poprosi o dowody. Zacznij od inwentarza, powiąż go z ryzykiem i buduj ścieżkę migracji — jedna kontrolowana decyzja po drugiej.

Frequently Asked Questions

About the Author

Igor Petreski

Igor Petreski

Compliance Systems Architect, Clarysec LLC

Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council

Share this article

Related Articles

Podręcznik zgodności GDPR dla AI dla CISO: przewodnik po zgodności LLM w produktach SaaS

Podręcznik zgodności GDPR dla AI dla CISO: przewodnik po zgodności LLM w produktach SaaS

Ten artykuł przedstawia praktyczny podręcznik dla CISO, pomagający zarządzać ryzykiem na styku GDPR i AI. Omawia scenariuszowo sposób zapewniania zgodności produktów SaaS wykorzystujących LLM, ze szczególnym uwzględnieniem danych treningowych, kontroli dostępu, praw osób, których dane dotyczą, oraz gotowości audytowej w wielu ramach zgodności.

Od chaosu konfiguracji w chmurze do środowiska gotowego do audytu: projektowanie programu bezpieczeństwa chmury zgodnego z ISO 27001:2022 z wykorzystaniem zestawu narzędzi Zenith od Clarysec

Od chaosu konfiguracji w chmurze do środowiska gotowego do audytu: projektowanie programu bezpieczeństwa chmury zgodnego z ISO 27001:2022 z wykorzystaniem zestawu narzędzi Zenith od Clarysec

Dyrektorzy ds. bezpieczeństwa informacji, menedżerowie ds. zgodności i architekci chmury: zobaczcie, jak operacjonalizować zabezpieczenia ISO 27001:2022 dla środowisk chmurowych, aby utrzymywać ciągłą zgodność. Praktyczne scenariusze, techniczne tabele mapowania i użyteczne plany działania od Clarysec łączą bezpieczeństwo, ład organizacyjny i gotowość audytową w wielu ramach zgodności.