Всем привет 👋!
Продолжаем формировать процесс Detection Engineering в компании
World of Detection. К этому моменту у нас уже внедрен трекер задач для учета и ведется активная разработка и доработка правил обнаружения. Однако аналитики не успевают справляться с поступающими задачами.Рассмотрим ситуацию)
У компании
World of Detection используется Exchange, а OWA (Outlook Web Access) доступна из интернета. В трекер задач поступил запрос на разработку правила для обнаружения эксплуатации уязвимости 🤬 (unauth RCE via OWA), эксплойт для которой доступен на GitHub. Администраторы сообщили, что обновление системы в данный момент невозможно, и придется ждать выходных. Тем временем аналитики продолжают разбирать поступающие запросы, и неизвестно, когда они доберутся до задачи, связанной с Exchange.Хакеры 😈, естественно, воспользовались уязвимостью, взломали почтовый сервер, проникли во внутреннюю сеть и зашифровали часть инфраструктуры.
Когда начали разбираться, почему уязвимость не была обнаружена своевременно, выяснилось, что запрос на разработку правила уже был в трекере. Аналитики еще раз пояснили, что обрабатывают задачи по мере их поступления, без какой-либо фильтрации или приоритизации.
Что мы упустили?
Один из ключевых этапов — triage (сортировка и приоритизация задач). В созданной нами ранее карточки не предусмотрено поле для критичности (срочности).
Далее я рассмотрю один из способов расчета критичности для задачи на разработку правил обнаружения. Этот способ не является панацеей, и у каждой компании может быть свой подход к определению критичности и срочности разработки правил.
#detection@detectioneasy