Публикация MITRE «11 стратегий SOC-центра мирового уровня». Стратегия №7 «Выбирайте и собирайте правильные данные»

Руслан Рахметов, Security Vision

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

1. Планирование сбора данных.

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

Данные, которые нужны SOC-центру, можно получать из различных источников; понимание функционирования таких источников является ключом к определению того, какие данные можно использовать для тех или иных сценариев обнаружения инцидентов (англ. "use cases"), и какие данные являются первоприоритетными. В Приложении "E" к публикации приведен список возможных источников ИБ-телеметрии (различные СЗИ, журналы ОС, сетевые устройства, инфраструктурные элементы) и их характеристики: тип передаваемой информации, ориентировочное количество событий в сутки, а также субъективная оценка полезности данных от различных источников. 

При выборе источников и типа данных членам SOC-центра также следует ответить на следующие вопросы:

- Как данные от специализированных ИБ-систем смогут дополнить информацию из журналов событий?

- Каково качество и понятность формируемых логов: пригодны ли логи для анализа человеком или информационной системой, какова логическая связность создаваемых событий друг с другом, возможно ли настроить политики логирования для удовлетворения потребностей SOC?

- Доступность и возможность обработки логов: пишутся ли логи в вендоро-нейтральном формате, можно ли их обрабатывать инструментами сбора журналов событий и в текущей SIEM-системе, каковы затраты на настройку парсинга и нормализации данных от источника, могут ли владельцы систем предоставить прямой доступ к журналам аудита своих систем, есть ли в инфраструктуре уже готовое решение для централизованной обработки логов (syslog-коллектор, шина сообщений, централизованное хранилище данных), каков будет общий объем собираемых логов, справится ли с нагрузкой аппаратное/программное обеспечение?

- Охват системы журналирования: сможет ли выбранный источник данных охватить значительную часть инфраструктуры компании, сможет ли источник повысить качество мониторинга работы критичной системы? 

При настройке мониторинга и сбора данных важно помнить об их возможном негативном влиянии на инфраструктуру компании; для минимизации негативного влияния авторы публикации дают следующие рекомендации:

- Минимизируйте количество установленных агентов сбора логов, особенно на конечных системах;

- Тщательно настройте параметры производительности агентов, такие как частота запросов, количество передаваемых в каждом запросе событий, потребление вычислительных ресурсов конечной точки;

- Используйте существующие точки сбора информации (например, syslog-коллекторы и управляющие серверы), с учетом того, что данные передаются на эти точки сбора информации без потерь и задержек, у SIEM-системы есть агент для такой точки сбора, а данные с точки сбора передаются без задержек для возможности корреляции с другими релевантными событиями;

- По возможности используйте гарантированную доставку: используйте протокол TCP вместо UDP, размещайте агенты сбора в логической/физической близости к источнику данных для минимизации задержек и более широкого применения методов шифрования передающихся данных, а также используйте технологии шины сообщений, такие как Apache Kafka, для обеспечения пакетной обработки, шифрования, сжатия данных;

- Используйте SIEM-решение или Log Management систему, которые могут переносить данные с одного агента на множественные места хранения для обеспечения отказоустойчивости и непрерывности процессов мониторинга и сбора логов;

- Старайтесь использовать стабильные и киберустойчивые системы сбора ИБ-телеметрии, анализируйте количество аварийных завершений их работы, устойчивость к атакам и к попыткам нарушения и вмешательства в их работу со стороны злоумышленников. 

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

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

Тонкая настройка (тюнинг) источников данных выполняется для достижения баланса между объемом данных и их пользой для выявления кибератак: при слишком грубой настройке можно или пропустить важные события ввиду недостаточности получаемой информации, или «засыпать» членов команды SOC нужными и ненужными данными, что также может привести к пропуску инцидента ввиду утомления от количества событий и предупреждений. В публикации рекомендуется сразу отфильтровать источники, которые предоставляют малоинформативные данные - это позволит отсеять «информационный шум» на первом этапе. В случае работы в распределенных инфраструктурах рекомендуется обрабатывать данные локально, т.е. ближе к источникам на соответствующих площадках, а анализировать - централизованно, что позволит распределить нагрузку. Кроме того, следует логировать не только события «отказа» (когда СЗИ блокируют активность или ИТ/ИБ-системы не разрешают выполнение запрашиваемых операций), но и события «успеха» (когда определенные действия была разрешены и выполнены), поскольку при расследовании важно понимать не только неудачные действия атакующих, но и операции, которые были ими выполнены. 

Авторы публикации также приводят три основных подхода к настройке источников данных, которые имеют свои плюсы и минусы:

- Включение всех возможных опций и сбор всех возможных данных от всех источников с последующей «вычисткой» от неинформативных событий и отключением неэффективных опций журналирования;

- Включение опций журналирования и обработка новых типов данных по мере необходимости с предварительным формулированием потребностей в мониторинге тех или иных типов событий и использовании определенных источников;

- Использование имеющихся средств обработки данных, таких как промежуточные системы Log Management или платформы обработки Big Data, что позволяет обрабатывать ИБ-телеметрию ближе к источнику данных до заведения её в контур SOC. 

В публикации подчеркивается важность контроля за функционированием источников данных, которые могут непрерывно появляться и исчезать вместе с вводом новых систем и отключением старых, особенно в больших инфраструктурах. Авторы публикации дают следующие рекомендации для управления процессом обслуживания сенсоров и источников данных:

