Чек-лист: как управлять уязвимостями и подружить департаменты ИT и ИБ в финансовых организациях

Чек-лист: как управлять уязвимостями и подружить департаменты ИT и ИБ в финансовых организациях

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

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

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

ЗАЧЕМ УПРАВЛЯТЬ УЯЗВИМОСТЯМИ

Согласно нашему исследованию, если рассматривать последствия атак, то финансовые организации чаще всего сталкивались с кражей конфиденциальных данных (53%) и остановкой бизнес-процессов (41%), 6% компаний понесли непосредственные денежные потери. В 6% случаев злоумышленники использовали ресурсы финансовой организации для проведения дальнейших атак на клиентов и другие предприятия.

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

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

• выводу денежных средств свыше определённой суммы со счетов финансовой организации или её клиентов;
• приостановке операционных процессов компании из-за недоступности её информационных систем;
• утечке баз данных с персональными данными клиентов.

По этой причине важно организовать процесс VM и скоординировать специалистов из департаментов ИБ и ИТ.

ПОДКЛЮЧИТЕ СПЕЦИАЛИСТА ПО ИБ

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

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

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

СДЕЛАЙТЕ ТРИ ШАГА

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

Шаг 1. Определите перечень недопустимых для организации событий — обязательно вместе с бизнес-подразделением, в том числе с владельцами компании и топ-менеджментом. Таких событий не должно быть много (иначе защита сведётся к попыткам объять необъятное): их количество, как правило, не должно превышать пяти.

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

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

ЗАФИКСИРУЙТЕ РОЛИ ПОДРАЗДЕЛЕНИЙ

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

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

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

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

­­­Рисунок 1. Схема взаимодействия бизнеса, отделов ИТ и ИБ в процессе управления уязвимостями

ОПРЕДЕЛИТЕ СРОКИ ОБНОВЛЕНИЯ СИСТЕМ

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

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

Указать на активы, скорее всего относящиеся к ключевым (такие как контроллер домена), поможет система управления уязвимостями. Например, в MaxPatrol VM существуют специальные запросы, которые позволяют выделить важные категории активов и расставить их по уровню значимости (вручную или с помощью политик).

Рисунок 2. Пример запроса на присвоение уровня значимости активам

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

Сроки обновлений определяются путём долгих согласований. Так, спланировать обновление Windows на рабочих станциях достаточно просто (в отличие от, допустим, встраиваемых ОС в банкоматах): Microsoft публикует патчи, как правило, раз в месяц. Двух недель на тестирование и «раскатывание» систем в большинстве случаев должно хватить. Просрочки в регламенте необходимо фиксировать, разбираться в причинах и при необходимости менять договорённости о сроках. Эффективность закреплённых регламентов можно анализировать во встроенных отчётах MaxPatrol VM.

В условиях сложившейся в 2022 году ситуации остро стоит вопрос обновления зарубежного ПО. Повышаются риски внедрения недокументированных возможностей и нежелательного контента в продукты для российских пользователей. Регуляторы рекомендуют отключить автоматическое обновление ПО, но без регулярного обновления в программах будут появляться новые уязвимости, в том числе критически опасные. Специалисты по информационной безопасности должны решить, обновлять ПО, рискуя получить недокументированные возможности, или не обновлять и получить уязвимости. Национальный координационный центр по компьютерным инцидентам (НКЦКИ) опубликовал алгоритм, который может помочь решить эту дилемму.

В тестовом режиме на сайте БДУ ФСТЭК России работает раздел с результатами тестирования обновлений ПО. В нём эксперты предоставляют рекомендации после проверки вышедших обновлений и выносят вердикт по выявлению их негативного влияния на инфраструктуру. Чтобы принять решение об установке патча, можно общаться к этим указаниям.

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

НАСТРОЙТЕ РЕГЛАМЕНТ ОБНОВЛЕНИЙ

Если специалист по ИБ придёт к ИТ-службе с огромным списком уязвимостей без какой-либо их приоритизации, это не даст эффекта. В списке должен быть набор узлов и программного обеспечения, которые необходимо обновить в первую очередь, а также сроки выполнения этих действий. Для ИТ-службы есть несомненные плюсы в регулярных обновлениях: при появлении опасной уязвимости не придётся разбираться с множеством разных систем (к примеру, СУБД разных версий) и будет возможность синхронно обновлять ПО для всей инфраструктуры.

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

РЕЗЮМЕ

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

Недавно мы провели опрос, чтобы выяснить, как этот процесс выстроен в разных компаниях. Результаты исследования показали, что 8% специалистов усложняют работу ИТ-отделу: отправляют в подразделение список выявленных уязвимостей без фильтрации и оставляют решение о порядке их устранения за ним же. У 14% компаний обратная ситуация: ИТ-отдел заставляет специалистов по ИБ заводить заявку на каждую обнаруженную уязвимость. При этом 32% ответивших указали, что тратят на задачи VM до 10% рабочего времени.

Проактивный подход в устранении уязвимостей используют 27% респондентов: ИТ-подразделение регулярно устанавливает патчи или обновления ОС и ПО, не дожидаясь информации об уязвимостях от службы ИБ. А 28% специалистов применяют реактивный подход: ИТ-подразделение устанавливает обновления после того, как служба ИБ предоставит информацию об обнаруженных уязвимостях и сформирует списки активов, ОС и ПО для реагирования. Автопатчинг используют 20% ответивших. В текущих реалиях внедрять обновления без тестирования может быть вдвойне рискованнее. Мы считаем, что обоснованно доверить обновление инфраструктуры ИТ-отделу, который может протестировать ПО в защищённой среде, знает особенности поддержки текущей инфраструктуры и отслеживает загрузку сервисов.