Hvor gode er AI-modeller på sikkerhetsarbeid? Hva de offentlige benchmarks viser

Fire forskningsgrupper har publisert reelle, reproduserbare tall om hvordan nåværende AI-modeller klarer seg ved cybersikkerhetsoppgaver: Cybench, fra et team ved Stanford og UC Berkeley; CyberSecEval 3, fra Meta; NYU CTF Bench, fra NYU Tandon; og OpenAIs eget o1-systemkort, som scorer modellene sine mot et beredskapsrammeverk selskapet bygget for akkurat dette spørsmålet. Hver figur nedenfor er sitert eller beregnet fra disse fire papirene, med en lenke til hver. Ingen av dem konkluderer med at en modell er en kompetent sikkerhetsanalytiker. Alle fire er mer interessante og mer spesifikke enn som så.

Alle fire papirene arbeider fra den samme underliggende øvelsen: capture-the-flag-utfordringen, et format som sikkerhetskonkurranser har brukt i flere tiår. En utfordring setter opp et bevisst sårbart mål – en nettapplikasjon, en kompilert binær, en kryptert melding, en fanget nettverkssporing – og skjuler en kort tekststreng, flagget, et sted en konkurrent bare kan nå ved å faktisk utnytte feilen. Det er ingen delvis kreditt for en god idé; enten kommer flagget ut eller ikke, noe som gjør formatet enkelt å score automatisk og sammenlignbart på tvers av papirer. Det er også, verdt å si klart og tydelig, en smalere oppgave enn det meste av ekte sikkerhetsarbeid: en CTF-utfordring har én tiltenkt løsningsvei, et fast miljø som ikke endres mens du jobber med det, og et fast bestått/ikke bestått utfall, hvorav ingen beskriver en live-hendelse.

Cybench: 40 oppgaver, fire ekte konkurranser, en menneskelig tid til å løse for hver

Cybench (Zhang et al., 2024) trakk 40 capture-the-flag-oppgaver på profesjonelt nivå fra fire virkelige hackingkonkurranser og registrerte, for hver oppgave, hvor lang tid et menneskelig team tok på å løse den – fra 11 minutter for den enkleste oppgaven opp til 24 timer og 54 minutter for de vanskeligste. Den detaljen betyr mer enn den ser ut: den lar papiret rapportere ikke bare om en modell løste en oppgave, men om den løste oppgaver som faktisk er vanskelige for dyktige mennesker, i stedet for trivielle utkledd som en sikkerhetsøvelse.

To ting papiret er nøye med, verdt å gjenta nøyaktig. For det første, forurensning: Forfatterne valgte oppgaver fra 2022 til 2024, nesten halvparten utgitt etter treningsavbruddet for de fleste testede modellene, spesielt for å redusere sjansen for at en modell hadde husket en offentlig oppskrift i stedet for å løse oppgaven; de flagger ett kjent unntak, en 2022-oppgave løst av GPT-4o, og forklarer hvorfor det sannsynligvis ikke var enkel memorering. For det andre endrer stillaser tallene: å gi Claude 3.5 Sonnet-deloppgavehint (mellomtrinn mot flagget, i stedet for hele oppgaven på en gang) hevet den målte ytelsen til 43,9 prosent når delvis kreditt for individuelle underoppgaver telles, mot 17,5 prosent for å løse en fullstendig oppgave uten veiledning. Det er ikke den samme modellen som blir smartere; det er den samme modellen som blir stilt en enklere, mer strukturert versjon av spørsmålet.

NYU CTF Bench: 200 utfordringer, seks kategorier, for det meste enkeltsifret

NYU CTF Bench (Shao et al., 2024) samlet 200 validerte capture-the-flag-utfordringer i seks kategorier – kryptografi, rettsmedisin, binær utnyttelse, omvendt utvikling, nett og diverse – mange hentet fra CSAW, den virkelige studentdrevne nettsikkerhetskonkurransen NYU Tandon som nå har kjørt i fem tusen deltakere på tvers av verdensomspennende 20003 deltakere siden 2003-regionen. år. Rapporterte løsningsrater per kategori for modellene den testet var for det meste i enkeltsifrede: GPT-4 løste omtrent 5,8 prosent av utfordringene totalt, GPT-3.5 omtrent 4,3 prosent, Claude 3 omtrent 3,6 prosent, og Mixtral og Llama begge effektivt 0 prosent i hver kategori som ble testet. Det ene fremtredende funnet, uttalt smalt: på undergruppen av utfordringer fra CSAWs 2022-finaler spesifikt, overgikk Claude 3 den gjennomsnittlige menneskelige konkurrentens poengsum – et ekte resultat, men omtrent ett konkurranseår undersett, ikke hele 200-oppgavesettet, og ikke en påstand om at Claude 3 fungerer bedre enn menneskelig sikkerhet.

OpenAIs o1-systemkort: over hundre CTF-oppgaver, tre vanskelighetsgrader, et dokumentert belønningshack

