Source: https://essa.pro/aktualnosci/ewolucja-wymagan-dla-systemow-zarzadzania-bezpieczenstwem/
Timestamp: 2020-07-15 05:12:02+00:00

Document:
EWOLUCJA WYMAGAŃ DLA SYSTEMÓW ZARZĄDZANIA BEZPIECZEŃSTWEM | ESSA
HomeBlogAktualnościEWOLUCJA WYMAGAŃ DLA SYSTEMÓW ZARZĄDZANIA BEZPIECZEŃSTWEM
Systemy zarządzania bezpieczeństwem ewoluują i zmierzają w kierunku przeniesienia odpowiedzialności za stworzenie ram i zakresu systemów z prawo-twórcy (np. ustawodawcy) czy organizacji międzynarodowej (w przypadku ISO) na przedsiębiorcę. W przepisach czy normach nowego podejścia wskazywane są jedynie efekty, jakie muszą zostać osiągnięte i niektóre działania, jakie należy podjąć bez formalnego wskazania metod, form czy wymaganych dokumentów. Idealnym przykładem jest ochrona danych osobowych i wymagania RODO, które zamykają się praktycznie w kilku punktach w art. 5.
Niestety system jednak nie zawsze funkcjonuje właściwie. W tym momencie pojawia się zagadnienie „audyt bezpieczeństwa”, który wskazuje nieprawidłowości prowadzące do fatalnego funkcjonowania całego systemu. To z kolei jest już niezgodność z fundamentem aktu prawnego czy normy.
Przykład pozornych zgodności
Najpopularniejszym tematem ostatnich miesięcy jest ochrona danych osobowych, weźmy ją zatem pod lupę i mamy doskonały przykład ewolucji systemów zarządzania bezpieczeństwem.
Dla zobrazowania dwa przepisy prawa w tej samej materii:
Przepis pierwszy – art. 36 Ustawy o ochronie danych osobowych z 1997 roku:
,,Administrator danych jest obowiązany zastosować środki techniczne i organizacyjne zapewniające ochronę przetwarzanych danych osobowych odpowiednią do zagrożeń oraz kategorii danych objętych ochroną, a w szczególności powinien zabezpieczyć dane przed ich udostępnieniem osobom nieupoważnionym, zabraniem przez osobę nieuprawnioną, przetwarzaniem z naruszeniem ustawy oraz zmianą, utratą, uszkodzeniem lub zniszczeniem.”
Przepis drugi – art. 32 RODO:
,,Uwzględniając stan wiedzy technicznej, koszt wdrażania oraz charakter, zakres, kontekst i cele przetwarzania oraz ryzyko naruszenia praw lub wolności osób fizycznych o różnym prawdopodobieństwie wystąpienia i wadze zagrożenia, administrator i podmiot przetwarzający wdrażają odpowiednie środki techniczne i organizacyjne, aby zapewnić stopień bezpieczeństwa odpowiadający temu ryzyku, (…)’’
Oba przepisy są do siebie zbliżone treścią w aspekcie organizacyjnym.
Dzisiejszy artykuł jest pierwszym z cyklu ,,Zarządzanie bezpieczeństwem” i w niewielkim stopniu skupia się na kwesti różnic między ZAGROŻENIEM dla danych osobowych a RYZYKIEM wynikającym z zagrożeń. Meritum będzie dla nas ukazanie podejścia zgodnościowego (compliance) w przypadku aktów prawnych o różnym stopniu szczegółowości, w których z jednej strony mamy do czynienia z przepisami wskazującymi dokładnie zakres, zawartość dokumentacji oraz konieczne działania (tzw. instrukcyjne), z drugiej akty prawne wskazujące tylko efekt, do którego należy dążyć, jak np. RODO.
Ustawa z 1997 roku zobowiązała organizacje do opracowania i wdrożenia dwóch głównych dokumentów:
Polityki bezpieczeństwa danych osobowych, która była w rzeczywistości bardziej planem ochrony danych osobowych,
Dodatkowo rozporządzenie wskazywało trzy poziomy ochrony i obowiązkowe rozwiązania zależnie od pewnych okoliczności. Np. podłączenia do sieci Internet.
Żaden z tych dokumentów nie wskazywał konieczności wykonania analizy zagrożeń w odniesieniu do art. 36 Ustawy o ochronie danych osobowych, mimo że zapis był dość jasny. Ochrona danych osobowych miała być odpowiednia do zagrożeń i kategorii przetwarzanych danych.
Analogicznie do RODO, dziś również żaden przepis nie wskazuje konieczności wykonania analizy ryzyka w odniesieniu do art. 32 RODO, który dość podobnie określa, że administrator wdraża środki organizacyjne i techniczne (środki ochrony) odpowiednie do ryzyka. Różnicą jest wyjście o krok dalej w RODO, gdzie poza analizą zagrożeń, należy przy planowaniu ochrony wziąć pod uwagę przede wszystkim ryzyko.
DPIA – czyli Data Protection Impact Assessment (ocena wpływu na ochronę danych osobowych) nie jest analizą ryzyka.
Obecni Trenerzy Europejskiej Akademii Bezpieczeństwa i Ochrony wskazują, iż na kilkaset audytowanych organizacji do wymagań Ustawy o ochronie danych osobowych z 1997 r. ponad 90% nie posiadało analizy zagrożeń.
Niestety formalnie trudno było wskazać to jako niezgodność, ponieważ literalnie trzymano się przepisów prawa, a ABI (administrator bezpieczeństwa informacji) zadawał pytanie „Z czego wynika wymaganie wykonania analizy zagrożeń?”.
Uzasadnienie, że ochrona powinna być odpowiednia do zagrożeń i kategorii przetwarzanych danych, było niewystarczające, a niezgodność często przybierała formę potencjału doskonalenia. I nie trafiały na podatny grunt argumentacje, że ciężko będzie wykazać zgodność z art. 36 przed organem (w tym czasie GIODO), w przypadku braku analizy zagrożeń i uzasadnienia stosowania konkretnych zabezpieczeń.
Jaki jest stan faktyczny? Czyli bezpieczeństwo osób, których dane są przetwarzane.
W wielu przypadkach dane osobowe były przechowywane w magazynach, w miejscach ogólnie dostępnych, narażonych na zniszczenie i utratę lub kradzież. Jeden z krytycznych przykładów, jaki przewijał się niemalże za każdym razem to przechowywanie danych osobowych w aktach pracowniczych po zakończeniu zatrudnienia właśnie w niezabezpieczonych magazynach, do których dostęp miał prawie każdy lub – co gorsza – pokojach pracowników, na regałach z innymi dokumentami. Brak oceny zagrożeń zniszczeniem w wyniku niewłaściwych parametrów środowiskowych (temperatura, wilgotność, oświetlenie) skutkował wyblaknięciem arkuszy papieru i brakiem możliwości odczytania zawartych w nich informacji (zniszczenie, utrata informacji). Dla przypomnienia dostępność nie była atrybutem bezpieczeństwa ujętym w krajowych regulacjach.
RODO zawiera dość podobne wymaganie, skupiające się co prawda na ryzyku (analiza zagrożeń powinna być częścią lub elementem poprzedzającym ocenę ryzyka). Dziś już nikt nie ma wątpliwości, że całość zarządzania ochroną danych osobowych zaczyna się właśnie od analiz zagrożeń dla procesu przetwarzania danych osobowych i ryzyka z nim związanego. Nie ma możliwości ucieczki w „quasi-compliance” wskazując, że wszystkie wymagane dokumenty są opracowane i wdrożone, bo na dziś RODO wymaga naprawdę niewielkiej ilości dokumentacji.
W nowym podejściu oceniamy ryzyko naruszenia praw i wolności osoby, a tutaj w odniesieniu do przykładu akt pracowniczych takie występuje, w zakresie nawet naruszenia prawa do ochrony zdrowia i życia. Wynika ono z braku możliwości wystawienia druku Rp7 (zmaterializowane zagrożenie zniszczenia danych) i uzyskania właściwej dla wypracowanych okresów emerytury czy renty (ryzyko pośrednie – obniżenie świadczeń).
W całym artykule posługujemy się określeniem „system zarządzania bezpieczeństwem”. Wdrożenie i realizację tego procesu zalecamy przy wszystkich systemach. Niezależnie od tego, jakie wymagania i jak szczegółowe są oraz czy pojawią się w nowych regulacjach, prawidłowo zrealizowany proces zarządzania bezpieczeństwem pozwoli uzyskać zgodność za każdym razem.
Tam, gdzie nie będzie wskazanych wprost wymagań co do dokumentacji, szkoleń itp. łatwo jest wykazać podejście oparte o ryzyko, ponieważ na identyfikacji zagrożeń oraz analizie ryzyka opierają się wszystkie zabezpieczenia, a ocena sprawności i skuteczności systemu stanowi jeden z kluczowych elementów (dla RODO – art. 5.2).
W tych rozwiązaniach, w których nadal występują wymagania w zakresie dokumentacji czy stosowanych zabezpieczeń, podejście systemowe również pozwala na uzyskanie zgodności. Ponieważ nie obejmuje ono narzucenia konkretnych rozwiązań, a ma na celu uporządkowanie kolejności wykonywanych działań, nadając im sens i zrozumienie.
Pozostańmy dalej przy RODO, jako doskonałym przykładzie. Mimo że wskazuje na podejście nazywane „zasobowym” (dane osobowe to zasób, czasem nazywany aktywem), a więc ochrona nakierowana jest na uzyskanie i utrzymanie określonego poziomu bezpieczeństwa dla tego konkretnego zasobu, warto pamiętać, że uzyskanie tego jest poprzedzone szeregiem czynności.
Realizując od początku do końca proces zarządzania bezpieczeństwem, który jest zaszyty praktycznie w całym RODO, ale również innych regulacjach związanych z bezpieczeństwem (BHP, ochrona ppoż, ochrona fizyczna, cyberbezpieczeństwo).
Dziś skupimy się na jednym z elementów i przedstawimy podstawowy przebieg, rozwijając go w kolejnych artykułach i uzupełniając m.in. o świadomość uczestników (interesariuszy) oraz ich udział w procesie zarządzania.
Etapy procesu zarządzania bezpieczeństwem
Identyfikacja i wartościowanie zasobów. Czasem nazywane etap „0”, w założeniu organizacja powinna wiedzieć, co ma i czym dysponuje. Analogicznie do zasobów rzeczowych, praktycznie każda organizacja jest świadoma posiadanych budynków, samochodów czy sprzętu. Inaczej niestety bywa przy zasobach informacyjnych i danych osobowych, dlatego ten element jest ujmowany w procesie zarządzania bezpieczeństwem jako odrębne działanie,
Identyfikacja zagrożeń, czyli źródeł niepożądanych incydentów, które mogą wykorzystać słabości (podatności) zasobów. Tu często dokonywana jest analiza zagrożeń w obszarach makrootoczenia i identyfikowane są zagrożenia i podatności nie tylko wynikające z lokalizacji i stosowanych środków, ale również otoczenie prawne, ekonomiczne, społeczne czy technologiczne. W tym etapie możliwa jest też ocena siły oddziaływania zagrożenia, a to ma wpływ na ocenę ryzyka,
Szacowanie i ocena ryzyka, czyli jakie skutki mogą zaistnieć i jakie jest prawdopodobieństwo ich wystąpienia,
Planowanie, projektowanie i wdrożenie systemu bezpieczeństwa. Na podstawie informacji zgromadzonych w poprzednich etapach organizacja dysponuje już wiedzą co do wartości zasobów (w tym kategorii danych osobowych), występujących zagrożeń, możliwego ryzyka. Na tym etapie może przystąpić do wyznaczenia celów długoterminowych (np. w dokumencie polityki bezpieczeństwa), określić sposób i termin ich realizacji (np. w dokumencie strategia bezpieczeństwa), jak i wskazać konkretne zasady i reguły (procedury i instrukcje). Oczywiście dokumentacja jest przykładowa, formalnie powinna być dokładnie taka sama jak w innych procesach w organizacji.
Postępowanie z incydentami, to obszar, który należy rozważyć zawsze. Organizacja ma do czynienia z ryzykiem, które chce zmniejszyć do poziomu akceptowalnego, a więc kluczowym elementem jest planowanie zasad postępowania z incydentami. Jako że jest to nadal ryzyko. Mniejsze, ale nadal możliwe wystąpienie.
Ocena i doskonalenie. Ostatnim elementem jest ocena systemu oraz jego doskonalenie. Ocena to najczęściej audyt wykonywany w dwóch obszarach – zgodności (compliance), jak i skuteczności przyjętych rozwiązań (bezpieczeństwo). Ten drugi aspekt jest niezbędny. Audyty zgodnościowe wskażą nam tylko poziom zgodności i dążenie do jego uzyskania i utrzymania. W wielu przypadkach nie są nakierowane na rozwój, doskonalenie i wykorzystanie szans. Kluczowym w procesie zarządzania bezpieczeństwem jest identyfikowanie potencjału doskonalenia, w celu rozwijania i doskonalenia systemu.
Więcej na temat audytu RODO przeczytasz tutaj: Audyt RODO
Co nie zostało ujęte?
Nie ujęliśmy w niniejszym przebiegu zarządzania kryzysowego, zarządzania ciągłością działania i odporności (trwałości) organizacji, ponieważ nie wchodzą one w klasyczny proces zarządzania bezpieczeństwem jako etapy. Elementy zarówno kryzysów i ciągłości działania ujęte są w niektórych etapach procesów powyżej, niemniej tematyce tej poświęcimy z kilka następnych artykułów, jako że organizacje o pewnym stopniu dojrzałości wyodrębniają funkcje i role związane z kryzysami, ciągłością działania, czy odpornością organizacji.
Dlaczego warto wdrażać systemy zarządzania bezpieczeństwem?
Podstawą wykazania zgodności z ogólnymi wymaganiami RODO lub innymi przepisami, standardami zarządzania bezpieczeństwem jest zrozumienie procesów, jakie zachodzą w organizacji. Proces pomocniczy, którym jest zarządzanie bezpieczeństwem, wymaga dokładnie takiego samego zrozumienia jak każdy inny proces w organizacji, a jego właściwe wdrożenie pozwoli uzyskać maksimum efektów. Z odpowiednim zarządzaniem budżetem, o czym napiszemy w innym czasie.

References: art. 5
 art. 36
 art. 32
 art. 36
 art. 32
 art. 36
 art. 5