Light mode

Переосмысляем ИБ-продукты в терминах результата

6 минут
  • #РКБ

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

Нас учили, что безопасность — это процесс, но не говорили, что у безопасности должен быть результат.

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

Кто виноват несет ответственность?

Современная ИБ-парадигма держится на трех китах (читай — запросах). Первый — запрос на человеко-дни ИБ-специалистов. В этом случае исполнитель — вендор или интегратор — просто предоставляет клиенту экспертов для решения задачи и не несет ответственности за реальное повышение уровня защищенности компании.

Второй запрос — реализация базовых функций защиты. К сожалению, зачастую внедрение и интеграция ИБ-инструментов осуществляются исключительно ради формального соответствия техническому заданию и прохождению приемочных испытаний — без оглядки на реальную эффективность и практическую пользу. «Обеспечьте нам связь между площадками через VPN, а что будет в туннеле — не ваше дело». Растет ли при этом практическая защищенность клиента? Вряд ли.

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

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

Контракт, ориентированный на результат

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

  1. Сформулировать понятный и измеримый результат. Клиент (самостоятельно или с ИБ-партнером) должен четко описать, чего именно он ждет от конкретного проекта и его участников.
  2. Определить качественные и количественные метрики достижения и удержания результата. Это может быть своего рода SLA на результат, где четко описаны условия, при которых система ИБ или отдельный продукт находится в результативном состоянии.
  3. Установить требования, критерии и методику оценки непрерывности обеспечения результата. Нужно уходить от привычных, но морально устаревших технических заданий: как правило, они оторваны от практической безопасности и не отражают реальных потребностей заказчика в защите.
  4. Подготовить инфраструктуру, выбрать продукты и определить процессы. Будем честны: не всех важных для бизнеса результатов получится достичь с имеющейся инфраструктурой и/или процессами. Результативная кибербезопасность должна строиться на безопасной ИТ-инфраструктуре: с микросегментацией, описанными и внедренными ролями и полномочиями учетных записей, контролем подключения новых устройств, настроенными механизмами ИБ и т. д.
  5. Детализировать, внедрить и автоматизировать процессы. Отработать первое достижение результата. Чтобы добиться первого результата в новой парадигме, потребуется сплоченная работа специалистов из смежных подразделений. Важно, чтобы подобные проекты поддерживал топ-менеджмент компании.
  6. Непрерывно удерживать результат, оценивать заявленные метрики и управлять изменениями. Помните, что ответственность за удержание результата лежит не только на клиенте, но и на всех участниках проекта, будь то производитель ИБ-продукта, сервис-провайдер или интегратор, обеспечивающий поддержку и сопровождение. Определите и выразите ответственность за результат соразмерно вовлеченности всех сторон. При этом могут быть предусмотрены как штрафы за отклонение от результата, так и поощрения за его удержание в рамках согласованного SLA.

Новые требования к старым решениям

Приведем несколько примеров требований, которые можно (и нужно) предъявлять к проектам по внедрению ИБ-продуктов в терминах результата.

Класс ИБ-решенияКлассические требования к проектуТребования к проекту в терминах результата
Сканер уязвимостейИнвентаризация активов, выявление уязвимостей, приоритизация и контроль устранения уязвимостейОтсутствие трендовых уязвимостей на периметре и в ключевых активах, отсутствие shadow IT в критически значимых сегментах сети и небезопасных конфигураций в сервисах и приложениях
EDRСбор информации с хостов, обнаружение угроз, реагирование на инцидентыМгновенная остановка вредоносных действий на хостах, минимизация затрат на восстановление хостов после атак
SandboxПолучение файлов по различным каналам, анализ на предмет наличия ВПО, имитация среды исполнения или «обманок» для злоумышленниковБлокировка распространения ВПО до попадания на хосты, отсутствие APT-атак в инфраструктуре, отсутствие утечек конфиденциальных данных
Табл. 1. Примеры требований к ИБ-решениям в терминах результата

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

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

Как определить метрики

Чтобы описать все возможные метрики для разных ИБ-решений, понадобится несколько выпусков Positive Research, поэтому остановимся на одном — сканерах уязвимостей. Подойти к снаряду можно несколькими способами.

Во-первых, метрики могут опираться на статистику реальных атак. Например, согласно отчету Palo Alto Networks хакеры начинают сканировать инфраструктуру организации уже через 15 минут после появления информации об уязвимости в базе CVE. Т.е. можно использовать в качестве метрики показатель «15 минут».

Второй вариант — ориентироваться на характеристики, которые производители закладывают в свои ИБ-продукты. Мы в MaxPatrol VM, к примеру, гарантируем доставку информации о трендовых уязвимостях в течение 12 часов. Соответственно, можно зафиксировать «12 часов» в качестве метрики.

Еще одной отправной точкой может стать методический документ ФСТЭК России от 17.05.23. В нем указаны следующие рекомендуемые сроки устранения уязвимостей:

  • критический уровень опасности — до 24 часов;
  • высокий уровень — до 7 дней;
  • средний уровень — до 4 недель;
  • низкий уровень — до 4 месяцев.

При формировании результативных метрик ИБ рекомендуем:

  • обращать внимание на статистику реальных атак;
  • следить, чтобы метрики не были ниже показателей, указанных в нормативных документах (если они существуют и применимы к вашей организации).

Достижение и удержание результата

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

  1. Определение и приоритизация активов. Выделите область, в которой требуется достижение результата, а затем приоритизируйте содержащиеся в ней активы. Вы должны четко понимать их принадлежность к информационным системам и бизнес-процессам компании.
  2. Планирование и дизайн процессов. На этом этапе важно определить верхнеуровневый дизайн процессов для достижения результата и сформировать команду, включающую специалистов из всех вовлеченных подразделений.
  3. Проектирование систем и описание процессов. Сформулируйте требования к средствам автоматизации, которые позволят реализовать процессы с заданными метриками. Подготовьте проектную документацию на внедряемые системы и детализируйте процессы.
  4. Поставка, модернизация, пусконаладка. Сюда входят технические работы: приобретение средств защиты, интеграция с другими ИС, модернизация имеющихся решений для достижения установленных метрик и т. д.
  5. Подготовка персонала и ввод в действие средств автоматизации. Здесь важно работать с командой и активно погружать сотрудников, ответственных за результат, в процесс работы со средствами автоматизации.
  6. Достижение первого результата. Ура, все получилось! Теперь нужно отработать процессы, оценить и зафиксировать узкие места, вычислить фактические показатели (насколько они отличаются от заявленных метрик) и обработать фидбэк от команды.

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

Требования к результату работы ИБ должны быть одновременно громкими и ясными. Они должны стать вызовом для всей организации.

***

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

Мы дěлаем Positive Research → для ИБ-экспертов, бизнеса и всех, кто интересуется ✽ {кибербезопасностью}