Category Archives: Bezpieczeństwo

ePUAP- fikcyjny urząd – rozwiązanie zagadki?

Słowo się rzekło, zapytanie do Ministerstwa Cyfryzacji wysłałem (Fri, 22 Apr 2016 01:12:54 +0100), otrzymałem również odpowiedź (Thu, 5 May 2016 09:58:15 +0000) – jak można policzyć, w ustawowym terminie.

O co pytałem?

  1. treść regulaminu lub równoważnego dokumentu regulującego prawa i obowiązki użytkowników (w tym administratorów) platformy ePUAP
  2. politykę bezpieczeństwa informacji
  3. informację który użytkownik utworzył na platformie ePUAP konto podmiotu “Jan Kowalski, 00-001 Poznań, Astrowa 21”
  4. informację, czy, kiedy i z jakim rezultatem wniosek o nadanie funkcjonalności podmiotu publicznego w/w podmiotowi został rozpatrzony przez MAiC
  5. informację, w jaki sposób na platformie ePUAP rejestrowany jest fakt oraz rezultat rozpatrzenia wniosku o nadanie funkcjonalności podmiotu publicznego
  6. jeżeli nie wynikało to z powyższych, wyjaśnienie jakie zabezpieczenia przed nieuatoryzowanym tworzeniem kont użytkowników, podmiotów oraz przed nieautoryzowanym (w tym niepopartym pozytywną decyzją Ministra) nadaniem funcjonalności podmiotu publicznego wdrożone są na platformie

Odpowiedź, jak P.T. czytelnicy mogą zobaczyć poniżej, nie jest wyczerpująca i z wdziękiem omija zagadnienie kto utworzył/autoryzował konto testowe podmiotu publicznego w środowisku produkcyjnym, oraz jakie zabezpieczenia przed nieautoryzowanym utworzeniem takiego podmiotu są wdrożone. Niemniej wdzięczny jestem za otrzymanie kopii Zarządzenia nr 14 Ministra Administracji i Cyfryzacji z dnia 12 września 2012 w sprawie Polityki Bezpieczeństwa elektronicznej platformy usług administracji publicznej z załącznikami, w tym rzeczoną Polityką Bezpieczeństwa epuap. Wdzięczny jestem tym bardziej, że w/w zarządzenia nie sposób znaleźć w Dzienniku Urzędowym Ministra Administracji i Cyfryzacji (jak również w Dzienniku Urzędowym Ministra Cyfryzacji). W trakcie moich poszukiwań ustaliłem, że dokument ten wydobył już prędzej nieoceniony Adam Dobrawy, który swoje perypetie opisuje w serwisie ochrona.jawne.info.pl. Można tam znaleźć również link do przedmiotowego dokumentu, ja dla zwiększenia dostępności udostępniam “moją” kopię również tutaj. Jest to skan dokumentu, wyszukiwanie tekstowe nie działa.

Poniżej treść odpowiedzi, którą otrzymałem:

RP-MC-BM-odpowiedz
Szanowny Panie,

w odpowiedzi na wniosek z dnia 22 kwietnia 2016 r. uprzejmie informuję, że prawa i obowiązki użytkowników platformy ePUAP reguluje Rozporządzenie Ministra Administracji i Cyfryzacji z dnia 6 maja 2014 r. w sprawie zakresu i warunków korzystania z elektronicznej platformy usług administracji publicznej (Dz. U. z 2014 r. poz. 584). Podmiot „Jan Kowalski” o identyfikatorze epuap_test1IP został założony na potrzeby odbiorów produktów (e-usług) w ramach projektu POKL. Sytuacja ta była wyjątkowa, że względu na całkowite wykorzystywanie środowiska testowego ePUAP, w chwili zakładania
konta epuap_test1IP, na potrzeby testów wdrożeniowych nowej odsłony ePUAP 2. Fakt posiadania przez podmiot funkcjonalności podmiotu publicznego na ePUAP jest przede wszystkim rozpoznawalny ze względu na możliwość wyszukania danego podmiotu w słowniku listy adresatów w usłudze pisma ogólnego do podmiotu publicznego. Dokładniej, już następnego dnia po nadaniu uprawnień możliwe jest wysłanie pisma do danego podmiotu i otrzymanie Urzędowego Poświadczenia Przedłożenia (UPP). Ponadto uprzejmie wyjaśniam, iż funkcjonalność podmiotu publicznego nadają wyłącznie osoby upoważnione przez Ministra Cyfryzacji, po weryfikacji danych z wniosku o nadanie funkcjonalności. Jednocześnie w załączeniu przesyłam obowiązujące zarządzenie w sprawie Polityki Bezpieczeństwa elektronicznej platformy usług administracji publicznej.

