POIT #095: Bezpieczeństwo aplikacji

Witam w dziewięćdziesiątym piątym odcinku podcastu „Porozmawiajmy o IT”. Tematem dzisiejszej rozmowy jest bezpieczeństwo aplikacji.

Dziś moim gościem jest Andrzej Dyjak – architekt bezpieczeństwa z kilkunastoletnim doświadczeniem, aktywny konsultant, prelegent i szkoleniowiec. Doświadczenie zdobywał w kraju i za granicą dostarczając pełne spektrum oceny bezpieczeństwa dla organizacji z sektora prywatnego i publicznego. W przeszłości odkrył wiele krytycznych podatności w popularnym oprogramowaniu firm takich jak: Apple, Adobe, Google czy Mozilla. Blogger i podcaster.

W tym odcinku o bezpieczeństwie aplikacji rozmawiamy w następujących kontekstach:

  • dlaczego jest ważne i warto o nie dbać?
  • w jakim stopniu są za nie odpowiedzialni programiści?
  • czego brakuje developerom aby włączyć dbanie o bezpieczeństwo w proces wytwórczy oprogramowania?
  • czym jest DevSecOps?
  • jaką rolę w zapewnieniu bezpieczeństwa gra komunikacja?
  • co to jest OWASP?
  • czy zespół QA odpowiada za finalne bezpieczeństwo aplikacji?
  • czym zajmują się osoby odpowiedzialne za security?
  • jakie umiejętności trzeba posiąść żeby na takim stanowisku pracować?
  • jak wygląda rynek pracy dla takich osób?
  • czy są w tym obszarze dostępne jakieś certyfikaty?

Tech Master Class Podcast

Chcę Ci powiedzieć o nowym projekcie, do którego prowadzenia zostałem zaproszony przez ING Tech Poland, dostawcę kompleksowych usług IT i usług operacyjnych dla ING na całym świecie. Projekt ten to Tech Master Class Podcast, czyli cotygodniowa dawka technologicznych inspiracji i fachowej wiedzy w formie podcastu.
W odcinkach posłuchasz rozmów z ekspertami m. in. o nauce programowania, sytuacji kobiet w IT, przebranżowieniu, a nawet technologii przeciwdziałających praniu brudnych pieniędzy.
W ramach Tech Master Class Podcast słyszymy się w każdą środę rano i już teraz serdecznie zapraszam do odsłuchania pierwszego odcinka.

Podcast jest dostępny na Spotify, YouTube i innych platformach podcastowych.

Subskrypcja podcastu:

Linki:

Wsparcie na Patronite:

Wierzę, że dobro wraca i że zawsze znajdą się osoby w bliższym lub dalszym gronie, którym przydaje się to co robię i które zechcą mnie wesprzeć w misji poszerzania horyzontów ludzi z branży IT.

Patronite to tak platforma, na której możesz wspierać twórców internetowych w ich działalności. Mnie możesz wesprzeć kwotą już od 5 zł miesięcznie. Chciałbym oddelegować kilka rzeczy, która wykonuję przy każdym podcaście a zaoszczędzony czas wykorzystać na przygotowanie jeszcze lepszych treści dla Ciebie. Sam jestem patronem kilku twórców internetowych i widzę, że taka pomoc daje dużą satysfakcję obu stronom.

👉Mój profil znajdziesz pod adresem: patronite.pl/porozmawiajmyoit

Pozostańmy w kontakcie:

 

Muzyka użyta w podcaście: „Endless Inspiration” Alex Stoner  (posłuchaj)

Transkrypcja podcastu

To jest 95. odcinek podcastu Porozmawiajmy o IT, w którym z moim gościem rozmawiam o bezpieczeństwie aplikacji.

Przypominam, że w poprzednim odcinku rozmawiałem o buzzwordach w IT.

Jeśli jeszcze tego nie zrobiłeś, to wystaw ocenę lub recenzję podcastowi w aplikacji, w której tego słuchasz.

Zanim odpalę rakietę i przejdę do odcinka, chcę Ci powiedzieć o nowym projekcie, do którego prowadzenia zostałem zaproszony przez ING Tech Poland, dostawcę rozwiązań i usług IT.

Projekt ten to tech Masterclass Podcast, czyli cotygodniowa dawka technologicznych inspiracji i fachowej wiedzy w formie podcastu. W odcinkach posłuchasz rozmów z ekspertami, między innymi o nauce programowania, sytuacji kobiet w IT, przebranżowieniu, a nawet technologii przeciwdziałających praniu brudnych pieniędzy.

W ramach Tech Masterclass Podcast słyszymy się w każdą środę rano i już teraz zapraszam Cię do odsłuchania pierwszego odcinka.

Podcast jest dostępny na Spotify, YouTube i innych platformach pdcastowych. Linki standardowo najdziesz w opisie tego odcinka pod adresem porozmawiajmyoit.pl/95. 

Chcę poszerzać horyzonty ludzi z branży IT i wierzę, że poprzez wywiady takie jak ten, publikowane jako podcasty, będę to robił z sukcesem.

Nazywam się Krzysztof Kempiński i życzę Ci miłego słuchania. 

Odpalamy!

 

Cześć! Mój dzisiejszy gość to architekt bezpieczeństwa z kilkunastoletnim doświadczeniem, aktywny konsultant, prelegent i szkoleniowiec. Doświadczenie zdobywał w kraju i za granicą, dostarczając pełne spektrum oceny bezpieczeństwa dla organizacji sektora prywatnego i publicznego.

W przeszłości odkrył wiele krytycznych podatności w popularnym oprogramowaniu firm, takich jak Apple, Adobe, Google czy Mozilla. Bloger i podcaster. 

Moim i Waszym gościem jest Andrzej Dyjak. 

Cześć, Andrzej! Miło mi gościć cię w podcaście.

 

Cześć, Krzysztofie! Od razu powiem, że cała przyjemność po mojej stronie. Bardzo, bardzo jestem ucieszony, że udało się trafić do Porozmawiajmy o IT.

 

Też się bardzo cieszę no i oczywiście tematem naszej dzisiejszej rozmowy nie może być nic innego niż bezpieczeństwo, ale trochę to zawęzimy i porozmawiamy sobie o bezpieczeństwie aplikacji.

Oczywiście nie możemy rozpocząć naszej rozmowy bez standardowego, klasycznego pytania na wejście, czyli czy słuchasz podcastów i jeśli tak, to podziel się proszę swoimi ulubionymi audycjami.

 

Oczywiście, że słucham podcastów. W zasadzie już od paru lat. Zacząłem w 2016 roku, więc to już 4 rok odkąd słucham – w zasadzie parę razy w tygodniu odsłuchuję jakąś audycję. Słucham zarówno podcastów technicznych i z zagranicznych polecam Software Engineering Daily, od którego w zasadzie zacząłem swoją przygodę z podcastami. A już bliżej bezpieczeństwa, takie twory jak Cyber Security Sauna, The Secure Developer i kilka innych też się znajdzie. Takim wybitnym – ja akurat niezbyt za nim przepadam, natomiast myślę, że dla dużej ilości osób jest bardzo fajny, to Darknet Diaries, to jest podcast, który wyjaśnia różnego rodzaju wydarzenia z cyberbezpieczeństwa z przeszłości i opisuje po prostu ich historie.

Robi to w taki ciekawy sposób, jest dobrze zbudowana narracja, dobrze się tego słucha. Mnie osobiście niezbyt dobrze, bo znam te przypadki od strony technicznej, natomiast znam opinie wielu znajomych, którzy nie siedzą w bezpieczeństwie i im się bardzo podoba właśnie Darknet Diaries. Tu więc też polecam każdemu słuchaczowi na przetestowanie i zobaczenie. Być może siądzie, być może nie.

Natomiast jeszcze z takich nietechnicznych podcastów, ale również zagranicznych słucham przede wszystkim The Joe Rogan Experience. Jestem aktywnym i żywym słuchaczem tego podcastu, w dużej mierze dlatego, że bardzo często zapraszani są ludzie, którzy mnie interesują. Osobiście interesuje mnie ich zdanie na ich działki, bo to czasami jest życie, czasami są ich techniczne domeny. Natomiast również polecam ten podcast.

Oczywiście Tim Ferriss Show, Lex Friedman Podcast, The Art of Manliness czy Smart Passive Income. To są dodatki, które też, jeżeli mam trochę więcej czasu, to staram się przesłuchać, staram się być na bieżąco z tymi podcastami.

Z polskich, no to tutaj myślę, że koronne miejsce zajmuje właśnie Porozmawiajmy o IT, głównie dlatego że w zasadzie słuchania polskich podcastów zacząłem od Porozmawiajmy o IT i jest to jednym z jedynych, polskich podcastów, których dalej słucham. Kilka mi przeleciało i końcem końców przesłuchałem to, co mnie interesowało, ale nie zachęciło mnie to do kontynuacji. Natomiast Porozmawiajmy o IT dalej wiernie słucham. Nie wszystkich odcinków, bo też nie wszystkie są dla mnie interesujące, natomiast większość odcinków myślę, że przesłuchałem.

Jeszcze z polskich, zrobię taką małą reklamę trzech innych podcastów, mianowicie polecam Małą Wielką Firmę od Marka Jankowskiego, to myślę, że akurat większość słuchaczy przynajmniej kojarzy, bo to jest dość duży, polski podcast, następnie Biznes w IT Piotrka Buckiego – to jest fajny podcast, natomiast on jest o biznesie, więc nie każdemu musi podejść i takim ostatnim, taką perełką, którą ostatnio znalazłem a bardzo mi się spodobała, to podcast Nowoczesna Sprzedaż i Marketing od Szymona Negacza.

Jeżeli więc ktoś działa w sprzedaży, w marketingu a myślę, że każdy przedsiębiorca w jakimś zakresie działa w tych dwóch polach, to mocno polecam właśnie ten podcast, bo można się dowiedzieć bardzo wielu, bardzo cennych informacji za darmo, więc nie trzeba nikomu płacić za książkę. Szymon się dzieli.

Tutaj się na to pytanie rozwiodłem, natomiast jak sam widzisz słucham podcastów doc dużo i dość żywo. Jeszcze wspomnę na marginesie jak ja to robię – najczęściej staram się łączyć słuchanie podcastów z innymi pracami czy aktywnościami. To znaczy – o ile dla przykładu trudno oglądać film i jechać samochodem albo iść na spacer, to podcast jest tutaj tą świetną formą, gdzie nie ma z tym problemu. 

Podcastów więc słucham jadąc autem, idąc na spacer czy sprzątając w domu. Staram się łączyć te aktywności i dlatego też mam tak dużo czasu na przesłuchanie różnego materiału, więc słuchaczom polecam wypróbowanie tego sposobu, bo ułatwia większe przyswojenie różnorodnego materiału, co końcem końców poprawia naszą wiedzę, nasz światopogląd, a to zawsze tylko plusuje w życiu.

 

Oczywiście. Sypnąłeś podcastami jak z rękawa! Dzięki za te rekomendacje. Cieszę się, że Porozmawiajmy o IT jest też wysoko na tej liście. Dzięki wielkie.

