Постройтесь в линию: как мы набивали шишки на создании процессов выявления и реагирования на кибератаки

 И все остальные – “просто аналитики”, в чьи обязанности входило углубленное расследование инцидентов за рамками типового процесса и SLA, создание правил детектирования новых угроз, а также плотная работа с заказчиком (анализ общего уровня защищенности, проработка максимально эффективного пула сценариев для покрытия модели угроз, подключение новых источников, проработка необходимого уровня аудита, написание парсеров/коннекторов и т.д.).

Мы сознательно не строили многоуровневую линейную модель эскалации расследования инцидентов по линиям 1->2->3-> и т.д. Наверное, просто потому, что не смогли придумать, как уложить подобную парадигму расследования в экстремально короткий SLA на решение инцидентов (0,5–2 часа), причем 30 минут на разбор инцидента далеко не редкость, такие кейсы составляют значимую долю в общем потоке.

То есть по большому счету линия обработки инцидентов была одна – первая, она же и последняя. К ней предъявлялись требования по полному расследованию всего пула типовых инцидентов в рамках типового шаблона уведомлений. И эта схема работала вполне себе хорошо. До той поры, пока не заказчиков не стало больше. Это привело к необходимости масштабировать ресурсы и параллельно выполнять взаимоисключающие требования разных заказчиков. Одни говорили, что им нужны более глубокие расследования и вопрос тайминга вторичен, другие хотели максимально быстрых уведомлений об инцидентах, пусть даже с неполной информацией на начальном этапе.