Lektura Polityki Bezpieczeństwa, która, po pobieżnym przejrzeniu, wydaje się być sensowna, być może zaoowocuje kolejnym “pogłębeniem tematu” z mojej strony, za co pracowników Ministerstwa z góry przepraszam, z drugiej strony mając nadzieję, że zadawane pytania oraz ewentualna krytyka odbierane są konstruktywnie, z pożytkiem dla wszystkich użytkowników platformy ePUAP.

ePUAP- fikcyjny urząd cd…

22 lutego 2016, zażywając uciech doczesnych w postaci przeczesywania platformy ePUAP w poszukiwaniu właściwej usługi i właściwego urzedu, natknąłem się na “podejrzany” podmiot o nazwie “Jan Kowalski”, z siedzibą w Poznaniu, przy ulicy Astrowej 21, kod pocztowy 00-001.

Podmiot ten istnieje do dziś:
ePUAP_Kowalski_2016-04-15

Znalezisko niezwłocznie zgłosiłem tego samego dnia korzystając z funkcji Zadaj pytanie / Zgłoś uwagę w systemie ePUAP, a już w piątek 26/02/2016 otrzymałem maila z następującą odpowiedzią:

Re: [Ticket#056902] Dane testowe w środowisku produkcyjnyn
Service-Desk. 26 February 2016 at 10:07
To: ######@#######
Szanowny(a) Panie(i)

Dziękuję za przekazanie spostrzeżeń. Faktycznie mogą występować konta, gdzie osobom fizycznym zostaną nadane uprawnienia podmiotu publicznego.

Pozdrawiam
##################
Zespół Service Desk
Centrum Cyfrowej Administracji.

Oszczędzając słowa, rzekłbym, że odpowiedź nie wyczerpuje tematu. Problem z tym “podmiotem” na platformie ePUAP jest taki, że

  • nazwa tego podmiotu to, w powszechnym przekonaniu, najbardziej popularne imię i nazwisko w Polsce, czyli metonim przeciętnego obywatela Polski.
  • kod pocztowy jest nieprawidłowy dla siedziby podmiotu (Poznań):
    Poczta_Polska_kod_00-001_2016-04-15
  • Adres również wygląda na nieprawidłowy (nie ma numeru 21 przy Astrowej w Poznaniu):
    geoportal_Astrowa_Poznan_2016-04-15

Mając na względzie przepisy rozporządzenia Ministra Administracji i Cyfryzacji z dnia 6 maja 2014 r. w sprawie zakresu i warunków korzystania z elektronicznej platformy usług administracji publicznej do głowy przychodzi co najmniej kilka pytań…

§ 4. 1. Założenie konta dla podmiotu jest dokonywane przez użytkownika zarejestrowanego działającego w imieniu podmiotu i wymaga podania:
1) nazwy podmiotu;
2) identyfikatora podmiotu.
2. Użytkownik zarejestrowany, zakładając konto dla podmiotu, staje się administratorem podmiotu.
3. Identyfikator użytkownika i identyfikator podmiotu są wybierane przez użytkownika. Raz nadany identyfikator nie może być nadany ponownie.
4. W przypadku zmiany danych, o których mowa w ust. 1 pkt 1, użytkownik zarejestrowany działający w imieniu podmiotu powinien niezwłocznie dokonać ich zmiany w profilu podmiotu.
5. Konto podmiotu może usunąć administrator tego podmiotu albo minister na wniosek podmiotu.
§ 5. 1. Podmiot publiczny występuje do ministra z wnioskiem o nadanie funkcjonalności podmiotu publicznego na ePUAP.

