Scroll to top
en pl

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


Radoslaw Kosiec - 30 sierpnia 2019 - 0 comments

W poprzedniej części tego artykuły pisaliśmy o wyzwaniach i pułapkach, z jakimi muszą się zmierzyć projektanci i programiści tworzący aplikacje do obsługi bankowości mobilnej. Cyberbezpieczeństwo powinno być priorytetem na każdym etapie realizacji aplikacji – od projektu, poprzez wdrażanie komponentów open source, uwzględnianie patchów do oprogramowania oraz zabezpieczenia wbudowane w urządzenie.

Pułapki w zabezpieczeniach aplikacji c.d.

#3 Różne rodzaje patchów

Kiedy większość ludzi mówi o łataniu, mają oni na myśli system operacyjny swojego urządzenia. Każdy użytkownik komputera spotkał się z Windows Update, aktualizację MacOS lub mechanizmy aktualizacji na swoich smartfonach. Te wszechobecne systemy łatania są dobrze znane, ale nie są to jedyne miejsca, w których może ono nastąpić.

Komponenty innych firm są często dołączane bezpośrednio do skompilowanych aplikacji. Oznacza to, że te komponenty muszą zostać poprawione przed rozpoczęciem procesu budowania aplikacji, aby skompilowane aplikacje zawierały ich najnowsze wersje.

Niestety, nie ma łatwego sposobu na określenie, które komponenty są załatane przez system operacyjny i które muszą zostać poprawione podczas procesu budowania aplikacji.

Zastanówmy się przez chwilę nad błędem Heartbleed. Heartbleed był wadą wielu wersji biblioteki kryptograficznej OpenSSL, wspólnego komponentu open source.

Biblioteka OpenSSL jest często pobierana, instalowana i zarządzana pakietowo w systemach operacyjnych Linux.

Wiele aplikacji Linux jest zaprojektowanych do wywoływania i używania kopii bibliotek OpenSSL zarządzanych przez managera pakietów systemu operacyjnego. W tym przypadku regularne, zautomatyzowane aktualizacje systemu operacyjnego aktualizowałyby także OpenSSL, a każda aplikacja korzystająca z niego, używałaby nowej wersji podczas ponownego uruchamiania aplikacji bez konieczności ponownej kompilacji lub ponownego wdrażania aplikacji.

OpenSSL jest jednak również wbudowywana bezpośrednio w niezliczone aplikacje, zwłaszcza gdy aplikacje te są przeznaczone do użytku w systemie Windows. Manager pakietów systemu Windows nie instaluje ani nie zarządza żadną wersją bibliotek OpenSSL. W takim przypadku aplikacje muszą być przekompilowane (lub przynajmniej przepakowane) za każdym razem, gdy wychodzi nowa wersja biblioteki OpenSSL.

Ta sama dyskusja mogłaby zostać podniesiona w przypadku wielu innych kategorii powszechnie stosowanych komponentów. Istnieje wiele struktur i bibliotek, które stały się tak powszechne, że wielu współczesnych programistów nie jest w stanie napisać bez nich aplikacji.

#4 Bezpieczeństwo urządzenia – niewystarczające rozwiązanie

Problem aplikacji, które wykorzystują komponenty open source o znanych lukach, plasuje się wśród naważniejszych wydatków związanych z bezpieczeństwem. Mimo to, nie da się go rozwiązać jedynie przez ulepszenie zabezpieczeń w urządzeniach. Żadne oprogramowanie antywirusowe, narzędzie do profilowania zachowań aplikacji, pakiet zabezpieczeń punktów końcowych ani narzędzie do zarządzania urządzeniami mobilnymi nie mogą sprawić, że aplikacja o znanej luce w zabezpieczeniach nie będzie podatna na ataki.

Budowanie własnych aplikacji w celu korzystania z zaawansowanych funkcji zabezpieczeń urządzenia również nie rozwiąże tego problemu. Biometria, NFC i uwierzytelnianie wieloskładnikowe to tylko słowa-klucze, jeśli sama aplikacja, którą mają zabezpieczyć, jest podatna na ataki. Ponadto włączenie każdej z tych funkcji bezpieczeństwa do aplikacji może wymagać wielu dodatkowych komponentów innych firm, z których każdy będzie musiał być na bieżąco aktualizowany.

