Scroll to top
en pl

Dlaczego banki ignorują bezpieczeństwo aplikacji – część 1


Radoslaw Kosiec - 1 sierpnia 2019 - 0 comments


Kwestia cyberbezpieczeństwa w ostatnich czasach staje się głównym problemem banków i jest to zjawisko w pełni zrozumiałe.
Uważa się, że same ataki z wykorzystaniem wirusów typu ransomware spowodowały szkody przekraczające 5 miliardów dolarów, a jest to tylko jeden z wielu rodzajów szkodliwego oprogramowania. Na szczęście wiele luk w cyberzabezpieczeniach, z którymi borykają się banki, może być łatwo uszczelnionych, jeśli tylko osoba odpowiedzialna za bezpieczeństwo wie jak to zrobić.

Banki muszą zmagać się z bezpieczeństwem operacyjnym własnych rozwiązań wewnętrznych. Muszą także wspierać rosnącą liczbę rozwiązań dla klientów, począwszy od bankomatów i czytników kart, a skończywszy na aplikacjach bankowości mobilnej i stronach internetowych. Większość banków tworzy również aplikacje do użytku wewnętrznego, a także aplikacje dla dostawców, partnerów oraz ich klientów.

Nie będzie błędem stwierdzenie, że nowoczesna bankowość jest całkowicie uzależniona od technologii informatycznych – bez nich nie jest w stanie funkcjonować, musi też używać aplikacji do interakcji z klientami. Właśnie dlatego problemy cyberbezpieczeństwa nie mogą zostać zignorowane.

Rozwiązanie problemów związanych z cyberbezpieczeństwem nie jest łatwe. Obecnie nie da się już określić dokładnie liczby cyberataków, a ich różnorodność wzrasta z każdym dniem.

Organizacje, które nie mają jasno określonych procedur bezpieczeństwa mogą odczuwać w tym aspekcie coraz większą presję zarówno ze strony klientów, jak i organów prawa.

Niestety, efektem końcowym są często niedopatrzenia w uszczelnieniu obszarów kluczowych dla bezpieczeństwa, co daje spore pole manewru dla potencjalnych ataków.

Cyberbezpieczeństwo – rozwiązanie problemów

Aplikacje vs operacje

Większość użytkowników, mówiąc o pojęciu cyberbezpieczeństwa, ma na myśli wyłącznie te problemy, które napotkać można podczas wykonywania standardowych operacji. Dostęp i uwierzytelnianie, zabezpieczenia endpointów i rozwiązań bezprzewodowych, szyfrowanie i monitorowanie to jedne z najnowszych trendów w zakresie bezpieczeństwa IT.

Tradycyjne technologie cyfrowych zabezpieczeń pochłaniają znaczną część wydatków i są postrzegane przez większość organizacji jako wysoce skuteczne. Chociaż bezpieczeństwo i funkcjonalność aplikacji są najbardziej pożądanymi cechami, organizacje oceniają swoje wysiłki w tym zakresie jako najmniej efektywne.

Mimo istniejącej korelacji między wydanymi pieniędzmi a zgłoszoną skutecznością, nie jest to równoznaczne z istnieniem związku przyczynowo-skutkowego. Obawy związane z bezpieczeństwem tradycyjnych operacji informatycznych mają zdecydowanie większe znaczenie. Dzieje się tak po części dlatego, że od kilkudziesięciu lat bezpieczeństwo IT skoncentrowane na operacjach jest stosunkowo lukratywnym rynkiem, a firmy inwestują miliardy dolarów w marketing i wzrost świadomości użytkowników i developerów.

Bezpieczeństwo aplikacji to jeszcze inna historia. Przez dziesięciolecia, bezpieczeństwo aplikacji w dużej mierze opierało się na edukowaniu programistów w zakresie sposobów bezpiecznego tworzenia aplikacji. Wysiłki na poziomie organizacyjnym koncentrowały się głównie na „kulturze” lub polegały na wdrażaniu różnych metodologii. Rozwiązaniem jest tworzenie aplikacji „bezpiecznie zaprojektowanych”. Innym dobrym pomysłem jest zmiana priorytetów tak, aby wychwytywać problemy już na wczesnym etapie developmentu w nadziei na zmniejszenie ryzyka i wdrażanie operacji, które nie spowodują opóźnień w planowanych terminach.

