SOC — это люди: курсы переподготовки джедаев

Мы уже некоторое время рассказываем о кадровых задачах и модели развития сотрудников в Solar JSOC. Наверняка вам удалось прочитать статью о том, как студенту третьего курса попасть в центр мониторинга и реагирования, или как инженеру прокачать опыт для вертикального движения в структуре Solar JSOC (из первой линии во вторую). Не за горами материалы о дальнейшем вертикальном развитии аналитиков и о том, как сервис-менеджер может превратиться в полноценного CISO. Но пока хотелось бы поговорить о другом.

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

Часто бывает, что сотрудник просто устал от текущих задач и стремится не столько «прокачать» опыт, т.е. заниматься тем же, но глубже, сколько найти для себя новые вызовы в смежных направлениях. В таких случаях мы всячески стараемся помочь ему обрести новое призвание и получить не «вертикальное», а «горизонтальное» развитие внутри Solar JSOC. Сложность лишь в том, чтобы не упустить этот момент, а также дать человеку все необходимое «снаряжение» для покорения новых вершин.

Вот о нескольких таких случаях мы и попробуем рассказать.

g5bkq7i9gh6jboxn-5a8y6tbj6a.jpeg

Горячие руки, холодное сердце


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

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

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

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

Это может быть не всегда очевидно даже самому сотруднику, но со стороны заметно невооруженным взглядом, особенно если:

  • Сильный инженер проводит очень качественный анализ и расследование инцидентов, но при этом регулярно проваливается в тайминге, определенном SLA, особенно по самым «коротким» инцидентам.
  • В параллель к основным задачам инженер тянется к работе с внутренними задачами повышения эффективности инфраструктуры или начинает писать на коленке скрипты для автоматизации своих рабочих задач.


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

Если специфика работы в мониторинге становится для человека проблемой, это вовсе не значит, что ему нужно пойти искать новое место. Для нас это сигнал, что, пройдя огонь и воду мониторинга, он может попробовать себя в медных трубах администрирования и взяться за прямое управление и «докручивание» политик самых разнообразных железок, средств защиты и систем ИБ. И такие «трансферные переходы» не являются для нас исключением из правил или чем-то неосвоенным.

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

  • Изучить функционал и интерфейсы тех средств защиты, с которыми придется работать на ежедневной основе (антивирусы, прокси, межсетевые экраны, VPN).
  • Подтянуть навыки в администрировании сетевого оборудования при помощи внутренних и внешних лабораторных, чтобы набить руку в управлении, в том числе в планировании работ.
  • Научиться диагностировать проблемы и сбои средств защиты, разобрав с десяток практических кейсов из накопленной нами базы знаний.


И еще одно: фраза про холодное сердце в заголовке абзаца была дана не в шутку. Работа с критичными высоконагруженными системами не терпит суеты и эмоционального «А сейчас я по-быстрому все сделаю!» Это очень взвешенные и рациональные действия с оценкой потенциальных последствий, разработкой процедуры применения изменений (RFC) и планированием технологического окна.

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

Математик не должен считать, математик должен думать


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

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

Как получается, что клиенты влияют на наши внутренние кадровые процессы? В основном по двум причинам:

  • Сама по себе SIEM-платформа, помимо выявления инцидентов, является очень хорошим инструментом Log Management и апостериорной аналитики. Часть задач, связанных с эксплуатацией — диагностику причины нагрузки на канал, определение списка внешних адресов, используемых в работе приложения, восстановление цепочки изменений в политиках и конфигурациях — зачастую куда быстрее и эффективнее можно сделать в SIEM. Поэтому все инженеры, начиная с первой линии администрирования, получают доступ к чтению логов систем заказчиков. Достаточно быстро это приводит пытливый ум к желанию создать для себя микроавтоматизацию, шаблоны отчетов и т.д. Таким образом инженер вовлекается в смежную область и иногда находит ее более интересной.
  • Вторая, не менее важная часть нашей жизни — это расследование нетиповых инцидентов или реагирование на сложные атаки. В таком случае, особенно если счет идет на минуты, все занимаются всем, и администраторы тоже вовлекаются в мозговые штурмы по способу анализа, противодействия и ликвидации последствий атаки. Такое стимулирование мозга на аналитику и поиск неявных связей тоже достаточно быстро кристаллизует в сотруднике осознание комфортности и увлекательности таких задач.


