Журнал "Information Security/ Информационная безопасность" #5, 2023

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