SOT

SOT

SOAR
Security Orchestration, Automation and Response

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

NG SOAR
Next Generation SOAR

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

AM
Asset Management

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

VM
Vulnerability Management

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

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

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

FinCERT
Financial Computer Emergency Response Team

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

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

GRC

GRC

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

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

RM
Risk Management

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

ORM
Operational Risk Management

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

CM
Compliance Management

Аудит соответствия и комплаенса различным методологиям и стандартам

BCP
Business Continuity Plan

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

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

False или не false?

False или не false?
09.10.2023


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


Ева Беляева, Руководитель Отдела развития
Security Vision

Зачем нам это знание... и почему нельзя без него обойтись

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


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


От флага, полученного на этапе реагирования и расследования, может зависеть многое – как время аналитика, так и область поиска ошибки с дальнейшим ее исправлением.


Понимание, в какой области находится проблема, как с ней разбираться и как к ней подступиться, даже то, в какой системе эта проблема находится – ко всему этому можно прийти, разбирая случаи подтвержденных/не подтвержденных инцидентов и false positive сработок.

Откуда берутся false positives?

Начнем разматывать клубок с того, что вообще в природе инфраструктуре может породить ложноположительный инцидент. Оттолкнемся от того, что предстоит чинить на этапе пост-инцидента: 

· Проблемы настроек. Здесь речь может идти как об источнике данных, так и о SIEM или любой другой системе, генерирующей инциденты (TIP, UEBA и проч.).    

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

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

- SIEM. Наверное, самый частый случай – «фолзящие» правила корреляции: тут не тот временной диапазон, там не та частота событий – и у нас в SOAR или IRP целый набор инцидентов, которым предстоит уйти в папку false positive.


· Отсутствие угрозы как таковой. Тут есть несколько вариантов:

- Расследование привело к тому, что субъектом действия выступал легитимный пользователь – инцидент, по сути, не подтвердился. Действия пользователя были правомерными, но паттерн этих действий непреднамеренно совпал с поведением злоумышленника. Такое бывает и с лучшими из нас, когда после отпуска сам собой забывается пароль.

- Действие было легитимно, но одновременно с этим отсутствовало какое-либо уведомление со стороны субъекта (например, когда речь идет о сканировании, инициированном коллегами из ИТ), и своевременно не был наполнен список исключений для правил.

- Произошедший инцидент был вызван учениями, тестированием нового правила.

Во всех этих случаях алгоритм проверки примерно одинаков, а вот способы устранения проблемы могут сильно разниться.

Как находят и как трактуют false?

Существуют и best practice, и целые методики работы с FP, но можно сказать и проще: в первую очередь стоит поискать доказательства сработки – проверить логи источника, парсинг их для коррелятора, даже задать пользователю прямой вопрос. Нередко в SOC выделяют отдельный процесс и ресурсы под отработку и тестирование правил, написание use case – правила проходят тщательную проверку на тестовых данных, прежде чем отправиться в боевую систему.


С трактовкой же все не так однозначно.

Что в документах?

На бумаге все очевидно, прозрачно и просто: существуют настоящие угрозы или их отсутствие. Первое представляет собой true positive – подтвержденный инцидент, второе же – не существующий трафик, результат ошибок настроек, некий дополнительный шум, вызванный некорректными пороговыми значениями, если речь идет об адаптивной системе. В нескольких словах, false – это то событие, которого на самом деле не было. Здесь и начинаются приключения.

А как предлагают трактовать false positive из коробки вендоры SOAR/IRP?

Несколько вариантов на выбор:

· Дублирование флага от SIEM – а этот флаг проставляется вручную.

· Конструктор из различных свойств карточки инцидента, иногда добавляется шаг подтверждения и дополнительный флаг, отличный от FP.

· Иная метрика опасности угрозы, основанная на скоринге или критичности.

· Отдельный флаг для ошибки в правилах корреляции – и отдельный коробочный сценарий. 


Нередко SOC или конкретным заказчикам не хватает таких метрик и трактовок, и они просят добавлять свои.

Что настроит интегратор?

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

Как у заказчиков?

Со временем (или даже сразу) количество понятий перерастает в целый «зоопарк». Какие мы встречали флаги в карточках, как они могли быть выявлены и какое предлагалось реагирование:

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

- По скорингу активов. Произошедшее могло не быть критичным, могло быть, но место возникновения инцидента настолько не критично для организации или не влияет на процессы и общую безопасность, что инцидент и сам теряет свою значимость.