2. Wniosek, o którym mowa w ust. 1, zawiera:
1) oznaczenie podmiotu publicznego;
2) imię i nazwisko osoby upoważnionej do reprezentacji podmiotu publicznego wraz z podaniem funkcji lub stanowiska;
3) dane administratora podmiotu.
3. Funkcjonalność podmiotu publicznego na ePUAP staje się dostępna po pozytywnym rozpatrzeniu wniosku przez ministra.

Pytania prześlę do Ministerstwa.

Super silne szyfrowanie numerów kart płatniczych

Oczywisty jest wyłącznie marketingowy aspekt zapewnienia opublikowanego na stronie, bo jego wartość merytoryczna jest bliska zeru (szyfrowanie transmisji czy w spoczynku? 128bit RC4 czy 128bit AES?). Mimo tej wieloznaczności,  faktom nie  udaje się dopasować do teorii 🙂

bsi-group-encryption-mark-record-publicSzczególnie zastanawia powtarzająca się pozycja “preferred”. Będzie okazja przetestować proces obsługi incydentów 🙂

  * TLSV1_2 Cipher Suites:
      Preferred:
                 RC4-MD5                       -              128 bits      HTTP
      Accepted:
                 AES256-SHA                    -              256 bits      HTTP
                 RC4-SHA                       -              128 bits      HTTP
                 RC4-MD5                       -              128 bits      HTTP
                 AES128-SHA                    -              128 bits      HTTP
                 DES-CBC3-SHA                  -              112 bits      HTTP

  * TLSV1_1 Cipher Suites:
      Preferred:
                 RC4-MD5                       -              128 bits      HTTP
      Accepted:
                 AES256-SHA                    -              256 bits      HTTP
                 RC4-SHA                       -              128 bits      HTTP
                 RC4-MD5                       -              128 bits      HTTP
                 AES128-SHA                    -              128 bits      HTTP
                 DES-CBC3-SHA                  -              112 bits      HTTP

  * SSLV3 Cipher Suites:
      Preferred:
                 RC4-MD5                       -              128 bits      HTTP
      Accepted:
                 AES256-SHA                    -              256 bits      HTTP
                 RC4-SHA                       -              128 bits      HTTP
                 RC4-MD5                       -              128 bits      HTTP
                 AES128-SHA                    -              128 bits      HTTP
                 DES-CBC3-SHA                  -              112 bits      HTTP

  * TLSV1 Cipher Suites:
      Preferred:
                 RC4-MD5                       -              128 bits      HTTP
      Accepted:
                 AES256-SHA                    -              256 bits      HTTP
                 RC4-SHA                       -              128 bits      HTTP
                 RC4-MD5                       -              128 bits      HTTP
                 AES128-SHA                    -              128 bits      HTTP
                 DES-CBC3-SHA                  -              112 bits      HTTP

Aktualizacja 30/11/2015:

poza wstępną odpowiedzią, że sprawa zostanie przekazana do odpowiedniego działu nic ciekawego nie otrzymałem, ale widać poprawę:

  * TLSV1_2 Cipher Suites:
      Preferred:
                 AES256-SHA                    -              256 bits      HTTP  
      Accepted:
                 AES256-SHA                    -              256 bits      HTTP  
                 DES-CBC3-SHA                  -              112 bits      HTTP  

  * TLSV1_1 Cipher Suites:
      Preferred:
                 AES256-SHA                    -              256 bits      HTTP  
      Accepted:
                 AES256-SHA                    -              256 bits      HTTP  
                 DES-CBC3-SHA                  -              112 bits      HTTP  

  * SSLV3 Cipher Suites:
      Server rejected all cipher suites.

  * TLSV1 Cipher Suites:
      Preferred:
                 AES256-SHA                    -              256 bits      HTTP  
      Accepted:
                 AES256-SHA                    -              256 bits      HTTP  
                 DES-CBC3-SHA                  -              112 bits      HTTP  

Security through obscurity wiecznie żywe

CC BY-NC 2.0 Glen Darrud
CC BY-NC 2.0 Glen Darrud

