Здравствуй, Дзен!

Добро пожаловать на мой Дзен!

Буду стараться, чтобы мои заметки на новом месте будут во всех отношениях не хуже прежних.

Увидимся на Дзене!

Визуализация расследования

В прошлой заметке я примерно рассказал как выглядит расследование инцидента. Технически, для аналитика SOC это выражается в необходимость на базе имеющейся информации строить запрос к используемому data lake из данных (событий систем, EDR-like и NTA-like телеметрии, Netflow и т.п., что там у кого еще есть...). Запрос возвращает новые, связанные по observables, события, в которых есть новые поля, по которым также можно далее поискать. Каждое новое событие добавляет контекста в инцидент, что позволяет более точно интерпретировать происходящее, а более точная интерпретация позволяет спланировать более эффективные и результативные мероприятия по реагированию. Детализация контекста зависит от ширины и глубины телеметрии, но, в любом случае, ограничена, в сравнение с форенсикой, так как объем телеметрии и\или логов - это компромисс межу собирать все подряд и умереть под объемом данных, и собирать мало и не иметь возможности обнаруживать современные атаки. Как правило, этот компромисс решается очень просто: нужно обнаружить любую современную атаку и иметь возможность ее валидировать, т.е. насколько  это возможно, подтвердить, что выявленная активность не является ложным срабатыванием, далее инцидент передается в команду расследования, которая делает форенсику и восстанавливает полную картину. Задача полного расследования исключительно по телеметрии MDR не ставится.

Ответственный MDR провайдер стремится в карточке инцидента заказчику предоставить как можно больше информации, насколько это возможно на основе собираемой телеметрии (== насколько позволяет технологический стек MDR). Для этого аналитик SOC/MDR собирает таймлайн - это последовательность всех, связанных с данным инцидентом, алертов и сырах событий (событий, релевантных действиям атакующих, но не попавших в какие-либо алерты). Связка релевантных алертов и событий вместе (== событий, подтверждающих те или иные действия атакующих) производится именно как указано выше - по observables\IoC. 

Практика показывает, что аналитику SOC намного удобнее строить таймлайн визуально на графе, чем делать это, например, в Блокноте, а потом копи-пейстить это в Карточку инцидента, публикуемую заказчику. Технически это выглядит так: алерт - первый узел графа. В алерте есть связанные события, у каждого из которых есть поля, и каждое поле может служить ключом поиска в качестве observable. Аналитик изучает события алерта и задает вопросы, ответы на которые приводят к появлению на графе новых связанных узлов. Новые узлы - это тоже события и\или алерты (совокупности событий), в которых есть тоже уже свои поля, каждое из которых можно использовать как observable для поиска новых связанных событий и\или алертов, и т.д. 

Это звучит сложно на слух, поэтому попробуем придумать примеры. Всем известна и понятна цепочка запуска процесса, типа процесс1 --> процесс2 --> процесс3 и т.п. , пример можно увидеть в Kibana здесь. С учетом предлагаемого нами подхода эта цепочка запуска процесса является частным случаем графа из событий телеметрии EDR "запуск процесса" - здесь мы связываем события запуска процесса по полю Unique PID. Но связывать между собой можно не только события запуска процесса, а вообще любые события. Например, мы имеем алерт на событие запуска процесса - построили цепочку из событий запуска. В событии запуска процесса видно в контексте какой учетной записи (УЗ) пользователя произведен запуск. Для дальнейшего расследования аналитику SOC нужно найти информацию об этой УЗ и отобразить ее на графе таймлайна - аналитик кликает по SID с запросом "найти вход" - на граф подрисовывается событие входа этой УЗ. В событии входа виден тип входа и адрес и\или имя системвы, откуда произведен вход, далее аналитик ищет запуски процессов от данной УЗ, но уже на системе с которой был зафиксирован вход... Подстраивать узлы графа можно не только "назад", но и "вперед". Мы начали с первого алерта на запуск процесса, в котором есть хэш, допустим, в телеметрии на этот файл можно найти срабатывания AM-движка (AM == anti-malware), - эти события также стоит добавить на граф таймлайна.