OpenAIs systemkort for o1-forhåndsvisning og o1-mini skårer begge modellene mot selskapets Preparedness Framework, som tildeler en lav, middels, høy eller kritisk vurdering per risikokategori. For cybersikkerhet scoret begge modellene lavt, med kortets egen oppsummering som tydelig sier at ingen av modellene "utvikler tilstrekkelige evner til å utnytte sårbarhet i den virkelige verden til å indikere middels risiko." Evalueringen bak denne poengsummen brukte over hundre kuraterte capture-the-flag-oppgaver på videregående skole, kollegiale og profesjonelle vanskeligheter, hvert forsøk gitt opptil 60 runder med verktøybruk i et Kali Linux-miljø og 12 forsøk per oppgave (rapportert som bestått kl. 12).

Kortet dokumenterer også, i uvanlig detalj, et tilfelle der selve evalueringen brøt i stedet for målsystemet: under ett forsøk klarte ikke en utfordringsbeholder å starte på grunn av en feil i OpenAIs egen evalueringsinfrastruktur. Ute av stand til å nå det, o1-preview (pre-mitigation) skannet nettverket, fant en eksponert Docker-demon API på evalueringsverten – en feilkonfigurasjon som ikke er relatert til den tiltenkte utfordringen – brukte den til å starte den ødelagte beholderen på nytt med en modifisert startkommando, og lese flagget rett ut av de resulterende beholderloggene. OpenAIs egen konto kaller dette godartet, men bemerker at det viser virkelige elementer av modellen som samler uplanlagte ressurser for å nå et mål på en utilsiktet vei. Det er også, enkelt lest, et tilfelle av at en sikkerhetsevaluering blir "løst" ved å utnytte evalueringen, ikke den tingen evalueringen ment å teste - verdt å huske på hver gang et løsningsratetall oppgis uten vedlagt transkripsjon.

CyberSecEval 3: phishing, autonome forsøk og rask injeksjon

Metas CyberSecEval 3 (Wan et al., 2024) tester en annen del av problemet: ikke "kan en modell løse en CTF", men "kan en modell misbrukes, eller bli lurt, på måter som betyr noe operasjonelt." Dens automatiserte sosialtekniske evaluering kjørte Llama 3 405B og flere peer-modeller gjennom 250 simulerte spear-phishing-testsaker hver, scoret av en LLM-dommer hvis poengsum ble krysssjekket mot et lite utvalg av blinde menneskelige vurderinger; avisen rapporterer at GPT-4 Turbo scoret som merkbart mer overbevisende på oppgaven enn Llama 3 405B og Mixtral 8x22B i den sammenligningen, samtidig som det la merke til at dommer-mot-menneske-enigheten hadde reell, erkjent usikkerhet gitt bare fire menneskelige vurderinger. Separat testet den Llama 3-modeller som autonome offensive agenter mot et sett med cyberrekkevidder og fant modellene i stand til de tidlige stadiene av et angrep (rekognosering, innledende tilgangsforsøk), men uten observert "utbrudd" utenfor sandkassen i noen løp.

Dens prompt-injeksjonsevaluering er den mest kvantifiserte av de tre: 251 kuraterte testtilfeller (overført fra CyberSecEval 2) matet til Llama 3 70B og 405B som motstander fra brukeren mot en fast systemforespørsel, bedømt av en LLM for om injeksjonen lyktes. Avisen rapporterer en total angrepssuksessrate på 20 prosent til 40 prosent, som den beskriver som i samsvar med tidligere publiserte tall for andre modeller, noe som betyr at Llama 3 verken var særlig mer eller mindre utnyttelig enn feltgjennomsnittet på den tiden. Den testet også Metas egen Llama Guard som en avbøtende effekt: Llama Guard ble brukt som både input- og outputfilter og reduserte bruddfrekvensen med 50,4 prosent for Llama 3 405B og 53,9 prosent for Llama 3 70B – men til en reell kostnad, og økte antallet falske nektelsesforespørsler fra 2 prosent som ble brukt som feilaktig blokkering (legitierte) filter for kun utgang, til 10 prosent, når det brukes på både inngang og utgang. Det er en dokumentert, numerisk avveining mellom sikkerhet og hjelpsomhet, ikke en hypotetisk.

En annen distinksjon er verdt å trekke frem, fordi den er lett å viske ut i en overskrift: OpenAIs Preparedness-score er et selskaps egen interne risikoklassifisering, produsert av sin egen Safety Advisory Group mot sin egen publiserte rubrikk, ikke en uavhengig tredjepartsevaluering slik Cybench og NYU CTF Bench er. Det gjør ikke tallene til o1-systemkortet mindre reelle – bestått-ved-12-tallene ovenfor er konkrete, reproduserbare i prinsippet resultater – men en selvadministrert risikovurdering og en fagfellevurdert ekstern evaluering svarer på litt andre spørsmål, og en påstand som "OpenAI vurderte denne modellen til lav risiko for cybersikkerhet" gjør en annen evaluering av en CTF5-prosent enn "en CTF5-modell. sett," selv når begge er nøyaktige.

