Wewnętrzny audyt bezpieczeństwa w jednostkach publicznych

Wstęp

31 maja 2012 roku weszło w życie:

Rozporządzenie Rady Ministrów 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.

Rozporządzenie to jest aktem wykonawczym do Ustawy z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne.

Wprowadza ono liczne wymagania, między innymi obligując odpowiednie jednostki administracji publicznej do realizowania corocznych, wewnętrznych audytów bezpieczeństwa swojej infrastruktury IT czy uczestniczenia w szkoleniach z obszaru bezpieczeństwa.

Co więcej, narzuca ono na systemy IT wykorzystywane obecnie w administracji publicznej pewne wymagania dotyczące bezpieczeństwa. Wymagania te muszą być spełnione dla nowych systemów IT, a dla istniejących – muszą zostać wprowadzone przy pierwszej dużej modyfikacji.

Niektóre jednostki publiczne mogą zostać przeanalizowane pod względem bezpieczeństwa wcześniej niż daty wymaganej zgodności wynikające z Rozporządzenia – ostatni ’audyt zlecony’ był realizowany przez Ministerstwo Finansów pod koniec 2013 roku dla 323 wybranych jednostek (pod tym adresem można zobaczyć również ankiety, które musiały wypełniać organizacje wytypowane do audytu).

Warto zatem przyjrzeć się dokładnie temu Rozporządzeniu.

Omówienie wybranych zapisów rozporządzenia

Na wstępie warto zwrócić uwagę, że nie jest to pierwsze „techniczno-informatyczne” rozporządzenie do ww. ustawy. Jednak obecnie jest ono jedynym obowiązującym dokumentem, omawiającym ogólne minimalne wymagania bezpieczeństwa dla systemów IT administracji publicznej.

1. Struktura rozporządzenia

Dla tych, którzy nie lubią za wiele czytać, przygotowałem diagram omawiający w skrócie jego zawartość:

Rozporządzenie składa się z pięciu rozdziałów (oraz dwóch załączników, którymi nie będziemy się tutaj zajmować):

1. Wstęp, w którym znajdziemy m.in. definicje. Swoją drogą wreszcie termin „polityka bezpieczeństwa” został przedstawiony tak, jak się go rozumie również poza polskimi granicami. Czyli polityka bezpieczeństwa już nie koniecznie oznacza dokument określający zasady przetwarzania związane z danymi osobowymi – jak to się już nieco zwyczajowo przyjęło w polskiej praktyce. To po prostu dokument określający pewne przyjęte w danej organizacji zasady bezpieczeństwa.
2. Krajowe Ramy Interoperacyjności – rozdział określa cele wdrażania „interoperacyjności” – m.in. „zwiększenie efektywności usług świadczonych przez administrację publiczną” czy „zapewnienie obywatelom i przedsiębiorcom zmniejszenia obciążeń związanych z realizacją uprawnień i obowiązków przewidzianych w przepisach odrębnych”.
   W skrócie, chodzi o pewną standaryzację działania administracji publicznej przez odpowiednie przygotowanie systemów IT. Jest tu też mowa o konkretnych wymaganiach organizacyjnych oraz technicznych, takich jak: zgodność z pewnymi standardami / normami / formatami danych, neutralność technologiczna, standaryzacja procedur czy wymienność systemów. Poruszono też kwestię spełnienia konkretnych wymagań minimalnych dotyczących bezpieczeństwa systemów (wskazanie na rozdział 4 poniżej). W rozdziale definiowane jest również centralne „repozytorium interoperacyjności” zapewniające wspólne struktury danych oraz pewne dalsze rekomendacje i dobre praktyki „ułatwiające osiągnięcie interoperacyjności”.
