W najnowszym odcinku naszego podcastu gościmy Marka Zmysłowskiego, eksperta w dziedzinie cyberbezpieczeństwa, który dzieli się swoimi przemyśleniami na temat aktualnych wyzwań w branży IT. Rozmowa koncentruje się wokół trzech kluczowych tematów:

1. Wpływ sztucznej inteligencji (AI) na cyberbezpieczeństwo: Marek analizuje, jak AI zmienia landscape zagrożeń i metody obrony, jednocześnie tworząc nowe wyzwania dla specjalistów ds. bezpieczeństwa.
2. Ewolucja błędów w aplikacjach i trudności w ich wykrywaniu: Marek omawia rosnącą złożoność luk bezpieczeństwa, które wymykają się tradycyjnym narzędziom automatycznym, podkreślając potrzebę bardziej zaawansowanych metod testowania.
3. Komunikacja wartości cyberbezpieczeństwa w biznesie: Marek porusza problem niedoceniania inwestycji w bezpieczeństwo IT przez kadrę zarządzającą, proponując strategie efektywnej komunikacji między działami technicznymi a zarządem.

Ten wywiad rzuca światło na najnowsze trendy w cyberbezpieczeństwie, oferując cenne spostrzeżenia dla profesjonalistów IT, managerów i entuzjastów technologii.

Odcinek dostępny na YouTube, Spotify, Apple Podcasts i innych platformach.

Transkrypcja

Andrzej: Dzień dobry, wracamy z kolejnym, z kolejną rozmową. Tym razem gościłem Marka Zmysłowskiego. Myślę, że bezpiecznicy będą kojarzyć Marka, bo Marek jest starym wyjadaczem bezpieczeństwa i na arenie międzynarodowej i na naszej polskiej. Generalnie, jeżeli ktoś był na konferencjach polskich związanych z security, to Marka na pewno widział i pewnie się też przeciął. Marek to jest otwarta osoba z moich doświadczeń. Cześć Marku, witamy cię. Witam wszystkich, witam was. I teraz od razu z grobiej rury. Marek, ja wiem, że ty masz bardzo dużo doświadczenia w bezpieczeństwie aplikacji niskopoziomowym, ale nie tylko niskopoziomowym, bo na wyższym poziomie też operowałeś. Generalnie z aplikacjami i z ich bezpieczeństwem, no siedzisz w temacie już wiele lat, nawet chyba siódł dłużej niż ja. Powiedz mi, Jak widzisz, co się zmieniło, czy się zmieniło, na lepsze, na gorsze przez te wszystkie lata? Czy widzisz jakąś zmianę, czy nie? Czy cały czas popełniamy te same błędy i wywracamy się o własne nogi?

Marek: Czy popełniamy te same błędy? No to można sprawdzić najnowsze CV pewnie w tej bazie danych i znajdziemy jakieś XSS jeszcze, tak? W XXI wieku byłem na różnych konferencjach, gdzie zdarzało się nawet prezentację pod tytułem XXI wiek, a my nadal jesteśmy w XSS, więc tak, stare błędy popełniamy nadal. Część z nich zostało wyeliminowanych. Czy jest to zasługa security i tego awarenessu? Nie jestem pewien. Dużo rzeczy staramy się łatać technologią. Przesiadamy się na lepsze, w cudzysłowie, lepsze języki programowania, gdzie jest lepsze zarządzanie pamięcią, gdzie nie należy to już do programisty, tylko do samego frameworku, nie wiem, typu C-Sharp czy RAS, gdzie to działa zupełnie inaczej niż kiedyś, jak pisało się w czystym C. Czy w C++ niby memory corruption odchodzą do lamusa pomału? No ale coś za coś, więc za to przychodzą nowe błędy, nowe możliwości dają języki. no to jest nowe miejsce do popełniania kolejnych błędów. Czyli odstawiliśmy jedne, przyszły drugie, typu serializacje różnego rodzaju, gdzie tego jest coraz więcej.

Krzysztof: Ale widzisz właśnie Marek w tym problem, że to programiści nie są świadomi, po prostu dostali narzędzie, które jest idiotoodporne, mówiąc kolokwialnie.

