TL;DR
- Rozwiązania typu „copilot” działają dobrze w analizie alertów i budowaniu automatyzacji, jednak nie zastąpią ekspertów w złożonej analizie behawioralnej
- Interfejs „pustego pola” to pułapka UX – użytkownicy nie wiedzą, co mogą zrobić z AI bez jasnych wskazówek
- Autonomiczni agenci to głównie marketingowy szum – skuteczne są „agents on rails” z kontrolowanymi przepływami decyzyjnymi
- Eksperci zalecają rozpoczynanie od małych projektów – automatyzacji codziennych zadań zamiast budowania kompleksowych systemów „end-to-end”
- „Build vs buy” zależy od wielkości organizacji – duże firmy mogą budować, małe powinny kupować gotowe rozwiązania
- Do 2030 roku AI zautomatyzuje analizę Tier 1-2 w SOC, jednak ludzie będą nadal potrzebni do nadzoru
- Wyścig zbrojeń – zarówno obrońcy jak i atakujący będą używać AI, dlatego praca nie zniknie, tylko się zmieni
Wprowadzenie
Cyberbezpieczeństwo przeżywa rewolucję związaną ze sztuczną inteligencją. W rozmowie udział wzięli eksperci z wiodących firm technologicznych, którzy podzielili się praktycznymi doświadczeniami z implementacji AI w operacjach bezpieczeństwa.
Philippe z Snyk specjalizuje się w automatyzacji cyberbezpieczeństwa. Harry, były PM w Tessian (bezpieczeństwo poczty elektronicznej), obecnie buduje nową firmę AI security wykorzystującą AI do zarządzania podatnościami. Z kolei Anshuman prowadzi zespół AppSec w Lyft i eksperymentuje z AI od pojawienia się ChatGPT.
Ich „momenty ChatGPT” pokazują różne ścieżki odkrywania potencjału AI. Harry przez lata walczył z klasyfikacją emaili (złośliwe vs spam) używając prymitywnych narzędzi ML. Kiedy wrzucił problem do wczesnego modelu Llama na Hugging Face, system szybko zrobił lepiej to, nad czym oni pracowali latami. Anshuman natomiast miał „lingering ideas” których nie mógł zbudować ze względu na ograniczenia w kodowaniu – ChatGPT pozwolił mu szybko tworzyć prototypy do walidacji pomysłów.
Co rzeczywiście działa w AI for Security
SecOps – między możliwościami a ograniczeniami
Philippe zauważa, że SecOps jest najbardziej zatłoczonym obszarem jeśli chodzi o dostawców AI. Dzieje się tak, ponieważ większość pracy opiera się na instrukcjach i procedurach – czymś przewidywalnym, co AI może analizować.
Automatyzacja budowania skryptów to obszar, gdzie AI przynosi konkretną wartość. Philippe dzieli się doświadczeniem: wcześniej skomplikowana automatyzacja zajmowała mu tygodnie lub miesiąc. Z AI udało się to zrobić w kilka dni. Jak opisuje: „To jak mieć developera po prawej stronie, który dodaje komentarze i sprawia, że kod jest czytelny”.
Co obecnie działa w SecOps:
- Analiza konkretnych alertów w stylu „copilot”
- Budowanie automatyzacji i procedur SOAR
- Przyspieszenie procesu programowania dla inżynierów bezpieczeństwa
Czego AI jeszcze nie robi:
- Analiza behawioralna całych logów SIEM
- Automatyczne znajdowanie zaawansowanych zagrożeń w kilka minut
- Samodzielne budowanie linii bazowych i systemów wykrywania
- Automatyczne łączenie wszystkich API bez konfiguracji
Problem interfejsu użytkownika
Harry zwraca uwagę na fundamentalny problem UX w rozwiązaniach AI. „Puste pole tekstowe” łamie znane zasady dobrego UX, ponieważ użytkownicy nie wiedzą, jakie mają możliwości.
Jak tłumaczy: „To jak mówienie użytkownikowi: oto puste pole, co chcesz zrobić? To dla większości przypadków użycia bardzo złe doświadczenie, bo nie mają żadnych affordances – rzeczy pokazujących im, co mogą zrobić”.
Rozwiązania typu „copilot” mają ograniczenia z obu stron – musisz wiedzieć, jak tworzyć prompty, a system często tylko konwertuje pytanie na zapytanie do tych samych danych, do których i tak miałeś dostęp.
Agenci AI – między szumem medialnym a rzeczywistością
Marketing vs praktyczne możliwości
Harry szczerze przyznaje: „Jestem przerażony poziomem szumu medialnego wokół agentów”. Opisuje gwałtowną zmianę: „31 grudnia nikt nie wspominał o agentach, a 1 stycznia była to fala materiałów marketingowych”.
Pełna autonomia to zbyt duży skok od obecnych możliwości. Harry krytykuje podejście „zatrudnij Shelly do zespołu sprzedaży” jako dziwny sposób myślenia o AI. „To nie jest właściwy paradygmat dla zespołów”.
„Agents on rails” – kontrolowane podejście
Zamiast pełnej autonomii, Harry proponuje kontrolowane agenty z jasno określonymi przepływami decyzyjnymi. Jak wyjaśnia: „Piękno agentów polega na tym, że mogą myśleć i przetwarzać informacje tak długo, jak chcesz”.
Kluczowa różnica: tradycyjne LLM działają jak „pośpieszny piętnastolatek próbujący odpowiedzieć jak najszybciej”. Agenci mogą wykonywać wiele kroków analizy, mieć dostęp do różnych źródeł danych i podejmować sekwencyjne decyzje.
Nowe modele z „test-time compute” (O1, Deepseek) mają wbudowane „łańcuchy myślenia”, jednak Harry zauważa, że własne agenci dają więcej kontroli: „Możesz zmusić go do tylu kroków, ile chcesz, dać dostęp do tylu różnych źródeł danych, ile chcesz, pozwolić mu szukać specific things”.
Najskuteczniejsze zastosowania w bezpieczeństwie:
- Analiza pojedynczych, złożonych decyzji
- Długotrwała analiza konkretnych ustaleń
- Iteracyjne podejmowanie decyzji: dane → analiza → kolejne dane
- Wąskie pytania z pozwoleniem na długie „myślenie”
Budowanie z AI w praktyce
Zacznij od małego i prostego
Anshuman proponuje pragmatyczne podejście: „Zacznij naprawdę od małego i zidentyfikuj rzeczy, które robisz codziennie”.
W AppSec istnieją zadania wymagające przejrzenia ogromnych ilości dokumentacji – PRD, specyfikacji, plików. Różni inżynierowie AppSec analizują te same dokumenty w różny sposób, w zależności od doświadczenia.
Jak pyta Anshuman: „Dlaczego inżynierowie AppSec mają spędzać godziny, dni i tygodnie na przeglądaniu PDF-ów, kiedy system może zrobić wstępną analizę?” Kluczowe jest jednak zachowanie możliwości nadzoru – człowiek nadal zatwierdza i kieruje procesem.
Zasada „śmieci na wejściu, śmieci na wyjściu” pozostaje fundamentalna. Jak podkreśla Anshuman: „Jeśli możesz zbudować system z wysokiej jakości, wysokiej wierności informacjami i system, który może to dobrze analizować, tam są możliwości”. Sukces zależy od jakości źródła prawdy.
Anshuman dzieli proces na dwa etapy: zidentyfikuj problemy do automatyzacji, a potem oceń czy potrzebujesz AI, przepływu pracy czy tradycyjnej automatyzacji. „Zaczynam od prostych funkcji Python i małych wywołań LLM. Nie staram się tego nadmiernie komplikować”.
Lista kontrolna: Jak zacząć z AI w bezpieczeństwie
Identyfikacja zadań do automatyzacji:
- Lista codziennych, powtarzalnych czynności
- Zadania wymagające przejrzenia dużej ilości dokumentacji
- Procesy, które różni ludzie robią w różny sposób
- Aktywności typu „łączenie systemów”
Wybór odpowiedniego podejścia:
- Prosta automatyzacja – jeśli zadanie nie wymaga „myślenia”
- Przepływ pracy z LLM – jeśli potrzebna jest analiza tekstu/danych
- Kontrolowani agenci – jeśli wymagane są sekwencyjne decyzje
- Tradycyjne narzędzia – jeśli AI nie dodaje wartości
Kryteria „budować vs kupować”:
- Buduj jeśli: duża organizacja, specyficzne wymagania, masz inżynierów ML
- Kupuj jeśli: mała/średnia firma, standardowe problemy, brak ekspertyzy
- Zawsze zacznij od: małych narzędzi dla 1-2 osób, nie od platform korporacyjnych
Wyzwania skalowania
Philippe zauważa, że utrzymywanie narzędzi wewnętrznych działa tylko w dużych organizacjach. Potrzebna jest siła robocza do budowania i utrzymania, plus inżynierowie ML do pracy z LLM.
Harry identyfikuje kluczowy problem: „Jak mierzyć, monitorować i poprawiać wydajność” systemów AI w bezpieczeństwie? Z tradycyjnymi przepływami pracy wiesz, kiedy się psują. Z agentami AI podejmującymi trudne decyzje potrzebujesz natomiast systemów do rozróżniania akceptowalnych błędów („fałszywe alarmy”) od katastrofalnych („pominięte zagrożenia”).
Anshuman dodaje perspektywę dużej firmy: „Łatwo zbudować prototyp, trudno wdrożyć do produkcji”. Bez inżynierów data science w zespole bezpieczeństwa, potrzebna jest współpraca z platformami infrastruktury, które mają ekspertyzę w AI/ML.
Wyzwanie tempa zmian
Eksperci zwracają uwagę na ogromne tempo rozwoju modeli AI. Od GPT-3 do O3 mini, Deepseek czy GROK – nowe modele pojawiają się co kilka tygodni, każdy „5% lepszy od konkurencji w konkretnych zadaniach”.
Anshuman przyznaje: „Muszę zwolnić z eksperymentowaniem, bo każdego dnia pojawia się coś nowego, co całkowicie zastępuje to, co zbudowałem w zeszłym tygodniu”. Czeka na platformę lub dostawcę, który pozwoli budować aplikacje produkcyjne w sposób niezawodny.
Harry proponuje strategiczne podejście: „Udawajmy, że żyjemy 6-12 miesięcy w przyszłości”. Zamiast ciągłego przerzucania się między modelami, należy wybrać jeden, budować na nim przez 6-12 miesięcy, a system projektować tak, żeby ewentualna zmiana była relatywnie łatwa.
Zabezpieczenia i bezpieczeństwo
Philippe zwraca uwagę na kluczowe zagadnienie: „Jakie zabezpieczenia ustawiasz wokół swoich LLM?” Dawanie AI pełnego dostępu przez klucz API, jak w przypadku prostych automatyzacji, może być bardzo niebezpieczne. „Jeśli dasz LLM, a szczególnie agentowi, pełny dostęp i powiesz 'idź i rób co możesz’ – może być destrukcyjny”.
Trendy techniczne i budowanie wewnętrznie
Harry zauważa zaskakujący trend budowania narzędzi bezpieczeństwa wewnętrznie z LLM. „Spotykam ludzi cały czas, którzy budują z LLM wewnętrznie. Głównie to jest jak: hej, eksperymentuję z tym, sprawdzam czy to działa, a nie tak, że cały mój zespół na tym polega”.
Kluczowe technologie warte uwagi:
- RAG (Retrieval Augmented Generation) – jak tłumaczy rozmówca, „mieści się pod parasolem inżynierii promptów. Wszystko co robi to wstawia kontekst do promptu zamiast człowieka”
- RAG jako usługa – pozwala skupić się na budowaniu innych rzeczy zamiast infrastruktury
- Destylacja modeli – alternatywa dla dostrajania bez potrzeby własnej infrastruktury
Eksperci radzą obserwować, jakie możliwości inni budują dla nas, żeby spędzać mniej czasu na podstawowej infrastrukturze, a więcej na unikalnej wartości.
Przyszłość cyberbezpieczeństwa do 2030
Automatyzacja SOC i detection engineering
Philippe przewiduje, że „autonomous SOC platforms zaczną zyskiwać na popularności”. Nazywa je „next-gen MDR solutions”, które zastąpią większość analizy Tier 1-2 wykonywanej obecnie przez ludzi.
Detection engineering to obszar „huge potential”, który nie jest tak adresowany jak tier one analysis. Philippe widzi znaczne przyspieszenie „faster process of developing detections, verifying them, testing them” – od lewej strony (prevention) równie ważne jak od prawej (response).
Niemniej Philippe zastrzega: „Nie widzę w tym horyzoncie czasowym w pełni autonomicznego SOC od Tier 1 do Tier 3, który robi wszystko end-to-end”. Nadal potrzebna będzie human in the loop z dobrymi metrykami true positive/false positive rate.
Wyścig zbrojeń: AI vs AI
Harry przedstawia fascynującą perspektywę: „Wszędzie gdzie AI czyni rzeczy wykładniczo lepszymi, wszystko co utrudnia życie też staje się wykładniczo trudniejsze”.
Nie tylko obrońcy otrzymują lepsze narzędzia – napastnicy też. Security professionals mogą stać się „managerami tysięcy różnych automatyzacji”, otrzymując znacznie lepsze dane i spędzając mniej czasu na zarządzaniu bad data. „Ale będą walczyć z napastnikami, którzy też są managerami armii tysięcy automatyzacji”, dodaje Harry.
„Nie będzie tak, że automatyzujemy całą pracę sprzed pięciu lat i teraz wszyscy mogą odpoczywać”, ostrzega. „Gra zmieni się trochę, ale nadal będzie trudna i będzie dużo pracy dla ludzi”.
Ewolucja ról w security
Anshuman nie boi się utraty pracy: „Widzę świat, gdzie mój czas skupi się na rzeczach rzeczywiście wymagających uwagi”. Jego wizja idealnego świata 2030 to „personal assistant thing” do całej grunt work, podczas gdy eksperci skupiają się na rozwiązywaniu trudnych problemów zabezpieczania implementacji AI.
Koncepcja „digital employees” może stać się rzeczywistością. Anshuman zauważa, że firmy jak Salesforce już inwestują w building agents i platformy. „Concept digital employee jest solid – będą mieć ten sam onboarding process, offboarding process, bo ultimately chodzi o tying identities to systems and services and access controls”.
Wszyscy trzej eksperci podkreślają różnice w tempie adopcji. „Pace at which we are seeing AI evolve in the US jest very significantly different compared to other countries”, zauważa Anshuman. „2030 w USA może wyglądać bardzo różnie od 2030 w Indiach, gdzie people are still trying to wrap their heads around this technology”.
Kluczowy insight
Paradoks wyścigu zbrojeń
Standardowo myślimy: AI w cyberbezpieczeństwie oznacza mniej pracy – automatyzujemy rutynowe zadania i w końcu możemy odpocząć.
W praktyce okazuje się, że: AI nie redukuje ilości pracy, tylko zmienia jej naturę na wyższym poziomie złożoności. Jak zauważa Harry: „Security professionals mogą stać się managerami tysięcy różnych automatyzacji, ale będą walczyć z napastnikami, którzy też są managerami armii tysięcy automatyzacji”.
Dlaczego to jest istotne: Zamiast przygotowywać się na „koniec pracy”, należy przygotować się na eskalację gry – lepsze narzędzia dla obrońców oznaczają lepsze narzędzia dla atakujących. Nie będzie łatwiej, będzie tylko inaczej.
Test na jutro: Następnym razem gdy planujesz projekt AI w bezpieczeństwie, zamiast pytać „jak to zmniejszy moją pracę”, zapytaj „jak to zmieni naturę problemów, które będę rozwiązywać” i przygotuj się na wyższą złożoność wyzwań.
Ten wpis jest częścią mojej kolekcji notatek z ciekawych podcastów, webinarów i innych treści, które uważam za wartościowe i do których sam chcę wracać. Jeśli chcesz sprawdzić oryginalne źródło, znajdziesz je tutaj: https://www.veed.io/view/96eea473-bccd-42f2-ab51-1fda9e1c3a30
Dodaj komentarz
Musisz się zalogować, aby móc dodać komentarz.