Na początku zapytam cię, o jaką stawkę my tutaj gramy, jeśli chodzi o bezpieczeństwo aplikacji? Dlaczego to bezpieczeństwo jest tak ważne, dlaczego mówi się.o nim coraz częściej i coraz więcej ostatnio?

 

Na wstępie chciałbym uwypuklić, że nie chciałbym siać paniki, nie o to mi chodzi. Różne środowiska, aplikacje, systemy, różne organizacje mają różne profile ryzyka i związane z nimi modele zagrożeń, więc tutaj nie jest tak, że cokolwiek powiem, można zastosować u siebie. Natomiast patrząc ogólnie na świat, tak to szeroko ujmijmy, to obecnie systemy IT towarzyszą nam praktycznie we wszystkich czynnościach, które wykonujemy w ciągu dnia. I te systemy IT są większe lub mniejsze. Przez system rozumiem tutaj nawet pojedynczą aplikację, najczęściej zbiór aplikacji, które dostarczają jakąś funkcjonalność, nazwijmy to biznesową, czyli po prostu pozwalają nam zrobić coś.

Tym czymś mogą być różne rzeczy, dla przykładu oprogramowanie w naszym czajniku pozwala nam lepiej sterować czajnikiem. Oprogramowanie w naszej pralce pomaga nam włączyć i nastawić pranie, żeby się zrobiło z samego rana i po wstaniu możemy sobie już wywiesić.

Idąc dalej – woda w kranie leci i tę wodę też musi coś przepompować. Te stacje korzystają z software’u, prąd mamy, ale żeby go mieć to elektrownia musi nam go jakoś przesłać. Te stacje też korzystają z software’u. Software jest wszędzie. Oczywiście nie jest tak, że cały ten software jest tak samo podatny, to co na początku powiedziałem, natomiast zmierza to wszystko w takim kierunku. Dlatego w mojej ocenie – żeby nie wyszło nazbyt dramatycznie, ale od paru lat przechodzimy ze strefy pomarańczowej do czerwonej.

 

Idąc dalej – woda w kranie leci i tę wodę też musi coś przepompować. Te stacje korzystają z software’u, prąd mamy, ale żeby go mieć to elektrownia musi nam go jakoś przesłać. Te stacje też korzystają z software’u. Software jest wszędzie. Oczywiście nie jest tak, że cały ten software jest tak samo podatny, to co na początku powiedziałem, natomiast zmierza to wszystko w takim kierunku. Dlatego w mojej ocenie – żeby nie wyszło nazbyt dramatycznie, ale od paru lat przechodzimy ze strefy pomarańczowej do czerwonej.

 

Odpowiadając konkretnie na Twoje pytanie, o jaką stawkę gramy, ta stawka zmienia się po trochu w takie być albo nie być. Co też widać pod kątem regulacji. Nie trzeba wspominać o RODO, bo dotyczy czegoś innego – dotyczy prywatności, ale być może nie każdy jest świadomy, natomiast my w Unii Europejskiej mamy już regulację odnośnie cyberbezpieczeństwa. 

U nas to jest KSC, która definiuje, że podmioty z branży krytycznej- właśnie dla przykładu te, które wymieniłem: dostawy wody, prądu, linie kolejowe, samoloty – generalnie wszystkie krytyczne dla działania państwa, dla działania infrastruktury. Te elementy muszą być poddane jakiemuś nie tyle testowi, ile podglądowi od strony bezpieczeństwa. Tutaj też nie każdy słuchacz kojarzy to to jest Security Operations Center, ale tu akurat odsyłam do odpowiedniego odcinka Porozmawiajmy o IT, bo nie pamiętam kiedy, ale wydaje mi się, że to było dwa albo trzy, może cztery miesiące temu. Był o tym odcinek więc tam każdy słuchacz może sobie słuchać co to jest Security Operations Center, ale w dwóch słowach to jest po prostu monitorowanie tego, co się dzieje u nas w sieci, co się dzieje w komputerach.

Dla przykładu właśnie w ramach KSC, mamy już wymóg, że ci wszyscy dostawcy usług krytycznych – one są zdefiniowane, muszą mieć coś takiego jak Security Operations Center. Muszą monitorować samych siebie pod kątem bezpieczeństwa, muszą też zgłaszać incydenty. To też pokazuje, że ten ruch, w tę stronę się odbywa cały czas. My w Polsce – nie tylko w Polsce, nawet w Unii Europejskiej jesteśmy trochę do tyłu za tym, co się dzieje w Stanach Zjednoczonych, za tym, co się dzieje w Australii czy w Chinach. Natomiast do nas to dociera. 

I tak jak powiedziałem, zaczynamy wchodzić w nazwijmy to taką strefę być albo nie być. I o ile możemy sobie z tego nie zdawać zawsze sprawy, bo nasza świadomość może być na poziomie takim, że korzystamy sobie z fejsa i tyle, no to jednak większość rzeczy, które po prostu mamy w życiu, które jest nam dostarczane, dzieje się właśnie dzięki software’owi aktualnie. I to bezpieczeństwo software’u, tak jak powiedziałem, przechodzi z takiej strefy pomarańczowej do strefy czerwonej. Oczywiście jeszcze w połączeniu z tzw. Internet of Things, gdzie widać pewien ruch w kierunku podłączania różnego rodzaju sprzętu do internetu, co oczywiście zwiększa i ryzyko, i problemy związane z bezpieczeństwem.

 

Rozumiem. Okej, pokazałeś w taki przejrzysty sposób istotę problemu, ale też pewnie jakoś nie minę się mocno z rzeczywistością, jeżeli powiem, że często w tym procesie wytwarzania oprogramowania, w procesie tworzenia kodu, tworzenia aplikacji o security myśli się na ostatnim etapie, tuż przed release’em, albo nie daj Boże po release’sie.

W twojej opinii w jakim stopniu programiści i product managerowie, którzy bezpośrednio z programistami pracują, są odpowiedzialni za zapewnienie bezpieczeństwa docelowego tej aplikacji? Jak to też wygląda w praktyce, bo możemy sobie teoretyzować, że powinni być, ale jestem ciekawy, jak z twoich obserwacji wynika w praktyce na ile faktycznie te role są zaangażowane w zapewnienie bezpieczeństwa?

 

Tutaj najpierw odniosę się do tej pierwszej części, mianowicie niestety tak jest, że o tym bezpieczeństwie myśli się trochę pod koniec całego procesu twórczego, a nie na tych początkowych fazach. Co się zmienia? Nie chciałbym oczywiście przekłamywać sytuacji, więc to się zmienia powoli. Na Zachodzie ta zmiana jest już dość mocno widoczna, w Polsce zaczyna być widoczna chęć zmiany, to znaczy zaczyna być budowana świadomość tego, że bezpieczeństwo powinno się dziać na różnych etapach procesu wytwórczego po to, żeby po pierwsze zapewnić jak najwyższy poziom bezpieczeństwa, oczywiście taki, który sobie ustalimy i który jesteśmy w stanie zaakceptować, ale też, żeby zmniejszyć koszty.

Bo jednak jeżeli o bezpieczeństwie będziemy myśleć w fazie designu, dla przykładu przez modelowanie zagrożeń, no to takie ćwiczenie pozwoli nam wyłapać różne problemy już właśnie na etapie designu. Czyli nie popełnimy błędów, które moglibyśmy popełnić, gdybyśmy tego nie zrobili. To jest jeden z przykładów. To bezpieczeństwo przesuwa się w lewo, w tzw. shift left i ono w każdej z faz – zależy oczywiście jaki mamy proces wytwórczy, ale w każdej z faz, tych początkowych, przed release’em, ma jakieś kontrole, które możemy uruchomić, które możemy wprowadzić w nasz proces wytwórczy, które końcem końców mają nam zapewnić wyższy poziom bezpieczeństwa, ale też oczywiście ze strony biznesowej obniżyć koszt, jakim jest bezpieczeństwo.

 

Bo jednak jeżeli o bezpieczeństwie będziemy myśleć w fazie designu, dla przykładu przez modelowanie zagrożeń, no to takie ćwiczenie pozwoli nam wyłapać różne problemy już właśnie na etapie designu. Czyli nie popełnimy błędów, które moglibyśmy popełnić, gdybyśmy tego nie zrobili. To jest jeden z przykładów. 

 

Jeżeli wyłapiemy coś wcześniej, to usunięcie problemu kosztuje nas mniej. Zapytałeś konkretnie o programistów i managerów, to znaczy, w jakim stopniu oni są odpowiedzialni za bezpieczeństwo – w zasadzie od managerów, nawet nie tyle managerów, w ogóle od biznesu wydaje mi się, że jedyne czego można wymagać to po prostu świadomości, że pewne kwestie powinny zostać dopięte, to już od programisty, czyli osoby technicznej, więc może rozszerzmy to po prostu od ludzi technicznych w procesie wytwórczym można wymagać już jakiejś głębszej wiedzy na temat typowych problemów bezpieczeństwa występujących w technologii, z której dana firma korzysta. Czyli jeżeli mamy na przykład programistów javowych, no to moglibyśmy od nich wymagać tego, żeby kojarzyli jakie są problemy bezpieczeństwa w typowych aplikacjach javowych.

Tutaj też mówię „wymagać” – dobrze by było. Na wymagania jeszcze, powiedzmy, przyjdzie czas, natomiast wydaje mi się, że już teraz powinniśmy przynajmniej oczekiwać, że programista pewną wiedzę na temat bezpieczeństwa po prostu posiada. Niestety to się trochę rozmija z rzeczywistością, bo jednak jeżeli ktoś wychodzi prosto z uczelni, to poziom uczelni w naszym kraju pod kątem bezpieczeństwa aplikacji pozostawia wiele do życzenia, tak dyplomatycznie to ujmę. Natomiast jak już taki człowiek wyjdzie z tej uczelni, wejdzie w świat IT, zacznie pracować, zacznie wytwarzać kod, to z moich obserwacji wynika, że po kilku latach na poziomie mida, seniora ta świadomość już często po prostu jest. I tutaj zaczynamy mieć trochę inny problem, to znaczy programista zdaje sobie sprawę, że pewne problemy bezpieczeństwa mogą wystąpić, ale biznes jeszcze nie ma tak wysokiej świadomości w tej kwestii, że faktycznie rozpoznanie i wyprowadzenie tych problemów już na poziomie myślenia o jakimś rozwiązaniu informatycznym będzie tańszy, będzie bardziej optymalny.

I wtedy to biznes staje się takim, nazwijmy to, blokerem. Sam byłem w procesie wytwórczym, sam byłem programistą, więc wiem, że na koniec dnia dla biznesu liczy się dowiezienie funkcjonalności, a nie bezpieczeństwo. Zdaję sobie z tego sprawę. Nie chciałbym demonizować ani programistów, ani też biznesu – po prostu idziemy w dobrym kierunku, jeszcze tam nie jesteśmy, myślę, że prędzej czy później będziemy. Tak jak wspomniałeś. To bezpieczeństwo cały czas gdzieś tam zaczyna być bardziej żywym tematem w światku IT i wydaje mi się, że zmierzamy w dobrym kierunku.

