Rządowe Centrum Bezpieczeństwa

Witold Skomra – Rządowe Centrum Bezpieczeństwa

W nocy z 9 na 10 marca w serwerowni OVHcloud w Strasburgu we Francji wybuchł pożar. W jego wyniku wiele firm światowych utraciło część swoich danych lub miało problemy z dostępnością do swoich serwisów. Dotyczyło to również firm polskich. Sama informacja jest interesująca z dwóch powodów. Po pierwsze świadczy o błędach w zarządzaniu bezpieczeństwem w firmie dotkniętej pożarem. Zniszczeniu lub uszkodzeniu uległy zarówno serwery podstawowe jak i zapasowe. Co prawda były one umieszczone w dwóch różnych blokach, ale zlokalizowanych obok siebie. W efekcie, pożar w jednym obiekcie miał destrukcyjny wpływ na infrastrukturę w obiekcie sąsiadującym. Drugi powód, dla którego informacja jest interesująca to fakt, że nadal wiele osób dziwi się, że zdarzenie w jednym miejscu może mieć wpływ na firmy (a właściwie na ich procesy) realizowane nieomal w każdym możliwym zakątku świata.

Tego typu zdarzenia nazywamy zagrożeniami wynikającymi ze współzależności i nie trzeba sięgać do Francji, by wskazać skutki takich współzależności. W wyniku powodzi w Jenie (RFN), 11 czerwca 2013 r. przestały funkcjonować systemy rowerów miejskich w Warszawie, Wrocławiu, Poznaniu i Opolu. Przyczyną było zalanie serwerów, które utrzymywały aplikację rozliczającą klientów tych systemów. Pożar mostu Łazienkowskiego 14 lutego 2015 r. wywołał zakłócenia w funkcjonowaniu usług internetowych i telekomunikacyjnych. Przyczyną zakłócenia było uszkodzenie traktów światłowodowych umieszczonych pod mostem. Pożar hurtowni warzyw 31 stycznia 2019 r., w wyniku którego doszło do uszkodzenia infrastruktury sieci T-mobile i ograniczenia skali świadczonych usług (w tym ostatnim przypadku należałoby dodać, że dzięki właściwie prowadzonemu systemowi utrzymania ciągłości działania, w wyniku pożaru doszło jedynie do ograniczenia skali świadczonych usług, a nie do ich przerwania).

Wszystkie te przypadki są tylko dowodem na poprawność twierdzenia, że wszystkie współczesne organizacje działają w warunkach współzależności, a zasięg tych współzależności zaczyna obejmować cały świat. Formalnie współzależności możemy podzielić na następujące kategorie: [1]

• współzależność fizyczna – fizyczne połączenie wyjścia i wejścia, przykładowo usługa lub produkt dostarczane przez jedną infrastrukturę są niezbędne, by inna infrastruktura mogła funkcjonować;
• współzależność cyfrowa – działalność infrastruktury jest uzależniona od informacji przesyłanych systemami transmisji danych;
• współzależność geograficzna – kilka obiektów lub rodzajów infrastruktury znajduje się w swoim bezpośrednim sąsiedztwie (w efekcie zagrożenie w jednym obiekcie może oddziaływać na pozostałe);
• współzależność logiczna – dwa lub więcej rodzajów infrastruktury wzajemnie na siebie oddziałuje bez żadnego powiązania fizycznego, cyfrowego czy geograficznego.

Z przytoczonych zdarzeń można by wyciągnąć wniosek, że współzależności są jedynie zagrożeniem, które należy wyeliminować. Nic bardziej mylnego. Istnienie współzależności pomiędzy systemami jest w zasadzie elementem pożądanym i niezbędnym dla dalszego rozwoju współczesnych społeczeństw. W efekcie takich powiązań powstają systemy złożone [2] (Systems of Systems – SoS). Standard „Systems and Software Engineering – System Life Cycle Processes ISO/IEC/IEEE” [3] definiuje to pojęcie następująco. SoS jest zbiorem systemów realizujących zadanie, jakiego żaden z tych systemów nie byłby w stanie realizować samodzielnie. Jednocześnie, każdy z systemów zachowuje własną strukturę zarządzania, cele i zasoby w ramach skoordynowanych działań, mających na celu osiągnięcie wspólnego efektu [4]. Niektóre z systemów złożonych bazują na infrastrukturze globalnej, której ewentualna dysfunkcja będzie powodować skutki ogólnoświatowe. Przykłady takiej infrastruktury „bazowej” to:

