Podejście do cyberbezpieczeństwa zgodne z NIS 2 i DORA

Spis treści:

1. Archetyp cyberbezpieczeństwa
2. Główne założenia
3. Podejście holistyczne
4. Koncepcja standaryzacji
5. System zarządzania
6. Ramy a system
7. Podejście proaktywne
8. Podejście procesowe
9. Akcja i reakcja

Jednym z podstawowych wymogów wynikających z rozporządzenia DORA oraz dyrektywy NIS 2 w stosunku do instytucji finansowych oraz podmiotów kluczowych i ważnych w Unii Europejskiej jest wymóg zarządzania ryzykiem oraz ciągłością działania. W tej serii artykułów omówimy filary, na których opierają się założenia tych aktów prawnych.

Budowa w pełni funkcjonalnego systemu odporności cyfrowej, który realnie zwiększy cyberbezpieczeństwo danej organizacji i jednocześnie będzie spełniał wszystkie wymagania regulacji unijnych DORA i NIS 2 (oraz jednocześnie będzie zgodny z zapisami rodo) w praktyce, a nie tylko biurokratycznej teorii, to nie lada wyzwanie. Dlatego w artykule będziemy wybiegać również poza formalne wymagania tych dwóch regulacji unijnych i uzupełnimy ich zapisy o dobre praktyki pochodzące m.in. z europejskich norm ISO.

Zanim jednak przejdziemy do szczegółowej analizy wymagań regulacyjnych, należy zdać sobie sprawę z dwóch istotnych faktów. Po pierwsze, zarządzanie ryzykiem ICT nie jest procesem odizolowanym – musi być integralną częścią systemu zarządzania ryzykiem w obrębie całej organizacji. Po drugie, efektywne wdrożenie wymogów DORA i NIS 2 wymaga synergii pomiędzy standardami technologicznymi a celami biznesowymi.

Archetyp cyberbezpieczeństwa

W normie ISO 27005 możemy przeczytać, że „analizę ryzyka można przeprowadzać na różnym poziomie szczegółowości, w zależności od krytyczności aktywów”. W DORA oraz NIS 2 nie został niestety określony tzw. archetyp cyberbezpieczeństwa, który powinien być drogowskazem w tym zakresie. Według nas musi się on składać z następujących poziomów odnoszących się do podłączenia systemów ICT do sieci:

1. Podłączenie bezpośrednio do publicznej sieci internet – najwyższy poziom ryzyka cybernetycznego;
2. Podłączenie pośrednio do publicznej sieci internet za pomocą interfejsów systemowych – średni poziom ryzyka cybernetycznego;
3. Brak punktu styku z publiczną siecią internet (czyli te w wewnętrznej sieci LAN) – najniższy poziom ryzyka cybernetycznego.

Podobny archetyp pojawiał się kiedyś w dokumentach dotyczących bezpieczeństwa informacji w odniesieniu do rodo, natomiast w DORA i NIS 2 został niestety całkowicie pominięty, chociaż jest on naszym zdaniem kluczowy w kontekście zarządzania ryzykiem ICT. Wskazuje bowiem poziom podatności elementów architektury na ataki cybernetyczne.

W DORA serwisy internetowe, extranetowe i aplikacje mobilne zostały zaliczone do usług cyfrowych, co jest skrótem myślowym, ponieważ zgodnie z modelem procesu SIPOC są to zasoby ICT, za pomocą których świadczone są usługi cyfrowe, czyli e-usługi (nie mylić z usługami ICT). Przykładowo system bankowości elektronicznej nie jest usługą, tylko zasobem ICT, służącym do świadczenia wielu różnych e-usług, np. przelewu, zapłaty, wymiany walut.

