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

Tag: Harry Tessian

AI w cyberbezpieczeństwie – praktyczny przewodnik ekspertów #EN152