Фатальная ошибка: как избежать уязвимостей в ПО для ИБ

Компании полагаются на средства защиты: антивирусы, файерволы, системы мониторинга — это помогает строить неприступные барьеры для хакеров и злоумышленников. Но что, если ПО для защиты содержит в себе уязвимости?

Александр Дельва, руководитель отдела информационной безопасности Контура, рассказал Cyber Media, что могут сделать разработчики и конечные пользователи, чтобы не пользоваться уязвимым ПО.

Уязвимое ПО для защиты: это реально

За последние 10 лет можно привести как минимум пять громких примеров, когда в популярных ИБ-решениях в сфере ИБ были обнаружены уязвимости:

• в 2013 году Эдвард Сноуден обвинил компанию Cisco в том, что они внедряли в маршрутизаторы, серверное и иное сетевое компьютерное оборудование специальные маячки для слежки за клиентами;
• в 2015 году обнаружилось, что с помощью сервиса для защиты сайтов Cloudflare можно узнавать IP пользователей;
• в 2020 году в Solarwind обнаружили вредоносные компоненты, которые заразили инфраструктуру их клиентов;
• в 2021 году в библиотеке журналирования log4j была обнаружена уязвимость, позволяющая выполнить произвольный код. Библиотека применялась в различных SIEM, что сделало их уязвимыми;
• в 2024 году из-за проблемного обновления продукта CrowdStrike миллионы Windows-систем показали «синий экран смерти», что вызвало массовые сбои в работе аэропортов, банков, медицинских учреждений и множества других организаций.

Все эти события произошли из-за того, что средства защиты по сути это обычное программное обеспечение и может содержать в себе любые ошибки. Это ПО создают обычные разработчики, которые могут написать небезопасный код. Пользователи этого ПО могут эксплуатировать его небезопасным способом, что тоже приводят к уязвимостям.

Как разработчики могут снизить число уязвимостей в ПО

Ответ прост — программировать эффективно и безопасно. Разберемся подробнее, что это значит.

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

Кроме багбаунти можно использовать национальный ГОСТ по безопасной разработке в обновленной версии 2024 года. Его использует ФСТЭК для контроля лицензиатов, разрабатывающих средства защиты информации. Даже если вы не являетесь лицензиатом ФСТЭК, то документ поможет проверить ваше приложение на уязвимости.

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

Как пользователю проверить продукт на безопасность

• Проверить продукт по базе данных угроз. В любой базе вы увидите различные сообщения об инцидентах, связанных с тем или иным ПО. Но не нужно думать, что программы, которые не попадают в базы, более безопасны. Возможно, что ими пользуется так мало людей, что их уязвимости еще не изучены. И, наоборот, компании, у которых были несколько лет назад обнаружены уязвимости, уже успели их закрыть. Чем крупнее вендор, тем больше у него ресурсов на то, чтобы внедрять изменения и вносить исправления в архитектуру и код.
• Не использовать непопулярные продукты. Логичный вывод из предыдущего пункта — если вы используете непопулярные продукты, вы рискуете стать первым пользователем, который обнаружил критическую уязвимость в ПО.
• Грамотно внедрить продукт в свою инфраструктуру. Главное — при внедрении сократить поверхность атаки. Нужно следить, чтобы средство защиты было относительно изолированным от другой инфраструктуры. Иначе злоумышленник взломав это ПО, может проникнуть в любую точку инфраструктуры компании.

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

• Следить за тем, как работает продукт. Обычно все атаки происходят не за секунду, а в определенном временном промежутке. Чем внимательнее вы мониторите, как используется продукт, тем точнее сможете отследить возникшие уязвимости и отреагировать на них. Вы сможете это сделать, когда уязвимость только появилась, проверяя базы уязвимостей и наблюдая за инфраструктурой, а можете уже на этапе, когда нарушитель начал ее эксплуатировать и наследил в логах.

Самый главный способ, который поможет сделать приложение безопасным — быть бдительным на всех этапах разработки и эксплуатации приложения. При этом важно проверять приложение и искать уязвимости не разово, а регулярно, помня о том, что угрозы могут также становиться все современнее и опаснее.