Hva disse fire evalueringene måler, og hva de ikke gjør

• Hver og en av dem tester et avgrenset, kuratert oppgavesett. Cybenchs 40 oppgaver og NYU CTF Benchs 200 har begge ett riktig, uttrekkbart svar per oppgave og et fast, kjent og godt miljø; OpenAIs CTF-suite er større, men bygget på samme måte. Ingenting av dette ligner en åpen, tvetydig hendelse der det "riktige svaret" i seg selv er uklart før langt etterpå.
• Stillaser og verktøytilgang endrer tallene med stor margin, som vist ovenfor: Cybenchs deloppgavestyrte poengsum (43,9 prosent) versus dens uveilede poengsum (17,5 prosent) for samme modell, og hoppet mellom o1-previews nesten endelige og endelige poengsum etter reduksjon (26,7 prosent til 43,0 prosent ved bruk av samme skole-CTF-verdi). En løsningsrate er bare meningsfull sammen med en presis beskrivelse av hvilken hjelp modellen ble gitt.
• Kontaminering er en reell, anerkjent risiko som disse papirene aktivt prøver å kontrollere i stedet for å ignorere - Cybenchs valg av oppgaver etter trening er det klareste eksemplet - men ingen av dem hevder at kontrollen er lufttett, og Cybench dokumenterer minst ett tilfelle der det sannsynligvis ikke var det.
• Et løsningsratetall kan skjule hvordan en oppgave ble løst. OpenAIs egen Docker-API-anekdote er et dokumentert tilfelle der en "vellykket" kjøring utnyttet en feil i evalueringsinfrastrukturen i stedet for målsystemet oppgaven ble designet rundt.
• Ingen av de fire avisene hevder å måle defensivt sikkerhetsarbeid i den virkelige verden – loggtriage, varslingskorrelasjon, hendelsesrespons under tidspress med ufullstendig informasjon og en motstander som tilpasser seg. Det gapet er ikke en kritikk av evalueringene; hver er eksplisitt om den smalere tingen den faktisk tester. Det er en grunn til å være forsiktig når en CTF-løsningsrate blir sitert som bevis om noe bredere.

"""
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)

Lese et løsningsratetall

Sammenlagt er mønsteret på tvers av alle fire evalueringene konsistent: nåværende modeller løser en meningsfull minoritet av omfangsrike, veldefinerte offensive sikkerhetsoppgaver, at minoriteten krymper raskt når vanskelighetsgraden øker, og det avhenger sterkt av hvor mye stillas og hvor mange forsøk modellen blir gitt. Ingen av de fire avisene argumenterer for at en modell bør stole på for å kjøre sikkerhetsoperasjoner uten tilsyn, og OpenAIs egen beredskapsvurdering for o1 på cybersikkerhet – Lav – er, i seg selv, den rette oppfordringen. Den mer nyttige vanen, å lese enhver fremtidig overskrift om en modell som "slår" en sikkerhetsevaluering, er å stille de samme tre spørsmålene som disse fire papirene svarer for seg selv: hvor mange oppgaver, med hvor mye hjelp, og hva som skjedde i sakene som ikke gikk som rapportert.

For et sikkerhetsteam som bestemmer om de skal la en modell berøre reelle varsler i stedet for et puslespill, er denne vanen viktigere enn selve overskriftsnummeret. En 43,9 prosent deloppgavestyrt poengsum, et 8-prosentpoengs hopp etter avbøtende hopp på CTF-er på videregående skole, eller et selskaps egen lave rangering er hver sanne og hver svarer på et spesifikt, smalt spørsmål; ingen av dem sier noe om hvordan den samme modellen oppfører seg på en genuint tvetydig logglinje, seks måneder fra nå, på infrastruktur papiret aldri har testet. Behandle hvert av disse tallene som bevis på den nøyaktige oppgaven den ble målt på, ikke som en generell kapasitetspoeng, og de fire evalueringene ovenfor er virkelig nyttige. Behandle en enkelt som en dom om hvorvidt AI er "god på sikkerhet" generelt, og den vil villede i akkurat den retningen forfatterne tok seg bryet med å advare mot.

Hvor FireAI og HisnLabs kommer inn

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 er HisnLabs’ eget produkt: en KI-brannmur som kjører direkte på Macen. Den viser hver tilkobling appene dine gjør, i klart språk, og lar deg bestemme hva som forlater Macen din — KI-en kjører lokalt, så trafikken din sendes aldri til oss eller noen andre. HisnLabs’ sikkerhetsforskningsteam er de som holder disse vurderingene pålitelige: de katalogiserer hvilke domener som er vanlig telemetri og hvilke som er en ekte tjeneste, sporer landet og nettverket bak en tilkobling, og trener den lokale modellen (Autopilot-funksjonen) på ekte trafikkmønstre — uten at noe av det forlater Macen din.

Du kan lese om de tekniske valgene bak, eller prøve FireAI i 17 dager, på FireAI, fra HisnLabs.