После N+1-ого раза, потраченного на доказательство, почему время реакции для инцидентов в один час - это нормально, решил написать эту заметку. Под временем реакции я здесь понимаю время с момента создания самого раннего события по инциденту, до момента публикации карточки инцидента с рекомендациями заказчику, например, через сервисный Портал.
Скажу сразу, что те, кто анонсирует 15-20 минут, вероятнее всего, под временем реакции понимают что-то иное, а некорректное восприятие этих 15-и минут уже [умышленно] создано мастерами маркетинга.
Невозможно управлять тем, что ты не можешь померить, поэтому в случае сервиса Kaspersky MDR я могу точно (на основе прошлых результатов работы) сказать сколько времени тратится на каждом этапе жизненного цикла инцидента. Как не раз отмечал, например, здесь, четкое понимание сколько и на что мы тратим времени дает почву для планирования будущей автоматизации.
Итак, давайте просто посчитаем. В среднем, в нашем случае это выглядит так: алерт (alert) из события будет создан в течение ~5 минут (если глубина корреляции требуется больше, то и еще позже), и назначен умным роботом Alert Assigner на аналитика. В течение 5-10 минут (среднее время ноября было 8 минут), алерт будет взят в рассмотрение и аналитик начнет его расследование. Здесь надо выделить два этапа: первоначальный триаж, в рамках которого аналитик бегло понимает, что алерт заслуживает внимания, нужно ли его обрабатывать прямо сейчас или можно отложить. Алерт может быть игнорирован как ложное срабатывание сразу на этапе алерта, либо импортирован в "кейс" (case) для дальнейшего расследования. По нашей статистике алерты, которые были сразу игнорированы как фолса в рамках триажа и алерты, которые были признаны положительными срабатываниями после расследования кеса имеют различное время триажа. Время триажа алерта, в итоге импортированного кейс больше, и в последнем исследовании составляло около 4 минут.
После импорта, уже над кейсом начинатся расследование. Расследование представляет собой построение полного таймлайна происходящего: поиск всех связанных событий, предшествующих алерту и следующих за ним, подтягивание релевантного TI и информации об инфраструктуре заказчика. Это время очень разное, так как в различных ситуациях степень автоматизации сбора связанных событий и TI различна. Мы будем рассматривать сценарий человекоуправляемой полностью нестандартной атаки, так как, во-первых, по нашей классификации инцидентов именно такие случаи получают высокий уровень критичности, во-вторых, брать за основу сценарий с наивысшей степенью автоматизации не показательно, например, у нас есть полностью автоматически обрабатываемые инциденты, когда с момента создания алерта до момента публикации проходит не более 7-10 минут, однако, очевидно, что это не повод указывать даже в маркетинговых листовках, что у нас время реакции не превышает 10 мин. Среднее время расследования алерта по состоянию на ноябрь у нас составляло около 11 минут.
Собрав всю картину, аналитик начинает оформлять карточку инцидента для заказчика. Здесь, опять же, на типовые инциденты у нас есть шаблоны карточек, где текст заполняется автоматически и подставляются нужные поля из алерта, однако, для полностью уникальной человекоуправляемой атаки шаблоны редко применяются и большую часть карточки инцидента аналитик описывает вручную в соответствии с внутренним чеклистом. Эта часть наиболее продолжительная по времени и, чтобы уложиться в 1 час для критичного инцидента мы идем на "хитрость", публикуя самое важное с указанием, что будем по мере расследования обновлять информацию в инциденте. В среднем, время на оформление карточки инцидента составляет 19 минут, для инцидентов высокой критичности оно сильно различно, но, в среднем, превышает время оформления инцидентов средней и низкой критичности, тем более, что последние очень часто хорошо шаблонизируются. Поэтому не будет большой ошибки, если для нашей оценки мы возьмем время оформления карточки около 20 минут.
Сейчас мы даже не берем во внимание, что после публикации инцидент может не останавливаться, атакующий может продолжать свою деятельность и нам будут продолжать прилетать алерты о его новых похождениях, мы будем собирать новые алерты, в уже существующий кейс, проводя его дорасследование, дописывать новую информацию в карточку, перепубликовывать ее заказчику - это тоже время триажа, расследования и оформления инцидента. Возьмем только время до момента первой публикации, и оно уже составляет: 5 + 8 + 4 + 11 + 20 = 48 мин.
Да, можно, сэкономить на наиболее трудоемких операциях - оформление карточки инцидента с рекомендациями (20 мин) и расследовании (11 мин), ну, пусть даже, в два раза, получим 33 минуты. Снова не 15 и не 20 мин, и даже 30 мин - достаточно рискованно, ну, или если только с потерей качества результата (как, например, неполное расследование или поверхностные рекомендации).
Далее, можно оптимизировать время нахождения в очереди (8 мин), но здесь тоже есть оценка. Анализируя, поток алертов (~работа, выпадаемая на команду аналитиков) нетрудно заметить плохую предсказуемость объема. Поэтому, чтобы обрабатывать всплески, нужно иметь запас трудоемкости команды. Большой резерв трудоемкости делать не разумно, так как это приведет к слабо обосновываемому росту себестоимости за счет увеличения числа аналитиков, но около 15-30% надо иметь, а остальное как раз будет компенсироваться допустимой длиной очереди (понятно, что длина очереди должна помещаться в SLA). По моей грубой оценке, основанной на истории всплесков, чтобы гарантировать длину очереди на обработку в 0 минут, т.е. алерт сразу брать в работу, как он был назначен, и в таком режиме отрабатывать всплески, резерв общей трудоемкости команды должен быть минимум +50-70%, а лучше х2, что очевидным образом повлияет на увеличение стоимости. Поэтому допустимая длина очереди - разумный компромисс. Кстати, вместе с этим длина очереди - хороший индикатор нагрузки команды: если наблюдается стабильный рост длины очереди, пришло время расширять команду аналитиков.
В общем, у MDR есть время работы и его некорректно сравнивать, например, с временем работы Endpoint-а. Если атака почему-то была пропущена во время превоначального пробива, горизонтальных перемещений, провышения и сейчас уже запустили автоматический шифровальщик, то человекоуправляемое реагирование MDR здесь будет проигрывать в скорости полностью автоматическому Endpoint-у. Однако, отмеченные выше тактики - как раз профиль MDR, и в большинстве случаев атакующий будет замечен и отреагирован раньше, чем успеет запустить свой, приносящий ущерб, инструмент. Снова банальщина - каждый инструмент хорош в своем сценарии, действительно, мы не забиваем гвозди микроскопом и не изучаем в бинокль строение молекулы.
Нередко, заходя с пилотом MDR или проектом Compromise Assessment мы находим атакующих, которые месяцами, а то и годами сидят в инфраструктуре. Это тоже человекоуправляемые атаки и для нас они тоже были бы инцидентами уровня High, и первую карточку мы бы опубликовали заказчику в течение часа. Не 30 мин, и не 15 мин. Вот давайте на минуту задумаемся, если ребята сидят уже год, нам принципиально, оповестят ли об этом в течение часа или 30 мин?!