3. Minimalne wymagania dla rejestrów publicznych i wymiany informacji w postaci elektronicznej to opis głównych zasad dotyczących jednolitej struktury danych dla pewnych obiektów (np. dane obywateli czy instytucji) oraz wskazane metody wymiany tych danych pomiędzy jednostkami – z wykorzystaniem repozytorium interoperacyjności.
4. Minimalne wymagania dla systemów teleinformatycznych – to rozdział, który interesuje nas najbardziej (i o nim poniżej).
5. Przepisy przejściowe i końcowe.

Minimalne wymagania dla systemów teleinformatycznych

W dalszej części tego omówienia zajmę się przede wszystkim wyżej wymienionym rozdziałem czwartym, w którym jest m.in. mowa nie tylko o cyklicznych audytach bezpieczeństwa, ale również o wymaganiach bezpieczeństwa, które powinny spełniać systemy IT.

Zanim do tego przejdę, dwa słowa o strukturze tego rozdziału. Mamy tutaj wymagania dotyczące:

• utrzymania / zarządzania systemami IT (co ciekawe wystarczy tutaj spełnić wymagania norm: PN-ISO/IEC 20000-1 i PN-ISO/IEC 20000-2),
• wymiany danych z innymi systemami i kodowania znaków,
• dostosowania systemów do standardów WCAG2.0  (kwestia większej dostępności dla osób niepełnosprawnych),
• wymagania dotyczące bezpieczeństwa, które dominują nad innymi wymaganiami z tego rozdziału.

Minimalne wymagania bezpieczeństwa

Wymagania dotyczące bezpieczeństwa zapisane są w paragrafie 20. (główne wymagania) oraz 21. (tutaj tylko informacje dotyczące rozliczalności). Zacznijmy od:

Paragraf 20., ustęp 1.:

Podmiot realizujący zadania publiczne opracowuje i ustanawia, wdraża i eksploatuje, monitoruje i przegląda oraz utrzymuje i doskonali system zarządzania bezpieczeństwem informacji zapewniający poufność, dostępność i integralność informacji z uwzględnieniem takich atrybutów, jak autentyczność, rozliczalność, niezaprzeczalność i niezawodność.

Dalej określone jest, w jaki sposób należy organizować zarządzanie bezpieczeństwem informacji:

Paragraf 20., ustęp 2.:

Zarządzanie bezpieczeństwem informacji realizowane jest w szczególności przez zapewnienie przez kierownictwo podmiotu publicznego warunków umożliwiających realizację i egzekwowanie następujących działań:

1. zapewnienia aktualizacji regulacji wewnętrznych w zakresie dotyczącym zmieniającego się otoczenia

Najczęściej nie udaje się jednorazowe poprawne wdrożenie mechanizmów bezpieczeństwa – tj. jednokrotne przygotowanie odpowiednich procedur, zabezpieczenie systemów, wprowadzenie odpowiednich mechanizmów monitoringu bezpieczeństwa itd.

Zazwyczaj bezpieczeństwo zmienia się w czasie – zmieniają się technologie, wdrażamy nowe systemy, powstają nowe zagrożenia, może się również okazać, że przygotowane przez nas procedury po jakimś czasie nie są do końca skuteczne, optymalnie itd.

Wszystko to wymaga dostosowania wewnętrznych procedur działania do bieżącej sytuacji i moim zdaniem może być realizowane w ramach okresowego audytu wewnętrznego (o którym mowa w punkcie 14. poniżej).

2. utrzymywania aktualności inwentaryzacji sprzętu i oprogramowania służącego do przetwarzania informacji obejmującej ich rodzaj i konfigurację;

Ciężko mówić o bezpieczeństwie danego systemu IT, jeśli nie wiemy, co się na niego składa. Stąd potrzeba dokładnej inwentaryzacji (swoją drogą jest ona często jednym z pierwszych punktów wymaganych w procesie analizy ryzyka).

3. przeprowadzania okresowych analiz ryzyka utraty integralności, dostępności lub poufności informacji oraz podejmowania działań minimalizujących to ryzyko, stosownie do wyników przeprowadzonej analizy

