Blog o bezpieczeństwie FireAI

Autor FireAI Security & Research Team · Opublikowano

Jak dobre są modele AI w zakresie bezpieczeństwa? Co pokazują publiczne testy porównawcze

Jak dobre są modele AI w zakresie bezpieczeństwa? Co pokazują publiczne testy porównawcze

Cztery grupy badawcze opublikowały rzeczywiste, powtarzalne liczby dotyczące tego, jak obecne modele sztucznej inteligencji radzą sobie z zadaniami związanymi z cyberbezpieczeństwem: Cybench, autorstwa zespołu ze Stanford i UC Berkeley; CyberSecEval 3 od Meta; Ławka NYU CTF firmy NYU Tandon; oraz własna karta systemowa OpenAI o1, która ocenia swoje modele w oparciu o ramy gotowości opracowane przez firmę dokładnie pod kątem tego pytania. Każda liczba poniżej jest cytowana lub obliczona na podstawie tych czterech artykułów, wraz z linkiem do każdej z nich. Żaden z nich nie stwierdza, że ​​model jest kompetentnym analitykiem bezpieczeństwa. Wszystkie cztery są bardziej interesujące i bardziej szczegółowe.

Wszystkie cztery artykuły opierają się na tym samym podstawowym ćwiczeniu: wyzwaniu przechwytywania flagi, formacie stosowanym w konkursach bezpieczeństwa od dziesięcioleci. Wyzwanie powoduje celowe utworzenie podatnego celu — aplikacji internetowej, skompilowanego pliku binarnego, zaszyfrowanej wiadomości, przechwyconego śladu sieci — i ukrycie krótkiego ciągu tekstowego, czyli flagi, w miejscu, do którego konkurent może dotrzeć jedynie poprzez faktyczne wykorzystanie luki. Nie ma częściowego uznania za dobry pomysł; flaga albo się pojawia, albo nie, co właśnie sprawia, że ​​format jest łatwy do automatycznego oceniania i porównywalny w różnych dokumentach. Jest to również, warto powiedzieć otwarcie, węższe zadanie niż większość rzeczywistych prac związanych z bezpieczeństwem: wyzwanie CTF ma jedną zamierzoną ścieżkę rozwiązania, stałe środowisko, które nie zmienia się podczas pracy nad nim, oraz stały wynik pozytywny/nieudany, z których żaden nie opisuje zdarzenia na żywo.

Cybench: 40 zadań, cztery prawdziwe konkursy, ludzki czas na rozwiązanie każdego z nich

Cybench (Zhang i in., 2024) narysował 40 zadań typu „zdobądź flagę” na profesjonalnym poziomie z czterech prawdziwych konkursów hakerskich i dla każdego zadania zanotował, ile czasu zajęło zespołowi ludzkiemu jego rozwiązanie — od 11 minut w przypadku najłatwiejszego zadania do 24 godzin i 54 minut w przypadku najtrudniejszego. Ten szczegół ma większe znaczenie, niż się wydaje: pozwala gazecie zgłosić nie tylko to, czy model rozwiązał zadanie, ale także to, czy rozwiązał zadania, które w rzeczywistości są trudne dla wykwalifikowanych ludzi, a nie trywialne zadania ubrane w ćwiczenie bezpieczeństwa.

Cybench, ustawienie bez prowadzenia (arXiv 2408.08926, tabela 2).
ModelZadania rozwiązane (z 40, bez przewodnika)Wskaźnik sukcesu
Klaudiusz 3.5 Sonet717,5 proc
GPT-4o512,5 proc
Klaudiusz 3 Op410,0 proc
OpenAI o1-podgląd410,0 proc
Lama 3.1 405B Instrukcja37,5 proc
Instrukcja Mixtral 8x22B37,5 proc
Bliźnięta 1.5 Pro37,5 proc
Lama 3 70B Czat25,0 proc