P.T. Pan Klient zażądał dzisiaj, żeby zablokować skanowanie jego systemów (udostępnionych publicznie usług) przez Shodan. Jako że Shodan nawiązując połączenie niczym szczególnym się nie wyróżnia, to technicznie należaloby to zrealizować blokując ruch z określonej grupy adresów źródłowych (z których Shodan dokonuje skanowania). Podejście to ma masę słabości, poczynając od tego, że Shodan takiej listy nie publikuje, a to co można znaleźć w sieci to zapis pewnego wycinka rzeczywistości w określonej chwili, bez gwarancji, że zebrane adresy będą niezmienne w przyszłości.

Inżynier, który pracował nad tym zgłoszeniem, zrobił dobrą robotę, i zasugerował uszczelnienie polityki firewalla tak, aby tylko rzeczywiście niezbędne zasoby były dostępne publicznie, a także regularne testy bezpieczeństwa, aplikowanie poprawek i innych rozwiązań usuwających ewentualne podatności – zamiast blokowania skanera. Pan Klient jednak wie lepiej, płaci i wymaga, tak więc koniec końców zaimplementowana została reguła blokująca kilkadziesiąt adresów mniej lub bardziej powiązanych z Shodanem. Inne niż Shodan skanery, w tym potencjalni atakujący, mogą dalej prowadzić rekonesans ze swoich (lub cudzych) adresów. Ponieważ rezultatu tych działań nie będzie widać na shodan.io to Pan Klient będzie spał spokojniej, może nawet zmniejszy częstotliwość testów penetracyjnych, a z poczynionych oszczędności ktoś przyzna mu premię.

A kiedy padną ofiarą ataku… winny będzie MSSP, który przegrał zawody w kopaniu się z koniem.

www.gitd.gov.pl – serwer dedykowany w OVH

Informacja publiczna uzyskana w dniu 16.02.2015, w odpowiedzi na wniosek z dnia 15.02.2015 skierowany do Głównego Inspektoratu Transportu Drogowego. Zgodnie z duchem art. 13 ust. 1 ustawy – czyli bez zbędnej zwłoki.  Interesowały mnie tryb i kryteria wyboru dostawcy usługi hostingowej wykorzystywanej do utrzymania strony internetowej http://www.gitd.gov.pl/ a także treść, wartość oraz okres obowiązywania umowy na tę usługę.

Treść odpowiedzi:

GITD-odpowiedz-2015-02-16

Wspomniany w odpowiedzi Regulamin Zamówień Publicznych, w obecnym brzmieniu ustalony został zarządzeniem nr 10/2015 Głównego Inspektora Transportu Drogowego, które jest dostępne online.

Szczególnie zainteresowało mnie stwierdzenie:

Nie zawierano umowy – jest to standardowa usługa dzierżawy serwerów dedykowanych w fimie OVH Sp. z. o.

Pani Kobylska twierdzi, że GITD zawarł umowę dzierżawy nie zawierając umowy, a jednocześnie płaci za tę (bezumowną) dzierżawę 7679 złotych i 88 groszy rocznie. Intrygujące.

Na końcu pojawiają się formułki dotyczące mojej odpowiedzialności za błąd nadawcy, a także ochrony środowiska naturalnego – czyli Corporate email bullshit.

Zastanawia mnie, który podmiot w tym układzie biznesowym, z “bezumowną” dzierżawą w tle, dba o to, aby przedmiotowy serwer i informacje na nim przetwarzane były objęte oddziaływaniem systemu zarządzania bezpieczeństwem informacji, o którym mowa w § 20 Rozporządzenia 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. Kto dba o zapewnienie dostępności informacji – na przyklad przyłączając serwer z użyciem nadmiarowych łącz do Internetu i chroniąc serwer fizycznie, przed celową bądź przypadkową manipulacją jego stanem. Zgaduję, że GITD nie oddelegowało pracowników do Roubaix w tym celu. Zapewne dba o to dostawca, tylko GITD o tym nie wie…

Oprogramowanie serwera również cierpi na  parę bolączek, ale to temat na osobne zapytanie o dostęp do informacji publicznej:

GITD-reverse-proxy-176.31.238.14.png

Czy kontrola paszportowa zwiększa bezpieczeństwo lotu?

Na forum lotnictwo.net.pl pojawił się ciekawy wątek. Jego autor poddaje w wątpliwość czujność służb bezpieczeństwa w porcie lotniczym im. Chopina w Warszawie:

Wróciłem w niedzielę z Madrytu[…] My z żoną lecieliśmy przez WAW (lotnisko Chopina w Warszawie – przyp. aut.) i CDG (lotnisko Charles de Gaulle w Paryżu – przyp. aut.), przyjaciółki przez Modlin. Po raz kolejny na Okęciu NIKT nie sprawdził żadnego naszego dowodu tożsamości. Boarding passy wydrukowane w domu czy na telefonie, dotknięcie przy wejściu do security, dotknięcie przy boardingu i tyle. W Paryżu żadnej kontroli takoż. Miałem już tak bardzo wiele razy.
[…]Na pewno się obudzą jak coś się stanie. Czy naprawdę potrzebujemy zawsze jakiś intensywnych bodźców żeby wykonywać należycie zadania, to przecież powinna być rutyna

W jednym z kolejnych postów dodaje:

Procedury bezpieczeństwa są od tego, żeby ich przestrzegać – choćby po to, żeby na pokład samolotu nie wszedł ktoś o kim wiadomo, że ma powiązania z terrorystami. Jeśli to złe prawo, to trzeba je zmienić ale nie przez jego ignorowanie.

Można to skomentować dwojako – po pierwsze, z punktu widzenia obowiązującego prawa, po drugie z perspektywy wpływu przestrzegania domniemanej procedury na bezpieczeństwo lotu.

W art. 14 Ustawy o ochronie granicy państwowej ustawodawca postanowił:

1. Przekraczanie granicy państwowej jest dozwolone na podstawie dokumentów uprawniających do jej przekroczenia.
2. Dokumenty, o których mowa w ust. 1, określają odrębne przepisy, w tym umowy międzynarodowe, których Rzeczpospolita Polska jest stroną, lub przepisy prawa Unii Europejskiej.
3. Przekraczanie granicy państwowej stanowiącej granicę wewnętrzną w rozumieniu przepisów rozporządzenia (WE) nr 562/2006 Parlamentu Europejskiego i Rady z dnia 15 marca 2006 r. ustanawiającego wspólnotowy kodeks zasad regulujących przepływ osób przez granice (kodeks graniczny Schengen) (Dz. Urz. UE L 105 z 13.04.2006, str. 1), zwanego dalej “kodeksem granicznym Schengen”, następuje na zasadach określonych w kodeksie granicznym Schengen.

 Z kolei Rozporządzenie (WE) nr 562/2006 Parlamentu Europejskiego i Rady (“kodeks graniczny Schengen”) zawiera następujące przepisy:

Artykuł 20 Przekraczanie granic wewnętrznych
Granice wewnętrzne mogą być przekraczane w każdym miejscu bez dokonywania odprawy granicznej osób niezależnie od ich obywatelstwa.

Artykuł 21 Odprawa na terytorium
Zniesienie kontroli granicznej na granicach wewnętrznych nie wpływa na:
a) wykonywanie uprawnień policyjnych przez właściwe organy Państw Członkowskich na mocy prawa krajowego, o ile wykonywanie tych uprawnień nie ma skutku równoważnego z odprawą graniczną; ma to zastosowanie również do obszarów przygranicznych. W rozumieniu zdania pierwszego wykonywanie uprawnień policyjnych nie może być w szczególności uznawane za równoważne dokonywaniu odprawy granicznej, jeżeli środki policyjne:
i) nie mają na celu kontroli granicznej;
ii) są oparte na informacjach i doświadczeniu policyjnym o charakterze ogólnym, dotyczących potencjalnych zagrożeń dla bezpieczeństwa publicznego i mają na celu w szczególności walkę z przestępczością transgraniczną;
iii) są opracowywane i stosowane w sposób zdecydowanie odróżniający je od rutynowej odprawy osób na granicach zewnętrznych;
iv) są przeprowadzane na podstawie kontroli wyrywkowej;