• sieć szkieletowa internetu zapewniająca ogólnoświatową wymianę danych pomiędzy węzłami regionalnymi;
• sieć SWIFTnet, zarządzana przez Stowarzyszenie na rzecz Światowej Międzybankowej Telekomunikacji Finansowej (Society for Worldwide Interbank Financial Telecommunication – SWIFT), łącząca poszczególne banki, giełdy, domy maklerskie i inne instytucje finansowe;
• systemy pozycjonowania (GPS, GLONASS, Galileo), na bazie których funkcjonują zarówno samochody autonomiczne czy drony, jak i całe systemy, jak np. system kierowania ruchem morskim i lotniczym.

W efekcie nawet jeśli posiadacze systemów opartych na systemie bazowym mają świadomość jego możliwej dysfunkcji, to nie są w stanie określić ryzyka z tym związanego ani zarządzać tym ryzykiem. Pojawia się więc pytanie – jak zarządzać bezpieczeństwem w systemach złożonych? Klasycznie, organizacje zabezpieczają się przed negatywnym wpływem awarii poprzez zawieranie umów SLA (Service Level Agreement – umowa o gwarantowanym poziomie świadczenia usług) oraz poprzez weryfikację dostawców. Wiarygodny dostawca musi posiadać stosowne certyfikaty i raporty z audytów. Często przeprowadza się inspekcję bezpośrednio u dostawców, by potwierdzić prawdziwość deklarowanej ciągłości świadczenia usług czy dostaw. Jednak ten sposób kontroli ryzyka coraz częściej jest niewystarczający. W obszarze usług cyfrowych łańcuch dostawców ma złożoność fraktala – dostawcy i usługodawcy też mają swoich dostawców i usługodawców, a ci kolejnych. Z praktycznego punktu widzenia, łańcuch dostaw przemysłu telekomunikacyjnego jest nieskończenie złożony i stale się rozwija [5]. W efekcie nikt nie ma zdolności to wiarygodnego sprawdzenia czy kontrahent utrzyma deklarowany poziom świadczenia usługi czy nie. Pół biedy, jeśli awaria dotyczy relacji biznesowych. Tu ewentualne straty można ubezpieczyć. Gorzej, jeśli dojdzie do zakłócenia usług kluczowych dla bezpiecznego funkcjonowania społeczeństwa. Z tego powodu coraz częściej regulacją poziomu bezpieczeństwa u operatorów usług kluczowych zajmuje się państwo. Pierwszymi symptomami tego trendu była dyrektywa RODO[6] oraz NIS[7]. Obecnie, na forum Komisji Europejskiej trwają prace nad dwoma dokumentami, które mają być ze sobą komplementarne. Jest to znowelizowana dyrektywa NIS (tzw. NIS2) oraz zupełnie nowa dyrektywa, dotycząca odporności podmiotów krytycznych (tzw. Dyrektywa CER) [8]. Generalnie, każdy operator mający wpływ na realizację usługi o kluczowym znaczeniu dla państwa i jego obywateli będzie zobowiązany do wdrożenia minimalnych standardów bezpieczeństwa, przeprowadzania analizy ryzyka i wszystkich innych elementów składających się na proces zarządzania ryzykiem i utrzymania ciągłości działania. Rygorowi temu mają być poddane wszystkie podmioty z danego obszaru, a nie tylko te, którym udało się udowodnić powiązanie z operatorem usługi kluczowej. Wskazywanie podmiotów krytycznych nie będzie ograniczone granicami państw. Każdy kraj UE będzie mógł wskazać podmiot zlokalizowany w innym państwie, jeśli tylko uzna, że jego działalność jest związana z utrzymaniem usługi kluczowej. Jeśli 1/3 państw uzna podmiot za krytyczny, automatycznie stanie się podmiotem krytycznym dla całej UE.