W wielu firmach zdarza się, że wszyscy zajmują się zabezpieczeniami grupy systemów z trzeciego poziomu archetypu cyberbezpieczeństwa, a pozostałymi dwoma często zarządzają jednostki biznesowe (np. dział marketingu), które nie mają nawet wyznaczonych administratorów technicznych. Co więcej, serwisy internetowe i extranetowe tworzone są zazwyczaj w systemach klasy CMS, które często też są pomijane w architekturze systemów. Oprócz CMS-ów w architekturze serwisów internetowych i aplikacji mobilnych funkcjonują również serwery plików, a te również trzeba zabezpieczać. Przez to, że firmy nie mają określonego archetypu cyberbezpieczeństwa, zajmują się często przede wszystkim zabezpieczeniem największych i najdroższych systemów ICT, pomijając te najbardziej zagrożone cyberatakami – tańsze i pochodzące od mniej znanych producentów – w których znajduje się najwięcej podatności. Tymczasem zgodnie z DORA to pierwsza grupa systemów z archetypu cyberbezpieczeństwa powinna być przede wszystkim poddawana okresowym testom penetracyjnym oraz testom po każdej istotnej zmianie, a nie grupa systemów w wewnętrznej sieci LAN. Naszym zdaniem nie można serwisu internetowego firmy traktować tylko jako miejsca z informacjami na temat działalności podmiotu, którym samodzielnie zarządza dział marketingu lub komunikacji. Strony internetowe i extranetowe stanowią bowiem bardzo istotny element architektury ICT w przedsiębiorstwie. Jest on przeznaczony do wymiany informacji z klientami, dostawcami czy inwestorami, a ze względu na bezpośredni punkt styku z publicznym internetem to ten element infrastruktury ICT jest najbardziej podatny na cyberataki. Serwisy internetowe oraz extranetowe, które możemy łącznie określić jako Corporate Bussines Portal, to skomplikowany mechanizm infrastruktury ICT składający się często z kilkuset, a nawet kilku tysięcy stron internetowych oraz interfejsów międzysystemowych. Tym samym stanowi on olbrzymią platformę wymiany informacji z wieloma interesariuszami zewnętrznymi, a zarządzanie wymianą danych wymaga współdziałania wielu komórek biznesowych oraz IT.

Główne założenia

Aby dobrze zinterpretować zapisy i wymagania zawarte w regulacjach DORA i NIS 2, co oznacza wyjście poza to, co napisane wprost i czytanie między wierszami, trzeba znać filary, na których opierają się obie te regulacje Unii Europejskiej, bo filary te definiują ich ideę. To dwa akty prawne UE, które mają na celu podniesienie poziomu cyberbezpieczeństwa w różnych sektorach gospodarki. Główna różnica między nimi sprowadza się do zakresu podmiotowego oraz szczegółowości przepisów.

DORA koncentruje się wyłącznie na sektorze finansowym, w tym na bankach, firmach ubezpieczeniowych i dostawcach usług ICT, które są kluczowe dla tego sektora. NIS 2 ma z kolei szerszy zakres i obejmuje wiele kluczowych sektorów gospodarki, takich jak energetyka, transport, ochrona zdrowia, usługi cyfrowe, woda i żywność. Warto przy tym zaznaczyć, że dotyczy również sektora finansowego, choć w innym zakresie. W przeciwieństwie do DORA NIS 2 jest dyrektywą – państwa członkowskie mają więc obowiązek wdrożyć jej zapisy do swojego prawa krajowego, co może prowadzić do pewnych różnic w implementacji. W Polsce dyrektywa NIS 2 będzie wdrażana na podstawie nowej ustawy o krajowym systemie cyberbezpieczeństwa (dalej: uoksc), która – popodpisaniu przez Prezydenta RP i miesięcznym vacatio legis – już obowiązuje. Wymogi NIS 2 są ogólniejsze i stanowią ramy (frameworki) dla zarządzania ryzykiem ICT.

Zarówno DORA, jak i NIS 2 – chociaż dotyczą różnych podmiotów prawnych – opierają się na sześciu głównych filarach:

1. Podejście holistyczne (holistic approach).
2. Podejście proaktywne (pro active approach=resilience) dotyczące zarządzania incydentami ICT oraz kryzysami.
3. Podejście procesowe (process-based approach).
4. Podejście oparte na ciągłości działania (business continuity approach).
5. Podejście oparte na zarządzaniu ryzykiem ICT (risk-based approach).
6. Podejście oparte na jakości usług ICT (SLA – Service Level Agreement approach).
7. Podejście zwinne w zarządzaniu incydentami (agile incident approach).

Podejście holistyczne

W ramach tego podejścia organizacja traktuje cyberbezpieczeństwo jako całość – jeden spójny i kompleksowy system zarządzania, a nie zbiór odrębnych rozwiązań i wymogów, które należy spełnić. Oznacza to oczywiście konieczność zbudowania modelu odporności cyfrowej opartego na kilku zintegrowanych ze sobą systemach zarządzania. W zależności od przedsiębiorstwa będą to m.in.:

• system zarządzania procesowego (Business Process Management System, BPMS);
• system zarządzania ryzykiem (Risk Management System, RMS);
• system zarządzania bezpieczeństwem informacji (Information Security Management System, ISMS);
• system zarządzania ciągłością działania biznesu (Business Continuity Management System, BCMS);
• system zarządzania jakością usług IT (IT Service Management System, ITSM).

O podejściu holistycznym, a także integracji wszystkich wyżej wymienionych systemów w tzw. Zintegrowany System Odporności Cyfrowej (ZSOC) pisaliśmy na naszych łamach w ubiegłym roku („IT Professional” 9/2025, s. 39) – zainteresowanych odsyłamy więc do wyżej wymienionego artykułu.

Koncepcja standaryzacji

Warto jednak w tym momencie pochylić się nad standaryzacją. Po wielu nieudanych wdrożeniach systemów ISO, w szczególności ISO 9001, które zaczęły się lawinowo na początku lat 90., można było odnieść wrażenie, że była to zbędna biurokracja i przerost formy nad treścią, dlatego wiele firm wycofało się nawet z certyfikacji swoich systemów zarządzania. Obecnie jednak idea standaryzacji wraca do łask w podejściu bardziej praktycznym niż biurokratycznym, a wręcz jest niezbędna, aby spełnić wymagania DORA czy NIS 2. Musi to być jednak robione z głową, aby przyniosło zakładany efekt, a nie stało się tylko kulą u nogi lub biurokratycznym gniotem. Podczas gdy wdrażanie norm ISO ma w Polsce nieco złą prasę, to na świecie rekordy popularności biją obecnie dwie koncepcje. Pierwszą jest koncepcja zarządzania procesowego (Business Process Management, BPM), a drugą zwinnego zarządzania projektami i całymi organizacjami (agile management). Zakładają one odejście od tzw. zarządzania silosowego na rzecz zarządzania procesowego, które jest efektywniejsze i umożliwia szybsze reagowanie na zmieniające się otoczenie rynkowe. A przecież za ideą standaryzacji procesów (zgodnie z ISO 9001) stoi to samo, więc należałoby się zastanowić, jak przekształcić założenia ISO 9001 w praktyczną koncepcję BPM oraz agile management.

Można nawet pokusić się o nadanie tej koncepcji nazwy „follow reality” – podążania za zmieniającą się rzeczywistością, która w dobie internetu, sztucznej inteligencji i komputerów kwantowych jest na tyle dynamiczna, że firmy nie są w stanie dostosowywać się do zmian. W końcu modelowanie procesów, przygotowanie zaktualizowanych procedur postępowania czy wdrożenie nowych systemów informatycznych zajmuje sporo czasu. Zazwyczaj im większy podmiot, tym większa jest siła bezwładności i dłuższy czas dostosowania się do nowej rzeczywistości, natomiast mniejsze firmy są dynamiczniejsze ze względu na prostszą strukturę zarządzania, mniejszą liczbę systemów IT, procesów, procedur, a także pracowników.

System zarządzania