Ключевым отличием нашего графа от используемого в решениях других производителей является то, что здесь узлы - не информационные системы, а события телеметрии, ребра - связи между событиями на основании observables. Метод построения - выбор аналитика SOC из списка предопределенных поисковых запросов по артефакту (observable, IoC) и возвращенных данных на выбранный запрос, причем начать можно с наиболее общих запросов, типа, найти все события, где фигурирует этот хэш, или все запуски процессов от данной конкретной УЗ, или все события срабатывания AM-движка с конкретным вердиктом и т.п.

Такой интерактивный метод построения таймлайна в виде графа позволяет быстро и удобно для аналитика SOC найти все связанные с данным инцидентом события телеметрии и сформировать наиболее полную картину происходящего... 

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

Но это еще не все! Процесс построения таймлайна аналитиком SOC, а именно, при каких начальных условиях какие запросы к телеметрии формирует аналитик (по-человечески это можно перефразировать как "какие алерты как расследуются аналитиком SOC"), нужно подробно логгировать/журналлировать. Очевидным использованием таких логов является оценка эффективности работы аналитиков, - этим всегда полезно заниматься. А также на эти логи можно натравить Машобуч, который можно обучить на успешных расследованиях, и затем использовать Машобуч для подсказки запросов аналитикам SOC в процессе построения ими графа таймлайна. Успешными расследованиями для Машобуча будут те, которые в итоге были опубликованы заказчикам в качестве инцидентов и впоследствии не были помечены как ложные срабатывания, а также успешно прошли перепроверку. Если практика использования Машобуча в качестве подсказчика\помощника аналитику SOC при построении графа таймлайна показала воодушевляющие результаты, то можно какие-то сценарии затем перевести в автоматическую отработку, и аналитику при расследовании алерта сразу будет подрисовываться часть графа таймлайна на базе опыта прошлых расследований, аккумулированного в модели Машобуча.

Вторая линия, виртуальная

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

Из общения с различными менеджерами SOC, да и процессе собеседований с потенциальными коллегами на операционные линии, сложилась уверенность, что в большинстве SOC есть первая линия аналитиков, действующая практически полностью по алгоритму (~плейбуку) и более-менее проявить инициативу можно только на "второй" линии. При этом мне никто не объяснил, почему, если работа первой линии столь детально алгоритмизирована, ее нельзя полностью автоматизировать, да хоть даже с использованием машобуча. Да, есть определенные различия в квалификации аналитиков, в опыте, но это все равно не повод полностью обламывать крылья, превращая аналитиков SOC в биологические автоматы. Чтобы люди умели принимать решения,  им надо давать возможность принимать решения!

Постоянно раздумывая о проблематике, намеченной выше, мы в конечном счете пришли к выводу, что у нас не будет нескольких операционных линий с жестким назначением аналитиков. Я уже рассказывал (и раньше в этом посте есть ссылка на запись доклада), что "первой линией" в нашем случае является Автоаналитик, являющийся частью конвейера обработки телеметрии, а на команду SOC уже попадает меньше фолсы. Вместо нескольких у нас есть одна операционная линия, среди которой по расписанию выделяется группа, выполняющая функции второй линии. Поскольку состав группы по расписанию меняется каждую неделю, внутри мы ее называем "Виртуальная вторая линия" (Virtual Second Line, VSL). 

На VSL выпадают все более-менее творческие задачи за рамками расследования алертов, причем назначение конкретных членов VSL на функциональные участки также приводится в расписании, мы это тоже постоянно ротируем. Для понимания приведу примеры некоторых функциональных участков для VSL .

• Операционка. Эта группа занимается расследованием алертов, как и дежурные, но на нее дежурные могут выполнить эскалацию. При получении такой эскалации данная группа VSL (конкретный аналитик, на кого передали кейс) переключается на работу по эскалации и доводит ее до конца. По завершении работы на эскалации, снова "превращается" в операционного аналитика, расследующего поступающие алерты. Такой режим работы используется при высокой нагрузке команды SOC в целом (большой объем работы, много алертов и/или инцидентов). В более спокойное время, под операционку не выделяется группа из состава VSL, а на эскалации переключаются из других направлений (например, аналитик занимался ретро-хантингом, но, получив эскалацию. переключился на нее, а по окончании - продолжил проверять свои гипотезы)
• Перепроверка. Известно, что мы перепроверяем за Автоаналитиком, но мы перепроверяем и за аналитиками. Приоритезация перепроверки (за кем следует посмотреть побольше) управляется метриками SOC (в частности, на основе конверсии). Типы ошибок аналитиков я привел в докладе на слайде 32, ошибки регулярно обсуждаются, и тенденция к их уменьшению доказывает полезность этого мероприятия.
• Периодический ретро-хантинг. Не все гипотезы реализованы в виде алертов, ввиду своей склонности к ложным срабатываниям. Но это не отменяет необходимость их проверки вручную. Для ретро-хантинга есть несколько критериев. которые позволяют его применять с большей результативностью.
• Фильтрация, адаптация детектирующей логики. Давно писали о разных типах ложных срабатываний, с т.з. этой статьи "контекстные" ложные срабатывания в ответственности операционной группы и на их расследование требуются ресурсы.

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

