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

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

Признаки и причины появления уязвимости

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

• • обнаружение или информирование об активных атаках в режиме онлайн (или максимально приближенном к режиму реального времени) в приложении не предусмотрено или по каким-то причинам не осуществляется;
  • при проведении динамического анализа приложения (DAST) и проведении пентестов предупреждения не появляются;
  • неэффективная организация оповещений, в том числе о пороговых значениях, либо их отсутствие;
  • предусмотрено локальное хранение журналов;
  • не предусмотрено отслеживание подозрительной активности в АРI и журналах приложений;
  • сообщения в журнале отсутствуют, являются недостоверными или неясными из-за предупреждений и ошибок;
  • не осуществляется регистрация проверяемых событий.

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

Пути предотвращения уязвимости

Чтобы снизить риск возникновения этой уязвимости, рекомендуется:

• • Разработать план, в соответствии с которым будет осуществляться реагирование на атаки и другие ИБ-инциденты. Компания может принять один из существующих планов, к примеру, план NIST 800-61r2. 
  • Организовать мониторинг и обеспечить его эффективность, предусмотреть оповещение об инцидентах. Это позволит вовремя обнаруживать подозрительные активности и быстро на них реагировать. Как правило эту задачу берут на себя команды DevSecOps.
  • Обеспечить наличие и ведение контрольного журнала транзакций со значениями свыше определенного порогового (уровень устанавливается в зависимости от усредненных сумм транзакций конкретного бизнеса). Для журнала должен быть предусмотрен контроль целостности, чтобы затруднить злоумышленникам задачу по взлому или удалению данных.
  • Организовать корректную кодировку данных журнала.
  • Контролировать форматы, в которых создаются журналы. Они должны быть удобными для использования в решениях по управлению журналами.
  • Обеспечить возможность регистрации всех проверок входных данных, ошибок входа и иной важной для отслеживания инцидентов информации. Регистрация должна осуществляться с достаточным объемом данных, который позволит выявить подозрительные учетные записи, а также удерживать их в течение временного промежутка, необходимого для отложенной аналитики.

 
В зависимости от рисков, которым подвергается приложение, особенностей его использования и критичности данных, можно реализовать все перечисленные выше меры или выбрать только некоторые из них. 

Примеры возникновения уязвимости

Пример №1

Авиакомпания пострадала из-за нарушения правил обработки персональных данных. В журналы информационной системы попала конфиденциальная информация. Злоумышленники воспользовались этой уязвимостью и получили более 400 тысяч уникальных записей о платежных операциях клиентов организации. В результате регулятор наложил на компанию штраф. 

Пример №2

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

Пример №3

Поставщик услуг детского медицинского страхования обнаружил, что злоумышленники получили доступ к базам данных и внесли изменения в конфиденциальные медицинские записи примерно 3,5 миллионов застрахованных детей. Оператор веб-сайта страховщика не выявил подозрительную активность, так как мониторинг и регистрация инцидентов не были настроены, а разработчики сайта проигнорировали необходимость устранить эту уязвимость, чем и воспользовались злоумышленники. 
Предположительно утечка информации происходила с 2013 по 2020 годы включительно.