Z punktu widzenia banku powinno to być niepokojące. Oznacza to, że ciężar bezpieczeństwa nie może zostać z powrotem przeniesiony na klienta lub któregoś z dostawców istniejących w łańcuchu dostaw między klientem a bankiem.

Jeśli bank wdroży aplikację, która zawiera komponenty open source ze znanymi lukami w zabezpieczeniach – lub jeśli bank nie zaktualizuje i nie wdroży nowej wersji swoich aplikacji, od razu po wykryciu luk w komponentach, których używa – to bank ponosi za to odpowiedzialność. Przerzucenie odpowiedzialności za bezpieczeństwo na klienta lub na producenta urządzenia lub dostawcy systemu operacyjnego nie jest możliwe.

Jeżeli potencjalna luka w bezpieczeństwie występuje jako część kodu umieszczonego w aplikacji, to obowiązkiem firmy jest bieżące aktualizowanie aplikacji i dodawanie do niej odpowiednich łatek i zabezpieczeń.

Nowe wyzwania otwartej bankowości

Wprowadzenie otwartej bankowości staje się koniecznością, ale niesie ze sobą także nowe wyzwania, jeśli chodzi o bezpieczeństwo danych osobowych użytkowników. W zależności od tego, jak analizuje się ryzyko związane z tworzeniem aplikacji, otwarta bankowość może wydawać się idealnym rozwiązaniem kwestii zarządzania ryzykiem lub potencjalną katastrofą.

Otwarta bankowość przenosi ciężar rozwoju aplikacji na zewnętrzne podmioty. W otwartej bankowości aplikację tworzy podmiot komercyjny, całkowicie niepowiązany z bankiem.

Aplikacja komunikuje się z API opublikowanymi przez bank. Otwarte aplikacje bankowe mogą zazwyczaj współpracować z wieloma bankami, umożliwiając użytkownikowi końcowemu korzystanie z aplikacji niezależnie od wybranego przez nich banku.

Ponieważ aplikacja jest projektowana, publikowana i utrzymywana przez programistę będącego trzecim podmiotem, który nie jest powiązany kontraktem z bankiem, to odpowiedzialność za aktualizację tej aplikacji spoczywa na jej developerze, a nie na banku. Chociaż może to być pożądane, z punktu widzenia odpowiedzialności oznacza to również, że bank ma niewielką kontrolę nad tym czy ich klienci korzystają z aplikacji o znanych lukach, co wymaga od banków podwojenia wysiłków w zakresie zwalczania oszustw.

Zaufanie między bankiem, a developerem aplikacji otwartej bankowości to klucz do udanej współpracy. Musi ono istnieć także między bankiem i klientem, ale także między klientem i developerem. Zaufanie w świecie otwartej bankowości często komplikuje się przez zmiany w relacji z klientem. Banki spółdzielcze przyzwyczajone są do tego, że proces tworzenia relacji z klientami może trwać przez całe dekady. Jednak dzięki otwartej bankowości developer otwartej aplikacji bankowej posiada wiele codziennych doświadczeń bankowych klienta.

Jednak otwarta bankowość dostarcza developerowi aplikacji otwartej bankowości wgląd w wiele codziennych doświadczeń bankowych klienta. W miarę wzmożonego użytkowania aplikacji bankowych, rynek staje się coraz bardziej konkurencyjny. Wielu twórców aplikacji bankowych dokłada wszelkich starań, aby zdobyć zaufanie, pielęgnować relacje z bankami, z którymi współpracują ich aplikacje i realizować certyfikaty bezpieczeństwa oraz formalne przeglądy kodu swoich aplikacji. Banki, które wykorzystują otwartą bankowość, mogą podnieść poziom bezpieczeństwa dzięki wykorzystaniu inicjatyw bezpieczeństwa aplikacji partnerskich. Mogą również zwiększyć swoje bezpieczeństwo, wdrażając kontrole, które dowodzą, że twórcy aplikacji otwartej bankowości wykorzystują wszystkie narzędzia niezbędne do zapewnienia bezpieczeństwa wdrożonych aplikacji poprzez ich terminową i bieżącą aktualizację.

Jak narzędzia bezpieczeństwa aplikacji mogły zapobiec naruszeniu Equifax

