IT-инфраструктура организации может меняться довольно динамично. Чтобы не допустить вреда IT-инфраструктуре и бизнес-процессам и чтобы повысить эффективность действий специалистов, проводящих работы по изменению IT-инфраструктуры, в организациях должен функционировать процесс управления изменениями ИТ.
Изменение (согласно ITIL 4) — добавление, видоизменение или удаление чего-либо, что может прямо или косвенно повлиять на IT-сервис.
С точки зрения результативной кибербезопасности изменения — это действия в целевых или ключевых системах, которые могут привести к нарушениям условий безопасного функционирования этих систем.
В организации должны существовать процессы рассмотрения, согласования, проведения и верификации изменений. Если изменение возможно, то оно должно проходить проверку на предмет влияния на информационную безопасность целевых и ключевых систем. Для оценки изменения необходимо определить критерии, при которых изменение должно быть согласовано с точки зрения информационной безопасности.
Поскольку все изменения (в том числе несанкционированные) должны отслеживаться операционным блоком ИБ (ОБИБ), необходимо определить критерии для информирования ОБИБ.
Операционный блок ИБ (ОБИБ) — подразделение организации или специалист, ответственные за мониторинг событий ИБ и расследование киберинцидентов.
Пример изменения, оказывающего влияние на целевую систему
Недопустимое событие: вывод более 3 млн рублей со счета организации.
Целевая система: «банк — клиент».
Изменение в IT-инфраструктуре, существенно снижающее уровень защищенности: открытие прямого доступа из интернета к целевой системе.
Отслеживание изменений в IT-инфраструктуре
Согласно рекомендациям ITIL 4, изменения бывают трех типов.
Рисунок 1. Типы изменений, согласно рекомендациям ITIL 4
Для согласования нормальных и экстренных изменений создаются специальные органы согласования изменений — CAB (Change Advisory Board) и ECAB (Emergency Change Advisory Board).
CAB (по ITIL 3) — группа сотрудников, поддерживающих оценку, определение приоритетов, авторизацию и планирование изменений.
ECAB (по ITIL 3) — подгруппа CAB, принимающая решения в отношении экстренных изменений.
Работы по внесению изменений должны планироваться, и план для каждого изменения должен описывать этапы его проведения. Планом изменения должны быть предусмотрены процедуры тестирования, отката (возвращения в исходное состояние) в случае, если изменение не удалось, и информирования ОБИБ о проводимых изменениях. План изменения также должен проходить экспертизу со стороны функции ИБ, так как может предполагать небезопасные действия.
В организации должны быть определены конфигурационные единицы, изменения в которых могут повлиять на безопасность функционирования целевых и ключевых систем, и критерии изменений, которые обязательно проходят процедуру согласования со стороны ИБ.
Конфигурационная единица (ITIL 4) — любой компонент, которым необходимо управлять для предоставления IT-услуги.
С точки зрения результативной кибербезопасности конфигурационная единица — это любой компонент ключевой или целевой системы, которым необходимо управлять для предоставления IT-услуги.
Примеры критериев и изменений, которые должны проходить экспертизу ИБ, приведены в таблице ниже.
Критерий изменения
Изменения, подходящие под критерий
Изменение сетевого взаимодействия целевой или ключевой системы
1. Открытие порта (TCP 22) на сервере системы «банк — клиент» в интернет. 2. Открытие доступа для администрирования системы «банк — клиент» из пользовательского сегмента
Изменение интеграций целевых систем
1. Интеграция системы «банк — клиент» с ERP-системой. 2. Интеграция ERP-системы с порталом Госуслуг
Изменение параметров настройки встроенных механизмов защиты
1. Отключение антивирусной защиты на сервере системы «банк — клиент». 2. Изменение параметров журналирования событий безопасности на сервере системы «банк — клиент»
Изменения согласовываются функцией ИБ с учетом оценки возможного снижения уровня защищенности. Примеры критериев, по которым изменения снижают уровень защищенности целевой системы:
существенное уменьшение количества действий, необходимых для проведения атаки на целевую систему;
добавление точки проникновения в сегмент сети с ключевой или целевой системой;
отключение встроенных механизмов защиты;
интеграция с менее защищенными системами;
изменение параметров харденинга целевой системы;
потеря управляемости и связи целевой системы с централизованными средствами защиты: отключение функций мониторинга, отключение антивирусной защиты и т. п.
Так как ОБИБ должен отслеживать события безопасности в целевых и ключевых системах, его необходимо информировать обо всех изменениях данных систем.
Примеры критериев изменений, о которых необходимо информировать ОБИБ:
прерывание работы (отключение) централизованных средств защиты;
добавление новых узлов в сегменты сети, в которых функционируют целевые и ключевые системы;
изменение параметров журналирования событий безопасности.
Все изменения в целевых и ключевых системах, о которых не был проинформирован ОБИБ, должны рассматриваться как инциденты ИБ.
Критерии изменений, которые должны проходить экспертизу по ИБ, определяются после утверждения списка целевых и ключевых систем, а также связанных с ними конфигурационных единиц. Сформулированные критерии необходимы для начала работ по оценке изменений с точки зрения ИБ.
Основные шаги для обеспечения должного контроля изменений
Шаг
Описание шага
Шаг 1. Определить все конфигурационные единицы, которые могут повлиять на целевые и ключевые системы
Целевые и ключевые системы могут состоять из множества элементов, которые влияют на безопасность. Такими элементам могут быть: - аппаратное обеспечение: серверы, системы хранения данных, коммуникационное оборудование; - программное обеспечение для виртуализации: гипервизор и файлы виртуальных машин; - системное и прикладное программное обеспечение. Обычно в организации формируется база данных конфигурационных единиц CMDB (Configuration Management Database, база данных управления конфигурацией), которая может быть использована для быстрого получения информации о связанных конфигурационных единицах. Если CMDB не используется, то необходимо провести дополнительный анализ по определению компонентов целевых и ключевых систем
Шаг 2. Определить критерии, по которым изменение будет проходить экспертизу с точки зрения ИБ
В целях своевременной проверки изменения, влияющего на безопасность целевых и ключевых систем, необходимо сформулировать критерии, по которым изменение будет всегда согласовываться с функцией ИБ. Такие критерии должны быть разработаны до вынесения изменения на рассмотрение CAB (Change Advisory Board, комитета по изменениям)
Шаг 3. Определить критерии согласования изменения
Изменение может быть небезопасным, тогда оно должно быть отклонено по одному или нескольким критериям. Критерии отклонения изменения должны быть понятны инициатору изменения. В случае рассмотрения варианта, снижающего защищенность целевой или ключевой системы (например, вынужденное отключение харденинга), должны быть предусмотрены компенсирующие меры защиты
Шаг 4. Определить форматы взаимодействия (представления информации) для согласования изменения
Рассмотрение изменения иногда может быть затруднено ввиду недостатка информации для анализа, поэтому, в целях сокращения количества итераций, форматы взаимодействия между функцией ИТ и функцией ИБ в рамках рассмотрения изменения должны быть согласованы. Например, в случае изменения параметров сети необходимо предоставить изменения в политику межсетевых взаимодействий
Шаг 5. Определить шаги при отклонении изменения
В случае отклонения изменения со стороны функции ИБ должны быть определены шаги по доработке изменения или другому преодолению сложившейся ситуации. Например, решение в таких случаях может принимать генеральный директор или другой топ-менеджер
Процесс управления изменениями в IT-инфраструктуре организации существенно зависит от уровня зрелости IT-процессов. Например, он может подразумевать использование специализированной системы для управления изменениями и для управления конфигурационными единицами, процедурами согласования экстренных, нормальных и стандартных изменений в IT-инфраструктуре — или может вообще не управляться. В последнем случае для достижения результативной кибербезопасности драйвером внедрения процесса управления изменениями должна выступать функция ИБ.
Таким образом, с точки зрения результативной кибербезопасности все изменения в IT-инфраструктуре, способные оказать влияние на защищенность целевых и ключевых систем, должны управляться и быть согласованными.
Пример реализации процесса контроля нормального изменения
На рисунке 2 показан пример упрощенной схемы процесса контроля нормального изменения. В таблице 1 приведено описание шагов процесса. В таблице 2 дано описание контролей по критериям ИБ в шагах процесса изменения.
Рисунок 2. Процесс контроля нормального изменения
Таблица 1. Шаги контроля нормального изменения
№
Шаг
Описание
1
Формирование запроса в специализированной системе или по электронной почте
На данном шаге инициатор изменения подает запрос на обслуживание по принятому в организации каналу (например, через специализированную систему или по электронной почте)
2
Обработка запроса
Все запросы обрабатывает service desk (первая линия технической поддержки). Если запрос связан с изменением, то оно соответствующим образом классифицируется
3
Согласование изменения, назначение координатора изменения
Владелец IT-актива или сервиса или менеджер изменений рассматривает поступившую заявку на изменение и принимает решение о предварительном согласовании заявки и назначении координатора изменения — или отклоняет заявку
4
Составление (доработка) плана изменения
Координатор изменения составляет или дорабатывает план изменения. В случае если изменение подпадает под критерии изменений, которые должны проходить экспертизу по ИБ, координатор направляет план изменения (и, возможно, другие сопроводительные документы) на экспертизу в функцию ИБ
5
Согласование изменения
Функция ИБ рассматривает план изменения и сопроводительную документацию, проводя оценку по критериям снижения уровня информационной безопасности целевой системы
6
Согласование изменения CAB
CAB согласовывает изменение и его план. Представитель функции ИБ должен быть включен в состав CAB
7
Координация работ по проведению изменения
Координатор изменения назначает задачи согласно плану изменения и проводит координацию исполнения плана изменения
8
Исполнение задач по плану изменения
Исполнители изменения исполняют мероприятия, назначенные планом изменения. В план изменения должны входить следующие мероприятия: — информирование ОБИБ о предстоящих изменениях — в случае выявления критериев изменений, о которых необходимо информировать ОБИБ; — тестирование и откат изменения — в случае, если изменение не достигло своих целей
9
Закрытие запроса на изменение
В случае успешного изменения координатор или менеджер изменения закрывают запрос на изменение
10
Откат в исходное состояние
В случае если изменение не достигло своих целей, производится откат изменения
Таблица 2. Контроли по критериям ИБ в шагах процесса изменения
Шаг
Описание контроля по критериям ИБ
4. Составление (доработка) плана изменения
Координатор изменения проводит проверку необходимости согласования плана изменения с функцией ИБ по установленным функцией ИБ критериям
5. Согласование изменения
Функция ИБ согласовывает план изменения и дополнительные материалы по установленным критериям
6. Согласование изменения CAB
Представитель функции ИБ входит в состав CAB и как член CAB участвует в согласовании изменений
8. Исполнение задач по плану изменения
ОБИБ контролирует изменения в IT-инфраструктуре; в случае если ОБИБ не был проинформирован о предстоящем изменении, то данная активность классифицируется как инцидент ИБ
Рекомендации по контролю изменений в IT-инфраструктуре
Артемий Пономарёв
Рисунок 1. Типы изменений, согласно рекомендациям ITIL 4
Рисунок 2. Процесс контроля нормального изменения