b) kontrolę bezpieczeństwa osób przeprowadzaną w portach i na lotniskach przez właściwe organy na mocy prawa każdego Państwa Członkowskiego przez funkcjonariuszy portu lub lotniska lub przewoźników, pod warunkiem że kontrola tego typu przeprowadzana jest również w stosunku do osób podróżujących po terytorium danego Państwa Członkowskiego;

c) możliwość ustanowienia przez Państwo Członkowskie przepisów o obowiązku posiadania lub posiadania przy sobie papierów i dokumentów;

d) obowiązek zgłaszania przez obywateli państw trzecich swojej obecności na terytorium któregokolwiek Państwa Członkowskiego zgodnie z postanowieniami art. 22 Konwencji z Schengen.

Biorąc pod uwagę powyższe, wygląda na to, że autor przedstawionego na początku wpisu nie ma racji. Służby ochrony lotniska, na podstawie art. 36 ustawy o ochronie osób i mienia mają prawo ustalania uprawnień do przebywania na obszarach lub w obiektach chronionych oraz legitymowania osób w celu ustalenia ich tożsamości, ale nie mają takiego obowiązku. Prawdopodobnie przekonanie o konieczności weryfikacji tożsamości pasażerów bierze się z częstej praktyki przewoźników lotniczych, polegającej na porównaniu nazwiska na karcie pokładowej z dokumentem tożsamości. Praktyka ta wynika z regulaminu przewoźnika i zazwyczaj ma na celu uniemożliwienie odstąpienie biletu innej osobie bez wniesienia opłat przewidzianych w cenniku. Dla potwierdzenia – rzut oka na informacje dla podróżnych opublikowane przez port lotniczy, a tam w dziale kontrola dokumentów stoi czarno na białym:

Po odprawie biletowo-bagażowej oraz kontroli bezpieczeństwa pasażerowie podróżujący z Warszawy do portów lotniczych w państwach spoza strefy Schengen przechodzą przez kontrolę dokumentów prowadzoną przez Straż Graniczną.

Zakładając, że autor w takim razie postuluje obowiązek sprawdzania tożsamości pasażerów, warto zadać sobie pytanie jaki to ma sens. Czy wiadomość, że danym lotem na pewno podróżuje Jan Kowalski a nie Adam Nowak zwiększa bezpieczeństwo lotu i jego pasażerów? W przeciwieństwie do autora, nie miałbym oporów lecieć razem z Osamą bin Laden, jeżeli obowiazujące procedury bezpieczeństwa byłyby przestrzegane – to znaczy w bagażu podręcznym ani rejestrowanym tego współpasażera nie byłoby przedmiotów uznanych za niebezpieczne. Z drugiej strony, weryfikacja tożsamości po to, żeby na pokład samolotu nie wszedł ktoś o kim wiadomo, że ma powiązania z terrorystami wydaje się być kiepskim pomysłem. Po pierwsze nie wiadomo jaka miałaby być definicja powiązania z terrorystami, po drugie kto miałby tworzyć, aktualizować (jak często) i przetwarzać taką listę, po trzecie czy z tej listy można by się wypisać. Wypisz, wymaluj – no-fly list z wszystkimi jej wadami – od fałszywych alarmów, z niemowlętami włącznie, po łatwość jej ominięcia przez prawdziwych terrorystów (np. używając fałszywego dokumentu tożsamości).

Przymusowa weryfikacja dowodu tożsamości sprawiłaby kłopot zwykłemu podróżnemu, który zapomniał zabrać dowód osobisty, ale z dużym prawdopodobieństwem nie stanowiłaby żadnej przeszkody dla terrorysty, posiadającego przy sobie czysty jak łza paszport kupiony od odpowiedniego specjalisty. Założenie, że ktoś o kim wiadomo, że ma powiązania z terrorystami i stanowi zagrożenie dla bezpieczeństwa lotu, będzie posługiwał się dokumentem ujawniającym jego prawdziwą tożsamość (a co za tym idzie – owe powiązania) jest naiwne. Jeżeli z kolei ma powiązania z terrorystami ale nie stanowi zagrożenia dla bezpieczeństwa lotu to dlaczego akurat służby ochrony lotniska czy też pracownicy linii lotniczych mieliby się taka osobą zajmować (a nie na przykład policja, czy też inne powołane do tego celu służby)zakładając, że na to powiązanie z terrorystami jest jakiś paragraf.

