Да, опять :-) Вообще эта заметка должна была быть опубликована на Хабре. Но я там уже недавно публиковал одну заметку про SOC на удаленке и не могу сказать, что она была воспринята положительно. Хотя и отрицательных отзывов тоже не было. Скорее, она оказалась не в формате Хабра, так как в ней не было "техники", а скорее организационные и психологические аспекты работы аналитиков SOC в дистанционном режиме. Поэтому заметку про дашборды в SOC я решил вынести уже в этот блог, хотя она и опирается на опыт Cisco в этом вопросе. Но так как никаких продуктов Cisco в ней не рекламируется, а высказанные мысли будут полезны широкой аудитории, то пусть лежит здесь.
Допустим, у вас есть playbook по анализу подозрительной активности пользователя и среднее время реагирования на нее (от момента получения сигнала в SIEM и до замораживания учетной записи в AD, помещения узла в карантинный VLAN и поиска других узлов и пользователей, которые могли быть связаны с пострадавшим) у вас занимает около 28 минут. Вы смотрите статистику по отработанным инцидентам и видите, что этот показатель немного скачет в диапазоне от 19 до 37 минут, но в среднем составляет те же 28 минут. Вроде все ОК. Отвлекусь на секунду и отмечу, что в данном случае надо смотреть не среднее арифметическое, а медиану, которая гораздо лучше покажет насколько часто аналитики выходят за средний показатель. В идеале же надо смотреть еще глубже и оценивать время реагирования применительно к разным типам инцидентов, да еще и для разных аналитиков (новичок и бывалый должны иметь разные временные показатели - второй должен работать быстрее).
Но если бы у вас была возможность мониторить все отдельные шаги/задачи playbook, то вы бы увидели, что вместо традиционных 1-3 минут на выявление индикаторов, 1-3 минут их проверки в TI-платформе, 1-2 минут на принятие решения, 3 минут на замораживание учетки и т.п., у вас аналитик сразу после получения сигнала тревоги помещает пользователя и его узел в карантин, а то и вовсе без проверки передает инцидент на следующий уровень, к аналитикам L2. И, примерно, 9-10 минут вообще непонятно, что аналитик делал. То ли он пошел на кухню налить себе кофе, то ли он решил посмотреть новости на смартфоне, а может он просто пошел проветриться или посмотреть на солнце. Но имеющаяся у вас метрика по конкретному инциденту соблюдена. Поэтому так важно оценивать не процесс целиком, а отдельные его этапы и учитывать это в соответствующем дашборде.
ЗЫ. А где же про дашборды? Мы думали примеры будут. Будут. В следующей заметке. Я выше написал, что дашборд - это вершина айсберга. Чтобы дашборд "попал" в нужную аудиторию - надо понимать, что мы хотим (и хотим ли) и что она хочет? И только потом отрисовывать дашборды, о чем я уже подробно писал два года назад.
ЗЗЫ. Еще бы хотел обратить ваше внимание на свою презентацию про измерение эффективности SOC, которую я читал на SOC Forum в ноябре и ее видеозапись.
Итак, исходные данные следующие. Один наш заказчик решил провести аудит своего 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 в ноябре и ее видеозапись.
