Изкуственият интелект (ИИ) променя офанзивната сигурност, но не е променил стандарта, който е най-важен: констатацията трябва да бъде доказана, преди да стане полезна. Инструментите, подпомагани от ИИ, могат бързо да четат код, да генерират зловреден код, да обобщават повърхността на атака, да обясняват непознати API и да изпълняват повтарящи се работни процеси за тестване с впечатляваща скорост. Това е реално предимство за екипите по сигурността. То също така създава нов вид натиск, тъй като индустрията сега може да произвежда повече резултати, изглеждащи като уязвимости, от всякога.
Проблемът е, че генерираните резултати не са същото като доказателствата. Един генериран доклад може да звучи изпипан, да включва оценка на сериозността и дори да съдържа концептуална доказателствена разработка (proof-of-concept), която изглежда разумна на пръв поглед. Нищо от това не доказва, че грешката съществува в реално внедрената среда. Нищо от това не доказва възможност за експлоатация, въздействие или риск. В офанзивното тестване трудната част никога не е била да се напише нещо, което звучи като доклад за уязвимост. Трудната част е да се демонстрира какво действително е вярно.
Тази разлика става все по-важна с навлизането на ИИ в работните процеси за сигурност. ИИ може да ускори откриването, но валидирането все още зависи от познанията: познания за системи, протоколи, поведение на приложенията, граници на идентичността, компрометиране на паметта, бизнес логика и всички детайли по внедряването, които разделят една правдоподобна теория от реален експлойт. Бъдещето на офанзивната сигурност няма да принадлежи на хората, които просто генерират най-голям брой констатации. То ще принадлежи на хората и екипите, които могат да докажат това, което има значение.
Индустрията вече вижда цената на повърхностните резултати от ИИ
Предупредителните знаци вече са видими. Програмите за награждаване за открити грешки (bug bounty) и поддържащите софтуера лица вече се справят с вълна от нискокачествени, генерирани от ИИ доклади, често изпращани с оскъдни доказателства, шаблонен език и малко смислено валидиране. Bugcrowd публично обърна внимание на тази тенденция в промените на политиките си относно изпращането на материали, генерирани от ИИ, описвайки клас доклади, които изглеждат изпипани, но създават излишен товар при триажа, вместо да дават полезен сигнал за сигурността.
Това не е проблем само за bug bounty програмите. Това е предварителен преглед на случващото се навсякъде, където ИИ се използва за създаване на констатации за сигурност без достатъчно човешка преценка зад тях. Ако един инструмент може да генерира убедително описание за секунди, организациите ще получават повече доклади, повече предупреждения и повече твърдения. Освен ако тези твърдения не бъдат валидирани, резултатът не е по-добра сигурност. Резултатът е просто по-голяма опашка от чакащи задачи.
Екипите по сигурността вече са претоварени с резултати от скенери, предупреждения за зависимостти, проблеми с облачни конфигурации и констатации за съответствие. Добавянето на генерирани от ИИ спекулации върху това не помага, освен ако в същото време не се повиши летвата за качество. Една констатация трябва да отговаря ясно на основни въпроси: какво се е случило, как е възпроизведено, какво контролира атакуващият, коя граница е премината и какво е демонстрираното въздействие. Без това докладът може да е интересен, но не е готов да задвижи действия от страна на инженерния екип.
„Изглежда уязвимо“ не е същото като „уязвимо е“
Един от най-опасните навици в офанзивното тестване е объркването на подозрителен шаблон с валидирана уязвимост. ИИ може да влоши този навик, защото е добър в обясняването защо нещо може да бъде лошо. Един модел може да види потребителски вход в близост до заявка към база данни и да опише SQL инжекция. Може да види извличане на URL адрес и да предложи SSRF. Може да види опасен API в път на кода и да опише отдалечено изпълнение на код. Понякога моделът посочва реален проблем. В други случаи той пропуска условията, които определят дали проблемът изобщо има значение.
Тестващият все още трябва да докаже достижимостта. Дали контролираният от атакуващия вход действително достига до опасната операция? Изисква ли се автентификация? Прилага ли се оторизация на друго място? Активирана ли е уязвимата функция? Излага ли производствената конфигурация кодовия път на риск? Дали приложението нормализира, кодира, санира или отхвърля зловредния код, преди той да повлияе? Дали проблемът пресича граница на доверие или просто засяга вътрешен път без практическо въздействие върху сигурността?
Тези въпроси са мястото, откъдето започва истинската офанзивна сигурност. Те са и мястото, където повърхностната автоматизация често се проваля. ИИ може бързо да генерира хипотези, но хипотезите не са констатации. Добрият тестващ се отнася към резултатите от ИИ като към следа за разследване, а не като към заключение, което да препрати нататък.
Най-добрите експерти по офанзивна сигурност са ценни, защото разбират системите, а не защото могат да стартират инструменти. Инструментите винаги са били част от работата, но резултатите от тях никога не са били достатъчни. Уеб скенерът може да идентифицира параметър, който отразява въведения вход. Статичният анализатор може да маркира опасна функция. Фъзърът може да предизвика срив. Езиковият модел може да опише правдоподобен път на атака. Във всеки случай все още е необходим човек, който да разбере какво означава този сигнал.
Това разбиране обикновено се придобива чрез повторение. Старшите изследователи са прекарали години в ръчна работа: проследяване на заявки, четене на изходен код, обратно инженерство на двоични файлове, отстраняване на грешки при сривове, писане на код за експлойти, коригиране на грешки в автентификацията...