Sformułowanie bezpieczeństwo procesowo-proceduralne dla laika może być niezrozumiałe lub mylące, gdyż zdarza się, że kojarzy się z technologią chemiczną, a nie ze światem cyberbezpieczeństwa. Nic podobnego.
Jest to termin związany z nauką o bezpieczeństwie i ma zastosowanie zarówno w szeroko rozumianym bezpieczeństwie, bezpieczeństwie informacji, czy – bardziej szczegółowo biorąc – w obszarze cyberbezpieczeństwa.
Bezpieczeństwo procesowo-proceduralne jest procesem, podobnie jak bezpieczeństwo informacji, którego jest elementem składowym, jego podprocesem. Można powiedzieć, w pewnym rzecz jasna uproszczeniu, że każdego rodzaju bezpieczeństwo, niezależnie od jego rodzaju, opiera się na dwóch podstawach:
- bezpieczeństwie technicznym (w różnym tego słowa rozumieniu, ale generalnie chodzi tu o narzędzia, urządzenia, systemy, oprogramowanie etc.),
- bezpieczeństwie procesowo- proceduralnym (funkcjonujące w organizacji procesy i opisujące je procedury, oparte o funkcjonujące standardy, tzw. dobre praktyki, normy itp.).
Można powiedzieć, że te dwie podstawy to jakby dwa zestawy klocków, z których projektujący zabezpieczenia czerpie składniki do budowy systemu, w zależności od funkcjonalności, które projektowany system ma posiadać. Efektem może być:
- system bezpieczeństwa,
- system bezpieczeństwa informacji,
- cyberbezpieczeństwo organizacji, państwa etc.
Każdy z budowanych systemów może być trochę inny w zależności od kontekstu zewnętrznego, oczekiwań wobec niego, wymagań, które ma spełnić.
W obszarze bezpieczeństwa zbliżonym do IT warto uwzględnić podejście definiowane przez tak ostatnio modne terminy jak security by default czy security by design.
Niestety, ale zwykle takie modelowe podejście do projektowania bezpieczeństwa jest ideą, która nijak ma się do rzeczywistości.
Często, zwłaszcza w świecie cyberbezpieczeństwa można usłyszeć, że prawdziwe bezpieczeństwo zapewnia tylko ta twarda podstawa, czyli bezpieczeństwo techniczne, a bezpieczeństwo procesowo-proceduralne to są jakieś takie „fanaberie,” które traktowane są jak „piąte koło u wozu”, nikomu niepotrzebne, bo praktycznie nic one nikomu nie dają, generują koszty, ewentualnie (to czasami jedyny powód do ich tolerowania) mogą ustrzec przed zapłaceniem kary za niespełnienie wymogów wynikających z zapisów prawnych.
Jest w tym odrobina prawdy, bo wszystkie systemy ISO, czy procesowo-podobne są przeznaczone do zarządzania bezpieczeństwem, monitorowania go, poprawiania, ulepszania, wymuszania pewnych działań, ale nie są stworzone do realnych działań. Są z natury miękkie, w odróżnieniu od tych twardych, które proponuje bezpieczeństwo techniczne.
Z drugiej strony opieranie bezpieczeństwa systemów wyłącznie na bezpieczeństwie technicznym jest błędem, ponieważ systemy budowane i konserwowane bez podstaw opartych o rzetelną analizę ryzyka są słabo dopasowane do organizacji, nie uwzględniają zagrożeń wynikających z kontekstu (wewnętrznego i zewnętrznego) organizacji, nie są odpowiednio zarządzane, bo nikt nie pamięta o zapewnieniu odpowiednich zasobów, cyklicznej pielęgnacji i nadzorze. Aktualizacje systemów, kopie zapasowe są robione od czasu do czasu, wtedy kiedy się komuś o tym przypomni, lub drobna awaria zwróci uwagę na potrzebę odzyskania kopii. Uprawnienia są przydzielane na podstawie rozmowy na korytarzu organizacji, a administratorzy pracują na kontach uprzywilejowanych. Przykłady można mnożyć. Pełen chaos i luz. Ktoś może powiedzieć, że systemy tak działają i nic się nie dzieje. Owszem działają, ale działają do smutnego końca, kiedy coś się komuś stanie z jego zasobami, nastąpi wyciek danych, kradzież danych, awaria sprzętu, która spowoduje szkody. Wtedy pojawią się roszczenia klientów, zjawią się zewnętrzni audytorzy z niewygodnymi pytaniami i luźne życie chaotycznych administratorów bardzo się skomplikuje. Nasuwa się pytanie, czy w tym kierunku chcemy iść?
Wydaje się, że nie jest to optymalny kierunek i wielu administratorów systemów, ich właścicieli powoli zdaje sobie sprawę, że należy znaleźć złoty środek, że trzeba wymyśleć jakiś sposób na sensownie budowany system teleinformatyczny, który będzie obsługiwany przez świadomych swoich zadań administratorów, którzy na bieżąco się szkolą i wiedzą, że połączenie dwóch opisywanych wcześniej podstaw, czyli bezpieczeństwa technicznego i bezpieczeństwa procesowo-proceduralnego jest niezbędne, bo po prostu przynosi to wszystkim korzyści.
W oparciu o różnego rodzaju zrealizowane projekty można stwierdzić, że opisywany w poprzednim akapicie odsetek administratorów czy właścicieli systemów wciąż nie jest duży i dalej dużo jest systemów, które mają niepoprawnie wprowadzone i uregulowane kwestie związane z bezpieczeństwem procesowo-proceduralnym.
Spotkane nieprawidłowości procesowo-proceduralne można usystematyzować według następujących problemów:
- Brak procedur związanych z zarządzaniem systemami
W bardzo wielu organizacjach brak jest jakiejkolwiek dokumentacji związanej z bezpieczeństwem procesowo-proceduralnym. Administratorzy tłumaczą to natłokiem zajęć, licznymi obowiązkami, które nie pozwalają im na zajęcie się tak zwanymi „papierami”. Czasami po fakcie jakiejś nagłej kontroli, audytu są one tworzone, uzupełniane tak, aby były, bez żadnego głębszego sensu. Często administratorzy mówią, że w pracy posługują się standardami, tzw. „dobrymi praktykami”. Niestety, ale w żaden sposób nie są sobie w stanie przypomnieć, jak nazywały się te wykorzystywane przez nich standardy, zalecenia itp.
- Jeśli już występują dokumenty dotyczące zarządzania systemami, bezpieczeństwem IT to są one związane z polityką bezpieczeństwa w rozumieniu starego rozporządzenia do ustawy o ochronie danych osobowych tj. rozporządzenia Ministra Spraw Wewnętrznych i Administracji z dnia 29 kwietnia 2004 roku w sprawie dokumentacji przetwarzania danych osobowych oraz warunków technicznych i organizacyjnych, jakim powinny odpowiadać urządzenia i systemy informatyczne służące do przetwarzania danych osobowych.
Bardzo często dokumentacja w organizacji wzoruje się na tym dokumencie, bo nawet jeśli układ graficzny dokumentu jest trochę zmieniony, to i tak zakres merytoryczny jest dokładnie taki jak w rozporządzeniu. Często dokumenty nowe, pisane, tworzone pod kątem RODO mają układ taki jak w wymienionym wyżej rozporządzeniu. Bardzo ciekawa jest siła wpływu tego aktu prawnego na pokolenia administratorów.
Ciekawym jest też to, że nie sięgają oni do wzorca, jakim mógłby być załącznik A do normy ISO 27001, gdzie jest wymieniony katalog procedur wymaganych w Systemie Zarządzania Bezpieczeństwem Informacji. Wzorcowy katalog procedur, które powinien realizować system zgodny z normą rodziny ISO 27000.
Gdyby administratorzy skorzystali z rozporządzenia Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych także znaleźliby odniesienie do norm, jakie powinni zastosować w swojej pracy.
- W niektórych organizacjach twierdzi się, że posiadają one System Zarządzania Bezpieczeństwem Informacji (SZBI), ale nie są to systemy zbudowane w oparciu o normy np. z rodziny ISO 27000. Opierają się one przeważnie na wzmiankowanym wcześniej nieaktualnym rozporządzeniu Ministra Spraw Wewnętrznych i Administracji z dnia 29 kwietnia 2004 roku w sprawie dokumentacji przetwarzania danych osobowych oraz warunków technicznych i organizacyjnych, jakim powinny odpowiadać urządzenia i systemy informatyczne służące do przetwarzania danych osobowych. Napisana zgodnie z rozporządzeniem polityka bezpieczeństwa oparta o wymienioną w rozporządzeniu politykę bezpieczeństwa danych osobowych i instrukcję zarządzania systemem informatycznym służącym do przetwarzania danych osobowych jest wprowadzana zarządzeniem i traktowana jako dokumentacja systemu SZBI. Należy zwrócić uwagę, że zbudowany w oparciu o taką politykę rzekomy system nie wyczerpuje znamion SZBI, bo nie jest cyklicznie aktualizowany, zarządzany, pielęgnowany, nie adresuje też innych kwestii opisanych w normie.
Warto dodać, że jeśli organizacje nie chcą korzystać z płatnych norm ISO, to mogą skorzystać z darmowych dokumentów NIST, a jeśli mają problem z tłumaczeniem tych dokumentów na język polski, to mogą sięgnąć do Narodowych Standardów Cyberbezpieczeństwa opartych o przetłumaczone na język polski dokumenty NIST.
- Brak dokumentacji związanej z procesem szacowania ryzyka, analizą ryzyka, itp.
Organizacje generalnie nie posiadają dokumentacji związanej z analizą ryzyka. Jeśli jakaś dokumentacja jest, to jest ona zrobiona na potrzeby ochrony danych osobowych. W tym miejscu warto dodać, że w zakres braków związanych z dokumentacją dotyczącą analizy ryzyka należy dodać braki związane z inwentaryzacją zasobów IT. Rzecz jasna, nie chodzi tu o inwentaryzację księgową. Trudno zarządzać czymś, o czym się nie wie, lub nie ma się świadomości, że coś takiego istnieje w zarządzanej infrastrukturze. Bardzo często administratorzy nie potrafią wskazać na jakiej podstawie podjęli takie, czy inne decyzje zakupowe. W wielości przypadków rodzynkiem była sytuacja, kiedy administrator stwierdził, że pewnych rzeczy nie robi, bo tak wynika z analizy ryzyka.
Niestety, ale można powiedzieć, że analiza ryzyka traktowana jest jako coś kompletnie niepotrzebnego, a jeśli trzeba ją zrobić, to tylko z uwagi na jakiś obowiązek narzucony przez przepisy prawa. Administratorzy nie widzą w tym żadnej korzyści (poza bardzo nielicznymi wyjątkami).
- Brak planów ciągłości działania
W organizacjach kwestia ciągłości działania traktowana jest z dużą nonszalancją. Nie ma dedykowanych dokumentów poświęconych tym zagadnieniom. Czasami zdarza się akapit lub dwa w polityce bezpieczeństwa rozumianej tak, jak w poprzednich punktach, szczególnie w punkcie 3.
- Brak systemowego zarządzania tożsamością i uprawnieniami.
W analizowanych organizacjach przydzielanie uprawnień czasami odbywa się w bardzo luźny sposób, bez dowodów potwierdzających przydzielenie uprawnień do zasobów. Jeśli nawet jest to robione w sposób zgodny z zasadami, to brak jest udokumentowanych procedur.
- Brak systemowego zarządzania incydentami, podatnościami.
Jeśli coś w tym zakresie jest realizowane od strony procesowo-proceduralnej, to zapisane jest znowu jako element polityki bezpieczeństwa rozumianej tak, jak w poprzednich punktach, szczególnie w punkcie 3. Incydenty są opisywane wyłącznie pod kątem ochrony danych osobowych, natomiast inne są przeważnie bagatelizowane. Zdarza się, że jako rejestr incydentów, zdarzeń traktowany jest UTM (rejestry i logi urządzenia) lub logi systemów zabezpieczających.
- Brak podejścia usługowego do zarządzania systemami IT (ISO 20000, ITIL)
Można zaobserwować delikatny rozwój zainteresowania tego typu zagadnieniami, ale bardziej w charakterze ciekawostki, odbywania szkoleń w tym kierunku itp. Praktyczna wiedza i doświadczenie w tym zakresie jest znikome, i bardziej z zakresu biblioteki ITIL niż ISO 20000.
- Brak dokumentacji dotyczącej planowania rozwoju zarządzanych systemów.
Realizowane inwestycje, zakupy sprzętu nie mają uzasadnienia w planach rozwoju. Jeśli takie planowanie jest robione, to być może na innych, wyższych szczeblach organizacyjnych. Na poziomie wykonawczym, jeśli w zakresie informatyków pojawiają się środki finansowe, to momentalnie się rozdysponowywane, gdyż potrzeb jest bardzo dużo, a środków mało. Konsekwencją tego jest brak planowania, bo trudno planować w dalszej perspektywie, skoro trzeba zaspokajać bieżące, najpilniejsze potrzeby. W związku z tym w przedstawianych do wglądu analizowanych dokumentach trudno znaleźć takie elementy.
Podobniej jest z wzmiankowanym wyżej ryzykiem (punkt 4). W zasadzie nie spotyka się organizacji (jeden stwierdzony wyjątek), gdzie jakiekolwiek działania związane z cyberbezpieczeństwem , zarządzaniem systemami były oparte lub powiązane z analizą ryzyka. Nie dostrzega się związku między stwierdzonymi ryzykami, a mitygacją tych zagrożeń poprzez odpowiednie inwestycje, inne działania zabezpieczające. Świadczy to albo o źle prowadzonym procesie analizy ryzyka w organizacji, albo o silosowości, złym obiegu informacji, braku powiązań między procesami organizacyjnymi.
Podsumowanie
Jak widać z przedstawionych uwag, w zakresie bezpieczeństwa procesowo-proceduralnego jest wiele do zrobienia. Wydaje się, że warto zacząć od zwrócenia uwagi na to, że bezpieczeństwo informacji, czy cyberbezpieczeństwo to jest permanentny proces, nigdy nie skończony, wymagający ciągłej pracy.
Ważne jest zachowanie cykliczności tego procesu, ciągłych aktualizacji nie tylko dokumentacji, ale także systemów, wdrażania poprawek, planowych udoskonaleń, inwestycji, szkoleń itp.
Procedury mają być narzędziem do kontroli parametrów systemów bezpieczeństwa, mają pomagać i przypominać administratorom o tym, co mają zrobić. Z drugiej strony dokumentacja systemu ma być też dla administratorów pamięcią zmian i udoskonaleń dokonanych przez nich w systemie. Ma ona zabezpieczać dowody wykonanych prac, ślady po incydentach itp.
Dokumentacja ma nie tylko być „karą Bożą” dla administratorów, ale także i wybawieniem dla nich, kiedy właśnie na podstawie dokumentacji i zebranych zgodnie z nią logów, dzienników zdarzeń można udowodnić, że administrator wykonał swoją pracę, odpowiednio skonfigurował, zabezpieczył system, zabezpieczył ślady po włamaniu i wina nie leży po jego stronie, tylko gdzieś indziej, w innymi miejscu organizacji.
