Сбои регистрации журналов и мониторинга безопасности в рейтинге OWASP

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

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

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

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

Как проявляется:

• обнаружение или информирование об активных атаках в режиме онлайн (или максимально приближенном к режиму реального времени) в приложении не предусмотрено или по каким-то причинам не осуществляется;

• при проведении динамического анализа приложения (DAST) и проведении пентестов предупреждения не появляются;

• неэффективная организация оповещений, в том числе о пороговых значениях, либо их отсутствие;

• предусмотрено локальное хранение журналов;

• не предусмотрено отслеживание подозрительной активности в АРI и журналах приложений;

• сообщения в журнале отсутствуют, являются недостоверными или неясными из-за предупреждений и ошибок;

• не осуществляется регистрация проверяемых событий.

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

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

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

1. Разработать план, в соответствии с которым будет осуществляться реагирование на атаки и другие ИБ-инциденты. Компания может принять один из существующих планов, к примеру, план NIST 800-61r2.

2. Организовать мониторинг и обеспечить его эффективность, предусмотреть оповещение об инцидентах. Это позволит вовремя обнаруживать подозрительные активности и быстро на них реагировать. Как правило эту задачу берут на себя команды DevSecOps.

3. Обеспечить наличие и ведение контрольного журнала транзакций со значениями свыше определенного порогового (уровень устанавливается в зависимости от усредненных сумм транзакций конкретного бизнеса). Для журнала должен быть предусмотрен контроль целостности, чтобы затруднить злоумышленникам задачу по взлому или удалению данных.

4. Организация корректной кодировки данных журнала.

5. Контроль форматов, в которых создаются журналы. Они должны быть удобными для использования в решениях по управлению журналами.

6. Убедиться, что обеспечена возможность регистрации всех проверок входных данных, ошибок входа и иной важной для отслеживания инцидентов информации. Регистрация должна осуществляться с достаточным объемом данных, который позволит выявить подозрительные учетные записи, а также удерживать их в течение временного промежутка, необходимого для отложенной аналитики.

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

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

Пример №1

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

Пример №2

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

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

Пример №3

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