Автор: Андрей Дугин, директор центра сервисов кибербезопасности компании МТС RED
Любой бизнес-процесс, который реализован в информационной системе, может быть описан на языке SOC. Если говорить в общем виде, то любой процесс имеет данные на вход, последовательность действий и данные на выход (результат). Все эти этапы имеют свои следы в ИТ-системах. Это значит, что SOC может отслеживать соответствующие логи и выявлять аномалии, то есть фактически вмешательства внутреннего или внешнего злоумышленника в процесс или нарушение его нормального функционирования по иным причинам. Таким образом, SOC может мониторить не только стандартные события информационной безопасности, но и отклонения от нормы в логах, описывающих ход бизнес-процесса. Это позволяет обнаружить и обезвредить на ранней стадии инциденты, не всегда связанные с кибербезопасностью напрямую, но влияющие на бизнес и грозящие ему финансовым ущербом.
В качестве наглядного примера возьмем процесс предоставления сотруднику доступа к информационной системе. В норме процесс имеет следующие этапы:
Аномалии процесса предоставления доступа в информационную систему, которые можно рассматривать как инциденты ИБ, – это, например, получение доступа без оформленной заявки или назначение уровня доступа, не соответствующего запрошенному. Соответственно, правильная последовательность этапов процесса может обрабатываться метриками времени, количества и т.п., а отклонения от нормы будут приравниваться к инцидентам ИБ разной степени критичности.
Возьмем другой пример, значимый для компаний, чей бизнес связан с электронной коммерцией. В 2021 г. человек купил через мобильное приложение ЦУМ 19 наименований товаров ценой от 19 до 129 тыс. руб. В этот день из-за технического сбоя цены на товары в интернет-магазине отражались некорректно – в сотни раз ниже их реальной стоимости. В результате клиент приобрел вещи в 846 раз дешевле, чем магазин готов был их продать. ЦУМ отказался выдать заказ покупателю, и тот подал иск против магазина. Пройдя несколько инстанций, дело было передано в Верховный суд РФ. Он встал на сторону клиента, поскольку в силу действующего законодательства покупатель имеет право на получение товара по цене, заявленной в интернет-заказе.
Если нелегитимное изменение цен на сайте или в мобильном приложении ретейлера было связано не со взломом, а, скажем, с действиями сотрудника магазина, SOC не смог бы выявить инцидент. Однако если бы изменение цен на сайте и в мобильном приложении было заведено в мониторинг как бизнес-процесс, SOC бы своевременно уведомил об изменении цены на сайте без предшествующих в норме действий в информационных системах. В этом примере "красным флагом" могло стать отсутствие задокументированного в ИТ-системах прохождения этапов согласования снижения цен, подозрительный IP-адрес хоста, который инициирует изменения, или изменение цен пользователем, не указанным в описании бизнес-процесса.
Для того чтобы завести бизнес-процесс на контроль в SOC, необходимо соблюдать несколько условий. Прежде всего процесс должен быть прогнозируемым и систематизируемым, то есть всегда включать одни и те же этапы в одной и той же последовательности. К таким процессам относятся, например, закупочные процедуры. Разумеется, SOC может контролировать только те этапы бизнес-процессов, которые отражаются в информационных системах и генерируют логи достаточной полноты и интерпретируемости. Очень сложно с высокой точностью определять, что является инцидентом ИБ бизнес-процесса в SOC, если не все информационные системы, задействованные в процессе, логируют действия на необходимом уровне.
Если эти условия соблюдаются, необходимо описать для аналитиков SOC все особенности процесса, признаки нормы и аномалий. После этого можно будет сгенерировать тестовые шаги нормы и аномалий, которые рассматриваются как инциденты ИБ.
Основная сложность состоит в том, что при контроле бизнес-процессов с помощью SOC огромная часть логов собирается на уровне приложений. Выполнять интеграцию "из коробки" для всего существующего ПО в корпоративном сегменте производителю проблематично, поэтому интеграционные модули готовятся, исходя из популярности тех или иных приложений в корпоративном секторе либо по запросу крупных заказчиков. Остальное придется выполнять MSSP-провайдеру, интегратору или самостоятельно заказчику.
Интегрировать приложения с SIEM не сложно, если оно дает логи разумной полноты и синтаксиса на каждый тип событий, который можно использовать для определения признака инцидента ИБ.
Генерируемые на каждом уровне события необходимо собирать, хранить и обрабатывать. Обработка событий представляет из себя разнообразные действия, от фильтрации и парсинга до применения метрик и алгоритмов корреляции. При этом метрики могут по сложности варьироваться от банального подсчета интенсивности генерируемых событий до выведения интегральных показателей уровня защищенности компании. Алгоритмы так же разнообразны, в зависимости от задач и используемых технологий, начиная с grep pattern и заканчивая ретроспективным анализом, предиктивной аналитикой и т. п.
Помимо метода сбора информации в SIEM, важно определить частоту проверки, уровень критичности для тех или иных аномалий, который будут считаться инцидентом, круг лиц, оповещаемых об инциденте, и каналы коммуникации с ними.
Результаты применения метрик и алгоритмов к собираемым данным формируют показатели либо инциденты ИБ, которые дают специалистам и руководству основания для принятия решений.
Таким образом, если есть необходимость контролировать тот или иной бизнес-процесс, SOC с высокой вероятностью сможет это сделать, если предоставить аналитикам описание процесса, его реализацию в информационных системах, соответствующее логирование и требования к генерации инцидентов ИБ – описание легитимный показателей и аномалий.
Кибербезопасность – это в первую очередь функция бизнеса, обеспечивающая его непрерывность и защиту от финансового или репутационного ущерба, который могут нанести кибератаки. Поэтому и SOC должен мыслить категориями бизнеса и расширять свою сферу контроля от защиты непосредственно ИТ-инфраструктуры до защиты критически важных бизнес-процессов.