Zastanawiam się, czy to nie jest przypadkiem trochę jak z pisaniem testów, które kiedyś były kosztem, stały po stronie kosztów, dopiero z biegiem czasu, z biegiem nabywania jakiejś świadomości zrozumieliśmy, że możemy czerpać z nich realną wartość i że mogą nam się przysłużyć.

 

Czy podobnie też nie jest na przykład z tematem bezpieczeństwa? Czy dopiero zaczniemy zauważać albo zauważamy powoli wagę, istotność zadbania tego obszaru?

Zmierzam tym pytaniem do tego, żeby spytać, czego obecnie według ciebie brakuje deweloperom, aby włączyć temat security do procesu wytwórczego. Czy to jest edukacja, czy to jest może brak presji odgórnej? Czy to jest jeszcze może niska świadomość? Jak ty to oceniasz?

 

Musielibyśmy to podzielić na rodzaje programistów. Jeżeli weźmiemy wszystkich i wrzucimy do jednego worka, to wydaje mi się, że świadomość zespołów wytwórczych – a zespół wytwórczy często jest złożony z programistów różnego poziomu, czyli i seniorów, i midów, i juniorów, to jeżeli wzięlibyśmy świadomość zespołów wytwórczych, to wydaje mi się, że jest na poziomie całkiem okej. To znaczy – ludzie z mojego doświadczenia kojarzą co to jest TOP 10, nie wszyscy kojarzą Application Security Verification Standard, o którym pewnie jeszcze uda mi się opowiedzieć w tym podcaście, bo to jest świetny temat, ale żeby odpowiedzieć teraz na to pytanie, to o TOP 10 większość programistów zdaje sobie sprawę, że takie coś istnieje. Natomiast już o SVS nie każdy, ale też nie jest ta świadomość na poziomie zerowym.

Natomiast jeżeli już wejdziemy do edukacji i wymogów z góry, czyli nazwijmy tych wymogów biznesu, no to sytuacja wygląda trochę mniej różowo. Z kilku względów – też nie chcę do końca wchodzić w jakieś detale, ale po pierwsze. Pod kątem edukacji – w zasadzie dużo szkoleń dostępnych na rynku, nie tylko polskim, ale polski jest mi najbardziej znany. Na rynku polskim skupia się raczej na bezpieczeństwie z punktu widzenia bezpiecznika, a nie osoby będącej w procesie wytwórczym. Takiej jak programista czy dla przykładu testerzy QA. 

To jest problematyczne, ponieważ często objawia się to omawianiem dużej ilości różnych ataków, ale wtedy brakuje skupienia jak można temu przeciwdziałać. To znaczy – usłyszałem kiedyś takie bardzo ładne porównanie, które wpadło mi w pamięć od razu, mianowicie że szkolenia security pokazują jak wysadzać mosty, a ludzie w procesie wytwórczym, programiści, testerzy, architekci chcą widzieć jak budować bezpieczne mosty. I oczywiście, żeby budować bezpieczne mosty to należy wiedzieć, jak się mosty wysadza. 

Ale – ta wiedza nie jest wystarczająca. Ona jest konieczna, ale niewystarczająca. Musimy więc pójść krok dalej, musimy pokazać, jak można to budować, a nie tylko pokazywać problemy, bo takie pokazywanie problemów albo traktowanie sprawy po łebkach ja często przyrównuję do takiej rady jak „Jeżeli chcesz schudnąć, to jedz mniej”. Ta porada jest prawdziwa, ona będzie działać, tylko jeśli człowiek chce schudnąć, to chce wiedzieć, w jaki sposób to zrobić, w jaki sposób jeść mniej, a nie to, że po prostu powinna jeść mniej. To jest informacja, a nie coś, czego można użyć w praktyce. 

 

Ale – ta wiedza nie jest wystarczająca. Ona jest konieczna, ale niewystarczająca. Musimy więc pójść krok dalej, musimy pokazać, jak można to budować, a nie tylko pokazywać problemy, bo takie pokazywanie problemów albo traktowanie sprawy po łebkach ja często przyrównuję do takiej rady jak „Jeżeli chcesz schudnąć, to jedz mniej”. Ta porada jest prawdziwa, ona będzie działać, tylko jeśli człowiek chce schudnąć, to chce wiedzieć, w jaki sposób to zrobić, w jaki sposób jeść mniej, a nie to, że po prostu powinna jeść mniej. To jest informacja, a nie coś, czego można użyć w praktyce. 

 

Odnosząc to do edukacji w kontekście bezpieczeństwa, szkolenia raczej największą wartość mają wtedy, kiedy pokazują jak budować ten bezpieczny most, jak budować bezpieczne oprogramowanie, a nie tylko jak je wysadzać. Nie mówię o tym, że trzeba siedzieć z deweloperami i pisać w ID bezpieczny kod, natomiast po każdym jakimś pokazanym ataku powinno być większe skupienie na to, jak można mu przeciwdziałać, co można zrobić, żeby zastopować taki atak, wyprowadzić podatność – a nie tylko „Tu mamy podatność, pokażemy, jak ją wyexploitować, a potem idziemy do kolejnej. 

To jest dobre, żeby zbudować świadomość, ale ten drugi krok, czyli edukacja, wydaje mi się, że powinna być czymś szerszym. Natomiast wracając do wymogów z góry, czyli raczej do biznesu, no to tak jak wcześniej powiedziałem, to się powoli zmienia, natomiast biznes musi być świadomy wagi bezpieczeństwa i znaleźć zasoby, aby je zapewnić na odpowiednim poziomie. Często jest tak, że programiści mogą sobie zdawać sprawę z czegoś, co jest problematyczne, ale jeżeli nie mają odpowiednich środków, no to nie będą w stanie nic z tym zrobić. A nawet mogą po prostu zwrócić się do biznesu i powiedzieć, że będzie problem, a biznes może powiedzieć, że akceptuje to ryzyko. Tylko że taka odpowiedź jest poprawna, jeżeli mamy odpowiednią analizę ryzyka, z czym też jest problem. Jeżeli więc biznes nieodpowiednio analizuje ryzyku albo w ogóle i po prostu się na wszystko zgadza, no to wiemy, że to prowadzi do problemów. Wiemy, że to prowadzi do problemów, bo tutaj dobrym porównaniem jest po prostu dług techniczny. W momencie, kiedy biznes zdaje sobie sprawę z powagi długu technicznego, to możemy coś z nim robić. Jeżeli nie, to będzie rósł do momentu, kiedy jakakolwiek zmiana w systemie będzie tak kosztowna, że każdy będzie się łapał za głowę. 

Czegoś takiego byśmy nie chcieli w bezpieczeństwie analogicznym. 

 

Poruszyłeś tutaj istotną kwestię współpracy różnych osób, różnych ról w firmie. O ile promowanie działów technicznych jako nerdów zamkniętych w piwnicy myślę, że możemy sobie włożyć pomiędzy bajki, o tyle ja jeszcze dobrze pamiętam takie czasy, kiedy programiści i administratorzy, czy też ogólnie osoby zajmujące się bezpieczeństwem tworzyły trzy niezależne działy, niezależne obozy z osobnymi celami, działającymi zupełnie odrębnie. Później mieliśmy do czynienia z filozofią DevOps, która powiedzmy, jakoś tam mocno zbliżyła przynajmniej tych programistów i administratorów, ale mówi się też ostatnio o czymś takim, co nazywa się DevSecOps. Dlatego chcę też zapytać, jak to podejście wpasowuje się w nowoczesne zespoły i czym jest, jeśli byś mógł powiedzieć kilka słów? 

 

Dobra! O DevSecOpsie można powiedzieć, że dość dużo rozmawiam. Tak jak DevOps w zasadzie składa się na zmianę mindsetu odnośnie do wytwarzania i utrzymywania oprogramowania, które są bardziej widziane od tej strony samej monety, czyli nie jako dwa osobne silosy, tylko jeżeli piszemy software, to w końcu chcemy go utrzymywać. A utrzymywanie software’u jest też w jakimś stopniu wytwarzaniem go. Nazwijmy to takim podziałem logicznym. 

Na marginesie chciałbym zaznaczyć, że zmiany i DevOpsowe i DevSecOpsowe, o którym zaraz powiem, możliwe są w dużej mierze właśnie dzięki chmurze, która napędziła automatyzację. 

Tak jak ja widzę historię stojącą za DevOpsem, DevSecOpsem, to właśnie ten kawałek, ten obszar bardzo rzuca mi się w oczy. Mianowicie wzrost chmury, która napędziła automatyzację, a automatyzacja można powiedzieć pozwoliła osobom wcześniej działającym tylko w wytwórstwie, tylko w pisaniu oprogramowania, pozwoliła im też tylko niejako pisanie infrastruktury jako kawałek kodu. Jeżeli mamy automatycznie stawianą infrastrukturę w chmurze, to można popatrzeć, że koniec końców infrastruktura jest kodem. Bardzo podobnie jest właśnie w DevSecOpsie. Często mówię, że składa się on na dwa główne filary – na kulturę i automatyzację. O ile automatyzacja jest bardzo podobna do tej monety, o której mówiłem w DevOpsie, jeżeli mamy różnego rodzaju narzędzia to automatyzując je te narzędzia stają się pewnego rodzaju kodem. Mając kod, to dość naturalne, że programista nagle zaczyna widzieć to jako kawałek swojej odpowiedzialności. Bo skoro jest programistą, to tutaj ma kawałek narzędzia, które w zasadzie może okodować, to w zasadzie robi to samo, tylko po prostu na czymś innym. Nie robi tego w jakimś frameworku, tylko oskeptowuje jakieś narzędzia. Natomiast od jednego do drugiego jest już bardzo blisko. 

Pod kątem kultury – i to też łączy się z tym, co powiedziałem przed chwilą – no właśnie, jeżeli mamy programistów, którzy nagle zaczynają widzieć bezpieczeństwo jako kawałek ich własnej odpowiedzialności, jeżeli mamy testerów QA, którzy nagle zaczynają widzieć bezpieczeństwo jako coś, co „W zasadzie jakieś proste testy bezpieczeństwa mógłbym przeprowadzić”, no to ci ludzie w dłuższym procesie zaczynają się bardziej identyfikować z problemami bezpieczeństwa, czyli zaczynają nam dawać taką odpowiedzialność. To też idzie trochę w drugą stronę, mianowicie że bezpieczniacy obecnie zaczynają często do jakiejś roli w procesie wytwórczym i przechodzą niejako do specjalizacji, gdzie zajmują się bezpieczeństwem. I taka osoba naturalnie nawet inaczej będzie patrzyła na bezpieczeństwo, niż osoba, która tak jak było 15, 20 lat temu, która nigdy nie wytwarzała software’u, była typowym bezpiecznikiem. Weszła w IT, tym się zajmuje i tym ma zamiar się zajmować przez kolejnych naście lat. To wszystko więc się łączy i dzięki temu mamy po pierwsze DevOps, to samo tylko w odniesieniu do utrzymania oprogramowania i DevSecOps, czyli w budowaniu tego bezpieczeństwa w DevOps. Jeżeli je wbudowujemy no to musimy zacząć patrzeć bardziej jako na naszą odpowiedzialność i oczywiście musimy automatyzować. 