Przypominam: integralność, dostępność oraz poufność informacji to trzy zasadnicze czynniki wpływające na bezpieczeństwo (w rozporządzeniu wymieniany jest jeszcze czwarty – rozliczalność – ale mowa o nim jest dopiero w paragrafie 21.). Co więcej, nacisk kładziony na te elementy jest zazwyczaj różny i zależny od konkretnej organizacji i wykorzystanych w niej systemów.

Przeprowadźmy symulację utraty jednego z ww. czynników, żeby zobaczyć, jak wpłynie to na działalność naszej organizacji. Następnie spróbujmy to ryzyko ograniczyć.

Można powiedzieć, że jest to zminimalizowany proces pełnej analizy ryzyka.

4. podejmowania działań zapewniających, że osoby zaangażowane w proces przetwarzania informacji posiadają stosowne uprawnienia i uczestniczą w tym procesie w stopniu adekwatnym do realizowanych przez nie zadań oraz obowiązków mających na celu zapewnienie bezpieczeństwa informacji

Chodzi o uprawnienia w sensie możliwości realizacji określonych czynności – taką interpretację nasuwa przynajmniej punkt 5. poniżej. Nie chodzi tutaj więc o uprawnienia wynikające z posiadania stosownych certyfikatów potwierdzających wiedzę z obszaru bezpieczeństwa (np. CISSP, CISA, CEH itp).

Przykłady uprawnień? Np. wgląd do logów systemów, wgląd do zdefiniowanych ustawień bezpieczeństwa w systemie, możliwość wydania rekomendacji dotyczących instalacji dodatkowego komponentu zwiększającego bezpieczeństwo danego systemu (zmniejszającego ryzyko utraty bezpieczeństwa) itp.

5. bezzwłocznej zmiany uprawnień, w przypadku zmiany zadań osób, o których mowa w pkt 4.;

Patrz punkt 4. powyżej.

6. zapewnienia szkolenia osób zaangażowanych w proces przetwarzania informacji ze szczególnym uwzględnieniem takich zagadnień, jak:

a) zagrożenia bezpieczeństwa informacji
b) skutki naruszenia zasad bezpieczeństwa informacji, w tym odpowiedzialność prawna
c) stosowanie środków zapewniających bezpieczeństwo informacji, w tym urządzenia i oprogramowanie minimalizujące ryzyko błędów ludzkich

Zatem zgodnie z rozporządzeniem odgórne wskazanie, że osoby przetwarzające informacje powinny posiadać wiedzę z obszaru bezpieczeństwa informacji to za mało. Należy dodatkowo zapewnić takim osobom szkolenia. Ogólny zakres szkolenia został wskazany powyżej (punkty a-c).

Z mojej strony dodam, że szkolenie takie powinno być raczej niezależne od dostawcy konkretnych produktów bezpieczeństwa (neutralność w stosunku do konkretnych rozwiązań) oraz powinno pokrywać możliwie szeroki obszar tematyki związanej z bezpieczeństwem. Po takim szkoleniu pracownik powinien mieć większą świadomość różnych zagrożeń / obszarów bezpieczeństwa, a przy okazji zdobyć wiedzę dotyczącą możliwych metod zabezpieczania  systemów / monitorowania systemów itp. Przykładowo warto rozważyć szkolenie: wprowadzenie do bezpieczeństwa, choć możliwości jest tutaj sporo.

7.  zapewnienia ochrony przetwarzanych informacji przed ich kradzieżą, nieuprawnionym dostępem, uszkodzeniami lub zakłóceniami, przez:

a) monitorowanie dostępu do informacji
b) czynności zmierzające do wykrycia nieautoryzowanych działań związanych z przetwarzaniem informacji
c) zapewnienie środków uniemożliwiających nieautoryzowany dostęp na poziomie systemów operacyjnych, usług sieciowych i aplikacji;

