Главная » Хабрахабр » SOC — это люди: курсы переподготовки джедаев

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

OWASP Proactive Controls: cписок обязательных требований для разработчиков ПО

Данная статья содержит список техник по обеспечению безопасности, обязательных для реализации при разработке каждого нового проекта.Недостаточно защищенное ПО подрывает безопасность объектов критической инфраструктуры, относящихся, например, к здравоохранению, обороне, энергетике или финансам. Предлагаем вашему вниманию Top 10 Proactive Controls for Software ...

— А вы там в нефтехимии бензин делаете, да?

Привет, Хабр! Понятно, по пути будем упрощать, чтобы не превращать рассказ в занудную лекцию с перечислением всей таблицы Менделеева (кстати, 2019 год – официально год периодического закона, в честь 150-летия его открытия). Продолжая серию наших публикаций, мы решили, что для ...