SLA для Threat Hunting-а

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

Любая работа SOC характеризуется определенными параметрами уровня сервиса, закрепленными в Соглашении. Традиционно, - это Время реакции и Время решения. Threat hunting (TH), вроде как, тоже работа SOC, а значит, тоже должны быть метрики времен реакции и решения... А вот и нет! 

Эти метрики предполагают, что есть некоторая точка во времени, откуда начинается их отчет, т.е. они по определению неразрывно связаны с Alerting-ом. ТН же предполагает проверку гипотезы путем анализа множества показателей, каждый из которых по отдельности еще не является свидетельством атаки, однако совокупность таких признаков, под соусом всевозможного Threat intelligence, помноженная на опыт аналитика - вполне может ею быть. На практике ТН реализуется как совокупность поисковых запросов, выдающих некоторый список кейсов, которые надо "отсмотреть" и расследовать, путем все тех же запросов, но с уже с уточненными условиями, - получить новый список кейсов, которые также надо проверить и т.п. - процесс итеративный. Обнаружив через последовательность таких запросов подозрение на атаку, аналитик регистрирует инцидент. В этом подходе нет Alert-а (или есть, но он не представляет собой точный детект, требующий уже реакции, но требующий проверки) от которого начинают свой отчет Время реакции и Время решения, и поэтому такие метрики здесь не подходят. Да они и не нужны, - в случае целевой атаки, согласитесь, если вы были взломаны по меньшей мере последние 6+ месяцев, дополнительные несколько дней на время реакции\решения - не принципиальны.

Но, раз мы занимается чем-то, очевидно, это что-то надо уметь мерить, иначе просто не понятно делаем ли мы это хорошо, и вообще, нужно ли это делать, поэтому метрики нужны. Можно предложить следующие:
1. этап атаки, когда вы ее обнаружили - характеризует оперативную готовность, а также способность обнаруживать атаку на разных стадиях (очевидно, обнаружить надо уметь на всех этапах и, по возможности, как можно раньше);
2. абсолютное время с момента компрометации - спустя сколько времени с момента взлома обнаружили (надо учитывать только то время, в которое проводился ТН);
3. критичность обнаруженного инцидента - важно для планирования реагирования;
4. % и тип ложных срабатываний - определяет с одной стороны - качество подходов к обнаружению, а с другой стороны - эффективность расходования ресурсов ТН;
5. гипотеза, которая сработала, - гипотеза может быть оформлена, например, в виде цепочки связанных событий, что технически может быть реализовано в виде последовательности связанных поисковых запросов и частично может быть автоматизировано - нужно анализировать результативность гипотез (сразу замечу, что это не просто количество успешных "хитов", а более сложная метрика, учитывающая современные тренды, "моду" на те или иные ТТР атакующих), ну, как минимум, чтобы, придя в поле, приоритезировать свою работу, проверяя в первую очередь гипотезы, наиболее часто дающие положительный результат (вообще, для гипотез надо иметь своего рода процесс Управления изменениями, чтобы отслеживать все их параметры: фолсивость, трудоемкость проверки, актуальность/современность, где/кто использовал такие ТТР и т.п., - это заслуживает отдельной заметки);
6. степень автоматизации - параметр который, преодолевая все трудности насколько это возможно, надо стремиться увеличивать со временем (== его надо контролировать);

Тема ТН последнее время популярна, поэтому есть масса публикаций, в том числе и по тематике измерений. Возникшие идеи приветствуются в комментариях.