Wewnętrzny audyt bezpieczeństwa w jednostkach publicznych

14 stycznia 2014, 13:21 | Teksty | Komentarze: 18
: zin o bezpieczeństwie - pobierz w pdf/epub/mobi.

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.

Jeśli potrzebujesz wsparcia w realizacji audytu bezpieczeństwa IT – warto zapoznać się z ofertą Securitum.

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ść:

ustawa1

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).

PYTANIA KONTROLNE:

1. Czy śledzę nowe przepisy prawa, który mogą wpływać na formalne wymogi bezpieczeństwa mojego systemu (np. nowelizacja ustawy o ochronie danych osobowych)?
2. Czy co najmniej raz na rok weryfikuję skuteczność oraz racjonalność regulacji wewnętrznych dotyczących bezpieczeństwa IT?

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).

PYTANIA KONTROLNE:

  1. Czy posiadam zinwentaryzowany sprzęt / oprogramowanie wraz z określeniem ważności danego komponentu dla całej organizacji?
  2. Czy pracownicy mogą używać swojego sprzętu domowego do pracy nad zadaniami powierzonymi w ramach obowiązków służbowych?
  3. Czy pracownicy mogą podłączać swój sprzęt (laptopy, telefony, tablety) do infrastruktury służbowej?
  4. Czy zapisuję każdy fakt podłączenia zewnętrznego sprzętu do infrastruktury służbowej?
  5. Czy monitoruje podłączenia ew. nieautoryzowanych punktów bezprzewodowych do infrastruktury służbowej?
  6. Czy stosuję protokół 802.1x przy podłączeniu nowych urządzeń do sieci? (w skrócie: 801.X to mechanizm umożliwiający podłączenie się do sieci – kablowo lub bezprzewodowo – tylko zaufanych, wcześniej zarejetrowanych urządzeń)
Jednym z lepszych narzędzi w dużym stopniu automatyzujących wykrywanie na poziomie sieciowym sprzętu IT jest darmowe narzędzie The Dude:

demodude

Wartym wspomnienia jest też bezpłatne narzędzie OCS Inventory, dostępnych jest również kilka polskich narzędzi tego typu.

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.

PRZYKŁAD: potencjalnie mniejszym problemem może być niedostępność witryny internetowej urzędu niż jego nieautoryzowana podmiana (lub podobna podmiana np. w systemie finansowo-księgowym instytucji) – czyli naruszenie integralności.

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ć.

PRZYKŁAD: na naszym firmowym serwisie WWW wykryliśmy nieaktualną, podatną wersję oprogramowania WordPress. Umożliwia to nieautoryzowaną utratę integralności (możliwość podmiany strony) oraz dostępności (możliwość wyłączenia strony). Możemy ryzyko ataku zminimalizować, wykonując np. aktualizację oprogramowania WordPress do najnowszej wersji.

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

PYTANIA KONTROLNE:

  1. Czy znam najistotniejsze zagrożenia dla zinwentaryzowanych systemów IT?
  2. Czy wiem, które systemy są krytyczne dla działania mojej organizacji?
  3. Czy mam pewność, że każdy krytyczny system jestem w stanie odtworzyć z kopii zapasowych w odpowiednim czasie?
  4. Czy mam opracowane plany działania w momencie naruszenia bezpieczeństwa IT w mojej organizacji (np. procedury reagowania na incydenty IT)?
  5. Czy znam potencjalne zagrożenia dla systemów, które znajdują się w mojej infrastrukturze lub w infrastrukturze zewnętrznej (outsourcing)?
  6. Utrata któregoś ze składników bezpieczeństwa (integralność / poufność / dostępność) jest w moim przypadku najbardziej dotkliwa?

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.

PYTANIA KONTROLNE:

  1. Czy posiadam listę osób odpowiedzialnych za bezpieczeństwo IT w mojej organizacji?
  2. Czy na bieżąco aktualizuję ww. listę (np. w momencie zmiany zakresu obowiązków, przyjęcia na stanowisko nowej osoby)?
  3. Czy osoby te posiadają stosowne kompetencje?
  4. Czy posiadam formalną listę zadań / obowiązków / uprawnień takich osób?

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.

PYTANIA KONTROLNE:

  1. Czy wiem, kto w mojej instytucji powinien być szkolony w obszarze bezpieczeństwa IT?
  2. Czy sprawdzam jakość i przydatność szkoleń odbytych przez pracowników?
  3. Czy mam zaplanowane szkolenia z bezpieczeństwa, na które chciałbym wysłać pracowników?

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.