Należy również zwrócić uwagę, że pomiędzy systemami informatycznymi a systemami zarządzania istnieje również pewna analogia, ponieważ jedne i drugie wdraża się, utrzymuje oraz rozwija i integruje w przedsiębiorstwach w podobny sposób. Wynika to z faktu, iż zgodnie z wywodzącą się z cybernetyki definicją, w której nie ma rozróżnienia systemów, każdy system podlega tym samym regułom, obojętnie, czy jest to system informatyczny, zarządzania, prawny, czy system obronny.

System zarządzania jest narzędziem w ramach całego systemu zarządzania przedsiębiorstwem. Umożliwia on świadome i celowe kierowanie organizacją, aby osiągnęła swoje cele. Innymi słowy, system zarządzania to metodologia, która pomaga usprawnić i zorganizować pracę w firmie, a standaryzacja jest jednym z elementów, które mają na celu zwiększenie efektywności działania przedsiębiorstwa, a nie tylko spełnienie wymogów regulacyjnych DORA czy NIS 2.

Systemy ISO, takie jak ISO 9001 (zarządzanie jakością) czy ISO 27001 (zarządzanie bezpieczeństwem informacji), to zbiory wzajemnie powiązanych lub oddziałujących na siebie elementów konfiguracji, które służą do ustanowienia celów, polityk, procedur i procesów w organizacji. Ich głównym zadaniem jest zarządzanie danym obszarem tematycznym (np. jakością, cyberbezpieczeństwem, ryzykiem, ciągłością działania) w sposób kompleksowy, metodyczny i powtarzalny – innymi słowy, zgodnie z podejściem holistycznym, którego wymagają DORA, NIS 2 oraz amerykańskie standardy NIST.

Zarówno DORA, jak i normy ISO promują podejście procesowe do zarządzania cyberbezpieczeństwem informacji. Jest to jeden z fundamentów tego rozporządzenia. DORA odchodzi od traktowania bezpieczeństwa jako jednorazowego projektu lub zestawu przypadkowych działań i w zamian nakazuje wdrożenie spójnego systemu opartego na ciągłym cyklu zarządzania procesami zgodnie z PDCA (cyklu Deminga).

Ramy a system

Pojęcia „framework” i „system zarządzania”, chociaż brzmią podobnie, dotyczą zupełnie innego poziomu szczegółowości.

FRAMEWORK

W świecie technologii i biznesu framework to szkielet (platforma), który nie jest gotowym produktem, ale zestawem zasad i komponentów, na których można zbudować własny system. Poniżej krótkie omówienie frameworku:

• charakter – jest „pusty” w środku – musisz go wypełnić własną treścią lub kodem;
• przykład IT – React lub Django, w ramach których dostajesz mechanizmy do obsługi użytkowników, ale to Ty decydujesz, jak będzie wyglądać Twoja strona;
• przykład biznesowy – scrum, czyli ramy postępowania, tłumaczące, jak pracować, ale nie nad czym.

SYSTEM ZARZĄDZANIA

To zbiór połączonych ze sobą procesów, procedur i często narzędzi (oprogramowania), które służą do kontrolowania konkretnego obszaru firmy. Taki system można opisać w następujący sposób:

• charakter – jest nastawiony na cel i monitorowanie wyników; często jest to gotowe oprogramowanie (np. ERP) lub formalny zbiór norm (np. ISO);
• przykład IT – CMS (np. Word-Press), tj. system zarządzania treścią z gotowym panelem, UI oraz bazą danych. Nie musisz nic programować, tylko zarządzasz gotową strukturą;
• przykład biznesowy – system ISO 9001, będący zbiorem konkretnych procedur sprawdzania każdego produktu przed wysyłką.

Podsumowując, można przyjąć, że framework to instrukcja i klocki, z których możesz zbudować, co chcesz. Tymczasem system zarządzania to gotowy, zdalnie sterowany samochód, którym kierujesz, by dojechać do celu.

RÓŻNE METODYKI

