22.09.2026
CyberSec Update #38: Parametry i matryca zdarzeń | KWKR
Parametry projektu i matryca zdarzeń. Jak nie zbudować wieży Babel z incydentów
Budowniczowie wieży Babel mieli wszystko: technologię, zasoby i wspólny cel. Zabrakło im jednej rzeczy – wspólnego języka. Gdy każdy zaczął mówić po swojemu, najlepiej zaprojektowana konstrukcja stanęła w miejscu.
W poprzednich odcinkach zbudowaliśmy „mur graniczny” (klauzulę) i zważyliśmy ryzyko (kategorie A-D). Dziś schodzimy poziom niżej, do warstwy operacyjnej. Jak sprawić, aby terminy zgłoszeń i klasyfikacja incydentów działały tak samo u każdego kontrahenta, niezależnie od tego, jakim „dialektem” cyberbezpieczeństwa posługuje się na co dzień? Służą do tego dwa narzędzia: parametry projektu oraz matryca mapowania zdarzeń.
1. Czym są parametry projektu?
Parametry projektu to zbiór szczegółowych, operacyjnych ustaleń pomiędzy stronami. Doprecyzowują wykonanie klauzuli dla konkretnej umowy, bez konieczności każdorazowej zmiany jej treści.
Typowo obejmują:
- kanały i formaty zgłoszeń oraz dane kontaktowe;
- klasyfikację systemów oraz wartości RTO/RPO;
- harmonogramy i kryteria przypisania kategorii ryzyka;
- kwoty, progi, okresy retencji i inne parametry ilościowe.
To „warstwa zmienna” projektu, którą można dostosować do konkretnej umowy, przy zachowaniu stałego trzonu klauzuli.
2. Czego parametry projektu nie mogą zmieniać?
Kluczowe jest zachowanie równowagi. Parametry projektu doprecyzowują zasady współpracy, ale nie mogą ich osłabiać.
- Nie mogą modyfikować ani ograniczać podstawowych obowiązków, w szczególności obowiązków zgłoszeniowych, minimalnych środków bezpieczeństwa oraz odpowiedzialności kontrahenta.
- Mają pierwszeństwo wyłącznie w zakresie wyraźnie dopuszczonym przez klauzulę, np. w odniesieniu do kanałów zgłoszeń, RTO/RPO lub kryteriów kategorii ryzyka.
- Nie mogą znosić obowiązku zgłaszania incydentów ani wydłużać terminów raportowania.
- Do czasu ich ustalenia stosuje się wykładnię zapewniającą maksymalną ochronę zamawiającego.
Innymi słowy: parametry regulują „jak”, ale nigdy nie eliminują odpowiedzi na pytanie „czy”.
3. Wspólny język terminów zgłoszeń incydentów
Podstawą sprawnej współpracy są jednolite terminy zgłaszania i raportowania incydentów do zamawiającego.
- do 4 godzin – wstępne powiadomienie o zdarzeniu;
- do 12 godzin – pełne zgłoszenie poważnego incydentu;
- do 48 godzin – pełne zgłoszenie pozostałych incydentów i błędów.
Zgłoszenia powinny być realizowane dwoma niezależnymi kanałami: podstawowym i awaryjnym, wskazanymi w parametrach projektu.
Warto pamiętać, że terminy te dotyczą relacji kontrahent–zamawiający i nie zastępują ustawowych terminów zgłoszeń do CSIRT wynikających z KSC i NIS2.
4. Matryca mapowania zdarzeń – tłumacz między światami
Każdy dostawca może stosować własne oznaczenia alertów, incydentów czy błędów. Matryca mapowania zdarzeń pozwala przełożyć wewnętrzną klasyfikację zdarzeń i incydentów stosowaną przez kontrahenta na definicje bazowe przyjęte przez zamawiającego.
W praktyce:
- kontrahent przedkłada matrycę do zatwierdzenia w terminie 14 dni od rozpoczęcia realizacji umowy;
- matryca mapuje klasyfikacje alertów, zdarzeń, incydentów, podatności i błędów na definicje umowne oraz odpowiadające im terminy zgłoszeń;
- może zawierać przykłady typowych zdarzeń oraz sposób inicjowania zgłoszeń.
Celem matrycy jest ograniczenie ryzyka zaniżania klasyfikacji zdarzeń, opóźnień w raportowaniu oraz sporów dotyczących obowiązku zgłoszenia incydentu.
5. Kto odpowiada za definicje?
Aby matryca nie stała się narzędziem do rozmywania progów bezpieczeństwa, obowiązuje jasny podział ról.
- Definicje bazowe i progi ochronne pozostają po stronie zamawiającego.
- Kontrahent nie tworzy własnego katalogu zdarzeń, lecz odwzorowuje swoją klasyfikację na definicje przyjęte w umowie.
- Jeżeli kontrahent nie przedłoży matrycy, stosuje się bezpośrednio definicje bazowe wynikające z klauzuli.
- W przypadku racjonalnych wątpliwości należy przyjmować kwalifikację konserwatywną, chyba że zamawiający wskaże inaczej.
6. Reguły kolizyjne – gdy dokumenty mówią różnymi głosami
Spójną strukturę zapewnia wcześniej ustalona hierarchia źródeł.
- moduł ICT/OT działa jako lex specialis wobec postanowień ogólnych dotyczących dostawców technicznych;
- parametry projektu obowiązują wyłącznie w zakresie wyraźnie dopuszczonym przez klauzulę;
- w przypadku rozbieżności pierwszeństwo ma rozwiązanie bardziej rygorystyczne i zapewniające wyższy poziom ochrony.
7. KSC, NIS2 i RODO – dlaczego wspólny język ma znaczenie?
Ujednolicona klasyfikacja incydentów oraz ciągły monitoring systemów wspierają realizację obowiązków związanych z ciągłym monitorowaniem systemów i oceną skuteczności środków bezpieczeństwa przez podmioty kluczowe i ważne.
Wspólny język zdarzeń ułatwia również terminowe zgłoszenia do CSIRT. Jeśli incydent dotyczy danych osobowych, sprawna klasyfikacja skraca drogę do oceny naruszenia w reżimie RODO i doboru środków adekwatnych do poziomu ryzyka.
Podsumowanie
Morał z historii o wieży Babel jest prosty: wspólny cel bez wspólnego języka prowadzi do chaosu. Parametry projektu i matryca zdarzeń pełnią rolę takiego wspólnego języka. Dzięki nim wielu kontrahentów może raportować incydenty według tych samych zasad, terminów i definicji, przy zachowaniu stałego katalogu obowiązków po stronie zamawiającego.
W kolejnym odcinku zajmiemy się ciągłością działania i odpowiemy na pytanie, jak ustawić RTO/RPO, plany BCP/DRP oraz testy odtworzeniowe dla systemów o znaczeniu operacyjnym.