Logi zazwyczaj są tworzone i przechowywane przez maszynę (np. na serwerze), która je generuje, jednak bezpieczniejszą formą jest przechowywanie ich również w jednym, centralnym miejscu (serwer logów). Budowę tego typu architektury umożliwia choćby narzędzie syslog.

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).

Tutaj przydatne może być choćby bezpłatne narzędzie OSSEC (automatycznie analizuje logi przede wszystkim z systemów Windows / Linux oraz raportuje ew. naruszenia; jest też prosta możliwość tworzenia własnych reguł – co daje możliwość analizy w zasadzie dowolnych logów).

Z kolei sprawdzonym narzędziem ułatwiającym analizę lub przeglądanie logów z wielu różnych miejsc jest splunk (dostępna wersja darmowa przetwarzająca do 500MB logów dziennie).

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:

monitoring

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).

Osoby zainteresowane tą tematyką zachęcam do spojrzenia na darmową dystrybucję Linuksa security onion – zawierającą prekonfigurowane narzędzia typu IDS.

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.

Z kolei jeśli chodzi o aplikacje – sprawa zazwyczaj wymaga wiedzy i czasu. O kilku podstawowych i szybkich do zastosowania metodach zabezpieczania aplikacji webowych można przeczytać u nas.

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.

Osoby zainteresowane testami penetracyjnymi odsyłam również do naszego trzyczęściowego cyklu: Czego uczą metodologie testów penetracyjnych, a także do prześledzenia przykładowego scenariusza audytu bezpieczeństwa (czy dokładniej: testów penetracyjnych).

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ą

Co proponuję?

  • administratorom: sprawdzić, czy przypadkiem w swoich systemach nie stosuję domyślnych haseł (do urządzeń sieciowych, baz danych, aplikacji…),
  • administratorom: wymusić odpowiednie bezpieczeństwo haseł użytkowników zgodne z polityką bezpieczeństwa,
  • administratorom i użytkownikom: rozważyć korzystanie z managera haseł,
  • administratorom i użytkownikom: tworzyć złożone hasła, a jednocześnie łatwe do zapamiętania, np.: hhoinkaa77bankowatA (to złożenie dwóch prostych do zapamiętania słów, lekko zmienionych, tak aby utrudnić ataki słownikowe).

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.

PYTANIA KONTROLNE:

  1. Czy zapisuję logi na serwerach wchodzących w skład mojej infrastruktury?
  2. Czy są to logi usług sieciowych / systemu operacyjnego, czy również logi dedykowanych aplikacji, które udostępniam na serwerach?
  3. Czy posiadam komponenty w automatyczny sposób analizujące logi pod względem wystąpienia ew. naruszeń?
  4. Czy posiadam centralne miejsce przechowywania logów?
  5. Czy logi zabezpieczam w odpowiedni sposób (zapewnienie poufności / integralności / dostępności)?
  6. Czy wykorzystuję w infrastrukturze IT systemy typu IDS lub IPS?
  7. Czy realizuję testy penetracyjne dla najbardziej istotnych systemów?
  8. Czy dbam o aktualizacje (komponenty serwerowe oraz stacje PC)?
  9. Czy badam domyślną konfigurację systemów pod względem bezpieczeństwa?
  10. Czy mam jasno sprecyzowane zasady umieszczania systemów w strefie DMZ?
  11. Czy umożliwiam ruch z Internetu do stref DMZ tylko na ograniczoną liczbę portów (tylko do ściśle sprecyzowanego zbioru usług, które powinny być dostępne z Internetu)?
  12. W jaki sposób zarządzam bezpieczeństwem haseł w mojej organizacji?
  13. Czy użytkownicy pracują na swoich stacjach PC z uprawnieniami jedynie ‚standardowych’ użytkowników (tj. nie z uprawnieniami administracyjnymi)?
  14. Czy realizuję okresowo kontrolę uprawnień i kont użytkowników, którzy już nie współpracują z moją organizacją?
  15. Czy w mojej infrastrukturze posiadam sieć Wi-Fi? Czy jest ona zabezpieczona w odpowiedni sposób?

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.

W tym przypadku warto się na pewno zastanowić nad wymogiem korzystania z systemu VPN (zapewniającego bezpieczną transmisję do zasobów centralnych; przykładem bezpłatnego rozwiązania może być tutaj OpenVPN), a także rozważyć wykorzystanie szyfrowania dysku – w przypadku kradzieży lub zagubienia laptopa nasze dane będą bezpieczne (bez podania hasła nie będzie ich można odszyfrować). Darmowym przykładem narzędzia umożliwiającego szyfrowanie dysku jest np. TrueCrypt.