W wielu opracowaniach pojawiają się rekomendacje różnych metodyk – zarówno europejskich, jak i amerykańskich, np. NIST. Ze względu na to, że metodyki ISO są ze sobą kompatybilne oraz łatwo je łączyć za pomocą odpowiednich interfejsów (High Level Structure, HLS), bezpieczniej korzystać właśnie z nich, a nie amerykańskich, które mogą się okazać niekompatybilne z normami ISO. Dokumenty NIST nadają się bardziej do zastosowania jako dobre praktyki w zakresie implementacji konkretnych zabezpieczeń technicznych niż jako kompleksowy system do zarządzania ryzykiem w organizacji. Model risk managementu zawarty w NIST różni się nieco od tego w normach ISO i nie będzie on kompatybilny z innymi systemami zarządzania ISO wdrożonymi w europejskich firmach i instytucjach. Co za tym idzie, próba połączenia standardów NIST z ISO może się zakończyć niepowodzeniem. Według nas mieszanie ze sobą wymienionych wyżej standardów może prowadzić do chaosu i przynieść więcej szkód niż pożytku dla organizacji. Nie można bowiem stosować jednocześnie dwóch różnych wizji zarządzania ryzykiem. Konieczne jest zdecydowanie się na konkretną wizję – europejską (ISO) lub amerykańską (NIST) – i konsekwencja w jej realizacji. Podeście oparte na frameworkach NIST jest zupełnie inne niż to oparte na systemach zarządzania ISO.

Zaznaczyć należy, że tzw. dobre praktyki czy „frameworki” są czymś w rodzaju platformy lub elementów konfiguracji, z których można zbudować system zarządzania cyberbezpieczeństwem lub system zarządzania odpornością cyfrową. Wdrożenie samych frameworków niczego jednak nie gwarantuje, bo nie są to rozwiązania kompleksowe, spełniające wymagania holistycznego podejścia w myśl DORA i NIS 2. DORA wymaga podejścia holistycznego (kompleksowego), a więc budowy systemu w myśl definicji cybernetycznej (system-based approach). Niestety dyrektywa nie jest w pełni konsekwentna w tym założeniu, ponieważ w innym miejscu pojawia się zdanie dotyczące budowy ram zarządzania ryzykiem, a nie w pełni działającego systemu zarządzania ryzykiem, czyli ERMS (Enterprise Risk Management System). Art. 6 ust. 1 DORA nakłada na podmioty finansowe następujący obowiązek: „Podmioty finansowe posiadają solidne, kompleksowe i dobrze udokumentowane ramy zarządzania ryzykiem związanym z ICT, które pozwalają im szybko, sprawnie i kompleksowo zająć się ryzykiem związanym z ICT oraz zapewnić wysoki poziom operacyjnej odporności cyfrowej”. Widać tutaj jasno, że w DORA ścierają się dwa nurty: amerykański – oparty na wdrażaniu ram zarządzania – i europejski, skupiający się na wdrażaniu systemów zarządzania. Można przyjąć, że ustawodawca unijny nie widzi różnicy pomiędzy pojęciami „system” oraz „ramy” i traktuje je synonimicznie, co powoduje pewien chaos metodologiczny.

ELEMENTY KONFIGURACJI

W niektórych przypadkach zdarza się, że pomimo wprowadzania różnych frameworków wciąż czegoś brakuje i nie wiemy, jaki jest poziom cyberbezpieczeństwa. Może się to wiązać z brakiem zdefiniowania wszystkich wymaganych elementów konfiguracji. Mogą one ze sobą również nie współpracować jako całość, jak to ma miejsce w przypadku systemu.

Tutaj dochodzimy do podstawowej różnicy między ramami a systemami. System musi mieć określone wszystkie elementy konfiguracji niezbędne do jego działania – tak jak np. system obrony przeciwlotniczej. Niezintegrowane ze sobą w jedną całość elementy konfiguracji dają jedynie fałszywe złudzenie cyberbezpieczeństwa. Z kolei system, którego harmonijne, całościowe działanie zostało przetestowane (elementy jego konfiguracji poprawnie ze sobą współpracują), daje realną ochronę przedsiębiorstwa, całego sektora, EU lub NATO. Potwierdza to podstawowa zasada, która mówi, że poziom cyberbezpieczeństwa zależy od najsłabszego ogniwa w systemie.

