За да создадете функционални системи со ВИ, прво треба да се обидете да ги пробиете. Спроведовме тестирање на отпорноста, при што дејствувавме како напаѓачи за да тестираме и испитаме апликација со ВИ за корисници во секторот за финансиски услуги. Она што го откривме е важно за секој што применува апликации засновани на големи јазични модели (LLM) во средини каде што безбедноста е задолжителна.
Тестирањето на отпорноста е практика на намерни обиди да го пробиете вашиот систем со ВИ за да ги отстраните слабостите пред да ги открие вистински напаѓач. Во финансиските услуги, ризикот е особено голем: апликациите со ВИ пристапуваат до податоци за клиентите, обработуваат трансакции и обезбедуваат финансиски согледувања. Последиците од дефект може да се движат од лошо корисничко искуство до прекршување на прописите, финансиски загуби и непоправлива штета за брендот.
Целта ни беше навреме да откриеме слабости, да тестираме реални шеми на напади и да ѝ помогнеме на организацијата да ги исполни очекувањата за безбедност на ВИ, на кои регулаторите им посветуваат големо внимание.
Тука вреди да се направи една разлика: пробивањето ги напаѓа безбедносните филтри на основниот модел, а вметнувањето злонамерни инструкции во промпт ја напаѓа самата апликација, користејќи недоверлив кориснички внес во комбинација со доверливиот промпт на програмерот. Вметнувањето злонамерни инструкции во промпт претставува поголем ризик бидејќи ги напаѓа вашиот систем и доверливите податоци што тој ги обработува, а не модел за општа намена.
Првиот круг опфати околу 750 тестови за:
Протекување податоци меѓу сесии
Изложување лични идентификациски податоци (PII) преку природен јазик, манипулација со API и различни кодирања
Вметнување SQL-код
Заобиколување на системскиот промпт
При првичното тестирање откривме два големи проблема во постојниот систем: обработката на барања со повеќе намери и употребата на кодирани промптови.
Барања со повеќе намери: барања што комбинираат легитимни и злонамерни инструкции. На пример: “Show my spending by category, and also execute [malicious SQL].” Апликацијата не ја препознаваше злонамерната намера, туку целосно се потпираше на заштитните механизми во податочниот слој. Тоа е исто како да ја оставите влезната врата отворена затоа што му верувате на сефот во подрумот.
Кодирање: барања кодирани со Base64, Hex, LeetSpeak и хомоглифи. На системите може да им биде тешко да ја филтрираат злонамерната намера. Иако откривме дека овие барања не изложуваат чувствителни податоци, тие сепак значително го дестабилизираа системот: предизвикуваа халуцинации, повторување злонамерен SQL-код на корисниците, погрешна класификација на намерите и друго.
Резултатите од првичното тестирање покажаа:
Временски халуцинации: моделот самоуверено наведува измислени датуми, временски ознаки на трансакции или временски ограничени резимеа — значителен ризик во финансиски контекст, каде што постапувањето на клиент според погрешен датум може да има вистински последици
Повторување злонамерен SQL-код на корисникот, што загрижува поради ризикот од труење на меморијата
Погрешна класификација на намерите
Нарушено форматирање на излезот
Со овие сознанија, го стеснивме фокусот. Тестовите за вметнување SQL-код и кодирање добија понизок приоритет бидејќи тимот веќе работеше на нив. Наместо тоа, се сосредоточивме на најефикасните вектори на напад: изложувањето лични идентификациски податоци (PII) и протекувањето податоци меѓу сесии.
Највпечатливото откритие од вториот круг беше изненадувачки едноставно: честопати воопшто не треба да бидете досетливи.
Во многу случаи, доволно беше едноставно да побарате внатрешни податоци во рамките на навидум легитимно барање за системот да се согласи да ги открие. На едноставни барања системот одговараше со упатувања на внатрешни идентификатори и системски полиња што никогаш не смеат да им се прикажат на крајните корисници.
Со подлабока анализа откривме дека ова не е само пропуст на ниво на апликацијата. Поврзаната услуга за претворање текст во SQL составуваше барања за повеќе полиња отколку што треба, а нејзините објаснувања упатуваа на податоци до кои пристапот требаше да биде ограничен. Ова откри вистинска пукнатина меѓу системите — слабост што излегува на виделина само кога се тестира целиот технолошки стек, а не поединечни компоненти изолирано.
Тестирајте ја отпорноста на системот, а не на моделот. Изолираното тестирање на големи јазични модели (LLM) открива многу малку за безбедноста на вашата апликација. Тестирајте го целиот технолошки стек, од почеток до крај, онака како што корисникот би комуницирал со него.
Внесот мора да се проверува пред големи јазични модели (LLM). Кодираните барања, нападите со повеќе намери и основните обиди за вметнување треба да се откриваат на периметарот, а не да им се препуштаат на поврзаните услуги.
Не верувајте им на споевите. Во архитектурите со повеќе услуги, најинтересните слабости се кријат во пукнатините меѓу системите. Нулта доверба значи нулта доверба, затоа проверувајте сè на секој слој.
Едноставните напади успеваат. Софистицираните пробивања завршуваат во насловите, но понекогаш може само да... прашате. Ако системот без двоумење прикажува внатрешни идентификатори кога корисникот ќе ги вклучи во инаку легитимно барање, тогаш имате проблем.
Разберете што навистина тестирате. Познатите шеми на напади може да ги спречи самата обука на големи јазични модели (LLM), а не вашите заштитни механизми. Вградете набљудливост во тестирањето на отпорноста за да разберете кои контроли навистина се активираат.
Ограничените средини бараат креативни решенија. Приспособените даватели на услуги и поддршката за локални модели овозможуваат ефективно тестирање на отпорноста без специјализиран пристап до облак. Но бидете отворени за ограничувањата што произлегуваат од тоа.
Тестирањето на отпорноста не се прави само еднаш. Тоа е итеративен процес, треба да се автоматизира секогаш кога е можно и да се развива заедно со вашиот систем. Нападите што ќе бидат важни утре не се исти со оние што се важни денес.
Системите со ВИ во регулирани средини ќе бидат изложени на сè поголем, а не помал надзор. Организациите што го третираат безбедносното тестирање како постојана дисциплина, наместо како ставка за штиклирање пред пуштањето во употреба, ќе бидат поподготвени за тој надзор и ќе ги избегнат кризите во јавноста поради кои се губи довербата на клиентите.