Analizując kwestie przenoszenia danych na nośnikach przenośnych (pendrive) oraz ich odpowiednie zabezpieczenie, trzeba pamiętać, że nawet po skasowaniu danych z pendrive istnieje możliwość ich odzyskania; aby temu zapobiec należy stosować metodę zerowania.

PYTANIA KONTROLNE:

  1. Czy w pracy na odległość stosuję bezpieczne metody połączenia (np. VPN)?
  2. Jakie metody uwierzytelniania stosuję przy podłączeniu się przez VPN (np.: tylko login + hasło / login + hasło + certyfikat cyfrowy / login + hasło + token generujący hasła jednorazowe / itp)?
  3. Czy podczas połączenia VPN mogę być również połączony z inną siecią (np. z Internetem, siecią Wi-Fi itp.)?
  4. Czy administratorzy systemów mają możliwość zdalnego zarządzania moją infrastrukturą? (Jeśli tak, to w jaki sposób się to odbywa?)
  5. Czy systemy (np. laptopy), które mają zdalny dostęp do mojej infrastruktury, posiadają aktualne oprogramowanie antywirusowe / są w pełni zaktualizowane?
  6. Czy systemy (np. laptopy), które mają zdalny dostęp do mojej infrastruktury, są chronione przed utratą danych (np. w wyniku kradzieży)?

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.
Więcej tego typu informacji można znaleźć np. w projekcie OWASP Legal Project (jest to wersja anglojęzyczna, jednak możemy ją śmiało użyć jako inspiracji przy tworzeniu własnego załącznika do umowy, który będzie określał wymagania bezpieczeństwa).

PYTANIA KONTROLNE:

  1. Czy posiadam zapisy gwarantujące odpowiedni poziom bezpieczeństwa IT w umowach zawieranych z dostawcami sprzętu / oprogramowania?
  2. Czy posiadam krytyczne systemy, dla których nie ma zapisów umownych dotyczących bezpieczeństwa (np. zapewnienie możliwości wgrania aktualizacji komponentów, na których bazuje dany system)?
  3. Czy systemy obsługiwane przez zewnętrzne podmioty spełniają wymogi omawianego tu rozporządzenia?

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.

PYTANIA KONTROLNE:

  1. Czy mam odpowiednie regulacje dotyczące zapisu danych na nośnikach przenośnych?
  2. Czy mam wdrożony mechanizm klasy DLP (Data Leak Prevention)?
  3. Czy posiadam mechanizmy uniemożliwiające dostęp do danych na urządzeniu mobilnym po jego utraceniu (np. pin/szyfrowanie przestrzeni dyskowej na urządzeniu)?
  4. Czy mam możliwość zdalnego, trwałego usunięcia danych z tego typu urządzenia?
  5. Czy kontroluję to, co użytkownicy mogą realizować na urządzeniach mobilnych (np. uruchamianie dowolnych aplikacji)?
  6. Czy mam zapewnione bezpieczne połączenie urządzeń mobilnych z moją infrastrukturą (np. tylko protokoły szyfrowane)?
  7. Czy pracownicy mogą podłączać swoje urządzenia mobilne do mojej infrastruktury IT (tzw. BYOD – Bring Your Own Device)?

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”:

vulns

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.
Przykład tego typu infrastruktury można zobaczyć np. tutaj.

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.

Serwisy, w których można znaleźć opublikowane podatności, to np. cvedetails, secunia, lista full disclosure, czy bugtraq. Już ich regularne przeglądanie daje szansę na szybkie namierzenie nowego problemu. Można też śledzić na bieżąco polskie i zagraniczne portale i blogi na ten temat.

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:

ar

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.

