Про скорость реакции написано немало, да и про критичность инцидентов. Почему-то в большинстве SLA/OLA, что я видел, скорость реакции ожидается тем выше, чем выше критичность инцидентов, но это не совсем корректно. Критичность инцидентов определяется их природой и потенциальным\фактическим ущербом, и это правильно, однако, для принятия решения как быстро надо реагировать нужно еще и понимание мотивации атакующего.
Отчасти для этого и нужны все исследования кластеров активности (будем это все называть общим термином Threat Intelligence, TI) и последующие попытки их атрибуции в реальных инцидентах: понимание мотивации определяет требуемый режим реагирования. Приведу простые примеры: если задача атакующего закрепиться в инфраструктуре и пассивно следить за происходящим, иными словами, - сбор данных, разведка, то реагировать можно в спокойном режиме, риска положить инфраструктуру жертвы нет, так как задача как раз сидеть в этой инфраструктуре и собирать разведданные; но после успешного респонса с вероятностью практически 100% атакующие вернутся, так как если жертва продолжила заниматься тем же, интерес у атакующих сохранился, а если мы говорим о военных, то боевая задача должна быть точно выполнена. Если же мы имеем дело с операторами шифровальщиков и вайперов, то здесь надо поторопиться, так как уничтожение инфраструктуры здесь - вероятная цель атаки.
Итак, необходимая скорость реакции, возможно, и зависит от природы инцидента, но в не меньшей степени она определяется мотивацией атакующих. Следует заметить, что в зрелых классификациях, подобных приведенной выше, учитывается потенциальный ущерб, если он увеличивается с ростом продолжительности присутствия атакующего в инфраструктуре, а ущерб - более универсальный инструмент классификации, учитывающий и мотивацию атакующего.
Я не раз говорил, что задача ИБ - не обеспечить отсутствие инцидентов, а обеспечить отсутствие ущерба, т.е. нам необходимо остановить развитие атаки до момента, как защищаемая инфраструктура будет испытывать ущерб. Изменение размера ущерба для компании с ростом продолжительности атаки тоже не дискретно, а, скорее, непрерывно, допустим, как на картинке.
Логично предположить, ущерб растет в зависимости от продолжительности присутствия атакующего в инфраструктуре, а с момента начала достижения атакующим цели рост становится стремительным. Глядя на этот график, несложно заметить, что существует некоторый размер ущерба, который можно считать допустимым. Я бы определил его так: допустимый ущерб - это такой, последствия которого можно устранить в рамках операционной деятельности подразделений ИТ и ИБ (т.е. когда ресурсов, заложенных в стандартные процессы Управления изменениями и Управления инцидентами на предприятии достаточно), а работа корпоративных бизнес-процессов, если и нарушена, то в рамках допустимого. Допуская наличие допустимого ущерба мы допускаем (:-)), что сеть подломана и у нас где-то есть злоумышленник, что прекрасно согласуется с концепциями и Assume breach и Assume vulnerable, а также с очевидной биологической аналогией про вирусов и иммунитет - в нам куча бактерий и мы вполне нормально с ними уживаемся, пока не болеем.
Допустимый ущерб для разных компаний различен и зависит от множества факторов - как от возможностей корпоративной операционной безопасности, так и от мотивации, техник и инструментов атакующих, поэтому вполне возможны ситуации, когда привлекать команду DFIR к реагированию на человекоуправляемую атаку (рекомендация по умолчанию в MDR) не требуется и все реагирование может быть выполнено исключительно инструментальными средствами, а то и полностью автоматически. Пример такой ситуации - шпионаж, когда мотивация атакующих заключается в долгом присутствии в инфраструктуре, сборе информации и последующей ее эксфильтрацией. Такая ситуация нередко наблюдается в госучреждениях, и здесь недопустимый ущерб начинается с момента эксфильтрации, а действия атакующего до этого момента, при условии сохранения возможности их остановить, попадают в область допустимого ущерба. В этом случае как будто неэффективные меры "отрезания постоянно отрастающих голов\щупальцев\хвостов" оказываются вполне эффективными: атакующие приносят новые инструменты и заводят новые C&C, команда MDR их обнаруживает и блокирует, и атака снова отбрасывается на начальные эатапы. При этом, скорее всего, присутствие в инфраструктуре атакующих сохраняется, например, на хостах вне объема мониторинга.
Ранее я отмечал, что в подобных разведоперациях, даже после результативного DFIR, когда, допустим, атакующих полностью вычистили, спустя время они точно вернутся. Да, DFIR их отбросит за первоначальный доступ и потребуются новые закрепления, поэтому этап эксфильтрации (недопустимого ущерба) будет отложен на более продолжительный срок, но нам надо быть эффективными и сравнивать себестоимости DFIR, но более редкого, и оперативного реагирования в рамках MDR ("отрезание постоянно отрастающих щупальцев"), но значительно более частого.