В това интервю за Help Net Security Ерика Дийн, директор по информационна сигурност (CISO) на Tricentis, говори за избягването на използването на производствени данни в средите за тестване и защо смята, че алтернативите вече са достатъчно добри. Тя обяснява как нейният екип е открил пропуск, свързан с подмяна на инструкциите (prompt injection), по време на симулация на атаки (red-teaming) и е задържал пускането на нова версия с една седмица, докато уязвимостта не бъде коригирана.

Дийн описва какво може да доведе до отхвърлянето на доставчик на изкуствен интелект (ИИ) – най-вече неясните отговори за това къде се съхраняват данните и колко време се пазят. Тя също така изброява три неща, които един малък екип по сигурност трябва да изгради първо, дори при ограничен брой служители.

„Ако трябва да бъда честна, управлението и съответствието (governance and compliance) са областите, в които лично аз прекарвам най-малко време в ежедневната си практическа работа, и не мисля, че това е погрешно разпределение на ресурсите предвид състоянието на съвременната среда на заплахи в момента.“

„Съответствието все още е фундаментална част от нашата програма за сигурност и винаги ще бъде, особено след като Tricentis е компания, работеща с клиенти, а нашите клиенти имат свои собствени задължения за съответствие. Това, което се промени, е начинът, по който го управляваме: приложихме автоматизация за събиране на доказателства и одити и изградихме силни елементи за самообслужване в програмата, което намалява ежедневните административни разходи, без да намалява нейното значение.“

„Точно това ми позволява да отделям повече време на корпоративната сигурност и сигурността на продуктите, където моят екип внедрява и управлява техническите контроли, които предпазват Tricentis и нашите клиенти. Тъй като атакуващите използват ИИ, за да експлоатират уязвимости по-бързо и да прилагат нови техники за атака, именно там се насочва времето с най-голяма ефективност в момента.“

„Вътрешно имам същите изисквания, каквито препоръчвам и на нашите клиенти – да не се използват производствени данни в по-ниски среди. От професионална гледна точка съм виждала множество компании да използват производствени данни в среди за осигуряване на качеството (QA) или непроизводствени среди. Например, в миналото е било трудно да се извършва тестване на натоварването за процеси като проверка на изображения на чекове и валидиране на социални осигурителни номера (SSN), тъй като те трябва да бъдат много точни и имат уникални характеристики, поради което компаниите по подразбиране са използвали производствени данни. Дори в сектори с висок залог като финансовите услуги и здравеопазването, фирмите понякога използват реални данни.“

„Контролите в една QA среда понякога не са толкова строги, колкото са в производствената среда, а вие искате да сте сигурни, че поддържате тази сегментация. Поради това винаги препоръчвам производствените данни да се държат далеч от средите за QA и тестване, доколкото е възможно, и да се търсят алтернативни начини за тестване. Технологията измина дълъг път и почти винаги има друг начин за справяне с тези предизвикателства.“

„Със сигурност имаше ИИ продукти и функции, при които трябваше да забавя или да наложа промяна в посоката на развитие по време на кариерата си. Това беше особено вярно в ранните дни на ИИ, когато компаниите се надпреварваха да го внедряват, използвайки агентски възможности. Не мога да назова конкретния продукт, но мога да опиша модела: докато компаниите бързаха да направят чатботовете да звучат по-човешки и ангажиращо чрез агентски функции, моят екип сигнализира за риска от подмяна на инструкциите (prompt injection) – например атакуващ, който създава входящи данни, предназначени да извлекат поверителна информация, която системата никога не е трябвало да разкрива.“

„Тествахме го чрез симулация на атаки (red-teaming) преди пускането на пазара, открихме точно този пропуск и задържахме релиза, докато уязвимостта не беше отстранена на бекенда. Това добави една седмица към графика, но алтернативата беше изтичане на данни. Поради това отлагането на пускането на продукти, докато приключи цялото тестване за сигурност и се коригират всички грешки преди внедряването, е необходимо днес точно толкова, колкото и в ранните фази на агентския ИИ. Моята позиция като цяло е да помагам на инженерния отдел и продуктовото развитие да се движат бързо, но без да се жертва сигурността.“

„Ние оценяваме доставчиците на модели и ИИ решения първо през призмата на сигурността, за да определим дали се чувстваме комфортно да ги използваме вътрешно или в нашите продукти. Някои от ключовите неща, които оценяваме, са: Как се използват и съхраняват нашите данни, какви контроли за сигурност се прилагат, как изглежда задържането на данни и колко устойчив е доставчикът.“

„Също така разглеждаме архитектурата и начина, по който тя ще бъде внедрена в нашата екосистема, включително как искаме нашите потребители да взаимодействат с технологията. Повечето компании внедряват ИИ под някаква форма и всички те също трябва да бъдат оценени спрямо нашите стандарти, преди да можем да разрешим използването им от нашите екипи. Най-добрите доставчици на ИИ позволяват на предприятията да конфигурират използването на големите езикови модели (LLM) и да ограничават агентите от гледна точка на компанията. Например, при разрешаване на използването на асистент за кодиране, бихме искали да го внедрим на нашия собствен стек и да използваме корпоративни контроли, за да гарантираме, че подканите преминават през нашите проверки за сигурност, преди да бъдат изпълнени от доставчика на ИИ.“

„Не мога да назова конкретен доставчик, когото сме отхвърлили, но мога да споделя какво дисквалифицира даден кандидат. Най-честият предупредителен знак е доставчик, който не може да отговори къде живеят нашите данни, колко дълго се съхраняват и дали се използват за обучение на техните модели. Ако не можем да получим директен отговор относно местоположението и съхранението на данните, това е категоричен отказ, независимо колко добър е продуктът. Вторият фактор е архитектурата: независимо дали се обръщаме директно към доставчик на услуги или той препродава услугите на някой друг...“