Incydent. W NIS 2 i UKSC (Ustawa o krajowym systemie cyberezpieczeństwa) to taki wielowymiarowy świat, że trudno się w nim odnaleźć. Szczególnie jeśli macie działania międzynarodowe, gdzie incydent znaczy co innego niż w polskim cyberbezpieczeństwie (przejrzałem większość rozwiązań, nie ma kraju, który mieszał w definicjach incydentu).
👉W NIS 2 „incydent” oznacza zdarzenie naruszające dostępność, autentyczność, integralność lub poufność przechowywanych, przekazywanych lub przetwarzanych danych lub usług oferowanych przez sieci i systemy informatyczne lub dostępnych za ich pośrednictwem;
💡W Polskim projekcie definicja incydentu jest inna. Jest to zdarzenie, które ma lub może mieć niekorzystny wpływ na bezpieczeństwo systemów informacyjnych,
O tym, że ma lub może mieć już pisałem. Ale dziś ważniejszy jest inny aspekt. ⚠️Otóż w przypadku przepisów europejskich incydentem będzie naruszenie bezpieczeństwa informacji lub usług, oferowanych przez sieci i systemy ICT.
🤔W przypadku polskich przepisów, ważniejszy jest system, a dokładniej odporność tego systemu IT/ICT.
Dla architektów systemów zarządzania incydentami konieczne stanie się więc przygotowanie identyfikacji i klasyfikacji zdarzeń i incydentów z różnymi aktywatorami:
➡️Aby być zgodnymi z NIS 2 – naruszenie bezpieczeństwa (atrybutów bezpieczeństwa) informacji (w NIS 2) oraz usług.
➡️Aby być zgodnymi z UKSC – naruszenie bezpieczeństwa systemów informacyjnych.
Mimo, że mi bliższe jest podejście z UKSC, gdzie szukam na początek źródeł ryzyka, a więc wykonuję analizę zagrożeń (ekspertami branżowymi, bo są pewne regulacje, że nie każdy może, są wymagania co do uprawnień), to jednak nie jest to zgodne zarówno z NIS 2, jak i przyjętym modelem odzwierciedlonym w przepisach europejskich (oprócz NIS 2 np. też RODO).
🔔Różnica wynika z przyjętego podejścia – analiza może być “od skutku” lub “od przyczyny”. Model zawarty w przepisach jest klasycznym modelem “od skutku”. Czyli najpierw skutek (dla chronionego podmiotu, obszaru, procesu), a potem schodzimy do przyczyn, w tym związków przyczyn, aż do bezpośrednich, jednostkowych źródeł (w tym naruszenie bezpieczeństwa systemu informacyjnego)
Jest to całkowicie zrozumiałe, ponieważ dany przepis ma ustanawiać minimalną ochronę dla konkretnych zasobów (usług, produktów, procesów czy informacji, a nawet danych). Chodzi kolokwialnie o takie podejście, w którym i operacja się udała, i pacjent przeżył.
W podejściu UKSC, skupionym na samych systemach ICT, ważniejsza jest ich odporność. Fakt, z racji przetwarzania danych i świadczenia usług przez te systemy wynikowo dane i usługi będą chronione. Ale nie o to chodziło.
💡Incydent miał dotyczyć informacji (danych) lub usług, a nie narzędzi do ich przetwarzania.
Trochę jakby zabrakło wizji i widzenia zagadnienia z lotu ptaka oraz zrozumienia istoty wydawanych regulacji oraz podejścia. Obecne są bardzo nastawione na osiągnięcie celu, co koliduje z polskim, które przez lata było czysto papierkowo-instrukcyjne. Mam Politykę, to moje zasoby są chronione…