Почему компании не внедряют ИБ-стандарты и редко проверяют защиту

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

Данные опроса глав ИБ- и IT-направлений средних и крупных компаний, проведенного K2 Cloud, хорошо показывают этот разрыв. Только 20% организаций внедрили собственные стандарты информационной безопасности, которые учитывают актуальные тренды кибератак и не сводятся к прохождению аудита. Еще у 15% есть задокументированные сценарии реагирования на инциденты, которые регулярно тестируются и обновляются. 40% компаний проверяют системы на уязвимости, но каждая третья не проводит такие проверки вовсе.

Отдельная слабая зона — обучение сотрудников. У трех из четырех компаний оно либо не проводится, либо проходит редко и формально: при приеме на работу, после инцидента или в виде разовой рассылки. При этом именно сотрудники часто становятся первой точкой входа для злоумышленника: через фишинг, слабые пароли, невнимательность к подозрительным письмам или нарушение правил доступа.

Еще один показатель незрелости — разрыв между ИБ и бизнес-рисками. В 91% случаев стратегии безопасности не учитывают возможные потери компании от кибератак. Только 9% организаций включают такие риски в задачи и бюджеты. Остальные планируют расходы на защиту по привычным параметрам: числу сотрудников, общему IT-бюджету, текущим закупкам или требованиям регулятора.

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

Одна из причин такого положения — ограниченные ресурсы. У бизнеса всегда есть понятные аргументы в пользу новых IT-сервисов, развития продаж, автоматизации производства или клиентских продуктов. ИБ на этом фоне часто проигрывает, потому что ее результат сложнее показать заранее. Хорошая защита проявляется не в росте выручки, а в отсутствии остановок, утечек, штрафов и аварийного восстановления.

Эту проблему отмечает и руководитель отдела риск-менеджмента кибербезопасности ГК Softline Елизавета Маркова. По ее словам, при наличии ресурсов компании чаще опираются не на самописные документы, а на международные практики и фреймворки, включая ISO 27001 и NIST. «Разрабатывать собственный стандарт с нуля, когда существуют проверенные методики, многим кажется избыточным», — говорит она.

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

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

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

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

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

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

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

Стандарты безопасности нужны как раз для того, чтобы в критической ситуации команда не действовала с нуля. Они задают порядок предотвращения, выявления, локализации, минимизации ущерба и восстановления. Когда этот порядок не описан и не отрепетирован, инцидент превращается в набор несогласованных действий: ИТ отключает одно, ИБ просит другое, юристы ждут факты, PR не понимает, что можно говорить, руководство получает фрагменты информации.

Кадровый фактор усиливает разрыв. На рынке по-прежнему не хватает сильных руководителей ИБ, которые могут перевести киберриски на язык бизнеса и объяснить топ-менеджменту, почему стандарт, аудит или учение нужны не для галочки. Там, где такого диалога нет, кибербезопасность остается внутренним вопросом ИТ- или ИБ-службы, а не управленческой темой.

При этом универсальный стандарт, скопированный у другой компании, редко дает нужный результат. У каждой отрасли своя модель угроз, критичные активы, требования к доступности и регуляторные ограничения. Документ, написанный «навсегда», быстро устаревает. Меняются угрозы, появляются новые сервисы, подрядчики, облака, каналы удаленного доступа и сценарии работы с данными. Поэтому стандарт должен пересматриваться, а не жить в архиве после утверждения.

Директор по развитию UDV Group Максим Хараск считает, что базовые ИБ-стандарты есть больше чем у пятой части компаний, но со сценариями реагирования и восстановления ситуация сложнее. Многие организации пока только вырабатывают соответствующие методики. «Развитие ИБ-системы обычно происходит эволюционно», — говорит он.

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

По словам Хараска, эти процессы логично выстраивать параллельно. Средства защиты, мониторинг, сценарии реагирования и планы восстановления должны появляться в связке. Компания должна понимать не только как снизить вероятность атаки, но и как действовать, если она все же произошла: кто принимает решения, какие сервисы отключаются, как сохраняются доказательства, откуда восстанавливаются данные, кто общается с регуляторами и клиентами.

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

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

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