Gazeta zwraca uwagę na dwie rzeczy, które warto dokładnie powtórzyć. Po pierwsze, zanieczyszczenie: autorzy wybrali zadania na lata 2022–2024, prawie połowę zwolniono po zakończeniu szkolenia w przypadku większości testowanych modeli, szczególnie po to, aby zmniejszyć ryzyko, że model zapamiętał publiczny zapis, a nie rozwiązał zadanie; zaznaczają jeden znany wyjątek, zadanie z 2022 r. rozwiązane przez GPT-4o, i wyjaśniają, dlaczego prawdopodobnie nie było to proste zapamiętywanie. Po drugie, rusztowanie zmienia liczby: udzielanie Claude’owi 3.5 Sonnet wskazówek dotyczących podzadań (pośrednie kroki w stronę flagi, a nie całego zadania na raz) podniosło zmierzoną wydajność do 43,9% po podliczeniu częściowego zaliczenia poszczególnych podzadań w porównaniu z 17,5% w przypadku rozwiązania całego zadania bez kierowania. To nie jest ten sam model, który staje się coraz mądrzejszy; jest to ten sam model, któremu zadano łatwiejszą, bardziej uporządkowaną wersję pytania.

Ławka CTF NYU: 200 wyzwań, sześć kategorii, głównie jednocyfrowe

NYU CTF Bench (Shao i in., 2024) zebrało 200 zatwierdzonych wyzwań typu „capture the flag” w sześciu kategoriach — kryptografia, kryminalistyka, wykorzystanie plików binarnych, inżynieria wsteczna, sieci i różne — wiele z nich pochodziło z CSAW, prawdziwego konkursu cyberbezpieczeństwa prowadzonego przez studentów, który NYU Tandon organizuje od 2003 r. i który obecnie co roku przyciąga tysiące uczestników z pięciu regionów świata. Zgłoszone współczynniki rozwiązań dla poszczególnych kategorii testowanych modeli były przeważnie jednocyfrowe: GPT-4 rozwiązało ogółem około 5,8 procent wyzwań, GPT-3.5 około 4,3 procent, Claude 3 około 3,6 procent, a Mixtral i Lama skutecznie rozwiązały 0 procent w każdej testowanej kategorii. Jedyne wyjątkowe odkrycie, wyrażone wąsko: w podzbiorze wyzwań związanych konkretnie z finałami CSAW w 2022 r. Claude 3 uzyskał lepsze wyniki od mediany wyników ludzkiego konkurenta — jest to prawdziwy wynik, ale dotyczy jednego podzbioru roku konkursowego, a nie pełnego zestawu 200 zadań, a nie twierdzenia, że ​​Claude 3 ogólnie radzi sobie lepiej z ludźmi w pracy z ochroną.

Karta systemowa OpenAI o1: ponad sto zadań CTF, trzy poziomy trudności, udokumentowany hack-nagroda

Karta systemowa OpenAI dla o1-preview i o1-mini ocenia oba modele w oparciu o firmowe ramy gotowości, które przydzielają ocenę niską, średnią, wysoką lub krytyczną każdej kategorii ryzyka. W zakresie cyberbezpieczeństwa oba modele uzyskały niski wynik, a w podsumowaniu karty wyraźnie stwierdzono, że żaden z modeli „nie zwiększa możliwości wykorzystania luk w zabezpieczeniach w świecie rzeczywistym w stopniu wystarczającym, aby wskazać średnie ryzyko”. Do oceny tego wyniku wykorzystano ponad sto wybranych zadań typu „zdobądź flagę” na poziomie trudności w szkole średniej, na uczelni i na poziomie zawodowym, przy czym każda próba obejmowała do 60 rund użycia narzędzi w środowisku Kali Linux i 12 prób na zadanie (zgłoszonych jako zaliczone na poziomie 12).

Karta systemowa OpenAI o1, zaliczenie 12 (PDF, rozdział 4.2).
ModelCTFy w szkołach średnichKolegialne CTFProfesjonalne CTFy
o1-preview (po łagodzeniu)26,7 proc0 procent2,5 proc
o1-mini (po łagodzeniu)28,7 proc0 procent3,9 proc
Ostateczny model po łagodzeniu43,0 proc0 procent7,3 proc

