Эффективное управление уязвимостями: как ИТ договориться с ИБ

Выстроить процесс управления уязвимостями невозможно, если не достичь баланса между мерами по безопасности и рабочей эффективностью. Почему в формировании процесса VM (Vulnerability Management) должны принимать участие разные подразделения компании, зачем определять риск-рейтинг активов, как достигнуть договорённостей с ИТ-отделом?

1. Введение
2. Подключение ИБ на старте проекта
3. Строим процесс управления уязвимостями
4. Роли подразделений в процессе VM
5. Как определить сроки обновления систем
6. Формируем риск-рейтинг активов
7. Устанавливаем регламенты
8. Нужно ли пересматривать сроки регламентов
9. Договорённости с ИТ-подразделением
10. Выводы

Введение

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

Информационная безопасность (ИБ) — это security, информационные технологии (ИТ) — safety. Оба направления конкурируют за ресурсы внутри одной компании, и это, к сожалению, — привычное дело. Хотя должно быть наоборот: ИТ и ИБ нужны для того, чтобы бизнес работал. ИТ-подразделение обеспечивает доступность и работоспособность сервисов, отдел ИБ усложняет жизнь злоумышленнику, не даёт ему спровоцировать события, которые компания определила как недопустимые.

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

Мы ориентировались на многолетний опыт работы центра PT Expert Security по мониторингу, расследованиям инцидентов и реагированию на них, а также на результаты сотен пентестов, проведённых нашей командой PT Swarm.

Подключение ИБ на старте проекта

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

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

Строим процесс управления уязвимостями

Готовой системе нужен процесс управления уязвимостями (Vulnerability Management, VM), а чтобы он действительно заработал, необходима синергия ИТ, ИБ и бизнеса. Действовать нужно сообща и в определённой последовательности.

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

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

Шаг 3. Составляем регламент для каждого типа активов: обсуждаем его с бизнесом, договариваемся с ИТ-отделом.

Роли подразделений в процессе VM

Каждое из подразделений — «винтик» в процессе управления уязвимостями.

Таблица 1. Задачи подразделений в процессе управления уязвимостями

Рассмотрим подробнее, в чём заключается роль каждого из подразделений.

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

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

• Целевые активы — конечная точка, куда стремится хакер. Это могут быть:
  • сервер СУБД с персональными данными клиентов организации;
  • сервер с информацией о финансовой отчётности и планами развития организации;
  • автоматизированная банковская система.

• Точки проникновения — активы доступные изо внешних сетей. Это — отправные пункты злоумышленника на пути к реализации риска:
  • серверы со внешними сетевыми интерфейсами;
  • веб-приложения по периметру сети;
  • рабочие станции с доступом в интернет;
  • системы подключённые к беспроводным сетям.

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

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

3. ИТ-подразделение. Отвечает за работоспособность систем, в большинстве случаев устраняет уязвимости с помощью регулярных обновлений. Задача ИТ-подразделения — следить, чтобы обновления устанавливались с учётом расписания для каждого типа актива и в рамках согласованных сроков (SLA).

Рисунок 1. Роли подразделений в процессе VM

Как определить сроки обновления систем

Постулат № 1: нельзя контролировать то, чего не видишь.

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

Постулат № 2. Безопасность нельзя рассматривать в отрыве от бизнеса.

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

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

Формируем риск-рейтинг активов

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

Целевые системы может назвать только бизнес, но активы, которые, скорее всего, относятся ко ключевым системам, покажет система управления уязвимостями. У нас в продукте MaxPatrol VM есть системные запросы, которые предлагают общие подходы для оценки значимости активов. Мы можем подсказать, какие инфраструктурные части нужно выделить: к примеру, будет объективно плохо, если кто-то сможет взломать контроллер домена. Это — явно высокозначимый актив во всех системах, кроме тестовой среды.

Устанавливаем регламенты

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

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

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

Примеры параметров, которые помогают определить SLA:

• риск-рейтинг активов;
• технологические окна;
• требования по доступности активов;
• требования по версионности.

Нужно ли пересматривать сроки регламентов

Для каждой группы активов надо определить, как часто ИТ-специалисты могут что-то обновлять. В случае с Windows всё просто: раз в месяц, если ничего критически важного не выходит, Microsoft публикует обновления. ИТ-подразделения берут тайм-аут на неделю для тестирования важных систем или, например, две недели для тестирования и «раскатывания» на офисные машины. Тогда этот срок фиксируется: в течение 14 дней версии должны быть обновлены. Если дальше в процессе эксплуатации мы видим, что не получится соблюсти эти сроки, то нужно поменять договорённости, чтобы не было просрочек.

Невозможно задать единые для всех регламенты обновления систем. К примеру, в банкоматах как использовалась Windows Embedded, так и будет использоваться в ближайшие пять лет, и никуда от этого не денешься. Но с банкоматами работают не все организации, поэтому дать единые рекомендации сложно. Главное — ежеквартально проверять, как выполняются существующие договорённости. Если отклонения происходят регулярно, нужно разбираться почему. Для этого в MaxPatrol VM есть встроенные отчёты, которые позволяют оценивать эффективность зафиксированных регламентов и проверять отклонения.

Сроки определяются путём долгих переговоров, других вариантов нет.

В качестве показателей эффективности процесса VM мы можем рассматривать:

• процент покрытия ИТ-инфраструктуры целевыми, ключевыми, периметровыми активами;
• процент нарушений установленных сроков (SLA) по устранению уязвимостей;
• процент охвата политик по устранению уязвимостей (для различных типов активов).

Договорённости с ИТ-подразделением

Постулат № 3. Патчить нужно всё.

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

Дополнительная польза для ИТ-служб от отслеживания обновлений — скорость реакции. Когда обнаружится что-то действительно опасное, а в компании, например, «зоопарк» версий СУБД, то вы никогда не успеете всё это быстро обновить. Поэтому надо иметь минимальное возможное число рабочих версий, которые можно постоянно и синхронно «накатывать» силами ИТ.

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

Выводы

Для качественного управления уязвимостями важно:

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

Авторы:

Евгений Полян, менеджер продукта MaxPatrol VM в Positive Technologies;

Анастасия Зуева, менеджер по продуктовому маркетингу Positive Technologies