A09:2025 Сбои журналирования и оповещения

Общие сведения.

Сбои журналирования и оповещения сохраняют 9-е место. Название категории немного изменено для акцента на функции оповещения, необходимой для инициирования действий на значимые события в журналах. Категория всегда будет недостаточно представлена в данных и третий раз подряд включена в список по результатам опроса сообщества. Тестирование в данной категории крайне сложно, а её представленность в CVE/CVSS-данных минимальна (только 723 CVE); тем не менее она может иметь существенное значение для видимости, оповещения об инцидентах и криминалистики. Категория включает проблемы с правильным экранированием при выводе в лог-файлы (CWE-117), вставкой конфиденциальной информации в лог-файлы (CWE-532) и недостаточным журналированием (CWE-778).

Таблица оценок.

Число CWE	Макс. частота встречаемости	Ср. частота встречаемости	Макс. охват	Ср. охват	Ср. взвешенная эксплуатируемость	Ср. взвешенное воздействие	Общее число встречаемостей	Общее число CVE
5	11,33%	3,91%	85,96%	46,48%	7,19	2,65	260 288	723

Описание.

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

Аудитируемые события, такие как входы в систему, неудачные входы и транзакции высокой ценности, не журналируются или журналируются непоследовательно (например, только успешные входы, но не неудачные попытки).
Предупреждения и ошибки не генерируют сообщений в журналах, либо они неадекватны или неясны.
Целостность журналов должным образом не защищена от подделки.
Журналы приложений и API не мониторируются на предмет подозрительной активности.
Журналы хранятся только локально и не имеют должного резервного копирования.
Пороговые значения оповещений и процессы эскалации реагирования отсутствуют, неэффективны или не получают своевременного рассмотрения.
Тестирование на проникновение и сканирование инструментами DAST (например, Burp или ZAP) не инициируют оповещений.
Приложение не может обнаруживать, эскалировать или оповещать об активных атаках в реальном времени или близком к нему.
Уязвимость к утечке конфиденциальной информации через раскрытие событий журналирования и оповещения пользователю или злоумышленнику (см. A01:2025-Нарушение контроля доступа), или путём журналирования конфиденциальной информации, которая не должна фиксироваться (например, PII или PHI).
Уязвимость к инъекциям или атакам на системы журналирования или мониторинга при некорректном кодировании данных журналов.
Приложение не распознаёт ошибки и другие исключительные ситуации или обрабатывает их неправильно, что делает систему неосведомлённой о возникшей ошибке и неспособной зафиксировать проблему.
Отсутствуют или устарели достаточные «варианты использования» для выпуска оповещений при распознавании особых ситуаций.
Слишком большое количество ложноположительных оповещений делает невозможным отличие важных от неважных, что приводит к их несвоевременному или полному игнорированию (физическая перегрузка команды SOC).
Обнаруженные оповещения не могут быть корректно обработаны, поскольку сценарий реагирования (playbook) для данного случая неполный, устаревший или отсутствует.

Как предотвратить.

Разработчики должны реализовывать некоторые или все следующие меры контроля в зависимости от риска приложения:

Убедитесь, что все сбои входа в систему, контроля доступа и серверной валидации входных данных могут быть занесены в журнал с достаточным контекстом пользователя для идентификации подозрительных или вредоносных учётных записей и храниться достаточно долго для отсроченного криминалистического анализа.
Убедитесь, что каждая часть вашего приложения, содержащая средство контроля безопасности, журналируется — независимо от того, успешна ли операция или нет.
Убедитесь, что журналы генерируются в формате, легко потребляемом решениями по управлению журналами.
Убедитесь, что данные журналов корректно закодированы для предотвращения инъекций или атак на системы журналирования или мониторинга.
Убедитесь, что все транзакции имеют аудиторский след со средствами контроля целостности для предотвращения подделки или удаления, например таблицы базы данных с режимом только добавления или аналогичные.
Убедитесь, что все транзакции, завершившиеся ошибкой, откатываются и запускаются заново. Всегда выполняйте безопасное закрытие (fail closed).
Если ваше приложение или его пользователи ведут себя подозрительно — выпускайте оповещение. Создайте руководство для ваших разработчиков по этой теме, чтобы они могли учитывать это в коде, или приобретите систему для этого.
Команды DevSecOps и безопасности должны создать эффективные варианты использования мониторинга и оповещения, включая playbook, чтобы подозрительные действия быстро обнаруживались и обрабатывались командой SOC.
Добавьте «honeytokens» как ловушки для злоумышленников в ваше приложение, например в базу данных, данные, в виде реальных и/или технических идентификаторов пользователей. Поскольку в обычной работе они не используются, любой доступ генерирует данные журнала, которые можно оповещать практически без ложноположительных срабатываний.
Поведенческий анализ и поддержка ИИ могут быть дополнительным методом для снижения частоты ложноположительных оповещений.
Создайте или примите план реагирования на инциденты и восстановления, например NIST 800-61r2 или более поздний. Обучите разработчиков программного обеспечения тому, как выглядят атаки на приложения и инциденты, чтобы они могли их сообщать.

Существуют коммерческие и открытые продукты защиты приложений, такие как набор правил OWASP ModSecurity Core Rule Set, и программное обеспечение с открытым исходным кодом для корреляции журналов, такое как стек Elasticsearch, Logstash, Kibana (ELK), которые предоставляют пользовательские панели мониторинга и оповещения. Существуют также коммерческие инструменты наблюдаемости, которые могут помочь вам реагировать на атаки или блокировать их практически в реальном времени.

Примеры сценариев атак.

Сценарий №1: Оператор сайта детского плана медицинского страхования не смог обнаружить нарушение из-за отсутствия мониторинга и журналирования. Внешняя сторона сообщила провайдеру плана, что злоумышленник получил доступ и изменил тысячи конфиденциальных медицинских записей более 3,5 млн детей. Анализ после инцидента показал, что разработчики не устранили существенные уязвимости. При отсутствии журналирования или мониторинга системы утечка данных могла продолжаться с 2013 года — более семи лет.

Сценарий №2: Крупная индийская авиакомпания пережила утечку данных, затронувшую более чем десятилетний объём персональных данных миллионов пассажиров, включая данные паспортов и кредитных карт. Утечка произошла у стороннего облачного провайдера, который уведомил авиакомпанию по истечении некоторого времени.

Сценарий №3: Крупная европейская авиакомпания понесла ответственность за нарушение в рамках GDPR. Нарушение было предположительно вызвано уязвимостями безопасности платёжного приложения, которые злоумышленники использовали для сбора более 400 000 платёжных записей клиентов. В результате регулятор оштрафовал авиакомпанию на 20 миллионов фунтов стерлингов.