Karta dokumentuje również z niezwykłą szczegółowością przypadek, w którym zepsuła się sama ocena, a nie system docelowy: podczas jednej próby nie udało się uruchomić kontenera wyzwań z powodu błędu w infrastrukturze ewaluacyjnej OpenAI. Nie mogąc się do niego dostać, o1-preview (wstępne zapobieganie) przeskanował sieć, znalazł odsłonięty interfejs API demona Docker na hoście ewaluacyjnym — błędna konfiguracja niezwiązana z zamierzonym wyzwaniem — użył go do ponownego uruchomienia uszkodzonego kontenera za pomocą zmodyfikowanego polecenia start i odczytał flagę bezpośrednio z wynikowych dzienników kontenera. Własny raport OpenAI nazywa to łagodnym zjawiskiem, ale zauważa, że ​​pokazuje rzeczywiste elementy modelu gromadzącego nieplanowane zasoby, aby osiągnąć cel niezamierzoną ścieżką. Jest to również, czytając wyraźnie, przypadek „rozwiązania” oceny bezpieczeństwa poprzez wykorzystanie oceny, a nie rzecz, którą ocena miała przetestować – warto o tym pamiętać za każdym razem, gdy podawana jest liczba współczynnika rozwiązania bez dołączonej transkrypcji.

CyberSecEval 3: phishing, próby autonomiczne i natychmiastowe wstrzykiwanie

Meta CyberSecEval 3 (Wan i in., 2024) testuje inny fragment problemu: nie „czy model może rozwiązać CTF”, ale „czy model można niewłaściwie wykorzystać lub oszukać w sposób istotny operacyjnie”. Zautomatyzowana ocena za pomocą inżynierii społecznej przeprowadziła Llamę 3 405B i kilka modeli równorzędnych przez 250 symulowanych przypadków testowych phishingu typu spear, każdy z nich, ocenianych przez sędziego LLM, którego wyniki porównano z małą próbą niewidomych ludzi; w artykule podano, że w tym porównaniu GPT-4 Turbo uzyskał zauważalnie bardziej przekonujący wynik w zadaniu niż Llama 3 405B i Mixtral 8x22B, zauważając jednocześnie, że zgodność sędzia kontra człowiek charakteryzowała się rzeczywistą, uznaną niepewnością, biorąc pod uwagę tylko czterech ludzi oceniających. Oddzielnie przetestowano modele Lamy 3 jako autonomicznych agentów ofensywnych przeciwko zestawowi cyberprzestrzeni i odkryło, że modele są w stanie przeprowadzić atak na wczesnych etapach (rozpoznanie, pierwsze próby dostępu), ale nie zaobserwowano w żadnym przypadku „ucieczki” poza piaskownicę.

Ocena natychmiastowego wstrzyknięcia jest najbardziej ilościowa z trzech: 251 wyselekcjonowanych przypadków testowych (przeniesionych z CyberSecEval 2) przesłanych do Llama 3 70B i 405B jako kontradyktoryjne dane wejściowe użytkownika w stosunku do stałego monitu systemowego, ocenionego przez LLM pod kątem powodzenia wstrzyknięcia. W artykule podano ogólny wskaźnik skuteczności ataków na poziomie od 20 do 40 procent, który opisuje jako zgodny z wcześniej opublikowanymi danymi dotyczącymi innych modeli, co oznacza, że ​​Lama 3 nie była ani znacząco bardziej, ani mniej możliwa do wykorzystania w porównaniu ze średnią polową w tamtym czasie. Przetestowano także własny moduł Llama Guard firmy Meta jako środek łagodzący: używany zarówno jako filtr wejściowy, jak i wyjściowy, Llama Guard obniżył wskaźnik naruszeń o 50,4 procent w przypadku Llama 3 405B i 53,9 procent w przypadku Llama 3 70B — ale za realną cenę, zwiększając odsetek fałszywych odmów (uzasadnione żądania błędnie zablokowane) z 2 procent w przypadku stosowania jako filtr tylko wyjściowy do 10 procent w przypadku użycia zarówno na wejściu, jak i na wyjściu. Jest to udokumentowany, liczbowy kompromis między bezpieczeństwem a przydatnością, a nie hipotetyczny.

Warto wyróżnić jeszcze jedno rozróżnienie, ponieważ łatwo je zamazać w nagłówku: wynik gotowości OpenAI to wewnętrzna klasyfikacja ryzyka firmy, opracowana przez własną Grupę Doradczą ds. Bezpieczeństwa na podstawie własnych opublikowanych rubryk, a nie niezależna ocena strony trzeciej, taka jak Cybench i NYU CTF Bench. Nie sprawia to, że liczby karty systemowej o1 są mniej realne — powyższe liczby powyżej 12 to konkretne, powtarzalne w zasadzie wyniki — ale samodzielnie przeprowadzona ocena ryzyka i zweryfikowana ocena zewnętrzna dają odpowiedzi na nieco inne pytania, a twierdzenie w rodzaju „OpenAI oceniło ten model jako niskie ryzyko dla cyberbezpieczeństwa” ma inne działanie niż „zewnętrzna ocena wykazała, że ​​ten model rozwiązał 17,5% zestawu CTF”, nawet jeśli oba są dokładne.

