Спрос на услуги по безопасности генеративного ИИ активно растет

Спрос на услуги по безопасности генеративного ИИ активно растет

Спрос на услуги по безопасности генеративного ИИ активно растет

По данным Swordfish Security, за услугами по безопасности больших языковых моделей (LLM Security) в 2024 году обращались 35% заказчиков. Спрос на такие услуги растет прямо пропорционально внедрению подобных инструментов в бизнес-практику.

В 2025 году такая практика будет только расширяться, поскольку генеративный интеллект, прежде всего, большие языковые модели, будут внедряться все более активно. В будущем году уровень проникновения генеративного ИИ составит не менее 40%, а к 2030 году может достигнуть и 90%.

Как отметил директор по развитию бизнеса ГК Swordfish Security Андрей Иванов, рост интереса к безопасности больших языковых моделей стал одной из главных тенденций 2024 года. Недооценка таких рисков чревата серьезными проблемами. Среди таких рисков Андрей Иванов инъекции вредоносного кода в промпт, уязвимости в цепочках поставок, выдача ошибочной информации за истину на этапе обучения модели и даже кража модели злоумышленниками.

«В бизнесе используют большие модели для распознавания текста, анализа данных, предиктивной аналитики, поиска, оценки ресурса механических узлов промышленных агрегатов и многого другого. Многие отрасли, та же ИТ, активно используют ИИ-помощников. Например, в DevSecOps мы обучили и применяем модель, которая может анализировать и приоритизировать большой объем уязвимостей кода, таким образом освобождая время для квалифицированных инженеров для других, более сложных и творческих задач, — комментирует Андрей Иванов. — Критичным может оказаться, например, некорректная работа виртуальных ассистентов, которые могут влиять на клиентские решения, аналитику, дающую ошибочную информацию в цепочке поставок. Существуют атаки, отравляющие данные или позволяющие получить конфиденциальную информацию, и так далее. К этому стоит относиться как к любой информационной системе, влияющей на бизнес-процесс и проводящей, в случае компрометации, к потерям репутации и убыткам».

Внедрение ИИ требует корректировки корпоративных политик ИБ. Важно делать акцент на безопасности, а разрабатывать модели необходимо в соответствие с практиками разработки безопасного ПО, анализируя исходный код и зависимости, ответственно относиться к контролю доступа к источникам данных и стараться использовать доверенные алгоритмы обучения, уверен Андрей Иванов. Также важно учитывать то, что многие большие языковые модели используют облачную архитектуру, а это создает угрозу утечки конфиденциальных данных.

Новая атака на кеш Nginx позволяет красть данные и ломать сайты

Исследователь YesWeHack Алекс Брумен описал вектор кибератаки Cache Key Injection. В случае её эксплуатации последствия для потенциальной жертвы опасные: обход контроля доступа, раскрытие закрытых страниц, отказ в обслуживании и при определённых условиях.

Как объясняет исследователь YesWeHack, проблема возникает не в Nginx по умолчанию, а в конфигурациях, где администраторы просто склеивают несколько значений переменной длины без разделителей. Например:

$scheme$host$request_uri$http_accept

Разных запроса два, а итоговая строка может получиться одна. Так, запрос к /h с заголовком Accept: ome*/* создаёт тот же ключ, что и обычное обращение к /home с Accept: */*.

Если атакующий успеет первым положить в кеш ответ 404, пользователи вместо главной страницы будут получать ошибку до очистки записи. Получается CPDoS — отказ в обслуживании с доставкой прямо из кеша.

 

Ещё веселее становится с закрытыми разделами. В лабораторном примере страница /admin была доступна только с localhost, но злоумышленник мог обратиться к /ad и перенести оставшуюся часть имени в соседний компонент ключа. Nginx видел разрешённый путь, однако доставал из кеша содержимое админ-панели.

При совпадении нескольких условий техника позволяет столкнуть HTTP- и HTTPS-запросы и записать в кеш страницу со ссылкой на атакующий JavaScript, превратив ошибку конфигурации в stored XSS. Даже Cloudflare не всегда спасёт: заголовок Authorization может провести запрос мимо его кеша прямо к уязвимому кешу Nginx.

 

Защита выглядит до смешного просто: не склеивать значения вслепую. Между элементами ключа нужны разделители или структурное кодирование, например:

$scheme|$host|$request_uri|$http_accept

Также следует проверять Host, перенаправлять HTTP на HTTPS и не кешировать аутентифицированные запросы.

RSS: Новости на портале Anti-Malware.ru