PYTANIA KONTROLNE:

  1. Czy realizuję bieżące aktualizacje zarówno na stacjach PC (system operacyjny / java / adobe reader / flash itp.), jak i serwerach?
  2. Czy aktualizuję oprogramowanie firmware na urządzeniach sieciowych – szczególnie tych, które mają bezpośredni styk z Internetem?
  3. Czy posiadam aktualne sygnatury dla systemu antywirusowego?
  4. Czy mam przygotowaną procedurę odtworzenia danej stacji roboczej / serwera po wykryciu na nim wirusa?
  5. Czy mam informacje o systemach, dla których aktualizacja nie powiodła się?
  6. Czy wiem, które systemy IT są krytyczne dla prawidłowego działania mojej instytucji?
  7. Czy zapewniam ciągłość działania w przypadku wystąpienia awarii ww. systemów?
  8. Czy użytkownicy mojej sieci przesyłają wrażliwe informacje w formie jawnej (np. za pośrednictwem e-mail lub przenosząc na pendrive / telefonie)?
  9. Czy posiadam instrukcję reagowania na incydenty bezpieczeństwa IT?
  10. Czy wiem, z jakimi innymi wymaganiami prawnymi muszą być zgodne moje systemy (np. ustawa o ochronie danych osobowych)?
  11. Czy zapewniam odpowiednio bezpieczny dostęp do poczty elektronicznej (dostęp tylko szyfrowany)?
  12. Czy umożliwiam zdalny dostęp do poczty elektronicznej?
  13. Czy dostęp do Internetu w mojej jednostce jest ograniczany (np. poprzez wykorzystanie serwera proxy i umożliwienie dostępu tylko do kilku usług – np. http, ftp)?
  14. Czy w odpowiedni sposób zapewniam ochronę przed fizyczną ingerencją w infrastrukturę IT (np.: odpowiednie zabezpieczenia serwerowni, okablowania)?

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.

Przykładową dokumentację obsługi i reagowania na incydenty publikujemy na stronach Securitum (można również poprosić o bezpłatnie udostępnienie pliku z tą dokumentacją w formacie .doc)

PYTANIA KONTROLNE:

  1. Czy mam przygotowane procedury zgłaszania incydentów naruszenia bezpieczeństwa informacji?
  2. Czy okresowo testuję procedury zgłaszania incydentów naruszenia bezpieczeństwa informacji?
  3. Czy prowadzę rejestr wykrytych incydentów bezpieczeństwa (symulacja wystąpienia incydentu bezpieczeństwa)?

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.

PYTANIA KONTROLNE:

  1. Czy mam zaplanowany czas na realizację wewnętrznego audytu bezpieczeństwa?
  2. Czy wiem, kto w mojej instytucji jest odpowiedzialny za realizację takiego audytu?
  3. Czy mam w mojej instytucji odpowiednie kompetencje do realizacji takiego audytu?

 

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”.

Podmiot wykonujący zadania publiczne definiowany jest ze względu na charakter wykonywanych przez niego obowiązków oraz jego uprawnień. Zadania publiczne są to działania realizowane w sposób powszechny, są użyteczne dla społeczeństwa i służą w ogólnym ujęciu osiąganiu celów wskazanych w Konstytucji i ustawach.

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

Spodobał Ci się wpis? Podziel się nim ze znajomymi:



Komentarze

  1. Tomek
    Odpowiedz
    • Tomek – linkuję je właśnie w tekście zaraz pod wskazaniem The Dude :-)

      Odpowiedz
  2. Inny Tomek

    Super Artykuł! Wielkie Dzięki!
    Jeśli mogę też coś polecić tak od serca, jeśli chodzi o bezpieczeństwo – to nVision. Od dwóch lat jestem jego wiernym fanem i tym samym użytkownikiem . A wiadomo..technologia tak szybko pędzi do przodu że bez odpowiednich aktualnych narzędzi ryzyko w obszarach, o których mowa choćby w pytaniach kontrolnych w Twoim artykule, staje się coraz większe..

    Odpowiedz
  3. Pawel

    @sekurak – dzięki za artykuł :)

    Polecam również program Zabbix – darmowy i łatwy a dostarcza wile przydatnych informacji.

    Odpowiedz
  4. Wiktor
    Odpowiedz
  5. Dziadek

    Co z tego jak ambasada Rosyjska ma bardzo dobry system nasłuchu w promieniu 1 km od niej i w którym znajdują najważniejsze instytucje rządowe nie używające komunikacji szyfrowanej….

    Odpowiedz
  6. Andrzej

    W takich momentach brakuje mi tak młodego i już zapomnianego przycisku jak „wersja do druku” ;).
    Bardzo dobry artykuł.

    Odpowiedz
    • @Andrzej: no niestety nie planujemy przycisku drukuj ;) Ale już niedługo będzie można część tekstów z sekurak-a dostać w PDF – wydamy naszego pdfowego zina.

      Odpowiedz
  7. Kacper

    Wszystko fajnie pięknie, szkoda że ma się to nijak do realiów. Aktualizacja Java? Bardzo chętnie, ale przestanie działać aplikacja X. Aktualizacja „jedynej słusznej” przeglądarki? Pewnie, ale w intranecie system X napisany w jakże wspaniałym Y padnie. I takich przykładów mógł bym podać dziesiątki o ile nie setki. Oprogramowanie dla administracji rządowej kupują finansiści a nie informatycy. Informatyk dzwoniąc na support aplikacji usłyszeć może tylko i wyłącznie „downgrade Z do wersji X.X, z nowszą nie działa”. Chciał bym trzymać swoje podwórko up-to-date, ale to jest nie wykonalne niestety. Jako informatyk na końcu „łańcucha pokarmowego” mogę sobie pomarudzić i złożyć rezygnację. TAKIE SĄ REALIA!

    Odpowiedz
    • Prześledź jeszcze raz tekst, i zobacz np. pojęcie ‚akceptacji ryzyka’ ;-)

      Odpowiedz
      • Kacper

        Nie mówię, że nie zobaczę pojęcia ‚akceptacji ryzyka’ ;) Bardziej miałem na myśli odbiegające od rzeczywistości rozporządzenia (choć to rozporządzenie moim zdaniem jest OK), a jeśli nie rozporządzenia to sytuację software’ową w jednostkach administracji publicznej. Niektóre przetargi i „zamówione” oprogramowanie podpada pod przekręty finansowe moim skromnym zdaniem. Akceptacja ryzyka w postaci 90% aplikacji? Nie akceptuję ;)

        Odpowiedz
        • Kacper – zgadzam się że nie jest to idealne – brakuje jasnego określenia kto i na jakim poziomie szczegółowości powinien robić ten audyt. Zostało to przerzucone na „analizę ryzyka” (http://sekurak.pl/czym-jest-analiza-ryzyka-it-wprowadzenie/) – tyle że też dokładnie nie ma określonego kto w danej jednostce robi do tego założenia. Ale updatey są w drodze (patrz linkowane strony ministerstwa z tego tekstu).

          Odpowiedz
          • Kacper

            Ale jest wiele więcej niedomówień choć by rola ABI w urzędach państwowych. ABI nie może być informatykiem, ale ma się znać na tyle by skontrolować informatyka. Nikt z umiejętnościami nie weźmie sobie fuchy ABI za darmo, wiec ABI podpisuje wszystko co mu się pod nos podsunie bo jest z pierwszej łapanki. Jaki jest więc sens ABI?

    • Sebastian

      Zawsze można stosować dwie przeglądarki (jedną do Internetu z najnowszymi aktualizacjami i jedną z komponentami dostosowanymi do naszego oprogramowania.) Można aplikacje uruchamiać poprzez RemoteApp lub RDS i przez to ograniczyć ryzyko nieaktualnej Javy. Myślę, że biznes nie ma świadomości co może zrobić złośliwe oprogramowanie w sieci którą zarządzamy. Informatyk powinien uświadomić górę jakie będą tego konsekwencje. Jak dowiedzą się, że straty będą milionowe i że będą za to odpowiadać to sami znajdą pieniądze na informatykę.

      Odpowiedz
  8. Mariusz

    Bardzo ciekawy artykuł… (pochwała dla autora) cóż nikt nie powiedział że sprawa jest łatwa więc pozostawmy gdybania. Rolą „informatyka” jest zarządzać zasobami i czynić je dostępnymi w pełnym zakresie dla wszystkich którzy tego potrzebują, w zakresie który jest sprecyzowany przez Kierownictwo. Należy jednocześnie pamiętać o uświadamianiu (proces ciągły) zagrożeń oraz szkoleniu personelu zwłaszcza grupy Management oraz szeregowych pracowników. Należy również uświadomić potrzebę uczestniczenia w redagowaniu SIWZ dotyczącego teleinformatyki ale również budownictwa (bezpieczeństwo fizyczne). Można by wiele ale i szeroka jest tematyka nie marudźmy wiec tylko przedstawiajmy swoje potrzeby (potrzeby firmy) … na piśmie – to bardzo dobra technika. POLECAM

    Odpowiedz
  9. Pier

    Świetny artykuł gratulacje dla Autora

    Odpowiedz
  10. Adam

    Urzędy Administracji Publicznej które świadczą usługi stricte publiczne tak….ale tzw. służby Wojsko, Sądy, Prokuratury, Policja, CBA która stosuje to szerzej chyba nie jest objęta owymi obowiązkami bo usługi w/w raczej nie są zaliczane do kategorii usług publicznych. A zaliczanie owej grupy do jednego katalogu podmiotów publicznych jest niewłaściwe. Choć robią te audyty KRI ….ale na siłę.

    Odpowiedz

Odpowiedz