W pierwszym odcinku nowego sezonu 2025 podcastu, Andrzej i Krzysiek zagłębiają się w „dramę” związaną ze zmianą licencji przez Semgrep – wiodące narzędzie do statycznej analizy kodu pod kątem bezpieczeństwa. Okazuje się, że wielu dostawców rozwiązań ASPM (Application Security Posture Management) wykorzystywało Semgrep, tworząc bezpośrednią konkurencję dla jego komercyjnej wersji. Dyskutujemy, czy takie działania są etyczne i jak wpłynęły na decyzję firmy Semgrep o zmianie warunków licencjonowania, pomimo braku wkładu ze strony firm wykorzystujących ich narzędzie.
Kluczowe wątki poruszane w odcinku
- Hakowanie Subaru i Realne Zagrożenia Finansowe: Na koniec analizujemy przypadek zhakowania Subaru przez Sama Curry’ego. Prowadzi to do wniosku, że wiele podatności, choć spektakularnych, nie zawsze ma realny wpływ na bezpieczeństwo, a prawdziwym zagrożeniem w świecie cyberbezpieczeństwa są ataki motywowane finansowo.
- Incydent z OpenGrep i Wycieki Sekretów: Odcinek porusza humorystyczny, choć przerażający, przypadek, w którym jeden z kontrybutorów do OpenGrepa (sforowanego Semgrepa) zapomniał zarezerwować nazwę swojej paczki w oficjalnym rejestrze PyPI, co umożliwiło researcherowi wstrzyknięcie złośliwego kodu. Ten incydent, naprawiony w ciągu 17 minut, podkreśla problem wycieków sekretów i brak dbałości o bezpieczeństwo nawet w firmach zajmujących się cybersecurity.
- „Living Tradition” Google: Hackowanie Pracowników i Wzrost Bezpieczeństwa: Dyskutujemy o „Living Tradition” w Google – 15-letniej tradycji hakowania własnych pracowników w ramach legalnych ćwiczeń. Ta praktyka przyczyniła się do podniesienia bezpieczeństwa produkcyjnych systemów, wdrożenia HSTS i poprawy procesów aktualizacji Chrome, pokazując wartość etycznego hakowania w praktyce.
Odcinek dostępny na YouTube, Spotify, Apple Podcasts i innych platformach.
Transkrypcja
Andrzej: Panie, panowie, startujemy z nowym sezonem, sezonem 2025. Wracamy w błysku, w plasku, w plasku i chwalę ku uciesze gawiedzi.
Krzysztof: Nowy sezon, Andrzej, nowy sezon. i to jest dotychczas mój najdłuższy podcast jako seria, który prowadziłem, bo jedyny w tym miesiącu. wybija nam rok.
Andrzej: Zgadza się, zgadza się. Pierwszy odcinek wleciał rok temu i można powiedzieć, że ten rok był całkiem owocny. Z mojej perspektywy dowiedzieliśmy całkiem sporo, nie tylko podcastów, ale też innych różnych rzeczy. Jak ty oceniasz tamten miniony już 2024 rok?
Krzysztof: No, było grubo. Powiem tak naprawdę, jakbyście spojrzeli na ilość materiałów, które są na kanale. No to sami możecie ocenić, czy próżnowaliśmy, czy jednak pracowaliśmy. Wydaje mi się, że ciężko pracowaliśmy, Andrzej. I naprawdę dużo fajnych materiałów wpadło na kanał. Nie tylko związanych z samym podcastem, w którym my rozmawiamy między sobą, ale również z ciekawymi gośćmi. Był kongres, z którego są nagrania prelekcji. Więc, kurczę, naprawdę tego było sporo.
Andrzej: Tego było sporo, a były przecież jeszcze jakieś wystąpienia na konferencjach, no i oczywiście samo szkolenie ABCD, które będzie miało kolejną edycję już niedługo, pod koniec tego kwartału. O tym będziemy mówić nie dzisiaj, bo tutaj nie jesteśmy przygotowani, żeby mówić o tym dzisiaj, ale będziemy jeszcze o tym mówić. Krzysiek, dobra, jak już zrobiliśmy intro, jak już się powitaliśmy, to powiedz mi… Co ostatnio tobie wpadło na talerz i dlaczego była to drama związana z tym grepem?
Krzysztof: Dlaczego to była drama związana z tym grepem? Ponieważ jak wszyscy wiemy, przynajmniej wiem ja i ty Andrzej, SEMGREP jest w zasadzie bezkonkurencyjnym narzędziem, jeżeli mówimy o statycznej analizie pod kątem bezpieczeństwa. i SEMGREP w grudniu przed samymi świętami zmienił warunki licencjonowania. I tak naprawdę okazało się, że branża była, można powiedzieć, w pewien sposób bezbronna na ten bold move Semgrepa, ponieważ wiele rozwiązań klasy ASPM, czyli Application Security, Posture Management, takich kombajnów, które wiążą w sobie wiele różnych rozwiązań. od Sasta po Sekrety, Dasta, SC i tak dalej. W zasadzie większość rzeczy, o których mówiliśmy na przykład w ABCD, o którym już mieliśmy nie wspominać. Właśnie, no i okazało się, że duża część konkurencji SEMGREPA po prostu wykorzystuje w tych swoich kombajnach SEMGREPA pod spodem. co wydaje się racjonalnym ruchem ze strony biznesowej firmy SEMGREP, aby położyć kres takim działaniom. No i położyli ten kres właśnie poprzez zmianę licencji. Oczywiście oni tam dali pewien grace period dla swojej konkurencji, dla tych pozostałych vendorów, żeby mogli się wycofać z używania SEMGREPA w swoich rozwiązaniach. Jest tak w dużym skrócie.
Andrzej: Tak, Krzysiek, natomiast tutaj będę musiał dopowiedzieć, bo ty jak na inżyniera przystało, opowiedziałeś to tak po inżynieryjnemu, ze szczegółami, to teraz wjadę ja cały na biało i powiem z perspektywy architekta, czyli wiadomo, wysokopoziomowej na dużych klockach. Cały galimatias jest o to, że te rozwiązania, o których wspomniałeś, te kombajny, te ASPM-y, takie duże kobyły, które wdrażamy po to, żeby ten kod, te aplikacje, które wytwarzamy na końcu były bezpieczne, zaczęli w pewnym momencie korzystać z SEMGREPA pod spodem. i wykorzystywać ten jego silnik wraz z regułkami. Oni oczywiście sobie dopisywali swoje regułki i dodatkowe funkcjonalności budowali na tym Semgrepie. Ale tutaj ważnym faktem jest to, że po prostu wzięli sobie rozwiązanie open source, wdrożyli je pod spodem i niejako tworzyli bezpośrednią konkurencję dla samego Semgrepa, który ma oczywiście wersję open source, ale też… jest rozwiązaniem komercyjnym. I jest to taka sytuacja, gdzie ja bym coś wyprodukował, a potem ty przychodzisz do mnie, bierzesz to i sprzedajesz jako swój produkt. Co z jednej strony jest okej, no bo przecież była licencja open source, no ale… No to jest okej, ale wiecie, to jest tak samo jak ze sredu do paczkomatów, nie? No nikt tego nie zabrania, prawo tego nie zabrania. No ale i tak się nie powinno tego robić. I tak samo tutaj, może nie tyle nie powinno, no bo ja też rozumiem, biznes is biznes, tak? Biznes is biznes. W biznesie wszystkie chwyty są dozwolone i oczywiście o ile zamykają się w granicach prawa, to są dozwolone. I ci vendorzy mieli jak najbardziej prawo wykorzystywać Semgrepa jako narzędzie pod spodem i sprzedawać, robić tak naprawdę reselling. Ale czy autorzy Semgrepa mogą w tym wypadku poczuć się, jakby ktoś ich wykorzystywał? Jak najbardziej tak. Ta firma może poczuć się, że inne po prostu korzystają z niej, nie dając nic. W zamian. Ja widziałem takiego posta dzisiaj na LinkedInie, gdzie jakiś nie wiem, czy to był pracownik SemGrepa, ale generalnie ktoś zrobił listę top kontrybutorów do SemGrepa przez cały projekt, przez całe życie. tego projektu i wyszło, że w zasadzie jakbyśmy wzięli top 10 kontrybutorów do SEMGREPA, no to wszyscy pracowali w SEMGREPA.
Krzysztof: Tam bodajże z tego co pamiętam, że ponad 60% ogółem wszystkich kontrybutorów do SEMGREPA to byli ludzie, którzy byli związani bezpośrednio z firmą SEMGREP. I co, jak na ironię, jak kotna płaka było tam szukać tych wszystkich ludzi z tych pozostałych firm, którzy wykorzystywali SEMGREPA pod spodem w swoich rozwiązaniach jako Sasy?
Andrzej: Oczywiście. A teraz nagle jak SEMGREP zmienił tą licencję i biznes model tych firm zaczął się już nie spinać, no to nagle się okazuje, że a no nie, to w takim wypadku my sobie sworkujemy i my sobie zrobimy naszego OpenGREPA. ku uciesze, to co już powiedziałem w intrze, ku uciesze gawiedź, bo owszem. Użytkownik końcowy, potencjalny klient, dla niego to będzie tylko sytuacja idealna. On na tym korzysta. On na całej tej sytuacji tylko korzysta. Ale kto traci? Traci biznes w formie SEMGREPA. Tracą ci founderzy, którzy niejako poświęcili x czasu na budowanie. W silnikach analizy statycznej narzędzie silnik jest najtrudniejsze do zbudowania. Potem rozbudowanie regułek. to już jest Easy Peasy Lemon Squeezy. Już pomijam, że w dzisiejszych czasach AI LLM, tak? Ale to silnik jest tutaj najtrudniejszy i… nasi słuchacze mogą nie wiedzieć, ale SEMGREP jest kontynuacją narzędzia S-GREP, które było wydane w Facebooku, oryginalnie właśnie zbudowane do analizy statycznej, a S-GREP też jest kontynuacją narzędzia Coxinel. Generalnie te kontynuacje, kolejne iteracje pewnego… Spiritual Ancestor. Można trejsować do Coxinelle, które wyszło w 2003, 2004 i było napisane przez, o ile dobrze kojarzę, Juliena Val, taką francuską panią profesor, która zajmuje się bezpieczeństwem. I oczywiście to było jako coś w akademii, to było rozwiązanie takie akademickie. Natomiast… Dochodzimy do tam 2017, kiedy powstaje firma Semgrep. Semgrep powstaje, upublicznia swoje rozwiązanie, budują firmę i teraz nagle dochodzimy do 2024 roku, gdzie Semgrep musi zmienić model licencyjny i musi to zrobić, dlatego że… przez tę deltę pomiędzy 2017 a 2024 pojawiło się sporo vendorów, którzy po prostu sobie wciągnęli Semgrepa i zaczęli z niego korzystać i odsprzedawać swoje narzędzia. I jest to o tyle, znowu, jest to dozwolone, więc nie ma problemu, ale jest to o tyle, można powiedzieć… Nie chcę używać słowa nieetyczne, bo znowu, czy jest nieetyczne? Może jest etyczne, zależy jak sobie etykę zbudujemy. Ale myślę, że każdy zrozumie, że jest to o tyle drażniące autorów Semgrepa, bo te wszystkie firmy, które go wykorzystywały, tak naprawdę za bardzo nie kontrybuowały. Po prostu brały i nic nie dawały od siebie. Gdyby jeszcze coś dawali, ale oni brali… Nic nie dawali od siebie, a teraz nagle wielka inicjatywa i zaraz jeszcze przejdziemy do tego małego fuck upu, który wyniknął. Może gdyby poświęcili więcej czasu na inżynierię, a mniej na marketing, to by wyszło trochę inaczej, ale chciałbym też tutaj ująć, że tam jest taki startup Aikido. Aikido ma świetny marketing, ale my już… Krzysiek, rozmawialiśmy kilka razy prywatnie o tym, jak dobry marketing ma Aikido. Aikido ma dobry marketing nie dlatego, że… founder czy CEO jest taki dobry z marketingu, tylko po prostu mają funding i zatrudnili ogarniętego człowieka od growth hackingu, który im robi dobry marketing. I to nie jest pierwsza sytuacja, w której Aikido bierze sobie różne artefakty, no wiadomo, skoro są open source, to mogę je wziąć, prawda? A mogę je przepuścić przez LLMA. i no to nie jest tak, że ja skopiowałem twój pomysł. Chociażby te ichniejsze listy, które oni publikują, Nie będę mówił jakie. Jak ktoś będzie chciał, to sobie sam znajdzie. Natomiast listy, które publikują, dziwnym trafem takie same listy były już prawie dekadę temu, publikowane przez inną firmę security, która w pewnym momencie została wykupiona, te listy zniknęły. Natomiast chodzi o to, że… Owszem, w Aikido ludzie od marketingu nie są w ciemie bici, ale widać też, na co idzie realnie tam hajs. Dużo hajsu idzie na pewno na marketing. Czy od strony inżynierii, czy od strony produktu jest tak samo? Nie wiem, nie próbowałem, więc nie będę się wypowiadał z tego, jak wygląda to narzędzie. I też opinie ludzi, których opinie respektuję, wychodzi na to, że Aikido jest całkiem przyjemny i może faktycznie robić ciekawe rzeczy i może realnie będzie jakimś liderem. Co jest dużym plusem, bo są z Unii Europejskiej, z Belgii, o ile dobrze pamiętam. Ale abstrakując od tego, Aikido, wszystkie te inne firmy, które teraz się zrzuciły na OpenGrapha, no wcześniej nie przyszło im do głowy, że może należałoby coś kontrybuować do projektu open source. Nie, wcześniej to nie. Dopiero teraz, jak SamGraph się… wypiął. To teraz, a dobra, to zróbmy. I jeszcze ten płaszczyk taki delusions of grandeur, typ o, chcemy zdemokratyzować SAS, zdemokratyzować SAS, niech każdy ma dostęp, dlatego to robimy. No to może napiszcie od nowa ten swój silnik do SAS-ta i tak będziecie demokratyzować, czy nie, czy może jednak weźmiemy coś, co ktoś już napisał i tak będziemy demokratyzować. No okej, okej. Ferenc, nie?
Krzysztof: Tak, tak, tam w tej całej dyskusji przetaczają się głosy rozsądku, znaczy to wiecie, tutaj głos rozsądku w zależności po której stronie stoicie, jak sobie ułożycie tą linię etyczną, gdzie ona przebiega, ale podobało mi się, jak ktoś napisał, okej, no to w takim razie do tych, tutaj jest bodajże 10 albo 11 film, które zawiązało taką koalicję dookoła tego nowego rozwiązania, czy nowego starego rozwiązania, czyli Open Grepa, sworkowanego Sem Grepa. powiedział, dobra, no to pokażcie jakieś swoje projekty open source’owe. Jeżeli tak bardzo zależy wam na kontrybuowaniu do społeczności open source, no to gdzie macie jakieś agenty runtime’owe związane z bezpieczeństwem? Gdzie macie jakieś dusty open source’owe i tak dalej? No i wszyscy… Nasze incentywy są związane teraz z tym, że my po prostu chcemy demokratyzować dostęp do SaaS dla wszystkich, ale przede wszystkim dla tych dziesięciu firm, które robią na tym biznes.
Andrzej: Dokładnie, który robił na tym pieniądze i gdyby to jeszcze były firmy bootstrapowane. Ale nie, to są firmy tak naprawdę bakowane przez VC, a wiemy, w VC gra się nie toczy o to, żeby… gra się toczy o to, żeby wygrać i zwrócić hajs inwestorom, bo to oni mają zarobić. To nawet nie jest tak, że founderzy tam zarabiają jakieś miliony, no bo bądźmy szczerzy, czy Aikido będzie unicornem, które kiedykolwiek zostanie sprzedane za miliard czy dwa? Nie jestem pewien. Wydaje mi się, że jest w zbyt dużej niszy, żeby było aż tak dużym unicornem. Kto wie, nie wydaje mi się. Natomiast jak są te mniejsze ceny, no to wiadomo, wtedy automatycznie fanderzy, no biedni nie będą, ale na listę miliarderów, czy po angielsku bilionerów, też się nie zapiszą po takim evencie. Natomiast ci, którzy inicjalnie włożyli w to hajs, Oni na tym wykręcą większość. I na koniec dnia o to chodzi tym biznesom. Po prostu mają się spinać i te wszystkie bajki, które są ciśnięte na social mediach tychże firm, można włożyć tam, gdzie pasują, między bajki. I chciałem tu zaznaczyć jedną ważną rzecz, bo w niektórych komentarzach też widziałem już wypowiedzi osób operacyjnych, po prostu inżynierów czy architektów z tychże firm. które podchodzą jak to zwykle osoby operacyjne merytorycznie. Tylko często takie osoby nie rozumieją, że te osoby ponad nimi, biznesowe, nie patrzą na tą grę w ten sposób. I kupują tą taką bajkę, ten fairy tale, że nie, my tutaj robimy to dla nas. Nie. Na górze to nie jest robione dla zasady, tylko jest to zrobione, żeby zrobić hajs. Bo gdyby nie było, to niepotrzebny byłby VC funding. A skoro VC wchodzi i jest funding, to jest robione dla hajsu. I jesteśmy dorośli, nie musimy sobie opowiadać bajek. Bo bajki są dla dzieci i dla dorosłych, którzy są naiwni i się zachowują jak dzieci. Nie ma nic złego w robieniu pieniędzy, o ile… No. o ile nie łamiemy prawa. No chyba, że mamy tyle pieniędzy, że już nam nikt nic nie zrobi, ale to nam nie grozi. Niestety, Krzysiek, problemy. Ale chciałbym, żebyś jeszcze poruszył ten jeden mini wątek, który zauważyłeś i wpunktowałeś w swoim dzisiejszym poście, bo był to fab.
Krzysztof: Jest tak, jest przezabawny, ale też troszeczkę straszny, bo jeden z researcherów Rohit Kumar. To jest hindus. Był przez kilka lat top security researcherem w mecie. Po prostu zarabiał na backhunting, usługając podatności w produktach od mety. Zauważył, że w OpenGrepie, czyli w tym sworkowanym SemGrepie, w README, w instrukcjach dotyczących instalacji OpenGrepa, bo to jest paczka Pythonowa, ta instalacja przebiega w taki sposób, że podajemy tam jeszcze jeden dodatkowy parametr i nie zaciągamy tej paczki bezpośrednio z PIP, tylko zaciągamy ją z rejestru githubowego. Ale problem tkwi w tym, że te 10 firm zapomniało zarezerwować sobie tej nazwy w oficjalnym rejestrze paczek Pythonowym, czyli w PIP. A podczas robienia PIP install precedens bierze jednak to oficjalne repozytorium, więc jeżeli pojawi się paczka w oficjalnym repozytorium PyPI, no to ona w pierwszej kolejności zostanie zaciągnięta, pomimo tego, że mamy podany ten argument, który wskazuje, że jednak byśmy chcieli tantą, tą inną z GitHub’a. No i on studiując dokumentację wpadł na to, że hmm, faktycznie kojarzę, że już robiłem coś takiego w innej firmie z inną paczką. No i po prostu stworzył paczkę, wypuszował ją dompa API. Ta paczka nie robiła z wiele, ona po prostu zbierała output z komendy ID i uname i wysyłała na jego serwer. No i wytknął to. open grepowi, że no słuchajcie, coś tutaj chyba nie gra, no i oczywiście w popłochu to zostało naprawione, oni się z nim skontaktowali, sytuacja jest już pod kontrolą, ale to tylko pokazuje, jak bardzo te firmy skupiły się, tak jak powiedziałeś, Andrzej, na marketingu. Firmy, które powinny w zasadzie nas chronić, mogły mieć naprawdę mega poważnego backdoora. w swoich rozwiązaniach.
Andrzej: No, technicznie to nawet nie mogły mieć, tylko należy uznać, że miały. Gdyby nie trafiły na kogoś, kto po prostu ich poinformował, co jest super zabawne, biorąc pod uwagę, że mówimy o vendorach z security. I teraz tak, bezpiecznicy będą mówić o, jak to trzeba wykazywać się paranoją, jak to trzeba dbać o bezpieczeństwo, a nawet bezpiecznicy nie potrafią bezpieczny sposób zdeployować narzędzia, które komuś najpierw pożyczyli sobie od niego, sworkowali. Więc to jest takie, można powiedzieć, zwięzłe podsumowanie branży, nie? XD. Ale trochę szerszej. Nie tylko cyberbezpieczeństwo, tak ogólnie techu. Tak
Krzysztof: i tutaj tip dla was, jeżeli korzystacie z prywatnych rejestrów swoich paczek, czy nie bezpośrednio z tych oficjalnych rejestrów, to zawsze jest dobrze sobie sklejmować nazwę takiej paczki w oficjalnym publicznym rejestrze i bardzo często na przykład na NPM znajdziecie takie paczki, które są puste i w README mają jedynie taką notkę, że to jest security holding package i to jest jej cały cel. Po prostu ma zarezerwować nazwę, nic więcej.
Andrzej: Dokładnie tak. I my o tym nawet mówiliśmy w tym szkoleniu, o którym już mieliśmy dzisiaj wspominać. To właśnie tak.
Krzysztof: Nie możemy się powstrzymać.
Andrzej: Ale, Krzysiek, dobra, tyle o sprawie, czy tam mamy w akapie związanym z semgrepem, mała dramka, wiadomo, to i tak się rozejdzie po kościach. Po wynikach ich poznamy, zobaczymy, jak to będzie wyglądać za 3, za 6, za 9, za 12 miesięcy, jak wygląda projekt, czy nie umrze śmiercią naturalną, bo mówić można dużo, szczególnie za hajs inwestorów, ale zobaczymy, co zostanie dowiezione. pod płaszczykiem tych wszystkich dyskusji, które teraz wynikały. Krzysiek, ja mam jedną rzecz, o której chciałbym powiedzieć. Pobieżnie, chociaż zobaczymy jak bardzo pobieżnie, ale czy jest coś, co ty chciałbyś poruszyć? Czy było ewidentnie twoją uwagę w tym minionym miesiącu?
Krzysztof: Tak. Dosłownie można powiedzieć, że nie w tym miesiącu, pod koniec zeszłego roku, pod koniec zeszłego miesiąca, bo ja o tym nie wiedziałem, a wiem Andrzej, że ty o tym wiesz, że Google miał taką piętnastoletnią tradycję hakowania własnych pracowników w ramach czegoś, co nazywało się u nich Living Tradition. Więc do słuchaczy, wyobraźcie sobie, że pracujecie w Google. I wasz współpracownik właśnie ogłasza, że zmienia zespół, zmienia brancza, nie wiem, jedzie do innego kraju lub odchodzi z firmy, whatever. No to większości firm, no co moglibyście dostać na takie pożegnanie? No nie wiem, może ciasto, może jakiś miały prezent, ale w Google nie. W Google zaczyna się prawdziwa zabawa. No i to taka, która przez ostatnie 15 lat pomogła uczynić tą firmę, jedną z największych firm technologicznych na świecie i jeszcze bezpieczniejszą, a jeżeli ktoś interesuje się przynajmniej minimalnie, w jaki sposób Google podchodzi do bezpieczeństwa, to wie, że poziom jest naprawdę równy paranoi, o której wspomnieliśmy kilka minut temu.
Andrzej: No, ja bym powiedział, że ich poziom jest po prostu taki, oni mają poważny fret model, ich faktycznie mogą atakować nation states. I podchodzą do tego poważnie. Większość firm tak naprawdę może sobie mówić o nation states, które będą ich atakować, ale jak to mówią, bitch please. Jak nation state będzie cię chciał zaatakować, to cię zaatakuje, ci rozjedzie bez żadnych problemów. Bo raz, że nie będzie chciał, ale jak będzie chciał, to i tak to zrobi, bo nie masz zasobów, żeby się przed tym obronić. Google ma zasoby i Google faktycznie może być targantowane przez nation states. Zresztą było w operacji Aurora z 2009 roku. Natomiast oni podchodzą bardzo po inżyniersku. i tutaj książka Building Secure and Reliable Systems jest świetna, przynajmniej od strony właśnie budowania software’u, bo pokazuje w jaki sposób podchodzą do inżynierii, do architektury bezpieczeństwa. bo podchodzą w sposób właśnie inżynieryjny, traktują to jako security engineering, a nie jako willy-nilly testowanie, bo testowanie to jest jakiś jeden malutki wycinek realnego bezpieczeństwa, realnej inżynierii. Ale Krzysiek, kontynuuj.
Krzysztof: Dokładnie. No i ta historia z tym Living Tradition też zaczyna się w 2009 roku, tak jak Operacja Aurora. Zaczyna się w 2009 roku w Curyskim Biurze Google’a.
Andrzej: Krzysiu, ja chciałbym jeszcze wypunktować, uspokoić wszystkich naszych słuchaczy. Operacja Aurora nie została wykonana przez mojego kotka, Aurorkę. Zaprzeczam, dementuję wszystkie takie plotki, to jest po prostu hash collision. Więc tutaj spokojnie, to moja Aurorka nie maczała w tym żadnych palców.
Krzysztof: Rafał, zdjęcie kota z takim paskiem na oczach. Dobra, słuchajcie. Historia zaczyna się w 2009 roku w bodajże córyskim biurze Google’a. No i ktoś wpada na pomysł, że fajnie by było właśnie spróbować wykraść hasło osoby, która odchodziła. swojego współpracownika, no i oczywiście za jego pełną zgodą. To living tradition odbywa się na zasadzie pewnej zgody, którą między sobą ci współpracownicy zawiązują. To nie jest tak, że ty odchodzisz, a my teraz będziemy kopać w twoich śmieciach i szukać na ciebie brudów. I tak, na początku inżynierowie byli dość… Można powiedzieć tradycyjnie w swoich metodach, więc pojawiały się tam jakieś ukryte kamery, kilogery pod biurkiem, klasyczne szpiegowskie zabawki, ale szybko się to znudziło, no bo grupie uzdolnionych inżynierów z Google’a możliwość takiego legalnego hakowania nie przejdzie obok nosa. No i tutaj sprawy się zaczynają robić naprawdę ciekawe, bo zaczęli szukać look, zaczęli szukać zero dayów w swojej infrastrukturze, testować różne naprawdę odjechane wektory ataków. No i każdy taki włam prowadził do tego, każdy taki znaleziony zero day, każda znaleziona luka prowadziła do tego, że Google polepszało swoje zabezpieczenia. No i to nie były jakieś tam chaotyczne ataki. Każda akcja miała swego rodzaju zasady, trochę jak w dobrzej grze, że cel musiał się zgadzać, wszystko było dokumentowane krok po kroku. No i nad całością czuwali ludzie, którzy nie byli bezpośrednio zaangażowani, aby sprawy nie poszły zbyt daleko. No i tak, co udało się m.in. zrobić, co udało się poprawić w Google poprzez Living Tradition? Przeprzyło to wdrożenie HSTS-a, aby przeciwdziałać atakom, które polegały na tym, że obniżaliśmy rangę połączenia z HTTPS-a na HTTP. Wdrożono zabezpieczenia do automatycznego blokowania nowych urządzeń, USB. pendrive’ów, różnych nosików danych, przy pierwszym podłączeniu do komputera, więc jakieś tam keyloggery porozrzucane w biurze, wiatraczki na USB, które były wpinane, aby nas chłodzić w upalny sierpniowy dzień, już nie przechodziły. No i poprawiono sam proces aktualizacji przeglądalki Google Chrome. No i teraz tak. Jak udało się wykraść któryś z tych haseł, bo zawsze takim trofeum było hasło tego współpracownika, no to to hasło było grawerowane, naklejane na różnych przedmiotach. i tak byli pracownicy, którzy dostawali na przykład miecze samurajskie z wygrawerowanym hasłem czy bumerangi. Ja powiem, że… Bardzo ciekawie mi się czytało ten artykuł, który oczywiście podlinkujemy w referencjach do tego odcinka i ja kompletnie nie byłem tego świadomy. I bodajże, o ile mnie pamięć nie myli, jednym z bohaterów tego artykułu jest Michał Zalewski.
Andrzej: Te prezenty były tematycznie związane z daną osobą. Michał Zalewski, o ile dobrze kojarzę, dostał… piłę mechaniczną Husqvarna z wygrawerowanym hasłem, dlatego, że Michał Zalewski, znany amerykański badacz bezpieczeństwa, nie pamiętam, w którym stanie mieszka, ale gdzieś tam w Midwest, na jakimś wypiździowie, ma całą swoją swój ranch. i generalnie musi zajmować się takimi rzeczami jak cięcie drewna, etc. By the way, na przykład Michał… Na pewno jest interesującym człowiekiem, nigdy nie poznałem go na żywo, ale w internetach gdzieś tam się przewija i przecina. Michał na przykład pisał poradnik, w jaki sposób odśnieżać drogę pługiem. Ponoć to nie jest takie łatwe, bo jak odśnieżysz ten śnieg, to on potem może zamarznąć, więc też musisz coś… Nie możesz tak go zostawić, bo jak zamarznie, a potem wyjeżdżasz autem, wpadniesz w poślizg, to ten śnieg jest bardzo twardy, więc się… z nim zderzysz. To nie są takie proste rzeczy. To są te tak zwane second order thinking. Nie możesz tylko, a muszę odśnieżyć, tylko muszę odśnieżyć, ale potem coś muszę jeszcze zrobić z tym, co odśnieżyłem, nie?
Krzysztof: To tak jak w tej jego książce Doomsday, tak? Przygotować się na najgorsze.
Andrzej: Exactly, exactly. No i Michał to jest właśnie świetny przykład osoby, która myśli second order i nawet third order, czyli o tych następnych implikacji, implikacji, implikacji. Jak Każda, każda inteligentna osoba tak powinna działać przynajmniej. Natomiast tak, to living tradition. to jest coś ciekawego, natomiast z mojej perspektywy podoba mi się, że coś takiego miał i tak realny wpływ na podniesienie bezpieczeństwa produkcyjnych systemów, ale nie tylko produkcyjnych systemów samego Google’a, ale też systemów, które potem dotykają końcowego użytkownika. Czyli z jednej strony my jako inżynierowie się bawimy w jakąś zabawę, ale ta nasza zabawa i tak wnosi wartość, bo na koniec dnia możemy poprawić pewne mechanizmy, które dotykają setek milionów użytkowników dziennie. Więc to mi się tutaj… podoba. Ja chętnie usłyszałbym uzasadnienie biznesowe czegoś takiego, wiesz, w samym Google. Wiadomo, jak już masz efekty, to uzasadnienie pisze się samo, ale na początku, jak nie było jeszcze tych efektów.
Krzysztof: No tak, to jest ciekawe. Mi się to… Trochę kojarzę z pojęciem antykruchości, wpuszczanie trochę haasu, reakcji na bodźce po to, żeby polepszać siebie jako organizację, jako system, więc tak, mi się to bardzo podoba.
Andrzej: Dokładnie tak, to jest definicja antykruchości. co często jest błędnie utożsamiane z właściwością odporności. A to są dwie różne rzeczy, bo system, który jest resilient, potrafi przeżyć ataki. Czyli przykładowo, jak mam architekturę mikroserwisową, w AWS-ie, która się skaluje, no to jestem w stanie przeżyć. atak denial of service. Nazwijmy, powiedzmy, jakiś DDoS ktoś puszcza na moje infrastrukturę, jestem w stanie to przeżyć. I to jest bycie resilient, ale to jeszcze nie jest bycie antifragile, bo antifragile dodaje tą jedną ważną wartość, właściwość, że trzeba się po takim ataku być lepszym, czyli Każdy atak, każda taka sposobność na błąd systemu, na failure, nie tylko nie występuje, nie ma albo ma małą prawdopodobieństwo się zmaterializować, ale jeszcze wpływa pozytywnie na system, czyli system się niejako uczy i jest lepszy po każdym takim ataku. I to już jest dużo trudniejsze do osiągnięcia, bo to musi być odpowiednio zaprojektowany system. i procesy, no i też muszą być odpowiedni ludzie, bo nazwijmy to na odpowiednim poziomie świadomości.
Krzysztof: To jeszcze tak rzucę a propos tego, że to bardzo przypomina mi… Taką myśl, którą przypominam, mam teraz taką myśl w głowie, że wiesz Andrzej, możemy mieć super zajebiście skalowalny klaster kubernetesowy, który w momentach szczytu będzie wyrabiał 10 tysięcy procent normy, bo przyjmie ruch z zewnątrz, a w takim podejściu Chaos Engineering, gdzie my… z wewnątrz tego klastra wyłączamy poszczególne serwisy i patrzymy, jak cały system zaczyna reagować i na podstawie tego wyciągamy wnioski i aplikujemy ulepszenia. To jest antykruchość, nie tylko ta odporność na zewnętrzne, przewidywalne, można powiedzieć, wręcz czynniki, tak?
Andrzej: To też, ale to… już mogłem dyskutować, bo nieważne, czy coś jest z zewnątrz czy wewnątrz, ważne jest to, że system musi się ulepszać. Jak się nie ulepsza, to nie możemy mówić o antykruchości. Ta antykruchość, tak jak definiuje Taleb, to jest super ważne, że system musi się ulepszać. wiadomo, idealnie sam z siebie automatycznie, no ale nie żyjemy w idealnym świecie.
Krzysztof: Szkodziło mi o wystawianie się na bodźce, tak?
Andrzej: To jest super. Jeśli chcemy, żeby system długoterminowo nabył tą właściwość antifragile, bo to jest coś, co się nabywa, to musimy wystawiać się na bodźce. Nie, to masz w stu procentach rację. I tutaj powiem trochę szerzej, że tak działają ludzie. I powiem więcej, tak działają najlepsi ludzie. czyli najbardziej efektywni, najbardziej produktywni, ci, którzy tworzą najwięcej wartości. To są ludzie, którzy przejawiają właściwość anti-fragile, anti-fragility. Oni są nie tylko resilient, czyli nie tylko… Wiadomo, podziałów logicznych jest bardzo dużo, więc na pewno możemy podzielić ludzi na tych, którzy dość szybko się łamią pod stresem. Są ci, którzy pod stresem się nie łamią, są w stanie znieść bardzo dużo stresu i się nie złamać. ale nie stają się lepszymi, a są, i tych osób jest jeszcze mniej, ludzie, którzy pod wpływem stresu nie tylko się nie łamią, ale jeszcze ten stres działa jako bodziec, który poprawia performance tych ludzi. I można powiedzieć, że wszyscy topowi gracze w sporcie, ale nie tylko w sporcie, w biznesie, biznes to też tak naprawdę gra. W każdej grze. Topowi gracze to ludzie, którzy mają wbudowaną, oni sobie wyrobili podejście do świata, wyrobili w sobie tą właściwość bycia antykruchym, gdzie każdy stresor zewnętrzny nie tylko ich nie łamie, ale jeszcze bezpośrednio wpływa na to, że po takim stresorze są lepsi. I takim prostym przykładem jest chociażby trening siłowy, zresztą jakikolwiek trening. Po to mamy te jednostki treningowe, że z treningu na trening, z tygodnia na tydzień, potem z coraz większych kawałków czasu stajemy się lepsi. No i to pokazuje, że natywnie jako ludzie mamy wbudowaną tą właściwość antyfragility, nawet na poziomie biologicznym. Nasz organizm potrafi nie tylko wytrzymać, ale stawać się jeszcze lepszym pod wpływem bodźca zewnętrznego.
Krzysztof: No i Nassim Taleb pisze o tym w swojej książce Antykruchość, którą ja przynajmniej polecam. Ty Andrzej też pewnie polecasz. W ogóle całą twórczość pewnie Taleb’a.
Andrzej: Tak, ja polecam całą twórczość Taleb’a.
Krzysztof: Znamienitą większość.
Andrzej: Ja polecam całą jego twórczość, ale oprócz tej na Twitterze.
Krzysztof: Tak, on jest ekscentryczny, mówiąc łagodnie.
Andrzej: I jest ekscentryczny.
Krzysztof: No to słuchajcie, tak przyszliśmy od Living Tradition do antykruchości. Andrzej, wskakujemy teraz w coś, o czym chciałeś jeszcze powiedzieć.
Andrzej: Tak, ja chciałem powiedzieć o jednym takim małym temacie. On nawet sam w sobie nie jest jakoś super ważny, bo ile razy tak naprawdę można mówić o stand hackingu? No bo, nie, zhakowali Subaru, o nie, można trackować i kontrolować auta przez system, Jezus Maria, wszyscy zginiemy. No, być może tak, oczywiście, aaa, Rafał, zrób fajnego thumbnail’a, lol. Nie, oczywiście nie jest tak, że wszyscy zginiemy, w zasadzie można byłoby tutaj zrobić zupełną odwrotność. i pomimo tego, że wszystko jest popsute, we wszystkim są podatności, to w dalszym ciągu wstaje rano i woda z kranu leci, elektryczność działa i generalnie wcale się nie żyje tak źle w tym kraju pierwszego świata, jakim Polska jest. Więc pomimo tego, że te podatności są, a świat i tak działa, to jest tylko argument za tym, że najwidoczniej te wszystkie podatności nie mają tak dużego znaczenia, jak mogłoby się wydawać. I oczywiście można wchodzić i straszyć, ale ola Boga, co by było. Natomiast doświadczenie pokazuje, że nie ma sensu mówić, co by było, bo to nie było. Oczywiście zaraz ktoś, miłośnicy Taleb’a zaraz powiedzą, Andrzej, Andrzej, ale czarny łabędź. Czarny łabędź jest niemożliwy do przewidzenia. Jeśli coś jestem w stanie przewidzieć, typu ktoś moje Subaru jest w stanie schakować, to już to nie będzie czarny łabędź. Więc again. Trzeba czytać definicje, które Taleb podaje w tej książce, a w ogóle polecam przeczytać książki, a nie tylko streszczenia, bo ja już dawno doszedłem do takiego olśnienia, rewelacji takiej, że rozmawiam z ludźmi i ktoś mówi, tak, tak, czytałem tą książkę, ale w zasadzie jak o niej rozmawiam, to wychodzi, że w zasadzie ta osoba nie czyta tej książki, tylko jakieś streszczenie. Może, nie wiem, pierwsze dziesięć stron przeczytała i on mówi, że ona czyta tą książkę i jak podstawowych rzeczy w niej nie ogarnia. Moja rada czytać mniej, ale więcej wartościowych rzeczy. Więcej sygnału, mniej szumu, nie chodzi o to, żeby przeczytać 50 książek w rok, nie ma to sensu. Chodzi o to, żeby nawet przeczytać jedną książkę, ale ją przestudiować i naprawdę ją wciągnąć w swój system i odpowiedniej wartości, czyli nie czytać pierwszej lepszej książki stop 10 2024, bo to na pewno będzie chłam, ale myślę, że każdy jak przeczyta Iliadę, czy chociażby książki Taleba, nawet jeśli przeczyta jedną, na rok, ale faktycznie ją będzie studiował, to wyciągnie z tego dużo więcej wartości niż z 50 książek czytanych. Więc tutaj nie chodzi o ilość, chodzi o jakość. Ale do tego jeszcze wrócę. Natomiast mówiąc o tym przypadku, który mnie zainteresował, no to był właśnie taki przypadek bardzo świeży, bo to było wczoraj. Czyli taki case, gdzie bardzo znany researcher Sam Curry zhakował Subaru, system właśnie tam internetowy, który za pośrednictwem którego mógł śledzić całą flotę Subaru, za pomocą którego mógł kontrolować Subaru. Oczywiście tam nie chodzi o te konkretne podatności, bo tam były śmieszne te podatności. To jak on się dostał do tego panelu, gdzie tak naprawdę wystarczyło… poznać, no trzeba było w jakiś sposób enumerować adresy e-mail pracowników, ale jak już się miało adresy e-mail pracowników, to ten payload, który szedł do web aplikacji, no pozwalał po prostu zmienić hasło bez żadnych problemów, w dowolnemu kontu, tylko musiało być aktywne w systemie. LOL. Więc nie chodzi o to. Chodzi mi właśnie raczej o takie szersze spojrzenie na to, że nawet w momencie, gdy mamy takie duże problemy, które są ewidentnie stand hackingiem, to realnie, czy realnie coś się wydarzyło przez te wszystkie lata, kiedy ta podatność była? No nie. Czy gdyby ten researcher, on oczywiście skontaktował się z Subaru, to już jest wyprowadzone etyce. Gdyby nie upubliczniał tego researchu, tylko po prostu skontaktował się z Subaru, czy miałby tą jakąś zmianę? No nie, miałby mniejsze credo na dzielni, ale poza tym generalnie nie ma większego to znaczenia. To jest jeden duży fakt, żeby narzucić trochę takiego trzeźwego spojrzenia na te wszystkie newsy, które wpadają do nas z internetu. Bo jest naprawdę bardzo dużo szumu, każdy stara się walczyć o naszą atencję, a większość, zdecydowana większość, 99,99% tych rzeczy… czy z bezpieczeństwa, czy szerzej, nie ma tak naprawdę większego znaczenia. Więc tutaj trzeba zachowywać zdrowy rozsądek i zawsze tego typu newsy czytać przez okulary sceptyka, zadając pytanie, okej, ale co z tego? Co z tego, że ktoś mógł to zrobić? No i co? Czy coś realnie się stało? Jeśli nie, jeśli nie mamy jasnych dowodów, że realnie było to wykorzystywane, że coś się stało, no to najwidoczniej… Najwidoczniej wcale to nie było taki duży problem, jak można byłoby to przedstawiać i jak duże serwisy informacyjne, bo na tym zarabiają, na klikach, będą starać się to przedstawiać. To jest jeden wniosek, a drugi to to, że to nie jest pierwsza podróż sama w kierunku dostawców aut. Wcześniej to on był odpowiedzialny za to zahakowanie KI, o których chyba też wspominaliśmy w podcaście. rip stinger. Ale tak czy siak, co do key, to chodzi mi o ten pattern, gdzie researcherzy często albo obierają konkretne klasy podatności, albo na przykład konkretnego vendora i szukają tylko u niego podatności, na przykład robią to przez pół roku, albo rok, albo na przykład, tak jak tutaj, obrał za cel, no bo wcześniej była Kia, teraz jest Subaru, pewnie kolejny jego duży research też pewnie będzie wokół vendorów od aut. Czemu? No bo najwidoczniej obrał sobie jakiś cel, że będzie teraz sprawdzał infrastrukturę, aplikacje, aplikacje mobilne, aplikacje webowe, TC, od vendorów, od producentów aut i będzie to robił, dopóki czegoś ciekawego nie znajdzie. A wiadomo, jak będziemy się patrzeć, dostarczająco długo będziemy coś testować, to na pewno znajdziemy problemy, na pewno nam się uda to shakować. Pytanie zawsze jest czas. effort, który musimy poświęcić, a nie to czy. Tylko pytanie, ile czasu, ile energii, ile pieniędzy, jaki koszt będziemy musieli ponieść. Więc to jest taka druga lekcja, że jeśli ktoś chce się bawić w programy Backbound, jeśli ktoś chce się bawić w hakowanie, to dobrze skupić się na albo na konkretnych vendorach pojedynczych, których… do których się naprawdę przysysamy i nie chcemy puścić, albo do konkretnych klas podatności pomiędzy vendorami, czyli na przykład szukamy wszędzie tylko SSRF-ów. To nie chodzi o to, że robimy to do końca życia, ale że na przykład przez kolejne 3 miesiące albo 6 miesięcy robimy tylko to. I jeśli robimy, jeżeli w ten sposób działamy, to nasz mózg zaczyna inaczej interpretować wszystko, co do nas dociera. Nasz mózg działa bardzo często podświadomie, wyłapuje rzeczy, których Albo inaczej. Rzeczywistość jest bardzo skomplikowana. To, co widzimy, to, co słyszymy, jest tylko uproszczeniem ogólnej rzeczywistości. Bo gdybyśmy mieli procesować wszystkie sygnały, które do nas docierają, to byśmy oszaleli. Więc nasz mózg wycina większość sygnałów, których nie potrzebuje. On je widzi, ale on nie daje nam na wyższym poziomie znać, że one są. Bo widzi, że nie ma to sensu. Natomiast w momencie, gdy się na czymś skupiamy, to nasz mózg wie, że… że musi wyłapać tą konkretną rzecz i z tego morza informacji zaczyna nam ją wyłapywać. W momencie, kiedy widzi instancję tego, nad czym się skupiliśmy, zaczynamy to po prostu wszędzie widzieć. I to nie jest tak, że nagle to się tam pojawia. To jest raczej tak, że nagle nasz mózg wie, że na to ma zwrócić w tym momencie uwagę. I to jest znany fenomen auta. gdzie chodzimy po mieście, nie widzimy aut, idziemy do dealera, mówimy sobie, o kurczę, no fajna taki ja stinger, no chciałbym sobie kupić. Wychodzimy od dealera, na drugi dzień idziemy po mieście, wszędzie widzimy stingery na mieście. Ale jak, kurczę, tyle stingerów na mieście w jeden dzień? Nie, nie ma tyle stingerów, tylko twój mózg teraz skupia się na tym stingerze, bo przed chwilą był bodziec w… w postaci tej wizyty u dealera i twojej chęci zakupu albo samo to, że ci się spodobał. i nagle teraz twój mózg wyłapuje to z całego morza informacji. Więc tutaj możemy niejako użyć tego jako pewna trampolina, będąc researcherami i również możemy skupiać się na konkretnych klasach podatności. To może zadziać jako dźwignia w tym, ile ich znajdujemy. Bo jak będziemy się skupiać tylko na jednej, to może przeoczymy inne, ale tej konkretnej już nie przeoczymy. I na koniec dnia wyjdziemy na tym lepiej. Dobra, to takie moje dwa szybkie wnioski. Szybkie wnioski, a 10 minut gadania, nie?
Krzysztof: Tak, ja bym do tego drugiego wniosku chciał dodać, że taki dowód anegdotyczny, który mam, że ja już bardzo często zauważam podczas współpracy z jakimiś zespołami, czy nawet powiedzmy grupą zespołów, że pewne… pewne problemy bezpieczeństwa się dookoła nich klastrują, że widać pewien wzorzec i pattern, pewien problem, który nie przejawia się tylko w jednej konkretnej instancji tego problemu, tylko to jest szersze i wynika często z niewiedzy osób, które projektowały ten system, więc warto jest faktycznie, powiedzmy, teraz będę strzelał mówić bardzo szczegółowo, tak, znajduje jedną instancję takiego problemu. to już zapala moją lampkę, że może warto jest poszukać w historii innych miejsc, które dotykał ten zespół, czy ten człowiek i poszukać, czy on przypadkiem nie postąpił już w historii dokładnie tak samo, jak to, co znalazłem właśnie teraz.
Andrzej: To jest klasyka. To jest klasyka, szczególnie w momencie, jak mówimy o audytowaniu kodu, gdzie jak wykryjemy jakiś patent podatności, to potem bardzo zalecane jest, żeby sprawdzić git commit i następnie… przeszukać pod kątem tego patternu wszystkie komity od danego dewelopera, bo jeśli popełni ten błąd raz i to może być błąd jakiś na poziomie implementacji, to może być błąd bardziej na poziomie logiki biznesowej, żeby po prostu pociągnąć wątek dalej, bo to jest bardzo, bardzo owocne. Ja się z tym zetknąłem pierwszy raz lata temu, to było chyba około 2008 roku, jak audytowałem kod ClamAV. To jest taki antywirus napisany na tywniewce. Na serwerach często jest uruchamiany. No i on jest napisany w C i parsuje pliki. Co może pójść źle? Dużo rzeczy może pójść źle. Jak tam audytowałem, to akurat ta instancja, która mi teraz przyszła do głowy, to sytuacja, w której był inny taki polski researcher, pozdrawiam Damian, który znalazł kilka różnych podatności. w językach i było zabawne to, że jak czytałem te komity i potem komentarze w kodzie, To był jeden deweloper, który mówił, wszedł w jednym, że poprawił to, potem poprawił kolejny i to był ten sam deweloper. Kolejny, kolejny, kolejny. I w którymś tam już mówi, o, I made Damian a rich man. Bo Damian to tam, wydaje mi się, opylał do iDefense VCP, więc tam zarobił jakieś pieniądze na tym, a deweloper popełniał w zasadzie generalnie ten sam błąd. tylko w wielu różnych parserach plików. Więc nie jestem pewien, czy w dalszym ciągu leży to w kodzie źródłem CLAM AV. Można sprawdzić. Można sprawdzić, a Damiana pozdrawiamy, chociaż… Nie sądzę, że Damian będzie słuchał naszego podcastu, ale kto wie, może.
Krzysztof: Ja ostatnio klamował taka anegdotka, bo przechodzę u jednego klienta. audyt, atestacje, no i oczywiście pewne kontrolki compliance’owe z upiorem maniaka mówią, no tak, musisz mieć ten antywirus na serwerach i tak dalej, wchodzisz na reddita. I czytasz opinie o Klam AV. Pierwsze pytanie w komentarzu, co? Jakiś debil z komplejansu kazał ci to zainstalować? Oczywiście oryginalny Fredo, takiegoś zdesperowanego DevOpsa, który boi się tego zainstalować, bo wie, że po prostu pożerę mu to kolejne zasoby na maszynie.
Andrzej: Dokładnie tak. Kto przechodził różne audyty, ten się w cyrku nie śmieje. Szczególnie jeśli Takie rzeczy da się obchodzić. Takie rzeczy da się obchodzić i dalej być compliant, ale to jest bardzo często sztuka dla sztuki. Ale ten wątek to może kiedyś zrobimy w jakimś odcinku specjalnym. Co myślimy o audytach i audytorach? XD. Będzie roast. Właśnie. Trzeba coś powiedzieć. Z mojej strony to w zasadzie tyle. Ale jak masz coś do dodania, to śmiało, tylko przypominam, że czas nam ucieka.
Krzysztof: Tak, ja bardzo króciutko z ostatnią wrzutką, dosłownie ekspresowo, znalazłem jakiś czas temu bardzo fajny white paperek opublikowany w jakimś czasopiśmie naukowym. On jest za paywallem, więc w zasadzie dostępny dla mnie był tylko abstrakt, ale chcę po prostu zajawić. Czy zastanawialiście się kiedyś, Czy te wszystkie szkolenia z cyberbezpieczeństwa, które przechodzimy w pracy, szczególnie w dużych organizacjach, naprawdę działają? No właśnie, nie do końca. I naukowcy też byli ciekawi i przeprowadzili takie fascynujące badanie, które może zmienić naszą percepcję na temat myślenia o tych wszystkich szkoleniach antyfishingowych. Eksperyment był przeprowadzony w dużej organizacji, która dotyka ochrony zdrowia, tam pracuje blisko 20 tysięcy pracowników, no i przez 8 miesięcy obserwacji i 10 symulowanych kampanii phishingowych. Okazało się, że nie ma żadnego znaczącego związku między tym, czy ktoś niedawno przeszedł szkolenie cyberbezpieczeństwa, a tym, czy da się złapać na fishing. Więc innymi słowy, świeżo przeszkoleni pracownicy wpadali w pułapki tak samo często jak ci, którzy tego szkolenia nie przeszli. Po drugie. Nawet gdy spojrzeli na te wbudowane szkolenia, takie szkolenia, które przeszkadzają wam w pracy, bo dostajecie nagle maila i musicie zareagować, czy zgłosicie to jako phishing, czy klikniecie w link itd., no to różnica między przeszkolonymi a nieprzeszkolonymi pracownika była minimalna, niezależną od tego, jaką formą to miało szkolenie. i najciekawsze, większość użytkowników… spędza absolutne minimum czasu na tym szkoleniach, żeby jak najszybciej je odklikać. I co więcej, to jest już naprawdę w ogóle głowa mi eksplodowała, jak o tym przeczytałem. W niektórych przypadkach osoby, które przeszły więcej szkoleń miały większą szansę na wpadnięcie w kolejną pułapkę phishingową. Więc efekt był dosłownie odwrotny od zamierzonego.
Andrzej: No, wiesz, tak naprawdę każdy praktyk, myślę, że zdaje sobie z tego sprawę, że te szkolenia, albo każdy świadomy praktyk, bo wiesz, bezpiecznicy często lubią mówić o to, jaki człowiek jest tym najsłabszym ogniwem i potem mówić, o, rozwiązanie to szkolenia, trzeba szkolić edukację. Gdyby edukacja miała działać, to nie mielibyśmy problemu z bezpieczeństwem informacji w zasadzie od lat 70. To pole wtedy zaczynało powstawać. Mamy 2025 i dalej mamy problemy. Więc szkolenie i świadomość nie. Jeśli twoja obrona polega na edukacji, na szkoleniach i świadomości, No, to pozdro 600, nie? Pamiętasz ten research z Google, gdzie jasno pokazali, że ataki phishingowe zmalały do zera dopiero wtedy, kiedy wprowadzili tokeny sprzętowe.
Krzysztof: Tak, tak. Kiedy tam ichniejsze YubiKie zostały wprowadzone, to dopiero wtedy faktycznie pozbyli się, tak, tytany, to dopiero wtedy pozbyli się tego problemu. Dobra, Andrzej. Zamykamy.
Andrzej: Zamykamy.
Krzysztof: Na dzisiaj. Dzięki wielkie, że jesteście. Dajcie suba, bo niedługo w ogóle będziemy wbijać chyba tysiąc w końcu. Pierwszy tysiąc.
Andrzej: Pierwszy tysiąc najtrudniejszy. Czy dają za to jakiś guzik?
Krzysztof: Nie, guzik jest za 100.
Andrzej: Nie, to są ci gu** w torebce, co moje wyżej.
Krzysztof: Dobrze, to jeżeli chcecie, żebyśmy dostali gu** w torebce, to sub, like i dzwoneczek, a my słyszymy się za miesiąc. Dzięki wielki Andrzej, no i pewnie łapiemy się za chwilkę.
Andrzej: Dobra, trzymajcie się, na razie.
Krzysztof: Dobra.
Andrzej: Mamy to.