стратегия
Чтобы внедрять в организации эффективные программы ИБ и сохранять глубокую вовлеченность ИБ-команды во все бизнес-процессы, ее руководитель должен регулярно показывать ценность этой работы высшему руководству. Для этого нужно говорить на языке бизнеса, но тех, кто искренне старается это делать, ждет опасная ловушка. ИБ-специалисты и высшее руководство используют одно и то же слово, но понимают под ним совершенно разные вещи. Иногда несколько схожих терминов используются как взаимозаменяемые. В результате топ-менеджмент не понимает, от каких угроз ИБ-команда старается защитить организацию, каков уровень киберустойчивости компании, во что будут вкладываться деньги и другие ресурсы. Поэтому, перед тем как демонстрировать эффектные дашборды и считать ROI ИБ-программ, стоит ненавязчиво проговорить важные терминологические нюансы.
Наведя в них порядок и сформировав общий словарь, CISO и совет директоров значительно улучшат свои коммуникации и в конечном счете повысят защищенность организации.
Почему словарь кибербезопасности важен для руководства
Разная трактовка терминов — это не просто неудобство, последствия могут быть весьма существенны. Непонимание деталей может приводить к:
- Ошибкам распределения инвестиций. Руководство может одобрить покупку решения zero trust, не понимая, что это лишь часть долгосрочной комплексной программы со значительно большим бюджетом. Деньги потрачены, но ожидаемые руководством результаты не достигнуты. Или при миграции в облако руководство посчитает, что это автоматически означает передачу всей ответственности за безопасность провайдеру, и отклонит бюджет на обеспечение мер облачной ИБ.
- Принятию рисков вслепую. Руководители бизнес-подразделений могут принимать риски ИБ, не имея полного представления об их потенциальном воздействии.
- Дефициту управления. Не понимая терминологии, руководство не может задавать правильные, «неудобные» вопросы и адекватно распределять зоны ответственности. Когда случается инцидент, выясняется, что бизнес-заказчики считали, что защита была целиком в зоне ответственности CISO, а CISO не имел полномочий влиять на бизнес-процессы.
Киберриски и ИТ-риски
Многие руководители полагают, что кибербезопасность — это сугубо техническая проблема, которую можно «делегировать в ИТ-отдел». Даже несмотря на то что важность ИБ для бизнеса бесспорна и киберинциденты давно считаются топовым бизнес-риском, опросы показывают, что многие организации до сих пор не вовлекают в обсуждение ИБ-вопросов нетехнических руководителей.
Риски ИБ часто ставят в один ряд с вопросами ИТ: временем безотказной работы и доступностью сервисов. В реальности киберриск — это стратегический бизнес-риск, связанный с непрерывностью бизнеса, финансовыми потерями и ущербом для репутации.
ИТ-риски, как правило, носят операционный характер и затрагивают вопросы эффективности, надежности и управления стоимостью. Реагирование на инциденты ИТ зачастую целиком проводится сотрудниками отдела ИТ. Крупные инциденты ИБ имеют значительно больший масштаб, требуют вовлечения практически всех подразделений и оказывают долгосрочный эффект на организацию, включая регуляторный и имиджевый аспект, взаимоотношения с клиентами и финансовое состояние.
Регуляторное соответствие и безопасность
Кибербезопасность входит в регуляторные требования всех уровней — от международных, наподобие директивы NIS2 и GDPR, или межнациональных индустриальных руководств (PCI DSS) до ведомственных. В результате руководство компании часто склоняется к восприятию мер ИБ как «галочек в отчете» (compliance checkboxes) и считает, что с достижением регуляторного соответствия вопросы ИБ можно считать решенными. Причиной тому может быть как сознательная минимизация затрат на ИБ («делаем не больше, чем от нас требуют»), так и искреннее заблуждение («мы прошли аудит по ISO 27001, значит, нас невозможно взломать»(.
В реальности compliance — это соответствие минимальным требованиям аудиторов и госрегуляторов, зафиксированное в конкретный момент времени. К сожалению, опыт масштабных кибератак на крупные организации доказывает, что минимальные требования названы так не зря и для реальной защищенности от актуальных киберугроз необходимо непрерывно совершенствовать стратегию защиты и меры ИБ с учетом специфики конкретной индустрии.
Угроза, уязвимость и риск
Эти три слова часто используют как синонимы, что приводит к ошибочным выводам руководства: «У нас на сервере критическая уязвимость? Значит, у нас критический риск!» Чтобы избежать паники или, наоборот, бездействия, важно использовать эти термины точно и понимать их взаимосвязь.
Уязвимость (Vulnerability) — это слабое место, «открытая дверь». Это может быть дефект в программном коде, ошибочные настройки сервера, незапертая серверная или сотрудник, который открывает любые вложения в письмах.
Угроза (Threat) — это потенциальная причина инцидента. Это может быть потенциальный злоумышленник, вредоносная программа или даже стихийное бедствие. Угроза — это то, что может «войти в открытую дверь».
Риск (Risk) — это вероятный убыток. Это совокупная оценка того, какова вероятность успешной атаки и что организация потеряет в итоге (последствия, impact).
Связь между ними лучше всего объяснять простой формулой:
Риск = (Угроза × Уязвимость) × Последствия
Для наглядности можно описать такую ситуацию: в устаревшей системе обнаружена критическая уязвимость с максимальным рейтингом опасности. Но система отключена от коммуникаций, находится в изолированном помещении, с ней работают только три проверенных сотрудника. Вероятность, что злоумышленник доберется до нее, почти нулевая. В то же время отсутствие двухфакторной аутентификации в системах, которыми пользуется бухгалтерия, создает реальный высокий риск, складывающийся из высокой вероятности атаки и значительного потенциального ущерба.
Реагирование на инциденты, восстановление после чрезвычайной ситуации и обеспечивание непрерывности бизнеса
Восприятие кризисных ситуаций ИБ у руководства часто упрощено: «Если нас атакует вымогатель, мы просто запустим план восстановления ИТ (Disaster Recovery) — развернем бэкапы». Однако смешение этих понятий (и процессов) крайте опасно.
Реагирование на инциденты (Incident Response, IR) — это задача ИБ или специализированных подрядчиков. Они должны локализовать угрозу, выгнать злоумышленника из сети, остановить распространение атаки.
Восстановление (Disaster Recovery, DR) — это техническая задача ИТ. Это процесс восстановления серверов и данных из резервных копий после того, как проведено реагирование.
Непрерывность бизнеса (Business Continuity, BC) — это стратегическая задача топ-менеджмента. Это план, как компания продолжает обслуживать клиентов, отгружать товары, платить зарплату и общаться с прессой в то время, когда основные системы еще неработоспособны.
Если руководство фокусируется только на восстановлении, у компании не будет плана действий на самый сложный период простоя.
Осведомленность в области ИБ и культура безопасности
Руководители всех уровней порой думают, что факт проведения ИБ-тренингов гарантирует результат. «Сотрудники прошли ежегодный тест, значит, они не нажмут на фишинговую ссылку». К сожалению, одними тренингами, которые проводят HR и ИБ, обойтись не получится — для эффективности нужно менять поведение команды, а тут не обойтись без вовлечения бизнес-руководства.
Осведомленность (Security Awareness) — это знание. Сотрудник знает, что такое фишинг и сложные пароли.
Культура безопасности (Security Culture) — это паттерны поведения. Это то, что сотрудник делает в стрессовой ситуации или когда за ним никто не наблюдает. Культура формируется не тестами, а средой, где безопасно сообщать об ошибках и выработан обычай отмечать и предотвращать потенциально опасные ситуации на работе. Если сотрудник боится наказания, он скроет инцидент. Если культура здоровая — он сообщит в SOC о странном письме или сам поговорит с коллегой, который постоянно забывает блокировать компьютер, став, таким образом, активным звеном защиты.
Обнаружение и предотвращение
Бизнес-руководители часто мыслят устаревшими категориями «крепостной стены». «Мы купили дорогие системы защиты, значит, нас не должны взломать. Если инцидент произошел — значит, CISO не справился». На практике предотвратить 100% атак невозможно технически и заградительно дорого экономически. Современная стратегия строится на балансе между безопасностью и бизнес-эффективностью. В сбалансированной системе совместно работают компоненты, направленные на обнаружение угроз и на их предотвращение.
Предотвращение (Prevention) отсекает массовые, автоматизированные атаки.
Обнаружение и реагирование (Detection and Response) помогают обнаружить и обезвредить более профессиональные и таргетированные атаки, которые смогли обойти инструменты предотвращения или проэксплуатировать уязвимости.
Ключевая задача ИБ-команды сегодня — не в том, чтобы гарантировать полную неуязвимость, а в том, чтобы обнаружить атаку на ранней стадии и минимизировать ущерб для бизнеса. Для измерения успехов здесь обычно используют метрики «среднее время обнаружения» (MTTD) и «среднее время реагирования» (MTTR).
Философия zero trust и продукт zero trust
Концепция zero trust, подразумевающая «недоверие по умолчанию» для всех компонентов ИТ-инфраструктуры, давно признана актуальной и полезной в корпоративной ИБ. Она требует постоянной проверки identity (учетных записей пользователей, устройств и сервисов) и контекста для каждого запроса доступа, исходя из допущения, что сеть уже скомпрометирована.
Но наличие слов «zero trust» в названии того или иного ИБ-решения не означает, что организация может в одночасье внедрить этот подход, просто купив такой продукт.
Zero trust — это не продукт, который можно «включить», а архитектурная стратегия и долгий путь трансформации. Внедрение zero trust требует перестройки процессов доступа, доработки ИТ-систем для постоянной верификации личности и устройств. Покупка ПО без изменения процессов не приведет к существенному эффекту.
Безопасность облака и безопасность в облаке
При миграции ИТ-сервисов в облачную инфраструктуру (AWS, Yandex Cloud и др.) часто возникает иллюзия полной передачи рисков: «Мы платим провайдеру, теперь безопасность — его головная боль». Это опасное заблуждение и ошибочное восприятие так называемой модели разделенной ответственности (Shared Responsibility Model).
Безопасность облака (Security of the Cloud) — это ответственность провайдера. Он охраняет дата-центры, серверы и физические кабели.
Безопасность в облаке (Security in the Cloud) — это ответственность клиента.
Обсуждение бюджетов на «облачные» проекты и их ИБ-аспект лучше сопровождать конкретными примерами. Провайдер защищает базу данных от доступа посторонних в соответствии с настройками, указанными сотрудниками. Если сотрудники оставят базу данных открытой или используют слабые пароли, если не будет включена двухфакторная аутентификация для доступа к панели администратора — провайдер не защитит от скачивания информации посторонними (очень частый сюжет в новостях, увы). Поэтому бюджет на подобные проекты должен учитывать инструменты облачной безопасности и контроля конфигураций на стороне самой компании.
Сканирование уязвимостей и пентест
Руководители часто путают автоматическую проверку, относящуюся к «гигиеническим» мерам ИБ, с проверкой ИТ-активов на устойчивость к сложным атакам: «Зачем платить хакерам за пентест, если мы каждую неделю запускаем сканер?»
Сканирование уязвимостей (Vulnerability Scanning) проверяет конкретный список ИТ-активов на наличие известных уязвимостей. Проще говоря, это похоже на обход сторожа, который проверяет, закрыты ли окна и двери в офисе.
Тестирование на проникновение (Penetration Test, Pentest) — это проверка, выполняемая специалистом вручную, чтобы оценить возможности реального вторжения в систему с помощью эксплуатации уязвимостей. Продолжая аналогию, это похоже на наем эксперта-взломщика, который пытается реально проникнуть в офис.
Одно не заменяет другое, для понимания реальной защищенности бизнесу нужны оба инструмента.
Управляемые активы и поверхность атаки
Распространенное и опасное заблуждение касается охвата защиты и общей видимости, которая есть у ИТ и ИБ. На совещании можно услышать: «У нас точный инвентарный список техники. Мы защищаем все, что у нас есть».
Управляемые активы (Managed IT Assets) — это то, что отдел ИТ купил, настроил и видит в своих отчетах.
Поверхность атаки (Attack Surface) — это все, что доступно злоумышленникам, все, что может стать точкой входа в компанию. Сюда входят «теневые ИТ» (Shadow IT) — облачные сервисы, личные мессенджеры, тестовые серверы, — все, что сотрудники запустили сами, в обход регламентов, чтобы ускорить или упростить работу. Зачастую именно эти «невидимые» для компании активы становятся точкой входа для атаки, потому что ИБ не может защитить то, о существовании чего не знает.
Советы