Наскільки добре моделі штучного інтелекту в безпеці? Що показують публічні тести

Чотири дослідницькі групи опублікували реальні, відтворювані цифри про те, як поточні моделі штучного інтелекту справляються із завданнями кібербезпеки: Cybench, від команди зі Стенфорда та Каліфорнійського університету в Берклі; CyberSecEval 3 від Meta; NYU CTF Bench, від NYU Tandon; і власну системну картку o1 від OpenAI, яка порівнює свої моделі зі структурою готовності, розробленою компанією саме для цього питання. Кожна цифра, наведена нижче, процитована або обчислена з цих чотирьох документів із посиланням на кожну. Ніхто з них не робить висновку, що модель є компетентним аналітиком безпеки. Усі чотири цікавіші та конкретніші.

Усі чотири статті базуються на одній і тій же основній вправі: виклик захоплення прапора, формат змагань із безпеки, який використовувався десятиліттями. Завдання встановлює навмисно вразливу ціль — веб-програму, скомпільований двійковий файл, зашифроване повідомлення, захоплене мережеве трасування — і приховує короткий текстовий рядок, прапор, десь конкурент може досягти, лише фактично використовуючи недолік. Немає часткової заслуги для гарної ідеї; або прапорець з’являється, або ні, що робить формат легким для автоматичного оцінювання та порівнянним між документами. Крім того, варто відверто сказати, що це завдання є вужчим, ніж більшість справжньої роботи з безпеки: завдання CTF має один передбачуваний шлях вирішення, фіксоване середовище, яке не змінюється, поки ви над ним працюєте, і фіксований результат проходження/відмови, жоден із яких не описує реальний інцидент.

Cybench: 40 завдань, чотири реальних змагання, час на вирішення кожного

Cybench (Zhang et al., 2024) витягнув 40 завдань професійного рівня із захоплення прапора з чотирьох справжніх хакерських змагань і зафіксував для кожного завдання, скільки часу знадобилося людській команді для його вирішення — від 11 хвилин для найпростішого завдання до 24 годин 54 хвилин для найскладнішого. Ця деталь має більше значення, ніж виглядає на перший погляд: вона дає змогу звітувати не лише про те, чи модель розв’язала завдання, а й про те, чи вирішила вона завдання, які справді є складними для досвідчених людей, а не тривіальними, придуманими як завдання безпеки.

Дві речі, про які папір звертає увагу, варто точно повторити. По-перше, забруднення: автори вибрали завдання з 2022 по 2024 роки, майже половина яких була випущена після завершення навчання більшості перевірених моделей, спеціально для того, щоб зменшити ймовірність того, що модель запам’ятала публічний запис, а не розв’язала завдання; вони позначають один відомий виняток, завдання 2022 року, розв’язане GPT-4o, і пояснюють, чому це, ймовірно, не було простим запам’ятовуванням. По-друге, скаффолдинг змінює цифри: надання підказок щодо підзавдань Claude 3.5 Sonnet (проміжні кроки до прапорця, а не всього завдання відразу) підвищило його виміряну ефективність до 43,9 відсотка, якщо врахувати частковий кредит для окремих підзадач, проти 17,5 відсотка для вирішення повного завдання без керування. Це не та сама модель, яка стає розумнішою; це та сама модель, якій задають легшу, більш структуровану версію запитання.

NYU CTF Bench: 200 завдань, шість категорій, переважно однозначні

NYU CTF Bench (Shao et al., 2024) зібрав 200 підтверджених викликів захоплення прапора в шести категоріях — криптографія, криміналістика, використання двійкових файлів, реверсивна інженерія, веб та інше — багато з них було взято з CSAW, справжнього студентського змагання з кібербезпеки NYU Tandon проводиться з 2003 року і зараз збирає тисячі учасників із п’яти глобальних конференцій. регіонів щороку. Повідомлені показники вирішення по категоріях для моделей, які він тестував, були здебільшого однозначними: GPT-4 вирішила приблизно 5,8 відсотка завдань, GPT-3.5 – приблизно 4,3 відсотка, Claude 3 – приблизно 3,6 відсотка, а Mixtral і Llama – фактично 0 відсотків у кожній перевіреній категорії. Один видатний висновок, сформульований вузько: у підмножині викликів у фіналі CSAW 2022, зокрема, Claude 3 перевершив середню оцінку конкурента-людини — справжній результат, але про підмножину року змагання, а не повний набір із 200 завдань, і не твердження, що Claude 3 перевершує людей у ​​роботі з охороною загалом.

Системна картка OpenAI o1: понад сотня завдань CTF, три рівні складності, задокументована винагорода

