Главная » Хабрахабр » 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 Интересное!

Образ современного тестировщика. Что нужно знать и уметь

Мол, знать ничего не нужно, уметь и подавно, достаточно желания и готовности не сильно щуриться от боли и слёз, когда тебе прилетает очередной набор тест-кейсов для регрессионного тестирования. Бытует мнение, что простейший путь к IT лежит через тестирование. Сейчас же ...

[Из песочницы] Нейронная сеть с использованием TensorFlow: классификация изображений

Привет, Хабр! Представляю вашему вниманию перевод статьи «Train your first neural network: basic classification». Для создания нейронной сети используем python и библиотеку TensorFlow. Это руководство по обучению модели нейронной сети для классификации изображений одежды, таких как кроссовки и рубашки. Установка ...