Нет повести печальнее на свете, чем повесть о слухах про работу в мониторинге ИБ-инцидентов. Публичные спикеры и авторы книг часто поддерживают разные заблуждения о SOC: что он скучный, лишен по-настоящему интересных задач и не предполагает карьерного роста. Однако я уверен, что это не так!



Меня зовут Сергей Солдатов. Я — Head of Security Operations Center в «Лаборатории Касперского». За свою карьеру мне посчастливилось работать в разных ипостасях мира ИТ и ИБ, поэтому, наверное, в своих размышлениях я могу быть вполне объективен. Ну а если нет, надеюсь, коллеги-ветераны кибербеза поделятся своим мнением в комментариях :)

Мы подробно разберем основные заблуждения, связанные со сферой мониторинга инцидентов, а также рассмотрим, из каких конкретных задач состоит работа аналитика SOC и какой карьерный трек у него может быть.

Свой рассказ о работе в Security Operations Center я построю на обсуждении трех, на мой взгляд, наиболее часто встречающихся мифов:

• SOC — это рутина;
• в SOC мало возможностей для профессионального развития;
• в SOC невозможен карьерный рост.

Миф № 1. Работа в SOC узкопрофильна и однообразна

Сначала отдельно остановлюсь на мифе, что аналитик SOC — это узкопрофильная специализация.



Итак, вся информационная безопасность крутится вокруг понятия инцидент, а инцидент, в первую очередь, надо обнаружить и расследовать, чем и занимается наша «синяя команда». После расследования на инцидент необходимо реагировать.

Далее. Некоторые угрозы распознаются не вручную. Для этого существует автоматизация, для которой надо сформулировать задачи и которую затем надо разработать.

Также можно построить отдельную стратегию обнаружения угроз. Поэтому у нас есть команда исследований, которая придумывает, за что зацепиться в той или иной технике атакующего. Эти ребята имеют квалификацию «красной команды», чтобы реализовать атаки для целей их исследования, а также прекрасно разбираются в работе «синей команды», чтобы понимать, как атаку обнаружить и как на нее реагировать, поэтому будем их называть «фиолетовой командой» — purple team. Важная задача фиолетовой команды — разработка детектирующей логики, Detection engineering.

Позже мы можем провести обследование инфраструктуры, но не с целью все разломать, как в случае пентеста, а чтобы найти следы компрометации. Такой проект называется compromise assessment.

Помимо типовых услуг SOC от заказчиков могут быть запросы на консалтинг по построению собственных практик операционной безопасности. И здесь также важен опыт работы в качестве аналитика Security Operations Center. Накопленные знания и умения, точно, будут полезны в построении как внутренних корпоративных SOC, так и сервисного предложения MSSP.

Далее. Нам говорят, что работа в SOC — это однообразная рутина. Давайте посмотрим на это предметно.



Работа линий строго определена и детерминирована. Мы живем в XXI веке и работаем в технологических компаниях, а значит, все, что поддается алгоритмизации, однозначно, может быть запрограммировано. Поэтому утверждение, что мы с вами биологические автоматы, которые молотят алерты, — не совсем верное. Мы вполне можем писать программы, которые будут нам облегчать работу. И постоянно это делаем. Кроме того, уже давно на практике работают ML-модели, обучающиеся на данных работы аналитиков SOC и вполне успешно снимающие с них часть нагрузки.

Еще одна важная тема — это переработки. Если мы возьмем суммарное время работы одного аналитика в сменах (поскольку Security Operations Center функционирует круглосуточно, работа в нем сменная), то за неделю у сменного аналитика, как правило, меньше 40 рабочих часов. Но главное в другом: эффективность SOC постоянно измеряют и контролируют. И по этим метрикам можно, в свою очередь, оценивать, насколько эффективно работает тот или иной член команды. Исходя из этого, мы точно знаем: переработки ведут к ухудшению качества! А качество работы для нас — бесспорный приоритет, поэтому мы не допускаем переработок, они имеют обратный эффект.

Нет интересных инцидентов. Это тоже не совсем так. На наших объемах, к примеру, мы фиксируем 32 тысячи инцидентов за год. А инциденты высокой критичности, если взять усредненную статистику, составляют примерно 7%. Получается, что примерно шесть инцидентов высокой критичности мы фиксируем каждый день. И можно сказать, половина из них очень интересны. Я бы не сказал, что это скучно.

Здесь же — что все интересные кейсы, «сливки SOC-а», забирают другие линии или даже функции. А аналитики занимаются некой рутиной, просто поставляют данные в «более продвинутые» команды. Это тоже не так, потому что в современных SOC-ах роли линий размыты. Это объясняется тем, что ситуаций, которые хочется предусмотреть, очень-очень много, поэтому полностью алгоритмизировать работу первой линии невозможно. У нас аналитики всех операционных линий имеют одинаковую квалификацию, следовательно, аналитик имеет возможность расследовать выпавший на него инцидент до конца. Поэтому эскалация на другую линию происходит только по самостоятельному решению аналитика, то есть когда ему не хватает времени или знаний, но не когда ему предписывает это какая-то внутренняя инструкция.

