В контексте растущей роли искусственного интеллекта (ИИ) в различных областях, вопрос о его влиянии на рынок труда в сфере кибербезопасности становится все более актуальным. С одной стороны, автоматизация и интеллектуальные системы могут значительно ускорить и улучшить процессы, связанные с защитой данных и ИТ-инфраструктуры. С другой стороны, существует опасение, что ИИ может заменить людей в некоторых функциях, что приведет к уменьшению числа доступных рабочих мест. По моим наблюдениям, будет совершенно наоборот (по крайней мере для специалистов по безопасности)!
Возможности ИИ в кибербезопасности
ИИ обладает способностью анализировать огромные объемы данных за короткое время, что является ключевым в кибербезопасности, где скорость реакции на угрозы часто имеет решающее значение. Алгоритмы машинного обучения могут обнаруживать ранее неизвестные угрозы на основе анализа моделей поведения и исторических данных. Это позволяет быстрее и точнее выявлять и реагировать на инциденты безопасности. Автоматизация процессов анализа и реагирования на угрозы может привести к сокращению рабочих мест для аналитиков безопасности низшего уровня, занимающихся рутинным мониторингом и реагированием на тревоги. С другой стороны, появляются такие специальности, как инженер машинного обучения в кибербезопасности, управление интеллектуальными системами защиты и анализ продвинутых угроз с использованием ИИ. Специалистам необходимо будет не только понимать работу современных ИИ-инструментов, но и уметь развивать их и адаптировать к специфическим потребностям в области безопасности.
Автоматизация создания кода = больше ошибок безопасности + новые классы уязвимостей
Введение ошибок автоматическими инструментами
Никогда ранее создание приложений не было таким простым, доступным для нетехнических людей и быстрым. Это приводит к появлению большого количества новых приложений. Одновременно растет популярность добавления элементов ИИ в уже существующее программное обеспечение. Однако автоматизация, особенно в виде генераторов кода или разработческих фреймворков, может привести к появлению незапланированных ошибок и уязвимостей безопасности. Эти инструменты, действующие на основе установленных шаблонов и алгоритмов, могут не учитывать специфические условия или нюансы безопасности, которые понимают и применяют опытные программисты. Например, сгенерированный автоматически код может быть недостаточно защищен от атак, таких как SQL Injection или Cross-site Scripting (XSS), если инструмент не был правильно настроен для учета этих угроз.
XSS в Zoomin Zdocs
Примером такой ошибки, где на скорую руку внедряется искусственный интеллект, является найденный мной простой «Reflected Cross-site Scripting» в приложении Zoomin Zdocs. Великолепной идеей кажется введение ИИ-ассистента для работы с документацией какого-либо приложения, где мы можем, задав вопрос, узнать, как пользоваться данным программным обеспечением. Однако нужно помнить, что ответы ИИ могут быть непредсказуемыми и приводить к ошибкам безопасности. В приложении Zoomin достаточно было спросить у ассистента, что он думает о —
<img src=1 href=1 onerror="javascript:alert(document.domain)"></img>?
чтобы он ответил, что не может найти ответ на наш вопрос, процитировав его:
I'm sorry, but I couldn't find a definitive answer to: <img src=1 href=1 onerror="javascript:alert(document.domain)"></img>?. Please provide more context or clarify your query.
Весь запрос выглядел следующим образом:
POST /api/aisearch/stream HTTP/1.1 |
Ответ сервера:
HTTP/2 200 OK |
Как видно, входные данные не были должным образом проверены и очищены, что в результате привело к выполнению внедренного кода JavaScript:
Пример псевдокода с неправильным отображением ответа:
function displayResponse(userInput):
# Ввод данных от пользователя
query = userInput
# Отображение ответа без очистки данных
# Это неправильно, так как позволяет выполнить скрипт, содержащийся в userInput
print("Ответ на ваш вопрос: " + query)
Пример псевдокода с правильным отображением ответа:
function sanitize(input):
# Удалить или закодировать специальные HTML-символы в данных, например, <, >, ", ' и другие
return input.replace("<", "<").replace(">", ">").replace("\"", """).replace("'", "'")
function displayResponse(userInput):
# Ввод данных от пользователя
query = userInput
# Очистка данных
safeQuery = sanitize(query)
# Безопасное отображение ответа
# Очистка предотвращает выполнение вредоносного кода
print("Ответ на ваш вопрос: " + safeQuery)
Уязвимость (вместе с рядом других) была сообщена и устранена производителем.
Повторение ошибок
Один из главных недостатков автоматизации заключается в воспроизведении одного и того же кода в различных местах, что может привести к массовому распространению ошибок или уязвимостей. Если ошибка находится в компоненте, генерирующем код (а ИИ может быть обучен на коде с ошибками), каждая программа или система, использующая этот код, потенциально уязвима. Это явление усложняет управление и исправление проблем безопасности.
Сложности аудита и проверки кода
Автоматически сгенерированный код часто бывает сложным или создается таким образом, который не является интуитивно понятным для «человеческих» программистов. Это может усложнять ручные проверки кода, которые важны для выявления тонких логических ошибок или уязвимостей безопасности. Отсутствие прозрачности и понимания генерируемого кода может привести к пропуску важных проблем во время тестов безопасности.
Новые классы уязвимостей
Автоматизация может вводить новые классы уязвимостей, которые были бы менее вероятны при ручном создании кода. Например, зависимости между автоматически генерируемыми модулями могут быть не полностью поняты или контролируемы разработчиками, что открывает путь для атак, связанных с зависимостями и логикой приложения. Появляются также новые классы уязвимостей, такие как, например, «prompt injection».
OWASP Top 10 для приложений с использованием больших языковых моделей
OWASP год назад начал работу по выявлению и разработке рекомендаций по защите от основных угроз, связанных с использованием LLMA — OWASP Top 10 для LLMA. Список выглядит следующим образом:
LLM01: Внедрение prompt
Манипуляция большим языковым моделем (LLM) посредством соответствующих входных данных приводит к непреднамеренным действиям LLM. Прямые внедрения перезаписывают системные prompt, тогда как косвенные манипулируют данными из внешних источников.
LLM02: Небезопасная обработка выходных данных
Уязвимость возникает, когда выходные данные LLM принимаются без контроля, что может подвергнуть риску системы backend. Злоупотребление может привести к серьезным последствиям, таким как XSS, CSRF, SSRF, эскалация привилегий или удаленное выполнение кода.
LLM03: Отравление тренировочных данных
Происходит, когда тренировочные данные LLM манипулируются, вводя уязвимости или ошибки, влияющие на безопасность, эффективность или этическое поведение. Источники включают Common Crawl, WebText, OpenWebText и книги.
LLM04: Перегрузка модели
Злоумышленники вызывают ресурсоемкие операции на LLM, что приводит к деградации услуги или высоким затратам. Уязвимость усиливается из-за ресурсоемкости LLM и непредсказуемости входных данных пользователя.
LLM05: Уязвимости цепочки поставок
Жизненный цикл приложений LLM может быть уязвим к атакам безопасности из-за уязвимых компонентов или сервисов. Использование внешних наборов данных, предварительно обученных моделей и плагинов может увеличить количество уязвимостей.
LLM06: Раскрытие конфиденциальной информации
LLM может неумышленно раскрывать конфиденциальные данные в своих ответах, что приводит к несанкционированному доступу к данным, нарушениям конфиденциальности и безопасности. Важно внедрять очистку данных и строгие правила использования для предотвращения этого.
LLM07: Небезопасный дизайн плагинов
Плагины LLM могут иметь незащищенные входные данные и недостаточный контроль доступа. Отсутствие контроля приложений упрощает эксплуатацию и может привести к таким последствиям, как удаленное выполнение кода.
LLM08: Чрезмерная автономия
Системы, основанные на LLM, могут предпринимать действия, приводящие к непреднамеренным результатам. Проблема возникает из-за чрезмерной функциональности, слишком больших привилегий или автономии, предоставленной системам на основе LLM.
LLM09: Чрезмерное доверие
Системы или люди, слишком зависящие от LLM без надзора, могут подвергаться дез информации, ошибкам коммуникации, юридическим проблемам и ошибкам безопасности из-за неправильных или неподходящих данных, сгенерированных LLM.
LLM10: Кража модели
Касается несанкционированного доступа, копирования или кражи собственных моделей LLM. Влияние включает экономические потери, утрату конкурентного преимущества и потенциальный доступ к конфиденциальной информации.
Что делать? Как жить?
OWASP вместе с списком Top 10 для LLMA выпустил ряд рекомендаций по безопасному подходу к внедрению LLM в вашей организации — LLM AI Cybersecurity & Governance Checklist. Программные рекомендации представлены ниже:
- Моделируйте угрозы для компонентов LLM и определяйте границы доверия архитектуры.
- Безопасность данных: проверьте, как данные классифицируются и защищаются в зависимости от их чувствительности, включая личные и корпоративные данные. (Как управляются права пользователей и какие механизмы защиты реализованы?)
- Контроль доступа: внедряйте контроль доступа на основе принципа минимальных привилегий и применяйте меры многослойной защиты.
- Безопасность процесса обучения: требуйте строгого контроля управления данными для обучения, процессами, моделями и алгоритмами.
- Безопасность ввода и вывода: оценивайте методы проверки входных данных, а также способы фильтрации, очистки и утверждения выходных данных.
- Мониторинг и реакция: отслеживайте рабочий процесс, мониторьте и реагируйте, чтобы понять автоматизацию, обеспечьте ведение журналов и аудит. Подтвердите безопасность записей аудита.
- Включите тестирование приложений, обзор исходного кода, процесс оценки уязвимостей и тесты на проникновение в процесс разработки продукта.
- Проверьте существующие уязвимости в модели LLM или цепочке поставок.
- Рассмотрите влияние угроз и атак на решения LLM, такие как внедрение prompt, раскрытие конфиденциальной информации и манипулирование моделью.
- Изучите влияние атак и угроз на модели LLM, включая отравление модели, неправильную обработку данных, атаки на цепочку поставок и кражу модели.
- Безопасность цепочки поставок: требуйте аудитов сторонних поставщиков, тестов на проникновение и обзоров кода (как на начальном этапе, так и в регулярном процессе).
- Безопасность инфраструктуры: узнайте, как часто поставщик проводит тесты на устойчивость. Какие их SLA по доступности, масштабируемости и производительности?
- Обновляйте руководства по реагированию на инциденты и включайте инциденты, связанные с LLM, в постоянный сценарий упражнений по безопасности.
- Идентифицируйте или расширьте метрики для сравнения генеративного ИИ в кибербезопасности с другими подходами для измерения ожидаемого улучшения производительности.