Marek: Wiesz co? Ciężko powiedzieć, kiedyś pamiętam jak zaczynałem, przypominam się taki obrazek, taki trójkąt bezpieczeństwa, gdzie na każdym z tych szech rogów na jednym było bezpieczeństwo, na drugim było jakby użyteczność kodu z punktu widzenia programisty, czyli jak dobrze mu się używa tego API, a na trzecim wierzchołku było Była użyteczność z punktu widzenia użytkownika i zawsze gdzieś ta kropka jest w środku, to znaczy do którego wierzchołka byś się nie zbliżał, te pozostałe dwie cechy, od których się oddalasz będą gorzej. Nie da się zrobić tak, żeby wszystko było bezpieczne. Ale było super do użytkowania dla użytkownika albo idealne dla programisty. Bo programista sobie wywołuje jedną komendę, to mu się wszystko inicjalizuje, to już działa i to działa. No tak się nie da. Gdzieś ten środek musi być. Więc to wszystko zależy od programistów. Wydaje mi się, że w dzisiejszym czasie świat tak szybko goni, że też o tym zapominamy. To znaczy liczy się wynik, tak? Główna zasada, która… Znaczy ja nigdy nie sprzedawałem oprogramowania i nie pisałem oprogramowania, więc nie wiem, ale wydaje mi się, takie jest moje przeczucie, że jednak średnio działający software i średnio bezpieczny software, który jest dostępny, zarabia. Jeżeli poprawiamy błędy w softwarze, którego nie wypuściliśmy, on nie generuje pieniędzy. Co z tego, że mamy bezpieczny produkt, jeżeli go nie ma na rynku? Naszym celem czy celem osoby, która wytwarza oprogramowanie, jest jak najszybciej to sprzedać. Security zawsze gdzieś tam schodzi na dalszą stronę. Tak mi się wydaje i tak obserwuję.

Krzysztof: Tak, jakby dążenie do absolutnego bezpieczeństwa. to jest pewna utopia i WUDA z punktu widzenia biznesu ma być wystarczająco bezpiecznie na tyle, żebyśmy byli w stanie to wypuścić. A i tak z tym bywa różnie.

Marek: Tak, jeżeli ktoś jest świadomy, tak, ja nawet pamiętam jeszcze sprzed x lat, nie będę mówił ile, ilu, żeby nie było widać, że jestem tak stary. Jak byłem na studiach, to gdy mieliśmy jakieś zadanie programistyczne, to zawsze pierwsze pytanie było, czy program ma być idiotoodporny, tak? Czyli już na samym początku pytaliśmy, czy dbamy o to bezpieczeństwo, czy olewamy? I wtedy input będzie robiony tak, że tylko ja wkładam input, żeby pan nie popsuł oprogramowania, które napisałem, tak? To już na samym początku mojej drogi gdzieś tam już to było, że jednak bez tego security jest szybciej, więc dzisiaj szybciej znaczy taniej. tak, bo czas to pieniądz. No więc coś za coś.

Andrzej: Okej, ale tutaj tutaj przeciągnę ciebie za język. Oczywiście ja się z tym zgadzam, bo ja też wiem, że ty masz doświadczenie w automatyzacji bezpieczeństwa. Konkretnie dla aplikacji niskopoziomowych tutaj się używa technik fuzzingowych, fuzzingu. Czy widzisz, że fuzzing poprawił sprawę, nie poprawił sprawy, bo ja mam takie wrażenie, że z jednej strony poprawił, no bo jest, kod jest fazowany, są wykrywane błędy, ale z drugiej strony kodu jest jeszcze więcej niż było kiedyś i tylko jest go coraz więcej, więc tak technicznie to trudno jest mi powiedzieć, czy fuzzing tu naprawdę poruszył tą igiełkę.

