Контакты
Подписка 2024

SOC для защиты бизнес-процессов

Андрей Дугин, 01/12/23

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

Автор: Андрей Дугин, директор центра сервисов кибербезопасности компании МТС RED

Контроль безопасности бизнес-процессов с помощью SOC

Любой бизнес-процесс, который реализован в информационной системе, может быть описан на языке SOC. Если говорить в общем виде, то любой процесс имеет данные на вход, последовательность действий и данные на выход (результат). Все эти этапы имеют свои следы в ИТ-системах. Это значит, что SOC может отслеживать соответствующие логи и выявлять аномалии, то есть фактически вмешательства внутреннего или внешнего злоумышленника в процесс или нарушение его нормального функционирования по иным причинам. Таким образом, SOC может мониторить не только стандартные события информационной безопасности, но и отклонения от нормы в логах, описывающих ход бизнес-процесса. Это позволяет обнаружить и обезвредить на ранней стадии инциденты, не всегда связанные с кибербезопасностью напрямую, но влияющие на бизнес и грозящие ему финансовым ущербом.

В качестве наглядного примера возьмем процесс предоставления сотруднику доступа к информационной системе. В норме процесс имеет следующие этапы:

  1. Возникновение бизнес-потребности.
  2. Определение необходимого уровня доступа.
  3. Создание заявки.
  4. Согласование заявки.
  5. Исполнение заявки.
  6. Результат: доступ получен.
  7. Использование информационной системы.

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

Возьмем другой пример, значимый для компаний, чей бизнес связан с электронной коммерцией. В 2021 г. человек купил через мобильное приложение ЦУМ 19 наименований товаров ценой от 19 до 129 тыс. руб. В этот день из-за технического сбоя цены на товары в интернет-магазине отражались некорректно – в сотни раз ниже их реальной стоимости. В результате клиент приобрел вещи в 846 раз дешевле, чем магазин готов был их продать. ЦУМ отказался выдать заказ покупателю, и тот подал иск против магазина. Пройдя несколько инстанций, дело было передано в Верховный суд РФ. Он встал на сторону клиента, поскольку в силу действующего законодательства покупатель имеет право на получение товара по цене, заявленной в интернет-заказе.

Если нелегитимное изменение цен на сайте или в мобильном приложении ретейлера было связано не со взломом, а, скажем, с действиями сотрудника магазина, SOC не смог бы выявить инцидент. Однако если бы изменение цен на сайте и в мобильном приложении было заведено в мониторинг как бизнес-процесс, SOC бы своевременно уведомил об изменении цены на сайте без предшествующих в норме действий в информационных системах. В этом примере "красным флагом" могло стать отсутствие задокументированного в ИТ-системах прохождения этапов согласования снижения цен, подозрительный IP-адрес хоста, который инициирует изменения, или изменение цен пользователем, не указанным в описании бизнес-процесса.

Требования к бизнес-процессу для постановки его на мониторинг SOC

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

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

Реализация контролей безопасности бизнес-процессов с помощью SOC

Основная сложность состоит в том, что при контроле бизнес-процессов с помощью SOC огромная часть логов собирается на уровне приложений. Выполнять интеграцию "из коробки" для всего существующего ПО в корпоративном сегменте производителю проблематично, поэтому интеграционные модули готовятся, исходя из популярности тех или иных приложений в корпоративном секторе либо по запросу крупных заказчиков. Остальное придется выполнять MSSP-провайдеру, интегратору или самостоятельно заказчику.

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

ris1-Dec-01-2023-08-35-45-5347-AM

Генерируемые на каждом уровне события необходимо собирать, хранить и обрабатывать. Обработка событий представляет из себя разнообразные действия, от фильтрации и парсинга до применения метрик и алгоритмов корреляции. При этом метрики могут по сложности варьироваться от банального подсчета интенсивности генерируемых событий до выведения интегральных показателей уровня защищенности компании. Алгоритмы так же разнообразны, в зависимости от задач и используемых технологий, начиная с grep pattern и заканчивая ретроспективным анализом, предиктивной аналитикой и т. п.

Помимо метода сбора информации в SIEM, важно определить частоту проверки, уровень критичности для тех или иных аномалий, который будут считаться инцидентом, круг лиц, оповещаемых об инциденте, и каналы коммуникации с ними.

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

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

ris2-Dec-01-2023-08-35-14-6876-AM

Выводы

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

Темы:SOCМТС REDЖурнал "Информационная безопасность" №5, 2023

Форум ITSEC 2024:
информационная и
кибербезопасность России
Москва | 15-16 октября 2024

Посетить
Обзоры. Спец.проекты. Исследования
Персональные данные в 2025 году: новые требования и инструменты. Что нужно знать бизнесу о защите ПДн?
Получите комментарии экспертов на ITSEC 2024
Статьи по той же темеСтатьи по той же теме

Хотите участвовать?

Выберите вариант!

КАЛЕНДАРЬ МЕРОПРИЯТИЙ 2024
ПОСЕТИТЬ МЕРОПРИЯТИЯ
ВЫСТУПИТЬ НА КОНФЕРЕНЦИЯХ
СТАТЬ АВТОРОМ
Linux
15 октября | Форум ITSEC Защищенный удаленный доступ: как обеспечить контроль работы внешних сотрудников
Узнайте на ITSEC 2024!

More...
Обзоры. Исследования. Спец.проекты
Защита АСУ ТП и объектов КИИ: готовимся к 2025 году
Жми, чтобы участвовать

More...