Как проходит движение по этому трансферу у сотрудников? Обычно обучение и перевод идет по трем направлениям:

  • Опыт в анализе логов и расследовании инцидентов. Конечно, очень помогают лабораторные примеры, но и жизнь MDR-провайдера подкидывает еженедельно новые интересные кейсы, на которых можно проверить и прокачать свои навыки. Тем более, что, как я уже говорил, базовый опыт работы с логами имеют и специалисты администрирования.
  • Работа с SIEM по созданию или адаптации контента. «Птичий» язык написания корреляционных правил в разных SIEM дается ребятам не сразу. Но опять же, опыт работы с логами и базовое построение отчетов сильно сокращает этот маршрут.
  • Ну, а навыки по развертыванию платформы, подключению и настройке источников для любого администратора давно привычны. Всего лишь еще один продукт в портфель.


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

Никогда не будет второй оказии произвести первое впечатление


Совсем отдельная история в работе Solar JSOC — это активности по поддержке продаж, а особенно пилотные проекты. Пилотный проект должен являть собой квинтэссенцию качества оказываемой услуги:

  • Время пилота всегда сжато и ограниченно, поэтому темп работ по подключению сервисов как со стороны заказчика, так и нашей должна быть максимальной.
  • Пилот должен максимально полно показать наши возможности и процессы, чтобы заказчик мог оценить применимость для себя наших услуг максимально объективно и без прикрас (в противном случае на этапе оказания сервиса может возникнуть масса неприятностей с обеих сторон).
  • За короткое время и на ограниченном скоупе пилота мы должны «накопать» некоторое количество инцидентов и уязвимостей инфраструктуры, которые позволят объяснить бизнесу фактическую пользу сервиса.


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

К возможному методу выращивания и подбора таких кадров нас привел случай. Мы были глубоко убеждены, что без технического понимания работы SOC, опыта работы с логами и SIEM навыки пресейла в нашем случае скорее бессмысленны. Но однажды один из кандидатов поставил всю ситуацию с ног на голову.

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

Тем не менее, волей чутья HR-службы кандидат пришел к нам работать и начал вливаться в команду. И совершенно неожиданно стало понятно, что желание расти и развиваться в совокупности с правильным окружением, когда процессы и задачи SOC впитываются в курилке, на обеде, да и просто на перекриваниях в кабинете, дают хороший результат. Буквально через месяц-полтора он уже взял в свои руки первый пилотный проект не просто в роли менеджера и контролера сроков, но с почти автономной технической реализацией задач. Сейчас он успешно реализует пилоты любой категории сложности уже в роли играющего тренера.

В итоге мы нашли двусторонний подход к очень нестандартной задаче по выращиванию таких штучных кадров, как пресейл-аналитики сервисов Solar JSOC:

  • «опыление» команды пресейлов техническими знаниями и духом жизни в cybersecurity operations,
  • поиск среди технарей тех людей, которые хотели бы перековаться из технических специалистов в более близкую к коммерческому направлению роль.


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

Конечно, это не все варианты перемещения сотрудников в рамках Solar JSOC. Были случаи, когда инженер группы администрирования, устав от непрерывной коммуникации с клиентом и имея желание сосредоточиться на эксплуатации чего-то «своего», перебазировался в архитекторы нашей развесистой инфраструктуры JSOC. В инженерах первой линии порой пробуждалась страсть к низкоуровневому анализу и работе с Assembler (первые признаки начинающего форенсера). Опытные бойцы первой и второй линии, уставшие от инженерных работ, понемногу смещались к задачам сервис-менеджера и коммуникации с заказчиком, или становились локальными тимлидами.

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

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

© Habrahabr.ru