Szymon Warda: Cześć, słuchacie Patoarchitektów. Prowadzą Szymon Warda…

Łukasz Kałużny: I Łukasz Kałużny. Wszystkie linki do tego odcinka znajdziecie na Patoarchitekci.io lub gdzieś tu na dole, z boku, dacie sobie radę jak zawsze. I słuchajcie, przypominamy o szkoleniach Pato, bo już niedługo, 21 lutego, Szymon prowadzi całodniowe szkolenie online z modelowania danych nie tylko w NoSQL. Czyli wreszcie będziecie mogli zobaczyć w praktyce to, o czym często wspominamy - w jaki sposób podejść do zamodelowania tych danych fizycznie w bazie danych. Ja za to 22 lutego powymądrzam się na temat Kubernetesa w szkoleniu Kubernetes The Hard Way. Czyli będziecie mogli na nim poznać detale działania Kubernetesa stawiając go samodzielnie od zera i zobaczycie skąd się biorą te wszystkie magiczne rzeczy, które Kubernetes przed nami chowa i gdzie są te parametry, które mówimy potem, że Kubernetes zachowuje się tak, a nie inaczej.

Szymon Warda: To dzisiaj będzie odcinek z gościem. Tak stwierdziliśmy, że będzie trochę bardziej regularnie. Temat mieliśmy już od jakiegoś czasu, tylko tak mi chodziło po głowie kogo zaprosić, kogo zaprosić. I chcieliśmy kogoś realnego, kogoś, kto się utrzymywał z szukania exploitów i znaliśmy Andrzeja. Przypomnieliśmy się, że Andrzej jest po prostu i już. Andrzej Dyjak, człowiek, który zajmuje się tematem od 20 lat, od 15 lat konsultuje, pomaga i który faktycznie wie i udziela się odnośnie czego? Oczywiście odnośnie bezpieczeństwa aplikacji i jak całe bezpieczeństwo połączyć sensownie z procesem wytwórczym, architekturą i tak dalej, a nie tylko po prostu odrzucać różne żądania developerów. Andrzeju, witamy.

Andrzej Dyjak Dzień dobry, dzień dobry. Ja tutaj od razu zrobię małe sprostowanie, bo jeżeli ktoś mnie zna, słyszał mnie w innych podcastach albo nawet w moim podcaście, to zdaje sobie sprawę, że ja przywiązuję wagę do słów i do tego, co one konkretnie oznaczają. I przyczepię się do szukania exploitów. Więc od razu wyjaśnię, exploitów się technicznie nie szuka, bo exploit to już jest wykorzystanie jakieś podatności. Czyli szukać można podatności, a w zasadzie nawet technicznie tak, szukamy podatności, a potem piszemy dopiero exploit, czyli wykorzystujemy podatność do zrobienia czegoś, do stworzenia jakiejś własnej logiki w aplikacji, która była nieprzewidziana. Przy czym może być tak, że wykorzystamy tutaj wiele podatności w jednym exploicie. Przykładowo, my to nagrywamy w 2024 roku i chwilę przed 2024 rokiem, czyli pod koniec 2023, był omawiany taki dość głośny atak na iPhone’a. To było omawiane na tej samej konferencji, na której były poruszone sprawy z naszym polskim Newagiem. Natomiast tam Kasperski upublicznił informację o dość dużym ataku na ekosystem Appla, konkretnie na iPhone’y. I tam było, o ile dobrze pamiętam, 4 podatności zero-day wykorzystane w jednym ataku. Więc tak naprawdę to był jeden exploit, który wykorzystywał X podatności do tego, żeby osiągnąć zdalne wykonanie kodu na sprzęcie Appla.

Szymon Warda: To by było w kontekście, gdyby ktoś miał wątpliwości czemu akurat Andrzej. Dobrze, to w sumie zacznijmy tak naprawdę. Bo powiedzieliśmy o bezpieczeństwie. To jest taki mega szeroki temat, który z reguły się kojarzy z taką starą gwardią bezpieczników, którzy po prostu mówią, że nie wolno podłączyć pendrive’a pod komputer, a i nie wolno otworzyć jakiejś tam strony, itd. A czym obecnie jest bezpieczeństwo w architekturze aplikacji i w ogóle w całym procesie wytwórczym? Jakbyś to zdefiniował i jak Ty to widzisz obecnie?

Andrzej Dyjak Dobra, to ja od razu słuchaczom podrzucę taki dość prosty, uproszczony model spojrzenia na bezpieczeństwo. Nadmienię, że jest to model logiczny, czyli tak naprawdę możemy sobie takich podziałów zrobić więcej niż ten konkretny, więc to nie jest prawda objawiona. Możemy zrobić ich więcej, natomiast każdy model nie jest rzeczywistością, ale model może być przydatny lub nie i ten model jest przydatny. Więc wspomniałeś o takiej starej gwardii cyberbezpieczeństwa, która technicznie jest bardziej związana z bezpieczeństwem sieci, bezpieczeństwem organizacji. I to można dość fajnie nazwać i zamknąć w takim obszarze jak Corp Sec i Net Sec, czyli Corporate Security i Network Security. I te odnogi bezpieczeństwa, bo to są odnogi Cybersecurity, cyberbezpieczeństwa. One zajmują się tym w Corporate Security, żeby to organizacja, jakaś grupa ludzi była bezpieczna. I tutaj przykładowo mamy bezpieczeństwo fizyczne, ale mamy też bezpieczeństwo teleinformatyczne. Natomiast Network Security, bezpieczeństwo sieciowe, to już schodzimy trochę niżej i zapewniamy, żeby to sieć organizacji była bezpieczna. Najczęściej jest to pewnego rodzaju intranet. A to, o czym Ty wspominasz i w którym kierunku idziemy i też to, czym ja się głównie zajmuję, ale też patrząc wstecz, to jest ta działka, która zyskuje głównie w ostatniej dekadzie. W poprzedniej dekadzie zyskała bardzo mocno na znaczeniu, a teraz cały czas idzie do góry i się nie zatrzymuje. To jest Application Security, czyli bezpieczeństwo aplikacji, czyli co zrobić, żeby to, co wytwarzamy w procesie wytwórczym, żeby to było bezpieczne. Nie za bardzo nas wtedy interesuje, w jaki sposób atakujący wchodzi do sieci, co musi zrobić, jakie kroki musi wykonać, żeby zdobyć dalsze kawałki naszej sieci i końcem końców wykraść jakieś dane, to w Application Security nie jest takie ważne. W Application Security odpowiadamy na pytania takie jak: co zrobić, żeby aplikacja, która żyje na środowisku testowym, żebyśmy mogli ją przeskanować i znaleźć w niej podatności? Albo co zrobić, żebym ja już pisząc kod w IDE miał w jakiś sposób informacje od IDE albo od jakiegoś dodatkowego narzędzia, że to co napisałem przed chwilą, to jednak nie jest koszerne i nie powinienem sklejać stringów do zapytania SQL, raczej powinienem użyć ORM-a. To jest analiza statyczna. Więc jak to wygląda? W chwili obecnej wygląda to coraz lepiej, ten Application Security. Natomiast dalsze kawałki, jak Network Security czy Corpo Security to myślę, że w całej tej rozmowie trochę pominiemy, bo one myślę, że dla słuchaczy tego podcastu są mniej ciekawe.

Szymon Warda: Trochę nas to nie dotyczy, faktycznie. Właśnie trochę zahaczyłeś o taki temat właśnie umieszczenia, czym w ogóle jest tak naprawdę na wysokim poziomie, jak nawet mamy dwa podziały praktyk, dużą architekturę, powiedzmy aplikacyjną, mamy architekturę systemową generalnie. Czy taki sam mniej więcej podział też występuje, jeżeli mówimy o bezpieczeństwie, że pewne obszary Application Security aplikujemy aplikacji, a pewien obszar aplikujemy do całej architektury? Mamy jakieś rozróżnione podejścia?