Marek: Dla danej biblioteki tak. Jeżeli spojrzymy co robi teraz OSS Fuzz, czyli ta platforma do testowania od Googla dla darmowych aplikacji czy open source’owych aplikacji, bo żeby skorzystać z niej trzeba być open source, no to na pewno. Ilość błędów, gdzie? jak sobie poczytacie jakieś dokumenty na temat fuzzowania, to tam zawsze jest NG. tak to jest. to jest chyba taki. taka standardowa biblioteka którą wszyscy testują i na której wszyscy się się ścigają. na to ilość błędów znalezionych tam z fazingu jest gigantyczna. tak i nadal są znajdowane i i i coraz więcej z tego natomiast. Czy to dygnęło? No ja miałem kiedyś taką prezentację właśnie, żeby pokazać to, co ty mówisz Andrzej, że sprawdziłem ile jest wszystkich open source’owych projektów na Sourceforge’u i na GitHub’ie w C i C++’ie, tak? To były setki tysięcy. No to teraz, jeżeli community to jest setki tysięcy, no to nawet nie przypada, nie wiem, jedna osoba na jeden projekt, no to jest… To jest tak, kiedyś się mówiło, że jak jest coś open source, to jest wystarczająco dużo Ludzi tak, żeby na to patrzeć. I pamiętam, że mieliśmy taką dyskusję, jak ja pokazałem i znalazłem błąd, nawet w OpenSSL-u nie, ale gdzieś znaliśmy 25 lat miał. Tak, sam ten błąd w Baszu, on tam chyba też był z 15 lat.

Andrzej: Tak, on tam miał 10 albo 15 lat.

Marek: Na 12 lat, tak? I co ciekawe, to są informacje niepotwierdzone, gdzieś próbowałem to znaleźć, że podobno ten komit, który spowodował ten błąd, W Shell Shocku tak to było. Spowodował ten błąd. Początkowo został odrzucony, że może być, że może być szkodliwy, ale później został ten komit dopuszczony. Natomiast to jest niepotwierdzona informacja. Nie znalazłem tego nigdzie oprócz jednego artykułu, więc tych komitów już chyba tam nie ma, więc nawet nie da się tego x lat wstecz sprawdzić.

Andrzej: Tak, no ja gdzieś tam ze swojej własnej prywatnej bazy wiedzy, którą mam w głowie, też kojarzę mutum takich przypadków, gdzie błędy są odkrywane, ale one tam siedzą bardzo długo. w tym kodzie i takimi przodownikami pracy są różnego rodzaju błędy, czy w kernelu Linuxa, czy w źródłach, no i potem wejściowych binarkach Windowsa, gdzie potrafią siedzieć 30 lat. i potem ktoś odkrywa ten błąd i człowiek myśli, no kurcze, Microsoft tutaj ma ten błąd w jakimś subsystemie NT od 30 lat, no ale przecież oni fazują ETC. No właśnie, bo to nie jest tak łatwo znaleźć te błędy i one dalej mogą nam po prostu umknąć, pomimo tego, że robimy te wszystkie praktyki. Dążę do tego, żeby powiedzieć, że fazowanie, analiza dynamiczna, generalnie wszystkie praktyki, one nie są idealne, one nigdy nie stworzą produktu w 100% bezpiecznego, bo to co powiedziałeś, idąc w bezpieczeństwo, dodalamy się od innych wartości, które chcemy dostarczać software’owi.

Marek: Tak, i też, no bo z drugiej strony nie jest to proste, nawet jeżeli masz ten błąd, to taka Taki przykład z mojej jednej z przeszłych prac, gdzie fazowaliśmy jedną bibliotekę i tam był błąd. Nazwałbym to szkolny. Ktoś nie sprawdzał długości tablicy. Czyli czytaliśmy z tablicy, gdzie user podawał numer bajtu i tego nikt nie sprawdzał. I teraz to taki klasyczny przykład, pewnie książkowy. I teraz co ciekawe. Fazując to, dostawaliśmy dziesiątki różnych błędów. To też jest ten problem, że dostajesz dziesiątki różnych błędów, a błąd był jeden. Błąd był tylko w tym jednym miejscu, tylko w zależności od tego jaka długość była. No to tak wyglądało. Z drugiej strony np. ta sama biblioteka była napisana w ten sposób, że fragmenty w celu optymalizacji były napisane w assemblerze. I dla różnych jakby procesorów pewne fragmenty były w oddzielnych plikach assemblerowych. I okazało się, że kod napisany w C był napisany dobrze, bo tam była pętla dual, Nie, była pętla while, a ktoś napisał w assemblaże ten sam fragment i zrobił do while. Tam w jednym miejscu mieliśmy crusha, tak? No i teraz fazując tą bibliotekę w C. Nie dostawaliśmy żadnych wyników, bo tam błędu nie było. Więc tego typu problemy też się zdarzają i to też nie jest łatwo wychwycić. No a z drugiej strony dochodzi coraz więcej błędów związanych z logiką aplikacji. Czyli coraz bardziej stają się niebezpieczne rzeczy, których narzędzia nie są w stanie wykryć. jakiegoś rodzaju autoryzation, bypassy, gdzie ktoś Privilege escalations, ale nie takie proste, tylko gdzieś bardziej skomplikowane, gdzie potrzeba 5, 7, 10 kroków. No i to jest coś, czego nie wiem, czy będziemy w stanie kiedykolwiek wykrywać narzędziami automatycznymi, no chyba, że AI będzie to robiła za nas.