Co ciekawe, z jednej strony w aktach prawnych pojawiają się pojęcia incydentu cybernetycznego, cyberprzestrzeni, a z drugiej strony cybernetyczna definicja „systemu” jest całkowicie pomijana. Ponadto w normie ISO 27001 mowa o systemie informacyjnym (Information System, IT), a w DORA i NIS 2 o systemie ICT (Information and Telecommunication Technologies, ICT). Dlaczego więc do zarządzania tymi „systemami technicznymi” mielibyśmy używać frameworków zarządzania, a nie „systemów zarządzania”? Na pierwszy rzut oka widać, że coś tutaj nie pasuje. Według nas jest to pewnego rodzaju niekonsekwencja ustawodawcy unijnego, która prowadzi do luk w całej koncepcji zarządzania cyberbezpieczeństwem (czy raczej koncepcji odporności cyfrowej). Zgodnie ze starą zasadą – jeśli coś opiera się na błędnych lub niepełnych założeniach, to wynik tego może być niepoprawny.

Podejście proaktywne

Drugi filar w zarządzaniu cyberbezpieczeństwem to strategia, która koncentruje się na zapobieganiu atakom i incydentom, zanim w ogóle do nich dojdzie. W przeciwieństwie do podejścia reaktywnego (które polega na reagowaniu po wystąpieniu ataku) proaktywne ma na celu ciągłe identyfikowanie, ocenianie i minimalizowanie potencjalnych zagrożeń oraz luk w zabezpieczeniach. Jest to kluczowa zmiana w myśleniu, która przekształca cyberbezpieczeństwo z roli „straży pożarnej” w rolę „architekta prewencji”.

Zarówno DORA, jak i NIS 2 przenoszą punkt ciężkości z podejścia reaktywnego na bardziej proaktywne. DORA nakłada na podmioty finansowe szereg proaktywnych działań, których celem jest nie tylko niedopuszczenie do incydentów cybernetycznych (na czym polega cyberbezpieczeństwo), ale również przygotowanie się na minimalizację ich skutków, jeśli się wydarzą, oraz jak najszybsze przywrócenie ciągłości działania krytycznych procesów biznesowych. Dopiero te wszystkie elementy oznaczają odporność cyfrową.

Ustawodawca unijny z góry zakłada więc – i jest to założenie jak najbardziej słuszne – że niektóre cyberataki na pewno się powiodą. W związku z tym organizacja musi być przygotowana na to, aby jak najszybciej usunąć ich skutki oraz przywrócić ciągłość działania przynajmniej najbardziej krytycznych procesów i funkcji biznesowych. Dla wyjaśnienia należy dodać, że krytyczna funkcja to po prostu część krytycznego procesu – nie zostało to jednoznacznie wyjaśnione w DORA, ale można to wywnioskować z treści tej regulacji.

Wśród działań proaktywnych można wymienić:

• szkolenia z cyberbezpiczeństwa dla najwyższego kierownictwa;
• kompleksowe zarządzanie ryzykiem ICT;
• zarządzanie dostawcami ICT (w tym analizę uzależnienia od dostawców ICT oraz strategię wyjścia z usługi ICT);
• zaawansowane testy odporności operacyjnej (np. testy penetracyjne);
• zarządzanie ryzykiem stron trzecich (dostawców ICT);
• wymiana informacji o cyberzagrożeniach.

Dla porównania do przykładowych działań reaktywnych zaliczamy z kolei:

• zarządzanie incydentami i reagowanie;
• raportowanie incydentów;
• ciągłość działania i przywracanie (BCP&DR);
• wyciąganie wniosków z incydentów (post-incident review).