Widzę tak DevSecOps, oczywiście ten mój pogląd cały czas się rozrasta, to znaczy aktywnie czytam, aktywnie poznaję historię, aktywnie uczestniczę też w dyskusjach, więc to nie jest tak, że mój pogląd na tę sprawę jest jedyny słuszny i nie ma żadnego innego, a ja mam to zapisane w kamieniu. To się może zmienić. Obecnie moje zrozumienie tego procesu jest właśnie na tym poziomie. 

 

Niezależnie od tego, jaką odmianę DevOps czy jakie rozszerzenie sobie nie weźmiemy, to można powiedzieć, że istotna jest ta komunikacja. Gdy tak sobie spoglądasz, wcześniej też miałeś okazję uczestniczyć w procesie wytwarzania oprogramowania, gdy spoglądasz jak inni to robią, to czy widzisz, że są jakieś braki w komunikacji, jeśli chodzi o bezpieczeństwo? Albo które role powinny się ściślej komunikować, jeśli chodzi o bezpieczeństwo, a nie robią tego na odpowiednio wysokim poziomie? 

 

W zasadzie to pytanie jest dość mocno połączone z tym poprzednim i pewne wątki, o których powiedziałem przed chwilą mogły być nawet tutaj po prostu wplecione, bez żadnego przetwarzania. Na pewno w bezpieczeństwie można teraz zauważyć złą komunikację lub nawet jej całkowity brak i ten brak może już trochę jest trudniej zauważalny, to znaczy występuje tylko w bardzo dużych podmiotach, które mają długą historię, czyli po prostu dość powoli wchodzą w digitalizację albo w dość małych podmiotach, które po prostu być może niekoniecznie wyciągają tak dużo wartości z całego bezpieczeństwa. Natomiast komunikacja najczęściej pozostawia wiele do życzenia i można byłoby coś pod tym kątem naprawić i w moim odczuciu jest to jeden z głównych problemów bezpieczeństwa. Czyli właśnie zła komunikacja z różnymi częściami organizacji, nie tylko z programistami, biznesem. 

Jeżeli weźmiemy sobie taki klasyczny przykład bezpiecznika, no to taka osoba często przychodzi pod koniec procesu wytwórczego, ma jakieś własne podatności, które znalazła i wieszczy wszem i wobec koniec świata z powodu tych podatności, które znalazła. To brzmi bardziej jak taki bloker, bo to jest typowy bloker. I bezpieczeństwo właśnie tak jest widziane, jako typowy bloker dla wytwarzania a końcem końców dla biznesu liczy się tworzenie nowej wartości, robienie biznesu, zarabianie pieniędzy. Jeżeli przychodzi bezpiecznik i krzyczy, mówi, że tak nie można, bo to i tamto, to w pewnym momencie przestanie być zapraszany na spotkania. I nota bene, jeżeli ktoś przeczytał The Phoenix Project to pewnie się teraz uśmiechnie, bo to tak tam wyglądało. Świetna książka, polecam wszystkim. Jeżeli słuchacze jeszcze jej nie czytali, to polecam zrobić to jak najszybciej. Bardzo dobra książka! 

 

Jeżeli weźmiemy sobie taki klasyczny przykład bezpiecznika, no to taka osoba często przychodzi pod koniec procesu wytwórczego, ma jakieś własne podatności, które znalazła i wieszczy wszem i wobec koniec świata z powodu tych podatności, które znalazła. To brzmi bardziej jak taki bloker, bo to jest typowy bloker. I bezpieczeństwo właśnie tak jest widziane, jako typowy bloker dla wytwarzania a końcem końców dla biznesu liczy się tworzenie nowej wartości, robienie biznesu, zarabianie pieniędzy. 

 

Natomiast takie podejście typowego blokera zamyka drzwi do dalszej dyskusji. Wyklucza bezpieczeństwo z aktywnego udziału w procesie wytwórczym. Opowiem, czemu tak się dzieje. Myślę, że każdy z własnego doświadczenia ma lepszą lub gorszą ocenę tej sytuacji, natomiast w zasadzie to nikt nie lubi wykonać jakiejś pracy, tak jak programiści często mają podczas sprintów czy większych releasów, a potem usłyszeć od tej drugiej strony, którą jest bezpieczeństwo, że coś jest do kitu, tak to kolokwialnie ujmijmy. Jeżeli będziemy tak cały czas słyszeć, to prędzej czy później przestaniemy relację koleżeńską i będziemy minimalizować kontakt z taką jednostką w organizacji. To jest typowy problem komunikacji. 

Sam widziałbym taki optymalny proces wytwórczy, gdzie bezpieczeństwo jest częścią wytwórstwa i to się powoli dzieje na zachodzie, natomiast powoli, a u nas raczkuje. W idealnym procesie wytwórczym, w momencie, kiedy bezpieczeństwo jest częścią, to zarówno programiści, jak i testerzy powinni mieć stały kontakt z bezpiecznikami i oczywiście na odwrót – bezpieczniki też powinny mieć stały kontakt z ludźmi w procesie wytwórczym, tak by wszyscy czuli się częścią większej całości, która ma wspólny cel. 

Jeżeli mamy organizację, to my mamy jakiś cel. I celem nie jest znalezienie podatności, nie jest eksploitacja krytycznej podatności. Celem jest wypuszczenie produktu, który ma określony poziom jakości –  tym bezpieczeństwa, bo bezpieczeństwo to jest odnoga jakości. To jest celem nadrzędnym organizacji, więc pomimo tego, że wewnątrz organizacji możemy być podzieleni na pewne grupy, bo nie da się zarządzać bardzo dużą grupą naraz, to naszym wspólnym celem – tych wszystkich grup – jest rozwiązywanie pewnych problemów biznesowych, dostarczanie systemów IT, aplikacji, które pomagają w rozwiązywaniu tych problemów biznesowych i to jest nasz cel nadrzędny. I powinniśmy to robić na jak najlepszym poziomie jakości, żeby było jak najbardziej bezpieczne, ale nie – to jest jak ten cytat, coś musi być proste, ale nie za proste. I tak samo jest z bezpieczeństwem. Coś musi być bezpieczne, a nie musi być za bezpieczne. To znaczy – nic nigdy nie będzie idealnie bezpieczne. 

Z tym powinniśmy się pogodzić i powinniśmy po prostu wybierać spójnie te rzeczy, które jesteśmy w stanie rozwiązać, które mają największy impakt i które faktycznie zapewnią nam jakiś poziom systemowy bezpieczeństwa. 

I to jest według mnie taka wizja optymalnego procesu wytwórczego. To się już powoli dzieje, natomiast jeszcze tam nie jesteśmy. Na marginesie chciałbym dodać, że podobne problemy mieli Site Reliability Engineers, SRE. Oni mieli podobne problemy. W momencie, kiedy ta rola powstała, chyba jeszcze 15 lat temu, w Google – mieli podobne problemy, ponieważ reliability jest bardzo zbliżone do bezpieczeństwa, security. Oni te problemy rozwiązali – na przykład komunikacyjne z zespołami wytwórczymi, z biznesem. My, jako działka bezpieczeństwa moglibyśmy uczyć się na ich błędach, na ich rozwiązaniach jak oni sobie poradzili z tym, żeby reliability, czyli pewna właściwość wytwarzanych systemów nie była widziana tylko jako koszt, tylko jako coś, co daje faktyczny zysk biznesowi. Przez co biznes oczywiście wtedy dużo poważniej podchodzi do tego, co mówimy. Bo jeżeli tylko krzyczymy, że świat się zapali, świat się potem nie pali, to nikt nie słucha kogoś, kto krzyczy o wilkach, a jak te wilki faktycznie przyjdą, to będzie problem, bo nikt takiej osoby nie będzie brał na poważnie. 

 

To jest też pewnie sztuka wyborów czy zrezygnowania z czegoś. Myślę, że zgodzisz się ze mną, że niezależnie ile czasu byśmy poświęcili na zadbanie o bezpieczeństwo na tym etapie wytwórczym to i tak znajdą się jakieś podatności. Tak samo, jak znajdują się wagi i to jest nie do uniknięcia. W związku z tym porozmawiajmy chwilę o tych grzeszkach. Jakie błędy najczęściej popełniają programiści w kontekście bezpieczeństwa, jakie obszary nie są przez nich zadbane, o czym zapominają?

 

Tutaj akurat tak mocno się nie rozgadam, bo w zasadzie takim sztandarowym dokumentem opisującym typowe błędy bezpieczeństwa – nazwijmy to typowe błędy bezpieczeństwa, bo w samym dokumencie opisują to jako „ryzyka”. To nie do końca są ryzyka – albo inaczej. To zależy od tego, jak sobie ryzyko zdefiniujemy. 

Natomiast w klasycznym sensie to nie są ryzyka. To są raczej zagrożenia. Ale mówię o dokumencie, o OWASP TOP 10. Pokazuje on 10 najbardziej rozpowszechnionych zagrożeń, które dotyczą web aplikacji. Nie wszystkie są tak samo dokładne, to znaczy jest pewne pomieszanie poziomów abstrakcji, bo niektóre z tych problemów są pewnymi bardzo szerokimi klasami problemów, a inne są dość mocno techniczne i w zasadzie zamykają się w konkretnych przypadkach, więc nie jest to narzędzie idealne, ale jest bardzo dobre na to, żeby wyrobić sobie podstawowe zrozumienie, podstawową świadomość na temat problemów związanych z bezpieczeństwem w web aplikacjach. 

Chciałem dodać ważną uwagę, że TOP 10 jest ruchomy, więc ta lista się zmienia. Jest co kilka lat aktualizowana – dużo osób nie zdaje sobie z tego sprawy, natomiast TOP 10 zmienia się w czasie. Aktualizowany jest najczęściej co 3-4 lata, co ma w zasadzie sens, bo pewne klasy podatności umierają, a inne się rodzą wraz ze wzrostem pewnych technologii. To trzeba mieć na uwadze, tę ruchomość. 

Najnowsza lista jest z 2017 roku, czyli jest już dość stara i prawdopodobnie pod koniec tego roku, a najprawdopodobniej w przyszłym powstanie nowa lista. Ona już jest w trakcie tworzenia, więc będziemy mieć nową listę OWASP TOP 10, która będzie definiować nowe, aktualne problemy z bezpieczeństwem. Natomiast jeszcze, żeby Cię nie zbywać tylko OWASP TOP 10, to możemy popatrzeć na sprawę z takiego bardzo wysokiego poziomu rozdzielczości. Jeżeli patrzylibyśmy na to w ten sposób, to w moim odczuciu można wyodrębnić dwa rodzaje, dwa zapachy błędów. Po pierwsze, nadmierne zaufanie do danych wejściowych i tutaj, o ile się nie mylę, to chyba 4 z 10 klas podatności z OWASP TOP 10 dotyczą właśnie niebezpiecznej obsługi danych wejściowych. wtedy na pewno. 