- Иные скоринги, к примеру, результат проверки вредоносного ПО: если score такого ПО меньше единицы (или любого другого порога), то происшествие считается незначительным и не заслуживает внимания. По аналогии эту логику можно экстраполировать и на WAF (некритичный сегмент, некритичная уязвимость) и на иные СЗИ.


· Дубликаты. Множественные оповещения об одной и той же сработке иногда помечаются «в лоб» - вердиктом «дубликат», а иногда закрываются с меткой false positive. В целом, аргументы есть для обоих понятий: более прозрачный вердикт поможет в дальнейшем при сборе статистики и построении отчетности, так как даст понимание о доле таких инцидентов от общего числа, а ошибка генерации инцидентов говорит о сбое и о том, что на самом деле в указанное время на точке сбора событие на источнике не произошло.
· Нелегитимность/легитимность. Такая отметка дает оценку действию пользователя, а не самому инциденту, и вполне уживается на карточке с флагом FP. По сути, и правило корреляции может быть настроено верно, и события пришли такие, как ожидали, но сработал человеческий фактор, и используемые в правилах корреляции списки исключений не заполнились (например, запланированная смена привилегий для пользователя отобразилась как инцидент, т.к. не было связанной с мероприятием служебной записки) или субъект предполагаемой атаки просто делал свою работу. Оценка характера действия субъекта в рамках процесса пост-инцидента позволяет более четко и качественно описать сценарии тестирования правил в дальнейшем.
· Разнообразные ошибки. Очень редко они появляются в виде каких-либо флагов, но вот в виде развилки дерева принятия решений – наверняка будут. Ведь в зависимости от контекста и характера ошибок определяются действия по их устранению, и опять же, это полезно для статистики:     

- Ошибка корреляционного правила. Самая популярная проблема, требующая отдельного внимания. Важно определять именно эту ошибку не столько для статистики, сколько для сценария.

- Ошибка источника. Призрачные логи, неправильное время и сбои при передаче – все это здесь.

- Ошибка парсинга. Неправильный маппинг полей, некорректное заполнение карточки – и вот даже протестированное и надежное правило корреляции начнет ошибаться на неверных вводных данных.


· Учения и тесты. Ошибочно попавшие в общий зачет события и инциденты, которые, с одной стороны, по всем параметрам – опасная сработка, а с другой – эмуляция реальных угроз. В таком контексте заказчики нередко переигрывают FP в обратную сторону, от чего может возникать путаница – нам встречались инциденты-симуляции, отмеченные как FP только потому, что результат не совпал с предполагаемым в use case.

Таким образом, перед SOC в процессе расследования стоит непростая задача по поиску странного существа, по сути кадавра от мира ИБ – true false positive, настоящего ненастоящего инцидента, который может принимать любые облики и трактовки. На этапе реагирования критически важно правильно установить этот флаг, так как в дальнейшем это влияет на выбор пути для процесса lessons learned: что чинить в первую очередь, с кем работать дальше и как преобразовать связанные процессы.

А можно отдать выявление false positive инцидентов на откуп AI?

Можно попробовать, но задачка непростая.


Как в целом можно предлагать искусственному интеллекту предсказывать, произошел или нет инцидент, полученный от источника или коррелятора? Существует такой вариант, как выявление false через частоту и всплески событий в трафике: хаотичные false positive, или события, которых не было, идут в противовес забагованному правилу корреляции, которое генерирует массу таких событий с флагом, одно за другим. Но от какой модели отталкиваться?


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


На практике есть риск потери важных данных и по-настоящему критичных инцидентов. Лучше уж ставить отметки о том, что угроза отсутствует, при виде логов, которые взялись из ниоткуда. 

Итоги

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

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


2. Автоматизация в порядке, но сыграл человеческий фактор – требуется провести внеочередную сессию awareness для пользователей и всех причастных. Еще раз оговорить существующие процессы, протестировать теорию на практике. Если СЗИ и источники настроены хорошо, дополнительный процесс для них не нужен, а решить проблему такого фактора можно в рабочем порядке расследования/реагирования. Правильно выставленная метка позволит сократить использование аналитического ресурса хотя бы здесь.


Решение разделить флаги на два блока – подтверждения и false positive – позволит сразу подсветить для аналитика конкретные проблемы и не даст спрятать в числе общих ошибок те, которые можно исправить.

SIEM Подкасты ИБ NG SOAR (Next Generation SOAR) SOAR Практика ИБ TIP SOC IRP UEBA СЗИ

Рекомендуем