Миф № 2. В SOC мало возможностей для профессионального развития

Начнем с областей знаний, которые мы обычно спрашиваем на собеседовании. Вот буквальный перечень тем, в которых нужно разбираться аналитику SOC, чтобы пройти техническое интервью.

Операционные системы. Необходимо знать их архитектуру. Также нужно знать, как можно в них реализовать определенные тактики: как можно повыситься, горизонтально перемещаться, закрепиться; где хранятся пароли, чтобы их можно было своровать… И все это, как минимум, по трем операционным системам: Windows, Linux, macOS.

Сетевые протоколы. SOC-аналитику обязательно нужно знать основные сетевые протоколы и службы: как работает DNS, HTTP, что такое MX. Если мы говорим о корпоративных сетях, нужно понимать протоколы NetBIOS, Kerberos и другие.

Defensive. Поскольку мы работаем в энтерпрайзе, нам нужно понимать технологии безопасности, которые есть на вооружении. То есть у нас есть какие-то инфраструктурные вещи, такие как SIEMы, incident response платформы, системы обнаружения сетевых вторжений, системы защиты конечных точек, EDR и так далее. Нужно понимать, как они работают, — это, как говорится, база.

И конечно же, раз мы хотим видеть и ловить атаки, нам нужно понимать, как эта атака выглядит. Поэтому, безусловно, нужно иметь какой-то offensive-опыт, то есть быть немножко пентестерами.

Мы перечислили основное, но есть еще масса менее важных умений, из которых я бы выделил следующие.

Криптография — базовый и старейший инструмент защиты информации, используемый по сей день. Необходимо знать основные криптографические схемы и как они используются в современных решениях: схемы аутентификации, шифрование данных, электронная подпись, контроль целостности и т. п.

Кроме того, неплохо было бы уметь автоматизировать свою работу на каких-то скриптовых языках — Python, Bash, PowerShell. Также важно понимать, как работает сбор информации из открытых источников: Open Source Intelligence, OSINT.

Необходимо также разбираться в социальной инженерии, в первую очередь, чтобы уметь ее распознавать. Если вы вдруг умеете анализировать вредоносное программное обеспечение хотя бы на уровне strings — это тоже небесполезный навык.

Помимо всего перечисленного, конечно же, важны soft skills.

• Языки. Наша команда, например, работает не только в Российской Федерации. Наши коллеги находятся в Италии, Португалии, Бразилии и других странах мира — поэтому, конечно, надо знать английский.
• Навыки деловой переписки. Мы часто общаемся с заказчиками от лица компании, и это необходимо делать грамотно. К навыкам деловой переписки я бы добавил умение управлять эмоциями и концентрировать внимание.

Чтобы все эти навыки использовались максимально эффективно, специалисту должно быть, в первую очередь, интересно работать. Мы, как работодатели, заинтересованы, чтобы наши работники трудились с максимальной отдачей, чтобы члены команды работали там, где им интересно. Но для того чтобы понять, где именно интересно, должна быть возможность попробовать себя на разных направлениях. И для этого у нас есть различные возможности. Например, Analyst Self Days — это дни, когда аналитик может переключаться на какие-то другие задачи: это могут быть как задачи по саморазвитию, так и кейсы других подразделений. В рамках таких переключений аналитик может попробовать себя в других ролях, а мы можем посмотреть, насколько он в них эффективен, а следовательно — насколько ему интересны такие задачи. Для возможности организации таких переключений важно, чтобы бэклоги были прозрачны, приоритизированы. Между командами должны быть договоренности, что такие переключения возможны, и соответствующие тимлиды готовы управлять такими сборными командами.

Например, в свой Self Day аналитик SOC может взять работу по исследованию какого-то фреймворка из бэклога фиолетовой команды по согласованию с тимлидом исследователей. Например, он может взять Sliver, погонять его в лабораторных условиях, придумать новую детектирующую логику — а уже мы, как менеджеры, посмотрим: может быть, он действительно здесь более эффективен. И бывает, что людям приедается operations, зато они замечательно проявляют себя как исследователи. Путь из операционки в исследования вообще наиболее логичный, поскольку команда исследователей не должна быть оторванной от действительности, от работы операционной команды.

Миф № 3. У SOC-аналитика неочевидные карьерные перспективы

Чтобы говорить о карьерных перспективах, для начала надо погрузиться в стандартную оргструктуру команды SOC.

Мы уже упоминали purple team, которая занимается исследованиями. Также есть команда DFIR (Digital Forensics and Incident Response), она расследует инциденты и выполняет связанные с этим работы по цифровой криминалистике и реверсу.

Есть команда Threat intelligence, выполняющая полный цикл работ по управлению данными об угрозах, которая ищет что-то по внутренним и внешним базам. Результаты их наработок используются фиолетовой командой при создании детектирующей логики, например для обогащения телеметрии.

Не менее важной задачей остается сопровождение ИБ-инфраструктуры. Используемые другими командами инструменты и программные средства должны кем-то поддерживаться.

