Рассказывая о том, как устроена работа центра мониторинга и реагирования на кибератаки (SOC) изнутри, мы уже говорили об инженерах первой и второй линии и об аналитиках. Тогда же мы вскользь упомянули о сервис-менеджерах. Это сотрудники SOC, которые отвечают перед заказчиком за качество оказываемых услуг. За этим коротким определением фактически скрывается следующее: сервис-менеджер определяет практическую реализацию сервиса на площадке заказчика, должен быть готов в любой момент дня и ночи ответить на звонок заказчика или уведомление инженера мониторинга о критичном инциденте, собрать команду реагирования или расследования и выехать на площадку.
В большинстве своем сервис-менеджеры Solar JSOC — это мужчины в возрасте за 30
Что и кому должен сервис-менеджер
От сервис-менеджера не требуется глубоких знаний конкретных средств защиты информации на уровне инженера эксплуатации. Но наличие широкого кругозора в области СЗИ и их производителей, минимальное знание сетевых протоколов и требований к специфическим информационным объектам типа АРМ КБР и т.д. — обязательно. А ещё в качестве обязательного требования — сформировавшееся и укоренившееся
Почему такой набор критериев? Сервис-менеджер — это единое окно для клиента. Вместе с аналитиком они составляют группу, которая непосредственно общается с заказчиком. Этакий фронт-офис в том виде, как мы его себе представляем. Именно сервис-менеджер определяет, как задачи заказчика будут решены на прикладном уровне. В контракте такие частности, как правило, не прописаны.
Хорошо, если у клиента есть четкое понимание, что он хочет получить от услуги (на этой строчке мои коллеги усмехнулись). В реальности это явление почти столь же редкое, как метеоритный дождь. И тут как раз не обойтись без человека, который обеспечивает развитие ИБ в рамках проекта. Для каждого конкретного клиента он выявляет критичные данные и процессы, а также средства их автоматизации; потенциальные точки компрометации на уровне инфраструктуры и организации взаимодействия систем и людей. И это только на стадии запуска сервиса. А потом наступают трудовые будни, во время которых сервис-менеджер постоянно держит руку на пульсе инфраструктуры заказчика. Необходимо помнить и учитывать кучу факторов: тип бизнеса, используемые сетевое оборудование и СЗИ, количество и типы субподрядчиков, уровни доступа к чувствительной информации и многое-многое другое.
Вполне закономерный вопрос: а зачем так сложно? Ведь можно подключить к SOC системы заказчика в качестве источников информации и на этом остановиться. Наверное, кто-то так и делает, но наш опыт показывает: то, что подойдет для банка, неприменимо для завода или лизинговой компании. Да и внутри банков нет одинакового подхода к безопасности, несмотря на то, что это одна из самых зарегулированных отраслей в нашей стране. А уж на заводах вообще тихий ужас: куча проприетарных протоколов, запредельное количество субподрядчиков, подключающихся к элементам инфраструктуры удаленно (зачастую не раскрывая этот факт перед заказчиком). И вот со всем этим знанием необходимо работать.
Как уже говорилось выше, под каждый контракт мы формируем команду из аналитика и менеджера, выступающих фронтом. Команды не являются постоянными и меняются от клиента к клиенту. Как правило, один сервис-менеджер обслуживает от трех до шести заказчиков — в зависимости от их объема контракта и уровня зрелости ИБ. А это три-шесть отличающихся друг от друга инфраструктур, различных
Индивидуальный подход к заказчику — это не громкие слова, а одна из задач при оказании сервиса. Даже у разных компаний одной отрасли инфраструктуры, подходы к безопасности, политики ИБ и бизнес-процессы настолько различаются, что, как бы нам ни хотелось унифицировать сервис, в реальности такой подход приведет к профанации и снижению уровня защищенности заказчика (иными словами, это будет халтурная работа). При этом все же необходимо искать баланс между пожеланиями заказчика, зачастую странными, и реальной полезностью того или иного действия.
Например, есть изолированный гостевой WiFi-сегмент без доступа к внутренним ресурсам, но заказчик хочет, чтобы, в случае, если мы фиксируем запуск RAT (Remote Access Tool), ему приходило уведомление с максимальным уровнем критичности. Однако по факту при получении подобного уведомления заказчик ничего не делает, т.к. у него нет плейбуков и не хватает своих ресурсов на реагирование. А удовлетворение подобных желаний увеличивает нагрузку на инженеров реагирования и не приносит пользы никому из участников процесса. В итоге мы не получаем ничего, кроме повышенных «социалистических обязательств», т.е. процесс реагирования и расследования инцидента в режиме High ничего не дает.
Или наоборот: заказчик из-за каких-то мало понятных суеверий не хочет ставить на мониторинг свою биллинг-систему (которая основная бизнес-система и вообще — КИИ). И приходится методично, фактически на пальцАх объяснять, почему мы должны защищать этот сегмент. У каждого из наших СМ-ов подобных историй масса, и, если их опубликовать, то получится хорошая такая книжка.
А на другой стороне медали находятся процессы Solar JSOC: непосредственно мониторинг и выявление инцидентов, аналитика, архитектура, форензика и т.д. и т.п. Вся эта немаленькая и разношерстная компания работает на заказчиков. Как в любом живом коллективе в нем есть свои векторы развития, предпочтения, личные коммуникации. И это не должно никак влиять на оказание сервиса. Это тоже головная боль СМ-а: необходимо перераспределить ресурсы на решение какой-то задачи, расставить приоритеты на выполнение так, чтобы это не сказалось на других заказчиках. Нескучное такое занятие получается.
Сон — для слабаков
В отличие от большинства сотрудников Solar JSOC, сервис-менеджер «работает круглосуточно»: без перерывов на ночь, выходной и обед. У всех остальных служб есть дежурные. Это не значит, что сервис-менеджер, как галерный раб, прикован к современному варианту вёсел — столу и компьютеру. Просто это тот человек, который должен ответить на звонок от заказчика или наших внутренних служб в любое время дня или ночи. В нашем понимании под термином «ответить» скрывается следующая последовательность действий (мы же за процессный подход): осознать вопрос/проблему, принять решение о дальнейших действиях и подключить требуемые службы внутри компании, проконтролировав по итогу результат.
Причины звонков могут быть разные — забавные и не очень. Самая распространенная и «любимая» у СМ-ов причина запускается на стороне форензеров. Они находят новый эксплоит, оценивают его с точки зрения возможных угроз и запускают в сервис-менеджеров (как это было недавно с BlueKeep-2).
А дальше — дискотека! Каждый из СМ-ов на всякий случай просматривает досье подопечных клиентов (хотя большинство помнит инфраструктуры наизусть), руководитель этих чудесных ребят формирует текст оповещения, который адресно отправляется заказчикам по всем доступным каналам.
С ночными звонками есть еще одна распространенная история. На старте контракта заказчик часто просит, чтобы об инцидентах по ряду сценариев ответственных лиц уведомляли голосом в любое время дня и ночи. Соответственно, когда срабатывает алерт, дежурный мониторинга будит СМ-а и дает ему всю необходимую информацию по инциденту. Дальше СМ будит ответственного со стороны заказчика и передает информацию уже ему. Даже если у клиента есть своя служба реагирования, работающая в круглосуточном режиме, это не мешает нам поднимать ответственного с постели. Звонки происходят в параллель с уведомлением в сторону заказчика об инциденте. Как правило, уже через пару месяцев, когда заказчик убеждается, что сервис действительно круглосуточный и он не зря за него платит, нас просят прекратить такую практику.
Но есть и серьезные причины не поспать ночью. К таким однозначно относится атака на инфраструктуру заказчика. Случается и такая редкая, но не исключительная ситуация: ночью раздается звонок, и из трубки просят о содействии на физической площадке. За годы существования Solar JSOC схема обкатана: «в темпе вальса» собирается команда, в которой СМ выступает в качестве координатора, и дружно десантируется к клиенту. Иногда бывает, что мы подъезжаем раньше ответственных лиц, запустивших эту цепочку.
Отчеты — для сильных духом
Помимо бессонной ночи в таких ситуациях есть еще один огромный минус: все участники процесса могут уже отсыпаться, а сервис-менеджеру необходимо написать предварительный отчет по ситуации с указанием тайминга совершенных действий, описать сами действия и их результаты. Отчетность — это не дань формальностям, а реальный документ, который потом разбирают для выявления ошибок или, наоборот, удачных решений. Учитывается абсолютно весь опыт всех специалистов Solar JSOC, независимо от того, на какой позиции они работают.
Вообще отчетность — неотъемлемая часть работы сервис-менеджера. Отчетов много. Нет, не так. Их ОЧЕНЬ МНОГО. На любой вкус и цвет: от протоколов встреч, на которых фиксируется дальнейшее развитие услуги, до регулярной отчетности перед клиентами. Очень часто отчеты сопровождаются презентациями для топ-менеджмента, который желает знать о потраченных деньгах, но вникать в частности сервиса не готов. Соответственно презентация должна доходчиво подтверждать, что суммы потрачены не зря и от сервиса действительно есть польза. И все это делается абсолютно для всех заказчиков руками мужчин в возрасте за 30. Да, есть определенный уровень автоматизации, но создавать презентации в автоматическом режиме мы пока не научились.
Вообще хороший СМ умеет работать с любой аудиторией: доходчивость — наше всё
Но главное в другом
Очень часто можно услышать о том, что сервис-менеджер — это расстрельная должность и адская работа без возможности развития. Это очень сильное заблуждение. Один из наших СМ-ов говорит, что «результат работы всегда виден, то есть ты не работаешь в мусорную корзину, а это всегда классно».
О том, куда развивается сервис-менеджер и как из него вырастить полноценного CISO, мы расскажем позже. Пока лишь — трудовые будни через замочную скважину.