Andrzej Dyjak Wiesz co, to jest dobre pytanie, bo technicznie nie ma takiego wydzielonego podziału. Najczęściej robi się to, przynajmniej w dużych organizacjach, przykładowo jedną rolą, czyli rolą architekta do spraw bezpieczeństwa. Ale moglibyśmy wyszczególnić takie dwa podziały, czyli odpowiedź na takie szerokie pytanie co zrobić, żeby to, nad czym pracujemy na poziomie implementacji, na poziomie operacyjnym, było bezpieczne. I drugi kawałek, co zrobić, żeby to, co już działa, czyli nawet niekoniecznie nad tym pracujemy, ale utrzymujemy, żeby ten kawałek był bezpieczny. I to wtedy bym widział jako ten kawałek, o którym Ty powiedziałeś, tak systemowo. Przykładowo, takie dwie praktyki, procesy, które pasują do jednego lub drugiego, to analiza statyczna pasowałaby do tego pierwszego, gdzie chcemy odpowiedzieć na pytanie co zrobić, żeby to, co będziemy teraz wytwarzać było bezpieczne. I to jest jakiś potok, który ma nam pozwolić zabezpieczyć to, co wytwarzamy. A z drugiej strony mamy Web Application Firewalla, czyli chcemy odpowiedź na pytanie, jakie regułki w firewallu powinny być i powinno obejmować całe portfolio aplikacji, które wystawiamy na brzegu sieci, żeby utrudnić atakowanie naszych web aplikacji. I w zasadzie technicznie w dużej organizacji jedno i drugie byłoby robione trochę inną rolą, trochę innym człowiekiem i wymagałoby też trochę innego spojrzenia na aplikację. Bo łatwo sobie wyobrazić, że to pierwsze wymaga bardziej osoby, która miała do czynienia z programowaniem, żeby wiedziała przykładowo jakie zasady na SAST-cie powinny być uruchomione, a drugie bardziej wymaga kogoś, kto zna się na utrzymaniu takiego typowego klasycznego bezpiecznika, czyli kogoś, kto odpowie na pytanie: dobrze, no to jakie mam typowe ataki i co ja powinienem zrobić, żeby odeprzeć te ataki?

Szymon Warda: Zacząłeś temat, do którego zmierzamy tak naprawdę. Mianowicie poruszyłeś temat roli procesu. I jeżeli ruszamy to, to nie możemy poruszyć ostatniego pędu w kierunku robienia i kombinacji różnych trzyliterowych skrótów. I teraz takim skrótem oczywiście jest DevSecOps. Czym jest tak realnie na to patrząc, poza takimi kartkowymi definicjami?

Łukasz Kałużny: Właśnie, to jest podejście czy rola?

Szymon Warda: Łukaszu, to jest podejście, które za chwilę będzie rolą.

Łukasz Kałużny: Albo już jest, patrząc na niektóre ogłoszenia.

Andrzej Dyjak Dobre pytanie. To jest filozofia, to po prostu nam mówi, jak mamy żyć. Trochę pół żartem, pół serio. Natomiast nie jestem pewien, czy nazwałbym to metodyką. Myślę, że w ramach DevSecOpsu można wyrobić sobie jakąś metodykę. Ale tak technicznie, jeżeli ktoś mówi o DevSecOps, to raczej jest to właśnie filozofia tworzenia oprogramowania, która technicznie, jeżeli byśmy się bardzo trzymali terminów i dlatego sporo osób nie lubi DevSecOpsa, ani SecDevOpsa, ani DevOpsSec. Gdybyśmy się tak mocno trzymali terminologii, to technicznie sam DevOps tutaj wystarczy. No bo DevOps w swoich założeniach zajmuje się jakością, a bezpieczeństwo jest odnogą jakości. Więc technicznie jeżeli wrócimy do takich podstawowych książek, jak np. Defining Project, które opisuje DevOps, to bezpieczeństwo jest tam niejako wbudowane, jest już zaadresowane, nie trzeba mówić o DevSecOps. I czemu ten DevSecOps gdzieś tam się pojawił? Wydaje mi się, nie wiem, choć się domyślam, że wynika to z tego, żeby po prostu łatwiej było mówić o tym, że tutaj mam DevOpsa i on łączy operacje + development, a tutaj właśnie chcę mieć rolę osobną, więc chcę mieć często gęsto jakiegoś klasycznego bezpiecznika, który od teraz ma się zajmować, ma wprowadzać bezpieczeństwo w proces wytwórczy. Czyli biorę kogoś, kto klasycznie był takim, właśnie tą osobą z tą pałką, która bije po głowie i teraz mówię: dobra, to to nie działa, to chodź, teraz połączysz się z nimi, będziesz im pomagał, żeby oni faktycznie tworzyli ten software już na samym początku bezpieczny i w takim podejściu, które też jest takim keywordem, które u nas w Polsce bardzo często się używa, secure by design/DevSecOps/shift left. To to praktycznie jest używane wymiennie, bo oczywiście wszystko to ze sobą jest połączone, ale nie jestem pewien, czy powinno być tak w stu procentach wymienne.

Łukasz Kałużny: Wiesz co, z tego wynika, to jest tak naprawdę, że ktoś próbuje się, bo moje zapatrzenie się na DevSecOpsa jest takie, że była sobie rola DevOps engineera… Nie bójmy się tego nazwać, podejście zostało tak realnie zgwałcone, że tak powiem, w filozofii poszło, wsadźmy kogoś w rolę w korporacjach.

Szymon Warda: Lub rekrutację.

Łukasz Kałużny: Tak, bo najprościej to nazwać. I mam wrażenie, że powstała potrzeba, żeby jawnie wsadzić bezpiecznika w cykl wytwarzania oprogramowania. Osoby, które powinny się zająć technicznym bezpieczeństwem i po prostu przymalowano nową rolę z drugiej strony. Moje wrażenie jest takie, że poza nielicznymi przypadkami, branża bezpieczników takiego szeroko, w szczególności tego korporacyjnego bezpieczeństwa, nie rozumie procesu wytwarzania oprogramowania.

Andrzej Dyjak To teraz to ok, jedziemy z tym.

Szymon Warda: Ja bym poszedł dalej. Nie wiem, niekoniecznie nawet jest czy rozumie, nie rozumie, po prostu jawnie mówi, że ich to nie interesuje w wielu obszarach.

Łukasz Kałużny: To zależy od instytucji. Generalnie moje wrażenie, że to co nazywa się corpo bezpieczeństwem nijak ma się do realnego wejścia poza mówieniem jakiś pentestów, wymyśleniem użycia standardów z rynku, że nijak nie wchodzi to w codzienny operacyjny rozwój aplikacji.

Andrzej Dyjak Jest dokładnie tak jak mówisz. Mamy to Enterprise Security i mówiąc Enterprise Security najczęściej mam na myśli klasyczne bezpieczeństwo jako zupełnie osobny silos w organizacji, który nie jest od tego, żeby pomóc przykładowo developmentowi stworzyć bezpieczne aplikacje, albo innym silosom w organizacji pomóc w bezpiecznych operacjach. Tylko jest po to, żeby się do wszystkiego przyczepiać. Co najgorsze, ludzie po jakimś czasie, często gęsto nie jest to na samym początku, ale po jakimś czasie sami zaczynają widzieć swoją rolę jako rola, która ma innym po prostu zabraniać i mówić, że: a nie mówiłem, patrz, jak zrobisz tak, to będzie źle. Ale nie dają faktycznie systemowych rozwiązań, jak coś powinno być zrobione. I teraz jeżeli przybliżymy się do naszego kawałka, czyli do wytwarzania oprogramowania, to nawet nie są w stanie podać praktycznych rozwiązań, dlatego że, i tutaj już było to jasno wypunktowane, co ja w stu procentach potwierdzam, najczęściej nie mają doświadczenia w procesie wytwórczym na poziomie programisty. Nie za bardzo ich interesuje inżynieria oprogramowania. Ja powtarzam nie raz, nie dwa, wszędzie gdzie mogę zresztą, że dużo łatwiej zrobić z programisty bezpiecznika niż z bezpiecznika programistę. Bo programowanie, nie chodzi mi o samą umiejętność tego, że ja jestem w stanie kod jakiś napisać, tylko że jestem w stanie uczestniczyć w procesie wytwórczym z innymi programistami i pisać kod produkcyjny, który gdzieś tam trafia, jest dużo bardziej skomplikowane niż właśnie samo zakodowanie czegoś, lub, albo też niż samo bezpieczeństwo, które często gęsto opiera się po prostu na takich przydługawych i rozbudowanych checklistach - jeżeli to, to zrób to, a jeżeli tamto, to zrób tamto, a tamtego to nigdy nie rób. Więc tak, jest duży problem takiego malowania trawy na zielono. Biorę bezpiecznika, który nie jest w stanie sobie poradzić, bo po prostu nie zna specyfiki pracy i teraz mówię mu, że on ma się zająć tym, żeby te systemy, które wytwarzamy, były bezpieczne. I potem mamy takie problemy, że taka osoba przychodzi i np. mówi, że: no dobra, mam na roadmapie inicjację procesu analizy statycznej i często gęsto kończy się to tak, że analiza statyczna jest wydaniu jakiegoś centralnego kawałka oprogramowania, przez który musi przelecieć cały kod i ten centralny kawałek oprogramowania skanuje ten kod i wyrzuca jakieś tam alerty. I te alerty oczywiście trafiają do bezpiecznika. Potem bezpiecznik idzie do tego zespołu i mówi: no patrzcie, macie tutaj te problemy, musicie je zaraz rozwiązać. Teraz macie wszystko zatrzymać i rozwiązać tych 150 problemów. I oczywiście raz, że to nie ma prawa działać, a dwa, że fundamentalnie stoi w kontrze z jakąkolwiek ideą DevSecOps, a nawet po prostu DevOps, bo bezpieczeństwo powinno być wbudowane. Jeżeli mówimy tutaj o analizie statycznej, to tak naprawdę te wszystkie problemy, te wszystkie warningi, one powinny być na maszynie developera. Jeżeli to się dzieje gdzieś tam dalej w potoku, to to jest bezpieczeństwo w starym wydaniu, które nie ma prawa działać. To raz, a dwa, że stoi w kontrze z samą ideologią DevOps czy DevSecOps, bo technicznie nie może być czegoś co gdzieś tam się dzieje post factum.

