Исторически так сложилось, что в нашей индустрии принято делить кибербезопасность на реальную и «бумажную». Деление грубое, но честное. Реальная безопасность отвечает на вопрос: выдержит ли компания целевую атаку, фатальную ошибку администратора или шифровальщика в региональном филиале?

«Бумажная» безопасность отвечает на другой: сможет ли компания показать проверяющим красивый акт, протокол, приказ и скриншот с подписью ответственного лица?

Смеяться над «бумажной» безопасностью легко. Особенно тем, кто каждый день видит живую инфраструктуру: забытые серверы, открытые порты, уволенных сотрудников с активными доступами и облачные хранилища, созданные разработчиками «на пять минут». Но у «бумажной» безопасности есть фундаментальная причина ее существования. Бизнесу, регулятору, аудитору и совету директоров нужен проверяемый след решения. Нельзя каждый раз, как консервную банку, вскрывать компанию до основания, чтобы понять, работает ли защита. Нужен язык отчетности и автоматизированных доказательств. Проблема начинается там, где бумажная форма окончательно отрывается от технического состояния.

Классическая модель выглядит так: компания проходит аудит или аттестацию, закрывает замечания, получает акт соответствия и спокойно живет до следующей проверки. Но реальность меняется быстрее. Через месяц меняется подрядчик. Через два появляется новый внешний сервис. Через полгода закупается ПО, которое никто не вносит в реестр активов. А когда через год приходит пентест, руководство искренне удивляется, почему наружу торчит половина ИТ-хозяйства, хотя в прошлогодних отчетах «все было зеленое».

Чем сложнее становится регуляторика и инфраструктура, тем хуже работает эта дискретная модель. Требований и облаков больше, скорость релизов выше. Вчерашний акт уже не описывает сегодняшнюю сеть. Отчет за прошлый квартал никак не объясняет инцидент, случившийся вчера вечером.

Рынок ответил на это модным термином — непрерывный анализ защищенности (Continuous Pentest/Continuous Validation). Звучит правильно. Но давайте будем честны: часто за этими красивыми словами скрывается банальное сокращение интервалов. Ведь настоящая непрерывность появляется не тогда, когда мы чаще зовем проверяющих, а тогда, когда сама инфраструктура начинает производить доказательства своего состояния в режиме реального времени. Для бизнеса это важнее, чем может показаться. Руководитель не должен разбираться в каждом правиле межсетевого экрана или атрибутах облачной роли. Но он должен понимать разницу между отчетом о прошлом и управлением текущим состоянием. В первом случае компания узнает о проблеме во время проверки или после инцидента. Во втором она видит отклонение почти сразу и может решить: исправить, принять риск, ограничить доступ, отключить сервис, потребовать от подрядчика действий, поднять вопрос на управляющем комитете.

Мир уже движется в сторону машиночитаемой регуляторики. В США институт NIST активно развивает OSCAL (Open Security Controls Assessment Language). Его смысл прост: описывать каталоги защитных мер, профили и результаты оценки в машиночитаемом виде (JSON/YAML), а не в многостраничных PDF- или ODT-файлах.

В Европе обсуждают подход Rules as Code, а в финансовом секторе ЕС вступает в силу DORA (Digital Operational Resilience Act), которая требует от организаций не политик на полке, а цифровой операционной устойчивости с непрерывным контролем ИКТ-рисков.

В России своя специфика. У нас масштабная нормативная база (КИИ, ПДн, ГОСТы), жесткие требования регуляторов и лавинообразное импортозамещение.

Но управленческая проблема идентична мировой: ручной труд ИБ-специалистов перестал масштабироваться. Если компания каждый раз собирает доказательства соответствия руками, она тратит все больше ресурсов на подготовку к проверке, все меньше понимает свое реальное состояние и перестает заниматься реальной безопасностью.

Сегодня многие отечественные компании живут в режиме «предаудитной мобилизации». За месяц до проверки начинается охота за документами. Администраторы делают выгрузки, ИБ просит скриншоты, юристы выверяют формулировки. Compliance превращается в обособленное бумажное производство, которое живет рядом с инфраструктурой, но не внутри нее. Поэтому и возникает конфликт между «бумагой» и "реальностью", которая меняется быстрее, чем компания успевает обновлять документы.

Настоящая цель автоматизации compliance — неразрывно связать требование регулятора, технический контроль, доказательство и управленческое решение.
Например, есть требование ограничивать привилегированный доступ. В бумажной модели компания показывает положение об управлении доступом, список администраторов, несколько заявок и акт последней проверки. В более зрелой модели система сама показывает, кто имеет привилегии, почему получен доступ, когда последний раз использовались права, есть ли многофакторная аутентификация, связан ли доступ с рабочей ролью, есть ли просроченные исключения, кто их согласовал. Аудитор смотрит на устойчивый механизм контроля.

Или другой пример: требование управлять уязвимостями. В старой модели есть регламент, отчет сканера и план устранения. На практике часть систем не сканируется, часть принадлежит подрядчикам, а патчи не ставятся, потому что «бизнес-сервис критичный». В непрерывной модели система сама показывает: вот актив, его владелец, уязвимость, компенсирующие меры (например, виртуальный патчинг на WAF или отключение порта на коммутаторе), сроки устранения, исключения и признаки попыток эксплуатации. Если уязвимость нельзя закрыть быстро, мониторинг должен показать, пытается ли кто-то ей воспользоваться.