Zgodnie z powyższym można stwierdzić, że pojęcie cyberbezpieczeństwa obejmuje w dużej mierze działania na poziomie działów IT, z kolei pojęcie odporności cyfrowej oznacza dodatkowo cały zakres działań, za realizację których odpowiada najwyższe kierownictwo organizacji. Zgodnie z DORA i NIS 2 cyberbezpieczeństwo awansowało w firmach na wyższy poziom organizacji. Zgodnie z NIS 2 członkowie organów zarządzających mogą ponosić osobistą odpowiedzialność finansową za zaniedbania w procesach reagowania na incydenty.

Jeśli natomiast połączymy pojęcie odporności cyfrowej z podejściem holistycznym i procesowym oraz innymi filarami, na których opiera się DORA i NIS 2, jak również nowa uoksc, to wyjdzie na to, że firma powinna zbudować swój system cyberbezpieczeństwa na poziomie danej organizacji. Zbiór krajowych systemów cyberbezpieczeństwa stworzy natomiast unijny system cyberbezpieczeństwa. Na podobnej zasadzie w obszarze militarnym krajowe systemy cyberbezpieczeństwa stworzą system cyberbezpieczeństwa NATO. Jak widać, jest to cały łańcuch naczyń powiązanych i zagnieżdżonych systemów (a nie ram/frameworków). Podobnie wygląda cała struktura zarządzania kryzysowego.

Jeśli chodzi o testy odporności cyfrowej, to powinniśmy raczej mówić o testach całego ZSOC według ISO lub całego SOS według NIST, a nie tylko o testach penetracyjnych systemów informatycznych. Istotną kwestią jest bowiem to, że cały system odporności cyfrowej powinien działać w praktyce, a nie jedynie w teorii, żeby zaspokoić wymagania biurokratyczno-regulacyjne.

Podejście procesowe

Zgodnie z modelem SIPOC oraz definicją z normy ISO 9001 proces składa się z: zasobów (np. ITC), które wchodzą do procesu i są w nim przetwarzane, dostawców tych zasobów oraz produktów, usług lub e-usług, które są finalnym efektem realizacji tych procesów. W kwestii zasobów oraz dostawców ICT zapisy DORA są zgodne z tym modelem. Jeśli natomiast chodzi o usługi ICT, to definicja nie pokrywa się w pełni z modelem SIPOC, bo obejmuje zarówno usługi wdrożeniowe, utrzymaniowe (czyli domeny IT zgodne z ITIL), jak i usługi będące efektem realizacji procesów biznesowych (czyli e-usługi).

Pojęcie e-usług zostało wprowadzone, aby odróżnić w ten sposób efekty realizowanych procesów biznesowych w organizacji od innych usług, np. tych realizowanych przez dostawców ICT, co niestety w DORA ani NIS 2 nie zostało wyszczególnione i powoduje wiele problemów interpretacyjnych.

BAZA CMBD

Tak jak Zintegrowany System Odporności Cyfrowej (ZSOC) według ISO czy amerykański System of Systems (SOS) według NIST buduje się z różnych systemów zarządzania i frameworków (czyli zestawów zasad i narzędzi), tak proces biznesowy składa się z podstawowych elementów modelu SIPOC. Do tych elementów należą m.in. dostawcy i zasoby ICT, e-usługi oraz klienci. Informacja jest oddzielnym (innym niż zasoby ICT) zasobem, który jak paliwo przepływa przez cały proces, dlatego słusznie został on wyodrębniony w DORA w oddzielnej definicji. W tej dyrektywie osobno definiuje się zasób ICT (czyli infrastrukturę, systemy informatyczne) oraz zasób informacyjny, którym jest sama informacja. To właściwe podejście, ponieważ informacja ma odmienną specyfikę niż techniczne zasoby ICT, zatem wymaga innego traktowania. Relacje pomiędzy poszczególnymi elementami konfiguracji zgodnie z modelem SIPOC można przedstawić w następujący sposób:

