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

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

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

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

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

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

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

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

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

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

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

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

Пример №1

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

Пример №2

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

Пример №3

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

Связанные материалы

(Словарь терминов ИБ) NIST
(Словарь терминов ИБ) DAST
(Словарь терминов ИБ) OWASP
Поиск
Мы в соцсетях
Рассказываем об информационной безопасности и актуальных ИТ-решениях, делимся своими кейсами и новостями ИТ: Telegram-канал компании «Рубикон»
Дзен-канал компании «Рубикон»
Услуги

Подпишитесь на получение новостей

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

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

Принять