Технические, организационные и культурные факторы мешают предприятиям устранять уязвимости, выявленные в ходе тестов на проникновение, — проблему, которую появление генеративного ИИ скорее усугубляет, чем устраняет.
Согласно исследованию, проведенному сервисной компанией Cobalt, занимающейся тестированием на проникновение, организации устраняют менее половины всех уязвимостей, которые можно использовать (48%), и этот показатель снижается до 21% для выявленных ошибок в приложениях gen AI.
Уязвимости, выявленные в ходе аудита безопасности и получившие высокую или критическую степень серьезности, с большей вероятностью будут устранены, а показатель устранения составляет 69%.
С 2017 года среднее время на устранение серьезных уязвимостей значительно сократилось — со 112 дней до 37 дней в прошлом году. По словам Cobalt, это демонстрирует положительное влияние программ обеспечения безопасности “сдвиг влево” (Shift-Left Security).
Shift-Left Security — это подход, при котором проверки безопасности внедряются так рано и так часто, как это возможно. Такой подход позволяет предупредить появление уязвимостей и других проблем с безопасностью приложения ещё на этапе проектирования, когда продукт только начинает создаваться или меняться по функциональным требованиям.
Оглавление
Проблемы с устранением уязвимостей
Иногда организации принимают осознанное бизнес-решение пойти на определенные риски, вместо того чтобы нарушать работу или нести значительные расходы, связанные с устранением некоторых уязвимостей.
Плохое планирование устранения уязвимостей и ограниченность ресурсов также являются факторами, замедляющими процесс исправления. В некоторых случаях уязвимости обнаруживаются в устаревшем программном или аппаратном обеспечении, которое нелегко обновить или заменить.
“Некоторые организации делают только то, что от них требуется для обеспечения соответствия требованиям или получения одобрения третьей стороны – проходят пентест”, — пишут исследователи Cobalt. “Снижение реальных рисков имеет меньшее значение. Однако по большей части это сводится к множеству организационных вопросов, касающихся людей, процессов и технологий”.
Проблема собственных уязвимостей ИИ
В последнем ежегодном выпуске отчета Cobalt о состоянии пентестинга было обнаружено, что большинство компаний провели ручное тестирование веб-приложений для больших языковых моделей (LLM), при этом треть (32%) тестов выявили уязвимости, которые заслуживают серьезного рейтинга.
Был выявлен целый ряд недостатков LLM, включая оперативное внедрение (prompt injection), манипулирование моделью и утечку данных, но только 21% из них удалось устранить. Разработка ИИ “стремительно продвигается вперед без какой-либо защиты”, предупреждает Cobalt.
Цифры основаны на анализе данных, собранных в ходе более чем 5000 тестов, проведенных компанией Cobalt. В ходе опроса, проведенного среди клиентов, более половины руководителей служб безопасности (52%) заявили, что им приходится отдавать предпочтение скорости, а не безопасности.
Уязвимости “отмечены, но не устранены”
Независимые эксперты по безопасности сообщили CSO, что выводы Cobalt совпадают с тем, что они наблюдают в области устранения ошибок.
“Большинство организаций по-прежнему слишком медленно устраняют известные уязвимости, и это редко объясняется недостаточной осведомленностью”, – сказал CSO Джеймс Лей, опытный инженер, ставший главным операционным директором юридической фирмы Sparrow. “Уязвимости отмечаются, но не устраняются”.
Устранение уязвимостей откладывается из-за того, что предприятия сталкиваются с конкурирующими более приоритетными задачами.
“Службы безопасности перегружены работой, инженерные группы сосредоточены на добавлении новых функций в продукты, и если нет давления со стороны регулирующих органов или зарегистрированного инцидента, устранению ”известной проблемы” просто не уделяется должного внимания”, – сказал Лей.
Устранение уязвимостей в эпоху искусственного интеллекта
ИИ-приложения нового поколения создают ряд проблем, которые усложняют устранение уязвимостей.
“Многие из них создаются быстро, с использованием новых платформ и сторонних инструментов, которые не были полностью протестированы в производственных средах”, – сказал Лей. “Вы сталкиваетесь с незнакомыми объектами атаки, моделями, которые ведут себя непредсказуемо, и зависимостями, которые команды не могут полностью контролировать”.
Лей добавил: “Таким образом, даже при обнаружении уязвимостей их устранение может быть сложным и отнимать много времени – даже при условии, что у вас в штате есть специалисты с соответствующим опытом”.
Приложение с генеративным ИИ состоит из двух компонентов: приложения и самого генеративного ИИ, как правило, LLM, такого как ChatGPT.
“Уязвимости в традиционных приложениях так же легко устранить, как и обычные уязвимости, разницы между ними нет”, – сказал Инти Де Кекелер, главный специалист по хакерским атакам в платформе bug bounty Intigriti.
Например, ИИ-приложение может содержать функцию для поиска определенных документов. Если в этой функции есть уязвимость, разработчики могут просто изменить код.
Напротив, уязвимость в самом LLM (нейронной сети или “мозге” ИИ) “гораздо сложнее устранить, поскольку не всегда легко понять, почему запускается определенное поведение”, – сказал Де Кекелер.
“Можно сделать предположение и обучить или скорректировать модель, чтобы избежать такого поведения, но нельзя быть на 100% уверенным в том, что проблема решена”, – сказал он. “В этом смысле сравнивать это с традиционным ”исправлением ошибок”можно весьма условно”.
Баг триажинг
Баг триажинг (bug triage) — это систематический процесс в разработке программного обеспечения для оценки, приоритизации и назначения обнаруженных дефектов или проблем. Он включает анализ новых отчётов о багах, чтобы определить их достоверность, серьёзность, приоритет и подходящий путь решения.
Если CISO хотят повысить скорость устранения уязвимостей, им нужно упростить для команд приоритезацию исправлений для системы безопасности. Это может означать более раннюю интеграцию инструментов обеспечения безопасности в процесс разработки ПО или установление показателей производительности во время устранения серьезных проблем.
“Это также требует назначения владельца данного процесса, который отвечает за то, чтобы уязвимости действительно устранялись, а не просто регистрировались”, – сказал Лей из Sparrow.
Другие эксперты утверждали, что специалисты по безопасности должны сосредоточить свои ограниченные ресурсы на наиболее опасных классах уязвимостей, непосредственно эксплуатируемых в Интернете.
По словам Тода Бердсли, вице-президента по исследованиям в области безопасности компании-поставщика средств управления рисками runZero, приоритетными также должны быть случайные воздействия и сокращение технического долга.
Технический долг (Technical Debt) — это метафора программной инженерии, которая обозначает накопленные в программном коде или архитектуре проблемы, связанные с пренебрежением качеством при разработке программного обеспечения. Это своего рода «заём», который разработчики берут у будущего, ускоряя текущую работу, но откладывая устранение проблем на потом. « Проценты» по такому «кредиту» — это трудозатраты, которые понадобятся для того, чтобы закрыть долг.
“Хороший тест на проникновение должен помочь CISO определить те области, где преступники, скорее всего, будут процветать, а не просто перечислять набор критических уязвимостей вне контекста”, – сказал Бердсли CSO.
Специалисты по безопасности могут быть просто ошеломлены количеством уязвимостей, которые необходимо устранять, если исходить из результатов пентестов и отчетов сканеров уязвимостей.
“Это информационная перегрузка, и командам сложно справиться со всем этим и расставить приоритеты для устранения неполадок в зависимости от степени риска”, – сказал Томас Ричардс, директор по практике обеспечения безопасности инфраструктуры в компании по тестированию безопасности приложений Black Duck.
Как и Бердсли из runZero, Ричардс утверждал, что результаты пентестов необходимо рассматривать в правильном контексте.
“Когда после тестирования на проникновение будет получен отчет, службы безопасности рассмотрят его, чтобы определить его точность и дальнейшие действия”, – сказал Ричардс. “Этот шаг требует времени, но позволяет организациям в первую очередь определить приоритетность устранения наиболее серьезных уязвимостей”.
К результатам работы сканеров уязвимостей следует относиться с еще большей осторожностью.
“С помощью наших автоматизированных инструментов мы часто обнаруживаем, что значение серьезности по умолчанию, полученное на выходе, не всегда является точным, учитывая другие факторы, такие как доступность эксплойта, доступность сети и другие факторы, которые снижают риск эксплуатации уязвимости”, – пояснил Ричардс.
Автор: John Leyden