SLA для Threat Hunting-а

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


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

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

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

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

Устали от того, что Интернет знает о вас все?

Присоединяйтесь к нам и станьте невидимыми!

Сергей Солдатов

REPLY-TO-ALL is a double language blog (English/Russian) run by three information security practitioners. Want to discuss information security problems? This is the place.