Niestety wysiłki te nie były tak skuteczne, jak można się było spodziewać – w dużej mierze z powodu braku wykształconych specjalistów na rynku i braku poważniejszych konsekwencji dla przestępców. Organizacje opracowały wytyczne w obszarze bezpieczeństwa aplikacji, które pomogą branży IT obrać właściwy kierunek.

Na szczęście rozwiązania takie jak Static Application Security Testing (SAST) i Dynamic Application Security Testing (DAST) są coraz częściej włączane do procesu tworzenia oprogramowania w celu skanowania i analizy kodu. Metody te wykorzystują zestawy predefiniowanych reguł w swoich algorytmach, aby wyszukiwać potencjalne błędy w kodzie. Mimo że wciąż nie jest to idealne rozwiązanie, zdecydowanie pomogło programistom w tworzeniu znacznie bardziej bezpiecznego kodu.

W dzisiejszych czasach korzystanie z komponentów open source to kolejna kwestia, z którą muszą się zmierzyć programiści i zespoły bezpieczeństwa. Według niektórych danych aplikacje używają średnio 24 komponentów z powszechnie ujawnionymi lukami w zabezpieczeniach, co może zostać wykorzystane przez twórców złośliwego oprogramowania.

Komponenty open source, na których oparto budowę aplikacji w wielu firmach, również stają przed koniecznością upublicznienia luk w swoich zabezpieczeniach, aby programiści wiedzieli, jak poprawić bezpieczeństwo ich produktów. Problem polega na tym, że takie informacje docierają zarówno do programistów, jak i do hakerów, którzy mogą wykorzystać te informacje do złych celów.

Nie jest to wcale nowy problem. O ryzyku, jakie niesie korzystanie z komponentów podmiotów trzecich i ich potencjalnych zagrożeniach, organizacje zostały zaalarmowane już wiele lat temu. Niestety bezpieczeństwo aplikacji nadal pozostaje zaniedbanym aspektem procedur bezpieczeństwa w dziedzinie bankowości.

Pułapki w zabezpieczeniach aplikacji

W przypadku banków rozwiązywanie problemów związanych z bezpieczeństwem aplikacji może być kluczową kwestią.

Aby zrozumieć dlaczego, należy przyjrzeć się częstym problemom, z którymi borykają się banki, gdy starają się zapewnić bezpieczne rozwiązania swoim klientom.

#1 Bezpieczeństwo poprzez projektowanie

Ogólne rozporządzenie Unii Europejskiej dotyczące ochrony danych (RODO) zaczęło obowiązywać w dniu 25 maja 2018 r. Jest to sztandar nowej generacji przepisów dotyczących ochrony danych, które zawierają kluczowe – choć często niejasne – koncepcje, takie jak bezpieczeństwo z założenia i domyślnie.

Jednym z praktycznych rezultatów wejścia w życie tej ustawy jest to, że twórcy aplikacji nie mają innej możliwości niż wdrożenie lepszych praktyk bezpieczeństwa w swoim procesie wytwarzania oprogramowania. Nawet po odłożeniu na bok wszystkie inne aspekty, zaprojektowanie bezpiecznej aplikacji wymaga użycia szyfrowania, a złotą zasadą kryptografii mówi o tym, że nigdy nie należy tworzyć własnego szyfru.

Szyfrowanie stanowi podstawę nowoczesnego bezpieczeństwa oprogramowania. Szyfrowanie TLC służy do zabezpieczenia komunikacji między aplikacjami (lub przeglądarkami internetowymi) i serwerami. Sieci VPN zapewniają bardziej kompletne, bezpieczne tunele, które umożliwiają aplikacjom lub urządzeniom bezpieczne łączenie się z siecią. W wielu jurysdykcjach szyfrowanie danych wrażliwych jest regulowane nakazem prawnym. To sprawia, że twórcy aplikacji nie mogą uniknąć szyfrowania w swoich aplikacjach.

Pole szyfrowania jest podzielone na dwie rozległe grupy: tworzące nowe szyfry i implementujące szyfry już istniejące. Wielu developerów wdraża szyfrowanie w takiej czy innej formie. Włączają je do aplikacji (lub komponentu aplikacji) lub używają gotowych rozwiązań z punktu widzenia operacji IT.

