В старой статье я рассказывал о том, что причина ложного срабатывания может быть совсем разной, а, следовательно, обрабатывать его надо по-разному: в общем случае, либо необходимо дорабатывать детектирующую логику, либо заниматься адаптацией под конкретного клиента, последний случай значительно более частый.
Оба описанных "зафолсения", т.е. признание алерта ложным срабатыванием, происходит на линии поставщика решения. Однако, опубликованный клиенту инцидент, классифицированный командой SOC как True positive, может вернуться как False positive (FP) уже от клиента.
Такой FP тоже надо учитывать, поскольку он, в общем-то, определяет бизнес-ценность работы SOC для клиента. Однако, проблема в том, что, к сожалению, клиент не всегда возвращается с обратной связью был ли опубликованный инцидент TP или FP (а это очень важно!), а так как здесь мы имеем высокую ступень неопределенности, определяемую желанием\возможностями конкретного клиента, такие данные могут даже не собираться. Не собираются они далеко не ввиду лени, а потому что их наличие полностью зависит от клиента, даже от конкретных представителей, а делать какие-либо выводы и прогнозы из столь субъективных данных дело неблагодарное. Однако, учет только FP на линии поставщика приводит к неочевидным, на первый взгляд, последствиям.
В заметке я рассказывал о разных типах клиентов, используемых для подсчета конверсии. Ожидаемый результат, что по новым клиентам и пилотам конверсия должна быть наихудшая, так как не прошла адаптация. Подавляющее большинство новых клиентов приходят после пилотов, поэтому ожидаемая конверсия должна улучшаться в последовательности: пилоты - новые - коммерческие, где наименьшая - на пилотах, а наибольшая - у коммерческих клиентов.
Но на практике выходят следующие цифры (про Автоаналитика можно почитать здесь).
Из картинки мы видим, что чаще конверсия для пилотов (PoC) и новых (New) клиентов выше, чем по клиентам, для которых наиболее интенсивная адаптация уже закончилась (Comm). Попробуем это объяснить, да и вообще порассуждаем над наблюдениями.
- Сам процесс адаптации. В 2016 году, на заре MDR, мы пытались заполнять с клиентами огромные опросники об особенностях инфраструктуры, однако, это работало плохо. В итоге, решили просто в процессе управления инцидентов адаптироваться: публикуем инцидент, если получаем информацию, что FP, выпускаем клиентский фильтр. В комбинации с внутренним принципом "лучше опубликовать фолсу, чем пропустить инцидент", получаем, что за период адаптации клиент получает больше инцидентов, которые могут быть классифицированы как FP только клиентом (поскольку мы пока еще плохо знаем клиента, и узнаем его через его инциденты). Если FP на стороне клиента не учитывается как FP, очевидно, это повышает конверсию.
- Клиенты, по которым не прошла адаптация (PoC, New) вносят значительный статистический шум и их исключение из рассмотрения дает более объективную картину. Позитивно, что в подавляющем большинстве случаев такое исключение приводит к росту конверсии относительно средней по всем (сравниваем "TPR with ML" с "Comm TPR with ML"). Действительно, количество пилотов и новых клиентов сильно меняется от месяца к месяцу (от единиц до нескольких десятков), и клиенты сильно разные и по степени кибергигиены в сети, и по характеру работы, в итоге результаты от месяца к месяцу по ним выглядят абсолютно несравнимыми и необъяснимыми, а данные хочется объяснять, чтобы предсказывать будущее.
- И еще момент. Пилот длится ограниченное время и полное появление всего объема в мониторинге имеет некоторое распределение по времени (несмотря на то, что активация выглядит как настройка политики EPP, ее применение не происходит мгновенно). Ограниченный объем телеметрии не позволяет качественно расследовать инцидент, а в совокупности с упомянутым выше принципом "лучше зарепортить фолсу, чем пропустить", получаем также увеличение потенциальных FP на стороне клиента.
Итог очевиден: FP на стороне клиента нужно учитывать, либо как отдельный тип ложного срабатывания, либо как статус клиентского закрытия (наш сценарий). Ну и обязательно использовать все возможные средства, чтобы клиент все-таки давал обратную связь (только так мы можем узнать друг друга лучше, а это, как и в браке, залог долгого успешного совместного существования), и статистика клиентских ложных срабатываний по-минимуму зависела от настроения клиента общаться с нами.