Jest to jeden z punktów, który wydaje się nieskomplikowany „na papierze”, ale jego spełnienie zazwyczaj bywa dość wymagające. Przyjrzyjmy się zatem dokładnie tym trzem wymienionym wyżej podpunktom.

a) Monitorowanie dostępu do informacji może mieć wielorakie formy, szerzej przyjmujące formę monitoringu bezpieczeństwa.

Jedną z częstszych metod monitorowania dostępu do danych jest automatyczne zapisywanie logów przez konkretne systemy. Logi to najczęściej pliki tekstowe zawierające informacje o fakcie dostępu do danych. W logach mogą być przechowywane informacje na temat:

• użytkowników / osób uzyskujących dostęp do danych,
• adresów IP, z których odbywał się dostęp,
• dokładanej daty dostępu,
• zakresu: dostęp został przydzielony / dostęp został odrzucony (np. w wyniku braku uprawnień użytkownika do danego zasobu),
• […] (listę w zależności od potrzeb można jeszcze uzupełniać).

Poza logami charakterystycznymi dla danego systemu czy aplikacji (jak powyżej), istnieją również logi generowane przez urządzenia sieciowe czy systemy operacyjne (łącznie z usługami działającymi na tych systemach – np. serwer www, serwer ssh itp.) – w tego typu logach można zazwyczaj znaleźć sporo informacji mówiących o ewentualnych naruszeniach bądź próbach naruszeń bezpieczeństwa.

Kilka dodatkowych wymagań dotyczących logów zapisanych jest w paragrafie 21. rozporządzenia (np. okres przechowywania logów został tam ustalony na 2 lata, chyba że odrębne przepisy mówią inaczej).

Istotnym elementem osiągania bezpieczeństwa jest analiza logów (jeśli ich nie analizujemy to ew. próby naruszenia bezpieczeństwa pozostaną zapisane w logach, a my sami nie będziemy wiedzieć o problemach).

Jeszcze innym przykładem logów jest zapis całej komunikacji sieciowej przepływającej przez naszą sieć. Tego typu logi zazwyczaj są bardzo duże i rzadko stosowane. Często lepszym pomysłem jest przechowywanie skróconej formy ruchu sieciowego (tzw. przepływów sieciowych). Przykład infrastruktury monitorującej można zobaczyć na diagramie poniżej:

b) Czynności zmierzające do wykrycia nieautoryzowanych działań związanych z przetwarzaniem informacji

W praktyce najczęściej wykorzystuje się tutaj monitorowanie logów systemowych (omówione powyżej) oraz systemy IDS (Intrusion Detection Systems). W skrócie – systemy typu IDS (a dokładniej network IDS) automatycznie analizują komunikację sieciową pod względem występowania w niej ataków, np. na naszą infrastrukturę; są też w stanie np. wykryć, że to nasza infrastruktura IT próbuje atakować inne systemy (np. w wyniku infekcji wirusem czy innym oprogramowaniem typu malware).

c) Zapewnienie środków uniemożliwiających nieautoryzowany dostęp na poziomie systemów operacyjnych, usług sieciowych i aplikacji.

Oczywiście nigdy nie można w 100% uniemożliwić nieautoryzowanego dostępu – możemy za to zmniejszać jego ryzyko (optymalnie do bliskiego zeru).

Jedną z metod jest tutaj zastosowanie hardeningu systemów operacyjnych / usług sieciowych (czyli zwiększania bezpieczeństwa standardowej konfiguracji) – pełne, bezpłatne dokumentacji w tym obszarze można znaleźć np. tutaj.

Przed wdrożeniem aplikacji można też zawrzeć w umowie z wykonawcą stosowne zapisy o bezpieczeństwie (mowa będzie o tym dalej), często przed wdrożeniem systemów realizuje się również audyty bezpieczeństwa (czy dokładniej: testy penetracyjne), dzięki którym jesteśmy w stanie zlokalizować (oraz usunąć) błędy (podatności) umożliwiające naruszenie bezpieczeństwa danego systemu.