Weryfikacja tożsamości może mieć sens, ale w innym modelu kontroli bezpieczeństwa, np. takim jaki stosowany jest na lotnisku Ben Gurion w Tel Awiwie. Okazanie dokumentu stwierdzającego tożsamość jest tam tylko wstępem do jej badania, a nie celem samym w sobie. Kontrola dokumentów połączona z dość intensywnym wywiadem może zająć nawet kilkadziesiąt minut, ale za to nie musiałem zdejmować butów ani pozbywać się napojów (powyżej 1l.) z bagażu podręcznego przed prześwietleniem, a mój pasek ze stalową sprzączką nie stanowił problemu przy przejściu przez wykrywacz metali.

Zasada czystego biurka – clean desk policy

CC BY-NC-SA 2.0 Tal-Bright
CC BY-NC-SA 2.0 Tal Bright

Przemierzałem budynek, w  którym obowiązuje zasada czystego biurka (clean desk policy), a na ścianach co kilka metrów wiszą plakaty przypominające o tym fakcie. Mijając małą salę konferencyjną zobaczyłem stół przygotowany dla trzech osób, na nim dokumenty, a w promieniu kilku metrów nie było żywej duszy. Zdjęcia brak, bo wykonywanie zdjęć było zabronione (ale jak wiadomo, norma prawna zapisana w art. 278 Kodeksu Karnego nie jest respektowana przez złodziei, a intruz niekoniecznie będzie zainteresowany przestrzeganiem polityki bezpieczeństwa).

FireEye, FPC, DLP, IPS i inne słowa kluczowe dobrze sie sprzedają. Niestety najsłabszym ogniwem byli i są ludzie, a nie środki techniczne. Z drugiej strony nie ma lepszej ochrony niż zespół dobrze wyszkolonych, inteligentnych osób.

Ciekawe jak często można pracownikom przeprowadzać szkolenie z podstaw bezpieczeństwa – unikając zmęczenia materiału i mechanicznych odpowiedzi pozbawionych odrobiny refleksji – tak żeby każdy cykl szkoleń zmniejszał liczbę klikniętych linków, otwartych załączników w niezamawianej korespondencji elektronicznej, czy też pozostawionych na biurku przedmiotów.

W tym temacie: ciekawa decyzja administracyjna dotycząca poświadczenia bezpieczeństwa.

Bezpieczna komunikacja przy użyciu pojemnika z moczem

Nie wiem jak często przedstawiony poniżej sposób komunikowania się jest wykorzystywany, ale niewątpliwie jest prosty a zarazem dość bezpieczny – a tych dwóch kryteriów łącznie nie spełnia np. GPG – tutaj instrukcja wysyłania zaszyfrowanej wiadomości.speak-in-confidence

Dla wyjaśnienia – ulotka, pojemnik oraz naklejki zlokalizowane są w toalecie dla pacjentek. Pojemnik (oznakowany lub nie) pacjentka pozostawia na półce w środku, a personel regularnie odbiera cały zestaw pojemnikó. Dość skutecznie blokuje to możliwość przechwycenia wiadomości przez osobę niepożądaną.

W Wielkiej Brytanii położne rutynowo odpytują ciężarne czy mają wsparcie w domu, czy mają jakieś problemy, a czasami wprost – czy nie są ofiarami przemocy. Często podczas spotkania obecny jest mąż/partner pacjentki – co oczywiście stanowi przeszkodę, jeżeli jest on domniemanym sprawcą. Jednym ze sposobów na ominięcie tego problemu jest sprowokowanie sytuacji sam na sam przy użyciu różnych zabiegów socjotechnicznych, ale oprócz tego, jak widać na załączonym powyżej obrazku, istnieje dodatkowy kanał komunikacji.

