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

Сырые данные Первое, что мы должны направить в "черный ящик" SOC, – это сырые данные нескольких типов. 1. Логи. Реагирование на инциденты начинается с умения их выявлять. А любое выявление инцидентов строит- ся на по возможности максимально широкой фиксации и сборе происходя- щих в организации и ее системах собы- тий и поиске в них маркеров того, что произошел инцидент. Поэтому важно организовать поступление в SOC логов и событий, с использованием которых будет осуществляться поиск инциден- тов. По сути, речь идет о стандартном лог-менеджменте: события гарантиро- ванно собираются с ИТ-инфраструкту- ры, из бизнес-систем, с других каналов, по которым может проходить инфор- мация, и анализируются. 2. Информация об известных атаках и угрозах. Она нужна для того, чтобы выявлять эти атаки в общем потоке событий по паттернам. Уточним, что информация, приходящая из внешних источников, помогает находить только известные атаки и угрозы. Как правило, на сегодняшний день, если где-то кто-то столкнулся с некой угрозой, информация об индикаторах атаки, включая вирусные сигнатуры, становится доступной через различные CERT, обновления баз сиг- натур или фиды. Сигнатуры и индикато- ры компрометации в рамках Threat Intel- ligence (TI) – это второй поток данных, приходящих в SOC. 3. Информация об уязвимостях. Дан- ные об уязвимостях поступают из нескольких источников и, несмотря на видимую структурированность, для SOC они тоже являются сырыми, поскольку: l они не учитывают контекст защищае- мой организации; l в каждом источнике данные имеют свою нотацию, формат, полноту и пр. 4. Информация о защищаемых хостах, системах и сетях. Невозможно реагиро- вать на инциденты, не понимая контекст информационных активов организации, с которыми инцидент происходит. Эти данные тоже являются для SOC сырыми, потому что большей частью поступают от внешних инфраструктурных и ИТ под- разделений, из различных CMDB-систем, и, как правило, являются разрозненны- ми, ненормализоваными и неполными. Они важны для получения полного кон- текста и ландшафта защищаемой орга- низации и используются при реагирова- нии на конкретный инцидент. 5. Информация о бизнесе и рисках. Часто этот поток данных в SOC вообще не анализируется, но это большая ошиб- ка, поскольку SOC строится именно для того, чтобы приносить пользу бизнесу. Поэтому при реагировании на инциденты обязательно нужно иметь информацию о том, какие бизнес-процессы и системы функционируют в организации. Без этого невозможно ни приоритизировать инци- денты, ни взаимодействовать при реа- гировании с бизнес-подразделениями – внутренними заказчиками всего сервиса информационной безопасности. Необходимо также проводить анализ рисков, поскольку он дает понимание, какие инциденты могут привести к боль- шему ущербу, а какие к меньшему. Зная это, можно расставлять приоритеты и планировать сроки для реагирования, чтобы не нанести активам недопустимый ущерб. Отсюда, по сути, вытекает SLA для обработки инцидентов – неотъем- лемая часть процессов SOC. Сбор и ведение актуальной информации о биз- нес-процессах, системах и рисках, вклю- чая процессы их оценки и обработки, удобно вести в системе класса SGRC. Обработка данных Когда в SOC заведены все необходи- мые потоки данных, необходимо прове- сти их обработку. Это движение от сырых данных к экспертизе, к знаниям, которые важно создать и накопить в SOC. Разберем составляющие эле- менты обработки данных. 1. Правила агрегации и нормализации. Данные приходят в SOC разрозненными из многочисленных источников, и необходимо выработать и обязательно апробировать правила агрегации и актуализации, чтобы сделать систем- ной последующую работу с ними. Дан- ные, поступающие в хаотическом виде и порядке, невозможно сделать полез- ными, их нужно нормализовать. Поэтому необходимо создать правила агрегации и нормализации – фундамент для накоп- ления знаний и практик в SOC. 2. Ресурсно-сервисная модель (РСМ). Она строится на основе информации о бизнесе, рисках, хостах, системах и сетях – по сути, на традиционных све- дениях об инвентаризации, поступающих в SOC. Необходимо реализовать полно- ценную модель взаимосвязей между всеми активами организации, чтобы в случае, если с любым из активов про- изошел инцидент, четко понимать ланд- шафт этого инцидента. Важно построить процесс так, чтобы в SOC была акту- альная информация о защищаемых акти- вах. Построенная РСМ также является знанием SOC, и ее наличие позволяет в случае инцидента начать реагирование максимально оперативно, не тратя вре- мени на сбор информации. К слову, реализация полноценной РСМ невоз- можна без использования платформы для ее сбора и актуализации, например SGRC или IRP. 3. Правила корреляции. Эта экспертиза должна быть выработана в SOC, и она заключается в документированных зна- ниях о том, какое сочетание различных событий и их атрибутов свидетельствует о потенциальном инциденте. Соответ- ствующие правила корреляции создают- 20 • СПЕЦПРОЕКТ Анатомия SOC сть известная парадигма “люди – процессы – технологии", из этих слагаемых состоит любой SOC: нужно нанять, обучить людей, построить и организовать процесс их работы по выявлению и обработке инцидентов, а затем автоматизиро- вать процессы с помощью определенных технологических платформ. Но нельзя упускать еще один, не менее важный элемент: любой SOC строится вокруг данных. SOC, как и любая организационно-технологическая сущность, не может существовать без данных и знаний. Поэтому рассмотрим раз- личные типы данных, а также методы их обработки, которые необходимы в SOC. Е Всеслав Соленик, директор центра экспертизы R-Vision