Также есть разработка, тестирование и, конечно, команда консалтинга для тех случаев, когда мы хотим наш опыт транслировать для своих заказчиков. И наоборот, команда консалтинга методологически нас тоже улучшает. Например, после завершения проекта по консалтингу мы можем впитать какие-то новые практики, а команда консалтинга может обкатывать на наших внутренних практиках свои свежие сервисы. Поэтому консалтинг в нашем случае — это тоже часть SOC.

А теперь рассмотрим возможный карьерный трек аналитика SOC.



В зависимости от опыта и результатов технического интервью, кандидат может попасть либо на позицию Junior SOC Analyst, либо на позицию SOC Analyst (Middle).

Дальше. С позиции SOC-аналитика, в зависимости от своих сильных сторон, спец может остаться в операционке, либо переместиться на направления Compromise Assessment или purple team.

Но вернемся в операционную команду, где, развиваясь как SOC-аналитик, с миддла можно дойти до позиции сеньора. Вместе с этим придут новые задачи — причем как частично софт-скилловые (в частности, онбординг и менторинг), так и хардовые (контроль качества, перепроверка работы аналитиков). Все, что выдает наружу операционная команда, впоследствии отсматривается их же коллегами, чтобы извлекать уроки из выявленных ошибок и чтобы больше, по возможности, их не допускать.

Следующая ступенька SOC-аналитика — лид. В рабочий фокус добавляются методология и архитектура, которые необходимо постоянно улучшать. Ну а дальше этот лид получает развилку: если он хочет продолжить заниматься техническими задачами и развиваться в глубину, то может стать экспертом, эдаким «мистером Вульфом», который решает проблемы (в положительном смысле этой аналогии). При этом спец становится работником, которого можно бросить на любую сложную техническую задачу, и она будет обязательно сделана. Либо лид тянется к менеджменту, хорошо работает с людьми и успешно мотивирует их, и тогда он может стать руководителем.

Этот карьерный путь более-менее един по всем командам в составе подразделения SOC «Лаборатории Касперского» и, по опыту, может занять у начинающего спеца не так уж много времени:



Обычно за полгода-год из джуна можно превратиться в миддла, а все последующие переходы рассматриваются по результатам года. Работа в позициях описана, а по каждой задаче есть КПЭ, которые постоянно измеряются и анализируются по всей команде SOC. Для перемещения с позиции на позицию необходимо достичь успехов по всем задачам текущей позиции.

Чтобы продвинуться с джуна или миддла нужно работать без ошибок и контрибьютить не ниже, чем в среднем по команде. Дополнительные задачи сеньора — менторство и перепроверки и для продвижения в лиды. Требуется, чтобы, например, его подопечные были эффективными аналитиками и работали без ошибок.

Чтобы продвинуться с лида в менеджеры, начать руководить командой, очень важна обратная связь от команды, поскольку назначение руководителя, пусть даже с матричным подчинением, должно иметь созидательные, а не деструктивные последствия в масштабе всей команды.

Успех тимлида в роли руководителя с матричным подчинением — весомый критерий для принятия решения о возможности его перевода в менеджеры с фактическим организационным подчинением.

В итоге получается, что карьерный трек успешного специалиста из джуна в тимлиды может составлять от четырех лет в условиях приведенной и достаточно длинной карьерной лестницы.

Итого: голые тезисы о работе в SOC

Во-первых, глубокая база в ИТ — основа операционной безопасности.

Маленький инсайт. Когда я работал менеджером и набирал команду по безопасности, «чистых» безопасников я не рассматривал и брал только классических айтишников. Причина проста: они обладают фундаментальными знаниями в ИТ, которые необходимы в кибербезе. Порой знания про условные compliance и ISO даются немного проще, чем какие-то технические основы, которые в SOC нужно иметь, что называется, на кончиках пальцев.

Во-вторых, операционная безопасность — это высокотехнологичная отрасль.

Что это значит? Мы будем автоматизировать все, что можно автоматизировать, чтобы на человека выпадало только то, что может сделать только человек.

Знаете разницу между ремеслом и искусством? Ремесло — это когда мы сделали стул и повторили его миллион раз. А искусство — это когда мы миллион разных стульев сделали. Надо фокусировать человека на искусство, а ремеслом в SOC займутся роботы.

В-третьих, специализация. Чтобы делать (и успешно!) много задач с хорошей результативностью, нужно углубляться в разные области.

Например, по ту сторону баррикад нас атакуют креативные ребята. У пентестеров очень широкий спектр специализаций — есть эксперты по вебу, по AD, по контейнерным средам… Масса направлений, в которые можно бесконечно углубляться. Соответственно, в противовес им нам тоже нужно дать экспертизу и креативность. Поэтому автоматика автоматикой, однако никакая жесткая алгоритмизация, скорее всего, не поймает уникальную атаку.

Ну и последний момент. В конце концов вся сфера ИБ крутится вокруг одного термина инцидент. И именно инцидентами занимается Security Operation Center. Проще говоря, если вы хотите начать карьеру в кибербезе, но не видите конкретной отправной точки, либо вы уже давно работаете и ищете развития, то вакансии в SOC «Лаборатории Касперского» могут оказаться тем самым трамплином для вашей карьеры :)