Łukasz Kałużny: Wiesz co, to słuchaj, bo powiedziałeś o maszynie developera i to jest pewnie kwintesencja troszeczkę dla mnie tego shift left, żeby feedback był jak najszybciej. Czy mógłbyś głębiej zdefiniować do czego powinniśmy dążyć przy tym shift left?

Andrzej Dyjak Dobra, więc jeszcze wytłumaczę, bo trochę wspomniałeś o tym shift left, ale jeszcze dopowiem. Jak sobie wyobrazimy proces wytwórczy to wiemy, że mamy pi razy drzwi takie fazy jak projektowanie, więc musimy coś najpierw zaprojektować. Następnie mamy jakąś fazę implementacji, to co sobie zaprojektowaliśmy chcemy zaimplementować. Następnie mamy lepszą lub gorszą fazę testowania, czyli chcemy sprawdzić, czy to, co jest zaimplementowane mniej więcej spełnia swoje zadanie. I potem trafia to na produkcję, więc utrzymujemy. W dużym uproszczeniu. No i teraz bezpieczeństwo klasycznie działo się na tym najbardziej prawym kawałku całej tej układanki, czyli na utrzymaniu. Więc jeżeli mówimy o testach bezpieczeństwa, to one się działy na samym końcu, wtedy, kiedy już dawno zaprojektowaliśmy, zaimplementowaliśmy, nawet QA-e już tam wjechali i otestowali. Już mamy takie rozwiązanie i teraz przychodzi bezpieczeństwo i mówi: nie, nie, nie, nie, nie, nie, proszę pana, tutaj jest za dużo błędów. Tu nam wyszło z testów, że nie możecie wjechać na produkcję. No i oczywiście zaczyna się przepychanka, która często gęsto kończy się tak, że raczej wjeżdża to na produkcję, bo biznes naciska i nie może być inaczej, bo na koniec dnia piszemy kod po to, żeby rozwiązywać problemy biznesowe, a problem biznesowy rozwiązujemy po to, żeby robić pieniądze albo unikać jakiejś straty pieniędzy. Więc niejako stoi to trochę wyżej niż widzimisię bezpieczeństwa. I w pewnym momencie ludzie, szczególnie ci bezpiecznicy, którzy mają background inżynieryjny, zdali sobie sprawę, że to nie działa, to nie działa i to nie ma prawa działać, musimy problem naprawić systemowo. A skoro musimy naprawić problem systemowo, to musimy pójść bliżej tego, co budujemy. I zaczęła się droga shift left, czyli przesuwania bezpieczeństwa, ale nie tylko bezpieczeństwa, bo ogólnie jakości też, coraz bardziej na lewo. Czyli jeżeli od fazy utrzymania przejdziemy do fazy testów, to przykładowo w takiej fazie testów moglibyśmy wykonać jakiś podstawowy skan podatności automatyczny. On nie musi być wykonany przez człowieka. Możemy tam wykonać podstawowy skan automatyczny. Idąc dalej, w fazie implementacji. Tu już kilka razy wspomniałem analizę statyczną, to analiza statyczna nie powinna być w potoku CI, ale powinna być tutaj idealnie na maszynie developera, żeby ten silnik analizy statycznej uruchomił się tam i żeby te regułki uruchomiły się już na maszynie. Czemu? Bo jeżeli ja uruchomię i przeskanuję kod na tym kawałku, to developer jest w stanie w tym momencie zobaczyć: a dobra, to tego nie powinienem robić, to to poprawię. Jeszcze przed uruchomieniem pull requesta czy match requesta. Więc oszczędza czas innym ludziom, ale też i to też jest taka ukryta cecha przechodzenia w shift left, że taka osoba po prostu zaczyna się szybciej uczyć czego ma nie robić. Więc jak zobaczy ten błąd 50-któryś raz, to potem już go po prostu nie zrobi, bo podświadomie będzie wiedziała: tak się tego nie robi, to nie jest koszerne. No i oczywiście jeżeli jeszcze chcemy przejść dalej na lewo, czyli do fazy projektowania, to jest taki proces, który się nazywa modelowanie zagrożeń i też jesteśmy na tym kawałku procesu w stanie przewidywać, co może pójść źle i co z tym zrobimy. Modelowanie zagrożeń odpowiada na trzy pytania - nad czym pracujemy? Co może pójść źle? I co z tym zrobimy? I odpowiadamy na to ostatnie pytanie po to, żeby już w tych dalszych fazach po prostu tego w jakiś sposób uniknąć. Więc tak, są różne praktyki, które można zaimplementować na różnych etapach procesu wytwórczego, po to, żeby to, co na końcu wydajemy, było bezpieczniejsze, a nie bezpieczne, bo bezpieczne nigdy w stu procentach nie będzie. I bezpieczeństwo to jest po prostu żonglowanie pomiędzy kosztem ewentualnej straty a kosztem uniknięcia tej straty. I trzeba mieć tutaj też takie zdroworozsądkowe podejście, które można łatwo zaprezentować, że jeżeli ewentualna strata będzie niższa niż koszt implementacji jakiejś kontroli bezpieczeństwa, to ja się po prostu zgodzę na tę stratę i nie będę się nad tym zastanawiał, bo bezpieczeństwo nie jest zero-jedynkowe. Bezpieczeństwo jest raczej takie, jak większość rzeczy w życiu, szare, więc chcemy po prostu znaleźć balans pomiędzy tym, żeby coś było jak najbardziej bezpieczne, ale jednocześnie żeby nam się spinało w budżecie. Sporo wątków poruszyłem.

Łukasz Kałużny: Zaraz Cię weźmiemy i złapiemy. Andrzej, świetnie opowiadasz, ale chyba będziemy musieli w niektórych wtykać więcej pytań w trakcie.

Szymon Warda: Ja to postaram się w takim razie ułożyć generalnie, bo mówimy sobie właśnie, opisaliśmy mniej więcej jak to zaczęło się, jak to wygląda i wszystko fajnie, ładnie, ale chcemy konkretów, mówiąc bardzo prosto. Czyli mamy świadomość tego generalnie, już uogólniam świadomość, bo jako developerzy, że DevSecOps jest potrzebny. To bezpieczeństwo trzeba zaadresować. W takim razie pytanie proste: czego używać, a co odpuścić generalnie na chwilę obecną? Załóżmy, mamy projekt, który chcemy coś zrobić w miarę, żeby było ok, żebyśmy ładny return on investment, żeby to było sensowne, więc co zrobić?

Łukasz Kałużny: Czyli robimy te klasyczne bezpieczeństwo, a chcemy zacząć to robić zgodnie z tym w sumie właściwym modelem, który implementuje te shift left. To właśnie jak podchodzisz u siebie przy konsultacjach z klientami? Co proponujesz przy takich, być może ogólnikowo, bądź na technologiach, jeżeli masz jakieś szczegóły, którymi chcesz się z nami podzielić?