Andrzej: Właśnie, właśnie chciałem powiedzieć, że AI nadchodzi i wyeliminuje potrzebę bezpieczników, ale z tym to nie jestem taki pewien.

Marek: I tutaj jako kontrargument z pamięci nie przytoczę, jest gdzieś w sieci artykuł, tylko nie pamiętam, czy to jest PDF, czy to jest po prostu jakaś strona. gdzie było pokazywane, że AI generuje kod, który jest szkodliwy, w sensie niebezpieczny. Pokazywany był kod, który miał po prostu błędy bezpieczeństwa w sobie. AI to nie jest coś, co spłynęło nam z nieba. AI trzeba nauczyć. Uczymy to na średniej jakości kodzie, no to nie oczekujmy, że będzie to pisało kod niezwykle bezpieczny i piękny, i ładny, i szybko działający. Takie dane jakie wrzucimy, takie dostaniemy.

Andrzej: Dokładnie tak. Jak to się mówi w IT? Garbacz in, garbacz out.

Marek: Dokładnie tak.

Krzysztof: W kontekście reszty inteligencji, Marek, jak mówiłeś o tym złośliwym kodzie niskiej jakości, który jest produkowany przez generatywną inteligencję, to przypomniało mi się artykuł, który czytałem, który mówił o tym, że AI podpowiada paczki z NPM-a, między innymi z NPM-a, które kompletnie w tych repozytoriach paczek nie istnieją. Więc ktoś wpadł na pomysł, że jeżeli szukam rozwiązania problemu wpisując w GPT, jak połączyć np. do MongoDB i GPT odpisuje mi, no to musisz użyć takiej paczki i ta paczka nie istnieje, to zacznę po prostu te paczki zakładać, a dalej już wiecie co się chyba działo.

Marek: Tak, to już jest halucynacja i tego typu sprawy, to już jest kompletnie inna bajka, ale żebyśmy byli jasni, że to nie jest tak, że AI zawsze wygeneruje błędny, wadliwy czy niebezpieczny kod, oczywiście nie generalizujmy. Występują takie sytuacje, ale teraz kto to sprawdzi? No to znowu będą potrzebni bezpiecznicy, którzy…

Andrzej: Którzy to zwalidują w jakiś sposób.

Marek: Którzy poprawiają, poprawiają kod, no. Mi się tu kojarzy, akurat ostatnio oglądałem z synem Willie Wonka i tam była taka scena, gdzie ojciec tego Willie’ego został zwolniony z fabryki, która produkowała pastę do zębów, a na końcu został zatrudniony do automatów, które, które wyrzuciły go z pracy, ale ktoś musiał naprawiać te automaty, więc on znowu pracował w tej fabryce, naprawiając automaty, które pozbyły go wcześniej pracy. I to pewnie będzie tak samo, tak? Z jednej strony Część rzeczy AI nas pozbędzie, ale z drugiej strony będzie trzeba to kontrolować, bo jeżeli pozwolimy na wszystko, no to zobaczymy.

Krzysztof: Pytna analogie.

Marek: Tak, tak. Nie można puścić wszystkiego. Nie będę kontynuował.

Andrzej: Dobra, to w zasadzie z mojej perspektywy ja się wystrzelałem z pytań.

Krzysztof: Ja mam jeszcze takie jedno pytanie dla Ciebie Marek, takie bardziej filozoficzne, ogólne. Bezpieczeństwo w oczach biznesu widziane jako smutny obowiązek, czy może biznes enabler?