Drugim zapachem w kodzie jest pojawienie się syndromu not invented here – czyli coś, co powoduje, że programiści wymyślają koło na nowo, zamiast użyć dostępnych rozwiązań. Tutaj dobrym przykładem może być uwierzytelnianie czy kryptografia. Jeżeli możemy skorzystać z ogólnodostępnych bibliotek, które zapewniają nam pewne mechanizmy, no to nie piszmy ich od nowa, chyba że mamy naprawdę mocny business case, czemu powinniśmy to robić, bo implementacja różnego rodzaju mechanizmów zwiększa po prostu prawdopodobieństwo popełnienia błędu. Im więcej kodu piszemy, tym więcej błędów możemy popełnić. Jeżeli więc sami musimy zakodować uwierzytelnianie, no to statyscznie popełnimy więcej błędów niż gdybyśmy nie musieli tego robić. A o kryptografii nie będę nawet rozwijał, bo lepiej nie pisać własnego krypto. 

Krypto, to jest – ludzie zajmujący się tym na co dzień popełniają błędy, co dopiero jeżeli ktoś hobbystycznie czy nawet profesjonalnie musi zakodować coś konkretnego. Tutaj ewidentnie trzeba użyć jakiejś dostępnej biblioteki. Mocno odradzam. 

Nadmierne zaufanie do danych wejściowych i syndrom not invented here, czyli wymyślanie koła na nowo. To są takie dwa smaki w procesie wytwórczym, których najlepiej jest być świadomym. Jeżeli już o nich wiemy, to potem możemy wyłapywać problemy związane z tymi smakami, zapachami, w momencie, kiedy pojawiają się obok nas albo w naszej pracy. Nawet więc nie tylko obok, tylko w naszej. 

 

Najlepszy kod to taki, który nie został napisany. Powiedziałeś trochę o OWASP. To są takie fajne inicjatywy, które mają za zadanie wychwycenie takich najczęściej powtarzanych klas, na przykład podatności. Myślę, że warto tak jak sugerowałeś, się z tym zapoznać. Myślę, że może się to po prostu programistom przydać. 

Czy są jeszcze jakieś inne inicjatywy tego typu, o których warto byłoby powiedzieć? 

 

Tak. OWASP jest dość płodny pod kątem narzędzi, które mają pomóc nie tylko bezpiecznikom, ale przede wszystkim programistom, testerom QA właśnie w bezpieczeństwie. Chciałbym to sprostować konkretnie, czym jest OWASP, bo nie każdy ma pełne zrozumienie. 

OWASP to jest organizacja non profit z siedzibą w USA. OWASP oznacza Open Web Applications Security Project, co końcem końców nie jest już w stu procentach zgodne z prawdą, ponieważ w OWASP-ie można spotkać różnego rodzaju projekty, nie tylko związane z web aplikacjami. Po prostu od tego się wszystko zaczęło i wtedy została stworzona nazwa. Tak zostało „web application”, choć tak naprawdę organizacja ma dużo szerszy zakres działań, bo zajmuje się oczywiście i mobilkami, i desktopowymi. Każdymi aplikacjami, które można wytwarzać i które działają na komputerach. A czy ten komputer to jest nasz serwer czy komórka, końcem końców to są komputery. 

Tak jak powiedziałem – organizacja wytwarza bardzo dużo różnych projektów. Takimi flagowymi – w zasadzie i dla programistów, i dla testerów QA, tak jak powiedziałem wcześniej, czyli OWASP TOP 10 i jak wcześniej wspomniałem, jest świetny do budowania podstawowej świadomości problemów bezpieczeństwa, ale istnieją lepsze narzędzia, jeżeli chcemy już faktycznie zapewniać bezpieczeństwo naszych aplikacji, czy to systematycznie w procesie wytwórczym czy nawet jednorazowo – po prostu istnieją lepsze narzędzia. 

Zaraz o nich wspomnę, natomiast jeszcze będąc przy OWASP TOP 10 chciałbym uwypuklić, że tak samo, jak samo TOP 10 jest zmienne w czasie, to istnieją różne listy TOP 10, więc OWASP ma coś takiego jak TOP 10 API security czy TOP 10 serverless. Jeżeli działamy w nietypowej technologii, czyli na przykład stawiamy aplikacje serverlessowe albo działamy bardzo mocno w API Security. To oczywiście dobrze jest znać tę podstawową wersję OWASP TOP 10 do web aplikacji, natomiast są też dodatkowe narzędzia, które definiują TOP 10 klas podatności, klas zagrożeń dla innych rodzajów aplikacji. To jest dobrze mieć na uwadze. Myślę, że słuchacze nie będą mieć problemu, żeby sobie we własnym zakresie pogooglować i wszystko wyskoczy. Nie ma z tym problemów. 

Natomiast idąc dalej do tych narzędzi, które mają pomóc bardziej skrupulatnie oceniać bezpieczeństwo, no to takim głównym narzędziem jest to o czym wspomniałem wcześniej – application security verification standard, czyli coś, co skraca się do ASVS oraz pochodne mobile application security verification standard, skracany również do MASVS. W zasadzie to są już formalne standardy posiadające zbiór wymagań bezpieczeństwa względem systemu aplikacji. 

O ile ASVS i MASVS jest mocno przydatny dla programistów, bo mając takie wymagania, mając takie kontrolki, które należy zweryfikować w naszej aplikacji na odpowiednim poziomie, bo one mają swoje poziomy, więc ASVS ma trzy poziomy, a MASVS ma dwa poziomy. One się po prostu różnią ilością kontrolek do weryfikacji, więc mając ASVS-a i MASVS-a, to jest przydatne dla programisty. Bo może sobie coś takiego przeczytać, zobaczyć – „Czyli powinienem zweryfikować to, jeżeli powinienem zweryfikować, to powinienem zapewnić, że moja aplikacja pod tym kątem jest bezpieczna”. Natomiast w samych tych standardach nie ma opisu, w jaki sposób to testować. I oczywiście, jeżeli ktoś się zajmie bezpieczeństwem, to nie będzie miał z tym po jakimś czasie problemu. Bo to jest jego praca. 

Natomiast programista czy tester QA za pierwszym czy drugim razem może mieć problem albo może mieć na przykład błędne zrozumienie jak coś należy zweryfikować, więc może zweryfikować to nieodpowiednio. Tutaj wkraczają takie narzędzia, które nazywają się testing guides. I one są zarówno dla web aplikacji, wtedy nazywa się web security testing guides, WSTG, ale są też dla aplikacji mobilnych, mobile applications testing guides. MSTG. 

To są dokumenty, które opisują, w jaki sposób należy weryfikować pewne właściwości systemów pod kątem bezpieczeństwa. Tutaj ten myk jest fajny, dlaczego wspomniałem o tym mówiąc o MSVS i MASVS, dlatego że OWASP testing guides i dla mobilnych, i dla web aplikacji są połączone z tymi standardami do weryfikacji. Jeżeli więc mam ASVS-a, to będziemy mieć jakiś podpunkt w testing guides-ach, jak zweryfikować daną kontrolkę. To jest napewno bardziej przydatne czy to dla programisty, czy dla testera QA myślę, że nawet można powiedzieć, że na wagę złota, bo przejrzenie i wyuczenie się całego takiego dokumentu, oczywiście z czasem, bo nic się nie zrobi w jeden dzień, natomiast przechodzą przez taki dokument wykonując kilka razy taką weryfikację – myślę, że dana osoba bez problemu nauczy się jak weryfikować pewne aspekty bezpieczeństwa, dzięki czemu będzie miała większą wartość samej organizacji,w. której działa i będzie też mądrzejsza. A można powiedzieć, że wiedzy nigdy za dużo! 

Jeszcze wspomnę o jednym narzędziu, natomiast tutaj naprawdę króciutko. Mianowicie jest jeszcze coś takiego jak software assurance maturity model, to jest skracane do SAM i to jest model dojrzałości bezpieczeństwa w procesie wytwórczym. 

To w zasadzie jest takie wysokopoziomowe narzędzie, które służy i do implementacji procesu SDLC w organizacji, ale również do mierzenia stopnia dojrzałości. Pozwala nam nie tylko zaplanować jak moglibyśmy wdrażać bezpieczeństwo w procesie wytwórczym, ale też pozwala nam ocenić jak nam to wypadło i do jakiego poziomu chcemy dobić w różnych obszarach. 

To narzędzie procesowe może nie jest do końca dla programistów czy testerów QA – to znaczy te osoby też skorzystają, jeżeli sobie to narzędzie przerobią, natomiast to już jest taki bardziej organizacyjny tool dla ludzi od strony biznesowej. 

 

Powiedziałeś wcześniej, że bezpieczeństwo aplikacji jest odnogą jakości. Kilka razy napomniałeś o testerach, więc teraz może chwilę porozmawiajmy właśnie o tym zagadnieniu. Czy według Ciebie QA engineer, właśnie popularnie nazywany testerem również jest odpowiedzialny za finalne bezpieczeństwo software’u i w jakim zakresie? Jak może to robić?

 

Najpierw odpowiem na to ostanie pytanie, czyli jakie narzędzia ma do dyspozycji, jak taki QA engineer, inżynier do spraw jakości może to robić. Na przykład tymi narzędziami, o których wcześniej wspomniałem, czyli ASVS-em i testing guides’ami. To są narzędzia procesowe, z którymi w zasadzie polecam zapoznać się każdemu testerowi QA, który oczywiście myśli o specjalizacji w bezpieczeństwie i tylko na tym skorzysta. 

Natomiast jeżeli mielibyśmy rozmawiać o takich narzędziach technicznych – nie procesowych, tylko technicznych, czym się faktycznie klika, no to podstawą jest jakieś proxy, np. OWASP ZAP lub jego komercyjny odpowiednik Burp oraz Kali Linux. To są takie dwa, podstawowe narzędzia. Kali Linux w zasadzie, oczywiście wszystko, co jest w Kalim można sobie postawić samemu, ale czas to pieniądz, dlatego można wziąć Kali Linuxa, tam już są wgrane te narzędzia bezpieczeństwa, więc możemy się po prostu zacząć bawić, nie musimy się niczym przejmować. To są więc narzędzia procesowe i techniczne, które polecam każdemu testerowi QA do pobawienia się. Oczywiście programistom również polecam przynajmniej przez weekend się takim czymś pobawić, natomiast tak jak wcześniej wspominałem, że w zasadzie security jest odnogą quality, to powtarzam to od długiego czasu i to się wiąże z tym, że jeżeli weźmiemy takie zdanie, że każdy system o wysokiej jakości będzie posiadał bezpieczeństwo na wysokim poziomie, no to takie zdanie jest prawdziwe. Bo każdy system o wysokiej jakości będzie posiadał bezpieczeństwo na wysokim poziomie. 