Andrzej Dyjak Więc mam stan taki klasycznego bezpieczeństwa, czyli powiedzmy mamy tam jakieś testy bezpieczeństwa, które się dzieją raz na jakiś czas, nazwijmy to sobie pentesty i w zasadzie na ten moment mam tylko to. Bo to w większości organizacji jest, bo to się zaczęło już lata temu i raczej jest dość duża świadomość, że przynajmniej pewien zakres aplikacji, które wytwarzamy i utrzymujemy, powinien być testowany periodycznie. To najczęściej są aplikacje, które przykładowo przetwarzają dane osobowe. I teraz tak i chcemy zacząć rozbudowywać bezpieczeństwo, chcemy tak naprawdę zmniejszyć koszt końcowo bezpieczeństwa, bo koszt bezpieczeństwa, jeżeli mamy tylko testy bezpieczeństwa na samym końcu, będzie dużo większy, bo tak naprawdę potem musimy się cofać. Więc w pierwszym kroku należałoby odpowiedzieć na pytanie: czy mamy już podstawowe testy automatyczne? I one też mogą być jeszcze w tej fazie utrzymania, czyli na samym końcu. I to się nazywa Dynamic Application Security Testing, DAST. I tutaj chcemy odpowiedzieć, czy je mamy, czy nie. One często gęsto też już są, więc nie musimy tego dalej poruszać, bo one po prostu najczęściej są. Jeżeli ich nie ma, to należałoby zacząć od tego. Czyli należałoby spróbować sobie automatyzować testy systemów, które już żyją, po to, żeby w cyklu takim automatycznym i dość często, skanować to, co u nas żyje. Czyli niejako trochę odciążyć tych pentesterów z takiej pracy manualnej.

Łukasz Kałużny: Czyli Andrzeju mówisz bardziej o rozwiązaniach do automatycznego, te, które mamy na rynku, rozwiązania do automatycznych pentestów, sprawdzania takich podstawowych rzeczy. Bo część osób może pomyśleć, że mówisz o testach jednostkowych, o tej części takiej stricte aplikacyjnej. Jakbyś mógł pojęcie testy rozszerzyć teraz, w tym momencie?

Andrzej Dyjak Jasne, dobrze, masz rację. Przy czym poruszyłeś kwestię testów jednostkowych, a to też gdzieś zaadresuję. W takim wypadku mam na myśli automatyczne rozwiązania takie jak przykładowo Rapid Seven czy Acunetix. To są automatyczne skanery, które po prostu się puszcza na aplikację, podaje po prostu się URL-a do aplikacji i one tam odpalają jakiś zestaw swój wbudowany testów, czyli wysyłają pewne jakieś dane pod endpointy i po prostu sprawdzają w pętli czy aplikacja się wywaliła czy nie. Przykładowo jeżeli aplikacja wyśle 500-tkę, albo wyśle jakiś dziwny komunikat błędu, albo to co wysłałem pojawi się w odpowiedzi, to taki automat po prostu zaraportuje nam taką sytuację. Więc to jest bardzo prosta pętla. Składam sobie zapytanie, wysyłam je do aplikacji i sprawdzam co jest w odpowiedzi. Jeżeli spełnia moje kryteria odpowiedź, to ją flaguję i wrzucam do raportu, a jeżeli nie, to przechodzę do kolejnego zapytania i składam sobie kolejne. I to są takie klasyczne skanery bezpieczeństwa. Przy czym należałoby unikać słowa automatyczne pentesty, bo technicznie samych pentestów się nie do końca da zautomatyzować, bo jednak tam potrzebujemy człowieka i potrzebujemy tego, nazwijmy to, kreatywności. Być może w bliskiej przyszłości AI rozwiąże ten problem, ale na chwilę obecną jeszcze potrzebujemy człowieka, przynajmniej na ten moment. I to są takie najbardziej klasyczne skanery, które też widać na rynku, czyli Acunetix, Rapid Seven. W zasadzie ta dwójka u nas jest bardzo często używana. Acunetix chyba najczęściej. Oczywiście jest kilka innych vendorów, którzy dorzucają i można też użyć darmowego skanera ZAP, czyli Zeta Tag Proxy, który kiedyś był projektem OWASP-owym, teraz już nie jest projektem OWASP-owym, ale w dalszym ciągu jest darmowy i można go po prostu uruchomić bez większych problemów na swoje aplikacje. Przy czym trzeba pamiętać, że te aplikacje mogą się wywalić, więc nie należy tego robić na…

Łukasz Kałużny: Na produkcji.

Andrzej Dyjak Znaczy można, ale wtedy należałoby mieć jakieś pozwolenie od managementu i biznesu, bo coś może się wywrócić, a tego byśmy nie chcieli. Więc to rozumiem przez testy. Chociaż testy jednostkowe, do nich też wrócę, ale to już jest, ja to nazywam DAST-em, ale też SAST-em drugiej generacji. Bo to, o czym teraz powiedziałem, to jest taki DAST pierwszej generacji, tak się to robi od 20 lat i w dalszym ciągu to działa i daje jakieś wyniki. Ale w chwili obecnej od kilku lat widzimy wzrost narzędzi i DAST i SAST, które można nazwać narzędziami drugiej generacji, których podejściem, których filozofią jest rozwiązywanie problemów w trochę inny sposób. Natomiast do tego wrócę, bo to jest coś szerszego. Więc kontynuując w takim wydaniu, na chwilę obecną mielibyśmy jakieś testy bezpieczeństwa, pentesty ludźmi na fazie już utrzymania, oraz testy automatyczne, które jakimś narzędziem, które musimy albo kupić, albo sobie sami wgrać i sami nakierować i zautomatyzować. Następnie i to jak pewnie też widzicie raczej nie należy do programisty. Raczej programista nie będzie tego robił w tym punkcie. Ale już kolejny krok wymaga, albo przynajmniej należałoby wejść i zacząć współpracować z programistami, bo tutaj wchodzi analiza statyczna. I w analizie statycznej mamy tak naprawdę te duże problemy. To wszystko będzie analiza statyczna, ale to są trzy osobne problemy, które można rozwiązywać osobnymi narzędziami. Pierwszy problem, to jest problem z podatnościami w naszym kodzie. Więc programista popełnia jakiś błąd, ten błąd jest podatnością, czyli ma jakąś implikację związaną z bezpieczeństwem. I teraz ten błąd ma jakiś swój wzorzec, jakiś pattern. To już dawno temu mądre głowy doszły do tego, że w zasadzie te wzorce można ekstrapolować i można po prostu próbować szukać je na większych kawałkach kodu albo w tych samych, jeżeli mówimy o jakichś atomicznych komitach. Więc wdrożenie analizy statycznej po to, żeby znajdywać błędy podatności w kodzie, który my wytwarzamy, to jest jeden krok i to jest cały jeden duży strumień, który wymaga całkiem sporo pracy. Więc ja go ujmuję z grubsza, ale to nie jest takie łatwe, żeby to zrobić dobrze. Najczęściej działa to tak, jak wcześniej powiedziałem, w takim centralnym wydaniu. U nas na rynku często gęsto jest to SonarQube, ale to może być też komercyjny Fortify czy Checkmarx. Checkmarx też jest dość często używany. Ja nie jestem zwolennikiem tych rozwiązań. Według mnie te rozwiązania są mało skuteczne i one są analizatorami pierwszej generacji ewidentnie. I one bazują na tym, że główna logika, główny skaner jest w jakimś kawałku infrastruktury i przez ten kawałek musi przelecieć kod. Co już widzicie tutaj problem. Czyli nie jestem w stanie robić tego na maszynie, bo na maszynie nie mam tego…

Łukasz Kałużny: Wiesz co? To wrzucę Ci akurat ze światka .Netowego. Sonar np. ma część silnika, możesz odpalić lokalnie, to jest np., tam to się zmieniło chyba z dwa lata temu.

