Wszechobecna inwigilacja

Co rozumiemy przez monitoring? Chodzi tutaj o uczenie się przez system typowych zachowań użytkownika. Na podstawie zgromadzonych informacji wiadomo na przykład, że Jan Kowalski co piątek wykonuje kilka przelewów. Robi to ze swojego domu na przedmieściach Warszawy, ok. godziny 20.00 - tuż po telewizyjnych wiadomościach. Łączy się z reguły poprzez przeglądarkę Internet Explorer w wersji 6.5, z Windows Vista. Do tego dochodzi weryfikacja samej transakcji. Powiedzmy, że nasz Jan dokonuje przelewów na kwoty nie przekraczające 1000 zł. Tego rodzaju informacje dają punkt zaczepienia do prowadzenia dalszych analiz. Każde odstępstwo od tego wzoru może wzbudzić podejrzenia.

Systemy FDS to złożony zbiór wielu technik i technologii, które mają zapewnić wysoki poziom trafności rozpoznawania podejrzanych transakcji. Mamy tutaj do dyspozycji techniki takie jak: weryfikacja informacji udostępnianych przez samą stację kliencką, profilowanie użytkownika, geolokacja, analiza ryzyka związanego z transakcją, kontekstowa analiza wzorca transakcji czy analiza sposobu korzystania przez użytkownika z aplikacji dostępowej. Otrzymujemy także możliwość integracji z systemami dodatkowej weryfikacji transakcji czy tożsamości użytkownika - najczęściej OOB (Out Of Band). Wszystkie te technologie tak naprawdę służą do zliczania punktów przyznawanych za każdy z badanych parametrów (tzw. scoring), następnie przeprowadzenia na tej podstawie analizy ryzyka i zaakceptowania, bądź zakwestionowania (dalsza weryfikacja), czy wręcz odrzucenia transakcji. Mówiąc o FDS, nie można zapominać o technologii Risk Based Authentication (RBA). Wykorzystując zarówno dane historyczne, jak i te dostarczane w czasie rzeczywistym, określa prawdopodobieństwo tego, czy działania użytkownika mogą być niewiarygodne. Informacje te nie są badane jednostkowo, ale w kontekście pozostałych danych. Takimi atrybutami mogą być np.: dane logowania, adres IP, lokalizacja fizyczna lub typ wykorzystywanego do przeprowadzania transakcji urządzenia. Do tego dochodzą jeszcze dane dotyczące transakcji. Mając to wszystko, możliwe jest stworzenie wzorca lub też pewnego profilu typowego zachowania użytkownika, do którego można porównywać jego późniejsze działania - tzw. baselining. Wiadomo też, że transakcje elektroniczne to byt niezwykle dynamiczny. Dlatego też silnik korelujący, który leży u podstaw RBA, musi być wystarczająco inteligentny, aby uczyć się i naginać do zmieniających warunków. Stosowane są tutaj rozmaite koncepcje sztucznej inteligencji - od prostego modułu opartego na regułach - jak w firewallu, poprzez uczenie maszynowe, aż po rozbudowane analizatory anomalii. Każde z tych podejść ma wady i zalety - sporo rozwiązań wykorzystuje wszystkie z nich.

Silnik oparty na regułach pozwala na bardzo szczegółowe określenie warunków, jakich wystąpienie sprawia, że transakcja może być uznana za podejrzaną. Można stosować wyrażenia regularne, dopisywać dodatkowe moduły sprawdzające itp. Niestety, silnik ten potrafi tylko i wyłącznie postępować według z góry wyznaczonych wzorców. W związku z tym nie pozwala na wykrycie nowych typów nadużyć, a jego obsługa wymaga sporych nakładów administracyjnych - ciągłe zmiany reguł i wieczna deweloperka. Analizatory anomalii mają tę przewagę nad silnikami pracującymi wg reguł, że same wyszukują zachowania nietypowe, zanim ktoś zdąży opisać je regułą. Ponadto stosowane np. w systemie VIP Verisign wykorzystują algorytm klastrujący, za pomocą którego podobne transakcje są agregowane, następnie grupowane i tworzą wspólny wzorzec zachowania. Każdorazowe przeprowadzenie transakcji to porównanie jej cech do takich wzorcowych klastrów. Jeżeli zachowanie nie pasuje do żadnego z nich, wówczas transakcja uważana jest za podejrzaną. Inni producenci stosują nieco inne podejście, ale chodzi o to samo.

