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

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

Аналогичная ситуация возникает с DLP, PAM, EDR и другими классами решений. Формально средство защиты может быть внедрено, но реальный эффект зависит от того, насколько качественно вокруг него выстроена эксплуатация.

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

Контур Эгида — комплекс решений информационной безопасности, помогающий защитить бизнес от внутренних угроз.

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

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

Уже на этой основе можно определять необходимые меры защиты и распределять ресурсы ИБ. Регуляторные требования при этом остаются обязательными, но сами по себе не заменяют анализа рисков.

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

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

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

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

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

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

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

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

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

Есть старый афоризм: автоматизация хаоса дает автоматизированный хаос. В ИБ он по-прежнему работает.

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

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

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

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

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

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

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

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

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

Представим ситуацию. Компания внедряет SIEM, DLP и NGFW и пытается связать их большим количеством правил и корреляций. На схеме такая архитектура может выглядеть убедительно.

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

Если нужно приблизительно оценить ситуацию за день, можно начать с нескольких вопросов:

1. Понимаем ли мы, какие бизнес-процессы, системы и данные для нас действительно критичны?
2. Знаем ли основные сценарии, которые могут привести к их компрометации или остановке?
3. Понятно ли, кто отвечает за эксплуатацию каждого критичного средства и процесса защиты?
4. Обрабатываем ли мы данные и события, которые уже собирают наши системы?
5. Регулярно ли пересматриваются доступы, политики, сценарии обнаружения и настройки защиты?
6. Проверяем ли мы на практике способность восстановиться и отреагировать на серьезный инцидент?
7. Понимает ли руководство, какие существенные риски остаются незакрытыми и почему?

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

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

_{16+. Реклама. АО «ПФ «СКБ Контур». ОГРН 1026605606620. 620144, Екатеринбург, ул. Народной Воли, 19А.}