Классификация инцидентов исключительно по критичности нетрудоемка в реализации, но не позволяет делать какую-либо аналитику, а это очень надо, ибо целью управления инцидентами является не полное искоренение инцидентов (что невозможно), а повышение вероятности их переживания без ущерба - об этом я еще напишу отдельную заметку, так как, судя по частому вопросу: "Кто виноват в том, что инцидент случился?", полного понимания в вопросе нет. А пока поговорим о классификации по природе, используемой нами в MDR, и в каждом аналитическом отчете ее можно встретить, тем более, что я обещал представить эту классификацию, а обещания надо держать.
Итак, классификация инцидентов по их природе на момент их обнаружения (Дзен не достиг великих возможностей, позволить вставить табличку, поэтому, к сожалению, картинка).
Рассмотрим, как работает эта классификация на примере инцидентов высокой критичности.
Любая человекоуправляемая атака получает классификацию inc_apt. Если в доступном нам TI нашлись пересечения с известными группировками, мы предоставляем эту информацию в инциденте. Как правило, в инциденте мы уточняем у заказчика легитимность наблюдаемой активности, и если нам подтверждают, что да, например, это работают аудиторы, классификация изменяется на легитимную человекоуправляемую атаку - inc_rt. Если мы находим артефакты человекоуправляемой атаки, например, kirbi-файлы, дампы LSASS, дампы веток реестра с паролями, но на момент обнаружения всего этого активной работы человека-атакующего нет, инцидент классифицируется как inc_apt_trace, - в данном случае можно сказать, что мы наблюдаем пассивные артефакты. Понятно, что за любой атакой стоят люди, особенно когда мы говорим об инцидентах высокой критичности, а ВПО - это инструмент, но в рамках возможностей телеметрии MDR и времени, доступного аналитику на классификацию инцидента, проследить обнаруженное ВПО прямо до заинтересованного атакующего не всегда возможно. В подавляющем большинстве случаев атак с участием ВПО без активного атакующего человека такие инциденты будут классифицированы как Medium-критичности, однако, в ряде случаев, когда ВПО имеет потенциально большой ущерб, инцидент размечается критичностью High, например, это может быть атака шифровальщика, обнаруженная на этапе, когда активных действий атакующего уже не видно. Если кому-то, как и мне, важны аналогии, то обсуждаемый inc_mw_impact, можно интерпретировать как обнаружение активных артефактов :). inc_vuln_impct - обнаружение критичной уязвимости, которая, скорее всего, будет эксплуатирована, например, она на периметре или эндпоинт, где ее обнаружили, доступен из Интернет. Замечу, что если уязвимость уже проэксплуатировали и наблюдается развитие человекоуправляемой атаки - будет inc_apt, а если человека не видно, какой-то самоходный WannaCry, то будет inc_mw_impact. Иногда видим атаки на отказ в обслуживании - классифицируем inc_dos_impact, но таких инцидентов немного, MDR - не самый эффективный инструмент защиты от DDOS. Если мы наблюдаем подозрительные действия от литимной учетной записи, и при этом нет оснований считать, что она скомпрометирована, инцидент временно классифицируется как "нарушение политики безопасности" - inc_sec_policy_h, если такой инцидент заказчик подтверждает как работу внутреннего нарушителя (нечасто, но бывает) классификация меняется на inc_incider_impact. Если инцидент был обнаружен на этапе социальной инженерии и эта атака была успешна, хоть далее развитие и не пошло (например, эндпоинт отработал по поведению, и инцидент не развился до inc_apt или inc_mw_impact), то здесь классификация будет inc_se_impact.
По каждому типу инцидентов во внутренних инструкциях есть примеры инцидентов, также есть схема принятия решения, но полностью избежать субъективизма не всегда удается. Но ситуация исправляется на перепроверках, поэтому результирующая статистика вполне может считаться достоверной.