Marek: A to nie wiem, to trzeba pytać biznes. Ja zawsze miałem takie odczucie, że jednak to jest jakiś przykry obowiązek. Ludzie, którzy nie wiedzą na czym polega nasze bezpieczeństwo, bo to jest też tak, że wielokrotnie robiąc pentesty, znajdując błędy, mieliśmy na przykład problem wytłumaczyć osobie z managementu czy z wyższego managementu, dlaczego to trzeba naprawić. My to rozumiemy jako inżynierowie. Ja wam mówię, że tam był AXSS gdzieś tam w użytelnianiu czy w saldzie konta i tak dalej. Wy od razu widzicie oczami, gdzie tu można wstrzyknąć kod, żeby ukraść trochę forsy. Natomiast tym osobom to nic nie mówi. W związku z tym oni w pewnym sensie postrzegają też to bezpieczeństwo jako koszt. Dla nich jest koszt. Niestety, to jest moja opinia oczywiście, nic dla nich to nie przynosi. Oni nie mogą wpisać tego w Excelu, że zrobili 50 pentestów i oni na tym zarobili. Nie, oni muszą wpisać, że oni na tym stracili, a potencjalnie być może nie stracili więcej, ale to wiadomo, mądry Polak po szkodzie i to zazwyczaj tak jest. Dlatego myślę, że w dużych korporacjach i w takich tych jest też, ponieważ jest ogólne, rośnie świadomość tego niebezpieczeństwa i coraz więcej systemów jest takich, gdzie Gdzie zależymy w jakiś sposób od tego IT, tak? Gdzie jakieś włamy słychać malware w szpitalach, nie w szpitalach, tak? Więc ta świadomość rośnie, w związku z tym jest dużo instytucji dookoła tego, które narzucają to bezpieczeństwo, tak? Nie znam dokładnie przepisów, ale np. wiem, że jeżeli się ma instytucję finansową, to każdy coś ala nasz KNF obliguje taką instytucję do pewnego rodzaju bezpieczeństwa, typu pentesty, jakieś IZO itd., żeby jednak na siłę to podnieść. Oczywiście jest też druga strona medalu, jak jest popyt to i podasz i czasem te testy są na zasadzie odpalamy burpa ran.

Krzysztof: I wygeneruj mi raport.

Marek: I wygeneruj mi raport, później wrzucamy do OpenAI. I prosimy o to, żeby to przepisał, tak? I wypluwamy. I nam nie przeszkadza, że taki raport lata po całym świecie.

Andrzej: Done. Zrobione.

Marek: Tak jest, tak. Ja widziałem dużo, mam dzisiaj na prezentacji nawet taki slajd, gdzie pamiętam, jak kilka lat temu była taka akcja w Facebooku, który wysłał informację, że od dzisiaj te zdjęcia, które masz, to są jego. Ja nie pamiętam dokładnie o co chodziło, ja generalnie nie publikuję rzeczy, których się nie wstydzę. Nie mam w telefonie rzeczy, których się nie wstydzę, więc nawet jak ktoś mi się powłamuje wszędzie, to tam i tak nie ma rzeczy, którymi mógłbym je szantażować. I pamiętam jakie było poruszenie, że Boże, że prywatność, że zabierają nam, że nas okradają. Po czym OpenAI przyszedł i ludzie budują systemy retratingowe, wysyłają e-maile, robią sobie, nie wiem, tam oceny pracownicze, wpisują. No wszystko leci tam, ale jak Facebook chciał wziąć zdjęcie, nie, nie, bo to privac.

Krzysztof: Przedstawiają wyniki swoich badań krwi, sprawiają analizę.

Marek: Dokładnie tak, dokładnie tak. Jest też taka piękna scenka, taki rodzaj memu, ale taki rysunek jak pisze pracownik maila do menadżera i tam napisał dwa zdania, wrzuca do OpenAI, OpenAI mu generuje, wysyła to, a ten menadżer bierze to, wrzuca do OpenAI, żeby mi zrobił samadę. I na końcu on miał dwa zdania i ten menadżer też ma dwa zdania.

Andrzej: I tylko rozmowa pomiędzy OpenAIem z OpenAIem.

Marek: Dokładnie tak. No coś w tym jest.

Krzysztof: Tak jak ten mem ze Spidermanem.

Marek: Właśnie.

Andrzej: Dobra. Z naszej strony to wszystko. Dzięki Marek za wzięcie udziału w naszym mini wywiadzie. I do usłyszenia i zobaczenia później. Do zobaczenia.

Marek: Tak jest. Dzięki.

---