Kiedy banki i programiści pracują z komponentami ze źródeł zewnętrznych, muszą wierzyć, że używają kodu, który pomoże im stworzyć lepszy produkt, ale muszą też sami sprawdzić, czy komponenty te faktycznie są bezpieczne.

Sprawdzenie czy komponent open source nie zawiera żadnych znanych luk wymaga użycia odpowiedniego narzędzia do tego zadania. Jeśli SAST i DAST mogą pomóc w radzeniu sobie z prawnie zastrzeżonym kodem, uzasadniałoby to istnienie konkretnego narzędzia, które działa z komponentami open source w celu wzmocnienia zabezpieczeń aplikacji.

Podczas gdy SAST i DAST mogą pomagać w przeglądaniu poszczególnych linijek kodu, narzędzia analizy składu oprogramowania (SCA) są znacznie prostsze w obsłudze, ponieważ komponenty open source można łatwo zidentyfikować poprzez ich skróty, znane również jako SHA 1s.  Te skróty są umieszczane w bazach danych luk w zabezpieczeniach i mogą być dostosowane do komponentu w magazynie lub repozytorium.

Problemem jest to, że programiści nie zawsze są świadomi, które z komponentów dodanych przez nich do kodu mogą przechwytywać i zatwierdzać kod źródłowy. Oznacza to, że jeśli zostanie zgłoszona nowa luka w bezpieczeństwie, zespół programistów może nie wiedzieć, że ich produkt zawiera podatny fragment kodu, który ktoś może przechwycić i wykorzystać do innych celów. Brak tej wiedzy sprawi, że odpowiednie zabezpieczenia nie zostaną dodane odpowiednio szybko albo nawet zostaną całkowicie pominięte.

W zeszłym roku byliśmy świadkami takiej sytuacji, gdy w marcu ogłoszono znalezienie luki w projekcie Apache Struts2, który jest bardzo popularnym źródłem open-source, często wykorzystywanym w tworzeniu aplikacji webowych.

Poprzez ten komponent hakerzy byli w stanie włamać się do jednej z największej trójki agencji ratingowych (Equifax) i wejść w posiadanie danych osobowych należących do ponad 145 milionów osób.

Największe włamanie w historii programowania nie zostało dokonane dzięki zaawansowanej inżynierii, nie było też efektem długich miesięcy spędzonych na grzebaniu w kodzie. Hackerzy wykorzystali dobrze nagłośniony exploit w popularnym projekcie, uderzając w organizację niecałe dwa miesiące po ogłoszeniu podatności i łatki.  

Z materiałów i oświadczeń udostępnionych przez Equifax wynika, że korzystali oni z różnych rozwiązań testowych, ale najwyraźniej nie posiadali narzędzia SCA, które mogłoby zasygnalizować miejsca zwiększonego ryzyka w kodzie, powiadamiając o nich natychmiast po zgłoszeniu luki. Ta bolesna lekcja uczy, że nie da się naprawić błędu, o którego istnieniu się nie wie.

Pomimo powszechnego charakteru tego problemu, inicjatywy bezpieczeństwa aplikacji pozostają na niskim poziomie na większości rynków. Banki nie mogą sobie pozwolić na bycie częścią tych niepokojących statystyk, zwłaszcza w obliczu istnienia prostego rozwiązania tego problemu.

Narzędzia SCA, takie jak skanery podatności komponentów aplikacji, muszą być częścią podstawowych zabezpieczeń dla każdego banku. Ich użycie przez wewnętrzne zespoły programistów, programistów kontraktowych, zewnętrznych pracowników i dostawców aplikacji bankowych powinno być koniecznością i wymogiem.  

Wykrywanie luk w zabezpieczeniach

W bankowości i w każdym innym sektorze nowoczesne cyberbezpieczeństwo musi uwzględniać bezpieczeństwo aplikacji. Nie można pominąć tego aspektu podczas projektowania aplikacji. To nie tylko kwestia dobrych praktyk – coraz częściej jest to także wymóg prawny.

Czy chcesz dowiedzieć się więcej o oprogramowaniu WhiteSource, które pomoże zabezpieczyć Twój projekt w obszarze komponentów open source? Napisz do nas – chętnie odpowiemy na wszystkie pytania.

Related posts