Сколько нужно операционной безопасности?

 Во второй день SOC Forum выступал с докладом в секции аналитических отчетов. Выкладываю презентацию. Остановлюсь тезисно на основных вещах, которые хотелось донести.

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

2. Есть определенные различия в языке между CISO и Бизнесом, что в результате сводит общение об ИБ к пугалкам, типа: "Вот страшная-страшная угроза, но внедрив решение Х, уровень риска будет снижен до допустимых значений, нужны средства на этот Х". Подход не блещет новизной, и имеет проблемы эффективности и результативности.

3. На основании аналитики DFIR можно объективно оценить ландшафт угроз, а на базе метрик SOC - возможности соей операционной безопасности. Основной контент презентации - это те или иные цифры из аналитической отчетности, и вопросы, которые имеет смысл себе задать для оценки собственной готовности. Фактически, стоимость необходимой безопасности - это разница между возможностями атакующих (на базе фактических инцидентов, а не какого-то теоретического допущения) и способностями SOC (на базе метрик SOC, которые всегда надо считать, в случае любой операционки, иначе невозможно объективно судить о качестве сервиса)

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

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

5. Подход на базе метрик SOC, типа MTTD, MTTR представляется более точным и, самое главное, понятным менеджменту, чем, например, более академические модели оценки зрелости SOC, так как в большей степени подвержены субъективизму со стороны оценщика.

Сколько надо SOC? from Sergey Soldatov

От мониторинга к форенсике и обратно

15.11 выступал на мероприятии с более-менее техническим докладом, выкладываю презентацию.

В докладе были рассмотрены два сценария эскалации - SOC->DFIR и DFIR->SOC, на примере двух реальных инцидентов. Для инцидентов приведены техники и тактики атакующих, а также применяемые методы обнаружения.

От мониторинга к форенсике и обратно from Sergey Soldatov

Приятного просмотра!

SOC на удаленке

Удаленка - отличный способ оценки зрелости ваших процессов!

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

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

Припомним уровни зрелости, - с уровня 2 мы имеем требование повторимости, а с уровня 3 уже говорим о стандартизуемости. Повторимость, тем более, стандартность означает, что процесс документирован и доведен до исполнителей, а они его уже далее самостоятельно исполняют и получают предсказуемый результат. Если исполнители плохо исполняют свою роль в процессе, это значит, что либо процесс плохо описан - это фиксируется качеством документации и Базы знаний, либо исполнители не наработали достаточную практику - это исправляется онбордингом и менторством. Для обеспечения качества Базы знаний необходим процесс Управления знаниями (Knowledge management), крайне важный для SOC - это и данные о собираемой телеметрии, типовых сценариях отработки инцидентов (по-хорошему это должна делать правильная IRP), данные об инфраструктуре заказчиков (при этом база прошлых инцидентов\обращений - также отличный источник, но, ввиду того, что по требованиям по защите PII эти данные нельзя хранить долго, какие-то моменты придется вытаскивать в Базу знаний обезличенными), литература для ознакомления и многое другое. Заметка не про Управление знаниями и не про Базу знаний, поэтому напоследок лишь замечу, что для нее очень важна грамотная маркировка (теги, лейблы, summary, оглавление, и т.п., что упрощает навигацию и поиск).

Онбординг и менторство также заслуживают отдельной заметки, но пару слов здесь тоже оставим. Чтобы онбординг работал хорошо, он должен быть формально описан в виде алгоритма или перечня пунктов: что надо прочитать, какие видео посмотреть, с чем надо разобраться (может, поделать какие-либо упражнения). Здесь помогут описания и разборы прошлых обезличенных инцидентов, лабораторки,  практика - лучший способ обучения. Ментор - это назначенный опытный коллега, к которому можно обратиться по любому вопросу, при этом задача ментора - отрабатывать эти эскалации (обращения от newcomer-а)  в приоритетном порядке. На первых порах - этот ментор в прямом смысле стоит за спиной, в условиях удаленной работы это сделать несложно, так как все современные системы удаленного взаимодействия позволяют показывать экран.

