«Мы привыкли строить защиту так, будто у нас и у того, кто её ломает, одинаковые представления об уязвимости. Это стратегическое заблуждение, корень большинства ошибочных моделей угроз.»
Разные цели — одно поле
Когда мы моделируем угрозы или проектируем системы безопасности, мы почти бессознательно действуем в рамках единой аксиомы: мы и потенциальный нарушитель оцениваем риски и возможности по одним и тем же критериям. Мы предполагаем, что атакующий будет следовать определённой логике, искать «стандартные» уязвимости и действовать в рамках известных нам тактик. Мы верим, что защита — это симметричная игра.
Но это предположение опасно. Оно заставляет нас сосредоточиться на защите периметра, укреплении известных точек входа и контроле за регламентными процедурами. Мы строим баррикады там, где, по нашим правилам, должен пройти противник. А он в это время роет туннель под нашими ногами, используя правила, о которых мы не подумали.
Логика защитника: минимизация риска
Защитная стратегия строится на предсказуемости. Её цель — обеспечить непрерывность бизнес-процессов и соответствие требованиям регуляторов, таких как ФСТЭК. Ключевые понятия здесь:
- Комплаенс: система должна пройти аттестацию, соответствовать методическим документам, быть проверяемой. Защита оценивается по спискам контрольных вопросов.
- Известные векторы: угрозы каталогизированы, уязвимости занесены в базы (CVE), атаки описаны в матрицах (MITRE ATT&CK). Задача — закрыть эти известные бреши.
- Экономическая эффективность: инвестиции в защиту должны быть обоснованы, обычно через оценку вероятного ущерба. Защита часто оптимизируется под «наиболее вероятные» сценарии.
В этой логике безопасность — это состояние, которое можно достичь и сертифицировать. Мы играем в игру с конечным числом ходов, где правила прописаны в инструкциях.
Логика атакующего: максимизация результата
Атакующего не волнует соответствие требованиям или экономика безопасности. Его правила диктуются лишь конечной целью и доступными ресурсами. Его логика асимметрична:
- Цель оправдывает средства: если для доступа к данным нужно обойти десять систем контроля, но можно договориться с одним сотрудником, выбор будет сделан в пользу человека, а не технологии.
- Неизвестные векторы: в ход идут не задокументированные уязвимости в бизнес-логике приложения, особенности конфигурации, специфика работы конкретного оборудования или человеческий фактор, который невозможно формализовать в модели угроз.
- Неограниченное время: защитник должен быть начеку всегда, атакующему достаточно одного успешного момента. Защита — это марафон, атака — спринт в непредсказуемый момент.
Атакующий не играет по нашему сценарию. Он ищет разрыв между формальной моделью безопасности и реальной, «живой» системой. Его правило одно: добиться цели минимальной ценой, игнорируя любые наши «правильные» построения.
[ИЗОБРАЖЕНИЕ: Схема, где слева — структурированная, иерархическая модель защиты с четкими границами (периметр, сегменты, контроль доступа). Справа — хаотичный набор стрелок, обходящих эти границы через социальную инженерию, неизвестные уязвимости в прикладном ПО и цепочки из малозначительных прав.]
Где предположение ломается: практические примеры
Разрыв в правилах игры проявляется в конкретных технических и организационных просчётах.
Слепая вера в сегментацию
Защитник тратит ресурсы на построение сетевых DMZ, VLAN, микросегментации. В модели угроз это выглядит как надёжное разделение зон. Атакующий же, обнаружив одну скомпрометированную рабочую станцию в «доверенном» сегменте, исследует забытые администраторами статические маршруты, неправильно настроенные межсетевые экраны или использует легитимные средства управления (например, PsExec) для латерального перемещения. Сегментация была, но правила её обхода оказались вне модели.
Фетишизация сложных паролей и MFA
Политика безопасности требует 12-символьных паролей с заменой каждые 90 дней и двухфакторной аутентификации. По нашим правилам — это крепко. Но атакующий не брутфорсит пароль. Он внедряет фишинговый фрейм на корпоративном портале, который перехватывает одноразовый код из push-уведомления, или использует устаревший и забытый метод аутентификации (например, базовую аутентификацию для API), который остался в системе для совместимости. Защита была сконцентрирована на «передовой», а уязвимость нашлась на «фланге».
Аттестация как финишная черта
После успешной аттестации по требованиям 152-ФЗ и ФСТЭК у руководства возникает ощущение выполненной работы. Система «защищена». Но аттестация — это снимок состояния на определённый момент в рамках заданной модели. Атакующий работает с динамической системой: выходит обновление ПО, меняется конфигурация, увольняется опытный сотрудник, появляется новый контур интеграции. Его «правила» допускают атаку на компонент, который появился уже после составления акта аттестации и не попал ни в одну модель угроз.
К чему ведёт ошибочное предположение
Игнорирование асимметрии порождает системные слабости.
- Иллюзия контроля: чем сложнее и формальнее построена защита по «нашим» правилам, тем сильнее вера в её неуязвимость. Это снижает бдительность и замедляет реакцию на нестандартные инциденты.
- Перекос ресурсов: бюджет и время уходят на реализацию громоздких контрмер из методичек, в то время как простые, но эффективные меры (например, жёсткий контроль учётных записей сервисов или анализ исходящего трафика) остаются без внимания.
- Неадекватные модели угроз: модели строятся на предположении, что злоумышленник будет атаковать «правильно». Это исключает из рассмотрения низкотехнологичные, но разрушительные сценарии вроде саботажа со стороны инсайдера с привилегированным доступом.
Как сместить фокус: от симметрии к асимметрии
Отказаться от удобного предположения трудно, но необходимо. Это не значит игнорировать стандарты. Это значит накладывать на них слой асимметричного мышления.
- Ищи слабости в своей собственной логике. Проводите не только сканирование уязвимостей, но и Red Team-упражнения, где «красная команда» имеет задачу достичь цели, игнорируя прописанные регламенты. Их задача — найти те самые «подземные туннели».
- Декомпозируйте цель атакующего. Вместо вопроса «как защитить сервер?» задавайтесь вопросом «что нужно злоумышленнику в нашей сети и какой самый дешёвый для него путь к этому?». Часто ответ лежит вне ИТ-инфраструктуры.
- Принимайте неизвестное. Включите в модель угроз категорию «неучтённые векторы атак» и создайте процедуры быстрого обнаружения аномальной активности, а не только известных сигнатур. Инвестируйте в расширенное обнаружение и реагирование (XDR) и анализ поведения.
- Тестируйте на прочность бизнес-логику. Статический анализ кода и сканеры веб-уязвимостей не найдут изъян в последовательности бизнес-операций, который позволяет, например, дважды списать денежные средства. Это требует отдельного, глубокого тестирования.
[ИЗОБРАЖЕНИЕ: Две колонки. Левая: «Защитник думает» со списками: «Соответствие, Известные CVE, Контроль доступа, Логирование». Правая: «Атакующий ищет» со списками: «Ошибки в бизнес-процессах, Устаревшие учётные записи, Человеческий фактор, Нелогичные конфигурации». Между колонками — жирная красная стрелка с надписью «Разрыв в правилах игры».]
Вывод
Предположение об общих правилах — это когнитивная ловушка, упрощающая реальность до удобной, но неадекватной модели. Настоящая устойчивость системы начинается с признания этого разрыва. Задача защитника — не просто построить крепость по учебнику фортификации, а постоянно задаваться вопросом: «А если противник проигнорирует все эти стены и поступит иначе?». Безопасность — это не состояние, достигнутое раз и навсегда, а непрерывный процесс адаптации к правилам, которые пишет не только регулятор, но и тот, кто эти правила намерен нарушить.