SOC (Security Operation Center): что это такое и зачем используется? Центры мониторинга информационной безопасности
SOC (Security Operation Center): что это такое и зачем используется? Центры мониторинга информационной безопасности
КИИ - что это? Безопасность объектов критической информационной инфраструктуры
КИИ - что это? Безопасность объектов критической информационной инфраструктуры
Кейлоггер для кибербезопасности и оптимизации
Кейлоггер для кибербезопасности и оптимизации
Информационная  безопасность (ИБ) - что это такое. Виды защиты информации.
Информационная безопасность (ИБ) - что это такое. Виды защиты информации.
Что такое IRP, где используется и как внедряется
Что такое IRP, где используется и как внедряется
SIEM системы (Security Information and Event Management) - что это и зачем нужно?
SIEM системы (Security Information and Event Management) - что это и зачем нужно?
Управление рисками информационной безопасности. Часть 1. Основные понятия и методология оценки рисков
Управление рисками информационной безопасности. Часть 1. Основные понятия и методология оценки рисков
Управление рисками информационной безопасности (конспект лекции)
Управление рисками информационной безопасности (конспект лекции)
Федеральный закон № 161-ФЗ «О национальной платежной системе»
Федеральный закон № 161-ФЗ «О национальной платежной системе»
Категорирование объектов критической информационной инфраструктуры в рамках 187-ФЗ. Постановление Правительства РФ № 127
Категорирование объектов критической информационной инфраструктуры в рамках 187-ФЗ. Постановление Правительства РФ № 127
Практика ИБ. Централизованный сбор логов с Windows-устройств
Практика ИБ. Централизованный сбор логов с Windows-устройств
Управление инцидентами ИБ (конспект лекции)
Управление инцидентами ИБ (конспект лекции)

Рекомендуем

SOC (Security Operation Center): что это такое и зачем используется? Центры мониторинга информационной безопасности
SOC (Security Operation Center): что это такое и зачем используется? Центры мониторинга информационной безопасности
КИИ - что это? Безопасность объектов критической информационной инфраструктуры
КИИ - что это? Безопасность объектов критической информационной инфраструктуры
Кейлоггер для кибербезопасности и оптимизации
Кейлоггер для кибербезопасности и оптимизации
Информационная безопасность (ИБ) - что это такое. Виды защиты информации.
Информационная  безопасность (ИБ) - что это такое. Виды защиты информации.
Что такое IRP, где используется и как внедряется
Что такое IRP, где используется и как внедряется
SIEM системы (Security Information and Event Management) - что это и зачем нужно?
SIEM системы (Security Information and Event Management) - что это и зачем нужно?
Управление рисками информационной безопасности. Часть 1. Основные понятия и методология оценки рисков
Управление рисками информационной безопасности. Часть 1. Основные понятия и методология оценки рисков
Управление рисками информационной безопасности (конспект лекции)
Управление рисками информационной безопасности (конспект лекции)
Федеральный закон № 161-ФЗ «О национальной платежной системе»
Федеральный закон № 161-ФЗ «О национальной платежной системе»
Категорирование объектов критической информационной инфраструктуры в рамках 187-ФЗ. Постановление Правительства РФ № 127
Категорирование объектов критической информационной инфраструктуры в рамках 187-ФЗ. Постановление Правительства РФ № 127
Практика ИБ. Централизованный сбор логов с Windows-устройств
Практика ИБ. Централизованный сбор логов с Windows-устройств
Управление инцидентами ИБ (конспект лекции)
Управление инцидентами ИБ (конспект лекции)

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

Технология SOAR и ее место в SOC
Технология SOAR и ее место в SOC
Живее всех живых: непрерывность бизнеса
Живее всех живых: непрерывность бизнеса
Что такое системы анализа трафика (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)
Применение утилиты Sysmon для повышения уровня кибербезопасности
Применение утилиты Sysmon для повышения уровня кибербезопасности
Что такое шлюзы безопасности и какие функции они выполняют
Что такое шлюзы безопасности и какие функции они выполняют
Ландшафт угроз информационной безопасности последних лет. Часть 2
Ландшафт угроз информационной безопасности последних лет. Часть 2

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

Технология SOAR и ее место в SOC
Технология SOAR и ее место в SOC
Живее всех живых: непрерывность бизнеса
Живее всех живых: непрерывность бизнеса
Что такое системы анализа трафика (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)
Применение утилиты Sysmon для повышения уровня кибербезопасности
Применение утилиты Sysmon для повышения уровня кибербезопасности
Что такое шлюзы безопасности и какие функции они выполняют
Что такое шлюзы безопасности и какие функции они выполняют
Ландшафт угроз информационной безопасности последних лет. Часть 2
Ландшафт угроз информационной безопасности последних лет. Часть 2