• Supplier – to dostawca ICT zasobów ICT do procesu (zewnętrzny lub wewnętrzny);
• Input – to zasoby ICT dostarczane przez dostawcę ICT do procesu;
• Process – to przetwarzanie zasobów ICT w procesie;
• Output – to e-usługa, która jest efektem realizowanego procesu;
• Client – to klient zewnętrzny lub wewnętrzny, dla którego dostarczana jest e-usługa.

Na podstawie modelu SIPOC można więc stwierdzić, że usługi ICT dostarczane przez dostawcę ICT są zupełnie czymś innym niż e-usługi dostarczane klientowi końcowemu. Zgodnie z biblioteką dobrych praktyk ITIL i podejściem TQM, aby dostarczyć e-usługę klientowi końcowemu (zewnętrznemu), najpierw w firmie muszą zostać dostarczone jakieś usługi wewnętrzne. Mamy więc do czynienia z łańcuchem usług, które są ze sobą powiązane, co powinna odzwierciedlać relacja pomiędzy katalogami usług wewnętrznych i zewnętrznych. Te pierwsze są niezbędne do realizacji usług zewnętrznych i można by je porównać do półproduktów, które są niezbędne do wyprodukowania produktu końcowego.

Krytycznymi funkcjami w myśl DORA można nazwać części krytycznych procesów biznesowych, bo trudno byłoby schodzić jeszcze niżej, np. na poziom konkretnych funkcjonalności systemów ICT. Dlaczego stworzenie relacyjnego modelu składającego się z elementów konfiguracji procesów biznesowych (w szczególności procesów i funkcji krytycznych) w formie bazy CMBD jest tak ważne? Dopiero taka baza powiązań – stworzona na podstawie modelu SIPOC – umożliwi nam bowiem zidentyfikowanie wszystkich elementów konfiguracji, które są niezbędne do działania procesów biznesowych, co umożliwi połączenie świata technologii ze światem biznesu. Dlatego baza CMBD powinna zostać przygotowana przynajmniej dla wszystkich procesów krytycznych w organizacji. Tylko w ten sposób organizacja będzie w stanie realnie zarządzać ciągłością działania tych procesów krytycznych.

Akcja i reakcja

W drugiej części artykułu zajmiemy się kolejnymi filarami, na których opierają się DORA i NIS 2. Spojrzenie na trzy pierwsze wystarcza jednak, by zrozumieć, że oba te akty prawne wymagają czegoś więcej niż teoretycznej cyberodporności. Podejście holistyczne oznacza zebranie wszystkich składników naszej infrastruktury w jeden spójny, współdziałający system. Ponadto musimy nim zarządzać proaktywnie – nie wystarczy czekać na incydenty, które się wydarzą, ale trzeba przewidywać ich wystąpienie i być w stanie odtworzyć nie tylko środowisko IT czy infrastrukturę krytyczną, ale również przywrócić w jak najkrótszym czasie działanie całych krytycznych procesów biznesowych, a co za tym idzie e-usług dla klientów. To jedna z podstaw systemu odporności cyfrowej, który nie tylko obroni nasze zasoby ICT, ale też ustandaryzuje wszystkie działania w jedną całość, co pozwoli spełnić wymagania prawno-regulacyjne stawiane przed podmiotami w DORA i NIS 2.

---

Autor

Marek Prasoł

Autor jest absolwentem Wydziału Prawa i Administracji Uniwersytetu im. Adama Mickiewicza w Poznaniu oraz studiów podyplomowych na kierunku aplikacje internetowe i mobilne. Posiada m.in. certyfikat audytora wiodącego ISO 27001, audytora wiodącego ISO 22301, ITIL oraz specjalisty ds. rodo. W przeszłości zajmował się wdrażaniem oraz audytowaniem zarówno systemów informatycznych, serwisów internetowych i aplikacji mobilnych, jak również systemów zarządzania bezpieczeństwem informacji – ISO 27001, zarządzania ryzykiem – ISO 31000, zarządzania ciągłością działania – ISO 22301 oraz zarządzania jakością usług ICT – ISO 20000 dla czołowych firm w Polsce.