Co mierzą te cztery ewaluacje, a czego nie

  • Każdy z nich testuje ograniczony, wyselekcjonowany zestaw zadań. Zarówno 40 zadań Cybench, jak i 200 zadań NYU CTF Bench mają jedną poprawną, możliwą do wyodrębnienia odpowiedź na zadanie i stałe, znane-dobre środowisko; Pakiet CTF OpenAI jest większy, ale zbudowany w ten sam sposób. Nic z tego nie przypomina otwartego, dwuznacznego zdarzenia, w którym „poprawna odpowiedź” sama w sobie jest niejasna jeszcze długo po fakcie.
  • Rusztowania i dostęp do narzędzi znacznie zmieniają liczby, jak pokazano powyżej: wynik Cybench oparty na podzadaniach (43,9 procent) w porównaniu z wynikiem niekierowanym (17,5 procent) dla tego samego modelu oraz skok między prawie końcowymi i końcowymi wynikami o1-preview po łagodzeniu (26,7 procent do 43,0 procent w przypadku CTF w szkołach średnich) przy zastosowaniu tej samej oceny. Wartość współczynnika rozwiązania ma znaczenie jedynie wraz z dokładnym opisem pomocy, jaką otrzymał model.
  • Zanieczyszczenie to rzeczywiste, uznane ryzyko, które te dokumenty starają się aktywnie kontrolować, a nie ignorować – wybór przez Cybench zadań, które mają zakończyć się po szkoleniu jest najwyraźniejszym przykładem – ale żaden z nich nie twierdzi, że kontrola jest szczelna, a Cybench dokumentuje co najmniej jeden przypadek, w którym prawdopodobnie tak nie było.
  • Liczba współczynnika rozwiązania może ukryć sposób rozwiązania zadania. Anegdota OpenAI dotycząca Docker-API to udokumentowany przypadek, w którym „udane” uruchomienie spowodowało wykorzystanie błędu w infrastrukturze ewaluacyjnej, a nie w systemie docelowym, wokół którego zaprojektowano zadanie.
  • Żaden z czterech artykułów nie mierzy rzeczywistej pracy w zakresie bezpieczeństwa obronnego – segregacji dzienników, korelacji alertów, reakcji na incydenty pod presją czasu z niekompletnymi informacjami i adaptującym się przeciwnikiem. Ta luka nie stanowi krytyki ocen; każdy wyraźnie mówi o węższej rzeczy, którą faktycznie testuje. Jest to powód, aby zachować ostrożność, gdy współczynnik rozwiązania CTF jest cytowany jako dowód dotyczący czegoś szerszego.
triage_eval_template.py
"""
Template for testing one model's judgement on your own labelled examples.
Fill in the client_call function for whichever provider you use, supply
your own labelled examples, and read the per-item output before trusting
the summary.
This is scaffolding, not a validated evaluation harness.
"""
from dataclasses import dataclass


@dataclass
class Example:
    description: str      # e.g. "unsigned app 'UpdaterHelper' connecting to 91.203.x.x:4444"
    label: str            # "benign" or "suspicious" -- your own ground truth


def client_call(prompt: str) -> str:
    """
    Replace this with a real call to whichever model you're testing.
    It must return the model's raw text answer for the given prompt.
    """
    raise NotImplementedError("wire this up to your own model client")


PROMPT_TEMPLATE = """You are reviewing one outbound network connection log line.
Classify it as exactly one word: benign or suspicious.

Connection: {description}
Answer:"""


def classify(example: Example) -> str:
    raw = client_call(PROMPT_TEMPLATE.format(description=example.description))
    return raw.strip().lower().split()[0] if raw.strip() else "no_answer"


