3 апреля состоялся эфир AM Live с моим участием. В эфире принимало участие много экспертов, поэтому возможностей высказаться у каждого было немного. Однако, на мой взгляд, эфир важный, так как подобные мероприятия отчасти формируют понимание рынка у потенциальных заказчиков, а, с учетом того, что мнения, порой, высказывались противоречивые, да и с которыми я сам не согласен, мы получили практически треть слушателей, кто ничего не понял. В очередной раз, пользуясь своей уникальной возможностью полностью излагать свое мнение без внимания на регламенты и, где-то даже, приличия, постараюсь остановиться на моментах, которые меня стрегирили\я их не понял\не согласен. Сразу замечу, что здесь я высказываю свое личное мнение, и цель моя - немного расширить и углубить понимание аутсорсинга операционной безопасности, ну а читатель может самостоятельно принять для себя решение, выслушав, различные аргументы. Итак, поехали!
Артем Грибков рассказал, что много заказчиков обращается за TI, и за атрибуцией. Есть несколько вещей в кибербезе, к которым я отношусь скептически, так как они не дают бизнес-результата: одна из них - управление уязвимостями, а другая - это атрибуция (когда-нибудь подготовлю статью про это). Да и вообще TI не результативен, - это инструмент, причем его качество (эффективность и результативность) крайне сложно измерить, так как не понятна полнота, не понятна глубина, да и во времени это качество меняется крайне динамично: сегодня эти фиды ловят C&C, а завтра - нет, сегодня эта группировка использует такие инструменты\техники, а завтра - другие. Поэтому, на месте CISO я бы покупал не инструмент, а результат: пусть бы поставщик мне с помощью своего TI обнаруживал\предотвращал такие-то угрозы - здесь результат налицо, поэтому качество можно контролировать. Однако, если на TI есть спрос, как я сам отметил, наша задача дать опции, кирпичи, из которых уже CISO соберет свою, индивидуальную, систему управления безопасностью (СУИБ) - есть желание покупать запчасти для SOC, покупать TI, - мы можем это предложить.
Володя Дмитриев рассказал об Управлении уязвимостями как услуге коммерческого SOC. Вполне возможно, что я что-то неправильно понимаю, но даже, вынося за скобки то, что Управление уязвимостями - процесс, в котором невозможно достичь успеха, поскольку заканчивается где-то в области управления конфигурацией и управления изменениями (когда уязвимость исправлена), что полностью в ответственности ИТ (ну, если инфраструктура не облачная, и какие-то обновления там лежат в ответственности поставщика облаков). Мне, как CISO, опять же интересен результат - чтобы уязвимостей не было, чтобы они были исправлены, но едва ли поставщик сможет заниматься исправлением моей конфигурации, установкой патчей в моей инфраструктуре. Поставщик может сканировать на уязвимости и выдавать мне отчеты, пусть даже разобрав его руками, и удалив оттуда мусор, но ценности здесь немного, так как знание о том, что у меня есть уязвимость не делает меня неуязвимым, а если я исповедую Assume vulnerable, то результаты работы сканера не добавляют и знаний.
Далее, Андрей Заикин предлагает SOC-у обогнать эксплуатацию уязвимости. Я решил, что Андрей здесь немного некорректно выразился, так как эксплуатация уязвимости, даже с последующим закреплением в инфраструктуре занимает [меньше] минуты, а время реакции SOC - десятки минут. Поэтому, уважаемые заказчики, не стоит ожидать, что SOC должен обгонять эксплуатацию уязвимости, автоматы можно догнать и перегнать только автоматом, аналитики SOC, люди, отработают медленнее, чем любой автомат.
Комплексная результативная безопасность "под ключ", "чтобы меня защитили" о которой говорит Володя - правильная вещь, достойное желание руководства. Но, как грамотный CISO, я должен понимать, что никакой MSSP это не сможет обеспечить, так как безопасность хорошо работает только тогда, когда она интегрирована, а "интегрирована" означает глубокое внедрение во внутренние бизнес-процессы, как минимум, ИТ, чего MSSP не может дать, а причина этому - необходимость рентабельного масштабирования, как правильно отметил Артем. Дальше Володя ушел в Bug Bounty, что слабо относиться к услугам коммерческого SOC, ну, если только я буду тестировать качество работы поставщика услуг SOC с помощью Bug Bounty.
Далее, тему реальной комплексной услуги подхватил Андрей, и развил до составления индвидуальной модели угроз. На практике с этим большие проблемы. Во-первых, это не масштабируется, так как я не смогу иметь сотни заказчиков, для каждого их них своя модель угроз, следовательно, свои правила обнаружения и свои плейбуки к ним, а, во-вторых, такая глубокая интеграция в корпоративные бизнес-процессы невозможна ну, разве что только, если я продаю не услугу, а людей, и у меня не "аутсорсинг", а "аутстаффинг". Поэтому, полагаю, Андрей здесь имел в виду не операционный сервис SOC, а SOC Consulting: мы изучим бизнес-процессы заказчика, спроецируем их на ИТ, поймем как выглядят атаки и как их можно продетектить, напишем контент для их SIEM, поможем нанять людей, организуем обучение.
Почему-то всем хочется обеспечивать индивидуальный подход и максимальную гибкость, поэтому примерно то же начал говорить и Александр, я даже подумал, что коллеги под этим понимают "клиенториентированность". На практике, чем больше клиентских кастомизаций мы допускаем, тем менее масштабируемая услуга получается и тем дороже она. В моей картине мира это очевидно, поэтому слова коллег о бесконечно идивидуальном подходе я понимал как: а) клиентов немного, б) внутренние процессы нестрогие, так как под каждого заказчика своя история, в) продают аутстаффинг, либо они все говорят о консалтинге, но это - проект, и, вроде как, теме SOC (операционная безопасность) нерелевантно. Причем, Саша все мои догадки (а, б, в) только подтверждал, рассказывая о разности стоимости, тогда как зрелое предложение имеет прозрачно рассчитываемый по калькулятору тариф за единицу объема мониторинга.
Далее, мы начали обсуждать гибридные SOC-и. И здесь все эксперты, и Владимир, и Александр, мог бы поддержать и Андрей Дугин, сказали, что гибридный SOC - это когда SIEM - заказчика, команда - MSSP. Свое мнение о гибридных SOC я описывал здесь, в двух словах: MSSP дает стандартное типовое предложение, всю специфику обеспечивает внутренняя команда. В моем понимании SIEM - это инструмент, и не совсем понятно зачем CISO покупает себе инструмент, если им некому пользоваться. Действительно, если я не играю на баяне, мне едва ли он нужен. Возможный сценарий - это долгосрочный проект, например, я купил себе инструмент, потом под него ищу команду, а пока я ее готовлю, MSSP смотрит в мой SIEM, но это - не operations, это именно проект, консалтинг по построению SOC.
Тюнинг правил обнаружения как услуга SOC тоже требует глубокого погружение в коммуникации, как минимум с ИТ, с учетом того, что адаптация правил может продолжаться вечно, здесь тоже очень явный оттенок аутстаффинга. Далее Саша перескочил на оценку зрелости SOC - это понятная вещь, но не имеющая отношения к гибридным SOC и операционной безопасности вообще, это проект. В целом, Саша это прекрасно прекрасно понимает и явно указывает в своем монологе, однако такие переходы запутывают зрителей.
Зачем-то Виталий сказал, что у всех используются одинаковые инструменты, хотя я не слышал, чтобы кто-то так сказал, да и по факту это не так, видимо, это странное утверждение поставило в тупик Владимира, думаю, и зрителей тоже запутало.
Далее, Андрей предложил измерять скорость реакции команды SOC по скорости реакции клиент-менеджера или менеджера по продажам. Утверждение Андрея я понял примерно так: "в хороших компаниях все сотрудники работают хорошо", но, обычно, Продажи и Delivery-команды вообще разные вертикали подразделений, и даже более - чем лучше продукт, тем меньше надо маркетинговых усилий по его продаже, поэтому за хорошими предложениями могут стоять, напротив, плохие Продажи, а за плохими продуктами - ловкие, эффективные клиент-менеджеры.
Саша продолжает пропагандировать индивидуальный подход, вплоть до индивидуальной отчетности, что звучит удивительно. У эффективного MSSP отсутствует возможность для каждого из нескольких сотен заказчиков генерить персонализированную отчетность, более того, она вообще не генерится: вся информация об инцидентах доступна через клиентский портал, откуда клиент сам может ее выгрузить в нужном формате, или забрать по API в свою корпоративную систему управления инцидентами - это наиболее зрелый подход.
Референсы - замечательная тема, но надо понимать, что хороший MSSP никогда не рассказывает кто его заказчики без их явного согласия, поэтому предоставлять какой-то выбор коммерческий SOC может только среди тех своих заказчиков, кто дал на это согласие.
По технологиям SOC почему-то по-прежнему ставят SIEM на первое место. Я бы поставил в ядро - SOAR/IRP, поскольку это как раз те системы, которые объединяют в единое окно все технологии и автоматизируют процессы. Все-таки от SOC ожидают именно реагирования, обнаружение - хорошо, но не является ожидаемым окончательным результатом, а реагирование автоматизируется как раз на уровне IRP.
Далее Володя коснулся вопроса покрытия, но, ввиду того, что мы должны рассуждать с позиции коммерческого SOC, а слова Владимира - с позиции CISO, может сложиться некорректное ожидание, что обеспечение покрытия SOC-ом - это ответственность самого SOC, это не так. SOC, как не раз уже повторялось, - контроль безопасности, и куда в каком объеме его применить - это ответственность CISO. Полностью согласен с тем, что правильный ответ на вопрос: "Что должно быть покрыто SOC?"- "Вся инфраструктура", однако, окончательное решение в этом не за MSSP. Мы часто видим атаки, которые приходят из-за пределов объема мониторинга, с хостов, от которых мы не получаем телеметрию, мы явно указываем это в карточке инцидента, вместе с рекомендацией о необходимости расширения покрытия, но решение о расширении объема всегда за заказчиком. Ситуация даже еще хуже: чем больший объем мониторинга у заказчика, тем более он динамичен: какие-то хосты пропадают, какие-то появляются, отслеживать причины пропадания телеметрии практически невозможно, так как хост мог быть легитимно выключен, отключен от сети, выведен из эксплуатации и т.п. - часть этих сценариев теоретически можно покрыть интегрируясь в корпоративный Change management и Configuration management, но это не имеет смысла, так как наиболее частые сценарии - пользователь ушел в отпуск и выключил компьютер - не отслеживаются даже в случае столь тесной интеграции. На практике мы отслеживаем массовые ситуации, типа резкое падение объема событий вообще или в разрезе определенных типов, или резкий рост и т.п. - это делается с помощью модели машинного обучения без учителя (обнаружение аномалий).
А вот это, уважаемые читатели, очень важный итог: не получится отдать операционную безопасность в аутсорсинг и забыть, всегда должна быть "ответная часть" коммерческого SOC, "служба заказчика", если хотите, которая будет заниматься организацией реагирования на выявленные инциденты, отвечать на вопросы SOC фолса\не фолса, чтобы он подстраивал правила обнаружения, и решать все те вопросы, до решения которых подрядчику просто никак не дотянуться. В целом, понимание этого простого вывода служит объяснением моей мысли о том, что все SOC-и - гибридные.
