⚠️ SOAR-плейбуки превратились в машину производства ложных выводов: урок HTCE для IR-процессов Прошёл очередной инцидент: пентестер получил reverse shell в открытом RDP, SOAR-плейбук автоматически дописал заметку об обогащении данных «External perimeter: confirmed breach» и присвоил severity critical — хотя хост был изолированной тестовой машиной за NAT, не имевшей доступа к продакшен-сетям. Формальный процесс был соблюдён, плейбук отработал без ошибок — и создал ложный инцидент высокого приоритета, который дежурная смена эскалировала CISO. Это и есть производство ложных выводов в действии: вывод, полученный из корректного свидетельства, автоматически продвигается в статус истины без проверки контекста. Проект HTCE, описанный на Habr, формулирует эту проблему архитектурно: есть L1-наблюдение (алерт), L2-свидетельство (результат сканера), L3-кандидатный вывод (гипотеза о breach) — и между ними должны стоять проверки, которых в большинстве SOAR-реализаций нет. Плейбук в нынешнем виде принимает внешний вердикт за истину и пишет его напрямую в CMDB или инцидент-карточку. Авторы HTCE предлагают другой путь: внешний результат (сканер, EDR-вердикт, SMT-прувер) проходит через запись о расхождениях, арбитраж и только затем становится кандидатом — никогда не истиной автоматически. В практическом IR это означает три вещи. Во-первых, теги обогащения данных должны иметь уровень: «наблюдение», «кандидат», «проверено» — и плейбук не имеет права эскалировать до ручной верификации критичности. Во-вторых, конфликт данных (один сканер говорит «эксплойт сработал», другой — «версия не уязвима») должен порождать карантин, а не объединение с приоритетом более громкого источника. В-третьих, бюджет проверок должен быть конечным: если IR-команда получила 200 алертов за час и пытается прогнать каждый через полное обогащение данных, система должна перейти в режим деградации — безопасный отказ с эскалацией оператору, а не в автоматический ложный результат. Отдельно стоит моделирование угроз для внедрения ложного авторитета: разработчик, тимлид или вендор могут передать в тикет-систему утверждение «патч применён, уязвимость закрыта» — и это утверждение часто принимается как L2-истина без цепочки свидетельств. По логике HTCE, такое утверждение должно оставаться кандидатом до проверки свидетельством: либо формальной (SMT-подобной проверки compliance-сканера), либо эмпирической (penetration test на конкретный вектор). Большинство зрелых IR-процессов, которые я видел, ломаются именно на этапе автоматического продвижения гипотезы в истину. Плейбук, который не различает наблюдение и истину — это не автоматизация, а машина для производства бюрократии. Сколько тегов обогащения данных в вашем SOAR сегодня стали причиной эскалации ложного инцидента за последний месяц? По данным habr_infosec #IR #SOAR #truth_injection #automation_failure #DevSecOps