Andrzej Dyjak Nawet dalej niż dwa lata temu. Tak, SonarQube’a, Checkmarxa, ETC można wbudować w IDE. Albo inaczej można wgrać plugin, który będzie nam wykonywał podstawowe skany statyczne na maszynie developera, przy czym to są naprawdę bardzo podstawowe skany. Czyli jeżeli wykryje przykładowo sklejanie stringów zapytanie SQL, to takie coś jest dość łatwo, to Grepem można znaleźć. To takie coś nam wykryje. Ale już jeżeli będziemy mieć, chcemy znaleźć coś bardziej skomplikowanego, coś przykładowo, co opiera się o przepływie jakiś danych, to już tutaj to się nie zadzieje, a na tym silniku pełnym się zadzieje. Więc w takim wydaniu nie jesteśmy w stanie w stu procentach ufać temu co się dzieje na maszynie developera, co tworzy ten problem, że na koniec dnia i tak źródłem prawdy jest to, co się wydarzyło w potoku CI, czyli to, co się wydarzyło na tym centralnym serwerze. A my chcemy to odwrócić. I idealnie dążymy do tego, żeby źródłem prawdy było to, co się wydarzyło na maszynie developera, a to co się dzieje w potoku CI, żeby było tylko bramką, która daje znać bezpiecznikom ewentualnie jeżeli coś z maszyny developera się wślizgnie. Ale źródłem prawdy powinno być to, co się dzieje na maszynie developera. I są narzędzia w chwili obecnej już, które można zaprząc właśnie w taki sposób działania. Takim najlepszym narzędziem dla analizy statycznej, które ja tak często powtarzam na szkoleniach, że powiedzieli mi, że powinienem się do nich odezwać i jakiś procent od sprzedaży brać. To Semgrep jest i to się rozwija jako Semantic Grep. Więc Semgrep faktycznie jest bardzo ciekawym rozwiązaniem, które pozwala na szukanie podatności w kodzie, który piszemy, ale przede wszystkim pozwala robić to bardzo szybko. Więc jest bardzo duży nacisk, żeby narzędzie było bardzo wydajne. To jest plus. A minusem Semgrepa jest to, że jest raczej filozofia taka, że to nasz zespół bezpieczeństwa w tej organizacji powinien tworzyć dodatkowe reguły. Oni tam mają darmowe reguły, jest też wersja komercyjna, która ma jeszcze więcej reguł. Ale filozofia twórców narzędzia jest taka, że to Twój zespół bezpieczeństwa powinien tworzyć swoje reguły na podstawie błędów, które popełniają Twoi programiści w technologii, z której korzystasz Ty. My Ci dajemy sposób, my Ci dajemy narzędzie, które jest w stanie zrozumieć tą Twoją technologię, ale to Ty powinieneś pisać swoje reguły.

Szymon Warda: Czyli takie budowanie kawałka platformy wokół bezpieczeństwa procesu wytwórczego.

Andrzej Dyjak Dokładnie tak.

Łukasz Kałużny: Wiesz co, to mi się trochę kojarzy z rzeczą, za którą nie lubię GitHuba, bo ma kupę materiału źródłowego. Ale ten CodeQL, bo tam też jest w GitHub Advanced Security Packu jest ten CodeQL, który w sumie ma bardzo podobną filozofię.

Andrzej Dyjak No i właśnie dlatego lubię rozmawiać z programistami, architektami, bo wiedzą, o czym mówię. Widzisz, jesteś jedną z niewielu osób, które w ogóle kojarzy, że jest coś takiego jak CodeQL, to raz. A dwa, że w ogóle od razu w momencie, kiedy ja mówiłem o Semgrepie wyłapałeś, że to jest to samo podejście. Bo tak, dokładnie tak, CodeQL reprezentuje dokładnie to samo podejście, które reprezentuje Semgrep. Przy czym CodeQL był głównym rywalem Semgrepa i różnica jest tylko taka, że GitHub kupił CodeQL-a 4 chyba lata temu, a potem sam został kupiony przez Microsoft. Natomiast końcem końców to było dwóch takich rywali i trudno było powiedzieć, który z nich wygra. To teraz wiadomo, który wygra - Semgrep, bo oni też, nie wiem, ale się domyślam, że mają takie założenie, że nie chcą być kupieni przez duże korpo i raczej chcą właśnie, tak jak Szymon powiedział, stworzyć ekosystem i dostarczyć Ci pewną platformę wokół tego i robić na tym pieniądze. CodeQL po prostu dał się kupić. Natomiast filozofia jest dokładnie taka sama, czyli ja Ci daję narzędzie, a to Ty już potem możesz z tego narzędzia skorzystać. I CodeQL, ja nie testowałem CodeQL-a, tak nazwijmy to produkcyjnie, ale przynajmniej z tego, na ile robiłem kilka lat temu research, to CodeQL wypadał lepiej niż Semgrep. Sama technologia była bardziej innowacyjna, ale końcem końców jest to dokładnie odpowiednik jednego i drugiego. Jeden jest odpowiednikiem tego drugiego i teraz jest już tylko Semgrep dostępny.

Łukasz Kałużny: A jak jesteśmy przy toolingu i tej części, bo nie usłyszałem w ogóle, nigdzie nie padło chyba jedno z takich podnoszonych jako bardzo shift left, czyli Snyk. Dajemy się Andrzejowi napić.

Andrzej Dyjak Tak, Snyk jest bardzo często takim pierwszym wyborem. Tutaj jako background, Snyk rozpoczął swoją podróż z bezpieczeństwem, to w ogóle jest firma taka, która powstała od bezpiecznika, więc tu nie było żadnego pivotu, ale rozpoczął swoją podróż od podatnych bibliotek. Czyli niektórzy z naszych słuchaczy może kojarzą coś takiego jak ataki na łańcuch dostawczy, supply chain security? To trochę to, ale nie to. I teraz wyjaśnię. Bardzo często następuje mieszanie konceptów. Czyli Snyk zaczął od podatnych bibliotek, czyli dalej mówimy o podatnościach w bibliotekach. Czyli może ja dołączam ten kod, więc to nie ja popełniłem ten błąd, tą podatność, ale dalej w tym kodzie to po prostu jakiś programista popełnił błąd, nie chciał tego zrobić, ale trzeba było dowieźć na jutro, dowiózł i ja teraz dołączając tą bibliotekę dołącz.Am ją z podatnością i jeżeli wykorzystuję ten kawałek funkcjonalności, to też jestem podatny, ale dalej jest to podatność. Natomiast tak naprawdę jeżeli mówimy o atakach na łańcuch dostawczy, to jak z samej nazwy wynika, ktoś atakuje łańcuch dostawczy i robi to po to, żeby dodać złośliwy kod. Czyli ta biblioteka wtedy nie ma podatności, tylko jest złośliwa. Ktoś, kto ją tam dodał, to nie popełnił błędu, wręcz przeciwnie, chciał dodać ten złośliwy kod. Przykładowo, żeby kopać waluty, było pełno takich ataków. Więc to są dwie osobne klasy problemów, które rozwiązuje się tym samym narzędziem i często gęsto w tym samym punkcie procesu wytwórczego. Innym narzędziem może być np. Snyk. Oni startowali od podatnych bibliotek, potem trochę się rozeszli i oczywiście informują też o złośliwych bibliotekach, czyli rozwiązują ten problem z całym łańcuchem dostaw w pełni. Ale w pewnym momencie zaczęli rozwiązywać też dodatkowe problemy, takie jak analiza statyczna, czyli błędy w naszym kodzie. I teraz, czy ja polecam, czy ja nie polecam? To zależy. Ale powiem tak, ja nie miałem produkcyjnie do czynienia ze Snykiem poza własnym przecięciem się z wersją darmową. Co do komercyjnej, to tam gdzie mogłem się z nim przeciąć, to końcem końców do tego nie doszło, bo cena była za duża. Ja nie wiem jaka była cena, ale najwidoczniej była za duża, więc sobie muszą ileś tam charge’ować za to. Przy czym mogą mieć po prostu model licencyjny taki, że od developera i wtedy…

Szymon Warda: To ja mogę powiedzieć, cyferek jest dużo w tych wycenach Snykowych tak naprawdę i to tam mówimy tak górne 5, 6 cyferek.

Andrzej Dyjak Ok, ale w polskich czy nie?

Szymon Warda: Nie, oczywiście że nie polskich, amerykańskich.

Andrzej Dyjak Właśnie, to żeby dać jakąś referencję słuchaczom. Narzędzia takie jak na przykład SonarQube do analizy statycznej, to kosztuje coś koło poniżej 6 cyferek polskich, więc jest to dużo mniej. Przy czym jeżeli chcemy rozwiązać jeszcze ten problem z bibliotekami, to często gęsto Artifactory już jest albo jest Sonatype, to dokupienie Nexusa czy Xray’a też nie będzie nas dużo kosztowało. Łącznie się zamkniemy pewnie poniżej ćwierć miliona polskich złotych. Poniżej, czyli poniżej 250 tysięcy za oba narzędzia naraz. To jeżeli Snyk nie kosztuje nawet 200 tysięcy, ale to jest pojedyncze narzędzie i trzeba je dostawić i potem trzeba je spiąć jeszcze, bo tutaj powiedzmy Xray to jest taki w bonusie, tylko po prostu się kupuje większą licencję i on się nagle pojawia, więc te koszty potrafią się dość mocno akumulować. I dlatego tam, gdzie ja mogłem go dotknąć, to końcem końców Snyka nie dotknęliśmy.

Szymon Warda: Ruszyliśmy Snyka, ruszyliśmy GitHuba i te dwa narzędzia mają jeden feature i mówimy cały czas o procesie wytwórczym i gdzie tam wartość z tego zyskać. To teraz interesuje mnie Twoje zdanie na temat jednego tematu, automatycznego podbijania zależności, bo to jest mokry sen developera, bo to jest kolosalny koszt procesu wytwórczego. A jak to wygląda z drugiej perspektywy?