“Proszę pozostawić nam próbkę do analizy – w toalecie, na ścianie po lewej stronie jest instrukcja.”

 

Checkpoint IPS – protect internal hosts only – jak to działa?

Ostatnio otrzymałem takie oto pytanie:

Jak działa Checkpoint IPS, jeżeli w konfiguracji modułu,  w sekcji “Protection scope”  wybraje jest ustawienie “Protect internal hosts only”.

Checkpoint-protect-internal-hosts-only

Precyzyjniej rzecz ujmując, pytający chciał wiedzieć, czy w takiej konfiguracji moduł IPS będzie analizował tylko ruch przepływający pomiędzy interfejsem o topologii “External” a interfejsami o topologii “Internal”, czy też może analizie będzie również poddany ruch “Internal” do “Internal”.

Odpowiedź wcale nie jest oczywista, co można zaobserwować m.in. w dyskusji na cpug.org. Również logika modułu firewall, który decyzje podejmuje zazwyczaj przed trasowaniem pakietu, tj. w sytuacji, kiedy tylko interfejs źródłowy jest znany, sugeruje że omawiane ustawienie wymusza analizę ruchu, którego źródło to interfejs o topologii “External”

Checkpoint-topology

Stan faktyczny jest taki, że analizie poddawany jest każdy ruch kierowany do interfesju “Internal” – bez względu na jego interfejs źrodłowy – zarówno “External” jak i “Internal”. Dodatkowo, w przypadku kiedy sygnatura ma typ “Server/Client”, analizie poddany będzie ruch “Internal” do “External”.

Źródło: Checkpoint sk94072

Jakie jest znaczenie praktyczne tego ustawienia? Pokażę to na przykładzie.

Firewall brzegowy z uruchomionym modułem IPS. W profilu IPS aktywna sygnatura typu “Server protection”, chroniąca serwer www Apache przed atakami na pewną podatność. Profil ruchu: 1 000 000 nowych połączeń na godzinę, z tego 100 000 w kierunku “External”->”Internal”, 200 000 “Internal”->”Internal” i 700 000 “Internal”->”External”.  Dla uproszczenia zakładam, że 50% ruchu we wszystkich kierunkach to ruch HTTP.

Wersja 1 – aktywne jest ustawienie “Protect internal hosts only”
Ruch HTTP kierowany do interfejsów “Internal” to 50%x(100 000+200 000)=150 000 połączeń na godzinę. Tyle połączeń zostanie poddanych analizie przez aktywną sygnaturę, w celu ochrony chronionych serwerów www znajdujących się za interfejsami “Internal”. Jest to analogiczne do stosowanej w Snorcie konstrukcji any -> $HOME_NET.

Wersja 2 – aktywne jest ustawienie “Perform IPS inspection on all traffic”. Ruch HTTP kierowany do wszystkich interfejsów to 50%x1 000 000=500 000 połączeń na godzinę – i wszystkie one zostaną poddane analizie. De facto sensor w tej konfiguracji chroni “cały  Internet” przed atakami – analogiczne do Snortowego any -> any

Można przywołać wiele argumentów na obronę tezy, że inspekcji powininen być poddawany cały ruch – wykrywanie hostów z sieci wewnętrznej dokonujących ataków na obce systemy, wykorzystując zasoby organizacji, że sensor powinien być odpowiednio zlokalizowany itd. W praktyce jest tak, że klienci kupując urządzenia wymiarują je do celu ochrony własnej sieci,a uruchomienie trybu ochrony “wszystkiego” może powodować problemy z wydajnością, stabilnością, aż do odmowy wykonania usługi włącznie.

Producent zaleca, w zbiorze najlepszych praktyk dotyczących wydajności, aby używać ustawienia “Protect internal hosts only”. Odmienna konfiguracja – jeżeli jest pożądana – powinna być poprzedzona testowaniem i optymalizacją profilu IPS, a jeszcze lepszym rozwiązaniem wydaje się być przerzucenie ciężaru analizy ruchu wychodzącego na zewnątrz bliżej źródła – np. na serwer proxy albo oprogramowanie uruchomione na urządzeniu klienckim.