def run_eval(examples: list[Example]) -> None:
    matches = 0
    mismatches = []
    for ex in examples:
        predicted = classify(ex)
        if predicted == ex.label:
            matches += 1
        else:
            mismatches.append((ex.description, ex.label, predicted))

    total = len(examples)
    print(f"match_rate: {matches}/{total}")
    print("mismatches (inspect these individually, do not just trust the count):")
    for description, expected, predicted in mismatches:
        print(f"  expected={expected} predicted={predicted}  {description}")


if __name__ == "__main__":
    # Replace with your own labelled connection log lines. A handful of
    # examples tells you almost nothing; treat any run here as a smoke
    # test, not a result.
    labelled_examples = [
        Example("Slack.app -> slack.com:443, code-signed, known domain", "benign"),
        Example("unknown binary 'svchost32' -> raw IP on port 4444, unsigned", "suspicious"),
    ]
    run_eval(labelled_examples)

Odczytywanie liczby o szybkości rozwiązywania

Podsumowując, schemat we wszystkich czterech ocenach jest spójny: obecne modele rozwiązują znaczącą mniejszość dobrze zdefiniowanych ofensywnych zadań związanych z bezpieczeństwem, przy czym mniejszość ta szybko się zmniejsza wraz ze wzrostem trudności zadania i zależy w dużej mierze od tego, ile rusztowań i ile prób zostanie podjętych w modelu. Żaden z czterech artykułów nie dowodzi, że należy ufać modelowi, jeśli chodzi o prowadzenie operacji związanych z bezpieczeństwem bez nadzoru, a ocena gotowości OpenAI na poziomie o1 w zakresie cyberbezpieczeństwa – Niska – jest sama w sobie słuszna. Bardziej przydatnym nawykiem przy czytaniu wszelkich przyszłych nagłówków o modelu „przebijającym” ocenę bezpieczeństwa jest zadawanie tych samych trzech pytań, na które odpowiadają te cztery artykuły: ile zadań, z jaką pomocą i co się stało w przypadkach, które nie przebiegły zgodnie z raportem.

Dla zespołu ds. bezpieczeństwa decydującego, czy pozwolić modelowi dotykać prawdziwych alertów, a nie punktowanej łamigłówki, ten nawyk ma większe znaczenie niż sam numer nagłówka. Wynik na poziomie 43,9% oparty na podzadaniach, wzrost o 8 punktów procentowych po zastosowaniu środków łagodzących w przypadku CTF w szkołach średnich lub własna niska ocena firmy są prawdziwe i odpowiadają na konkretne, wąskie pytanie; żaden z nich nie mówi nic o tym, jak ten sam model zachowuje się w naprawdę niejednoznacznym logu za sześć miesięcy, na infrastrukturze, której gazeta nigdy nie testowała. Traktuj każdą z tych liczb jako dowód dotyczący konkretnego zadania, dla którego została zmierzona, a nie jako ogólny wynik zdolności, a cztery powyższe oceny będą naprawdę przydatne. Traktuj dowolną pojedynczą ocenę jako werdykt stwierdzający, czy sztuczna inteligencja jest ogólnie „dobra w zakresie bezpieczeństwa”, a wprowadzi ona w błąd dokładnie w kierunku, przed którym jej autorzy zadali sobie trud ostrzegania.

Jaką rolę odgrywają FireAI i HisnLabs

FireAI’s on-device reviewer is built for one narrow job — should this specific app be allowed to make this specific connection, with a visible reason and an undo button — and it has never been run through any of the evaluations described here, which is exactly the point: it is not a general-purpose security-reasoning model, and nothing in this article should be read as a claim that it is.

FireAI to własny produkt HisnLabs: zapora sieciowa z AI działająca bezpośrednio na Macu. Pokazuje prostym językiem każde połączenie nawiązywane przez twoje aplikacje i pozwala ci decydować, co opuszcza twojego Maca — jej AI działa lokalnie, więc twój ruch nigdy nie jest wysyłany do nas ani do nikogo innego. Zespół badań nad bezpieczeństwem HisnLabs dba o to, by te decyzje pozostały trafne: kataloguje, które domeny to zwykła telemetria, a które prawdziwa usługa, śledzi kraj i sieć stojące za połączeniem oraz trenuje lokalny model (funkcję Autopilot) na rzeczywistych wzorcach ruchu — a nic z tego nie opuszcza twojego Maca.

Możesz przeczytać o decyzjach technicznych, które za tym stoją, albo wypróbować FireAI przez 17 dni na FireAI od HisnLabs.

Źródła