Red Teaming в применении к ИИ требует переосмысления

Red Teaming в применении к ИИ требует переосмысления

Red Teaming в применении к ИИ требует переосмысления

Учения Generative Red Team, проведенные в рамках DEF CON 32, показали, что подобный способ оценки защищенности ИИ не дает адекватной картины. Эксперты предлагают создать систему, подобную CVE и учитывающую целевое назначение объектов анализа.

В мероприятии приняли участие (PDF) около 500 добровольцев с разным опытом аудита больших языковых моделей (БЯМ, LLM). В 48 случаях за выявленные недочеты были выплачены премии — суммарно $7850.

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

Без учета назначения ИИ-модели и сообразных встроенных ограничений результаты таких проверок на прочность могут ввести в заблуждение. Более того, отсутствие единых критериев оценки может привести к противоречивым заключениям.

Бурный рост и развитие ИИ-технологий создали новые риски, однако ни у кого пока нет четкого представления о том, как тестировать такие продукты и выстраивать их защиту.

Обеспечение безопасности LLM, по словам экспертов, — нескончаемый процесс. Умные помощники могут ошибаться, им свойственны галлюцинации, предвзятость (из-за неправильного обучения), уязвимость к инъекции стимула. Подобные системы бесперспективно защищать от взлома, однако его можно сделать более затратным, а последствия — краткосрочными.

Организаторы Generative Red Team призывают ИИ- и ИБ-сообщества совместными усилиями решить настоятельные проблемы. В противном случае техническая революция приведет к появлению ИИ-инструментов, на которые невозможно положиться; живой пример тому — скороспелка DeepSeek.

Мошенники начали рассылать «работу мечты» через Google AppSheet

«Лаборатория Касперского» предупредила о новой фишинговой схеме: мошенники используют Google AppSheet, чтобы рассылать письма с заманчивыми предложениями о работе. Письмо приходит с настоящего сервисного адреса noreply@appsheet.com, отправитель выглядит как рекрутинговая команда крупной компании, а внутри — предложение обсудить карьерные возможности.

Схема в целом интересная: злоумышленники регистрируются в Google AppSheet, оформляют рассылку и маскируют её под сообщение от рекрутеров технологических компаний, FMCG-брендов или автопроизводителей.

Получателю предлагают перейти по ссылке, чтобы выбрать время встречи и оставить контактные данные.

Дальше начинается классика фишинга: пользователя уводят на мошенническую страницу, где просят ввести логин и пароль, например от Google-аккаунта. В итоге работа мечты превращается в мечту злоумышленников о чужих учётных данных.

Есть и другой сценарий: ссылки в письме может вообще не быть. Вместо этого адресата просят ответить команде рекрутеров. Скорее всего, дальше жертву начинают обрабатывать уже в переписке.

Почему такие письма проходят в почту? Потому что они идут через инфраструктуру Google. А значит, часто успешно проходят проверки SPF, DKIM и DMARC. Для пользователя это выглядит солидно, для фильтров — менее подозрительно.

Плюс AppSheet позволяет отправлять не только письма, но и СМС. Чтобы запустить такую кампанию, достаточно платной подписки даже на базовом тарифе. То есть порог входа низкий, а доверия к домену Google — много.

В «Лаборатории Касперского» отмечают, что злоумышленники всё чаще используют легитимные облачные сервисы в атаках. Раньше похожие схемы фиксировали с Google Формы, Google Задачи, Google Таблицы и даже OpenAI. Теперь в список добавился AppSheet.

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