Jeśli chodzi o inną grupę specjalistów w dziedzinie szyfrowania, to na świecie jest bardzo niewielu kryptografów posiadających wystarczające umiejętności i odpowiednie doświadczenie, które pozwala im tworzyć nowe, realne i skuteczne algorytmy kryptograficzne. To bardzo niewielka grupa wyjątkowo cennych pracowników – ich pracodawcy z pewnością nie pozwoliliby im podróżować wspólnie jednym środkiem transportu. Osoby te są tak bardzo istotne, że przedsiębiorstwa (a nawet rządy) poważnie rozważają czynnik zgromadzenia zbyt wielu kluczowych osób w jednym miejscu, zanim zezwolą na wspólną podróż.

W wyniku niedoboru profesjonalnych kryptografów banki raczej nie będą miały dostępu do odpowiednich osób, dzięki którym będą w stanie wdrożyć nawet w minimalnym stopniu legalne i zgodne z wymogami szyfrowanie w swoich aplikacjach bez udziału komponentów aplikacji innych firm. Kryptografowie z całego świata współpracują ze sobą, aby projektować nie tylko algorytmy, z których wszyscy korzystamy, ale także komponenty aplikacji powszechnie służące do udostępniania funkcji szyfrowania.

Regulacja prawna zasady „bezpieczeństwa poprzez projektowanie” jest zatem – przynajmniej w praktyce – zagwarantowaniem prawa do korzystania z komponentów aplikacji podmiotów trzecich.

#2 Podatność na zagrożenia – to nieuniknione

Każdy kod zawiera błędy. Błędy w oprogramowaniu są przyczyną występowania luk w zabezpieczeniach. Stosowanie komponentów podmiotów trzecich, które zapewniają funkcjonalność szyfrowania nie są wystarczającą ochroną.

Powszechne komponenty szyfrujące przez lata ujawniły wiele słynnych luk w bezpieczeństwie. Przypadki takie jak Heartbleed, Shellshock, Krack i Log Jam trafiły na pierwsze strony gazet na całym świecie. Niektóre z nich można łatwo patchować, a niektóre z nich są bardziej fundamentalne, co wymaga rezygnacji ze starszych rozwiązań kryptograficznych na rzecz wdrożenia bardziej nowoczesnych technologii.

Nawet OWASP wspomina o tym problemie w słynnej „Top Ten List” – liście zagrożeń bezpieczeństwa aplikacji, która pokazuje najczęściej występujące błędy i może być łatwo wykorzystana przez hakerów.

W 2013 r. OWASP dodał jeszcze „A9: Używanie komponentów ze znanymi podatnościami na zagrożenia” i ostrzegł organizacje, że ryzyko wykorzystania komponentów innych firm o znanej luce staje się coraz powszechniejsze i czasami niemal krytyczne, ponieważ wykorzystanie komponentów open source rośnie wykładniczo z roku na rok, a w rezultacie publikowanych jest coraz więcej informacji o lukach w zabezpieczeniach.

Radzenie sobie z lukami w powszechnych rozwiązaniach szyfrujących wymaga łatania, zmiany używanych algorytmów domyślnych, a co jakiś czas oznacza to całkowitą zmianę sposobu szyfrowania. Niestety większość organizacji obecnie ignoruje fakt, że używa wrażliwych komponentów, podczas gdy hakerzy mogą z łatwością to wykorzystać (patrz – przypadek Equifax).

Wyzwania bezpieczeństwa bankowości mobilnej

To nie wszystkie pułapki, na jakie mogą natknąć się programiści i projektanci aplikacji bankowości mobilnej. Poza błędnym kodem i komponentami open source o nieznanych podatnościach na zagrożenia, twórcy aplikacji muszą także wziąć pod uwagę wbudowane zabezpieczenia urządzenia oraz różne rodzaje patchów i łatek do oprogramowania. W kolejnym artykule dowiecie się na co zwrócić uwagę, aby jeszcze bardziej podnieść poziom bezpieczeństwa aplikacji obsługujących bankowość mobilną.

Czy masz pytania dotyczące bezpieczeństwa bankowości mobilnej lub chcesz porozmawiać o możliwościach jakie oferuje oprogramowanie WhiteSource? Skontaktuj się z nami – nasi konsultanci chętnie odpowiedzą na wszystkie pytania!

Related posts