Natomiast zdanie odwrotne nie jest prawdziwe – nie każdy, bezpieczny system będzie systemem, który jest wysokiej jakości. To jasno pokazuje, że bezpieczeństwo zawiera się w jakości, bo każdy produkt dobrej jakości będzie automatycznie bezpieczny. I tak jak wcześniej mówiłem – on nie będzie w 100% bezpieczny, ale wystarczy, że będzie bezpieczny na tyle, na ile my byśmy sobie życzyli. Nie musi być bezpieczniejszy niż to, czego byśmy od niego racjonalnie oczekiwali. Czyli dla przykładu, racjonalnie można oczekiwać, że w momencie, kiedy logujemy się do naszego banku, to tylko my możemy to zrobić i nikt więcej. To jest racjonalne oczekiwanie względem tego systemu. Też nie chodzi mi o to, żeby robić nierealne oczekiwania, które też można sobie zrobić, tylko potem możemy być rozczarowani, bo często koszty nas zjedzą. Natomiast o takie trzeźwe, realne spojrzenie na to, co dany system, co dana aplikacja powinna zapewniać. I w takim wypadku, jeżeli mamy aplikację czy system wysokiej jakości, to on ma również odpowiedni poziom bezpieczeństwa i w moim odczuciu testerzy QA w niedalekiej przyszłości odegrają bardzo dużą rolę w bezpieczeństwie aplikacji. To już widać za granicą, w różnego rodzaju szerokich publikacjach w bezpieczeństwie odnośnie do tego, w jakim kierunku to wszystko idzie. U nas jeszcze tego nie widać, natomiast powoli zaczyna być to zauważalne Albo inaczej – powoli zaczyna być zauważalne, że takie coś zaczyna się dziać. 

 

W zasadzie security jest odnogą quality, to powtarzam to od długiego czasu i to się wiąże z tym, że jeżeli weźmiemy takie zdanie, że każdy system o wysokiej jakości będzie posiadał bezpieczeństwo na wysokim poziomie, no to takie zdanie jest prawdziwe. Bo każdy system o wysokiej jakości będzie posiadał bezpieczeństwo na wysokim poziomie. Natomiast zdanie odwrotne nie jest prawdziwe – nie każdy, bezpieczny system będzie systemem, który jest wysokiej jakości. 

 

Można powiedzieć, że proces się zaczął, teraz tylko idziemy w tym kierunku i zobaczymy, kiedy dojdziemy do tego punktu. 

 

Określiliśmy już, że rola programistów i testerów jest tutaj istotna, jeżeli chodzi o zapewnienie odpowiedniego poziomu bezpieczeństwa aplikacji, ale to najczęściej może nie wystarczyć. Tutaj właśnie wkracza rola bezpiecznika, osoby od bezpieczeństwa. To też najczęściej jest taka rola, którą się opisuje działania w różnym zakresie czy w różnych obszarach. 

Chciałbym Cię zapytać – czym zajmują się osoby od security? Jakie specjalizacje wewnętrznie występują? 

 

To jest dobre pytanie, bo bezpieczeństwo jest bardzo szerokie. Może nie chcę przesadzać – pewnie zdarzają się szersze domeny wiedzy, natomiast bezpieczeństwo jest dość szerokie. Jak typowo mówimy o bezpiecznikach, czy w ogóle o bezpieczeństwie, to o ile wcześniej sobie nie zdefiniujemy, w jakim kontekście mówimy, to możemy mówić o dwóch, zupełnie różnych sprawach pomimo tego, że po prostu mówimy o bezpieczeństwie. 

Wysokopoziomowo bezpieczeństwo można logicznie podzielić na bezpieczeństwo procesowe i operacyjne. Natomiast jeśli poszlibyśmy dalej, to operacyjne można podzielić na bezpieczeństwo organizacji i bezpieczeństwo systemów IT. Teraz nie ma znaczenia, czy my te systemy IT wytwarzamy, czy po prostu korzystamy z jakichś dostarczonych do nas. Mamy jakieś systemy IT w typowych organizacjach i one powinny być bezpieczne. Te granice więc są mocno umowne, pamiętajmy, że to jest taki podział logiczny, natomiast tak to wygląda. 

Moja specjalizacja leży głównie w tym ostatnim obszarze, czyli bezpieczeństwie systemów IT, na które składają się aplikacje i w tym kontekście główne skrzypce grają role takie jak pentesterzy czy inżynierowie bezpieczeństwa. 

Jeżeli cofniemy się o krok wcześniej i porozmawiamy o bezpieczeństwie organizacji, czyli mamy jakąś firmę i chcemy zapewnić bezpieczeństwo w ramach tej firmy, to często bezpieczeństwo aplikacji będzie tylko jakąś jedną domeną bezpieczeństwa ogólnej organizacji, bo organizacja robi różne rzeczy i wszystkie te rzeczy, które dzieją się na komputerach muszą być zabezpieczone. Tutaj więc zaczynamy widzieć to, o czym wspomnieliśmy na samym początku, czyli Security Operations Center, analitycy SOC architekci, ale bardziej architekci od projektowania i budowy, czy to SOC-ów czy właśnie systemów IT, więc to są te role, które w tej części bezpieczeństwa najczęściej można spotkać. Jeżeli pomyślimy i o architektach, i o inżynierach, to tych można spotkać też w tych systemach IT, czyli w budowaniu aplikacji, więc oni znowu. Mówimy o Security Architect, a już mamy dwóch, zupełnie różnych Security Architektów, bo jeżeli ja jestem architektem bezpieczeństwa, ale ja się zajmuję konkretnie bezpieczeństwem architektury aplikacji, a mamy architekta bezpieczeństwa, który zajmuje się architekturą bezpieczeństwa organizacji, czyli w kontekście budowania systemów IT, jak one są połączone, jakie mamy firewalle, systemy bezpieczeństwa w sieci, to z jednej strony brzmi to, jak ta sama rola, a z drugiej strony jest zupełnie inna. To jest to, od czego zacząłem, odpowiedź na to pytanie, mianowicie że jest raz, że szerokie, a dwa, że tak naprawdę nie mamy takiego jednoznacznego określania pewnych ról. Mamy te same nazwy, które w zależności od kontekstu oznaczają zupełnie co innego. 

Ale jeszcze wspomniałem tam wcześniej o bezpieczeństwie procesowym – to jest trochę inna bajka, oczywiście również ważna, natomiast trochę inna. I sądzę, że dla odbiorców podcastu Porozmawiajmy o IT akurat ta bajka będzie trochę mniej ciekawa, bo to jest daleko od technikaliów, a jednak myślę, że większość słuchaczy jest bliżej technikaliów, więc od strony technicznej to są te sprawy, o których wspomniałem. Jest jeszcze właśnie to bezpieczeństwo procesowe, ale to jest trochę inna bajka. 

Nie wiem, czy do końca odpowiedziałem na Twoje pytanie i, czy rozjaśniłem ten temat, bo jak sam widzisz, temat jest trochę zagmatwany.

 

Myślę, że tak, aczkolwiek trochę utrudniłeś mi sprawę, bo chciałem cię zapytać teraz, czy jest jaki zakres umiejętności wspólnych dla różnych ról, które z bezpieczeństwem są związane. Po części już na to odpowiedziałeś, że może tak, może nie – może nie, ponieważ często te role zajmują się, może nie powiem, że skrajnie różnymi rzeczami, bo to jednak jest ta sama domena, ale jednak te podejścia są różne. 

Mimo wszystko jednak zaryzykuję i zapytam cię, czy jest coś takiego, co uważasz, że każda osoba, która w tej domenie pracuje, tą domeną się zajmuje, czy pasjonuje po prostu powinna wiedzieć? Czy taki zakres umiejętności, który powinna posiąść, żeby zacząć pracę w tym obszarze? 

 

Nie chciałbym tutaj jasno się określić, że trzeba albo że ktoś powinien, dlatego że znam ludzi, którzy pewnych umiejętności nie nabyli, a dalej odnoszą sukcesy w bezpieczeństwie w tym kontekście, w którym się zajmują. Natomiast jeżeli mielibyśmy popatrzeć na tę sprawę i powiedzieć co według mnie jest mocno przydatne, to każdy, kto prędzej czy później chce odnieść jakiś większy sukces w bezpieczeństwie powinien zainwestować czas w zrozumienie tego, jak działają komputery i tutaj to brzmi trochę szeroko, natomiast mam konkretnie na myśli to, żeby zrozumieć, jak się programuje w Asemblerze, jak się programuje w C i jak działa Unix. 

To są takie podwaliny zrozumienia wielu innych konceptów – albo inaczej. Wiele konceptów z Computer Science trzeba posiąść, żeby zrozumieć Asemblera, C, Unixa. I w momencie, jeśli ktoś poświęci swój czas na nauczenie się tych obszarów, to nawet jeżeli nie będzie w nich ekspertem, to wiedza wyciągnięta z takiego studiowania – tutaj studiowania używam w takim własnym zakresie – pozwala dużo szybciej pojmować nowe koncepty. Bo w IT, w Computer Science nic nie dzieje się w próżni. Koncepty są nadbudowywane. Dla przykładu więc ja, widząc architekturę mikro serwisów zawsze od razu zapala mi się lampka, że w zasadzie mikro serwisy są jak aplikacje unixowe. To znaczy – zrób jedne mikro serwis, czyli napisz jedną aplikację, rozwiąż jeden konkretny problem, tak jak w aplikacji unixowej i pozwól komunikować się, czyli przesyłać dane pomiędzy aplikacjami, żeby rozwiązywać nowe, bardziej złożone problemy z wykorzystaniem tych cegiełek budulcowych tak jak w mikro serwisach. Weźmy kilka bazowych problemów, rozwiążmy je dobrze, rozwiążmy tylko te konkretne problemy, a następnie połączymy wszystko w jakiś jeden system, który dzięki rozwiązaniu pojedynczych problemów pozwoli nam rozwiązywać różne kombinacje tych problemów. 

I właśnie – jeżeli ktoś jest biegły w Uniksie, faktycznie rozumie jego filozofię, to patrząc na mikro serwisy od razu mu się lampka zapali, że już widziałem gdzieś ten pattern. Tutaj jeszcze polecam każdemu zrozumienie jak działają komputery połączone w sieci, czyli działanie podstawowych protokołów. To już bardziej w momencie, kiedy działam czy to w SOC-u, czy właśnie na poziomie organizacji. To też się przydaje, jak działają komputery w sieci i na zakończenie tego pytania chciałbym jasno wypunktować, że ja widzę bezpieczeństwo bardziej jako specjalizację niż jakąś osobną domenę. To znaczy – zdarzają się wyjątki i sam jestem takim wyjątkiem, natomiast moje zainteresowanie nigdy nie ograniczało się tylko na bezpieczeństwie. To znaczy – mnie interesuje zarówno bezpieczeństwo, jak i szersza inżynieria oprogramowania. Bezpieczeństwo raczej jest pewnego rodzaju specjalizacją i dobrze jest mieć mocny, techniczny background w jakiejś innej domenie, czyli właśnie czy to w inżynierii oprogramowania, czy w administracji sieciami, czyli po prostu w operacjach. 

To nam może tylko pomóc. Brak tego będziemy odczuwać – nie jest nie do pokonania, natomiast będziemy odczuwać brak tych podstaw, ale mając je i idąc w bezpieczeństwo będzie nam dużo, dużo łatwiej. Takie przejście w specjalizację bezpieczeństwa, myślę, że dla ludzi, którzy mają mocny background techniczny w jakimś obszarze będzie po prostu dużo łatwiejszy i też dużo przyjemniejszy, bo będą odkrywać bezpieczeństwo w kontekście tego ich wcześniejszego doświadczenia. 