- Применяйте методы управления конфигурациями для контроля изменений настроек источников данных (например, контролируя перечень источников и лиц, ответственных за каждый источник);

- Поддерживайте обмен информацией с системными администраторами и инженерным составом для контроля вносимых в инфраструктуру изменений и получения новостей о вводе новых систем в эксплуатацию;

- Регулярно проверяйте статус источников данных - это можно делать ежедневно или при заступлении новой смены SOC-центра; кроме того, следует проверять корректность получаемых данных, особенно от критичных источников, а также включить охват источников данных и их работоспособность в систему метрик SOC;

- Используйте встроенные средства оценки работоспособности сенсоров и источников данных, которые смогут предупредить об ошибках;

- Старайтесь оперативно выявлять сбои в работе источников данных и немедленно обращайтесь к ответственным за систему, чтобы найти причину сбоя «по горячим следам». 

В заключении раздела о планировании сбора данных авторы публикации напоминают о важности согласования сроков хранения собранных данных: период хранения может определяться внутренними требованиями компании-заказчика, законодательными нормами, а также риск-профилем компании-заказчика и бюджетными ограничениями. Как правило, период хранения данных устанавливается равным 12 или более месяцам, но в некоторых случаях может быть расширен. При этом важно обеспечить не только техническую возможность хранения информации (т.е. использовать вместительную дисковую подсистему), но и возможность оперативного поиска по собранным данным по всему объему информации. 

Далее, в Стратегии №7 идет описание различных технологий защиты информации, которые могут предоставлять информацию SOC-центру для мониторинга и реагирования. Детальному описанию технологий можно посвятить отдельные большие публикации, поэтому далее приведем лишь краткое описание содержимого разделов Стратегии №7. 

2. Средства обнаружения вторжений.

Средства обнаружения вторжений могут быть разделены на следующие типы:

- Системы на основе поведенческого анализа (включая выявление аномалий и машинное обучение) и на основе сигнатур (включая поиск соответствия индикаторам компрометации);

- Сетевые и хостовые средства обнаружения вторжений;

- Пассивный мониторинг (системы обнаружения вторжений - Intrusion Detection Systems, IDS) и активное предотвращение вторжений (системы предотвращения вторжений - Intrusion Prevention Systems, IPS). 

3. Средства мониторинга и защиты конечных точек.

Данные от конечных точек (серверов, рабочих станций), как правило, предоставляют более полную и целостную картину происходящего для выявления и подтверждения кибератак по сравнению с сетевыми средствами защиты. На конечных точках можно контролировать состояние файловых систем, ОЗУ, ЦПУ, подключенных устройств. Для продвинутого мониторинга и защиты можно использовать решения для защиты конечных точек (Endpoint Detection and Response, EDR), которые позволяют выявить вредоносную активность на основе анализа множества факторов, предоставляют расширенную ИБ-телеметрию, позволяют выполнить активные действия по реагированию. Решения для контроля запуска приложений запрещают или разрешают запуск процессов по модели разрешительных или запретительных списков, управление которыми требует значительных ресурсозатрат. Классические СЗИ, такие как антивирусы и хостовые фаирволлы, все еще могут использоваться для обеспечения кибербезопасности, но только в сочетании с другими технологиями при выстраивании эшелонированной системы киберзащиты.

Другими средствами, описанными в публикации, являются системы защиты от утечек данных (Data Loss Prevention, DLP) и системы мониторинга активности пользователей. При этом авторы публикации указывают на необходимость применения конкретных мер защиты в зависимости от критичности системы, привилегий работающих в ней пользователей, уязвимостей и поверхности атаки системы. 

4. Средства сетевого мониторинга.

Несмотря на снижение популярности средств сетевого мониторинга, в том числе из-за преобладания зашифрованного трафика, эти решения до сих пор могут быть использованы SOC-центром как один из самых простых и доступных вариантов. Важными характеристиками сетевых СЗИ будут: процент ложноположительных срабатываний, детали и контекст сработавших сигнатур, возможности по активному реагированию, пропускная способность и влияние на сетевую инфраструктуру, а также способы интеграции с другими технологиями и стоимость. 

5. Облачные инфраструктуры.

С ростом использования облачных технологий SOC должен брать на мониторинг облачные системы, сервисы, ресурсы. В облачных инфраструктурах можно применять многие подходы, использующиеся для защиты on-prem инфраструктур, при этом с учетом большой распределенности облачных сетей имеет смысл фокусироваться на мониторинге конкретных сервисов и конечных точек. Также следует быть готовым к работе с новыми типами источников данных и с незнакомыми ранее облачными технологиями защиты. 

6. Инфраструктуры с нулевым доверием.

В сценариях работы в сетях с нулевым доверием (англ. Zero Trust) можно использовать комбинацию различных продуктов для мониторинга: EDR - для конечных точек, DLP - для данных, контроль пользователей и ресурсов - для приложений.

7. OT-инфраструктуры.

В OT-системах и сетях обеспечение доступности имеет больший приоритет, чем обеспечение конфиденциальности и целостности. Основными вызовами для защиты OT-инфраструктур могут стать проприетарные специфические протоколы взаимодействия, разнообразие вендоров и моделей, ограничения по установке и применению устройств, ограниченный выбор специализированных СЗИ для OT-инфраструктур. Особое внимание следует обращать на технологические стыки между IT и OT сетями, а также на взаимодействие с IoT-устройствами.