W tym miejscu na pewno też warto poruszyć kwestie bezpieczeństwa haseł dostępowych – zarówno dla administratorów, jak i użytkowników. Jak pokazuje praktyka jest to często achillesowych pięta bezpieczeństwa. Co więcej, czasami gotowe rekomendacje dotyczące tworzenia bezpiecznych haseł nie do końca się sprawdzają…

Ostatnią kwestią, którą tutaj poruszę jest wykorzystanie w infrastrukturze bezprzewodowych sieci Wi-Fi. Może być to o tyle niebezpieczne, że w pewnych przypadkach jest ona w stanie umożliwić nieautoryzowany, zdalny dostęp (spoza fizycznego budynku) do infrastruktury LAN, w której zazwyczaj znajdują się najistotniejsze dane.

8. ustanowienia podstawowych zasad gwarantujących bezpieczną pracę przy przetwarzaniu mobilnym i pracy na odległość

Tu z jednej strony, mowa jest o bezpieczeństwie przy ew. dostępie do infrastruktury IT przez telefony komórkowe / tablety (np. dostęp do poczty elektronicznej jednostki) (w kwestii merytorycznej polecam tutaj nasze kompendium bezpieczeństwa systemów mobilnych), z drugiej strony, o pracy na odległość, która może być realizowana np. z laptopów czy komputerów stacjonarnych.

9. zabezpieczenia informacji w sposób uniemożliwiający nieuprawnionemu jej ujawnienie, modyfikacje, usunięcie lub zniszczenie;

Punkt ten podobny jest do punku nr 7 i moim zdaniem mógłby zostać spokojnie z nim zintegrowany. Warto tutaj jednak skupić się na kwestiach związanych ze zniszczeniem danych w kontekście realizacji kopii zapasowych.

10. zawierania w umowach serwisowych podpisanych ze stronami trzecimi zapisów gwarantujących odpowiedni poziom bezpieczeństwa informacji;

W tym przypadku zalecenie rozporządzenia jest dość ogólne, ale spróbujmy zaproponować kilka tego typu zapisów do umów serwisowych:

1. kwestia odpowiedniego dostępu do danych osobowych (być może umowa powierzenia przetwarzania),
2. zastrzeżenie możliwości monitorowania czynności realizowanych w naszych systemach IT przez firmy zewnętrzne,
3. wymóg zapewnienia możliwości aktualizacji bezpieczeństwa dla komponentów, których używa system wdrażany przez firmę zewnętrzną (np. chcemy, aby baza danych, z której korzysta aplikacja, mogła być aktualizowana pod względem bezpieczeństwa – chociażby bez ryzyka utraty gwarancji na samą aplikację),
4. zastrzeżenie możliwości realizacji audytów bezpieczeństwa i/lub testów penetracyjnych dla wdrażanych / serwisowanych systemów,
5. zastrzeżenie, że ew. wykryte błędy bezpieczeństwa zewnętrzny dostawca będzie usuwał na własny koszt.

11. ustalenia zasad postępowania z informacjami, zapewniających minimalizację wystąpienia ryzyka kradzieży informacji i środków przetwarzania informacji, w tym urządzeń mobilnych;

Część z tych elementów omówiliśmy już wcześniej (patrz punkt 8 powyżej oraz nasze opracowanie dotyczące bezpieczeństwa mobilnego). W punkcie tym warto na pewno zadbać o klasyfikację informacji oraz określić zasady dostępu do tego typu informacji.

12. zapewnienia odpowiedniego poziomu bezpieczeństwa w systemach teleinformatycznych, polegającego w szczególności na:

a) dbałości o aktualizację oprogramowania,
b) minimalizowaniu ryzyka utraty informacji w wyniku awarii,
c) ochronie przed błędami, utratą, nieuprawnioną modyfikacją,
d) stosowaniu mechanizmów kryptograficznych w sposób adekwatny do zagrożeń lub wymogów przepisu prawa,
e) zapewnieniu bezpieczeństwa plików systemowych,
f) redukcji ryzyk wynikających z wykorzystania opublikowanych podatności technicznych systemów teleinformatycznych,
g) niezwłocznym podejmowaniu działań po dostrzeżeniu nieujawnionych podatności systemów teleinformatycznych na możliwość naruszenia bezpieczeństwa,
h) kontroli zgodności systemów teleinformatycznych z odpowiednimi normami i politykami bezpieczeństwa;

Część zapisów tego punktu ponownie pokrywa się z zapisami już omawianymi; przeanalizujmy zatem tylko nowości.

a) dbałości o aktualizację oprogramowania

Nieaktualne oprogramowanie to oprogramowanie najczęściej podatne na ataki. Dotyczy to zarówno oprogramowania pracującego na stacjach roboczych (np. java, flash czy adobe reader), jak również oprogramowania serwerowego.

Co więcej, istnieją serwisy – takie jak np. cvedetails – umożliwiające sprawdzenie znanych podatności w konkretnych komponentach. W tego typu bazach określana jest też krytyczność danego błędu oraz podawane są szczegóły, których znajomość pozwala na wykorzystanie danej podatności. Aby wyświetlić szczegóły podatności znanych publicznie w danym komponencie infrastruktury, wystarczy wpisać w wyszukiwarkę nazwę tego komponentu, np.: „Oracle Database”:

b) minimalizowaniu ryzyka utraty informacji w wyniku awarii,

Można tutaj wskazać przede wszystkim dwa sposoby radzenia sobie z problem:

• regularne wykonywanie kopii zapasowych (i okresowe testowe ich odtwarzanie – chcemy mieć pewność, że będziemy umieli odtworzyć system z kopii zapasowej);
• dodatkowo, można zadbać o ciągłość dostępu do naszej usługi (zazwyczaj dotyczy to tylko usług krytycznych) przez odpowiednią redundancję (nadmiarowość) w naszej infrastrukturze. Dobrze przygotowany system tego typu w momencie awarii jednego z komponentów wykorzysta automatycznie inny komponent.

c) ochronie przed błędami, utratą, nieuprawnioną modyfikacją

Przykłady ochrony wskazywaliśmy już wcześniej.

d) stosowaniu mechanizmów kryptograficznych w sposób adekwatny do zagrożeń lub wymogów przepisu prawa

Oczywiście wymogi prawa są najróżniejsze i konkretne działania należy do nich dostosowywać, choć w tym kontekście warto na pewno wspomnieć o szyfrowaniu poczty (thunderbird, outlook) oraz wspomnianym wcześniej szyfrowanym dostępie zdalnym z wykorzystaniem VPN. Obowiązuje tu na pewno ogólna zasada, że żadne dane wrażliwe nie powinny być przesyłane przez sieć bez odpowiedniej ochrony kryptograficznej (w szczególności podczas przesyłania ich przez Internet).

e) zapewnieniu bezpieczeństwa plików systemowych

Punkt ten wygląda dość enigmatycznie, ale prawdopodobnie prawodawcy chodzi o pliki zawierające istotne dane (hasła dostępowe, dane obywateli, kody źródłowe, konfiguracje itp.). Ważne jest zachowanie odpowiednich uprawnień dostępu do takich plików (np. uniemożliwienie odczytu tych danych dowolnemu użytkownikowi) oraz ich bezpiecznie transferowanie i przechowywanie (wykorzystanie odpowiednich metod kryptograficznych).

f) redukcji ryzyk wynikających z wykorzystania opublikowanych podatności technicznych systemów teleinformatycznych

O tym punkcie już pisałem – przede wszystkim chodzi tu o regularne wykonywanie aktualizacji oraz o ograniczenie dostępności systemów / usług do minimalnego podzbioru, który jest wymagany do prawidłowego działania danej instytucji.

