«Сложность в ИБ — не дефект, а ресурс. Он создаётся не случайно, а теми, кому он нужен: продавцам для увеличения средней стоимости чека, аудиторам для расширения мандата, госзаказчикам для обоснования расходов, инсайдерам для закрепления своего статуса и регулятору для сохранения монополии на толкование. Простая система с понятными границами никому не выгодна. И только тем, кто за неё платит, эта сложность обходится в миллионы и в конечную безопасность»
.
Почему «просто» не побеждает
Кажется очевидным: кибербезопасность должна стремиться к простоте. Чем проще архитектура, тем меньше поверхность атаки, легче контролировать целостность, быстрее реагировать на инциденты. Однако на практике наблюдается обратное: системы, процессы и требования с каждым годом становятся всё сложнее. Эта complexity — не побочный эффект прогресса, а следствие экономических и социальных интересов конкретных групп. Простая, прозрачная и эффективная модель угрожает целым экосистемам, выстроенным вокруг управляемой сложности.
Рассмотрим типичную ситуацию внедрения средства защиты информации (СЗИ). Вместо одного интегрированного решения предлагается набор из десятка модулей от одного вендора, каждый со своей консолью, политиками и лицензией. Вместо чёткого стандарта на настройку межсетевых экранов создаётся трёхсотстраничное руководство по безопасной разработке, отсылающее к десятку других документов. Такая избыточность не повышает безопасность, но создаёт поле для манёвра.
Вендоры: монетизация неопределённости
Для производителей средств защиты и софта complexity — основной двигатель роста выручки. Простое, «закрывающее» все базовые потребности решение имеет низкую цену и быстро насыщает рынок. Гораздо выгоднее разбить функционал на множество модулей и создать narrative о необходимости «глубокой интеграции» и «комплексного подхода».
Пример: вместо единого модуля контроля доступа к информационным системам (ИС) вендор предлагает отдельные продукты для управления привилегированными учётными записями, контроля сессий, анализа поведения, управления паролями и аудита действий. Каждый требует отдельного внедрения, обучения, сопровождения и обновления. Сложность их взаимодействия порождает потребность в сервисных контрактах «премиум-уровня». Клиент, увязнув в одной экосистеме, вынужден докупать смежные продукты этого же вендора, так как интеграция с решением конкурента объявляется «небезопасной» или «неподдерживаемой».
Вендорская документация часто намеренно запутана, а настройки избыточны. Это создаёт иллюзию исключительной мощности инструмента («если здесь так много ползунков, значит, он решает очень сложные задачи») и делает клиента зависимым от экспертов вендора. Самостоятельная тонкая настройка становится почти невозможной, что гарантирует повторные продажи консалтинговых часов.
Аудиторы и консультанты: сложность как гарантия занятости
Процедура аудита соответствия требованиям ФСТЭК России или 152-ФЗ изначально содержит в себе потенциал для наращивания сложности. Чем расплывчатее и объёмнее требования, тем больше пространства для их интерпретации.
Аудиторская организация заинтересована не в том, чтобы клиент быстро и навсегда привёл всё в порядок, а в том, чтобы процесс исправления замечаний был длительным, требующим постоянных уточнений и повторных проверок. Например, требование «обеспечить регистрацию событий безопасности» может быть истолковано как необходимость внедрения полноценной SIEM-системы с корреляцией правил, даже если для конкретной ИС достаточно журналов ОС. Консультант, в свою очередь, предложит «лучшие практики», которые часто являются калькой с зарубежных фреймворков и добавляют слои абстракции, не имеющие прямого отношения к российскому регулированию.
Так формируется замкнутый круг: сложные требования рождают спрос на сложные консультации, которые оборачиваются сложными отчётами, содержащими новые сложные рекомендации для следующего цикла аудита.
Государственные заказчики и распределение бюджета
В государственном секторе, особенно в рамках крупных ИТ-проектов, сложность выполняет функцию обоснования бюджета. Объёмный, технически запутанный технический проект или план мероприятий по защите информации выглядит более солидно и «проработанно», чем лаконичный. Это снижает риски для ответственного лица при проверках Счётной палаты или внутреннего контроля: легче аргументировать расходы в сотни миллионов, если они размазаны по множеству сложносочинённых позиций.
Например, вместо закупки готового сертифицированного МЭ для сегментации сети может быть инициирован многомесячный проект по «разработке архитектуры микросегментации с применением решений класса NGFW и систем управления политиками». Такой проект потребует привлечения системного интегратора, отдельного вендора, команды архитекторов и даст работу целому отделу на годы. Простое и эффективное решение не позволяет освоить выделенный по статье бюджет в полном объёме, а иногда и вовсе ставит под сомнение необходимость самого проекта такого масштаба.
Инсайдеры и эксперты: капитализация знаний о лабиринте
В любой крупной организации со временем появляются сотрудники или целые отделы, которые становятся единственными хранителями знаний о запутанных внутренних процессах безопасности, уникальных скриптах, недокументированных возможностях СЗИ или тонкостях взаимодействия с регулятором. Эта knowledge gap — их ключевой актив и гарантия незаменимости.
Упрощение и документирование процессов, стандартизация конфигураций, внедрение платформ с низким порогом входа (low-code/no-code для автоматизации ИБ) напрямую угрожают их статусу. Поэтому негласное сопротивление таким инициативам — обычное дело. Сложность становится инструментом job security. Эксперт может сознательно усложнять описание проблемы или решения, используя профессиональный жаргон, чтобы сохранить монополию на понимание системы.
Сам регулятор: монополия на интерпретацию
Наконец, определённую выгоду из complexity извлекает и сам регулирующий орган. Чёткие, бинарные, технически конкретные требования (типа «шифрование TLS не ниже 1.2») оставляют мало пространства для манёвра и обсуждений. Они легко проверяемы, в том числе автоматически. Напротив, требования, сформулированные как «применение комплекса организационных и технических мер, достаточных для противодействия актуальным угрозам», являются принципиально интерпретируемыми.
Такая формулировка сохраняет за регулятором роль высшего арбитра, «держателя контекста». Это позволяет гибко подходить к разным организациям (что иногда необходимо), но также создаёт поле для неопределённости, которую заполняют все остальные игроки: вендоры, аудиторы, консультанты. Регулятору невыгодна предельная простота, потому что она снижает его влияние и делает процесс регулирования слишком прозрачным и предсказуемым для регулируемых.
Кто проигрывает и что можно сделать
Проигрывает, в конечном счёте, заказчик — организация, которая платит за всё: за избыточные лицензии, за бесконечные часы консалтинга, за неэффективные процессы, за риски, вызванные самой сложностью системы. Её безопасность не становится выше, а средства расходуются неоптимально.
Разорвать этот круг можно только осознанным движением в сторону simplification:
- Техническая архитектура: настаивать на принципах KISS (Keep It Simple, Stupid) и глубокой интеграции вместо набора точечных решений. Требовать от вендоров понятных, исчерпывающих документов по архитектуре безопасности их продуктов.
- Процессы и регулирование: внутри организации работать над переводом регуляторных требований в чёткие, измеримые технические спецификации. Там, где это возможно, заменять многостраничные политики на автоматизированные проверки (policy as code).
- Работа с поставщиками: включать в контракты критерии оценки успешности внедрения, привязанные к конкретным метрикам безопасности, а не к количеству установленных модулей. Проводить регулярные независимые penetration test не по версиям вендора, а по реальной конфигурации.
- Культура: поощрять документирование и стандартизацию, бороться с культом «незаменимых экспертов» через кросс-обучение и ротацию.
Complexity в кибербезопасности, это не техническая проблема, а политико-экономический феномен. Борьба с ней начинается не с поиска нового, более «простого» инструмента, а с честного ответа на вопрос: кому в вашем проекте или организации сейчас выгодно, чтобы всё оставалось сложным. Без этого ответа любая попытка упрощения будет саботирована теми, кто разжился на лабиринте.