Все заказчики разные. Одни хорошо разбираются в технологиях и точно знают, что им нужно. Другие – просто хотят работать без сбоев и инцидентов, хоть и не понимают, как это реализовать. А кто-то не разбирается в ИБ, но уверен, что точно знает, как выстроить процесс. Если дело доходит до таких сложных задач, как создание или перестройка Security Operations Center (SOC), разница в подходах к ИБ становится очевидной. В этой серии постов мы решили поделиться подборкой самых популярных запросов, с которыми к нам, как к сервис-провайдеру, приходят компании и рассказать, почему не все пожелания заказчика нужно и можно реализовывать. С какой бы стороны баррикад вы ни стояли (строитель SOC или заказчик), надеемся, наш опыт будет вам полезен. Мы уже писали о заказчиках, которые действительно хорошо разбираются в IT и точно понимают, чего они хотят от SOC. В этом посте речь пойдет про тех, кто не понаслышке знает, что такое SIEM, возможно, работали в SOC и основная их цель – защита от киберугроз. Но они не так погружены в вопрос, что в итоге приводит к своеобразной постановке задач.
К поставщикам услуг SOC они обычно приходят с 4 вариантами запросов.
1) «Хочу отдельную функцию SOC: первую линию мониторинга, например. А с остальным – я как-нибудь сам».
Лучше, конечно, отдавать провайдеру все функции SOC целиком. Если же дробить зоны ответственности, получится следующее. Представим, что внешний SOC забирает только первую линию мониторинга 24/7. А штатные специалисты пишут контент, поддерживают SIEM и занимаются расследованиями. Выходит, что сервис-провайдер отдает людей на аутстафф. А это противоречит самой сути сервисной модели, где ключевую роль играет шэринг специалистов между несколькими заказчиками и гибкая балансировка по нагрузке. Такая «неуникальность» делает услугу более дешевой для заказчика. Но в описанном выше запросе первая линия работает по уникальному контенту, с уникальными плэйбуками, инструкциями и только на конкретного заказчика. Выходит, что последний оплатит и выделенную команду, и наценку сервисной компании. Ни о какой экономии речи не идет. К тому же все «плюшки» SOC (экспертиза сервис-провайдера по контенту для SIEM, плэйбукам и рекомендациям) тут не задействуется.
Ситуация со 2й и 3й линией на аутсорсинге чуть лучше, но только, если первая линия заказчика работает с контентом и инструкциями внешнего SOC, прошла его подготовку и имеет двойное подчинение (внешнему SOC и внутреннему куратору). Если же отказ от 1й линии обусловлен попыткой сэкономить, то это не имеет смысла. Почти 85% стоимости услуг SOC складывается из цены оборудования, лицензий и экспертных функций, которые находятся в других подразделениях сервис-провайдера.
2) «У меня тут logstash есть, и я все логи туда собираю, просто забирайте их оттуда»
Еще один кейс про границы зон ответственности. ИТ-подразделение компании собирает логи в единое хранилище для своих нужд, в том числе и для удобного траблшутинга и разбора возникающих инцидентов. В момент подключения источников логов к SIEM ИБ-служба приходит к ИТ с инструкциями от сервис-провайдера и слышит: «Направлять логи в два destination неудобно и проще будет просто форвардить». И если речь про сетевые логи – это еще полбеды. А вот когда в эту базу затягиваются логи с ОС и СЗИ – пиши пропало! Потому что:
В таком варианте любая промежуточная агрегации логов – это точка отказа. Давайте честно: промежуточный коллектор с логами скорее всего не относится к критически важным бизнес-процессам компании, и обслуживают его обычно в режиме 8х5. Так что, если происходит сбой в таком хранилище в пятницу вечером, провайдер SOC остается без данных до понедельника.
Маппинг полей (то есть сопоставление полей исходного события со служебными полями SIEM) – еще одна головная боль сервис-провайдера. Каждый SOC использует свои особенности обработки логов, которые нацелены на нативный метод сбора данных (Windows – WMI+RPC, Kaspersky – DB (tcp:1433), Checkpoint – OPSEC и т.д.). Если метод меняется, приходится разрабатывать свои парсеры, мапить поля для каждого типа события (а только в ОС Windows их более 40). А ведь еще появляются новые сценарии, обновляются источники сбора данных и маппинг может меняться… Естественно, это сказывается на стоимости и скорости подключения к сервису и, что хуже, на скорости детекта новых техник и тактик, ведь каждое обновление занимает время.
Многие syslog-коллекторы заменяют заголовок и подставляют свой адрес источника событий ИБ. В итоге невозможно оперативно понять, например, в каком сегменте сети произошел инцидент, и у линий мониторинга могут возникнуть сложности при проведении расследования.
Как показывает практика, самые простые и прямые способы сбора логов с источников - наиболее правильные, так как позволяют оперативно отследить любые сбои.
3) «Вообще, у меня бюджет небольшой, но я хочу SOC под ключ».
Рынок услуг SOC очень разнообразен как по составу сервисов, так и по стоимости. Естественно, заказчики стремятся сэкономить и за меньшие деньги получить больше услуг. Казалось бы, варианты есть на любой кошелек, но, как обычно, дьявол – в деталях. Давайте разбираться.
Иногда за относительно небольшие деньги в качестве услуги SOC предлагают такой вариант: «Без SIEM, но мы поставим сетевые сенсоры и будем обрабатывать алерты с них». В целом неплохой вариант, если вспомнить, что огромное количество инцидентов выявляется именно на сети. Но достаточно ли только этого для оказания полноценного мониторинга? Скорее нет.
Отсутствие логов с АРМ, специализированных endpoint агентов (EDR), других СЗИ и инфраструктурных источников не позволяет выявлять многие типы инцидентов, которые являются частью атаки. Любые нелегитимные действия на хосте скрыты от сетевых сенсоров. Они не видят даже банальные срабатывания антивируса. При этом, если злоумышленник использует https соединение для построения туннеля взаимодействия с внешним миром, а сенсор не умеет расшифровывать SSL-трафика, то получается печальная картина. Злоумышленник, скомпрометировав удаленный хост администратора, зашел в инфраструктуру компании по VPN. Далее, попав на контроллер домена, групповой политикой раскидал по сети легальную утилиту dcrypt и отдал ей команду «пошифровать хосты». Что из этого является аномалией для сетевых сенсоров? Скорее всего, ничего.
Качество сигнатур детектирования у всех сенсоров разное. В первую очередь, необходимо смотреть на сигнатуры и обсуждать с сервис-провайдером частоту их обновления и наличие у него отдельной исследовательской команды, занимающейся только наполнением базы.
Важную роль играет расположение сетевых сенсоров. Поставьте его на периметре и будете видеть многочисленные сканирования внешними ботами и «отстуки» ВПО, находящегося на зараженных хостах, к C&C (управляющим центрам ботнетов). Поставьте на межсегментное взаимодействие, и тогда можно увидеть горизонтальное распространение на сети (если будут сигнатуры). Правда, перемещения в рамках одной подсети могут не проходить через сетевой сенсор (для снижения нагрузки на оборудования и повышения производительности).
Если с подходами разобрались и хотим полноценный SOC, то возникает второй вопрос: а какого провайдера выбрать? Для этого есть несколько ключевых критериев:
Максимальное число хостов/eps, которое можно подключить к мониторингу. Хватит ли вам и вашей инфраструктуре этого количества? Если хочется посчитать совсем точно (особенно EPS, которые заранее неизвестны в большинстве случаев), проведите пилот с сервис-провайдером и соберите статистику. Нет времени – руководствуйтесь здравым смыслом. Большинство событий генерят сетевые устройства и системы обнаружения вторжений. Дальше идут инфраструктурные источники: контроллеры домена и DNS. После – средства защиты. Если есть желание подключать хосты на уровне локальных логов (хотя бы самые критичные), то рассчитывайте на 2-3 EPS с АРМ, и на 3-6 EPS с сервера в зависимости от роли. Отдельное внимание занимают прикладные системы, например, те же веб-серверы (Nginx, Apache, iis), которые генерят много событий (иногда – очень много). В любом случае, чтобы оценить необходимость подключения тех или иных источников событий, лучше запросить список сценариев и маппинг их на источники, которые есть у сервис-провайдера.
Дополнительные параметры. Есть ли ограничения на обращения к сервис-провайдеру от клиента или ограничения на количество запускаемых сценариев и подключаемых источников.
Опыт провайдера. Чем более он опытный, тем больше у него будет типовых коннекторов и правил (особенно, если используется своя разработка в качестве SIEM). Отсутствие подходящих сценариев может стать серьезным ограничением для оказания сервиса. Лучше заранее запросить их список и обсудить источники событий.
Дополнительные сервисы - форензика, threat hunting, проверка индикаторов компрометации (в том числе ретроспективная), реверс ВПО, которое могло попасть к вам в песочницу или бдительному пользователю, плэйбуки, регламенты, описание процессов от методологов SOC. Будет полезна и помощь в реагировании на инцидент и проверке гипотезы компрометации на тех сегментах, которые не планируются к подключению к SOC и существуют автономно. Конечно, это существенно влияет на конечную стоимость, но часто становится необходимой опцией. Лучше сразу узнать о наличии и стоимости таких услуг.
Интерфейс взаимодействия: насколько гибок сервис-провайдер. Общение по почте, через личных кабинет, на уровне интеграций IRP-систем и даже предоставление IRP as-a-service в составе сервиса.
Сроки работ. Сколько разрабатывается коннектор к нетиповому для сервис-провайдера источнику, реализуются нетиповые сценарии выявления инцидента по запросу и какое их количество заложено в базе.
Дашборды и панели визуализации: есть ли они, лучше спросить заранее и даже посмотреть на них. Реальная безопасность важна, но и руководству надо красоту показывать.
Если же у компании есть SIEM, то лучше проверить, работает ли провайдер с таким вендором. Конечно, провайдер может адаптировать свои процессы под любую платформу, но на это требуется время. А пока будет идти эта настройка, провайдер не может гарантировать высокое качество своих услуг.
4) «У меня есть бюджет до конца года, и я хочу SOC. Люди есть, SIEM есть».
Наконец, последний вариант. Тут можно только перекрестить и пожелать удачи… Но, если серьезно, надо понять, что конкретно клиент ожидает. Просто подключить источники и хоть как-то реализовать сценарии выявления реально. Но, если нужно построить работающий SOC, то лучше привлечь команду для консалтинга (сервис-провайдера и строителя в том же лице), чтобы она оперативно начала осуществлять транзит экспертизы и процессов. А дальше строительство SOC – но это далеко не пара месяцев.
Во-первых, надо написать требования к SOC (концепция, пояснительная записка – кто как называет), включающие в себя:
цели и задачи SOC;
функции SOC;
зоны ответственности как внутри, так и между подразделениями компании;
состав технических средств;
оргштатную структуру;
персонал и компетенции;
SLA, KPI и другие метрики.
Во-вторых, нужно составить карту развития SOC хотя бы на три года и прописать основные чекпоинты.
Включая этап согласования и внесением изменений в положения компании, весь процесс занимает минимум полгода. Реализация хоть каких-то функций SOC по намеченному плану займет еще полгода минимум. И через год-полтора в компании появится свой работающий SOC.
Заключение
Итак, заказчики часто понимаю, что SOC им нужен и действительно поможет защититься от киберугроз. Но они не всегда представляют, насколько центр мониторинга – сложный механизм, под который нужно адаптировать многие процессы в компании. Не всегда (а точнее, очень редко) можно скрестить SOC провайдера с инфраструктурой заказчика без дополнительных настроек с обеих сторон. Правильно настроенные источники событий, налаженная коммуникация между командами заказчика и исполнителя, корректные правила и плейбуки – иначе часть событий будет потеряна, а хакеры просочатся в инфраструктуру незамеченными. А при строительстве собственного SOC всегда надо помнить, что этот процесс занимает не месяц и не два. И лучше пригласить команду по консалтингу, которая поможет построить центр мониторинга под нужды конкретной компании.
Автор: Алексей Павлов, директор по развитию бизнеса центра противодействия кибератакам Solar JSOC