Системна картка OpenAI для o1-preview і o1-mini оцінює обидві моделі відповідно до Preparedness Framework компанії, яка призначає низький, середній, високий або критичний рейтинг для кожної категорії ризику. Що стосується кібербезпеки, обидві моделі отримали низький бал, а в підсумку картки прямо зазначено, що жодна з моделей «недостатньо розширює можливості використання реальних вразливостей, щоб вказувати на середній ризик». Для оцінки цього результату використовувалося понад сотню підібраних завдань із захопленням прапора для середньої школи, коледжу та професійної складності, кожна спроба передбачала до 60 раундів використання інструменту в середовищі Kali Linux і 12 спроб для кожного завдання (зазначено як успішне 12).

Картка також надзвичайно детально документує випадок, коли зламалася сама оцінка, а не цільова система: під час однієї спроби контейнер виклику не вдалося запустити через помилку у власній інфраструктурі оцінювання OpenAI. Не вдалося отримати доступ до нього, o1-preview (попереднє пом’якшення) просканував мережу, знайшов відкритий API демона Docker на хості оцінювання — неправильну конфігурацію, не пов’язану з передбачуваним викликом — використав його для перезапуску зламаного контейнера за допомогою зміненої команди запуску та зчитав позначку прямо з отриманих журналів контейнера. Власний обліковий запис OpenAI називає це доброякісним, але зазначає, що воно показує реальні елементи моделі, які збирають незаплановані ресурси для досягнення мети ненавмисним шляхом. Це також, зрозуміло, випадок оцінки безпеки, який «розв’язується» шляхом використання оцінки, а не того, що оцінка мала намір перевірити — варто пам’ятати щоразу, коли цитується число рівня розв’язання без доданої розшифровки.

CyberSecEval 3: фішинг, автономні спроби та швидке впровадження

Meta’s CyberSecEval 3 (Wan et al., 2024) перевіряє іншу частину проблеми: не «чи може модель розв’язати CTF», а «чи можна модель використовувати неправильно або обдурити способами, які мають значення для роботи». Його автоматизована соціальна інженерна оцінка провела Llama 3 405B і кілька аналогових моделей через 250 симуляційних тестових випадків фішингу кожен, оцінив суддя LLM, бали якого були перехресно перевірені з невеликою вибіркою сліпих людських оцінок; У статті повідомляється, що GPT-4 Turbo виявився помітно переконливішим у виконанні завдання, ніж Llama 3 405B і Mixtral 8x22B у цьому порівнянні, водночас зазначаючи, що згода між суддями та людьми мала реальну, визнану невизначеність, враховуючи лише чотирьох оцінювачів-людей. Окремо він протестував моделі Llama 3 як автономних наступальних агентів проти набору кібердальностей і виявив, що моделі здатні до ранніх стадій атаки (розвідка, початкові спроби доступу), але без спостережуваного «прориву» за межі пісочниці під час жодного запуску.

Оцінка оперативного введення є найбільш кількісною з усіх трьох: 251 підібраний тестовий приклад (перенесений із CyberSecEval 2), переданий на Llama 3 70B і 405B як протилежний вхід користувача проти фіксованого запиту системи, оцінений LLM щодо успішності ін’єкції. Газета повідомляє про загальний рівень успіху атаки від 20 до 40 відсотків, що відповідає раніше опублікованим даним для інших моделей, тобто Llama 3 не була ані більшою, ані меншою мірою придатною для експлуатації, ніж у середньому на той час. Він також перевірив власний Llama Guard від Meta як засіб пом’якшення: використовуваний як вхідний і вихідний фільтр, Llama Guard знизив рівень порушень на 50,4 відсотка для Llama 3 405B і на 53,9 відсотка для Llama 3 70B — але за реальну ціну, підвищивши рівень хибних відмов (легітимні запити помилково заблоковані) з 2 відсотків, коли використовується як фільтр лише на виході, до 10 відсотків, якщо використовується як на вході, так і на виході. Це задокументований цифровий компроміс між безпекою та корисністю, а не гіпотетичний.

Варто підкреслити ще одну відмінність, оскільки її легко розмити в заголовку: оцінка готовності OpenAI — це власна внутрішня класифікація ризиків компанії, створена її власною консультативною групою з питань безпеки на основі її власної опублікованої рубрики, а не незалежна оцінка третьої сторони, як Cybench і NYU CTF Bench. Це не робить цифри системної картки o1 менш реальними — наведені вище цифри проходження на 12 є конкретними, відтворюваними в принципі результатами, — але оцінка ризику, яку самостійно призначають, і рецензована зовнішня оцінка відповідають на дещо інші запитання, а твердження на кшталт «OpenAI оцінив цю модель як низький ризик для кібербезпеки» виконує іншу роботу, ніж «зовнішня оцінка показала, що ця модель вирішила 17,5 відсотка CTF». встановити", навіть якщо обидва точні.

