A09:2021 - Журнал безопасности и сбои мониторинга

Обзор

Добавлена из опроса сообщества Топ-10 (#3), поднявшись с десятого на девятое место. Эта категория расширена и включает больше типов сбоев, ее сложно тестировать, и она не очень хорошо представлена в данных CVE/CVSS. Однако сбои в этой категории могут напрямую влиять на видимость, оповещение об инцидентах и проведение экспертизы. Эта категория выходит за рамки CWE-778 Недостаточное ведение журнала, чтобы включить CWE-117 Неправильную нейтрализацию вывода для журналов, CWE-223 Пропуск информации, относящейся к безопасности, и CWE-532 Вставка конфиденциальной информации в файл журнала.

Описание

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

• Проверяемые события, такие как входы в систему, неудачные входы в систему и транзакции с высокой стоимостью, не регистрируются.
• Предупреждения и ошибки приводят к отсутствию, неадекватности или неясности сообщений журнала.
• Журналы приложений и API не отслеживаются на предмет подозрительной активности.
• Журналы хранятся только в определенном месте.
• Соответствующие оповещения о пороговых значениях и реагирования на процессы эскалации не установлены или не эффективны.
• Тестирование на проникновение и сканирование с помощью инструментов динамического тестирования безопасности приложений (DAST) (таких как OWASP ZAP) не вызывают предупреждений.
• Приложение не может обнаруживать, усиливать активные атаки или предупреждать о них в режиме реального времени или почти реального времени.

Вы не в безопасности от утечки информации, открывая регистрацию и оповещения для пользователя или злоумышленника (см. A01:2021 - Нарушенный контроль доступа).

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

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

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

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

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

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

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

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