Tego typu ryzyko można również zmniejszać przez zastosowanie systemów IDS/IPS, o czym była już mowa wcześniej.

Istnieją też dedykowane serwisy pokazujące problemy w jednym konkretnym oprogramowaniu, np. w adobe reader:

g) niezwłocznym podejmowaniu działań po dostrzeżeniu nieujawnionych podatności systemów teleinformatycznych na możliwość naruszenia bezpieczeństwa,

Częstym przypadkiem obejmującym atak z wykorzystaniem „nieujawnionej” podatności (w przeciwieństwie do podatności opublikowanych), jest atak na aplikacje webowe (np. portale informacyjne czy usługowe). Niejednokrotnie atakujący odkrywa podatność i od razu przygotowuje „szyty na miarę” atak. Więcej o samym reagowaniu na incydenty piszę przy omówieniu punktu 13.

h) kontroli zgodności systemów teleinformatycznych z odpowiednimi normami i politykami bezpieczeństwa

Wspomniane normy zależą zazwyczaj od charakteru systemu (np. odpowiednie wymagania nakładane są na systemy przetwarzające dane osobowe). Każda jednostka administracji publicznej może też mieć własną politykę bezpieczeństwa, dopasowaną do profilu działania.

13. bezzwłocznego zgłaszania incydentów naruszenia bezpieczeństwa informacji w określony i z góry ustalony sposób, umożliwiający szybkie podjęcie działań korygujących;

Incydent bezpieczeństwa to naruszenie bezpieczeństwa jednego z elementów systemu IT: poufności, integralności lub dostępności.

14. zapewnienia okresowego audytu wewnętrznego w zakresie bezpieczeństwa informacji, nie rzadziej niż raz na rok

Audyt wewnętrzny powinien weryfikować aktualny stan naszych zabezpieczeń versus wskazania zawarte w omawianym rozporządzeniu (patrz punkty 1-13 powyżej).

Przypominam, że zazwyczaj bezpieczeństwo nie jest wartością stałą i zmienia się w czasie (np. w wyniku reorganizacji infrastruktury IT czy pojawienia się nowych zagrożeń), należy więc okresowo weryfikować utrzymanie odpowiedniego poziomu bezpieczeństwa.

W jaki sposób spełnić wymagania dotyczące bezpieczeństwa (paragraf 20. oraz 21. rozporządzenia)?

1. Paragraf 20

W tym przypadku możemy przeanalizować nasz system pod względem wymagań opisanych powyżej – najlepiej zrobić to w formie audytu wewnętrznego (być może ze wsparciem zewnętrznych audytorów), a następnie wprowadzić w życie wnioski poaudytowe, pamiętając również o ciągłym monitorowaniu / udoskonalaniu wdrażanego systemu zarządzania bezpieczeństwem.

Mamy również pewną alternatywę:

Paragraf 20, ustęp 3:

Wymagania określone w ust. 1 i 2 uznaje się za spełnione, jeżeli system zarządzania bezpieczeństwem informacji
został opracowany na podstawie Polskiej Normy PN-ISO/IEC 27001, a ustanawianie zabezpieczeń, zarządzanie ryzykiem
oraz audytowanie odbywa się na podstawie Polskich Norm związanych z tą normą, w tym:
1) PN-ISO/IEC 17799 – w odniesieniu do ustanawiania zabezpieczeń;
2) PN-ISO/IEC 27005 – w odniesieniu do zarządzania ryzykiem;
3) PN-ISO/IEC 24762 – w odniesieniu do odtwarzania techniki informatycznej po katastrofie w ramach zarządzania
ciągłością działania.

Czyli możemy ww. elementy uznać za spełnione, jeśli działamy w pewnych obszarach zgodnie z normami:  PN-ISO/IEC 27001, PN-ISO/IEC 17799, PN-ISO/IEC 27005, PN-ISO/IEC 24762, co niestety wcale nie jest takie proste…

2. Paragraf 21

