Jak obecnie wygląda tworzenie kodu? Jak pogodzić wymagania funkcjonalne z bezpieczeństwem użytkownika? Oh my god…OWASP. Czy leci z nami Security software developer? Czy ta funkcja ma jeszcze dzisiaj sens? Standardy testów oprogramowania. To tematy, naszego VIII odcinka Ingram Micro Podcast, w którym mamy przyjemność gościć Andrzeja Dyjaka, założyciela bezpiecznykod.pl, doświadczonego software security architekta, inżyniera oprogramowania, trenera i odkrywcę wielu krytycznych podatności w popularnym oprogramowaniu gigantów. Zapraszamy do słuchania!
Transkrypcja podcastu
Prowadzący: Cześć. Witam wszystkich słuchaczy w kolejnym odcinku naszego podcastu. Dzisiaj naszym tematem przewodnim jest konflikt. Nie chodzi o zwykły konflikt, a o swojego rodzaju batalię domową pomiędzy dobrymi, a dobrymi. Pomiędzy bezpiecznikami, a twórcami oprogramowania. Czy konflikt ten występuje rzeczywiście, czy ma sens i o tym, jak w czasach dzisiejszych tworzone są oprogramowania, porozmawiamy z moim gościem. Wojna domowa – programiści kontra bezpiecznicy. Miło mi przedstawić Państwu mojego dzisiejszego gościa, Andrzej Dyjak, założyciel bezpiecznykod.pl, doświadczony software security, architekt, inżynier oprogramowania, trener, odkrywca wielu krytycznych podatności w popularnym oprogramowaniu gigantów. Andrzej, miło mi Cię dzisiaj gościć.
Andrzej Dyjak: Cześć. Dzień dobry wszystkim. Miło mi tu być. To już kolejny podcast, w którym mam przyjemność uczestniczyć. I jak zawsze, jest mi bardzo miło, że ludzie mnie zapraszają. Szczególnie, jeżeli mogę się wypowiedzieć na tematy, które mi są dość bliskie, czyli konkretnie bezpieczeństwo, a może jeszcze konkretniej bezpieczeństwo aplikacji.
Sponsorem cyklu rozmów „Rady Porady” jest firma Cisco
TRANSKRYPCJA
Holy Wars odwieczna walka aplikacje vs bezpieczeństwo
[00:00:06]Prowadzący: Cześć. Witam wszystkich słuchaczy w kolejnym odcinku naszego podcastu. Dzisiaj naszym tematem przewodnim jest konflikt. Nie chodzi o zwykły konflikt, a o swojego rodzaju batalię domową pomiędzy dobrymi, a dobrymi. Pomiędzy bezpiecznikami, a twórcami oprogramowania. Czy konflikt ten występuje rzeczywiście, czy ma sens i o tym, jak w czasach dzisiejszych tworzone są oprogramowania, porozmawiamy z moim gościem. Wojna domowa – programiści kontra bezpiecznicy. Miło mi przedstawić Państwu mojego dzisiejszego gościa, Andrzej Dyjak, założyciel bezpiecznykod.pl, doświadczony software security, architekt, inżynier oprogramowania, trener, odkrywca wielu krytycznych podatności w popularnym oprogramowaniu gigantów. Andrzej, miło mi Cię dzisiaj gościć.
Andrzej Dyjak: Cześć. Dzień dobry wszystkim. Miło mi tu być. To już kolejny podcast, w którym mam przyjemność uczestniczyć. I jak zawsze, jest mi bardzo miło, że ludzie mnie zapraszają. Szczególnie, jeżeli mogę się wypowiedzieć na tematy, które mi są dość bliskie, czyli konkretnie bezpieczeństwo, a może jeszcze konkretniej bezpieczeństwo aplikacji.
Prowadzący: Andrzej, właśnie tematy, które są Ci bliskie. Bardzo się cieszę, że jesteś z nami, biorąc pod uwagę właśnie Twoje dotychczasowe zajęcia, czy zainteresowania. Jesteś właśnie osobą, która łączy w sobie te dwie strony, dwie strony batalii, o której dzisiaj mówimy. Z jednej strony twórcy kodu, z drugiej strony security architekta, osobę, której zadanie to w głównej mierze edukacja sztabów ludzi odpowiedzialnych za produkcję oprogramowania w kontekście bezpieczeństwa. Więc, tym bardziej się cieszę. Andrzej, to bardziej utożsamiasz się z programistą, czy z bezpiecznikiem? Musiałem to zadać, przepraszam.
Andrzej Dyjak: Jasne. Dobre pytanie. Wolałbym go uniknąć tutaj, obstawiania konkretnie jednej strony. Natomiast, jeżeli musiałbym wybrać, jeżeli byłbym tak przyciśnięty do ściany i musiałbym wybrać, to bardziej utożsamiałbym się jednak z osobą, która tworzy, czyli bardziej z programistą niż z bezpiecznikiem, niż z psują. Chociaż ja nie do końca widzę, że to musi stać w takiej kontrze. To znaczy można dość jasno zobaczyć, że oczywiście w bezpieczeństwie również potrzebujemy ludzi, którzy budują bezpieczeństwo, czy poprawiają czy budują same mechanizmy. Więc jedno z drugim się nie wyklucza. Natomiast, jeżeli za bezpieczeństwo w takim typowym wydaniu, mówimy o jakichś pentestach, o jakiejś ofensywie, to faktycznie bliżej mi do tej strony, która buduje niż do tej strony, która atakuje, pomimo tego, że moje korzenie wyrastają w zasadzie właśnie od strony atakującego. Po prostu w pewnym momencie zobaczyłem, że ofensywa jest fajna, ale końcem końców do niczego nie prowadzi. Chyba, że faktycznie działamy albo dla Rządu, albo dla złych organizacji, no to wtedy faktycznie do czegoś prowadzi, do jakiegoś zysku. Ale jeżeli nie robimy tego w takim wydaniu, to ta strona obronna, ten defens dla mnie jest ciekawszy i bardziej się z nim identyfikuje.
Prowadzący: Słuchaj, tak na początek. Jak wygląda współczesny proces wytwórczy, począwszy od koncepcji przez programowanie, po testowanie. Z iloma pracownikami i na jakich stanowiskach produkt ma z reguły styczność, zanim trafi do klienta końcowego? I tutaj wiem, że to jest sprawa mocno uzależniona, czy od wielkości linii, czy od rodzaju projektu. Ale zależy mi tutaj na takim wiesz, ogólnym przedstawieniu całego ciągu, od otrzymania zlecenia do finalnego produktu, do testów.
Andrzej Dyjak: Tak jak powiedziałeś. Nie będziemy tu tego rozbierać na takie faktyczne czynniki pierwsze. No, ale każdy taki projekt ma jakąś fazę designu, więc tam tak naprawdę jest kilka ról, w zależności od wielkości projektu. Albo inaczej, ról jest zawsze tyle samo tylko często może to być po prostu jedna osoba, która pełni wiele ról. Więc no musi być jakiś architekt, ktoś, kto po prostu wymyśla dany produkt, dane rozwiązanie czy dany feature. Muszą być już na tym etapie jacyś programiści, którzy są wciągnięci przynajmniej na samym podstawowym poziomie, typu mówienia – ok, to możemy zrobić albo tego nie możemy zrobić. Czyli jeszcze nie implementacja, ale dalej myślenie o tym, jak coś zrobić. No oczywiście jest jakaś osoba biznesowa, to może być product owner, to może być jakaś inna rola, ale ktoś, kto mówi – no po co w ogóle mielibyśmy coś zrobić, do czego to prowadzi w kontekście biznesu?
[00:05:05]Andrzej Dyjak: Bo to jest też ważne, że aplikacje, całe IT nie jest osobną bańką. IT jest po to, żeby pomagać biznesowi w osiąganiu jakichś konkretnych celów. Więc ta osoba biznesowa, jakaś rola biznesowa też jest ważna na samym początku designu, myślenia o oprogramowaniu. Potem przechodzimy do fazy implementacji, czyli zaczynamy po prostu z grubsza wcielać ten pomysł, wcielać ten design w życie. Następnie dochodzimy do fazy takiej pośredniej, typu testów buildów, robienia takiego sprawdzenia tego, czy to, co zrobiliśmy, to, co zaimplementowaliśmy koniec końców działa tak, jakbyśmy chcieli. No i na samym końcu gdzieś to trafia tam na produkcję i spełnia jakąś faktyczną funkcję biznesową. Czyli powiedzmy, takie 4 fazy. Oczywiście te 4 fazy dalej mogą się rozwijać na podfazy, mogą być dodatkowe role, ale z grubsza można wyodrębnić 4 fazy. I ról, tak jak widzimy jest trochę, całkiem sporo, jest całkiem sporo. Oczywiście tutaj jeszcze nie wspomniałem o testerach. No, bo testerzy też są w pewnej fazie. Najczęściej, jeszcze niestety nie są w fazie designu, nie są w fazie implementacji, są dopiero w fazie testów, w fazie sprawdzenia, czy to, co zrobiliśmy odpowiada temu, co chcieliśmy zrobić. Lub jeszcze dalej, to już w ogóle zły przypadek, kiedy testerzy są tylko po fazie już tak naprawdę deploya, czyli w fazie gdzie już coś żyje na produkcji. Bo oczywiście od tego tak naprawdę kiedyś się zaczynało. Zaczynało albo nawet kończyło, czyli zaczynało się od końca.
Prowadzący: A wiesz co, teraz chciałbym się odnieść bezpośrednio do tematu naszego dzisiejszego podcastu. Skąd ta zimna wojna? Dlaczego specjaliści od bezpieczeństwa tak często zgłaszają swoje obawy przed szybko tworzonym kodem? Nie wiem, czy jest to związane względem rozjazdu względem celów tak, czy wynika to z innego postrzegania świata rzeczywistości? Chodzi mi tutaj o takie klasyczne spojrzenie bezpiecznik vs spojrzenie programisty zaangażowanego w proces twórczy oprogramowania. Czy rzeczywiście w ogóle możemy mówić o swojego rodzaju konflikcie interesów pomiędzy tymi dwoma stronami?
Andrzej Dyjak: Wydaje mi się, żemożna popatrzeć na to jak pewnego rodzaju konflikt interesów i jest to konflikt interesów, natomiast to jest tak, jak powiedziałeś na samym początku tego podcastu, jedna i druga strona jest tą dobrą. Czyli to nie jest tak, że bezpiecznicy są źli, więc stoją w konflikcie. Raczej te cele nie są zawsze zbieżne. I my chcielibyśmy, żeby te cele były zbieżne. Niestety, często nie są. I teraz pytanie, czemu nie są? No, bo końcem końców programista jest rozliczany za dowożenie featurów i ja to też zrozumiałem będąc programistą, bo ja zacząłem, jako bezpiecznik, potem pracowałem, jako software engineer, a potem znowu przeszedłem do bezpieczeństwa. Natomiast, pracując właśnie, jako software engineer, pisząc oprogramowanie zobaczyłem, że ja rozliczany jestem za featury, a niekoniecznie za jakość i na pewno nie za bezpieczeństwo tych featurów. Oczywiście jest to pewnego rodzaju założenie, że te featury, które dostarczam powinny mieć jakąś jakość i być w jakiś sposób bezpieczne, ale głównie chodzi o to, że one powinny realizować cele biznesowe. I za to jesteśmy rozliczani. Natomiast, znowu bezpiecznik patrzy na to z trochę innego punktu widzenia. On jest rozliczany za zabezpieczanie tej aplikacji. I tutaj stoimy w takim pewnego rodzaju konflikcie, bo nasze cele nie są zbieżne. I oczywiście, niestety jest tak, że no nawet, jeżeli ja, jako bezpiecznik znajdę podatności, to nie ja je wyprowadzam jako bezpiecznik. Wyprowadza je programista, ale programista nie jest rozliczany za wyprowadzanie podatności, tylko za featury. I tutaj nie mamy tej zbieżności celów. To zaczyna się powoli zmieniać, ale jeszcze tam nie jesteśmy. Tutaj ważne też, żeby uwypuklić jeden fakt. Mianowicie, bezpiecznicy często nie mają doświadczenia właśnie od tej strony wytwarzania oprogramowania. Często ludzie w bezpieczeństwie lądują z ról takich jak administracja sieciami czy na przykład helpdesk, czy po prostu wskakują do bezpieczeństwa, jako bezpieczeństwo. Czyli to jest ich entry-level job i potem po prostu awansują w tym konkretnym wertykalu. No i jeżeli nie mają doświadczenia z wytwarzaniem oprogramowania, to nie do końca rozumieją właśnie ten język, te cele programistów. A to jest ważne, żeby mieć wyrównane cele i zrozumieć tę drugą stronę. I w moim odczuciu, każdy bezpiecznik mocno skorzystałby, jeżeli miałby doświadczenie programistyczne, czyli popracował po prostu, jako programista.
[00:10:00]Andrzej Dyjak: Ale no musiałby to zrobić komercyjnie, bo jednak programując samemu, a programując w zespole to zupełnie co innego, więc to jest taki trochę wishful thinking, natomiast jest to bardzo pomocne w zrozumieniu tej drugiej strony i w tym momencie zaczynamy widzieć rzeczywistość od ich strony, od programistów strony. I nasze cele zaczynają się po prostu bardziej wyrównywać, zaczynają być zbieżne, zaczynamy rozumieć, że pewne rzeczy można w łatwy sposób rozwiązać i moglibyśmy je rozwiązać. Innych nie tak łatwo rozwiązać, zaczynamy po prostu inaczej patrzeć na te problemy, dzięki czemu lepiej się rozumiemy. Programiści, z mojego doświadczenia, często patrzą na bezpieczeństwo takim krzywym okiem, ale to nie wynika z uprzedzenia, tylko to wynika po prostu z ich poprzednich doświadczeń, że bezpiecznik to była ta osoba, co przychodzi z pałką i zaczyna bić po głowach. Natomiast, jeżeli bezpiecznicy pokazują się z innej strony, to programiści nie są uprzedzeni, wręcz przeciwnie. Programiści to często są ludzie, którzy z natury chcą, żeby coś było dobrze zrobione, takie podejście craftsmanship i na bezpieczeństwie również im zależy i na jakości, i na bezpieczeństwie. Tylko te poprzednie ich doświadczenia, no niejako predykują to jak podchodzą do tego tematu w chwili obecnej. Więc tutaj mamy pole do poprawy i z jednej, i z drugiej strony.
Prowadzący: Słuchaj, wspominałeś o różnych rolach, między innymi o rolach związanych z biznesem. I tutaj właśnie o to chciałem jeszcze zapytać, bardziej pod kątem takim typowo menadżerskim. Jak pogodzić wymagania funkcjonalne z bezpieczeństwem użytkownika? Rozbudowując, żeby też od razu było wiadomo, o co mi chodzi. Jak pogodzić biznes, czyli wymagania, funkcjonalność i skończony czas tak, przewidziany na dany projekt, przekładający się oczywiście na koszty, względem finalnego produktu? Czyli standardowa sytuacja – mnóstwo zadań, skończony czas na realizację, deadliny na głowie, a wiesz, jeszcze kilka modułów do dołożenia.
Andrzej Dyjak: Tak. To szara rzeczywistość. Powinniśmy po prostu zacząć od tego, żeby nie odstawiać bezpieczeństwa na sam koniec, żeby implementować je jak najwcześniej. I jest taki ruch, co się nazywa Shift Left Security, czyli przesuwać sobie bezpieczeństwo w procesie wytwórczym na lewo, czyli im bliżej tej fazy designu, tym lepiej. I oczywiście trzeba się najpierw, na sam początek trzeba się pogodzić z tym, że nasze produkty nigdy nie będą w 100% bezpieczne, bo nic nigdy nie jest w 100% bezpieczne, nawet w zasadzie nie powinno być, bo tak jak powiedzieliśmy, koszty są skończone i nie da się wszystkim zapewnić bezpieczeństwa na 100%. Więc bezpieczeństwo zapewniamy tylko na tyle, na ile, powinniśmy to zrobić na tyle, na ile ma to sens w kontekście ryzyk, które na nas czekają, w kontekście zagrożeń, które mogą nam coś zrobić, mogą nam wyrządzić jakąś szkodę. Więc to jest ważne. I jak się z tym pogodzimy, czyli pogodzimy się z tym, że bezpieczeństwo nigdy nie będzie idealne, to możemy zacząć działać i możemy przesuwać bezpieczeństwo w lewo, czyli im bliżej procesu wytwórczego. Według mnie, ja patrzę na takie 3-4 praktyki, które mają dość duże znaczenie w poprawie bezpieczeństwa, widziałem to i gdzieś w zachodnich firmach, które po prostu pokazały swoje case study, znam to też z własnego doświadczenia. I tymi praktykami jest po pierwsze, automatyzacja, czyli używanie pewnego rodzaju narzędzi w odpowiednich punktach wytwarzania naszego oprogramowania tak, żeby odciążyć nasze zespoły, nasze tak nieładnie to ujmę, zasoby. I to jest taki pierwszy punkt, czyli automatyzacja. I tutaj można powiedzieć coś takiego, jak SAS, można użyć DAS i można użyć kilka innych skrótów. Myślę, że damy to w notatkach, będzie można sobie poczytać o konkretnych narzędziach. Natomiast automatyzacja, czyli zautomatyzowanie tego, co się da. Następnie przechodzimy do takich trochę trudniejszych procesów, związanych z ludźmi. Trudniejszych, bo po prostu trudniej zaimplementować, natomiast stopę zwrotów mają końcem końców większą. I tymi procesami to są modelowanie zagrożeń, które możemy wykonywać praktycznie na samym początku. I modele zagrożeń pomagają nam, jak sama nazwa mówi, zbudować model tego, co nam zagraża, co zagraża naszym aplikacjom. Modele zagrożeń są o tyle ciekawe, że można je robić na różnych poziomach szczegółowości, można je robić dla całego rozwiązania, można je robić dla jakiegoś kawałka rozwiązania, można je robić nawet dla konkretnego featura w oprogramowaniu. Więc modelowanie zagrożeń jako praktyka, jest czymś, co ma dość dużą stopę zwrotów pomimo tego, że nie jest takie łatwe i tanie do zaimplementowania . Dodatkowo proces secure code rewiev, czyli po prostu przeglądu kodu pod kątem bezpieczeństwa. I myślę, że każdy programista zdaje sobie sprawę, że sam code rewiev jest bardzo przydatny i bardzo wartościowy, no a jeszcze, jeżeli dołączymy do tego bezpieczeństwo, to tym lepiej.
[00:15:04]Andrzej Dyjak: Więc secure code rewiev, modelowanie zagrożeń i jeszcze jednym, takim można powiedzieć początkowym procesem to po prostu edukacja. I edukację też można rozdzielić na kilka poziomów. Możemy zacząć od takiego typowego awarenessu o bezpieczeństwie i przechodzić aż do takich już nisko levelowych, do nisko levelowej edukacji na temat danych podatności, czyli edukacji naszych zespołów deweloperskich z konkretnych podatności, z konkretnych klas podatności. Więc do edukacji też trzeba podchodzić kilkupoziomowo, a nie tylko, że – no, zrobimy jakieś tam szkolenie i każdy już będzie wiedział, że się zajmujemy bezpieczeństwem. Więc edukacja, modelowanie zagrożeń, proces code rewiev i automatyzacja. Z czego 3 z tych procesów są stricte powiązane z ludźmi i tylko jeden z tych procesów jest czymś, co możemy sobie zrobić maszynami.
Prowadzący: Andrzej, pytanie mocno przewrotne, które może Cię strącić z krzesła, także uważaj. Dlaczego bezpieczeństwo aplikacji jest obecnie tak ważne? Pytanie, tak jak wspomniałem, mocno infantylne, biorąc pod uwagę ilość aplikacji, z jakich korzystamy na co dzień, aplikacje, których to lokujemy najróżniejsze czasami oczywiście wrażliwe dane czy cały krajobraz cyberbezpieczeństwa. Jak bezpieczeństwo software ewoluowało, biorąc pod uwagę czas obecny i praktyki sprzed kilku lat?
Andrzej Dyjak: Czemu bezpieczeństwo aplikacji jest tak ważne? No właśnie, czemu? No, bo aplikacje tak naprawdę są wszędzie w naszym życiu. Czyli już w chwili obecnej w zasadzie cokolwiek robimy, to korzystamy z jakiegoś rodzaju aplikacji, czy to takie aplikacje można powiedzieć, przejrzyste dla nas, czyli po prostu nie wiem, korzystamy z czegoś na telefonie. Więc wiemy, że korzystamy z aplikacji, bo sobie klikamy i wiemy, że tam są nasze dane. Może nie do końca wiemy, jakie wszystkie dane, natomiast świadomie wiemy, że z niej korzystamy. No, ale są też takie aplikacje, z których korzystamy, ale nie do końca świadomie. Na przykład jeździmy autem, nasze auto jest pełne aplikacji. Włączamy kran, leci nam woda, systemy przepływowe, które przerzucają wodę są zarządzane aplikacjami. Włączamy światło, power grid jest zarządzany aplikacjami. To wszystko tak naprawdę jest software. Więc możemy przejść od takiej krytycznej infrastruktury, gdzie w naszym skupieniu nie są tyle dane, co jest samo to, żeby ta aplikacja działała i powinna działać tak, żeby nie było nieprzewidzianych stanów tej aplikacji. A możemy pójść dalej i popatrzeć na dane, czyli właśnie te aplikacje, z których korzystamy w naszych smartfonach, które przetwarzają nasze dane, a nasze dane, no są dla nas ważne. Ja wiem, że często ludzie nie końca zdają sobie sprawę, jak bardzo ważne są te dane. Natomiast incydenty, takie jak Cambridge Analytica, która no miała, można powiedzieć wybrała albo pomogła wybrać przyszłego Prezydenta Stanów Zjednoczonych w Stanach, no pokazują, że dane nawet takie, które po prostu wrzucamy do sieci i my nie patrzymy na nie, jako coś, co ma wartość, one mogą mieć wartość dla innych osób i mogą wpływać na naszą faktyczną rzeczywistość. I to jest ciekawe. Czyli ktoś za pomocą danych może wpływać na rzeczywistość. No i dlatego bezpieczeństwo aplikacji jest ważne. Natomiast tutaj musimy dorzucić ten dodatkowy kawałek, czyli nie tylko samo bezpieczeństwo, ale też prywatność, bo to często jest security and privacy. Więc ta prywatność, to privacy często jest widziane po prostu, jako osobna domena, która jest połączona z bezpieczeństwem, ale nie jest tym samym, nie jest równoznaczna. Więc tutaj też musielibyśmy to wyodrębnić. No, natomiast wydaje mi się, że tutaj przedstawiłem dość mocne argumenty, dlaczego bezpieczeństwo aplikacji jest w chwili obecnej ważne. I oczywiście tych przykładów można przywoływać dużo więcej, ja wziąłem pierwsze lepsze z głowy.
Prowadzący: Wiesz co, do tego właśnie zmierzałem, biorąc pod uwagę to pytanie odnośnie ewolucji tak, jak się te elementy zmieniały, bo czy hardware ma w dzisiejszym świecie jeszcze jakikolwiek sens bez oprogramowania z Twojego punktu widzenia?
Andrzej Dyjak: Wiesz co, ja od razu powiem, bez bicia, że ja się hardwarem nie zajmuję jakoś profesjonalnie. Natomiast trudno jest mi wyobrazić sobie hardware, który działa bez software, przynajmniej w chwili obecnej. Byłby, musiałby być bardzo prymitywny i oczywiście ja jestem pewien, że są takie, no chociażby włączenie przełącznika, to chyba jest jakiś kawałek hardwaru. Ale bez software, hardware jest bardzo, można powiedzieć prymitywny, więc nie daje nam dużo możliwości. Dopiero w momencie, kiedy mamy software, te możliwości zaczynają się mnożyć. Co więcej, często wychodzą nowe możliwości, których nawet nie byliśmy w stanie przewidzieć. I to jest ciekawe, że mamy tak zwane emergent properties, które nam po prostu się pojawiają z tego, w jaki sposób ludzie korzystają z software. Więc wydaje mi się, że na chwilę obecną sam hardware, bez software raczej tutaj za dużo nam nie da. Już w tej chwili sofware wartością przewyższył hardware.
[00:20:09]Prowadzący: No właśnie mówimy do mikrofonów, w pełni analogowych, no ale zaraz za tym mikrofonem i za kabelkiem mamy rejestrator już pewnie cyfrowy.
Andrzej Dyjak: Właśnie. I mamy tutaj jakąś aplikację, jakiś software, który coś robi z tym sygnałem, który przetwarza.
Prowadzący: Słuchaj, to poruszymy teraz troszkę drażniący temat. Kiedy w kodzie giganta zostaje znaleziona dziura tak, luka, cały świat huczy. Z jednej strony mamy do czynienia z nagonką, w sumie właściwą i jak najbardziej na miejscu, bo przecież czasami mówimy o bezpieczeństwie rzeszy ludzi na całym świecie. Z drugiej strony z rzeszą poszukiwaczy dziur, czy to wewnętrzne zespoły, bo powiedzmy, giganci mogą sobie na to pozwolić, że mają całkiem spore zespoły, które są odpowiedzialne tylko i wyłącznie za tego typu elementy, czy zewnętrzni poszukiwacze, pasjonaci, tak. A jak dziury są najczęściej znajdowane w przypadku mniejszych graczy tworzących właśnie oprogramowanie na zlecenie klientów?
Andrzej Dyjak: To znaczy konkretnie pytasz o to, w jaki sposób one są znajdowane?
Prowadzący: Jak najczęściej się to pojawia?
Andrzej Dyjak: A, ok.
Prowadzący: No, bo tak jak wspominałem, przy tych dużych tematach jest tyle oczu tak naprawdę, no ukierunkowanych w kierunku tego oprogramowania, że jeżeli nawet nie wewnętrzny zespół, to na pewno znajdzie się jakiś pasjonat, który stwierdzi, że tu jest ta luka, to trzeba nam załatać. A jak te elementy są wyłapywane w przypadku takich mniejszych, komercyjnych rozwiązań, które są na przykład dedykowane dla danej firmy?
Andrzej Dyjak: Wiesz co, to jest ciekawe pytanie dlatego, że bardzo często takie oprogramowanie, które jest dedykowane pod jakieś, to może być konkretna firma albo może być jakiś zestaw firm, ale niszowych. Takie oprogramowanie często jest przez wiele lat po prostu w ogóle nieruszane, to znaczy nikt na nie nie patrzy. No właśnie z tego powodu, że no nie ma tej, nie ma tego momentu, w którym osoba znająca się na bezpieczeństwie miałaby okazję popatrzeć na to oprogramowanie, dlatego że najczęściej nie jest w danej firmie zajmującej się czymś. Więc to jest pierwsze założenie, że po prostu tutaj nie następuje szybkie spotkanie pomiędzy bezpiecznikami, a tym oprogramowaniem. Natomiast w momencie, kiedy następuje, no to już jest najczęściej tak, że to oprogramowanie przez tyle lat nie było, nikt na nie nie patrzył, że po prostu te błędy są z prostego powodu, bo to, o czym wcześniej mówiliśmy, jeżeli my tworzymy oprogramowanie, to końcem końców dowozimy featury, czyli nie patrzymy na bezpieczeństwo. Tym bardziej, że nie mamy takiego sygnału z zewnątrz, który mówi nam, że nasze oprogramowanie ma błędy i powinno być poprawione. Co więcej, nasi klienci nie oczekują od nas tego albo powiedzmy, oczekują, ale nie robią tego wprost. Czyli no, oczywiście to oprogramowanie powinno być bezpieczne, no ale ja tego nie zapiszę w mojej specyfikacji ani w umowie. Ok, więc jeżeli czegoś nie ma na papierze, to tak jakby tego nie było. Więc ten vendor nie ma tak naprawdę powodów do inwestowania, bo tak jak wcześniej mówiliśmy, to jest koszt. Nie ma powodów do inwestowania w bezpieczeństwo, więc tego po prostu nie robi. A bezpieczeństwo samo z siebie też o siebie nie zadba. I w momencie, kiedy ktoś po prostu zaczyna szukać, no to zaczyna znajdować bardzo dużo, bardzo prostych błędów, dlatego że nikt wcześniej o nich nawet nie myślał, bo nie musiał tego robić. W przypadku tych większych vendorów, o których wspomniałeś, też nie jest tak różowo, że ci vendorzy nagle po prostu sobie myśleli – kurcze, fajnie jakby nasze oprogramowanie było bezpieczne. Nie, tak się stało tylko, dlatego że rynek to na nich wymógł. Czyli po prostu rynek wymaga na nich, żeby dbali o bezpieczeństwo na tyle, na ile rynek tego wymaga. Tutaj ważne, żeby przypomnieć o jednej takiej dość głośnej notatce od Billa Gatesa memos z 2001 roku, w momencie, to chyba był nawet styczeń, gdzie Bill Gates jasno napisał, że musimy postawić na bezpieczeństwo, musimy zadbać o bezpieczeństwo naszego oprogramowania, jest to nasze być albo nie być, dlatego że jeżeli nie będziemy dbać o bezpieczeństwo naszego oprogramowania, czyli głównie Windowsa i Offica w tamtym punkcie czasu, to klienci mogą pójść gdzieś indziej. I to jasno pokazuje, że to nie jest tak, że chcemy, żeby było bezpiecznie. Microsoft chciał, żeby było bezpiecznie, bo on nie chciał stracić klientów i tak samo jest z innymi wszystkimi firmami, dużymi gigantami. Chcą, żeby było bezpiecznie, bo nie chcą stracić klientów, czyli to już predykuje, że chcą żeby było bezpiecznie na tyle, na ile nie stracą klientów, ale nie musi być bezpiecznie. Więc, tutaj też nie chcę mówić, że u tych gigantów jest po prostu bardziej różowo i że oni dbają, a ci mniejsi nie dbają. Ci mniejsi nie dbają, bo po prostu ich klienci od nich tego nie wymagają. Ci więksi o to dbają, bo ich klienci tego wymagają bardziej wprost. I tylko jest taka różnica.
[00:25:03]Prowadzący: Gigantów tych parę też było, jest i będzie na pewno jeszcze bardzo dużo. Ale skoro już właśnie jesteśmy przy dziurach, lukach i ich poszukiwaczach to, jaką rolę w naprawie kodu czy szukaniu właśnie podatności przez społeczność zajmuje Bug Bounty? Pytanie nieprzypadkowe, bo sam znalazłeś kilka krytycznych podatności u topowych producentów. Jak producenci podchodzą do takich zgłoszeń? I jak tego typu zgłoszenia mogą im właśnie, tak jak wspominałeś, dalej pomóc? Czy chodzi tylko i wyłącznie rzeczywiście o utrzymanie reputacji, czy o bardziej wsparcie społeczności, takie wiesz zaangażowanie dwustronne w proces hardeningu oprogramowania?
Andrzej Dyjak: Tutaj być może mam niepopularną opinię, ale zaraz się nią podzielę. Natomiast rozpocznę od samego początku. Czyli postaram się nakreślić słuchaczowi, że to nie jest do końca tak, że te duże firmy sobie nagle pomyślały, że fajnie byłoby mieć Bug Bounty i płacić researcherom za to, że będą nam dostarczać…
Prowadzący: Taka promocja.
Andrzej Dyjak: Tak, że nie, nie, nie, nie. Po pierwsze, takie początki Bug Bounty można prześledzić od prywatnych, programów, które, czyli programów do zarządzania podatnościami, które rozpoczęły się jeszcze w dekadzie 2000/2010. I to były prywatne programy zewnętrznych firm, takie jak, dla przykładu Zero Day Initiative czy , w których uczestniczyłem, i w i w ZDI. I te programy miały za zadanie niejako oferować zewnętrznym researcherom sposób na, po pierwsze zarobienie na swojej wiedzy o tych podatności, a po drugie na koordynację tych podatności, tych błędów z firmami matkami. Czyli dla przykładu, ktoś znalazł błąd w Apple QuickTime, to on nie musiał iść do Apple. Mógł takie coś sprzedać do ZDI i teraz ZDI płaciło tej osobie, ZDI brało te dane, szło do Apple, a przy okazji robiło swój produkt, który, bo po prostu ID jest IPS. Więc to też nie jest tak, że ZDI robiło to za darmo i z dobroci serca. Mieli w tym swój interes, natomiast na pewno tutaj dołożyli taką dość mocną cegiełkę, czyli zrobili pewien kontakt, można by nawet powiedzieć kontrakt pomiędzy researcherem, a tą firmą końcową. Byli takim pośrednikiem. Bo jeszcze wcześniej, czyli przed tą dekadą było tak nie raz, że researcherzy próbowali coś zgłaszać, a te duże firmy, ci giganci pozywali researcherów. Od razu grozili im sądem.
Prowadzący: Do tego właśnie zmierzam.
Andrzej Dyjak: Więc to nie jest tak, że te duże firmy to tak z dobroci serca i one chcą, żeby było fajnie. Oczywiście, że nie. Co więcej, już tak na marginesie dodam, że to nie jest tak, że to było kiedyś, nawet teraz, nawet teraz, przedwczoraj czytałem o tym, że Xerox zabronił jednemu researcherowi opublikować swoich znalezisk podatności właśnie w oprogramowaniu Xeroxa na konferencji Infiltrate i groził mu sądem. Więc researcher, no po prostu tego nie zrobił, bo no nikt nie ma, no na pewno nie ma tyle na obronę w sądzie, co korporacja Xerox. Więc to się nawet jeszcze teraz nie skończyło, ale sytuacja jest trochę lepsza, ponieważ po tej dekadzie 2000/2010 nastąpiła kolejna dekada 2010/2020. I tu mieliśmy wysyp programów Bug Bounty. Te programy najpierw były takie prywatne, czyli jakiś vendor miał program Bug Bounty, dla przykładu przykład Google czy Microsoft, czy po prostu duża firma miała swój program Bug Bounty. Można było do nich zgłosić błędy w ich oprogramowaniu i oni za to płacili albo nie wiem, wysyłali koszulki. Ale już przynajmniej nie pozywali. Więc to już mieliśmy poprawę. Natomiast niektórzy ludzie w branży, w Stanach zobaczyli, że w zasadzie moglibyśmy być takim pośrednikiem, moglibyśmy wdrażać programy typu Bug Bounty do tych dużych vendorów, ale też do tych mniejszych, tych, których właśnie nie stać na dedykowane, duże zespoły bezpieczeństwa. No, bo jednak obsługa takiego programu Bug Bounty to jest koszt. Ktoś to musi robić. Więc jeżeli nie mamy zespołu albo nasz zespół jest mały, to trudno jest to robić. Więc powstały firmy, których specjalizacją jest zarządzanie programami Bug Bounty dla danych organizacji, dla przykładu HackerOne, dla przykładu Bugcrowd , w Europie mamy coś takiego jak Intigriti. Więc tych platform jest sporo. I teraz do sedna, jaka jest największa wartość dodana Bug Bounty? Bo Bug Bounty mają swoje plusy. Po pierwsze, pomagają na przykład ludziom wejść do branży. Kiedyś trzeba było wejść do jakiejś firmy, trzeba było zacząć robić pentesty, żeby się czegoś nauczyć, żeby pokazać swoje doświadczenie. Teraz już nie trzeba. Bug Bounty to nie jest pentest, Bug Bounty to nie jest ocena podatności. To jest taki mix pomiędzy oceną podatności, pentestem, może nawet trochę red teamem . Zależy od zasad. Ale nie jest tym, czymś konkretnym. Więc jest takim tlenem różnych testów bezpieczeństwa. Natomiast pomaga zyskać doświadczenie.
[00:30:00]Andrzej Dyjak: Więc jeżeli pobawimy się takimi programami Bug Bounty, no to raz, że się czegoś nauczymy, dwa, że możemy coś zarobić, a trzy, że jeszcze pokazać innym, że czegoś się nauczyliśmy, że coś zarobiliśmy, czyli pokazać naszą wartość, czyli zdobyć dla przykładu pierwszą pracę. Więc dla researcherów jest to duży plus. Dla firm jest to jeszcze większy plus, bo zmniejszają sobie koszty znajdowania podatności w swoim oprogramowaniu, czyli włączają taki program Bug Bounty, pozwalają researcherom znajdować błędy w ich oprogramowaniu. Tylko, że oni oczywiście biorą tylko te podatności, które uznają, że no faktycznie to jest podatność. Więc możesz im zgłosić coś, co końcem końców oni uznają, że to nie jest podatność, ale i tak to wyprowadzą. Natomiast Ty za to nic nie dostaniesz albo dostaniesz koszulkę. Co więcej, oczywiście są też takie sytuacje, że pięciu researcherów, czy więcej researcherów zgłosi tę samą podatność, no dostaje tylko ten pierwszy, a nie wszyscy. Więc widać, że według mnie, z mojego doświadczenia i z obserwacji rynku wydaje mi się, że organizacje otrzymują trochę więcej wartości z programu Bug Bounty, ale końcem końców ci researcherzy też otrzymują bardzo . Więc to nie jest tak, że tutaj ktoś nic nie otrzymuje, a ktoś otrzymuje wszystko. Po prostu researcherzy otrzymują trochę mniej, firmy otrzymują trochę więcej. Same programy Bug Bounty według mnie, działają na korzyść. Pozwalają nam trenować, pozwalają nam tworzyć większy zasięg, większą ilość ludzi, a bezpieczników brakuje i to w bardzo dużych liczbach. Więc końcem końców wydaje mi się, że mają pozytywny wpływ na to, jak wygląda krajobraz bezpieczeństwa i wydaje mi się, że są jednym z większych plusów ostatniej dekady – programy Bug Bounty, tak, definitywnie.
Prowadzący: Andrzej, kto tak naprawdę odpowiada za bezpieczeństwo aplikacji? Czy to są programiści, testerzy, QA engineer czy cały ciąg ludzi, czy software security developer? Czy ta funkcja w ogóle ma jeszcze dzisiaj sens, czy jest to tak naprawdę rozsmarowane na cały sztab ludzi odpowiadających za tworzenie oprogramowania?
Andrzej Dyjak: Tutaj może niepopularna opinia, ale jednak zgodna z prawdą. Za bezpieczeństwo aplikacji, za bezpieczeństwo kodu odpowiada developer. I tu nie ma miejsca do dyskusji, bo końcem końców, jeżeli ja coś tworzę, to ja odpowiadam za bezpieczeństwo. To oczywiście nie oznacza, że jeżeli coś pójdzie nie tak to ja jestem osobą, którą trzeba winić. Natomiast musimy wyjść od tego, że to developer odpowiada za bezpieczeństwo, dlatego że na koniec dnia też developer będzie wyprowadzał te ewentualne podatności. No gdyby nie on za nie odpowiadał, to ktoś inny mógłby to robić, a jednak nie może. Więc odpowiada za to developer. Ale oczywiście nie jest tutaj, nie jest jedyną osobą, która odpowiada. On po prostu odpowiada w większej mierze, bo to jest coś, co on tworzy. I też, jeżeli w momencie, kiedy ja tworzyłem oprogramowanie, to ja odpowiadałem za daną funkcjonalność, ja odpowiadałem za to jak dobrze ona jest zrobiona. Jeżeli nie działała, to ja byłbym osobą, która powinna ją poprawić, nikt inny. Natomiast na pewno mamy innych ludzi w procesie wytwórczym, którzy powinni nam pomagać zapewniać to bezpieczeństwo, powinni nam pomagać rozwiązywać problemy, jeżeli jakieś są znalezione. I teraz jest ciekawa kwestia właśnie, tutaj wspomniałeś o QA engineerach, Quality Assurance, o bezpiecznikach. U nas w Polsce, z moich obserwacji wynika, że raczej QA engineerzy często po prostu w ogóle nie mają nic wspólnego z bezpieczeństwem. To gdzieś tam powoli się zmienia, ale zmienia się trochę w takim brzydkim wydaniu, typu menadżer po prostu zrzuca odpowiedzialność za bezpieczeństwo na QA engineerów, bez ówwcześniejszej jakiejś edukacji, bez ówcześniejszego wdrożenia jakichś procesów, jest po prostu – no to teraz może zacznijcie też to testować. I to się nigdy dobrze nie kończy, bo bezpieczeństwo wymaga dość głębokiej wiedzy z różnych zakresów tego jak działa oprogramowanie, jak działają komputery. I tutaj też nie chcę mówić, że to jest jakieś rocket science, oczywiście da się tego nauczyć. Natomiast jest bardziej skomplikowane niż tylko oklikanie. I u nas jeszcze to nie jest takie widoczne albo jest widoczne w takim newalnym wydaniu. Natomiast za granicą już jasno widać trend, że za pewne aspekty bezpieczeństwa będą odpowiadać właśnie inżynierzy od spraw jakości, co jest w zasadzie dość logiczne, dlatego że bezpieczeństwo jest odnogą jakości, jest podzbiorem jakości. Więc to też logiczne, że takie podstawowe testy bezpieczeństwa, czyli security testing, nie penetration testing, bo to są dwa różne rodzaje testowania bezpieczeństwa. Security testing należy do QA. Natomiast penetration testing należy do bezpieczników. I penetration testing zawsze będzie należał do bezpieczników, co więcej, nigdy nie będzie się go dało zautomatyzować.
[00:35:04]Andrzej Dyjak: A security testing będzie należał do QA engineerów, na zachodzie już należy i w dużej mierze da się go automatyzować. Więc tutaj, no tutaj trochę tak opowiedziałem, że no coś trochę tu należy, trochę tam, trochę rozmyłem. Jeszcze odnośnie funkcji software security developer. Wiesz co, jest coś takiego jak security champions, często jest to wprowadzane w organizacjach, jako taki bufor, jako taka satelita odnośnie działu bezpieczeństwa. Czyli mamy dział bezpieczeństwa odpowiedzialny za bezpieczeństwo aplikacji. On zawsze jest za mały, czyli zawsze jest za mało osób tam. Nie jesteśmy w stanie po prostu się rozmnożyć i ogarnąć całego porfolia aplikacji. Więc dużo firm wymyśliło sobie sposób, że – aha, no dobra, no to jeżeli ja w każdym zespole wytwórczym, wydeleguję jedną osobę, która się bardziej jara bezpieczeństwem i ona będzie taką satelitą, ona będzie takim pierwszym punktem kontaktowym tego zespołu wytwórczego, w kontekście bezpieczeństwa, no to trochę mi się ta praca po prostu ułatwi, nie. Oczywiście, jeżeli taka osoba ma problem, to ona może przyjść do mnie, ale myślę, że często po prostu daje sobie radę sama i nie musi przychodzić do mnie. W takim wypadku ta funkcja ma dość dużo wartości, czyli właśnie funkcja security champion, można to nazwać software security developer. Po prostu osoba, która jest w zespole wytwórczym, która ma trochę większe raz, że pojęcie nie tylko o bezpieczeństwie, w ogóle po prostu o oprogramowaniu, jest w stanie przewidywać pewne rzeczy, czyli jest najczęściej seniorem. A dwa, no też się interesuje tym bezpieczeństwem, więc gdzieś tam jest w stanie po prostu pomagać tym swoim kolegom, koleżankom. Więc tutaj wszystkie w zasadzie te trzy role mają swój wkład, ale odpowiedzialny za bezpieczeństwo końcem końców jest developer.
Prowadzący: Słuchaj, już kilka razy dzisiaj wspomniałeś o edukacji, kilka razy. Jak wygląda właśnie edukacja programistów w kontekście bezpieczeństwa? Od czego najlepiej zacząć i jaką ścieżkę obrać? OWASP, coś innego?
Andrzej Dyjak: Wiesz co, jeżeli chcielibyśmy zacząć od edukacji i jeżeli teraz mówimy o programistach możemy to rozszerzyć po prostu na ludzi technicznych. Bo to mogą być , mogą być QA, mogą być ops . To tak, takim dobrym krokiem pierwszym jest edukacja pod kątem OWASP Top 10 i OWASP Top 10, a nie inny standard albo nie jakieś inne Top 10, z prostych przyczyn. OWASP Top 10 nie jest standardem, ale jest zbiorem top 10 klas podatności z jakiegoś punktu czasu. Najnowszy jest z 2017, w tym roku będzie nowsza wersja 2021. Natomiast on jest dobrym takim właśnie narzędziem, który buduje świadomość odnośnie bezpieczeństwa. I jeżeli sobie przetrenujemy te nasze zespoły właśnie pod kątem OWASP Top 10, czyli zaznajomimy ich z tymi podatnościami, z tymi klasami podatności, to te osoby nagle będą mogły w swojej pracy wyłapywać te podatności lub nawet, jeżeli tak świadomie ich nie wyłapywać, na przykład programista, to myśląc o nich, po prostu może ich nie wprowadzi. Bo zamiast pisać ręcznie jakiegoś sequena, no to użyje jakiegoś ORM. No i w takim wypadku rozwiąże ten problem SQL injection . Więc tutaj, top 10 jest takim dobrym początkiem. Natomiast potem można iść trochę głębiej i można edukować już w jakichś konkretnych technologiach, czyli dla przykładu, jeżeli mamy programistów i naszymi stackami technologicznymi jest nie wiem, Java, a na front-endzie mamy Reacta, no to moglibyśmy zrobić jakieś szkolenie dla front-endowców z Reacta, jak zabezpieczać to oprogramowanie reactowe, ale też oczywiście szerzej trochę java scriptowe, a dla back-endowców możemy zrobić szkolenie o tym, jak zabezpieczyć aplikacje javove, które mają swoje klasy, które się klastrują wokół Javy, które nie zawsze są jeden do jeden w przełożeniu z OWASP Top 10. Czyli w OWASP Top 10 mogą być takie podatności, które na przykład w Javie często nie występują. Tutaj akurat podałem Javę, to nie jest dobry przykład, bo Top 10 to raczej występuje cały w Javie. Ale jeżeli wzięlibyśmy jakąś inną technologię nie wiem, na przykład Ruby i Ruby on Rails, to są podatności, które są w OWASP Top 10, a w Ruby on Rails są rozwiązywane auto w dead box i w ogóle nawet nie trzeba ich sprawdzać, bo one po prostu są rozwiązane. Chyba, że robimy coś dziwnego. Więc tyle. No i oczywiście opsów to też, pod kątem tego jak się zabezpieczać infrastrukturą. Natomiast takim dobrym Baselinem jest OWASP Top 10. I to można dla wszystkich osób technicznych przeprowadzić tego typu szkolenie.
Prowadzący: Słuchaj, chciałem jeszcze wrócić do tematu standardów testów oprogramowania, rodzajów testów. Kto zajmuje się testowaniem?
Andrzej Dyjak: Kto zajmuje się testowaniem?
Prowadzący: Tak.
Andrzej Dyjak: Dobrze. Ja tutaj mam kolejną niepopularną opinię.
[00:40:00]Andrzej Dyjak: Mianowicie, ja rozgraniczam rodzaje testów. Po pierwsze widzę, że w ogóle nie tylko na naszym poletku polskim, tylko na zachodnim oczywiście też jest sporo niezrozumienia tego, czym jest test penetracyjny. I ile osób, wiesz, mamy 10 bezpieczników to będziemy mieć 11 opinii, czym jest test penetracyjny. Ja mam prosty model tego, jaki jest zakres, do czego prowadzi dane ćwiczenie. I ten model jest oparty oczywiście na różnego rodzaju standardach, to co powiedziałem wcześniej, a może jeszcze wrócę, dlaczego ja lubię to rozgraniczać. Ja lubię to rozgraniczać, bo pozwala mi to właśnie określić jasno, jaka rola powinna, co robić. Dla przykładu, jeżeli patrzymy tak simplistycznie na testowanie i wszystko według nas, testowanie bezpieczeństwa, to zawsze jest test penetracyjny. No to zamykamy sobie drogę i w takim wypadku, to musi zawsze robić pentester. No, bo to jest test penetracyjny, więc to powinien robić pentester. Ale jeżeli popatrzymy na to trochę szerzej i zdefiniujemy sobie pewne główne aspekty danego rodzaju testów bezpieczeństwa, to możemy zacząć rozdrabniać to i rozdzielać to na inne podzespoły, na inne komórki. I w moim modelu, dla przykładu, ocenę podatności może wykonać QA engineer. I ocena podatności końcem końców, jeżeli my mówimy o wytwarzaniu oprogramowania ma dużo większą wartość niż test penetracyjny. Bo test penetracyjny z założenia powinien testować naszą aplikację albo na środowisku produkcyjnym, albo kopii jeden do jeden środowiska produkcyjnego. Co więcej, powinien testować siłę naszych rozwiązań bezpieczeństwa. Czyli, jeżeli mamy test penetracyjny i ktoś w nim znajdzie podstawowego xssa to znaczy, że nasza aplikacja tak naprawdę w ogóle nie jest gotowa na test penetracyjny. Bo w momencie, kiedy testujemy penetracyjnie, to w ogóle nie powinno być xssów. My się powinniśmy skupić na jakichś ciągach ataków, na ciągu, na całym łańcuchu ataku, a nie tylko na jakiejś podatności i to jeszcze tak prostej, jak xss. Jeżeli mamy xssy, to coś już jest nie tak, bo ten xss powinien zostać znaleziony w rundzie oceny podatności, właśnie jeszcze na etapie QA engineera. I właśnie to jest to, co wcześniej powiedziałem, że testy penetracyjne zawsze będą robione przez pentesterów, bo one wymagają specjalizacji w bezpieczeństwie. Natomiast testy bezpieczeństwa i tutaj mówię o ocenie podatności, ona może być robiona przez QA engineera, bo ona nie wymaga specjalizacji w bezpieczeństwie. Ona wymaga jedynie podstawowej wiedzy, czym jest xss i jak testować xssa. Ja nie muszę wiedzieć jak potem wykorzystać tego xssa w ataku. Ja wystarczy, że wiem jak go znaleźć i jak go znajdę to wystarczy, że zrobię ticket w i na tym się kończy. Więc ja tutaj trochę to dzielę i dążę do tego, żeby pokazać, że różne role mogą spełniać różnego rodzaju kontrolki bezpieczeństwa. Więc QA engineerzy mogą robić ocenę podatności, pentesterzy mogą robić testy penetracyjne. Możemy mieć programistów, włącznie z bezpiecznikami, którzy tworzą modele zagrożeń. Ci programiści, w pewnym momencie jak przejrzą, jak przejdą kilka interakcji, sami będą sobie mogli robić te modele. Ale na początku dobrze jest mieć takiego eksperta domenowego, który pomoże w szukaniu tych problemów bezpieczeństwa. Więc tu już mamy tych programistów, którzy też tworzą jakiś proces, który końcem końców pomaga nam w obronie naszego softwaru, ale no w zasadzie to jeszcze nawet nie jest testowanie, bo to jest tylko myślenie o tym, co może pójść źle, bo to jest modelowanie zagrożeń, co może pójść źle i co możemy zrobić, żeby nie poszło źle.
Prowadzący: A jakie narzędzia są najczęściej wykorzystywane w przypadku testów oprogramowania?
Andrzej Dyjak: Wiesz co, jeżeli mówimy o takich typowych dynamicznych testach i manualnych. A to chwila. To najpierw powiedzmy o automatycznych. Jeżeli mówimy o automatycznych, to często jest wykorzystywany Nessus lub jakiś ekwiwalent Nessusa. To jest typowy skan podatności, który zawiera się w ocenie podatności, ale to jest skan podatności, on jest automatyczny. Następnie możemy mieć automatyczne narzędzia, które testują naszą aplikację, dynamicznie, tak zwane DASTY – Dynamic Application Security Testing, to może być na przykład Acunetix. I to też dalej jest można powiedzieć właśnie, taki automatyczny skan podatności, czyli pewnego rodzaju ocena podatności. Natomiast, jeżeli pójdziemy dalej i chcemy już przeprowadzać manualną ocenę podatności, ale dalej ocenę podatności, ale również też test penetracyjny, bo oczywiście w testach penetracyjnych aplikacji też się wykorzystuje to samo narzędzie. To musimy wykorzystywać, może nie musimy, ale najczęściej wykorzystuje się proxy. I tym proxy najczęściej jest albo Burp, albo ZAP. ZAP jest darmowym odpowiednikiem Burpa, który w chwili obecnej no jest już faktycznie całkiem dobrym wyborem, nie trzeba mieć Burpa. Ale, że Burp jest na tyle tani, że w zasadzie każdy może sobie na niego pozwolić w IT, bo kosztuje tam chyba 300$ na rok, więc nie jest dużym wydatkiem, a jest takim gold standard.
[00:45:09]Andrzej Dyjak: I tutaj ja o tym wspominam, dlatego że Burp będąc takim standardem rynkowym ma swój ekosystem i w tym ekosystemie jest bardzo dużo różnych pluginów, które po prostu ułatwiają nam pracę. Więc nawet o ile sam Burp mógłby być dość łatwo podmieniony przez ZAP, no to już ten ekosystem byłby trudniejszy, bo po prostu ZAP nie ma tak bogatego ekosystemu. Natomiast musimy mieć jakieś proxy. Proxy pomaga nam w podglądywaniu i w edycji tego, co wysyłamy do aplikacji. Czyli technicznie nie musimy mieć tego proxy, moglibyśmy robić wszystko ręcznie, ale zajęłoby to nam dużo więcej czasu. Więc proxy pomaga nam w szybszym działaniu, jest, tak pomaga nam w szybszym działaniu, więc musimy mieć jakieś proxy i najczęściej jest to Burp albo ZAP. I to służy do, no właśnie testowania manualnego pod kątem bezpieczeństwa. I może służyć zarówno w ocenie podatności, dla przykładu przez QA engineera, a może służyć również do testów penetracyjnych przy szukaniu podatności w web aplikacji. Bo końcem końców narzędzie jest to samo, tylko ten cel tego atakującego jest po prostu trochę inny. Natomiast narzędzie jest to samo. I takim no, właśnie rynkowym standardem jest Burp.
Prowadzący: No wspominałeś właśnie o Burpie. Ja pamiętam jak jakiś czas temu byłem na warsztacie dotyczącym podatności aplikacji webowych i rzeczywiście, przez większość czasu prowadzący korzystał tylko z Burpa i ja byłem pełen zdumienia. Tak, jak wspominasz odnośnie ilości modułów, które tam występują i w jaki sposób on oczywiście te moduły wykorzystywał do tego, żeby się dobijać do najróżniejszych systemów, do najróżniejszych aplikacji. I teraz właśnie też pytanie. No czy tego typu narzędzia są właśnie wykorzystywane tylko w przypadku testów penetracyjnych i właśnie testów? Czy również przez drugą stronę, tak produkcyjnie? No, bo z tego, co widziałem, to równie dobrze można to wykorzystać w dwojaki sposób.
Andrzej Dyjak: Nie. Oczywiście one są wykorzystywane przez tę drugą stronę. Bo zauważ, że w zasadzie to, co robisz jest takie samo, tylko twój cel jest inny, nie? Więc jeżeli twoim celem nie jest wypełnienie warunków umowy z daną firmą, tylko można powiedzieć działanie niezgodne z prawem, na szkodę tej firmy, to też będziesz korzystał z tego narzędzia. Jedyna różnica jest taka, że prawnie nie masz z nimi żadnych powiązań i twoim celem już nie jest udowodnienie zarządowi, że da się włamać, tylko faktyczne włamanie. Ale narzędzie będzie dokładnie to samo. Można byłoby się zastanawiać w takim wypadku, czy może producent byłby w stanie w jakiś sposób nie wiem, mitygować i sprzedawać jakimś dziwnym charakterom. Być może by był, być może nie. Końcem końców te narzędzia, o których mówimy, nawet komercyjne da się często znaleźć w różnych zakamarkach sieci. Więc, jeżeli ktoś ma złe intencje to i tak sobie poradzi, czyli w jakiś sposób dostanie to narzędzie. A to byłoby tylko utrudnienie dla tych, którzy nie mają złych intencji.
Prowadzący: Wiesz co, poruszyliśmy temat testów, a teraz co jest jeszcze ważne. Mamy testy, mamy testy penetracyjne również. Komunikacja pomiędzy testerem, a programistą, czyli takie typowe sprzężenie zwrotne. Jak działa, czy zawsze działa?
Andrzej Dyjak: Z mojego doświadczenia nie działa, bo to jest to, o czym mówiliśmy wcześniej. To znaczy bezpiecznicy nie mając doświadczenia w wytwarzaniu oprogramowania, często nie są w stanie popatrzeć oczami tej drugiej strony. I też trzeba wziąć pod uwagę jeszcze taką, no cechę charakteru, jeżeli ktoś, jeżeli czyimś zadaniem jest szukanie błędów w całym, to z założenia on będzie miał trochę inne predyspozycje, inny charakter niż osoba, która na przykład buduje. I będzie jej po prostu trudno, bezpiecznikowi spojrzeć tymi oczami programisty. I ja się sam do tego przyznaję, bo o wszystkich takich problemach, które mówię, to są często rzeczy, które ja sam przechodziłem. I dlatego ja te problemy zidentyfikowałem, i dlatego ja je tak jasno widzę, bo ja po prostu sam tam byłem. I na początku mojej kariery bezpiecznika bardzo trudno było mi zobaczyć skąd te problemy albo w ogóle no przecież myślałem, że no programiści, przecież to w ogóle nie powinno być tych błędów. No nie. I trochę później w tej karierze to zrozumiałem, ale dalej widzę brak zrozumienia właśnie bezpiecznik – programista i zaczyna się właśnie taka trochę wojenka pomiędzy tym bezpiecznikiem, a pomiędzy tym programistą. I to sprzężenie zwrotne nie występuje. Występuje mocny opór i brak współpracy. Też oczywiście tutaj trzeba brać pod uwagę, że często programiści swoje za uszami też mają, czyli też nie nastawiają się do tej rozmowy tak, że chcą zrozumieć sedno problemu. Tylko podchodzą trochę tak defensywnie do tego i mówią, że traktują ten swój kod albo ten swój feature, aplikacjacje, jako takie swoje dziecko. I wtedy, no ty przychodzisz i mówisz mi, że moje dziecko jest brzydkie, no to się nie będziemy lubić, nie?
[00:50:02]Prowadzący: Nie będziemy się lubić, tak.
Andrzej Dyjak: I no niestety tak to wygląda. Więc tutaj dobrze jest mieć, dla przykładu menadżera, to może być project manager bądź product owner, który trochę można powiedzieć ogładza tę relację, stara się pokazać, że tutaj gramy w tej samej drużynie, chodzi nam w zasadzie o to samo. I na koniec dnia chcemy to wyprowadzić i zrobić tak, żeby tego błędu w ogóle nie było w przyszłości.
Prowadzący: Czyli typowa rola rozjemcza?
Andrzej Dyjak: Tak, tak, tak. I ta rola, jeżeli jest i jeżeli taki człowiek faktycznie rozumie swoją rolę w kontakcie pomiędzy programistą, a bezpiecznikiem, to wtedy to może działać. Wtedy to może działać, jeżeli tutaj sobie wyrównamy to. Natomiast, jeżeli mamy tylko bezpiecznika i programistę, to często podchodzą do całej dyskusji już tak, nie grają w jednej drużynie, o. Widzą się, jako przeciwne drużyny, więc to sprzężenie zwrotne jest problematyczne. To znowu, to się powoli zmienia, zaczyna być trochę lepiej, ale jeszcze nie jesteśmy tam, gdzie byśmy chcieli, na czym końcem końców cierpi bezpieczeństwo naszych aplikacji.
Prowadzący: Andrzej, na chwileczkę chciałbym przeskoczyć do aplikacji typowo mobilnych. Zanim rozpoczęliśmy dzisiejsze nagranie to chwileczkę rozmawialiśmy na temat najróżniejszych, dziwnych czasami nawet aplikacji i dostępnych na naszych smartfonach. Jak też te główne firmy, które mają swoje sklepy podchodzą do tematyki tworzonego przez inne firmy oprogramowania i publikacji tego oprogramowania na swoich po prostu sklepach, tak? Jak analizują to oprogramowanie? Bo wiesz, nie raz było tak, że oprogramowanie trafiało do, właśnie do sklepu, zostało pobierane przez jakąś rzeszę tak naprawdę ludzi i po pewnym czasie słyszeliśmy jakieś głośne informacje, że n różnych aplikacji zostało zdjętych ze sklepu czy to Androida, czy iOSa z powodu właśnie naruszeń bezpieczeństwa.
Andrzej Dyjak: No to od razu powiem jako fan by Apple. No Apple to najlepiej. Ale oczywiście to też nie jest tak, że to lepiej jest samo z siebie. First things first , u Apple wygląda lepiej, ale też proces wejścia do sklepu Apple jest, można powiedzieć trudniejszy.
Prowadzący: Wiesz, może to z tego wynika. Ciężej się dostać.
Andrzej Dyjak: Tak.
Prowadzący: Więc jak już się ktoś tam dostaje to się trzyma rękami i nogami.
Andrzej Dyjak: Dokładnie. Też raz, że ciężej się dostać. Dwa, że ciężej się utrzymać i sama platforma jest po prostu bardziej zamknięta, czyli jest ze strony developera, jest bardziej dla nas hostline. No ona nam na dużo po prostu nie pozwala nawet, jeżeli byśmy coś chcieli zrobić. Z drugiej strony, Android jest dużo bardziej liberalny, jako platforma no, ale to też rzutuje potem na bezpieczeństwo i też musi rzutować właśnie na sklep Google, który jest po prostu znowu, jak platforma jest trochę bardziej liberalny. Dlatego na platformie Google spotyka się takie sytuacje, że mamy jakiś na przykład malware albo jakieś aplikacje, które nie do końca robią to, co powinny robić. Po prostu zdarzają się dużo częściej, bo po pierwsze, łatwiej wejść do sklepu. Po drugie, łatwiej już na danej platformie robić coś, czyli jak się dostaniemy, nasza aplikacja dostanie się na Androida, to łatwiej robić coś nie takiego, co powinniśmy robić. Więc, no stąd wynika po prostu ten problem. Google jest bardziej otwarty, jest bardziej przyjazny programiście, twórcy no, ale z tym też idzie to, że jego bezpieczeństwo jest po prostu trochę niżej. I tutaj nie mówię teraz o takim bezpieczeństwie niskopoziomowym, bo na takim poziomie oczywiście jest ok, jeżeli weźmiemy najnowszego flagowego Samsunga, to on nie jest jakoś bardziej niebezpieczny niż flagowy najnowszy iOS. Oczywiście, różnice występują, natomiast to nie jest tak, że do jednego to się pięciolatka wkradnie, a do drugiego nie. Jedno i drugie poprzeczkę ma wysoko. Natomiast, jeżeli my mówimy o samej platformie, właśnie o sklepach, to na pewno łatwiej wejść do Google, a przez to, że łatwiej, przez to, że platforma i sklep jest bardziej liberalny, no to łatwiej się prześlizgnąć oprogramowaniu, które no nie zawsze robi to, co my byśmy chcieli. Natomiast oczywiście Google też stara się temu przeciwdziałać, więc często są akcje, że na przykład ze sklepu znika nie wiem, 15 tysięcy aplikacji, nie. No, może przesadziłem, ale, że znika 500 aplikacji. I nagle, czemu? A potem się okazuje, że a no, bo coś w tych aplikacjach było nie tak, one robiły coś nie halo i Google wywala wszystkie. Więc to nie jest, że Google się tym nie zajmuje. Po prostu Google to nie jest core biznesu. Dla Google core biznesu to jest wyszukiwarka i reklamy, a u Apple core biznesu jest produkt. A jeżeli u Apple core biznesu jest produkt, no to większą wagę przywiązują do zabezpieczania tego produktu, bo jeżeli przestanie ci się podobać produkt, to nie kupisz kolejnego Iphona. A jeżeli przestanie ci się podobać Android, no to możesz albo kupić Iphona, albo zostać przy Androidzie.
Prowadzący: Andrzej, na zakończenie. Główne problemy bezpieczeństwa dla języka programowania, profilu aplikacji, nie wiem, bibliotek, które są wykorzystywane, mechanizmów.
[00:55:02]Prowadzący: Czy są po prostu jakieś wzorce, które mówią tak wprost, jeżeli korzystasz z biblioteki X, to zwróć uwagę na Y, a w tym języku programowania należy zwrócić dodatkowo uwagę na, tego typu patterny ?
Andrzej Dyjak: Ok. No to są, to nie jest do końca tak, że mamy dla wszystkiego i cokolwiek byśmy sobie nie wyśnili to mamy takie rozwiązania. Ale, dobrze jest zacząć od tego, o czym już dzisiaj mówiliśmy, OWASP Top 10. OWASP Top 10 listuje nie tylko 10 najpopularniejszych klas podatności, ale też listuje sposoby, jak można te podatności rozwiązywać. To jeszcze nie jest takimi faktycznymi radami z pokazaniem kodu źródłowego. Ale są już takie grupy, wysokopoziomowe kierunki, no mógłbyś zacząć robić to i to, i wtedy nie będziesz miał tej podatności, dla przykładu SQL injection, on ci mówi, że no możesz korzystać z ORM, no i ok, będziesz korzystał z ORM, to będzie ok. Następnie jest coś takiego jak OWASP Proactive Controls, to jest bezpośrednio dowiązane do Top 10, które, no jak sama nazwa mówi, kontrolki bezpieczeństwa, które można jakoś implementować. Kolejna rzecz, o której bardzo często ludzie zapominają albo w ogóle nie wiedzą, jest taki projekt OWASP Cheat Sheets, czyli ściągawki. I tutaj notabene, jednym z głównych twórców OWASP Cheat Sheets jest Polak. Teraz kurcze, nie pamiętam jak ma na nazwisko, ale wiem, że ma na imię Jakub. Ale tutaj, jest Polakiem, na githubie, jeżeli ktoś sobie wejdzie na Cheat Sheetsy to będzie tam widział imię, nazwisko, więc nie ma co. A nie, to chyba jest Jakub Maćkowski, dlatego ten Maciek gdzieś tam się w głowie czai. Przepraszam, poprawię się na przyszłość. Natomiast, jest Polak i to jest takie notabene, natomiast Cheat Sheetsy opisują właśnie dokładnie to, o czym powiedziałeś. Typu, mamy jakiś mechanizm, dla przykładu upload plików, no ok, no to, jeżeli implementujesz upload plików, no to zwróć uwagę na to, to i to. I to są typowe błędy, które są przy uploadzie plików, ten, ten, ten i ten, i spróbuj ich nie popełnić, nie? Mamy nie wiem, przetwarzanie xml, ok, to zrób to, to, to, to i na te i te, i te problemy powinieneś zwrócić uwagę. Więc Cheat Sheets są takim dokładnie przełożeniem typu robię jakąś funkcjonalność, bardzo dobrze jest wejść sobie na Cheat Sheets i zobaczyć, czy jest tam konkretna ściągawka dla funkcjonalności, którą robię. Bo też trzeba zdać sobie sprawę, że większość czasu, jaki poświęca programista na pisanie oprogramowania w typowej firmie, to nie jest wymyślanie kodu na nowo, to jest po prostu implementowanie już jakiejś funkcjonalności, którą można zgeneralizować, która już pewnie gdzieś jest. Więc, o ile oczywiście są firmy i programiści, którzy tworzą niestworzone rzeczy, to jeżeli pracują w jakiejś średniej czy mniejszej firmie, to najczęściej po prostu powielamy i też ok. Więc tutaj na naszą korzyść działa to, że możemy popatrzeć jak inni to robili, możemy popatrzeć, jak inni mówią nam, że ok, ty nie powinieneś robić tego i tego, i tego, bo to może potem cię ugryźć w tyłek. I na koniec jest jeszcze OWASP ASVS, czyli Application Security Verification Standard, który może nie mówi nam jasno jak wyprowadzać i jak przeciwdziałać tym podatnościom, ale mówi nam znowu, co powinniśmy, na co powinniśmy zwrócić uwagę. No on to mówi w takim kontekście, co powinniśmy zweryfikować. Więc, jeżeli mamy dla przykładu, przetwarzanie wejścia, no to mamy całą sekcję OWASP ASVS i on mówi ok, zweryfikuj to, to i to, i zweryfikuj, że jeżeli przyjmujesz dane to robisz to i to. No i to też możemy odwrócić, jak programista popatrzy – aha, dobrze, no to ja przejmuje dane, no to, co powinienem zrobić? Aha, oni mówią, że powinienem zweryfikować no, czyli powinienem to robić. Skoro bezpiecznik powinien zweryfikować, że istnieje taki mechanizm to znaczy, że ja, jako programista powinienem go stworzyć. Więc na ASVS też można popatrzeć, ale ASVS jest dość długi i jest specjalistyczny. Więc może po prostu nie być tak przyjazny jak Cheat Sheets. Cheat Sheets, czyli ściągawki będą na pewno przyjaźniejsze w odbiorze dla programisty. Więc zacząłbym od Cheat Sheetsów, a potem sobie zobaczył OWASP Top 10, OWASP Proactive Controls i OWASP ASVS. Chociażby tylko po to, żeby mieć takie mentalne punkty, że coś takiego istnieje.
Prowadzący: Hasło dla słuchaczy na dzisiaj to OWASP. Moim gościem w dzisiejszym odcinku był Andrzej Dyjak, bezpiecznykod.pl. Andrzej, wielkie dzięki za rozmowę i Twoją dzisiejszą obecność.
Andrzej Dyjak: Dzięki i tak jak mówiłem na początku, bardzo się cieszę, że mogłem jeszcze raz pogadać sobie o bezpieczeństwie aplikacji, o moim jednym z ulubionych tematów.
Prowadzący: Dzięki jeszcze raz. Do usłyszenia w następnym odcinku.
Andrzej Dyjak: Na razie.
