В обновленном рейтинге эта категория поднялась с 10 на 9 позицию. Категория значительно расширилась и помимо недостаточности ведения журналов вобрала в себя такие проблемы, как пропуски данных, некорректный вывод журналов и включение в них информации, которая считается конфиденциальной.
Тестировать уязвимости этой категории непросто, но включение ее в рейтинг специалисты OWASP посчитали важным, так как относящиеся к ней сбои оказывают непосредственное влияние на оповещение об инцидентах и их видимость , проведение экспертиз.
Признаки и причины появления уязвимости
Если нарушения не регистрируются, у компании нет возможности их мониторить или используемые способы отслеживания нарушений не достаточно эффективны. Возникает проблема. В такой ситуации инциденты практически невозможно вовремя обнаружить и отреагировать на них.
Как проявляется:
- обнаружение или информирование об активных атаках в режиме онлайн (или максимально приближенном к режиму реального времени) в приложении не предусмотрено или по каким-то причинам не осуществляется;
- при проведении динамического анализа приложения (DAST) и проведении пентестов предупреждения не появляются;
- неэффективная организация оповещений, в том числе о пороговых значениях, либо их отсутствие;
- предусмотрено локальное хранение журналов;
- не предусмотрено отслеживание подозрительной активности в АРI и журналах приложений;
- сообщения в журнале отсутствуют, являются недостоверными или неясными из-за предупреждений и ошибок;
- не осуществляется регистрация проверяемых событий.
Плохо, если не настроена анонимность журналов событий ИБ или оповещения о них приходят всем пользователям приложения. В этом случае высокий риск видимости таких данных злоумышленникам и, соответственно, риск утечки информации.
Пути предотвращения уязвимости
Чтобы снизить риск возникновения этой уязвимости, рекомендуется:
- Разработать план, в соответствии с которым будет осуществляться реагирование на атаки и другие ИБ-инциденты. Компания может принять один из существующих планов, к примеру, план NIST 800-61r2.
- Организовать мониторинг и обеспечить его эффективность, предусмотреть оповещение об инцидентах. Это позволит вовремя обнаруживать подозрительные активности и быстро на них реагировать. Как правило эту задачу берут на себя команды DevSecOps.
- Обеспечить наличие и ведение контрольного журнала транзакций со значениями свыше определенного порогового (уровень устанавливается в зависимости от усредненных сумм транзакций конкретного бизнеса). Для журнала должен быть предусмотрен контроль целостности, чтобы затруднить злоумышленникам задачу по взлому или удалению данных.
- Организация корректной кодировки данных журнала.
- Контроль форматов, в которых создаются журналы. Они должны быть удобными для использования в решениях по управлению журналами.
- Убедиться, что обеспечена возможность регистрации всех проверок входных данных, ошибок входа и иной важной для отслеживания инцидентов информации. Регистрация должна осуществляться с достаточным объемом данных, который позволит выявить подозрительные учетные записи, а также удерживать их в течение временного промежутка, необходимого для отложенной аналитики.
В зависимости от рисков, которым подвергается приложение, особенностей его использования и критичности данных, можно реализовать все перечисленные выше меры или выбрать только некоторые из них.
Примеры возникновения уязвимости
Пример №1
Авиакомпания пострадала из-за нарушения правил обработки персональных данных. В журналы информационной системы попала конфиденциальная информация. Злоумышленники воспользовались этой уязвимостью и получили более 400 тысяч уникальных записей о платежных операциях клиентов организации. В результате регулятор наложил на компанию штраф.
Пример №2
Другая авиакомпания выявила способ утечки информации, которым пользовались более 10 лет. За это время злоумышленники получили информацию о паспортных данных и кредитных картах нескольких миллионов пассажиров, пользовавшихся услугами компании.
По результатам расследования было установлено, что утечка информации произошла на стороне провайдера облачного хостинга. Причем провайдер направил компании уведомление о проблеме только спустя некоторое время.
Пример №3
Поставщик услуг детского медицинского страхования обнаружил, что злоумышленники получили доступ к базам данных и внесли изменения в конфиденциальные медицинские записи примерно 3,5 миллионов застрахованных детей. Оператор веб-сайта страховщика не выявил подозрительную активность, так как мониторинг и регистрация инцидентов не были настроены, а разработчики сайта проигнорировали необходимость устранить эту уязвимость, чем и воспользовались злоумышленники.
Предположительно утечка информации происходила с 2013 по 2020 годы включительно.