Недостаточность мониторинга системы является основой почти всех крупных взломов. Злоумышленники используют отсутствие контроля и своевременного реагирования для достижения своих коварных целей. Одна из стратегий определения уровня протоколирования заключается в проверке жерналов после тестирования на проникновение. Записей в журналах должно быть достаточно, чтобы оценить, какой урон мог быть нанесен системе. Существуют коммерческие и открытые среды защиты приложений, такие как OWASP AppSensor , брандмауэры веб-приложений (ModSecurity с базовым набором правил OWASP ModSecurity), и программное обеспечение для корреляции журналов с настраиваемыми панелями мониторинга и оповещениями.
Является ли приложение уязвимым?
Систему можно считать уязвимой, если:
- Пользовательские события, такие как входы в систему, неудачные входы в систему и операции, не регистрируются.
- Предупреждения и ошибки не генерируют никаких сообщений в журнале.
- Журналы приложений и API не отслеживаются на предмет подозрительной активности.
- Журналы хранятся только локально.
- Соответствующие пороги оповещения и процессы эскалации реагирования отсутствуют или не эффективны.
- Тестирование на проникновение и сканирование с помощью инструментов DAST (таких как OWASP ZAP ) не вызывают оповещения.
- Приложение не логгирует или оповещает об активных атаках в реальном времени.
- Система уязвима к утечке информации, если делаете запись событий и оповещение о событиях видимыми для пользователя или злоумышленника (см. A3)
Как предотвратить
- Убедитесь, что все ошибки входа в систему, контроля доступа и проверки входных данных на стороне сервера могут регистрироваться с достаточным для выявления подозрительных или злонамеренных действий контекстом и храниться в течение достаточного времени для проведения отложенного судебного анализа.
- Убедитесь, что журналы создаются в формате, который можно легко использовать для решений централизованного управления журналами.
- Убедитесь, что важные операции имеют контрольный журнал с элементами управления целостностью, чтобы предотвратить подделку или удаление, например БД только для чтения.
- Установить эффективный мониторинг и оповещение таким образом, чтобы подозрительные действия обнаруживались и своевременно реагировались.
- Разработать или принять план реагирования на инциденты, например NIST 800-61 rev 2 или более поздний.
Примеры атак
Сценарий № 1 : Программное обеспечение проекта с открытым исходным кодом, разработанное небольшой группой разработчиков, было взломано с использованием уязвимости в его программном обеспечении. Злоумышленникам удалось уничтожить внутренний репозиторий исходного кода, содержащий следующую версию, и все содержимое форума. Хотя источник может быть восстановлен, отсутствие мониторинга, регистрации или оповещения привело к худшему. В результате этой атаки проект не активен.
Сценарий № 2. Злоумышленник использует сканирование пользователей, использующих общий пароль, а система не производит логирование перебора.
Сценарий № 3 : у крупного американского ритейлера была внутренняя песочница для анализа вредоносных программ, анализирующая вложения. Программное обеспечение «песочницы» обнаружило потенциально нежелательное программное обеспечение, но никто не среагировал на находку. Песочница в течение некоторого времени выдавала предупреждения, прежде чем было обнаружено нарушение из-за мошеннических операций с картами со стороны внешнего банка.
Полезные ссылки
- https://www.owasp.org/index.php/OWASPProactiveControls#8:ImplementLoggingandIntrusion_Detection
- https://www.owasp.org/index.php/Category:OWASPApplicationSecurityVerificationStandard_Project#tab.3DHome
- https://www.owasp.org/index.php/LoggingCheatSheet