Andrzej Dyjak Wiesz co, ja w ogóle jestem zdania, ale to może właśnie dlatego, że mam doświadczenie developerskie i pisałem aplikacje, ja jestem zdania, że cały problem związany z podatnościami w zależnościach, czyli o ile nie mówię o złośliwych zależnościach, ale o podatnych zależnościach, to tak naprawdę nie jest problem, który powinien być rozwiązywany przez security, tylko to jest dług technologiczny i on powinien być rozwiązywany w kwestiach podbijania wersji do góry po to, żeby się szybciej po prostu developowało. I nie robimy tego, bo nie chcemy mieć podatności, tylko robimy to po to, żebyśmy nie zbierali tego długu technicznego i byli w stanie go dość sprawnie spłacać w czasie. Więc tak naprawdę trochę ten kawałek to spycham i mówię, że w zasadzie to tak, to te biblioteki powinny się same aktualizować, proces powinien być ułożony tak, żeby można było to robić. I tutaj bezpieczeństwo to jest tylko czymś, co dodatkowo zyskujemy, a nie czymś, co jest samo w sobie celem. Samo w sobie celem, to jest ewentualne wyprowadzanie podatności w bibliotekach punktowe, czyli wtedy kiedy jest Bóg wie jaki atak, jak Log4Shell.

Łukasz Kałużny: Bo tak, powiedzieliśmy sobie o pierwszej tej fazie, czyli przerzucaniu tych testów automatycznych bezpieczeństwa rozwiązaniami. Powiedzieliśmy sobie o tych dwóch generacjach analizy statycznej i też podejściu, że powinniśmy robić to lokalnie na stacji. Czym warto tak naprawdę w tym procesie się jeszcze zainteresować?

Andrzej Dyjak No i tutaj przed chwilą dotknąłeś tego Snyka i bibliotek, od którego Snyk zaczął, to jest ważny kawałek. I też podbijanie automatyczne, to jest ważny kawałek. To w bezpieczeństwie się nazywa Software Composition Analysis. Czyli tak naprawdę chcemy wiedzieć z czego jest zbudowany nasz software po to, żeby w dalszym punkcie utrzymywać to na odpowiednim poziomie bezpieczeństwa i jakości pod kątem i podatności i złośliwości i żebyśmy byli w stanie też to operacyjnie szybko wykryć. Czyli mielibyśmy tak, DAST-a, czyli Dynamic Application Security Testing, te testy automatyczne, Acunetixa na samej prawej stronie, czyli to się dzieje nam w fazie utrzymania. Mamy SAST-a w fazie implementacji, dzieje się na maszynie developera + niech się dzieje jeszcze w potoku CI przynajmniej jako bramka. Mamy ten Software Composition Analysis i to się powinno dziać podobnie jak analiza statyczna na maszynie developera i w potoku CI, bo znowu chcemy dać znać deweloperowi, że przykładowo ten pakiet, który przed chwilą dołączył, to on jest niebezpieczny albo złośliwy. I tutaj dochodzi jeszcze jeden kawałek, który też jest podzbiorem analizy statycznej. Kawałek, o którym myślę, że każdy inżynier słyszał nie raz, nie dwa, czyli problemy z sekretami. Więc również chcemy skanować kod pod kątem sekretów. Technicznie sekrety nie powinny być w repozytorium kodu. I robimy to trochę innym narzędziem niż te dwa, które wcześniej wymieniłem. Można to robić Semgrepem, bo on ma już taką funkcjonalność, ale ta funkcjonalność została dodana jeszcze jakiś czas temu, ona nie jest na takim poziomie jak typowe rekomendowane rozwiązania do tego problemu, takie jak np. Trufflehog, który jest takim, nazwijmy to, liderem w szukaniu sekretów. I tutaj takim świetnym przykładem jest ostatni problem Mercedesa, gdzie wypłynął taki sekrecik, który pozwolił wejść do całej instancji GitHubowej - GitHub Enterprise. I wiadomo, jeżeli atakujący wejdzie do instancji GitHub Enterprise, to ma dostęp do kodu źródłowego, który tam żyje. A tym pierwszym inicjalnym wektorem było to, że po prostu sekrecik, tu konkretnie token, był zahardkodowany w kodzie źródłowym, który na początku nie był publiczny, a który w pewnym momencie stał się publiczny i ktoś go szybko wykrył. Na marginesie dodam, że kiedyś miałem taki eksperyment i upubliczniłem sam taki sekret. To atakujący, pierwsze użycie tokena, który udostępniłem, to był token AWS, nastąpiło po trzech minutach. Więc po upublicznieniu na GitHubie po trzech minutach widziałem już pierwsze użycie. Mało czasu na reakcję.

Szymon Warda: A ja jeszcze dorzucę odnośnie narzędzi, to właśnie jeszcze żeby większy kontekst. GitHub Advanced Security właśnie też skanuje i też blokuje pushe, więc to jest też bardzo fajna funkcjonalność.

Andrzej Dyjak To drugie o czym wspomniałeś. W zasadzie ten problem powinien być rozwiązywany na poziomie git commita, czyli mamy jakiegoś pre-hooka, który nam blokuje możliwość dodania sekretu, bo jeżeli on tam został już dodany, to pozamiatane. Więc nie chcemy tutaj wykrywać, my chcemy działać proaktywnie, nawet nie pozwolić na wprowadzenie tego problemu. Bo o ile jeżeli wprowadzimy podatność, to możemy ją rozwiązać taką zwykłą i po problemie, to tutaj nie jest po problemie, bo o ile nie unieważnimy tego sekretu, albo sam się nie unieważni, bo ma jakiś czas życia, to problem będzie. I to co wspomniałeś Szymon, Łukasz też wspominasz cały czas o GitHub Advanced Security. Oni mają bardzo dużo ciekawych feature’ów, więc jeżeli ktoś korzysta z GitHuba lub z GitLaba, to polecam w pierwszej kolejności sprawdzić zakładkę Security i zobaczyć jakie feature’y są dostępne w tym co już używam, bo i jedno i drugie ma dość dużo tych feature’ów. Tutaj najgorzej wypada Bitbucket, bo Bitbucket nie ma praktycznie nic, w ogóle się tym obszarem nie zajmują. Natomiast i GitHub i GitLab starają się te obszary adresować w trochę inny sposób. Mają trochę inną filozofię podejścia do rozwiązywania tych problemów. Ale i jeden, i drugi dostawca stara się to rozwiązywać i robią to już od lat. Więc to nie jest coś, że obudzili się z ręką w nocniku wczoraj, tylko robią to od dobrych kilku lat i całkiem dobrze im to wychodzi.

Szymon Warda: I dodam jeszcze, że dla projektów opensource’owych, raczej opensource’owych publicznych sporo feature’ów jest za darmo. Można je sobie spokojnie włączyć. To jest też mała ciekawostka

Andrzej Dyjak Tak, można nawet po prostu potestować sobie i zobaczyć jak to będzie działać, a dopiero potem ewentualnie przechodzić.

Łukasz Kałużny: Dobra, słuchaj, to pytanie Andrzeju, jeżeli mówimy teraz o całej tej układance, co w Twojej opinii, bo mówimy teraz o technologiach i innych rzeczach, ale też trzeba sobie powiedzieć, z czym się opłaca wystartować, co według Ciebie ma największe w tej układance ROI, zwrot z tej inwestycji, żeby być bezpieczniejszym i zacząć to wdrażać i tego się uczyć?

Andrzej Dyjak Jasne, według mnie najpierw należy zacząć od DAST-a, od tych automatycznych skanów, jeżeli ich nie mamy, dlatego że pomimo tego, że one tak dużo może nie wniosą, to bardzo łatwo je po prostu dodać do procesu. Tym bardziej, że jeżeli kiedykolwiek mieliśmy jakieś testy, to niejako mamy przetartą ścieżkę, co robić potem z tym, co znaleźliśmy. Więc jest dużo łatwiej to wdrożyć. A to, co uzyskujemy w takim wypadku na koniec dnia daje nam to całkiem sporo wartości, odejmując koszt, który musieliśmy ponieść. Dopiero w dalszym kroku zastanawiałbym się nad SAST-em. SAST niesie bardzo dużo. Ale jeżeli chcemy go dobrze zaimplementować, to to już jest cała praktyka, cały proces i to nie będzie tanie i przestanie. Mam na myśli nie tylko koszt narzędzi, bo to jest najmniejszy koszt, tylko po prostu koszt, który nam to doda do ogólnego procesu wytwórczego, bo to samo się nie zrobi i czas z gumy nie jest. Więc będziemy mieć tutaj pewien koszt i dopiero w dalszym kroku zacząłbym myśleć o rozwiązywaniu problemów z bibliotekami, bo to brzmi łatwo, ale tak naprawdę nie jest łatwe. Rozwiązanie punktowe może jest dość łatwe, jeżeli mam tylko jedną rzecz, którą chcę naprawić, ale jeżeli chcę systemowo działać i systemowo obniżać to ryzyko, to jest to myślę, że chyba najtrudniejsze z tych rzeczy, które wymieniłem.