W tym miejscu opisane są wymogi dotyczące rozliczalności w systemie IT (głównie logowanie odpowiednich informacji). Rozporządzenie nie daje tu żadnej alternatywy (brak powołania się na odpowiednią normę), zatem musimy te wymagania spełnić wprost.

Na koniec opracowania zostawiliśmy mniej techniczny rozdział omawiający jednostki publiczne, które powinny zainteresować się ww. rozporządzeniem:

Kogo dotyczą zapisy rozporządzenia z 12 kwietnia 2012 roku?

Wprost wymienia te podmioty ustawa o informatyzacji działalności podmiotów realizujących zadania publiczne w art. 2.:

1. Z zastrzeżeniem ust. 2–4, przepisy ustawy stosuje się do realizujących zadania publiczne określone przez ustawy:
1) organów administracji rządowej, organów kontroli państwowej i ochrony prawa, sądów, jednostek organizacyjnych prokuratury, a także jednostek samorządu terytorialnego i ich organów,
2) jednostek budżetowych i samorządowych zakładów budżetowych,
3) funduszy celowych,
4) samodzielnych publicznych zakładów opieki zdrowotnej oraz spółek wykonujących działalność leczniczą w rozumieniu przepisów o działalności leczniczej,
5) Zakładu Ubezpieczeń Społecznych, Kasy Rolniczego Ubezpieczenia Społecznego,
6) Narodowego Funduszu Zdrowia,
7) państwowych lub samorządowych osób prawnych utworzonych na podstawie odrębnych ustaw w celu realizacji zadań publicznych
– zwanych dalej „podmiotami publicznymi”.
2. Przepis art. 13 ust. 2 pkt 1 stosuje się również do podmiotu, któremu podmiot publiczny powierzył lub zlecił realizację zadania publicznego, jeżeli w związku z realizacją tego zadania istnieje obowiązek przekazywania informacji do lub od podmiotów niebędących organami administracji rządowej.

W tym samym artykule ustawodawca wymienia też podmioty, do których działalności nie stosuje się jej zapisów (a więc i zaleceń rozporządzenia).

Aby odpowiedzieć na pytanie, czy omawiane przepisy prawa dotyczą mojej instytucji, wystarczy więc przejrzeć listę podmiotów wskazanych przez ustawę (część z nich jest wymieniona z nazwy albo z funkcji) albo sprawdzić, czy instytucja nie realizuje „zadań publicznych”.

Zatem zadanie publiczne to każde działanie administracji, które realizuje ona na podstawie zapisów Konstytucji RP i ustaw w trzech obszarach:

• świadczenia lub zapewnienia wykonania usług na rzecz mieszkańców i innych podmiotów (np. dostarczanie mediów, odbiór i utylizacja śmieci, organizacja komunikacji zbiorowej, budowa i utrzymanie dróg, edukacja itd.); zadania takie mogą być zlecane różnym pomiotom (np. zadania służby zdrowia realizowane przez niepubliczne zakłady opieki zdrowotnej (NZOZ), które są na podstawie kontraktów finansowane przez państwo (Narodowy Fundusz Zdrowia));
• wydawania decyzji administracyjnych (np. pozwolenia na budowę, koncesji na alkohol, pozwolenia na wycinkę drzew itd., a także uprawnienia nadzorcze i kontrolne wykonywane przez służby, inspekcje i straże, m.in.: policja, inspekcja pracy, inspekcja sanitarna, straże gminne/miejskie); tych zadań nie można przekazywać podmiotom niepublicznym;
• tworzenia przepisów, norm i standardów, w ramach ustawowo przewidzianych upoważnień (czyli wydawanie różnego rodzaju przepisów przez organy administracji rządowej i samorządowej w formie zarządzeń, rozporządzeń, uchwał); tych zadań także nie można przekazywać do realizacji innym podmiotom.

—Michał Sajdak, CISSP, CEH, michal.sajdak<at>securitum.pl