I tu możemy powrócić do pożaru omawianego na wstępie. W artykułach omawiających ten przypadek po raz kolejny wskazywano, że przecież wystarczyło przestrzegać zasad bezpieczeństwa zasobowego, by pomimo pożaru do utraty danych nie doszło. Jedną z tych zasad jest reguła podwójnego, a niekiedy potrójnego zabezpieczenia. Wśród informatyków jest ona znana pod nazwą 3,2,1 (minimum trzy kopie, minimum na dwóch urządzeniach, z czego minimum jedno jest zlokalizowane poza siedzibą macierzystej organizacji).

Jak zwykle wszyscy są mądrzy po szkodzie. Jednocześnie presja zawierania umów po jak najniższej cenie powoduje, że nie zawierają one zazwyczaj klauzul odpowiedzialności za skutki utraty danych. To z kolei osłabia wolę usługodawcy inwestowania w bezpieczeństwo na odpowiednio wysokim poziomie. W efekcie opłaca się nie inwestować w bezpieczeństwo. Wygląda na to, że po wejściu w życie dyrektywy CER niezależnie od zawieranych umów pomiędzy kontrahentami, jeśli tylko podmiot będzie związany z utrzymaniem usługi kluczowej, to z mocy prawa będzie zobowiązany do utrzymywania właściwego poziomu bezpieczeństwa. Bez znaczenia będzie fakt, że firma zlokalizowana jest we Francji, a świadczy usługi w Polsce. Jeśli jednak ten poziom bezpieczeństwa nie będzie właściwy, to podmiot krytyczny musi się liczyć z konsekwencjami finansowymi, gdyż w projektowanej dyrektywie znalazł się rozdział zatytułowany „sankcje”.

Przypisy

[1] Rinaldi S.M., Peerenboom J.P., Kelly T.K. Identifying, understanding, and analyzing critical infrastructure interdependencies. IEEE Control Systems Magazine 2001;11-25
[2] Takie tłumaczenie pojęcia „Systems of Systems” nie jest jeszcze ugruntowane w literaturze krajowej.
[3] Systems and Software Engineering – System Life Cycle Processes. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions / Institute of Electrical and Electronics Engineers, ISO/IEC/IEEE 15288:2015.
[4] Metodologia definiowania, wyodrębniania, modelowania i analizowania problemów związanych z funkcjonowaniem systemów złożonych uzyskało nazwę inżynierii systemów złożonych (System of systems engineering SoSE). Zob. szerzej Międzynarodowa Rada ds. Inżynierii Systemów Spraw https://www.incose.org/ [dostęp 1.12.2018].
[5] https://www.kozminski.edu.pl/pl/review/bezpieczenstwo-lancucha-dostaw
[6] Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016 r. w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych i w sprawie swobodnego przepływu takich danych oraz uchylenia dyrektywy 95/46/WE.
[7] Dyrektywa Parlamentu Europejskiego i Rady (UE) 2016/1148 z dnia 6 lipca 2016 r. w sprawie środków na rzecz wysokiego wspólnego poziomu bezpieczeństwa sieci i systemów informatycznych na terytorium Unii
[8] https://ec.europa.eu/home-affairs/sites/homeaffairs/files/pdf/15122020_proposal_directive_resilience_critical_entities_com-2020-829_en.pdf

Źródła:
1. https://tvn24.pl/biznes/ze-swiata/ovh-pozar-serwerowni-w-strasburgu-nie-dziala-wiele-stron-internetowych-w-polsce-5040011
2. https://www.computerworld.pl/news/Pozar-w-serwerowni-OVH,426085.html
3. https://wiadomosci.wp.pl/strasburg-pozar-w-serwerowni-ovh-utrudnienia-w-internecie-6616562457221696a
4. https://www.money.pl/gospodarka/pozar-serwerowni-ovh-sparalizowal-internet-znamy-zasieg-szkod-6617217694849632a.html