Szymon Warda: To ja dorzucę do tego, co mówisz właśnie, przyjrzenie się bibliotekom i zależnościom i jeszcze automatyczne podbijanie. Jeżeli się to zrobi po prostu, to może być absurdalny koszt i wprowadzenie strasznego chaosu i ryzyka regresji. To jest bardzo duże ryzyko.

Łukasz Kałużny: Wiecie co? Zgodzę się z Wami i nie, tak zrobię. Jeżeli ktoś ze słuchaczy dopiero setupuje projekt, bo jednak czasem greenfieldy się zdarzają, to na przykład jeżeli używacie GitHuba i odpalenie dependa na starcie projektu, jeszcze nad tym zapanujecie.

Andrzej Dyjak Masz rację, to jest duże IF, ale tak, jeżeli startujecie się z projektem, to zadbanie o SCA od samego początku będzie dużo łatwiejsze. W ogóle nie pozwolić, żeby ten problem się pojawił. Ale jeżeli mówimy o takim całym portfolio aplikacji i przychodzę dzisiaj i mam już tam setkę aplikacji, które działają, to jest problematyczne chociażby dlatego, że SCA nam wypluje tysiące tych problemów. Oczywiście to nie jest tak, że to jest tysiąc osobnych problemów. Sporo z nich się powtarza, więc to jest, powiedzmy jakiś zbiór problemów, a nie pojedyncze problemy. Ale w dalszym ciągu to będą co najmniej setki takich zbiorów, które trzeba rozwiązać. No i oczywiście, jeżeli nasza aplikacja nie ma testów regresyjnych, to jest bardzo duże prawdopodobieństwo, że jeżeli podbijemy wersję, to nam się coś wywali. I jak to często gęsto w skomplikowanych systemach, potem może być problem z rozpoznaniem czemu, co, gdzie i jak.

Łukasz Kałużny: Wiesz co, akurat z tym podbijaniem. Dla mnie piękno jest de facto te dwa lata temu, już dwa lata temu, to jest Log4Shell. To jest taki piękny przykład, jak ludzie dowiedzieli się, że supply chain istnieje.

Andrzej Dyjak Tak, bo to odczuło najbardziej bezpieczeństwo. To każdy z bezpieczników ma pewnie do dzisiaj koszmary związane z Log4Shellem i szukaniem tego przez całe portfolio swoich aplikacji, systemów. To był bardzo duży problem.

Łukasz Kałużny: Wiesz co, to teraz lecąc kontekstem, bo powiedziałeś coś na początku też o modelowaniu zagrożeń. To jest taka ciekawa dziedzina, ale chciałbym zostawić teraz modelowanie zagrożeń i pójść sobie dalej, bo kontekst w bezpieczeństwie, jak i w innych rzeczach jest context is the king całości tej układanki. I jak powinniśmy patrzeć, czy bezpieczeństwo ma swoje konteksty i czy możemy sobie pozwolić gdzieś, żeby to poluzować, odpuścić, a w innych miejscach dokręcić śrubę? Czy to jest bardzo płynne? Czy nie powinniśmy tak podchodzić? Jakie jest Twoje w ogóle podejście do całości takiej układanki?

Andrzej Dyjak Wiesz co to? Tutaj odpowiedź będzie wyrównana z tym, co powiedziałem wcześniej. Oczywiście, że tak. Należy tutaj rozważyć. To nie jest tak, że wszystko musi być na tym samym poziomie bezpieczeństwa, bo jest to nieracjonalne. Racjonalne jest podejście ekonomiczne. Najczęściej realizuje się to w taki dość prosty sposób, czyli pewnie każdy, kto pracował w większej organizacji kojarzy, rozbiciem systemów na kilka kategorii. Czyli mamy systemy, które mają większe ryzyko i one mają swój jakiś priorytet i mamy systemy, które mają mniejsze ryzyko. Takim dobrym przykładem jest, jeżeli mamy wewnętrzny system, który jest udostępniany tylko dla naszych pracowników i nie jest widoczny z internetu, to wiadomo, że taki system nie potrzebuje takich samych kontroli i bezpieczeństwa, takich samych procesów jak system, który jest udostępniany dla naszych klientów i jest widoczny z sieci publicznej internet. I w jednym i w drugim będziemy trochę inaczej dbać o bezpieczeństwo. Przez dbać o bezpieczeństwo mam na myśli, że te procesy, o których wcześniej mówiłem, mogą być dla niektórych rzeczy realizowane, a dla niektórych rzeczy w ogóle nierealizowane. Tutaj wspomniałeś o modelowaniu zagrożeń. Czy modelowanie zagrożeń powinno być robione dla każdego systemu albo dla każdej zmiany? Nie, raczej nie, bo ten proces jest dość drogi. Trudno jest go automatyzować w takim wydaniu, że narzędzie samo mi zrobi. Muszę wciągnąć ludzi. A skoro muszę wciągnąć ludzi, to będzie to kosztowne. Więc nie chcę robić tego dla wszystkich systemów, czy trochę idąc w stronę Agile, dla każdej zmiany, która przechodzi mi przez organizację. Ale to co mogę zautomatyzować, czyli jakieś skany statyczne czy skany dynamiczne w wydaniu takim mocno automatycznym, może to chcę mieć dla każdej aplikacji czy dla każdej zmiany, bo to tak naprawdę kosztuje mnie tylko jakiś czas procesora. Oczywiście mocno upraszczam, bo potem ewentualnie te błędy trzeba obsłużyć, więc to jest dodatkowy koszt, ale z czasem tych błędów jest coraz mniej, więc ten koszt raczej idzie w kierunku zera. A ten koszt związany z procesorem, on będzie mniej więcej stały, bo cały czas będziemy potrzebowali tyle samo procesora. Więc pewne rzeczy chcemy mieć zawsze jako pewnego rodzaju granicę tej drogi, a pewne rzeczy chcemy sobie dodawać w zależności od tego, czy system jest dla nas ważniejszy lub mniej ważny i często gęsto to mniej ważny lub ważny definiuje jakaś polityka wewnętrzna dla organizacji, która ma jasno spisane, że systemy, które przetwarzają dane osobowe i są wystawione na zewnątrz, mają klasyfikację taką i taką, a systemy, które tego nie robią mają taką i taką. A potem w dalszej polityce mamy, że bezpieczeństwo i to już taka konkretna polityka bezpieczeństwa w procesie wytwórczym mówi, że np. analiza statyczna ma być dla wszystkiego, ale modelowanie zagrożeń już nie musi być dla wszystkiego, ma być wtedy, wtedy i wtedy, powinno być. Więc da się to układać pod system. Tutaj też dochodzą organizacje, więc tutaj mamy dodatkowy ten taniec z organizacją. Pewne organizacje przykładowo są nadzorowane. Banki, ubezpieczenia muszą spełniać więcej wymogów związanych z bezpieczeństwem ich systemów, niż przykładowo pierwszy lepszy software house. Więc to też nam to daje. Przy czym są też standardy, o których w zasadzie dzisiaj nie wspomniałem, ale przykładowo jest taki bardzo popularny standard: Application Security Verification Standard, który definiuje kontrole bezpieczeństwa, które należy weryfikować w celu zapewnienia odpowiedniego poziomu bezpieczeństwa aplikacji nie tylko web aplikacji, ogólnie aplikacji. I ten standard jest podzielony na trzy poziomy - na poziom pierwszy, drugi, trzeci. I znowu on mówi, że tam poziom pierwszy powinny spełniać wszystkie aplikacje. Poziom drugi powinny spełniać aplikacje, które mają użytkowników. A poziom trzeci powinny spełniać aplikacje krytyczne, przykładowo aplikacje, które przetwarzają transakcje finansowe. Więc tutaj też możemy nie tylko brać nasz profil ryzyka organizacji, tego, co wymaga na nas regulator, ale jeszcze możemy się bawić tym kawałkiem ASVS-a. Takie poziomy ASVS-a też możemy sobie sami robić. Natomiast w zasadzie ten kawałek to jest właśnie duża część pracy świadomego bezpiecznika - wybranie tego co powinno być robione, kiedy. I potem ułożenie tych procesów, żeby one działały. Natomiast to jest, można powiedzieć, jedna z głównych wartości, które wnosi bezpiecznik.

