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

У большинства российских компаний среднего и крупного бизнеса кибербезопасность по-прежнему развивается не как управляемая система, а как набор отдельных мер.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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