SOC – это люди. «Алло, мы ищем таланты» или откуда берутся аналитики цетра мониторинга и реагирования на кибератаки
Сегодня даже беглый поиск по hh.ru выдает около 90 разных по задачам и функционалу вакансий с магическим словом «аналитик» и довольно приличными условиями оплаты. Перед глазами многих кандидатов сразу проплывают большие данные и машинное обучение, зарплата начинать плясать сильно выше рынка и заигрывать нулями. Так кто же такие аналитики центра мониторинга, «отвечающие за то, чтобы заказчика не взломали»? Чем они занимаются и что нужно знать и уметь, чтобы попасть на эту позицию?
В прошлых статьях мы говорили, что в перечень основных задач аналитика 3 линии входят:
- Анализ аномальных активностей с целью выявления инцидентов.
- Реагирование на нетиповые критичные инциденты своих Заказчиков.
- Участие в расследовании инцидентов ИБ, не зафиксированных мониторингом
- Техническое обследование, подключение и адаптация источников событий.
- Разработка новых сценариев выявления инцидентов.
Если резюмировать, то аналитик несет ответственность за технические аспекты мониторинга киберугроз у Заказчика. Не шлет логи источник, не отпарсилось событие, не сработал или сфолсил сценарий, пропустили атаку — за все отвечает закрепленный за Заказчиком аналитик.
Однако это не значит, что все аналитики Solar JSOC к 30 годам седые или лысые. Не все. Просто эта роль подразумевает высокие требования к ее исполнителю. Попробуем расписать их чуть подробнее.
Повелители SIEM
В описании вакансии часто пишут: «Опыт работы с SIEM-системой». С одной стороны, все понятно: SIEM — это движок SOC, без него сервис, как говорится, «не поедет». (У некоторых экспертов есть возражения и свои, имеющие право на жизнь, теории построения SOC без SIEM, но все же это не тема нашей статьи.)
Однако фактически за этими словами состоит нечто большее, чем умение смотреть в логи определенной ИТ-системы.
Аналитик должен уметь моделировать векторы атак на основе минимального объема информации об инфраструктуре Заказчика. Конечно, бывает, что при подключении Заказчика мы получаем от него полную информацию по подсетям L2-L3, перечень серверов и АРМ с указанием их ролей, выгрузки из AD и SCCM и т.д. А среди специалистов Solar JSOC даже ходит легенда, что был когда-то Заказчик, который предоставил всю эту информацию в актуальном состоянии… Но, к сожалению, так бывает далеко не всегда, и приходится работать с тем, что имеем. А это значит, что нужно уметь оценить достаточность подключенных источников и получаемых событий для обеспечения качественного сервиса по мониторингу и выявлению инцидентов ИБ. Очевидно, что для этого специалист должен иметь крепкий бэкграунд по основным IT-технологиям, используемым для построения типовой инфраструктуры компании.
Параллельно аналитик должен уметь использовать старые источники для решения новых (в данном случае читай — непрофильных) задач. Например, у одного нашего Заказчика-банка, обладающего развитой сетью банкоматов по всей стране, остро стояла проблема: используемое антивирусное решение не позволяло оценить полноту покрытия этих самых банкоматов антивирусным ПО. Однако у нас был подключен межсетевой экран уровня ядра, и мы знали, с каким сервисом процессинга взаимодействуют банкоматы. Используя эти логи, ответственный аналитик смог подготовить список IP-адресов банкоматов, которые стучатся в процессинг, и при этом в БД центра управления антивирусного решения отсутствует информация о наличии у них агента. За несколько месяцев совместной интенсивной работы нам удалось сократить список таких банкоматов с нескольких сотен до единиц, а задача инвентаризации, изначально атомарная, в итоге была запущена на постоянной основе.
Въедливость 80 lvl
Весьма полезна для аналитика въедливость и внимание к мелочам. Расследование инцидентов, которые не были зафиксированы запущенным пулом сценариев Solar JSOC, — это очень сложная, рутинная работа с тысячами, а то и миллионами событий от различных источников. И здесь самое сложное — это найти ниточку, потянув за которую, удастся распутать весь клубок инцидента.
Например, у нас был кейс, когда аналитик расследовал несанкционированное проникновение в инфраструктуру Заказчика и ему никак не удавалось найти первоначальную точку компрометации. Для решения задачи пришлось построить месячный отчет по входящим и исходящим сетевым соединениям с участием IP-адресов, принадлежащим пулу внешних адресов Заказчика. И только после длительного анализа этого отчета удалось найти нетиповые исходящие соединения с тестового веб-сервера на IP-адрес из Нидерландов, которые в итоге оказались активностью Reverse Shell, запущенным злоумышленником на скомпрометированном сервере.
Часть задач аналитика требует прямой коммуникации с Заказчиком. Иногда информацию из него приходится вытягивать буквально клещами, например, когда запрос прилетает в виде «что было подозрительного на таком-то АРМе на прошлой неделе?». По факту после ряда наводящих вопросов оказывается, что сотрудник, работавший на этом АРМе, в курилке пожаловался своему коллеге из подразделения ИБ, что у него на рабочем столе пропал файл. А безопасник после этого решил спросить у внешнего SOC, с чем было это связано, но формулировка вопроса была слишком размытой. И такое бывает сплошь и рядом. Сложно переоценить пресловутое умение работать в команде, а именно в связке с сервис-менеджером. Для оказания качественного оказания сервиса важно, чтобы оба тянули упряжку в одном направлении, а не как в одной известной басне.
Бороться со стрессом и уметь делегировать
Отдельно стоит отметить черту характера, которая настолько примелькалась во всех резюме, что на нее никто уже не обращает внимания. Речь идет о стрессоустойчивости. Solar JSOC предоставляет сервис в формате 24 на 7, а значит, все аналитики участвуют в круглосуточных дежурствах, готовые в любой момент дня и ночи подключиться к расследованию важного инцидента. При этом, как показывает статистика, немалая часть критичных инцидентов происходит именно в нерабочее время. На первый план выходит способность просыпаться по несколько раз за ночь, причем мозг должен заводиться и быть готовым к восприятию важнейшей информации практически мгновенно.
Расследование всех зафиксированных инцидентов выполняется силами инженеров первой линии мониторинга. Задача аналитика — подключаться при эскалации, а также следить за качеством расследования инцидентов, проработанных первой линией. Более того, инженеры нередко обращаются к аналитику с просьбой помочь интерпретировать события или оценить критичность инцидента. А это значит, что аналитик должен направлять своих младших коллег, отслеживать прогресс по качеству расследования и давать фидбек тимлиду первой линии.
Также нередко Заказчик просит предоставить ту или иную информацию по событиям. Аналитик должен оценить задачу, грамотно ее интерпретировать и передать инженерам первой линии на реализацию, полностью или частично, в зависимости от уровня сложности выполнения задачи. Тут важно не замыкать всю техническую активность на себе и вовремя делегировать автономные задачи на первую линию как масштабируемый ресурс. В качестве примера подобных задач можно привести запросы вида «необходимо выгрузить информацию об активности сотрудника N на определенных хостах» или «просьба предоставить информацию о сетевом взаимодействии с адресом x.x.x.x за последний месяц». Как видно, запросы достаточно простые, но их реализация в SIEM требует определенного времени, при этом вполне выполнима силами первой линии.
»… пусть меня научат»
Каким же образом происходит пополнение рядов аналитиков Solar JSOC? Хотелось бы, чтобы все было просто, как на картинке, но увы.
Если не рассматривать найм людей со стороны, а также горизонтальный переход, то наиболее естественным путем до аналитика дорастают из инженера реагирования (более подробно про эту роль в банде JSOC можно почитать тут и тут). «И только это логично», как говорил известный персонаж.
Инженер реагирования, скорее всего, вырос из первой линии мониторинга, а значит, прошел нелегкий путь расследования непрекращающегося потока инцидентов, лавируя между Сциллой False Positive и Харибдой False Negative. Вдобавок инженер уже получил навыки более сложных расследований, углубленной работы с SIEM, подключения источников событий, а также решения конкретных задач Заказчиков. В общем, освоил фундамент, необходимый для дальнейшего роста.
Но достаточно ли этого для перехода в аналитики? Сложный вопрос. И обычно на него нет универсального ответа. Как минимум, у аналитика по сравнению с инженером реагирования появляется новая обязанность — взаимодействие с Заказчиком. Многим это покажется мелочью, но практика показала, что это далеко не так. Многим ребятам, с головой погруженным в IT, приходится сильно поработать над собой, чтобы преодолеть страх и научиться общаться с людьми, которым мы предоставляем сервис. На некоторых очень давит груз ответственности. Другим психологически сложно принять то, что на должности аналитика уже не будет старших товарищей, которые перепроверят за тобой и укажут на ошибки. Для многих это просто слишком сильный стресс — когда ты занимаешься нетиповыми задачами, каждая из которых оказывается вызовом твоим скиллам, когда несколько путей решения подряд оказываются тупиком. У многих после этого просто опускаются руки. Так что человеческие качества здесь играют немаловажную роль.
В качестве переводных задач на должность аналитика обычно мы предлагаем два типа задач. Одна из них — это задача развития контента JSOC, например, разработка блока сценариев по детектированию новых векторов атак. Из свежего — реализация детектирования атак на Active Directory, в частности DCShadow.
Помимо работы с контентом аналитик в процессе перевода назначается ответственным по двум-трем Заказчикам Solar JSOC: изучает их инфраструктуру, подключенные источники и получаемые с них события, выверяет полноту подключенных систем и скоуп запущенных сценариев, приступает к контролю обнаруженных инцидентов и качества работы инженеров первой линии по этим инцидентам. После окончания приемки все вопросы касательно технической стороны сервиса по данному Заказчику переходят в зону ответственности нового аналитика.
В команде аналитиков есть градация должностей. Отдельно хотелось бы сказать о роли старшего аналитика. Как это следует из названия, старший аналитик прекрасно справляется со своими основными задачами, при этом имеет представление об управлении сервисами Solar JSOC, умеет оценивать бизнес-риски, обладает высоким уровнем коммуникации, при необходимости способен проработать архитектуру нетипового сервиса и т.д. Тем самым в лице такого сотрудника мы имеем автономную боевую единицу, который может без потери качества подменить сервис-менеджера на период его отсутствия.
Но что происходит дальше с сотрудником, который взошел на ступеньку под названием Аналитик? Лестница развития Solar JSOC на этом не кончается.
Можно сосредоточиться на развитии и «копать вглубь», совершенствуя свои знания и навыки аналитика центра мониторинга, постепенно становясь матерым экспертом, которому уже не важен уровень сложности решаемых задач.
Можно заняться оптимизацией процесса работы аналитиков, а также курировать ребят, начинающих работать на этой должности. Иными словами, постепенно выдвигаться на роль локального тимлида.
А можно попробовать уйти в ряды классических управленцев и взять на себя бремя сервис-менеджера, занявшись такими непростыми задачами, как контроль соблюдения SLA, управление услугой Solar JSOC, взаимодействие с Заказчиком по уровню оказываемого сервиса.
Мы же стараемся помочь каждому сотруднику определиться с наиболее подходящим ему вектором развития и найти себя в структуре Solar JSOC.