Szymon Warda: Dobra, to powiedziałeś takie magiczne słowo, które może być trochę zachętą dla osób nas słuchających, że łatwiej jest zrobić z developera osobę od security niż odwrotnie. Więc teraz pytanie, w takim razie sprawdzam jak stać się osobą od bezpieczeństwa, ale taką współczesną, nie takim bezpiecznikiem, tylko właśnie DevSecOps i nowoczesne podejście? Jak zacząć, gdzie się uczyć, czego się spodziewać, jak wygląda rynek?

Andrzej Dyjak Jasne, najlepiej zacząć od narzędzi procesowych ze stajni OWASP. Właśnie od tego ASVS-a, o którym wspomniałem. To nawet jest taki drugi krok, bo pierwszy to jest OWASP Top 10. Ale jeżeli chcemy iść w kierunku, że faktycznie chcielibyśmy się zacząć zajmować bezpieczeństwem, to najlepszym takim drogowskazem, który opisze całość różnych praktyk, które powinny się dziać w procesie wytwórczym i jak one mogą się dziać, bo też będą po prostu opisy tego, jak to może wyglądać, to jest projekt Software Assurance Maturity Model, czyli model dojrzałości, zapewniania bezpieczeństwa w procesie wytwórczym, również z OWASP-a. I jest bliźniaczy model Building Security Maturity Model, który jest komercyjny, to jest firmy Synopsys, ale materiały też można sobie za darmo pobrać i zobaczyć, jak one działają. Więc iść w kierunku OWASP-a. Ale tu niestety nie mam takiej idealnej odpowiedzi, bo o ile te narzędzia powiedzą na czym polegają te praktyki, co powinno gdzie być, jak to mniej więcej powinno wyglądać, to niestety nie ma żadnej takiej konkretnej odpowiedzi, takiej hands on, że mogę Ci powiedzieć, powiedzmy przy nauce testowania bezpieczeństwa, to mogę ci podać: to ściągnij sobie Juice Shopa, ściągnij sobie Web Security Testing Guide, zacznij przerabiać jedno, ćwicz na Juice Shopie i tam za 3 miesiące będziesz umiał ocenić podstawowe właściwości bezpieczeństwa aplikacji. To tutaj czegoś takiego nie ma. Niestety wymaga to więcej takiego odkrywania mapy samemu, bo nie ma jakiejś takiej jasnej ścieżki jak można w to jasno wskoczyć. Chociaż, a może nie chociaż, tylko właśnie dlatego w mojej ocenie programiście będzie łatwiej przejść z bezpieczeństwa niż bezpiecznikowi w programowanie, bo jednak programista znając cały proces wytwórczy i wiedząc co to jest taka rzecz jak analiza statyczna czy komponenty czy biblioteki, bo po prostu korzysta z tych narzędzi, to łatwiej w głowie mu się zbuduje ten model: a to tutaj mogę dodać to narzędzie, ono mi powie, że mam tutaj błąd. Albo tu mogę dodać to narzędzie, ono mi powie w tym kawałku procesu, że mam podatną bibliotekę, bo po prostu zna cały proces wytwórczy. Bezpiecznik popatrzy na narzędzie, ale nie do końca będzie wiedział, takie klasyczne, nie do końca będzie wiedział czemu, co, gdzie wyskakuje i jeszcze na czym to konkretnie polega, o ile faktycznie je umie dobrze programować. Tacy bezpiecznicy się zdarzają, ale jest po prostu ich za mało. Polecam bezpiecznikom też pójście w douczenie się takiej inżynierii oprogramowania. Ale idealnej odpowiedzi nie ma, jak się tego nauczyć. Raczej metodą prób i błędów, zacząć od tych narzędzi procesowych z OWASP-a. Tam jest multum referencji, więc zacząć od tego. I jeszcze zapytałeś, jak wygląda sytuacja pod kątem nazwijmy tam opportunities? Sytuacja wygląda bardzo dobrze, czyli jest bardzo duże zapotrzebowanie na bezpieczników, którzy znają się na programowaniu, na ludzi od DevSecOps, na ludzi, nawet po prostu od DevOps jest bardzo duże zapotrzebowanie. A jeszcze jeżeli dołożymy do tego bezpieczeństwo, a miałem do czynienia z takimi zespołami, gdzie mamy np. inicjatywę inżynierów DevOps i trzeba im dorzucić warstwę bezpieczeństwa, to te osoby często gęsto bardzo szybko łapią to bezpieczeństwo. I dla nich jest to zestaw narzędzi, które sobie dobierają, niż coś, co muszą potem się uczyć i studiować, bo one to wszystko wiedzą, tylko po prostu np. nie wiedziały, że jest coś takiego jak CodeQL albo Semgrep. To jak im powiesz i pokażesz: patrz tu masz to i to robi to, to od razu im się zapala lampka, bardzo szybko to łapią. I ich wartość na rynku momentalnie wzrasta, bo łatwiej się sprzedać jako DevSecOps, chociaż jako DevOps w chwili obecnej też łatwo. Więc opportunities na rynku są bardzo duże w chwili obecnej, szczególnie w firmach na zachodzie, bo jak zwykle one są trochę do przodu, więc u nich to już jest chleb powszedni, a u nas zaczyna być chlebem powszednim.

Łukasz Kałużny: Wiesz co, Andrzej, patrząc się przez nasze podcasty, bo zawsze z Szymonem stwierdzamy, że przynajmniej minimalna wiedza z zakresu sieci, podstaw, jak i programowania powinna być chlebem powszednim dla każdego, kto chce iść dalej.

Andrzej Dyjak Zgadzam się w stu procentach.

Łukasz Kałużny: I co najciekawsze, poprzednia rozmowa z Andrzejem Sobczakiem na temat Enterprise Architecture, on wspominał, że dobrze jeżeli ktoś miał chociaż chwilę backgroundu jako programista.

Andrzej Dyjak Ja generalnie nie wyobrażam sobie jak ktoś może pracować z komputerami i nie umieć programować, ale naprawdę programować, typu znowu nie zakoduje “Hello world” w Pythonie, tylko napisze od początku do końca web aplikację i jeszcze ją wystawi do internetu. Ta web aplikacja to może być najprostszy, ale jeżeli ja przejdę ten proces, to ja już wiem: a dobra, to mam coś takiego jak kontroler, mam jakiś widok, który mi się coś pojawia, a żeby to wrzucić na serwer to muszę zrobić jakąś paczkę, muszę spiąć, potok, tu coś zrobię, tu mi się coś tam pojawia i nagle się otwierają pewne drzwi w głowie. I teraz z mojej własnej historii, bo ja zaczynałem od bezpieczeństwa, potem miałem romans z inżynierią oprogramowania, a potem znowu wróciłem do bezpieczeństwa, to tak naprawdę dopiero ten romans z programowaniem i z pisaniem oprogramowania, z innymi ludźmi, dopiero ten moment tak naprawdę otworzył mi oczy tak mocno na to, jak działają komputery. Więc wcześniej wiedziałem na takim poziomie jak działa maszyna, bo tam czytałem asemblera i C, ale dopiero ten moment jak zacząłem pisać programowanie z innymi ludźmi i wszedłem w proces wytwórczy, to mocno ugruntowały moją wiedzę i polepszyły zrozumienie IT. Więc polecam każdemu. Przy czym z mojej perspektywy należy to traktować jako maraton, a nie jako sprint, karierę swoją w IT. To nie jest tak, że trzeba w rok zrobić wszystko. Spokojnie, masz 10, 15, 20, 30 lat i jak chcesz, to na wszystko znajdzie się czas i da się to naprawdę ogarnąć i da się być dzikiem. Tylko to nie zajmie 3 lata tylko pewnie z 15.

Szymon Warda: Dobrze to kończymy w takim razie.

Andrzej Dyjak Tak, bardzo dziękuję za rozmowę. Trochę się na niektóre tematy rozpowiedziałem. Jeżeli ktoś chciałby doszczegółowić, to można mnie zaczepiać na socialach i będę starał się doszczegóławiać albo prostować, jeżeli popełniłem gdzieś błąd.

Łukasz Kałużny: Dobra, linki dorzucimy do odcinka.

Szymon Warda: A tych linków będzie dużo, więc tym bardziej zachęcamy generalnie. I też będą linki gdzie Andrzeja znaleźć i tak dalej.

Łukasz Kałużny: Dzięki Andrzeju.

Andrzej Dyjak Dzięki.