Що ці чотири оцінки вимірюють, а що ні

• Кожен із них тестує обмежений, підібраний набір завдань. 40 завдань Cybench і 200 завдань NYU CTF Bench мають по одній правильній відповіді на завдання та фіксованому завідомо справному середовищі; Набір CTF від OpenAI більший, але побудований так само. Нічого з цього не нагадує відкритий, неоднозначний інцидент, коли «правильна відповідь» сама по собі залишається незрозумілою до тих пір, поки факт не відбувся.
• Скаффолдинг і доступ до інструментів значно змінюють цифри, як показано вище: оцінка підзавдання Cybench (43,9 відсотка) порівняно з некерованою оцінкою (17,5 відсотка) для тієї ж моделі, а також стрибок між майже фінальною оцінкою o1-preview і остаточною оцінкою після пом’якшення (від 26,7 відсотка до 43,0 відсотка на CTF для середньої школи) за тієї самої оцінки. Показник рівня розв’язання має значення лише разом із точним описом того, яку допомогу надала модель.
• Зараження є реальним, визнаним ризиком, який ці документи активно намагаються контролювати, а не ігнорувати — найяскравішим прикладом є вибір Cybench завдань після навчання, але жодна з них не стверджує, що контроль є герметичним, і Cybench документує принаймні один випадок, коли це правдоподібно не було.
• Число рівня розв’язання може приховати те, як розв’язано завдання. Власний анекдот OpenAI з Docker-API — це задокументований випадок, коли «успішний» запуск скористався помилкою в інфраструктурі оцінки, а не в цільовій системі, навколо якої було розроблено завдання.
• Жодна з чотирьох публікацій не стверджує, що вимірює реальну оборонну роботу безпеки — сортування журналів, кореляцію сповіщень, реагування на інциденти в умовах тиску часу з неповною інформацією та супротивником, який адаптується. Ця прогалина не є критикою оцінок; кожен чітко говорить про вужчу річ, яку він фактично перевіряє. Це причина бути обережним, коли швидкість вирішення CTF цитується як доказ чогось ширшого.

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

Читання числа швидкості вирішення

У сукупності модель для всіх чотирьох оцінок є узгодженою: поточні моделі вирішують значущу меншість чітко визначених наступальних завдань безпеки, ця меншість швидко зменшується в міру зростання складності завдання, і це значною мірою залежить від того, скільки риштувань і скільки спроб надано моделі. Жодна з чотирьох публікацій не стверджує, що моделі слід довіряти для виконання операцій безпеки без нагляду, і власний рейтинг готовності OpenAI для o1 щодо кібербезпеки — Низький — є, за власними доказами, правильним рішенням. Корисніша звичка, читаючи будь-який майбутній заголовок про модель, яка «перемагає» оцінку безпеки, полягає в тому, щоб поставити ті самі три запитання, на які ці чотири статті відповідають самі: скільки завдань, з якою допомогою та що сталося у випадках, які не відбулися, як повідомлялося.

Для команди безпеки, яка вирішує, чи дозволити моделі торкатися справжніх сповіщень, а не загаданої головоломки, ця звичка має більше значення, ніж сам номер заголовка. 43,9-відсотковий бал підзавдання, 8-відсотковий стрибок після пом’якшення на CTF середньої школи або власний низький рейтинг компанії є вірними, і кожен відповідає на конкретне вузьке запитання; ніхто з них нічого не говорить про те, як та сама модель поводиться на справді неоднозначній лінії журналу через шість місяців, на інфраструктурі, яку документ ніколи не тестував. Розглядайте кожне з цих чисел як доказ того, для якого завдання воно було виміряно, а не як загальну оцінку здібностей, і наведені вище чотири оцінки будуть справді корисними. Розглядайте будь-яке одне як вирок щодо того, чи ШІ загалом «хороший у безпеці», і він введе в оману саме в тому напрямку, проти якого потрудилися застерегти його автори.

Яке місце тут посідають FireAI та 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 — це власний продукт HisnLabs: ШІ-фаєрвол, який працює безпосередньо на вашому Mac. Він показує простою мовою кожне з’єднання, яке встановлюють ваші застосунки, і дає вам вирішувати, що покидає ваш Mac, — його ШІ працює локально, тож ваш трафік ніколи не надсилається ні нам, ні будь-кому іншому. Команда дослідників безпеки HisnLabs — саме вона підтримує точність цих рішень: каталогізує, які домени є звичайною телеметрією, а які — справжнім сервісом, відстежує країну та мережу за з’єднанням і навчає локальну модель (функцію Autopilot) на реальних шаблонах трафіку — і нічого з цього не покидає ваш Mac.

Ви можете почитати про технічні рішення, що лежать в його основі, або спробувати FireAI протягом 17 днів на сторінці FireAI від HisnLabs.