Здесь важно не обмануться термином «непрерывный пентест». Пентест можно проводить чаще, держать внешнюю команду на постоянном контракте, использовать платформы, которые регулярно проверяют поверхность атаки. Но человек все равно работает с ограниченным временем, областью и гипотезами. Даже автоматические атаки и BAS-сценарии обычно запускаются сериями, а не превращают инфраструктуру в живой самопроверяющийся организм.

Настоящая непрерывная оценка защищенности требует другого фундамента. Компания должна знать, что у нее есть. Описывать инфраструктуру так, чтобы изменения проходили через контролируемый процесс. Проверять настройки до внедрения, а не после. Собирать доказательства из первичных систем, а не из ручных отчетов. Видеть отклонения от базового состояния. Быстро понимать, какое отклонение создает риск реализации недопустимого события, а какое можно принять на ограниченный срок.

Сетевые правила, облачные ресурсы, роли доступа, параметры серверов, кластеры, политики могут меняться не руками в консоли, а через управляемый процесс. Любое изменение проходит через автоматическую проверку политик до того, как попадет в продуктивную среду.

• Не открыт ли опасный порт?
• Не выданы ли избыточные права; особенно для ИИ-агентов?
• Включена ли регистрация событий?
• Не нарушена ли сегментация?
• Не появился ли ресурс без владельца и метки критичности?
• Не противоречит ли изменение внутренней политике?

Так, compliance встраивается в сам рабочий процесс: «не пройдешь автоматическую проверку — не попадешь в прод». Проверка должна помогать выпускать изменения быстрее и безопаснее, а не превращаться в новый ручной забор. Это пресловутый shift left, но уже применительно не ко всей ИТ-инфраструктуре компании.

Машиночитаемые политики здесь играют роль переводчика. Они абстрактное «обеспечить защиту от НСД» разложат на проверяемые условия: включена ли многофакторная аутентификация для администраторов, запрещен ли прямой доступ из Интернета к внутренним системам, отправляются ли журналы в централизованное хранилище, защищены ли резервные копии от удаления, не лежат ли критичные секреты в репозитории, пересматриваются ли доступы с заданной периодичностью, доказал ли автопентестер (BAS) невозможность захвата Active Directory или иного корпоративного справочника?

Часть требований останется на уровне экспертной оценки, и это нормально. Машина не решит за совет директоров, какой риск допустим, а какое событие является недопустимым, не поймет политический контекст инцидента. Но машина может снять огромный пласт рутины: показать, где защитная мера есть, где ее нет, где данные устарели, где владелец не назначен.

Для собственника и руководителя такая система ценна потому, что она меняет качество управления. Вместо вопроса «Мы прошли проверку?» можно задать другой: «Что сейчас мешает нам доказать защищенность критичных процессов?» Ответ будет неприятнее, но зато полезнее. Может выясниться, что проблема не в отсутствии нового средства защиты, а в неучтенных активах или в подрядчике, который не дает данные. Российским компаниям этот разговор особенно важен. Многие из них одновременно решают несколько задач: выполняют требования регуляторов, заменяют иностранные решения, строят новые цифровые сервисы, обеспечивают киберустойчивость при атаках, экономят бюджеты и объясняют руководству, зачем все это нужно.

В такой ситуации ручной compliance быстро превращается в болото. Люди устают, документы плодятся, проверки множатся, а ясности не становится больше. Автоматизация не отменит регуляторную специфику. Но компании могут начать с внутреннего уровня и самостоятельно переводить свои политики и стандарты в проверяемые правила.

Опасно начинать с закупки дорогой платформы «непрерывного compliance» или дашборда для руководства, если на нижнем уровне нет учета активов.

В перспективе победит компания, которая встроит проверку в ткань своей инфраструктуры и управления. Проверяющий не должен каждый раз вытаскивать правду наружу вручную. Она должна накапливаться в системах сама: в логах, заявках, репозиториях, политиках, результатах сканирования, решениях о рисках, истории изменений. И «бумажная» безопасность никуда не исчезает — она просто меняет роль. Документ остается нужен, ведь он фиксирует ответственность, границы, решения, правила, но он перестает быть главным доказательством. Им становится связка живых данных: что требовали, как реализовали, чем подтвердили, кто увидел отклонение, что сделал, кто принял остаточный риск.

Для специалистов, которые определяют техническую политику, это означает смену приоритетов. Нужно больше думать об архитектуре доказательств. Сканер важен, но он должен видеть активы. EDR важен, но его покрытие должно проверяться. SIEM важен, но логи должны поступать из нужных источников.

Для бизнеса это путь от "ИБ просит бюджет, потому что надо соответствовать", к более понятной логике: «мы строим систему, которая показывает состояние критичных процессов, снижает неопределенность, ускоряет проверки, уменьшает ручной труд и помогает руководству принимать решения, основанные на фактах, а не предположениях».

Через пять-десять лет право и регуляторика вряд ли станут машиночитаемыми. Слишком много зависит от контекста, отрасли, ущерба, разумности мер, намерений и трактовок. Но технически проверяемая база уйдет в код. Те компании, которые начнут строить свою инфраструктуру как код и оцифровывать доказательства безопасности уже сегодня, получат огромное преимущество.