SOT

Security Orchestration Tools

SOAR
Security Orchestration, Automation and Response

Автоматизация реагирования на инциденты информационной безопасности при помощи динамических плейбуков с применением СЗИ, выстраиванием цепочки атаки и объектно-ориентированным подходом

NG SOAR
Next Generation SOAR

Автоматизация реагирования на инциденты ИБ со встроенной базовой корреляцией, сбором сырых событий непосредственно с СЗИ, динамическими плейбуками, выстраиванием цепочки атаки и объектно-ориентированным подходом

AM
Asset Management

Описание ИТ-ландшафта, обнаружение новых объектов в сети, категорирование активов, инвентаризации и управления жизненным циклом оборудования и ПО на АРМ и серверах организаций

VM
Vulnerability Management

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

VS
Vulnerability Scanner

Сканирование информационных активов с обогащением из любых внешних сервисов (дополнительных сканеров, БДУ и других аналитических баз данных) для анализа защищённости инфраструктуры

SPC
Security Profile Compliance

Оценка конфигураций информационных активов в соответствии с принятыми в организации стандартами безопасности

ГосСОПКА
Государственная Система Обнаружения Предупреждения и Ликвидации Последствий Компьютерных Атак

Двустороннее взаимодействие с Национальным координационным центром по компьютерным инцидентам (НКЦКИ), а именно передача информации об инцидентах и получение оперативных уведомлений/бюллетеней от регулятора

FinCERT
Financial Computer Emergency Response Team

Двустороннее взаимодействие с Центральным Банком (ЦБ РФ, ЦБ РБ и др.), а именно передача информации об инцидентах и получение оперативных уведомлений/бюллетеней от регулятора

Напишите нам на sales@securityvision.ru или закажите демонстрацию

GRC

Governance, Risk Management and Compliance

КИИ
Критическая Информационная Инфраструктура

Аудит и исполнение требований ФЗ-187 «О безопасности критической информационной инфраструктуры Российской Федерации» и других нормативных документов

RM
Risk Management

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

ORM
Operational Risk Management

Учёт и фиксация событий операционных рисков (СОР), мониторинг ключевых индикаторов рисков (КИР) и проведение самооценки /контроля согласно положению №716-П ЦБ РФ

CM
Compliance Management

Аудит соответствия и комплаенс различным методологиям и стандартам нормативно методической документации как для компании в целом, так и по отдельным объектам ресурсно-сервисной модели

BCP
Business Continuity Plan

Автоматизация процесса обеспечения непрерывности и восстановления деятельности (ОНиВД) после наступления чрезвычайных ситуаций

Напишите нам на sales@securityvision.ru или закажите демонстрацию

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

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

  |  Слушать на Google Podcasts  |   Слушать на Mave  |   Слушать на Яндекс Музыке  |  


Руслан Рахметов, 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-устройствами.

MITRE SOC Управление ИБ ГОСТы и документы ИБ Стандарты ИБ Подкасты ИБ

Рекомендуем

Security Vision SGRC 2.0, или Новые горизонты автоматизации процессов
Security Vision SGRC 2.0, или Новые горизонты автоматизации процессов
Darknet — что это, как им пользуются преступники, чего следует остерегаться
Darknet — что это, как им пользуются преступники, чего следует остерегаться
Польза от Pentest для постинцидента
Польза от Pentest для постинцидента
Атаки на веб-системы по методологии OWASP Top 10
Атаки на веб-системы по методологии OWASP Top 10
Анатомия визуализации. Часть первая: от задачи к исполнению
Анатомия визуализации. Часть первая: от задачи к исполнению
Фантастический TI и где он обитает
Фантастический TI и где он обитает
Модель угроз ФСТЭК
Модель угроз ФСТЭК
Метрики: их очарование и коварство
Метрики: их очарование и коварство
Кибератаки. Часть 1: Технические инструменты и способы реализации
Кибератаки. Часть 1: Технические инструменты и способы реализации
Тестирование на проникновение
Тестирование на проникновение
Термины и определения в области информационной безопасности
Термины и определения в области информационной безопасности

Рекомендуем

Security Vision SGRC 2.0, или Новые горизонты автоматизации процессов
Security Vision SGRC 2.0, или Новые горизонты автоматизации процессов
Darknet — что это, как им пользуются преступники, чего следует остерегаться
Darknet — что это, как им пользуются преступники, чего следует остерегаться
Польза от Pentest для постинцидента
Польза от Pentest для постинцидента
Атаки на веб-системы по методологии OWASP Top 10
Атаки на веб-системы по методологии OWASP Top 10
Анатомия визуализации. Часть первая: от задачи к исполнению
Анатомия визуализации. Часть первая: от задачи к исполнению
Фантастический TI и где он обитает
Фантастический TI и где он обитает
Модель угроз ФСТЭК
Модель угроз ФСТЭК
Метрики: их очарование и коварство
Метрики: их очарование и коварство
Кибератаки. Часть 1: Технические инструменты и способы реализации
Кибератаки. Часть 1: Технические инструменты и способы реализации
Тестирование на проникновение
Тестирование на проникновение
Термины и определения в области информационной безопасности
Термины и определения в области информационной безопасности

Похожие статьи

Security Vision SGRC 2.0, или Новые горизонты автоматизации процессов
Security Vision SGRC 2.0, или Новые горизонты автоматизации процессов
Что такое снифферы и как они используются
Что такое снифферы и как они используются
Что такое системы анализа трафика (Network Traffic Analysis, NTA), их отличие от NDR и IDS
Что такое системы анализа трафика (Network Traffic Analysis, NTA), их отличие от NDR и IDS
Что такое аутентификация Kerberos (Керберос), что такое NTLM и как они работают
Что такое аутентификация Kerberos (Керберос), что такое NTLM и как они работают
Open software supply chain attack reference (OSC&R)
Open software supply chain attack reference (OSC&R)
Фантастический TI и где он обитает
Фантастический TI и где он обитает
Процессы ИТ и ИБ
Процессы ИТ и ИБ
Сетевая форензика с помощью ZUI
Сетевая форензика с помощью ZUI
Справочник законодательства Российской Федерации в области информационной безопасности
Справочник законодательства Российской Федерации в области информационной безопасности
The Hive. Разбор open source решения
The Hive. Разбор open source решения
Как научиться выстраивать килчейн
Как научиться выстраивать килчейн

Похожие статьи

Security Vision SGRC 2.0, или Новые горизонты автоматизации процессов
Security Vision SGRC 2.0, или Новые горизонты автоматизации процессов
Что такое снифферы и как они используются
Что такое снифферы и как они используются
Что такое системы анализа трафика (Network Traffic Analysis, NTA), их отличие от NDR и IDS
Что такое системы анализа трафика (Network Traffic Analysis, NTA), их отличие от NDR и IDS
Что такое аутентификация Kerberos (Керберос), что такое NTLM и как они работают
Что такое аутентификация Kerberos (Керберос), что такое NTLM и как они работают
Open software supply chain attack reference (OSC&R)
Open software supply chain attack reference (OSC&R)
Фантастический TI и где он обитает
Фантастический TI и где он обитает
Процессы ИТ и ИБ
Процессы ИТ и ИБ
Сетевая форензика с помощью ZUI
Сетевая форензика с помощью ZUI
Справочник законодательства Российской Федерации в области информационной безопасности
Справочник законодательства Российской Федерации в области информационной безопасности
The Hive. Разбор open source решения
The Hive. Разбор open source решения
Как научиться выстраивать килчейн
Как научиться выстраивать килчейн