Będą patrzeć „A to dlatego! A to w ten sposób mógłbym to zrobić!”. To też bardziej pozytywnie działa na samych w procesie nauki, bo jeżeli czegoś się uczymy to jeżeli mamy się czegoś uczyć od zera, to ten proces nigdy nie jest przyjemny. Nauka jest ciężka. Jeżeli ktoś się uczy i dokształca, to ja każdej takiej osobie zawsze przyklaszczę, poklepię ją po plecach, bo nauka zawsze, zawsze jest trudna. Jeżeli ktoś się kształci, to duże propsy! 

 

Sam też zawsze polecam i reklamuję wiedzę o podstawach informatyki, bo wydaje nam się, że taka ogólnie rozumiana dziedzina jak informatyka rozwija się bardzo szybko, bardzo dużo się w niej dzieje, ale tak naprawdę bardzo rzadko zdarzają się obecnie przełomy na tyle istotne, że wcześniej nikt o tym nie pomyślał albo że nie zostało to w jakiś sposób teoretycznie ugryzione w latach 60, 70 czy późniejszych, więc tak jak powiedziałeś – wiele z rzeczy, które nas teraz otaczają, które wydają nam się wynalazkami ostatnich lat, tak naprawdę czerpią z tego, co wcześniej zostało wymyślone, przepracowane, przetestowane, więc to zawsze jest na plus i bardzo dużo może nam rozjaśnić, jeśli mamy podstawy o tych rzeczach, które budują tę dziedzinę. 

Chcę cię zapytać – gdzie taką wiedzę, takie umiejętności związane z obszarem bezpieczeństwa pozyskać? Żeby nie generalizować – jak ty się dokształcasz, jak ty się rozwijasz w tematach branżowych?

 

Odpowiedź na to pytanie nie jest do końca łatwa, ponieważ ja bym rozgraniczył uczenie się od dokształcania. To jest ważne dlatego że ja, jako ekspert domenowy dość sprawnie oceniam sygnał od szumu. Natomiast osoba początkująca nie będzie posiadać tej umiejętności, no bo tę umiejętność po prostu wyrabia się z czasem. Musimy mieć doświadczenie w czymś, żebyśmy wiedzieli co ma jakąś wartość, a co ma mniejszą wartość. Jest różnica od uczenia się bezpieczeństwa a dokształcania się w nim. 

Natomiast ja w zasadzie wszystkim polecam Reddita. Sam przeglądam co się dzieje pod kątem bezpieczeństwa właśnie na tym portalu. Są Slacki OWASP-owe, więc jeżeli ktoś korzysta ze Slacka to może dołączyć i popatrzeć na dyskusję, może też oczywiście zadać pytanie. Oczywiście jedno i drugie medium jest po angielsku. Jest też Twitter, który nie za bardzo jest popularny w Polsce, ale jest świetnym narzędziem, ponieważ możemy sobie sami zdefiniować kogo obserwujemy, czyli możemy poobserwować. Taką dobrą strategią jest obserwacja ludzi, którzy działają w danym obszarze, który nas interesuje. I po prostu patrzenie co oni mówią, co oni polecają. 

Bo ci ludzie, jeżeli mają jakieś doświadczenie, to najczęściej będą polecać ciekawe rzeczy. Nawet jeżeli nie wiemy czemu są ciekawe, to raczej jakaś wartość w nich jest. Bo jak ja coś podaję na Twitterze, to mam ku temu konkretny powód i widzę jakąś wartość. Ona może być dla kogoś innego nie do końca zrozumiała, ale ona jakąś wartość ma. Polecam Twittera, ale oczywiście Twitter też bardziej na zagranicę, czyli lokalnie niezbyt. 

W Polsce mamy Niebezpiecznika, Zaufaną Trzecią stronę, Sekuraka. Problem z tymi wszystkimi portalami jest w zasadzie taki, że w dużej mierze to jest podawanie informacji dalej, więc jeżeli ktoś siedzi na Reddicie czy na innych mediach, to po prostu te informacje wyłapie wcześniej. Ale często zdarzają się oryginale artykuły, które również polecam przeczytać. 

Na przykład: Zaufana Trzecia strona często robi opisy ciekawych przypadków, oczywiście Niebezpiecznik też, więc jedni i drudzy czasami mają oryginalny, bardzo ciekawy artykuł. Jeden z Niebezpiecznika, który teraz przyszedł mi do głowy jest seria artykułów o aplikacji Protego. To jest kontekst nasz lokalny, więc raczej za granicą nikt szeroko pisać nie będzie. Tutaj Niebezpiecznik bardzo dobrze opisał sprawę, więc oczywiście polecam Niebezpiecznika, Zaufaną Trzecią Stronę, Sekuraka. Myślę że większość ludzi kojarzy te portale. Jako wisienkę na torcie, trochę autopromocji, polecę swój własny newsletter, AppSec Monday, gdzie co tydzień wysyłam ciekawe newsy ze świata raczej bezpieczeństwa aplikacji, niż szeroko pojętego cyberbezpieczeństwa, więc jeżeli ktoś interesuje się bezpieczeństwem aplikacji, no to polecam się zapisać. Dostępny pod adresem appsec.pl. Tam można się zapisać i oczywiście, jeśli się nie spodoba, to można się też potem wypisać! 

Natomiast tutaj raczej celuję w bezpieczeństwo aplikacji, czasami podaję trochę inne newsy, jeżeli są bardzo duże, natomiast bezpieczeństwo aplikacji wlatuje co tydzień. Testerzy QA czy programiści, myślę, że znajdą tam sporo ciekawych materiałów dla siebie – zresztą mam dużo testerów QA, programistów, OPsów, CTO, CEO, mam managerów z dużych firm. Ci ludzie znajdują coś tam ciekawego dla siebie, bo jeszcze tam już prawie do półtora roku dalej są! 

 

Mnie przekonałeś i z chęcią się zapiszę! Słuchając tego ile masz do powiedzenia, jestem stuprocentowo przekonany, że jest tam duża wartość i sam się po naszej rozmowie dzisiaj z chęcią zapiszę. 

Teraz chcę cię zapytać jak ogólnie wygląda rynek pracy dla specjalistów zajmujących się bezpieczeństwem? Od czego można byłoby zacząć swoją przygodę zawodową w tym obszarze? 

 

Wracamy tu do tych specjalizacji, co konkretnie kto chce robić. Natomiast moglibyśmy popatrzeć na to w zasadzie z kilku stron. Jeżeli ktoś chce wpadać do SOC-a, co moim zdaniem byłoby w zasadzie najłatwiejsze, bo właśnie to o czym mówiłem – o KSC, które narzuca pewne wymogi powstawania SOC-ów, ale też powstawanie różnych hubów technologicznych dużych organizacji, które sobie robią z Polski dostawcę usług IT, w tym security, więc tego typu ról i pracy jest bardzo dużo, właśnie jako analitycy, operatorzy Security Operations Center. Ta praca może nie jest do końca super i dla każdego, bo często wiąże się z systemem zmianowym, natomiast jeżeli ktoś jest zdeterminowany, żeby po prostu wskoczyć w IT i konkretnie w security, to myślę, że to jest najłatwiejsza droga, bo po prostu jest największe ssanie na te role. 

Oczywiście, jeżeli popatrzymy ogólnie na listingi z ofertami pracy, to znajdziemy też role pentesterów czy często po prostu testowanie web aplikacji czy bezpiecznikowe testowanie web aplikacji. Tych ról też jest dość sporo i od jakiegoś czasu zaczynają się pojawiać role typowo właśnie application security engineering, gdzie chcemy mieć ludzi, którzy zapewniają bezpieczeństwo właśnie w procesie wytwórczym na różnych poziomach. To może być inżynier, to może być architekt, tak jak konkretnie ja się zajmuję – natomiast od jakiegoś czasu również te role się pojawiają, ale oczywiście one trochę dyskryminują względem umiejętności, typu nikt zielony nie wskoczy na architekta, ale już na junior appliactions security engineera może przynajmniej spróbować wystartować. Czy się dostanie czy nie, to zawsze jest kwestia pewnego rodzaju szczęścia, więc tutaj też do wszystkich słuchaczy – jeżeli gdzieś wysłaliście, nie poszło, to się nie zrażajcie. W tym wszystkim jest więcej szczęścia niż rozumu. Po prostu trzeba grać i prędzej czy później, jeżeli będziecie działać, jeżeli będziecie napierać, to dostaniecie się tam gdzie chcieliście. I możecie traktować takie zdarzenie jako pewnego rodzaju trampolinę, czyli jeżeli nie jest to docelowe miejsce, gdzie chcecie być, to można zacząć od Security Operations Center, a później przejść do pentesterki. Nie ma w tym żadnego problemu! 

Ważne tylko, żeby gdzieś sobie narysować pewnego rodzaju wizję tego i co chciałoby się robić, a potem wyznaczyć jakieś punkty kontrolne i zacząć iść w tym kierunku. 

 

Zgadza się. Nic dodać, nic ująć!  Czy w takim podbijaniu rynku pracy może nam pomóc posiadanie jakiegoś certyfikatu czy w tym obszarze certyfikaty są, mają znaczenie, są respektowane przez pracodawców?

 

Wiesz co, jeżeli mówimy o bezpieczeństwie jako o ścieżce kariery, to oczywiście są odpowiednie certyfikaty i są takie, które rynek ceni, na przykład OSCP, CISP, CISA. Są takie, które rynek otwarcie wyśmiewa – na przykład niechlubny CEH. 

Nie jest tak, że ja jakoś mocno odradzam zrobienie CEH-a, bo tak nie jest. Po prostu można się spotkać z szyderczymi komentarzami na temat CEH-a na rynku i trzeba być tego po prostu świadomym. 

Z mojego doświadczenia certyfikaty odgrywają dużo większą rolę w Polsce niż na Zachodzie. W zasadzie i tu i tam certyfikaty potrzebne są głównie do pracy w publicu. W Polsce dla przykładu w przetargach. Tylko że o ile na Zachodzie papierek w zasadzie sam w sobie nie ma większej wartości, czyli jeżeli go potrzebujemy, to fajnie, żebyś go miał, ale w zasadzie jest on nam potrzebny tylko do tego, to jednak u nas ten papierek często ma wartość niejako sam w sobie. Czyli brak posiadania jakiegoś papierka może grać na twoją niekorzyść albo posiadanie jakiegoś papierka może grać na twoją mocną korzyść, bo jest założenie, że jeżeli masz jakiś certyfikat, to już się znasz. 

Dobrym przykładem u nas jest certyfikat OSCP, który w zasadzie w UK bardziej traktowany jest jako entry level, czyli coś, co dobrze jest mieć, wchodząc w branżę, a u nas OSCP jest traktowany jako doświadczenie co najmniej na poziomie mid-level. Co oczywiście jest bzdurą. 

Nie chodzi mi tutaj o hejtowanie OSCP, bo jest to jeden z ciekawszych certyfikatów i same certyfikaty również mają swoje miejsce. Chodzi raczej o to, żeby nie przeceniać papierków, bo na koniec dnia liczy się wiedza i umiejętności. A wiedzę i umiejętności można zdobyć i dowodzić na wiele sposobów. Nie trzeba robić tego przez certyfikaty. Jeżeli – dla przykładu – nie mamy w jaki sposób wyrobić certyfikatu, bo to jest dość kosztowna zabawa, to możemy zacząć od uczestnictwa w programach Bug bounty albo CTF-ach i po prostu spisywać nasze przygody na blogu. 