Oszukanie systemu opartego na RBA nie jest wcale proste. Atakujący musiałby po pierwsze dokładnie znać zasady działania silników pracujących w tle, po drugie poznać mechanizmy korelacji, atrybuty brane pod uwagę (te w każdej organizacji są inne) oraz akceptowalne stopnie odchylenia od normy. Badanie działań użytkownika może następować na różnych etapach transakcji - proces logowania, standardowe operacje czy operacje wysokiego ryzyka. Zalet RBA nie można nie doceniać. Jest to technologia pracująca w tle, w sposób niewidoczny dla użytkownika. Efekty jej działania dla Jana Kowalskiego są widoczne tylko wówczas, jeżeli wykryta zostanie transakcja, która może budzić wątpliwości. Rośnie zatem zaufanie użytkownika do dostawcy usługi.

Komputer pod lupą

To, co w danym przypadku brane jest pod uwagę podczas oceny ryzyka, zależy od konkretnego rozwiązania. Każdy ma swoje preferencje. Niektórzy producenci (np. Iovation czy 41st Parameter) skupiają się na ocenie wiarygodności czy też reputacji stacji końcowej - tzw. CDI (Client Device Indentification). Badana jest tutaj każda stacja kliencka, która łączy się z portalem. Jeżeli podczas takiej sesji system zauważy, że stacja ta powoduje zakłócenia, albo działa niezgodnie z przyjętym wcześniej wzorcem, wtedy przyznaje jej punkty negatywne - co prowadzi do utraty reputacji. Z drugiej strony, gdy stacja zachowuje się prawidłowo - otrzymuje plusy. Dla przykładu: jeżeli z jednego komputera łączymy się z setką różnych kont albo korzystamy z kilkudziesięciu kart kredytowych, to z pewnością nie jest to zachowanie standardowe. Zbadanie stacji nie wymaga pobrania przez nią jakiegokolwiek kodu. Rezultaty weryfikacji reputacji są przechowywane w bazie danych, która może być współdzielona z innymi organizacjami. Dzięki temu możliwe jest zewidencjonowanie większej liczby potencjalnie wrogich komputerów. Systemy CDI oraz im pokrewne najczęściej potrafią zbierać informacje, takie jak: rodzaj, wersja oraz język systemu operacyjnego, rodzaj i wersja przeglądarki internetowej. Tych parametrów jest znacznie więcej.

Systemy oparte na badaniu reputacji stacji klienckich sprawdzają się dobrze nie tylko w przypadku systemów finansowych czy e-commerce. Całkiem nieźle wpasowują się w potrzeby dostawców gier internetowych. Nie ma jednak róży bez kolców. Systemy bazujące tylko i wyłącznie na CDI uważane są za nieskuteczne w przypadku ataków typu Man--In-The-Browser.

Wiemy, gdzie jesteś!

