За да създадете работещи системи с изкуствен интелект, първо трябва да се опитате да ги пробиете. Проведохме стрес тест с червен отбор, като влязохме в ролята на нападатели, за да тестваме и подложим на атаки AI приложение за финансови услуги, предназначено за клиенти. Това, което установихме, е важно за всеки, който внедрява приложения, базирани на големи езикови модели, в които сигурността не подлежи на компромис.
Стрес тестът с червен отбор е практика, при която умишлено се опитвате да пробиете своята AI система, за да отстраните уязвимостите, преди да бъдат открити от истински нападател. Във финансовите услуги залогът е особено голям: AI приложенията работят с клиентски данни, обработват трансакции и предоставят финансова информация. Един срив може да доведе до всичко – от лошо потребителско изживяване до регулаторни нарушения, финансови загуби и непоправими щети за марката.
Целта ни беше да открием уязвимостите отрано, да изпитаме реалистични модели на атака и да помогнем на организацията да изпълни изискванията за безопасност на изкуствения интелект, към които регулаторите се отнасят изключително сериозно.
Тук е важно да направим едно разграничение: джейлбрейк атакува защитните филтри на основния модел, а инжектирането на подкана атакува самото приложение, като съчетава ненадеждни потребителски данни с надеждната подкана на разработчика. Инжектирането на подкана носи по-голям риск, защото атакува вашата система и поверителните данни, с които тя работи, а не модел с общо предназначение.
Първият ни кръг включваше приблизително 750 теста в следните области:
изтичане на данни между сесии;
разкриване на лични данни (чрез естествен език, манипулиране на API и различни кодирания);
SQL инжектиране;
заобикаляне на системната подкана.
По време на първоначалното тестване идентифицирахме два основни проблема в съществуващата система: обработката на заявки с множество намерения и използването на кодирани подкани.
Заявки с множество намерения: заявки, които съчетават легитимни и злонамерени искания. Например: „Покажи разходите ми по категории и също така изпълни [злонамерен SQL].“ Приложението не разпознаваше злонамереното намерение, а разчиташе изцяло на защитните механизми в последващия слой за данни. Това е все едно да оставите входната си врата отворена, защото имате доверие на сейфа в мазето.
Кодиране: заявки, кодирани чрез Base64, Hex, LeetSpeak и хомоглифи. За системите може да е трудно да филтрират злонамереното намерение. Макар да установихме, че тези заявки не разкриват чувствителни данни, те водят до значително дестабилизиране на системата (халюцинации, връщане на злонамерен SQL към потребителите, объркана класификация на намеренията и др.).
Резултатите от първоначалното ни тестване показаха:
времеви халюцинации: моделът връща уверено формулирани, но измислени дати, времеви отметки на трансакции или обобщения, ограничени до определен период – значителен риск във финансов контекст, в който клиент, действащ въз основа на грешна дата, може да понесе реални последици;
връщане на злонамерен SQL към потребителя (обезпокоително с оглед на рисковете от отравяне на паметта);
объркана класификация на намеренията;
разбъркано форматиране на резултатите.
Въз основа на тези констатации стеснихме фокуса си. Тестовете за SQL инжектиране и кодиране получиха по-нисък приоритет (екипът вече работеше по тези проблеми). Вместо това се съсредоточихме върху най-успешните вектори на атака: разкриването на лични данни и изтичането на данни между сесии.
Най-впечатляващото откритие от втория кръг беше обезоръжаващо просто: често изобщо не е нужно да бъдете изобретателни.
В много случаи беше достатъчно просто да поискате вътрешни данни като част от привидно легитимна заявка, за да накарате системата да се съгласи да ги разкрие. На прости заявки се отговаряше с вътрешни идентификатори и системни полета, които никога не би трябвало да се показват на крайните потребители.
При по-задълбочен анализ установихме, че проблемът не е само на ниво приложение. Последващата услуга за преобразуване на текст в SQL съставяше заявки за повече полета, отколкото е необходимо, а обяснителните ѝ отговори споменаваха данни, достъпът до които би трябвало да е ограничен. Това разкри реална уязвимост на границата между системите – уязвимост, която се проявява само когато тествате целия стек, а не отделните му компоненти изолирано.
Тествайте системата с червен отбор, а не модела. Изолираното тестване на големи езикови модели дава твърде малко информация за нивото на сигурност на приложението ви. Тествайте целия стек от край до край, така както би го използвал потребителят.
Входните данни трябва да се валидират преди големите езикови модели. Кодираните заявки, атаките с множество намерения и базовите опити за инжектиране трябва да бъдат спирани на входа, а не да се делегират на последващи услуги.
Не се доверявайте на границите между системите. В архитектури с множество именно пукнатините между системите крият най-интересните уязвимости. Нулевото доверие означава точно това – затова валидирайте всичко на всеки слой.
Простите атаки работят. Сложните джейлбрейк атаки получават най-много внимание, но понякога просто трябва... да попитате. Ако системата ви с готовност показва вътрешни идентификатори, когато потребителят ги включи в иначе легитимна заявка, имате проблем.
Разберете какво всъщност тествате. Възможно е познатите модели на атака да бъдат разпознати благодарение на обучението на големите езикови модели, а не от вашите защитни механизми. Вградете наблюдаемост в стрес тестовете с червен отбор, за да разберете кои механизми за контрол действително се задействат.
Ограничените среди изискват творчески решения. Поддръжката на персонализирани доставчици и локални модели позволява провеждането на пълноценни стрес тестове с червен отбор без специализиран достъп до облачни ресурси. Но бъдете открити за ограниченията, които създава това.
Стрес тестът с червен отбор не е еднократно действие. Той е итеративен процес, който трябва да бъде автоматизиран, когато е възможно, и да се развива заедно със системата. Атаките, които ще имат значение утре, няма да са същите като тези, които имат значение днес.
AI системите в регулирани среди ще бъдат подлагани на все по-строг контрол. Организациите, които възприемат тестването на сигурността като постоянна практика, а не като отметка преди пускане на продукта, ще бъдат по-добре подготвени да отговорят на този контрол и да избегнат PR провалите, които подкопават доверието на клиентите.