С 16-ого года мы по-русски говорим о Threat hunting-е, как о ручном поиске угроз и его отличии от классического alerting-а. Тем не менее, некоторой степени TH можно свести к алертингу, создав нотификации на проверяемые гипотезы (действительно, зачем их проверять вручную, когда можно автоматизировать?!). Справочник техник давно есть и, вроде, понятно что делать: берем технику, эмулируем в лабе, смотрим, за что можно зацепиться так, чтобы получившийся алерт можно было бы использовать на практике. В процессе этого исследования станет понятно какой телеметрии еще не хватает, и какая предварительная обработка (обогащение, агрегация, корреляция, т.п.) ей требуется. Но, какие бы обобщенные подходы к обнаружению мы не придумывали, мы все равно, в большей степени действуем реактивно. Более того, все подряд продетектить невозможно и не нужно, - здесь, как и везде, важна "золотая середина": бессмысленно решать задачу защиты от всех возможных атак или их обнаружения, - это также невозможно как убить все вирусы и микробы в организме человека... И здесь остро встает вопрос своевременности выхода детектирующей логики - как понять, когда еще не поздно, но уже не рано.
Чтобы ответить на этот вопрос рассмотрим как появляется атака. Любая новая техника атаки имеет примерно следующие этапы жизненного цикла (некоторые этапы можно переставить местами, разбить на более мелкие этапы, и долго это дебатировать, но в большинстве это так):
Этап 1. Когда у ресечера есть идея, он придумал\обнаружил технику. Каких-то подтверждений ее широкого применении на практике пока не наблюдается. Пример: Саша Родченко придумал\нашел технику, рассказал о ней, зарепортил ее в MITRE, которая одарила его указанием как “Kaspersky” среди контрибьютеров.
Этап 2. В Интернете есть публикация в общих чертах, или даже есть подробная, но нет PoC реализации, на базе которого можно было бы сделать свою.
Этап 3. Есть PoC, который с незначительными доработками уже можно использовать
Этап 4. Этот PoC активно используется в пентестах. Т.е. PoC уже не просто доступен на git, но народ о нем уже знает и использует
Этап 5. Техника реализована в популярных пентестерских фреймворках. Более-менее полный список модных тулсетов можно посмотреть здесь.
Этап 6. Техника используется ITW, часто попадается в APT или commodity malware.
Этап 7. Техника проверяется в тестах (например, MITRE), и для вендора был бы неудобен ее пропуск. Также, к этому этапу можно отнести ситуацию, когда "у коллег по цеху это есть", следовательно вендору надо идти в ногу со временем - в самом простом случае это также выясняется на тесте.
На мой взгляд, разумно не стремиться сделать ханты/IoA на все подряд, и та "золотая середина", баланс между "слишком рано" и "слишком поздно" – этап 4. Этап 3 - слишком рано, - немного смысла в продетекчивании всего github-а, Этап 5 - слишком поздно, так как атака уже автоматизирована и любой script-kiddie сможет ее реализовать.
Получаем, что надо стремимся успешно трекать работу пентестеров. Именно поэтому для threat hunter-ов важен offensive опыт, поскольку чтобы уметь обнаруживать пентестера, надо самому быть пентестером. Опыт показывает, что редтимерско-CTF-ные увлечения способствуют успеху блютимера, особенно, в части придумывания подходов к обнаружению угроз. Поэтому я приветствую у наших ребят ранки на HTB и стремление сдавать OSCP/OSCE, так как полученный при этом опыт обязательно конвертируется практический успех.