Итак, в зрелом SOC все процессы ясно и понятно описаны, они повторимы на практике, и с ними легко ознакомиться самостоятельно. Есть формальный процесс онбординга, который также можно пройти самостоятельно, и он позволяет максимально быстро и эффективно войти в курс дела. Кроме этого, есть выделенный ментор, который ответит на все вопросы, проконтролирует, что newcomer на практике работает с достаточным качеством.

Уровень 4 модели зрелости требует измеримости. Метрики - неотъемлемая часть любого SOC, - это самый очевидный способ ответить на простые вопросы: насколько эффективно работают аналитики, как часто они ошибаются, какова трудоемкость в зависимости от объемов (уровня SLA, характера и количества систем в мониторинге), какова пропускная способность команды и как необходимо масштабироваться с приходом новых объемов, как изменяется пропускная способность со временем ввиду автоматизации, какова эффективность и результативность детектирующей логики, какова трудоемкость обработки инцидентов в зависимости от уровня критичности и типа атаки, и многое-многое другое. Метрики позволяют постоянно контролировать уровень сервиса и объективно показывать проблемные места.

Анализ метрик - важная задача не только для констатации прошлого и оценки настоящего, но и для угадывания будущего. Анализ метрик для целей будущего и подводит нас к 5-ому уровню модели зрелости, заключающемуся в непрерывном совершенствовании. Именно метрики подсветят проблемные места: в какое время дня\недели\года особенно напряг и с чем это коррелирует, на каких алертах и какие аналитики чаще ошибаются, на каких этапах разбора инцидентов наиболее вероятны ошибки, как изменяется трудоемкость обработки алертов с приходом новых объемов (economy of scale) и т.п. Анализ проблем - источник мероприятий по совершенствованию, и это - непрерывный процесс.

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

Тем не менее, коммуникация - основная проблема удаленной работы. Более 70% процентов информации передается невербальными методами. Здесь, безусловно, есть потеря в передаче некоторой ментальной информации, типа, озабоченности, взволнованности, душевного состояния, а с учетом тяжелой работы аналитиков SOC и потенциальным выгоранием - это крайне важно. Но и здесь можно придумать контроль - увеличение отдельных совещаний 1-на-1 с менеджером, при включенной камере (вообще, включение камеры при синхронных коммуникациях - правило хорошего тона), где можно обсудить не только производственные вопросы, а вообще, все, что угодно, именно в рамках синхронной коммуникации. Подавляющее большинство других коммуникаций можно делать асинхронно. Асинхронная коммуникация - важный фактор эффективной удаленной работы, - это когда мы пишем сообщение и не ожидаем ответ сию же секунду, общение не производится интерактивно. Когда команда распределена географически, асинхронная коммуникация - единственно возможный способ, так как наше рабочее время попадает на период отдыха наших американских и дальневосточных коллег.  Очевидным плюсом асинхронной коммуникации является ее документированность, и, следовательно, возможность ее хранения, последующего анализа и переиспользования, например, для целей обучения. В зрелом SOC документированность коммуникаций внутренних, тем более, внешних - принципиальное требование, так как это - единственный способ сохранения контекста при пересменках аналитиков, а также, для внутренних расследований в случае эскалаций (кто что кому когда написал\посоветовал, какие действия кем были предприняты и т.п.). Именно поэтому для зрелого SOC привычна и естественна асинхронная коммуникация, и это не создает отрицательного эффекта на работу SOC.

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

SOC Forum 2020 Live: Роботы среди нас!

Вкалывают роботы, 

А не человек!

"До чего дошёл прогресс" Крылатов. Энтин

Сегодня на SOC forum рассказывал о машинном обучении для целей триажа алертов.

Выкладываю презентацию.

Роботы среди нас! from Sergey Soldatov

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

FP против FN

Для начала рассмотрим самый известный компромисс между пропусками и ложными срабатываниями.