Z FDS i badaniem stacji związane są także usługi geolokacji - czyli w dużym uproszczeniu identyfikacji, na podstawie adresu IP, komputera łączącego się z portalem. Obecnie identyfikacja adresu IP nie wystarcza - potwierdzają to firmy zajmujące się dostarczaniem usług geolokacji, np. MaxMind czy Quova. Na marginesie: okazuje się, że gros systemów FP wykorzystuje usługi geolokacji firmy Quova (np. Verisign czy CyberSource). Potrzebne jest też rozpoznawanie typu połączenia (np. DSL, dial-up), danych dotyczących routingu czy domen powiązanych z określonym adresem. Do tego dochodzi problem łączenia się przez różnego rodzaju proxy albo sieci maskujące (np. Tor). Część systemów geolokacji w pewnych przypadkach potrafi spojrzeć poza serwer proxy i ustalić prawdziwy adres IP, z którego nawiązywane jest połączenie. Jeżeli nie uda się tego zrobić, to transakcja przechodząca przez proxy może być z góry oznaczana, jako ta o podwyższonym ryzyku. Dzięki danym z takich systemów możemy budować dodatkowe kryteria wiarygodności transakcji. Możliwe jest np. porównanie lokalizacji, z której nawiązywane jest połączenie z danymi posiadacza konta w naszej usłudze. Odnosząc się do wspomnianego Jana Kowalskiego - gdy konto zostało otwarte w Warszawie, a połączenie pochodzi z Władywostoku, to może być to znak ostrzegawczy. Ponadto możemy wychwycić coś, co eksperci określają mianem "impossible travel" (podróż niemożliwa do odbycia). Chodzi tutaj o sytuację, w której np. o 13.45 Jan loguje się do systemu z Krakowa, a już trzy minuty później z jego konta zlecana jest realizacja przelewu z Pekinu. Geolokacja pozwala także na włączenie czerwonego światła ostrzegawczego w momencie, kiedy połączenie pochodzi z kraju tzw. wysokiego ryzyka. Tradycyjnie takimi miejscami są: kraje afrykańskie, Rosja, Ukraina, Chiny, Bułgaria czy Rumunia.

Co jeszcze można sprawdzać? W przypadku portali typu e-commerce, gdzie klient może nie mieć prawie żadnej historii, można sprawdzać jego adres e-mail. Adresy z puli Hotmail.com, Yahoo.com czy Gmail.com mogą wzbudzać większe podejrzenia, niż te łatwo identyfikujące klienta. Możemy także przyglądać się adresowi dostawy towaru - skrytka pocztowa jest bardziej podejrzana niż adres zamieszkania.

Nauki ciąg dalszy

Zanim jednak system będzie mógł rozwinąć skrzydła, dobrze jest nakarmić go danymi. Musi nauczyć się jakiego rodzaju działania są prawidłowe, a jakie nie mieszczą się w akceptowalnym szablonie. Musimy też mu trochę pomóc, szacując ryzyko i przypisując określonym parametrom wagę. Dla każdego wycena transakcji będzie wyglądać inaczej. Na przykład dla polskiego banku z pewnością będą brane pod lupę te operacje, które inicjowane są spoza granic naszego kraju. Profilowanie zachowań przydaje się nie tylko w przypadkach, kiedy mamy do czynienia z użytkownikami dobrze znanymi - takimi jak klienci banku. Nadaje się również do weryfikacji transakcji, które dokonywane są po raz pierwszy, np. przez przypadkowych klientów sklepów internetowych. Jeżeli ktoś kupuje komputer w Polsce, płacąc przy tym kartą wystawioną przykładowo w Paragwaju, to istnieje prawdopodobieństwo, że transakcja taka może być oszustwem i warto ją wstrzymać do momentu wyjaśnienia wątpliwości. Profilowanie na pierwszy rzut oka wydaje się zatem idealnym wręcz rozwiązaniem. Ma ono jednak także ograniczenia. Co, jeżeli nasz Jan Kowalski jest prawdziwym obieżyświatem i swoje przelewy robi z przeróżnych miejsc na świecie, o dziwnych porach, za każdym razem korzystając z innego komputera? Samo profilowanie, zwłaszcza zdefiniowane pobieżnie, może nie ochronić dostatecznie przed atakami typu MITM (Man In The Middle) albo coraz bardziej popularnymi MITB (Man In The Browser).