О дашбордах для SOC

Итак, исходные данные следующие. Один наш заказчик решил провести аудит своего SOC и среди прочих задач, одна звучала так «Провести анализ существующей системы метрик оценки эффективности SOC и их представлений в виде дашбордов и отчетов». Могу сказать, что это достаточно редкая задача, так как по нашему опыту (а он измеряется не менее сотни спроектированных и примерно столько же проаудированных центров мониторинга) до оценки того, как работает SOC и его аналитики, руки доходят не всегда. Проработать архитектуру, отрисовать процессы, разработать Use Case и playbook… Это да, очень востребованные услуги. А вот так, чтобы оценивать свою эффективность, да еще и демонстрировать ее… до этого созрели далеко не все владельцы SOC.    

Проекты по созданию дашбордов… Хотя нет. Дашборды — это всего лишь верхушка айсберга. На самом деле речь может и должна идти о проектах именно по оценке эффективности SOC. Так вот такие проекты часто проваливаются, так как для того, чтобы они выстрелили нужны соответствующие верифицированные данные и умение с ними работать, то есть правильно ставить вопросы, подбирать данные, визуализировать их, а также делать выводы и вносить изменения в процессы. Если на каком-то этапе у нас происходит сбой, то и вся системе оценки эффективности дает сбой и мы вновь возвращаемся к набившим оскомину — время обнаружения инцидента, время реагирования на инцидент, загрузка аналитика SOC и т.п. В целом, эти метрики неплохи, если мы знаем, зачем они нам и что мы хотим сделать на их основе. Просто отображать время взятия инцидента в работу недостаточно. И постоянно лишать премии аналитиков за то, что они вместо 3-х минут «по SLA» инцидент берут за 3 минуты 12 секунд, тоже неправильно. Надо понять, почему так происходить и что сделать, чтобы улучшить показатель (или изменить SLA).

Оценка эффективности SOC — это процесс, до которого надо дозреть. И который выстраивается также поэтапно, как и сам SOC. Это не разовый продукт, который можно купить, завести на него источники данных и забыть. И рассчитывать, что консультант решит за заказчика все проблемы с оценкой эффективности за один раз тоже наивно. Начинается все с прототипа, который постепенно доводится до состояния инструмента, помогающего принимать решения, а не «картины, закрывающей дырку в стене».

Первый дашборд — всегда прототип. Его задача подсветить слабые места в том или ином процессе.  И вот тут самое главное — противодействовать сопротивлению руководителей групп аналитиков, которые будут утверждать, что никаких проблем у них в процессах нет и «все так и должно быть». Очень часто такие руководители утверждают, что они доверяют своим подчиненным, ставят ему верхнеуровневые задачи, а потом спрашивают результат. А контролировать и разбираться, почему процесс работает не так, как задумано, медленно или не полностью охватывает всю область действия SOC, это, мол, не задача руководителя. Хотя именно в этом и заключается его задача. И перебарывать сопротивление таких руководителей должен уже не консультант, который дает инструмент, а руководитель SOC (если он хочет это делать) или руководитель службы ИБ или руководитель компании, который инвестировал много денег в SOC и хочет получить результат на все 100.

Допустим, у вас есть playbook по анализу подозрительной активности пользователя и среднее время реагирования на нее (от момента получения сигнала в SIEM и до замораживания учетной записи в AD, помещения узла в карантинный VLAN и поиска других узлов и пользователей, которые могли быть связаны с пострадавшим) у вас занимает около 28 минут. Вы смотрите статистику по отработанным инцидентам и видите, что этот показатель немного скачет в диапазоне от 19 до 37 минут, но в среднем составляет те же 28 минут. Вроде все ОК. Отвлекусь на секунду и отмечу, что в данном случае надо смотреть не среднее арифметическое, а медиану, которая гораздо лучше покажет насколько часто аналитики выходят за средний показатель. В идеале же надо смотреть еще глубже и оценивать время реагирования применительно к разным типам инцидентов, да еще и для разных аналитиков (новичок и бывалый должны иметь разные временные показатели — второй должен работать быстрее).

Но если бы у вас была возможность мониторить все отдельные шаги/задачи playbook, то вы бы увидели, что вместо традиционных 1-3 минут на выявление индикаторов, 1-3 минут их проверки в TI-платформе, 1-2 минут на принятие решения, 3 минут на замораживание учетки и т.п., у вас аналитик сразу после получения сигнала тревоги помещает пользователя и его узел в карантин, а то и вовсе без проверки передает инцидент на следующий уровень, к аналитикам L2. И, примерно, 9-10 минут вообще непонятно, что аналитик делал. То ли он пошел на кухню налить себе кофе, то ли он решил посмотреть новости на смартфоне, а может он просто пошел проветриться или посмотреть на солнце. Но имеющаяся у вас метрика по конкретному инциденту соблюдена. Поэтому так важно оценивать не процесс целиком, а отдельные его этапы и учитывать это в соответствующем дашборде.

ЗЫ. А где же про дашборды? Мы думали примеры будут. Будут. В следующей заметке. Я выше написал, что дашборд — это вершина айсберга. Чтобы дашборд «попал» в нужную аудиторию — надо понимать, что мы хотим (и хотим ли) и что она хочет? И только потом отрисовывать дашборды, о чем я уже подробно писал два года назад.

ЗЗЫ. Еще бы хотел обратить ваше внимание на свою презентацию про измерение эффективности SOC, которую я читал на SOC Forum в ноябре и ее видеозапись.