Поскольку, чем заметнее зло, тем проще его обнаруживать и обезвреживать полностью автоматически, есть непреодолимое желание смещать свою способность обнаруживать автоматизированно (красный пунктир)  в сторону абсолютно невидимого Зла.

Да, это позволит нам снизить Ошибочные пропуски (False negative, FN), но увеличит количество Ложных срабатываний (False Positive, FP), которые, несомненно отразятся на нашей операционной эффективности – нам нужно много людей на первой линии, которые будут заниматься триажем алертов…. 

Типовое применение МашОбуча

Есть два вида машинного обучения: без учителя и с учителем. Первое применимо для поиска похожего, второе - для профилирования и аномалий.

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

Другое применение МашОбуча

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

Так мы придумали Автоаналитика, чему и посвящен мой доклад.

Этапы пайплайна MDR

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

Аналитики получают эти алерты в IRP, смотрят на них. Если сразу понятно, что это фолса – закрывают. Если есть ощущение, что надо посмотреть более пристально – импортируют в Кейс. 

Далее, работают по кейсу в IRP (идут в События, смотрят что было до, что было после, подшивают релевантные события, строят Timeline инцидента). Если после расследования понятно, что это не фолса, пишут описание для Заказчика и публикуют в Портал.

Мечты..., превращенные в цели

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

Этапы пайплайна MDR + ML

Модель встраивается в пайплайн таким образом. Будучи автоматом, Автоаналитк является частью пайплайна автообработки.

Прежняя детектирующая логика решает проблему пропусков (FN), а Автоаналитик быстрого триажа (фильтрации FP).

Входные данные 

На слайде представлен пример реального алерта. Это массив JSON-объектов Событий, каждый объект имеет набор признаков со значениями. В качестве значений может быть что угодно: строка, число, дата, список.

Текущая агрегация

Алерт мы представляем вектором значений полей, причем, если какие-то значения встречаются несколько раз, выбирается наиболее популярное. Полученный вектор передаем на вход Модели.

FPR и TPR

У каждого классифицируемого нами алерта есть истинные классы True и False, и есть классы, предсказанные Моделью, тоже True и False. В таблице приведены все пересечения истинной и предсказанной Моделью разметки.

FPR показывает какой % из истинно ложных алертов Модель классифицировала как True инциденты. Идеальная ситуация, чтобы ложных срабатываний не было и FPR=0%.

TPR показывает какой % реальных инцидентов был распознан корректно. Идеальная ситуация, когда TPR = 100%.

ROC-кривая

Рассмотрим как меняются предсказания Модели в зависимости от Порога. На схеме "горбиками" показаны распределения истинных классов True и False, а жирный красный пунктир – наш порог принятия решения Моделью: все что справа от порога модель предсказывает как True, все что слева – False. На горбиках в зависимости от порога я отобразил уже знакомые нам множества ошибок - FP, FN и верных предсказаний - TP, TN. Горизонтально перемещая порог влево и вправо, мы можем получать разные метрики TPR и FPR. 

Положения нашего Порога и получившиеся TPR и FPR удобно смотреть на ROC-кривой. ROC-кривая также характеризует качество модели – чем больше площадь под ней, тем модель работает лучше.

Схема потока алертов

Мы считаем, что все, что можно алгоритмизировать, должно быть автоматизировано! Поэтому у нас нет понятия "Первой линии SOC, отрабатывающей плейбук".

Весь поток алертов летит в Автоаналитика и чуть более трети он классифицирует как ложное срабатывание, а то, что превышает Порог и заданную Долю фильтрации – отправляет уже на разбор Человеку. 

Маленькие ручейки в виде 3% и 5% - это потоки перепроверки, необходимых для постоянного контроля качества аналитиков.

Послесловие

Этот слайд очень важен, но все что нужно я на нем написал текстом, поэтому пояснений, думаю, не требуется.

Важной ссылкой о теме является доклад Даниила Удимова по этой же теме на профильной конференции.

Благодарности

Автоаналитик был придуман в 2017, а с 2018 уже использовался в сервисе. С тех пор он значительно изменился, и процесс его совершенствования не стоит на месте. Он - продукт труда целой команды выдающихся экспертов, которым спешу выразить безмерную благодарность, и надежду на долгое плодотворное сотрудничество как в данной, так и во многих других областях применения машинного обучения в нашем нелегком Security Operations. Ребята, спасибо Вам!