PQC wymaga odpowiedzialności. Nie tylko technologii.

Nie. Wskaźniki wymagają przejrzystych definicji i leżącej u ich podstaw dokumentacji dowodowej. Jakie dokumenty są wymagane, ustala się w ramach konkretnego audytu.

Osoby odpowiedzialne monitorują istotne zmiany w normach, produktach i własnej infrastrukturze. Wnioski są w kontrolowany sposób uwzględniane w polityce, inwentarzu i planowaniu działań.

Przejście na nową kryptografię trwa dłużej niż pojedynczy projekt. Osadzamy inwentarz, decyzje i zakresy odpowiedzialności w Państwa istniejących procesach. Dzięki temu zmiany w aplikacjach, u dostawców i w rekomendacjach pozostają możliwe do obsłużenia i prześledzenia.

Opracowanie polityki kryptograficznej i zakresów odpowiedzialności Uregulowanie wyjątków wraz z uzasadnieniem, osobami odpowiedzialnymi i terminami Formułowanie wymagań dotyczących zakupów i dostawców Raportowanie postępu migracji na podstawie wiarygodnych danych Zestawianie dowodów technicznych na potrzeby Państwa procesów audytowych

Polityka kryptograficzna i model ról Procedura wyjątków i aktualizacji Pakiet dowodów z inwentarzem, decyzjami i testami

Centralna polityka potrzebuje osób, które wdrożą ją w poszczególnych aplikacjach. Przypisujemy osoby odpowiedzialne technicznie, merytoryczne decyzje dotyczące ryzyka oraz zatwierdzenia. Polityka opisuje dopuszczone algorytmy, kryteria wyboru i sposób postępowania przy zmianach. Wyjątki otrzymują uzasadnienie i termin ponownej weryfikacji. Wykorzystujemy istniejące procesy bezpieczeństwa i zarządzania zmianą, aby utrzymanie kryptografii nie skończyło się na odizolowanej liście projektowej.

Przy zakupach i odnawianiu umów można wymagać informacji o zależnościach kryptograficznych, sposobach aktualizacji i planowanym wsparciu. Deklaracje dokumentujemy wraz z ich statusem: zapowiedziane, dostępne lub przetestowane w konkretnym środowisku. Wskaźniki rozróżniają ujęte systemy, ocenione ryzyka i przypadki użycia skutecznie przeniesione na nowe algorytmy. Wysoka liczba zinwentaryzowanych certyfikatów nie może przesłaniać faktu, że wciąż brakuje krytycznych systemów offline.

Łączymy inwentarz, decyzje i raport z testów w taki sposób, aby stan realizacji można było prześledzić. Dokumentacja techniczna wspiera audyty wewnętrzne lub zewnętrzne; nie zastępuje odrębnie wymaganej oceny prawnej ani formalnej certyfikacji. Odbiór obejmuje sprawdzenie zakresów odpowiedzialności oraz przykładowego przypadku zmiany lub wyjątku. Dzięki temu widać, czy procedura działa w codziennej praktyce.

Łączymy wyniki techniczne z zatwierdzeniami, zakupami i możliwym do utrzymania stanem dokumentacji dowodowej. Dzięki temu przygotowania można skutecznie kontynuować, nawet gdy produkty, standardy i wewnętrzne zakresy odpowiedzialności ewoluują.

Decyzje i wyjątki mają przypisane osoby odpowiedzialne oraz terminy ponownej weryfikacji. Dowody są powiązane z inwentarzem i działaniami. Wymagania zakupowe obejmują pytania o konkretne możliwości i ograniczenia.

Przykład: zespół zakupowy otrzymuje dwie oferty z deklaracją PQC-ready. Przekładamy wymagane przypadki użycia na możliwe do zweryfikowania pytania dotyczące algorytmów, interfejsów i cyklu życia. Decyzja dokumentuje potwierdzone możliwości oraz niezrealizowane jeszcze zapowiedzi, tak aby kolejne zespoły projektowe mogły pracować dalej na tej samej podstawie.

Dla algorytmów, produktów i rozwiązań przejściowych dokumentowane są decyzja, uzasadnienie i zakres obowiązywania. Tymczasowy wyjątek wymaga osoby odpowiedzialnej i wyznaczonego momentu ponownej weryfikacji. Bez tych informacji pozostałe kwestie techniczne często zostają nierozwiązane na stałe. Łączymy inwentarz, ocenę ryzyka i działania, zamiast tworzyć niepowiązane ze sobą listy. Dzięki temu można wyjaśnić, dlaczego dany system został potraktowany priorytetowo, jakie testy zostały przeprowadzone i jaki warunek blokuje kolejny etap. Odpowiedzialność biznesowa i realizacja techniczna są przy tym wskazywane osobno.

Nowe produkty powinny dostarczać istotnych informacji o funkcjach kryptograficznych, możliwości aktualizacji i ścieżkach migracji. Formułujemy konkretne pytania do dostawców, wykraczające poza samo hasło PQC-ready. Dowody odnoszą się do konkretnych wersji i planowanego zastosowania, a nie tylko do ogólnej prezentacji producenta. Regularne przeglądy porównują mapę drogową z rzeczywistymi postępami. Przy istotnych zmianach architektury lub produktów aktualizowany jest inwentarz. Dokumentacja wspiera kontrole i audyty wewnętrzne, nie zastępuje jednak zewnętrznej certyfikacji ani wiążącej oceny wydawanej przez właściwe organy.

Inwentarz kryptograficzny i potrzeby ochrony IT, bezpieczeństwo informacji, właściciele aplikacji, specjalista ds. kryptografii OTOKO® CBOM, potrzeby ochrony i czas życia danych dla każdego systemu, analiza luk względem BSI TR-02102

Mapa drogowa, docelowe algorytmy, fazy przejściowe Architektura, bezpieczeństwo informacji, eksploatacja PKI, zakupy Mapa drogowa migracji, polityka kryptograficzna, docelowy model PKI i HSM, model eksploatacji