Привет! Меня зовут Маша, и я являюсь руководителем первой линии Security Operation Center в Ozon.
Наша первая линия постоянно выращивает стажёров и растёт. О стажёрах можно прочитать в статье моего руководителя. Но помимо стажёров, растёт и число обязанностей первой линии, которые необходимо качественно и количественно измерять.
Я поделюсь с вами тем, как мы решили мерить работу первой линии, какую пользу нам принесли метрики, а также с какими трудностями при разработке метрик мы столкнулись и как справились с ними.
Если вы строите подразделение, связанное с технической поддержкой, то вы смело можете примерить наш опыт на себя.
Чем же занимается первая линия?
Всю операционную деятельность первой линии необходимо измерять для того, чтобы корректировать как рабочие процессы, так и кадровый состав. Чтобы понять, что именно мы решили измерять, расскажу подробнее о наших основных задачах.
Обработка пользовательских обращений по вопросам информационной безопасности
Сотрудники первой линии обрабатывают пользовательские обращения в рабочем чате, где сообщения имеют структуру тредов (последовательность ответов на сообщение), и в тикетной системе ведения задач — Jira (где тикет представляет собой одну задачу). Таким образом, первая линия выполняет функцию технической поддержки в аспекте информационной безопасности. Часть вопросов могут носить общий характер, и специалист первой линии может без труда проконсультировать пользователя, но ряд вопросов остаются на решении коллег из смежных отделов, которые оказывают более точечную и глубокую консультацию по своему скоупу.
Обработка автоматизированных уведомлений SIEM-системы
Основной нашей деятельностью, как у многих первых линий SOC, является обработка уведомлений о потенциальных инцидентах ИБ — алертов. Алерты являются потенциальными инцидентами ИБ, поэтому их обработка наиболее приоритетна в работе первой линии. Так как часть алертов действительно перерастает в инциденты ИБ, при их обработке и расследовании привлекаются смежные команды, которые на более глубоком уровне проводят необходимые операции по реагированию и расследованию инцидентов.
Обработка заявок по процессам, переданным на поддержку от смежных команд ИБ
В нашем ИБ-департаменте родилась следующая концепция: первая линия SOC должна максимально разгрузить коллег от выполнения типовых рутинных операций, которые можно уложить в инструкции. Таким образом, появился механизм передачи процессов на первую линию. Этот механизм очень полюбился коллегам смежных команд ИБ, и число процессов на поддержке первой линии стало непрерывно увеличиваться.
Так наша первая линия обросла большим объёмом операционной деятельности, которую хотелось измерять и следить за эффективностью подразделения.
Что решили мерить?
Обработку пользовательских обращений
Тут, по классике, решили мерить количество, время реакции на обращения и время обработки таких обращений, а также процент самостоятельно решённых первой линией обращений.
Для вычисления времени реакции и времени обработки обращений в чате были выбраны соответствующие стикеры:
👀 — обращение взято в работу;
✅ — обращение было обработано.
В качестве критерия, по которому стали делить обращение на решённые первой линией или решённые второй линией, для рабочего чата выбрали разметку тредов определённым стикером — 1️⃣. Этот стикер означает, что обращение было решено первой линией самостоятельно без привлечения коллег из смежных команд (их же считаем в этом контексте второй линией).
Для Jira критерием взятия в работу, а также закрытия обращений является перевод тикета по соответствующим статусам. А критерием самостоятельного решения вопроса первой линией считаем разметку тикетов в поле components.
Из полученных данных вычисляются метрики по:
-
числу обращений;
-
среднему времени реакции на обращения;
-
среднему времени обработки обращений;
-
числу самостоятельно решённых вопросов;
-
числу вопросов, которые решались с привлечением второй линии.
При этом мы определили SLA на время реакции, который считаем допустимым.
Итоговые метрики выглядят следующим образом:
Число созданных и обработанных обращений
Среднее время реакции и закрытия обращений
В нашей парадигме первая линия должна обрабатывать как можно больше обращений самостоятельно, без привлечения коллег из смежных подразделений. Поэтому была введена метрика процента решённых обращений за неделю первой линией. Статистика позволяет оценить, насколько с течением времени первая линия разгружает вторую.
Процент обработанных первой линией обращений по неделям
Благодаря этой метрике мы увидели, что в среднем первая линия стала обрабатывать не менее 50% самостоятельно, хотя раньше этот процент был ниже.
Жизненный цикл алертов
Поговорим про алерты. Так как обработка алертов затрагивает не только первую линию, а ещё аналитиков второй линии SOC и коллег из группы расследования инцидентов — CSIRT (Computer Security Incident Response Team), появилась концепция жизненного цикла алерта.
Она предполагает следующее:
-
Происходит событие или цепочка событий, попадающих под критерии существующих правил корреляции.
-
Согласно заданным расписаниям, происходит создание алерта.
-
Дежурный специалист первой линии берёт алерт в работу и начинает расследование.
-
В зависимости от принятого дежурным специалистом первой линии решения алерт может быть закрыт или же эскалирован на вторую линию, где аналитики второй линии SOC проведут более глубокий анализ произошедшего.
-
Дежурный аналитик второй линии берет алерт в работу и присоединяется к расследованию.
-
В зависимости от принятого дежурным специалистом второй линии решения алерт может быть закрыт или же эскалирован на группу расследования инцидентов.
-
Дежурный специалист группы расследования инцидентов подтверждает алерт и присоединяется к расследованию.
-
Дежурный специалист группы расследования инцидентов выносит вердикт и заканчивает расследование.
Важно уточнить, что на всех этапах расследования сотрудник первой линии сопровождает инцидент ИБ и активно помогает коллегам проводить расследование.
Метрики жизненного цикла алерта отражают, насколько быстро система оповестила нас о событии ИБ, как быстро сотрудники каждой группы отреагировали на алерт и присоединились к расследованию, что позволяет оценить эффективность сотрудников на каждом этапе обработки инцидента ИБ.
Каким же образом вычисляются показатели эффективности?
У каждого алерта есть 3 статуса: открыт, подтверждён и закрыт.
Для взятия в работу алерт переводится в статус подтверждён. Для того чтобы привлечь аналитиков второй линии SOC или же специалистов из CSIRT, у сотрудника первой линии есть соответствующие кнопки в алертах, позволяющие произвести эскалацию в нужную команду.
Для того чтобы коллеги второй линии и CSIRT оперативно подключались к расследованию, настроены соответствующие автоматизации, которые вызванивают нужных дежурных, если алерт не был взят в работу за заданный правилами промежуток времени.
Качество правил корреляции
В силу того, что число обрабатываемых алертов довольно велико, появилась потребность производить их маркировку для оценки качества правил, на которые срабатывают автоматизированные оповещения. Была принята следующая разметка: TP/FP/LTP, где
-
TP (True Positive) — алерт обнаружил событие, которое должен был найти, и данное событие выражает аномальное поведение каких-либо компонентов в системе;
-
LTP (Legitimate True Positive) — алерт задетектировал событие, которое должен был найти, и данное событие мы считаем легитимным;
Довольно часто это сопряжено с работами администраторов в рамках своих задач. -
FP (False Positive) — логика алерта не предполагала поиск такого события, то есть правило отработало неверно.
Таким образом, появилась формула качества правил корреляции:
Quality = (True Positive + Legitimate True Positive)/(True Positive + Legitimate True Positive + False Positive) * 100%
Качество алертов оценивается в связке с количеством сработок для последующего пересмотра правил аналитиками второй линии SOC. Если правило заваливает первую линию большим числом False Positive, то оно должно быть пересмотрено раньше, чем правило такого же качества, но с меньшим числом всех сработок.
Корректность разбора алертов
В силу того, что первая линия постоянно растёт, новые специалисты порой допускают ошибки при разборе алертов. Чтобы понимать, где можно улучшить плейбуки или же провести дополнительное обучение первой линии, была разработана метрика, которая показывает качество разбора алертов. Специалисты первой линии и аналитики второй линии SOC производят перепроверку алертов, анализируя ход расследования, который сотрудник первой линии прописывает к каждому алерту, а также итоговую разметку на легитимность события ИБ. По результатам перепроверки производится маркировка алертов на предмет корректности разбора.
Какие же алерты перепроверяются?
Дежурным первой и второй линий 2 раза в день отправляется список случайно выбранных уже обработанных алертов. При этом неважно, был ли алерт эскалирован или же разобран первой линией самостоятельно.
Таким образом часть алертов будет перепроверена первой линией, часть — аналитиками второй линии, некоторые попадут под перепроверку дежурных двух линий сразу, а часть останется неперепроверенной.
Корректность разбора же вычисляется исключительно по алертам, которые были направлены на перепроверку.
Загруженность L1
Как я писала ранее, первая линия занимается поддержанием процессов от других команд ИБ. Из-за того, что эта активность уж очень полюбилась нашим коллегам, число процессов начало сильно возрастать. Чтобы сотрудники первой линии хорошо «усваивали» новые процессы, сначала была создана очередь — параллельно нельзя передавать два и более процессов. Первое время это действительно нас спасало, но впоследствии и это перестало помогать — число задач в день на дежурных первой линии стало таким большим, что ребята просто не успевали вовремя брать в работу и закрывать задачи. Время реакции и обработки начало расти, что стало видно по метрикам. И вот пришло время посчитать, насколько же загружена первая линия, для объективного варьирования нагрузки.
Были посчитаны человеко-часы, которыми мы обладаем за весь рабочий день с учётом того, что у нас есть 2 сменных и 3 обыкновенных дежурных в сутки.
Затем встал вопрос о подсчёте загруженности по всем операционным задачам.
Чтобы считать загруженность по каждому процессу, мы высчитали число поступающих заявок и время, которое тратится на них. Для каждого процесса посчитали, сколько времени в среднем за сутки тратим на его разбор.
Загруженность по пользовательским обращениям тоже считается подобным образом.
А вот с обработкой алертов у нас возникли нестыковки. Всё дело в том, что алерты могут прилетать пачками и обрабатываться параллельно. Тогда статистика со временем закрытия получается некорректная. Например, если за минуту приходят 5 однотипных сработок, дежурный первой линии берёт их в работу одновременно, затем проводит разбор по всем сработкам параллельно и переводит алерты в конечный статус. Если считать затраченное время по тому же механизму, что и время для заявок по процессам или обращениям, то оно будет почти в 5 раз больше, чем реальное время обработки.
Для того чтобы нивелировать эти погрешности, все время обработки алертов умножается на коэффициент, который учитывает число однотипных алертов, взятых в работу за одну минуту, и присваивает таким сработкам вес. Чем больше однотипных алертов было взято в работу за минуту, тем меньше будет вес.
Таким образом мы снижаем погрешности при подсчёте затраченного времени.
В итоге сопоставляем, сколько суммарно составляют общие временные затраты на всю операционную деятельность и какими человеко-часами мы обладаем, чтобы понять насколько же загружена первая линия.
Если загруженность первой линии меньше 75%, то мы можем принимать на поддержку новые процессы от коллег. Если же загруженность переваливает за 75% и наблюдается очередь из процессов, которые нам планируют передать, то мы своевременно задумываемся о расширении подразделения.
Что же нам дали метрики?
В первую очередь, метрики позволили нам своевременно определять, какие процессы security monitoring’а требуют пересмотра и улучшения. Мы стали легче понимать, что можем автоматизировать, чтобы разгрузить первую линию.
Также метрики дали нам возможность работать более прозрачно.
Мы стали оперативнее реагировать на входящие потоки обращений.
Метрики загруженности позволили принимать кадровые решения и своевременно производить наём новых сотрудников, а также дали возможность оценивать, сколько процессов от смежных команд мы можем принять для разгрузки коллег.
Ну и, конечно, метрики помогают видеть нам слабые места и делать больший упор на обучение и повышение осведомлённости сотрудников первой линии.
Поделитесь, какие метрики считаете вы, и чем они помогают вам в работе.
Автор: Mmmariii