I takie coś będzie miało równie dużą wartość, jak nie większą niż posiadanie certyfikatu. Nie traktujmy certyfikatów po prostu jako wymówki – jeżeli ktoś nie może sobie pozwolić na zrobienie certyfikatu, bo nie ma na to środków, to nie ma problemu, są inne drogi. Głównym celem powinno być po pierwsze zdobycie wiedzy, a po drugie dokumentacja tej wiedzy, żeby móc się pochwalić przyszłemu pracodawcy. I w zasadzie tyle w tym temacie. 

 

Myślę, że podobnie to wygląda jak w domenie programistycznej. Też certyfikaty mogą pomóc, nie są wymagane, natomiast dokumentacja chociażby poprzez bloga swoich dokonań jest zawsze mile widziana. 

Też prowadzisz bloga – poprzez tę informację myślę, że dałeś namiastkę tego, że lubisz się dzielić wiedza, ale tez obserwując twoje działania, wystąpienia na konferencjach, podcast, który prowadzisz, webinary, szkolenia, mnóstwo tego jest. Widzę, że tą wiedzą uwielbiasz się dzielić. 

Powiedz proszę parę słów o tym aspekcie swojej działalności. Po co to robisz? Jak to wygląda?

 

To jest trochę tak jak wspomniałem na początku tej dość długiej, ale bardzo miłej rozmowy! Bardzo dobrze mi się z tobą rozmawia. Technologia a w zasadzie w technologii bezpieczeństwo czy inżynier oprogramowania to w zasadzie jest moja pasja od wczesnych lat. 

Czasami ludzie, szukając celu w życiu zadają sobie takie pytanie – ono jest trochę takie cliché: „Co byś robił, gdybyś nie musiał zarabiać pieniędzy?”. Mam to szczęście, że znam na to pytanie odpowiedź – dokładnie to, co robię teraz. Zajmowałbym się bezpieczeństwem, oprogramowaniem i zajmowałbym się też właśnie dzieleniem się tą wiedzą z innymi. 

To trochę odpowiada po co to robię. To też można połączyć z tym, że ten software zaczyna być mocno krytyczny i to przestaje być zabawa, a zaczyna być czymś, co jest dość poważne. O ile x lat temu mogliśmy sobie pozwolić na ignorowanie pewnych tematów, no to w chwili obecnej raczej już nie możemy. Skoro nie możemy, to trzeba budować tę świadomość, tak jak wcześniej mówiłem biznes nie ma świadomości. Gdzieś to się buduje, ale jeszcze nie ma na odpowiednim poziomie świadomości. Chciałbym t wiadomość w jakimś zakresie, na tyle na ile mogę, powiększyć. Oczywiście w ramach tych mam różnego rodzaju inne projekty, nie każdy słuchacz może wiedzieć – mam firmę, tak jak wspomniałeś, prowadzę szkolenia, staram się robić webinary, mam ten swój mailing, na który wysyłam różnego rodzaju ciekawe informacje, które udało mi się zebrać z zakresu bezpieczeństwa aplikacji.

Mam też kurs online – ale to wszystko robię w tym celu, żeby jak najwięcej osób zdobyło tę wiedzę, czy to na poziomie świadomości czy już na poziomie konkretnych, technicznych umiejętności, po to, żeby docelowo horyzoncie x lat sytuacja bezpieczeństwa w aplikacji w naszym kraju, a być może za granicą, wyglądała lepiej niż wygląda teraz i żebym ja sam sobie mógł powiedzieć, że dołożyłem większą lub mniejszą cegiełkę właśnie do tego podwyższenia poziomu bezpieczeństwa. 

Trochę więc taka idealistyczna wizja, ale z tym idealizmem to walczę od lat nastoletnich, ale do tej pory nie udało mi się go stłamsić. 

 

Jasne. Bardzo lubię rozmawiać z ludźmi, którzy mają też taką misję życiową i w tym, co mówisz zdecydowanie słychać, że coś takiego jest. Myślę, że idziemy na rekordową długość podcastu, ale to w żaden sposób nie jest zarzut. Wręcz przeciwnie – myślę że to, co powiedziałeś może przyczynić się do tego, że więcej osób będzie miało jakieś lepsze rozumienie tego aspektu bezpieczeństwa aplikacji. I dlatego bardzo ci dziękuję za tę rozmowę, dziękuję za to, że uczuliłeś słuchaczy na te różne aspekty bezpośrednio lub pośrednio związane z bezpieczeństwem aplikacji właśnie i na koniec powiedz proszę jeszcze, gdzie cię można znaleźć w internecie? W jaki sposób się z tobą skontaktować, gdyby ktoś chciał poszerzyć swoją wiedzę, być może zadać ci jeszcze jakieś pytanie? 

 

Przede wszystkim ja tobie dziękuję za możliwość wystąpienia w Porozmawiajmy o IT, można powiedzieć, że achievement unlocked. Bardzo mi z tego powodu miło. 

Gdzie można mnie znaleźć? Myślę, że każdy sobie poradzi, żeby po prostu wpisać Andrzej Dyjak w Google i od razu będzie miał wyniki. Oczywiście jestem na LinkedInie i zachęcam gorąco wszystkich do zapraszania mnie do grona znajomych, ja tutaj nie zachowuję się jakoś elitarnie. Im większe grono znajomych, tym lepiej. Tylko na tym wszystkim możemy skorzystać. Na LinkedInie, spokojnie każdy, kto chce może mnie zapraszać do znajomych, będzie mi bardzo miło. Napisz „cześć”, napisz gdzie usłyszałeś o mnie i może się razem pośmiejemy. 

Natomiast mam swoją stronę internetową dyjak.me, tam są wszystkie punkty kontaktowe. Jeżeli ktoś chciałby zadać mi jakieś pytanie, jeżeli chciałby, żebym uściślił jakąś odpowiedź, która padła w tym podcaście, to oczywiście może napisać do mnie na maila, więc strona to jest dyjak.me, natomiast e-mail jest w zasadzie w tej domenie – andrzej@dyjak.me. To jest mój oficjalny e-mail, więc można do mnie pisać. Nie zawsze odpowiadam super szybko, natomiast odpowiadam na wszystkie maile. 

Jeżeli ktoś wyśle do mnie maila i nie ma odpowiedzi przez parę dni, to nie trzeba panikować – ja na pewno maila widziałem i na niego odpowiem, natomiast czasami mam taki natłok pracy, że nie jestem w stanie – czasami jestem tak zmęczony, że mi się po prostu, najnormalniej w świecie wieczorem nie chce. 

Każdy jest człowiekiem, ja również. 

Jest jeszcze jeden adres internetowy, który można sobie wbić. Mianowicie andrzejdyjak.com – to jest taki zestaw różnych linków do różnych miejsc, których jestem w internecie, więc można po prostu skorzystać z tego. Tam będzie, dla przykładu, link do dokumentu, który opublikowałem jeszcze w tym roku w kwietniu, mianowicie: DevSecOps – Podstawa automatyzacji. Też polecam każdemu programiście, każdemu testerowi QA, każdemu Opsowi, gdzie opisuję 5 sposobów, jak zabezpieczyć oprogramowanie w procesie wytwórczym w modelu DevSecOpsowym, czyli o pewnych problemach i narzędziach, które rozwiązują te problemy. Tam będzie link. Oczywiście tez można sobie pogooglać albo można napisać do mnie maila czy wiadomość na LinkedInie i też odpowiem z linkiem. 

Zapraszam wszystkich do kontaktu, wszystkim odpowiem, bo po prostu lubię też wymieniać się i doświadczeniem, i spojrzeniem, i poznawać nowych ludzi, bo według mnie wszystko kręci się wokół technologii, ale przede wszystkim wokół społeczności. 

O ile dobrze pamiętam, to ty Krzysztofie jesteś związany z Ruby on Rails, prawda? 

 

Tak, można powiedzieć, aczkolwiek już od pewnego czasu nie praktykuję. Natomiast faktycznie – najszersze, najdłuższe moje doświadczenie zawodowe jest związane z tą technologią. 

 

No właśnie. Też pracując jako programista, mając taki krótki, półtoraroczny epizod czysto programistyczny, no to ja byłem właśnie najwięcej związany z Ruby on Rails i mi najbardziej się podobało połączenie nie tylko technologii, ale właśnie tej społeczności. Społeczności, która wyrosła wokół tej technologii i jest dość niespotykana. Są różne technologie, które same w sobie są fajne, a koniec końców społeczność nie tyle jest niefajna – po prostu jest często… Jej nie ma! 

Tak to ujmę. Jestem zwolennikiem posiadania społeczności, bo po prostu razem łatwiej jest dążyć do różnego rodzaju celów. Jest przyjemniej i łatwiej, bo inni ludzie mogą pomóc nam, my możemy pomóc innym. I wszyscy możemy po prostu szybciej dojść do celu, do którego chcemy dojść. Zapraszam więc wszystkich do kontaktu. Jeżeli ktoś chciałby się czegoś dodatkowego dowiedzieć, to piszcie maile, a ja będę odpowiadał. 

 

Świetnie. Dziękuję za tę otwartość. Dla wygody wszystkie linki oczywiście znajdą się w notatce do tego odcinka. Andrzej, jeszcze raz bardzo ci dziękuję! Ogrom wiedzy, doświadczeń. Z mojej strony bardzo przyjemna rozmowa.

Dzięki raz jeszcze. Do usłyszenia, cześć! 

Na razie!

 

 

To na tyle z tego, co przygotowałem dla ciebie na dzisiaj. W zapewnieniu bezpieczeństwa aplikacji biorą udział wszyscy członkowie zespołu produktowo-deweloperskiego. Andrzej mówił też o komunikacji, która odgrywa tutaj znaczącą rolę. 

Jeśli doceniasz to, co robię, wesprzyj mnie na Patronite. To taka platforma, na której możesz wspierać twórców internetowych w ich działalności. Mnie możesz wesprzeć kwotą już od 5 złotych miesięcznie. 

Mój profil znajdziesz pod adresem porozmawiajmyoit.pl/wspieram.

Jeśli spodobał Ci się ten odcinek i nie chcesz przegapić kolejnych, równie ciekawych epizodów podcastu, zasubskrybuj go w swojej aplikacji podcastowej. Jeśli nie wiesz jak to zrobić, wejdź na stronę porozmawiajmyoit.pl/subskrybuj. 

Nazywam się Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT o bezpieczeństwie aplikacji. 

Zapraszam do kolejnego odcinka już za tydzień.

Cześć!

 

+ Pokaż całą transkrypcję
– Schowaj transkrypcję
mm
Krzysztof Kempiński
krzysztof@porozmawiajmyoit.pl

Jestem ekspertem w branży IT, w której działam od 2005 roku. Zawodowo zajmuję się web-developmentem i zarządzaniem działami IT. Dodatkowo prowadzę podcast, kanał na YouTube i blog programistyczny. Moją misją jest inspirowanie ludzi do poszerzania swoich horyzontów poprzez publikowanie wywiadów o trendach, technologiach i zjawiskach występujących w IT.