W tym odcinku podcastu „Bezpieczny Kod”, Krzysiek i Andrzej przedstawiają gorące tematy z obszaru cyberbezpieczeństwa. Na początek omawiają najnowszy raport DataDog „The State of Cloud Security”. Dowiesz się z niego, że długo żyjące poświadczenia wciąż stanowią poważne zagrożenie dla środowisk chmurowych, ponad 50% firm korzysta z uwierzytelniania federacyjnego, a AWS w końcu zmienił domyślne ustawienia prywatności dla bucketów S3, co jest krokiem w kierunku zwiększenia bezpieczeństwa chmury. Pokazujemy również jaki związek mają ostatnie ataki cybernetyczne z AI.
Kluczowe Wnioski i Najważniejsze Zagrożenia:
Zasada Najmniejszych Uprawnień i Perspektywy Branży: Dyskutujemy o zasadzie najmniejszych uprawnień (least privilege) w chmurze, która jest fundamentem bezpieczeństwa cybernetycznego. Zaskakuje również niewielka obecność tematów związanych z cyberbezpieczeństwem w najnowszym ThoughtWorks Technology Radar, mimo silnego polskiego akcentu w postaci Piotra Gankiewicza, co może wskazywać na niedoszacowanie wagi tematu w niektórych kręgach.
Rekrutacyjne Ataki z Korei Północnej: Analizujemy, jak północnokoreańscy hakerzy infiltrują zachodnie firmy, wykorzystując fałszywe profile na LinkedIn tworzone za pomocą AI. Mandiant ostrzega, że kilkadziesiąt firm z listy Fortune 100 nieświadomie zatrudniło tych cyberprzestępców, co podkreśla nowe wektory zagrożeń dla firm.
Szybkość Eksploitacji Podatności Zero-Day: Google publikuje szokujące statystyki dotyczące wykorzystanych podatności: 70% zero-dayów zostało wykorzystanych w 2023 roku, a czas od odkrycia do exploita spadł z 63 do zaledwie 5 dni. To pokazuje rosnącą potrzebę szybkiej reakcji i automatyzacji zabezpieczeń.
Odcinek dostępny na YouTube, Spotify, Apple Podcasts i innych platformach.
Transkrypcja
Andrzej: Dzień dobry. Siema. Witam wszystkich. Witam słuchaczy, ale witam też również ciebie, Krzysiek. Nie widzieliśmy się na live już jakiś czas, kilka tygodni. Byliśmy… Nie będę mówił co, ale byliśmy zajęci robotą. Program ABCD trwa, ludzie są zadowoleni. W zasadzie zmierzamy ku końcowi, ale nie upadkowi. My się dopiero rozkręcamy. Było co robić. Nie znaleźliśmy czasu, żeby nagrywać podcastu, ale wracamy do tego. Sama formuła nam się podoba, więc chcemy to kontynuować. Krzysiek, co tam u ciebie? Od tego zacznijmy.
Krzysztof: Witam, witam, witam was bardzo serdecznie po tej krótkiej bądź dłuższej przerwie. Z kilkoma ze słuchaczy udało się przybić piątkę przez ten okres, który nas nie było na antenie. U mnie wszystko dobrze, tak jak Andrzej powiedziałeś, czas nieco zapracowany, ale wracamy i myślę, że teraz nabierzemy już większej regularności w naszych nagrywkach.
Andrzej: Na 100%, na 100%. Nie może być inaczej. No i będziemy starać się dostarczać topowe materiały w naszym obszarze. Krzysiek, ja od razu się trochę przyznam bez bicia, że w zasadzie nie do końca jestem przygotowany do tego odcinka. Mam jedną rzecz, o której chcę wspomnieć, przynajmniej tak pobieżnie i będzie to Technology Radar od ThoughtWorks. Coś, co dostało kolejne update, chyba w tym tygodniu nawet, na samym początku. Natomiast na dniach dostało update, wleciał nowy technology radar, więc na pewno o tym będę chciał porozmawiać. Natomiast biorąc pod uwagę, że mam tylko ten wątek, to zacznijmy od czegoś twojego. Bo z mojej strony wygląda to tak, że naprawdę byłem tak… zarobiony, że po prostu nawet nie zwracałem uwagi na jakiekolwiek newsy, no a że nie było żadnego kolejnego CrowdStrike’a, no to newsy po prostu do mnie nie dotarły. Wszystko, co było, było clearly mniejsze i mniejszej wagi.
Krzysztof: Ja muszę słuchaczom powiedzieć, że my z Andrzejem mamy taką przestrzeń na Notion, gdzie dzielimy się tym, o czym będziemy chcieli powiedzieć. i specjalnie nie brałem tego technology radar, bo powiedziałam, że możesz ci coś zostawić.
Andrzej: Dziękuję.
Krzysztof: Dobra, ale słuchajcie, przechodząc do meritum, przechodząc do sedna, do mięsa, to pierwszy temat, który chcielibyśmy z Andrzejem poruszyć, to jest raport od Datadoga, The State of Cloud Security. I Datadog generalnie wydaje dużo raportów, bo Datadog jest dużym vendorem i dużą firmą. No i w tym roku właśnie wydał kolejny raport dotyczący bezpieczeństwa w chmurze i jak to się ma w środowiskach chmurowych, w którym przedstawia 7 faktów dotyczących tego, jak sprawy bezpieczeństwa właśnie mają się w chmurze. O podobnym raporcie DataDoga mówiliśmy kilka odcinków naszego podcastu temu. Wtedy ten raport dotyczył stricte DevSecOpsu. No i tak, DevSec DataDog coś o bezpieczeństwie wie, bo tak jak możecie wiedzieć albo i nie, poza niezwykle rozbudowaną platformą i narzędziami do budowania obserwowalności, To mają również szereg produktów poświęconych bezpieczeństwu w chmurze. Między innymi rozwiązania takiej klasy jak Cloud Security Post-Presture Management, ale już teraz w zasadzie nie tylko chmura, ale również cykl wytwórczy, bo narzędzia do analizy składu komponentów. I tak dalej, i tak dalej. Które swoją drogą, Andrzej, zaczęli bodajże oferować chwili, kiedy przejęli firmę Screen, pisaną przez Q.
Andrzej: Znam, znam, znam, znam. I w momencie, gdy ją przejęli, to trochę ubolewałem, bo Screen miał ciekawe zasoby, które zaraz po tym, jak zostały przejęta sama firma, po prostu zaczęły powoli znikać z internetów i niektórych się nie da już znaleźć.
Krzysztof: Mam je zdumpowane. Pamiętam, że to Andrzej mi je podrzucał. Bardzo ciekawe checklisty, ale takie naprawdę niesprzedażowe, bo wiecie, często jest tak, że vendorzy robią content typowo taki nacechowany po to, aby potem nim zacząć sprzedawać, co w zasadzie ma pewien sens. A te checklisty, z tego co pamiętam, to były… Co ma zrobić na przykład CTO w kontekście bezpieczeństwa w ciągu pierwszych 90 dni swoich pracy? Co ma zrobić security engineer w ciągu pierwszych 90 dni swoich pracy? I z tego co pamiętam, to były naprawdę bardzo fajne fachowe checklisty.
Andrzej: One faktycznie miały sens. Widać, że ktoś, kto je pisał, zrobił to z głową, to nie był marketer, to była osoba, która faktycznie ma doświadczenie z bezpieczeństwem, która przechodziła taki proces.
Krzysztof: No, ale reasumując ten taki wątek pobieżny, no DataDoc oferuje już teraz naprawdę bardzo szeroko narzędzia, jeżeli chodzi o bezpieczeństwo. I wracając stricte do tego raportu, ja napomnę o kilku z mojego punktu widzenia ciekawych wnioskach z tego raportu, a wy jak zawsze link znajdziecie w referencjach, w opisie tego odcinka. No więc tak, Datadoc wskazuje w swoim raporcie, że długo żyjące poświadczenia w dalszym ciągu stanowią poważne zagrożenia dla środowisk chmurowych, zwłaszcza kredki, kredensziale, które mają, wiecie, mają tendencję do omyłkowego pojawienia się w całej masie różnych miejsc, od repozytoriów po obrazy dockerowe, nie tylko na wierzchu tych obrazów, ale również w ich warstwach, kończąc na… logach z buildów i nie wiem, pochwalcie się w komentarzach, gdzie znaleźliście, w jakim najdziwniejszym miejscu znaleźliście sekret, mówiąc o takich kluczykach na przykład właśnie do środowisk murowych. Ja się pochwalę. Ja widziałem, że kiedyś ktoś stworzył brancha i nazwa tego brancha to był po prostu sekret. kopiował w taki sposób to, że nazwę tego brancha widzia, także piękne. Nie wiem w ogóle, czy jest jakiś skaner skryptów, który byłby w stanie, znaczy, czy byłby w stanie to na pewno, ale który bierze pod uwagę, że ludzie mówiąc, że nazwę brancha.
Andrzej: To jest ciekawe, to jest pomysł na research za darmo.
Krzysztof: Najdziwniejsze miejsca na sekrety. Bezpieczny kot.
Andrzej: Okej.
Krzysztof: I tak, wiecie, jeżeli chodzi o sekrety, wcale się nie dziwię. Jakby to jest problem, który z nami jest, żyje i pewnie jeszcze długo będzie żył, dopóki nie pozbędziemy się sekretów z użycia.
Andrzej: A jak można się ich pozbyć? Przykładowo można wejść do kursu ABC DevSecOps i my tam mówimy, jak można się pozbyć sekretów z Gita i z repozytoriów.
Krzysztof: Tak. DataDog w raporcie wskazuje również, że długo żyjące poświadczenia to jest ryzyko dla środowisk chmurowych, ale długo żyjące poświadczenia to jest również ten wektor ataku, który jest najczęściej wykorzystywany, jeżeli chodzi o to, w jaki sposób atakujący uzyskują dostęp do tychże środowisk.
Andrzej: Okej, bo tutaj chciałbym zrobić taką wstawkę, że to w zasadzie jest logiczne, bo jeśli mamy długo żyjący sekret, poświadczenie, które pozwala nam wejść do infrastruktury, to w zasadzie kwestią czasu będzie, aż ktoś je znajdzie. I teraz, jeśli druga strona, czyli atakujący zdają sobie sprawę z tego zagrożenia, to będą aktywnie szukać, czyli będą skracać ten czas… No i po prostu się to wszystko łączy, że okej, tutaj prawdopodobieństwo rośnie, więc będziemy w ten sposób zaatakowani i jest to taki, można powiedzieć, dość prosty sposób do automatyzacji, czyli po prostu skanujmy wszystkie githuby, gitlaby, etc. pod kątem sekretów i oportunistycznie wchodźmy do, używajmy tych sekretów i wchodźmy do tych środowisk.
Krzysztof: Bardzo dobrze, że podkreślasz, Andrzej, tą kwestię tego, że jest to dokonywane w pewien sposób oportunistycznie i również to wskazuje DataDog, że jakby W momencie, kiedy przekwytowane są te repozytoria, to atakujący niejako liczą oportunistycznie, że uda im się znaleźć te poświadczenia na przykład w repozytoriach i potem dokonywać takiego lateral movementu po infrastrukturze ofiary.
Andrzej: I ja tutaj jeszcze dodam, bo oportunistycznie to jest spolszczenie słowa opportunity z angielskiego. Jeśli ktoś nie kojarzy, to po prostu chodzi o to, że atakujący nie atakuje konkretnej organizacji, tylko po prostu chce zaatakować kogokolwiek i zaatakuje tego, czyj sekret znajdzie w kodzie. Robi to po prostu, nachybił, trafił. a nie ukierunkowane na jakąś konkretną organizację. Korzysta z szansy, z opportunity.
Krzysztof: Tak, i Datelog wskazuje, że remedium w przyszłości, jak i również remedium, które możemy jeszcze raz wykorzystywać, jest zarządzanie pracą uwierzytelnienia do środowisk chmurowych w sposób sfederowany, na przykład przez dostawców tożsamości, takich jak Okta, bądź takich dostawców, którzy są dostępni w waszych środowiskach chmurowych, I w chwili obecnej według raportu DataDoga, bazując na tym, co oni wiedzą o swoich klientach, którzy korzystają ze środowisk murowych, no to u nich wygląda to tak, że ponad połowa wszystkich ich klientów korzysta z tego federated marketingu. authentication, czyli mają jakiegoś dostawcę tożsamości, którym logują się, uwierzytelniają, poświadczają swoją tożsamość w chmurze. Jedna czwarta używa tylko i wyłącznie tych długo żyjących kluczy, które stanowią zagrożenie, a 22% miksuje oba podejścia, czyli część użytkowników loguje się w sposób sfederowany, część użytkowników loguje się długimi poświadczeniami, które żyją długo. I myślę, że to nie będzie również zaskoczeniem, bo mówiliśmy o tym, że coraz częściej poza tym, że atakujący uzyskują dostęp do chmury, to następnym krokiem jest, tak jak jeszcze do niedawna było to odpalenie dosyć dużych instancji w celu jakichś maszyn w celu kopania np. kryptowalut, to w chwili obecnej takim wektorem, w którym zmierzają, jest odpalenie dużych modeli językowych.
Andrzej: Klasyka. Klasyka już od jakiegoś czasu, bo wspomnieliśmy o tym kilka razy. No te modele językowe na czyjś koszt to jest good value proposition.
Krzysztof: Ma to sens. Tak, dokładnie. DataDoc pokazuje w swoim raporcie również kwestie publicznych assetów, publicznych elementów chmury, które są wystawione do klientów i tutaj podaje przykład konkretnie bucketów S3. I tak jak Andrzej, kojarzysz pewnie zmorą środowisk chmurowych, jeżeli chodzi o storage, było to, że źle skonfigurowane kubełki S3 były wystawione często publicznie, a wynikało to bardzo często z faktu, że jeszcze do kwietnia 2023 roku, tworząc kubełek w usłudze S3, on był domyślnie dostępny jako publiczny. Musiałeś wyraźnie to skonfigurować w taki sposób, aby ten kubełek był prywatny. I w pewnym momencie Amazon poszedł, można powiedzieć, w porozum długowy i stwierdził, że to chyba nie jest problem w tym, że nasi klienci, właściwie to jest problem w tym, że nasi klienci nie rozumieją tego, jakie konsekwencje ma stworzenie takiego kubełka w naszej usłudze. I od kwietnia 2023 roku zmienili swoje podejście, można powiedzieć, na coś, co nazywałbym jako secure by default od strony Vendora. Tworząc kubełek, on od początku jest prywatny.
Andrzej: To jest też ciekawe, bo w bezpieczeństwie mamy taką zasadę, że w zasadzie domyślna ścieżka powinna być ścieżką bezpieczną. I biorąc to pod uwagę, to ja chętnie poznałbym rozumowanie inżynierów w AWS, a to nie są… To są ogarnięci ludzie, więc mieli na pewno jakieś powody, dlaczego te kubełki przez tyle lat, bo przecież AWS nie powstał w tej dekadzie, nie powstał nawet w poprzedniej dekadzie, tylko jeszcze w poprzedniej, więc trochę już istnieje AWS. Jakie mieli rozumowanie pod kątem właśnie uznania kubełków za publiczne z defaultu, bo technicznie powinny być prywatne. I skoro zmienili to na prywatne, no to dało się to zmienić, ale na pewno mieli jakieś rozumowanie wcześniej. Chętnie bym się dowiedział. No właśnie i to mnie zastanawia, jaki mieli ten proces decyzyjny inżynierowie z Amazona, udostępniając domyślnie jako publiczne, No a teraz oczywiście podejmując już tą bardziej rozważną decyzję i zmieniając na prywatne, chociaż ja chciałem jeszcze jedną rzecz tutaj wypunktować, bo tam wspomniałeś, że użytkownicy końcowi nie rozumieją. I tutaj też ja jestem, skłaniam się ku opinii, że jeśli użytkownik końcowy nie rozumie i nie rozumie raz, drugi, trzeci, piąty, dziesiąty, popełnia się te błędy w dużej skali, to tak naprawdę problem nie jest z użytkownikiem, tylko z twoim mechanizmem. To jest jasne jak dzień.
Krzysztof: Tak, tam musiało być coś skopane, jeżeli chodzi o taki user experience, tego, w jaki sposób się to tworzy. Mimo, że mamy do czynienia z osobami technicznymi, z deweloperami, to w dalszym ciągu gro z nich popełniało ten błąd, tworząc kubełek S3, następnie podpinając go pod swoją aplikację. On stawał się publiczny, często z możliwością tego, by wylistować wszystkie pliki. I pamiętam, że w tym okresie 2020-2023 powstała masa researchów, badań, które mówiły o tym, że skala problemu jest zatrważająca. W podcaście wspominaliśmy o tym problemie już nie raz. Skądza się? I fakt trzeci na tej liście, naszej liście, to jest fakt siódmy, jeżeli będziecie przeglądać raport Datadoga, to już króciutko, to zbyt szerokie przepisywanie, przepisywanie zbyt szerokich uprawnień instancjom EC2, czy tym instancjom, z którym macie do czynienia na przykład na GCP czy Azure. I tutaj Data Talk wskazuje jasno, że przejęcie np. poprzez podatność w naszej aplikacji, która działa, jest uruchomiona na takiej infrastrukturze, na takiej instancji EC2 może powodować w przypadku, kiedy ona ma przypisane zbyt szerokie uprawnienia, że ten lateral movement, czyli poruszanie się w naszej infrastrukturze staje się niezwykle łatwe i płynne, więc tutaj zasada least privilege jak zwykle na propcie.
Andrzej: To jest jedna z zasad, z pryncypiów architektury bezpieczeństwa, więc ona nie jest łatwa do stosowania, bo oczywiście łatwiej jest nadać te uprawnienia szerokie i wszystko działa, ale w takim wypadku bezpieczeństwo zawsze będzie cierpieć i czasami ma to uzasadnienie, ale niestety w większości przypadków jednak nie ma i prowadzi do problemów down the road.
Krzysztof: Tak, i to jeżeli chodzi o raport Datadoga z naszej strony byłoby tyle. Jak zwykle zapraszamy do tego, żeby odwiedzić opis. Tam w referencjach znajdziecie link. Warto rzucić okiem, bo ten raport Datadoga nie jest jakiś przesadnie długi, a oni mają dosyć fajną reprezentantywną próbkę klientów i mogą wyciągać z tej próbki i z tego, co oni robią w chmurze całkiem ciekawe wnioski. No i te wnioski znajdziecie właśnie w tym raporcie. A my, Andrzej, przechodzimy do kolejnego tematu. Tematu, który już się obijał w naszym podcaście. Myślę, że co najmniej raz. Kontraktorzy IT z Korei Północnej znowu w natarciu.
Andrzej: Ach, ta Korea.
Krzysztof: Ach, nie mogą. Nie mogą przestać się rekrutować do tych firm zachodnich. Tacy dobrze są może.
Andrzej: No to Azjaci, oni tam dobrze są w komputery, w matematykę, w inżynierię.
Krzysztof: Tak.
Andrzej: Starcrafta.
Krzysztof: Starcrafta są bardzo dobrze. Tutaj wpadł mi bardzo ciekawy, nie bardzo ciekawy, ale przykuwający moją uwagę artykuł na BBC. I BBC opisuje to w taki sposób, że w firmach, której nazwy oczywiście nie padają, padła ofiarą. cyberataku po zatrudnieniu północno-koreańskiego przestępcy, który potrzył się pod zdalnego pracownika IT i sfałszował dane osobowe oraz całą swoją historię zatrudnienia. Po uzyskaniu dostępu do sieci firmowej, do organizacji, haker, ten nasz z północy, pobrał wrażliwe dane z firmy, a następnie wysłał żądanie okupu, grożąc ujawnieniem lub sprzedażą tychże informacji.
Andrzej: Pomysł na biznes.
Krzysztof: I kto by się spodziewał? I wiecie, jakby trend infiltracji firm w ten sposób, tutaj BBC wskazuje, że od 2022 roku obserwuje się wzrost tego typu ataków właśnie przeprowadzanych ze strony Korei Północnej w taki sposób, że infiltrują zachodnie firmy, co jest próbą obejścia zachodnich sankcji przez reżim pana Kim Jong-una. Więc ci kontraktorzy zdobywają wysokopłatne stanowiska. To są często ludzie na stanowiskach staff, principal, architect i tak dalej, i tak dalej. Zarabiają tam całkiem niemałe pieniądze. I gros tych pieniędzy pewnie jak niecałość przekazują do Korei Północnej w ten sposób właśnie obchodząc sankcje. I tutaj pewnie nie jest zaskoczeniem, że w chwili obecnej ci ludzie w trakcie procesu rekrutacji dosyć dobrze wykorzystują generatywną sztuczną inteligencję do modyfikowania zdjęć, do tworzenia sobie swojego bio, do odpicowania tych profili na LinkedIn, na social mediach w taki sposób, aby wyglądały one po prostu legitnie. Tutaj troszeczkę puszczowodzę fantazji. Myślę, że te profile są wygrzewane już na długo, długo przed taką operacją.
Andrzej: Na 100% są wygrzewane. To nie jest coś, co się po prostu robi pop-up. Robisz operację i robisz ją w przód. Więc myślisz na kilka miesięcy, może nawet kilkanaście miesięcy do przodu.
Krzysztof: Dokładnie, więc trzeba sobie też gdzieś tam uzmysłowić, że wśród nas, wśród nas użytkowników mediów społecznościowych jest cała masa kont, które są po prostu fałszywe, nie? Zimują jak rosyjskie czołgi na Syberii i czekają tylko na rozkaz do ataku.
Andrzej: Sleeping agent. Jak w zimnej wojnie.
Krzysztof: I Mandiant. Mandiant w ogóle został chyba kupiony przez Google’a?
Andrzej: Jakiś czas temu? Tak, tak, tak. Wydaje mi się, że oni są już dywizją Google’a.
Krzysztof: Tak, oni są już dywizją Google’a. I Mandiant mówi jasno, że na liście Fortune 100 jest kilkadziesiąt firm, które omyłkowo zatrudniło korończyków z północy. Upsi daisy. Jeżeli chodzi o Korea Północna, to jest też może nie, no powiedzmy odwrotny atak, wariant tego ataku. że to nie firma zatrudnia Koreńczyka z północy, tylko to Koreńczyk z północy próbuje zatrudnić ciebie. I wygląda to w taki sposób, że to rekruterzy, którzy podżywają się pod rekruterów z dużych, fajnych, kasiastych firm, łowią cię do takiej rekrutacji. Ci rekruterzy są oczywiście z Korei Północnej. Oferują ci sowite wynagrodzenie, Jest jeden malutki szczegół, ja to o tym mówiłem na konferencji na The Hack Summit miesiąc temu, no miesiąc, czy tygodnie temu, mówiłem o tym właśnie na konferencji, że szczegół taki w tym, że trzeba rozwiązać zadanie rekrutacyjne, no jak w każdej dobrej Andrzej rekrutacji. Pobierając repozytorium musisz sobie postawić tę aplikację, tylko szkopuł tkwi w tym, żeby ją postawić, to musisz najpierw zainstalować zależności, a w tych zależnościach znajduje się zawsze jedna paczka, która jest złośliwa i w trakcie procesu instalacji, postawiania sobie takiego repozytorium, propozyterem takiej aplikacji, po prostu host jest infekowany. I do tego typu operacji ofiary wybierane są spośród również innych fajnych organizacji, bo często jest tak, że no niestety te zdania rekrutacyjne wykonywane są na komputerach, które należą do firmy.
Andrzej: Tak, to jest kolejny wektor ataku, czyli po prostu sposób zaatakowania. organizacji, ale trzeba im przyznać sprytny.
Krzysztof: Tak, także jeżeli chodzi o Koreę Północną i ich wyczyny, to myślę, że tutaj postawimy kropkę i przejdziemy do kolejnego tematu. Google w swoim raporcie wskazuje, Andrzej, że 70% wykorzystanych podatności, które badali w 2023 to były zero day. Zaskoczenie czy nie?
Andrzej: Jeszcze raz, 70% wykorzystywanych podatności, które badali to były zero day.
Krzysztof: To były zero day, tak.
Andrzej: A o jakich podatnościach mówimy? Do jakich aplikacji? Czy ogólnie w całym przekroju?
Krzysztof: Ogólnie, w całym przekroju CVE.
Andrzej: Dobrze. A mówimy o jakichś konkretnych platformach?
Krzysztof: Może doprecyzuję podatności, które były wykorzystywane w atakach, tak?
Andrzej: Tak, tak, tak, tak. W realnych atakach. A mówimy, jest to precyzowanie co do platformy, czy znowu bez?
Krzysztof: Czyli można. Nie, bardzo szeroko. Tam podaję przykłady od pluginów WordPressowych po systemy Fortify, więc tutaj jakby nie ma takiego stricte jakiejś kategorii, na której się skupili.
Andrzej: No to tak, jestem zaskoczony i nie poznając wcześniej metodyki, jak to liczyli, to śmiem w to wątpić. Nie kupuję tego tak bez mocnego uzasadnienia. Z prostej przyczyny. Ekonomia. Nie opłaca się używać O-Day. Każda O-Day kosztuje… bo jak tylko go wykorzystamy, to rośnie prawdopodobieństwo, że zostanie wykryty, a potem załatany, zgłoszony. i biorąc pod uwagę, że w dalszym ciągu jednak większość systemów nie jest update’owana automatycznie i nie dzieje się to w sposób taki, że wychodzi update i już dzisiaj jest mój system zaupdatowany. Po prostu nie opłaca się korzystać wtedy z O-Day, korzysta się z One Day, czyli z czegoś, co już jest znane, ale jeszcze nie jest załatane. Więc musiałbym wejść głębiej w metodykę, jeśli się nią podzielili, jak konkretnie to obliczyli, bo jest mi w to trudno uwierzyć na… Na pierwszy rzut oka. A co oni tam pisali konkretnie?
Krzysztof: No pisali tak, że spośród 138 ujawnionych podatności, które były wykorzystywane in the wild, to 70% z nich to były zero day’e. I oni wskazują tam, że to jest poważna zmiana w stosunku do tego podziału, który mogliśmy obserwować w ostatnich latach, gdzie według Google’a i według Mandianta, tak, bo to Mandiant przygotowywał tą analizę, ten podział w ostatnich latach miał się na poziomie 60-40, czyli 60 to były zero day’e, 40% to były end day’e. Tego też nie kupujesz.
Andrzej: Wiesz co, to jest mi łatwiej kupić, tamto też mogę kupić, ale muszę poznać konkretną metodykę. i dlatego stąd pytałem na samym początku o te rodzaje ataków, bo jeśli weźmiemy wszystkie, to po prostu tego nie kupuję. Ale jeśli zawężymy i oni mówią o jakichś konkretnych atakach, zawężają grupę, kto był atakowany, to oczywiście jestem w stanie kupić. Są takie przypadki, gdzie nawet 100% ataków będzie wykonywane tylko podatnościami typu zero day. Natomiast jeśli weźmiemy wszystko, to prawo dużych liczb i to, o czym już dzisiaj mówiliśmy, atakujący są oportunistyczni, bo robią na tym biznes, to jest mi ciężko uwierzyć w to, że we wszystkich atakach, które się dzieją na całym świecie, 70% z nich korzysta z ODA i po prostu brzmi to jak bajka. i dla mnie.
Krzysztof: Okej, będziecie mieli szansę sami sprawdzić w jaki sposób Mandiant, ale musisz, Andrzej, w takim razie sobie sprawdzić.
Andrzej: Tak, tak, na pewno to sprawdzę. Mam nadzieję, że nie będę musiał podawać maila, żeby ściągnąć raport. A jak będę, to trudno, to podam i będę dostawał jakieś fajne informacje od Mandianta. Mam nadzieję, że fajne.
Krzysztof: Mandiant w aporcie pokazuje również trend, który mówi o tym, że w chwili obecnej time to exploit wynosi zaledwie 5 dni, co jest dosyć dużą zmianą w porównaniu, jeżeli chodzi o lata na przykład 2018, 2019, gdzie time to exploit wynosił 63 dni, 2021, 2022, 32 dni. więc pewnie możemy tutaj założyć, że dawało to opsom, programistom, administratorom, całemu IT dosyć sporo czasu na reakcje, sporo czasu na działania. Na chwili obecnej Andrzej 5 dni, Co możemy zrobić przez pięć dni?
Andrzej: Przez pięć dni? to myślę, że ustalimy spotkanie IT i zaskedulujemy być może kolejny proces zmiany. Tym bardziej, że patchowanie w dużych organizacjach dzieje się w cyklu miesięcznym, a nie w cyklu dziennym czy tygodniowym.
Krzysztof: No właśnie, to też zależy, jaki kontekst weźmiemy pod uwagę. Jeżeli weźmiemy kontekst dużej organizacji i systemów, mówię tutaj na przykład o końcówkach, o tym, co mamy na naszych serwerach, no to będziemy inaczej podchodzić do patch managementu niż do patch managementu w wydaniu tego, co mamy w naszych aplikacjach, z czego składają się nasze aplikacje produkcyjne, prawda?
Andrzej: Tak, tak, tak, tak. Oczywiście to są dwa rozłączne od siebie problemy. No jeden jest trochę trudniejszy, drugi jest trochę łatwiejszy, ale pięć dni to w obu tych wydaniach to jest dość mało czasu.
Krzysztof: Tak, więc przy takich pięciu dniach gro pracy musi iść w taką proaktywność i założenie, że nawet jeżeli ktoś będzie w stanie wykorzystać lukę, która wynika w naszym systemie, która wynika z tego, że on jest podatny, to musimy mieć dosyć dobrze skrojoną izolację na poziomie sieci, może narzędzia, które obserwują w jakiś sposób, co się dzieje na runtime, czy tam nie są podejmowane jakieś dziwne ruchy.
Andrzej: To bezpieczeństwo coraz bardziej idzie w kierunku takiej warstwowości, takiej cebuli, No ja myślę, że ono nie coraz bardziej, ono zawsze na tym polegało. Tylko ten, można powiedzieć, nacisk jest coraz mocniejszy, że nie jest tak, że jakaś jedna warstwa rozwiąże nasze wszystkie problemy. Musimy mieć wszystkie te warstwy. I od góry do dołu każda z nich musi być na jakimś poziomie, ale musi być. Jeżeli będziemy bazować tylko na jakiejś jednej, pojedynczej albo dwóch, trzech, no to będziemy mieć problem. I ten kierunek gdzieś tam jest jasny, to jest widoczne w ostatnich dekadach, gdzie to idzie.
Krzysztof: I ostatni, Andrzej, fakt, no ostatnie stwierdzenie Mandianta w tym raporcie, którym chciałbym się z tobą podzielić, no to jest to, że Mandiant nie widzi korelacji między ujawnieniem exploitów publicznie, a time to exploit dosyć kontrowersyjne, bo ja bym pomyślał inaczej, no że publiczny exploit równa się masowa eksploitacja w… no tak indie-wide, że tak powiem.
Andrzej: Ja myślałem, że powiesz, że Mandiant nie widzi problemu. I tyle.
Krzysztof: Podsumowanie. Kupujcie usługi.
Andrzej: Dokładnie. Przerzucajcie się na Google’a. U Google’a Mandiant nie widzi problemu. Więc kierunek jasny. Nie, oczywiście hejeszki na bok. Wiesz co? I To, co powiedziałeś w dalszym ciągu, a może nawet jeszcze mocniej, po prostu umacnia tą moją reakcję i niedowierzanie na fakty, którymi się tutaj podzieliłeś. Tym bardziej będę musiał po prostu poznać metodologię, metodykę, jak oni do tego doszli, bo jeśli twierdzą, że publiczne eksploity, które gdzieś tam wychodzą, nie mają wpływu na zwiększenie ilości ataków. no to jakoś mi się to, jakoś mi się to po prostu nie spina. To znaczy, że co? Że atakujący więcej używają Odej, ale więcej po prostu sami ich znajdują? I się, no to jest takie… Oczywiście ja rozumiem, że tutaj Odej, to nie mamy tutaj informacji o tej podatności, ale mówię o tym bardzo małym wycinku czasu, gdzie coś się pojawia i wiecie, tak jak w Log4Shellu, coś się pojawiło i w zasadzie na Twitterze i w zasadzie tego samego dnia już było… Pierwsze ataki leciały. Więc czy to jest all day, czy one day? No ja w tym momencie nazwałbym to w dalszym ciągu jeszcze all dayem, jak wypłynęło na Twitterku i w jakimś małym kręgu, bo w innym wypadku, to wiecie, po datą się all day, oni się rozmawia w różnych kręgach, po prostu nie jesteście w tych kręgach. Więc… To nie jest tak, że o nich nikt nie wie, że wie tylko jedna osoba. Nie, one są omawiane często gęsto, jak się znajdzie Zero Day’a i pisze się Exploita, to jest wielotygodniowa albo miesięczna praca i oczywiście się robi to z innymi ludźmi. Często gęsto robi się to w większych lub mniejszych, ale zamkniętych społecznościach, niekoniecznie organizacjach. To mogą być po prostu konkretnie jakieś… kluby, tak to nazwijmy. Więc w tamtym ciągu są oczywiście ludzie, którzy o tym wiedzą. Tutaj chodzi o to, że Wendor o tym nie wie. I tak samo tutaj, jak ktoś upubliczni to na Twitterze, no to jeszcze trochę minie, zanim Wendor się dowie i zacznie reagować. Więc to stwierdzenie Mandianta jest dla mnie trochę… counterintuitive, wbrew intuicji, ale cały ten raport jest wbrew takiej intuicji, no będę musiał sobie rzucić okiem, może są tam jakieś key wordy, które rozjaśni mi tą sytuację.
Krzysztof: Okej, okej. No tak, oni wskazują już kończąc, że na time to exploit w ich mniemaniu będzie tutaj grało. trudność wykorzystania, motywacja, wartość docelowa tego, kogo chcą zaatakować, no i ogólna złożoność. W zasadzie troszeczkę takie buzzwordy.
Andrzej: No dokładnie. To, co wypunktowałeś, to ja myślę, że GPT mi lepsze wnioski wyciągnie, nie? Więc tak trochę… No okej, okej.
Krzysztof: A na marginesie, jak się dostać do tego klubu, gdzie sam Odeje?
Andrzej: Trzeba sam pisać Odeje, nie? Jak piszesz, to potem cię przyjmują.
Krzysztof: Zapraszają cię.
Andrzej: Tak, albo ty znajdujesz ich, albo oni znajdują ciebie i jesteście w takim klubie. Ale te kluby, przynajmniej kiedyś, jeszcze niedawno, a dekadę temu, siedziały dużo na IRCU, teraz może na jakichś innych kanałach, telegramach czy signalach. Natomiast oczywiście takie klitki istnieją. Można też pojechać na konferencje, które się zajmują stricte ofensywnym bezpieczeństwem. Posty za dużo takich nie ma, ale w Europie jakaś jedna czy dwie się znajdą i tam też pojawiają się ludzie, którzy robią bardzo ciekawe rzeczy. Można spotkać osoby, które piszą eksploity na najnowsze wersje iOS-a, które w zasadzie są technicznie milionerami i stali się nimi przez pisanie eksploitów na iOS-a i o tak można sobie z nimi porozmawiać, pośmieszkować. Dobrze, rozumiem, że teraz przechodzimy do technology radaru.
Krzysztof: Tak, przechodzimy teraz do technology radar, bo chcę zrobić tylko taką małą wstawkę jeszcze. Miałem jeszcze jedną rzecz, którą chciałem się z Andrzejem podzielić i z wami oczywiście, drodzy słuchacze, ale jest ona tak kontrowersyjna, że wydaje mi się, że YouTube od razu wydał nam shadowbana za poruszanie tego typu treści, a dotyczy ona… bardzo mrocznej strony tego, do czego wykorzystywane są duże modele językowe. Duże modele językowe, które są przechwytywane przez atakujących i pewnego rodzaju role playu, które mają te, wchodząc w interakcje z takimi modelami tego role playu, który ma się tam odgrywać. Także zostawimy link do tego researchu. On nie jest jakiś wstrząsający, ale wydaje mi się, że nie dałoby się o tym opowiedzieć, nie mówiąc pewnych słów, które pewnie nie chodzi o demotyzację tego filmu, bo na tym nie zarabiamy. Tak, ale algorytm wyłapie i nie będzie zadowolony. Także zostawimy link, a teraz szybciutko przechodzimy do Technology Radar od Fortworks.
Andrzej: Co do Technology Radar, ja w zasadzie tutaj nie mam za dużo do powiedzenia, ale to chyba się wiąże z tym, że za dużo security po prostu w nim nie było. Tak, tak, tak. Ja przeskonywałem, jakieś było cyber security jako keyword rzucone tam pięć czy sześć razy w całym radarze i to w kontekście czegoś innego. Więc takich blipów, które odnosiły się w szczególności po prostu do security, to w tym radarze nie było. Czy mi umknęły?
Krzysztof: Nie było, jeżeli chodzi o praktyki i procesy, nie było żadnego blipu, który bezpośrednio odnosiłby się do bezpieczeństwa, tak jak mogliśmy gdzieś w poprzednich edycjach radaru spotkać praktyki związane z modelowaniem zagrożeń, z secure by design, secure by default, z bał jak z bał. Tak w tym naprawdę ciężko jest, nawet jakbyś chciał na siłę, coś podciągnąć, to ciężko coś tam znaleźć, co mówiłoby o bezpieczeństwie. Jest na palcach jednej ręki, można by było tam policzyć w tym kwadrancie, który mówi o narzędziach. To takie ogólne narzędzia, bardziej vendor, jak Whiz, jeżeli chodzi o bezpieczeństwo chmury, był poruszony, ale tak poza tym to nie.
Andrzej: Dokładnie tak. I jest jedna rzecz, którą tutaj warto wypunktować. Jeden z naszych kolegów z Lev Mentors, Piotrek, pozdrawiamy. Piotrek prowadzi projekt igi.rs, który jest kolejką pisaną w raszcie. I ten projekt pojawił się w technology radar, a to jest duże osiągnięcie, bo projekt open source, który się rozpoczął jako coś pisanego tak naprawdę po godzinach. Teraz Piotrek chyba dość mocno rozwija ten projekt. ale dobił do momentu, w którym pojawił się w radarze, to oznacza, że sam ThoughtWorks lub ich klienci używają produkcyjnie tego projektu, więc tutaj brawa, brawa dla Piotrka, gratulujemy. Jest to sukces w zasadzie dużej rangi. Nie ma za dużo takich polskich projektów open source’owych, które gdzieś tam są mocno utylizowane na całym świecie i mają szansę na bycie takim standardnym w tym, co robią, w tym staku technologicznym, w którym się obracają. Tutaj winszujemy, winszujemy brawa oklaski. Piotrek, gratulacje.
Krzysztof: Tak, gratulacje dla Piotra. Z technology radar. to oczywiście taki mój mały wniosek, bardzo dużo o LEM-ach, ale ciekawostka ThoughtWorks jeszcze nie myśli, jeszcze nie daje nam do zrozumienia, że generatywna sztuczna inteligencja za… zastąpi dobrych programistów. Bo oni tam w tym blipie, który mówi o tym, żeby gdzieś tam wykorzystywać generacyjną inteligencję do pisania całych aplikacji, całego kodu, dają jeszcze jako ten pierwszy etap tam bodajże to jest hold. Tak, jako hold. Dajmy jeszcze na wstrzymanie z tym całym boomem i szałem.
Andrzej: Tak, no i jeszcze tam nie jesteśmy. Idziemy w tym kierunku, zobaczymy, czy kiedykolwiek tam dojdziemy, ale jeszcze zdecydowanie nie jesteśmy. Dobrze, Szysiek, wyrobiliśmy się, jesteśmy poniżej godziny, więc great success! To może nawet z korzyścią dla słuchaczy. No właśnie, oczywiście. Więc tutaj musimy na pewno timeboxować na godzinę i poniżej. I tak będziemy to robić w kolejnych odcinkach. Tym razem się udało i w kolejnych będziemy starać utrzymywać się tą pasę żeby jednak było max godzina, a raczej poniżej godzinki. Taki akurat można odsłuchać w jeden dzień jadąc i wracając z pracy na dwa kawałki. Dobra, Krzysiek, nie przedłużając, dzięki za dzisiejsze spotkanie. w zasadzie, w którym ty mówiłeś większość, ja mówiłem mniejszość. No i musimy to kiedyś powtórzyć, żebym tylko ja tyle gadał. No i co? Słyszymy się za chyba dwa tygodnie.
Krzysztof: Tak, słyszymy się za dwa tygodnie. Teraz będziemy pilnować tej regularności. Dajcie znać, jak wypadło nam tym razem. Subujcie, lajkujcie, podawajcie dalej. No i co? Mojego długiego weekendu, bo właśnie się zaczyna. Przynajmniej jak wy będziecie słuchać, to już będzie pewnie po…
Andrzej: To już się skończy. Właśnie, to mamy nadzieję, że was długi weekend był dobry.
Krzysztof: Będziecie przed kolejnym długim weekendem, bo jedenasty to poniedziałek. Fakt. Tak.
Andrzej: Przysiek, ty to jednak jesteś. Dobra, trzymajcie się.
Krzysztof: Wszystkiego dobrego, hej.