Идея о создании собственного Security Operations Center (SOC) кажется многим организациям все более привлекательной. Вся инфраструктура под чутким контролем ИБ-мониторинга – враг не пройдет. Но когда дело доходит до реализации, возникает вопрос: «А кто, собственно, этот SOC будет строить и как?» Здесь компании часто привлекают помощников: сервис-провайдера и/или интеграторов, которые могут выступать в роли консультанта или аутсорсера. В этом посте попробуем разобраться в том, как как выбрать провайдера, которому можно доверить кибербезопасность собственной инфраструктуры? На что смотреть во время пилота? И не проще ли все-таки делать SOC полностью in-house?
Кому подойдет in-house SOC?
Начнем с выбора подходящей модели: собственный полноценный SOC внутри организации или SOC на полном аутсорсинге.
Безусловно, главный фактор, который определяет будущее SOC в организации, – это политика руководства. Бывает так, что компания не приемлет аутсорсинг ИТ- и ИБ-процессов, аргументируя это закрытостью предприятия, имиджем, стратегией развития и десятком других причин. Их можно понять: кибератаки через подрядчика происходят все чаще. Решение in-house действительно может быть по плечу некоторым компаниям, но далеко не всем.
Поэтому прежде, чем приступать к строительству своего SOC, стоит трезво оценить ключевые аспекты этого непростого процесса. Скажу сразу, что мы рассматриваем ситуацию, когда в компании уже построена базовая система обеспечения информационной безопасности. Без такой базы строительство SOC просто невозможно.
Бюджет
Создание и содержание SOC – это очень дорогое удовольствие. Траты на проектирование, технические средства, ФОТ (минимум 10 человек), разработку внутренних интеграций, правил выявления инцидентов, реагирования и так далее… Даже если организация привлечет подрядчика только на проектирование и внедрение технических средств, а остальное решит делать самостоятельно, то после проведения оценки эффективности SOC (неважно каким способом) вероятнее всего будут выявлены проблемы во внутренних процессах. И для устранения все равно придется привлекать внешнюю организацию. В итоге получается, как с ремонтом квартиры: запланировали бюджет в N рублей, а потратили Nx2.
Люди
Не буду повторять слова практически каждого владельца SOC, что люди – это самое главное. Посмотрим на это с точки зрения выстраивания процесса найма и обучения новых сотрудников. Для начала стоит изучить вузы региона с профильными кафедрами ИБ. Наличие такого учебного заведения существенно облегчит поиск сотрудников для дежурной смены SOC. Также есть шанс, что в регионе есть готовые аналитики и архитекторы SOC.
Время
Время – ценный, но при этом самый ограниченный ресурс. Держатели бюджета в компании зачастую не представляют, сколько времени нужно на построение SOC. Нередко задача от руководителя звучит так: «Уважаемый начальник отдела ИБ, у тебя есть полгода, чтобы сделать в компании центр мониторинга». Конечно, это практически нереальная задача: полгода уйдет только на внедрение технических средств, а надо еще выстроить работающие процессы и нанять людей. При самых благоприятных условиях строительство полноценного и действительно эффективно работающего SOC занимает 2 года.
Если у вас сложились все 3 фактора, и вы оцениваете свои условия как благоприятные, можно действительно попробовать построить in-house SOC. Но если есть сомнения хотя бы в одном из них, то лучше рассмотреть аутсорсинговую модель. Но тут тоже не все просто: надо же выбрать сервис-провайдера. Тогда на помощь приходит пилот.
С чего начать пилот?
Перед тем как начинать пилотный проект, необходимо собрать максимальное количество предложений и определить свои базовые потребности:
1) Для чего мне нужен SOC?
2) От кого я хочу защищать свою организацию, и кому она может быть интересна?
3) Как бы я хотел развивать SOC в ближайшие 2-3 года?
После анализа предложений и сравнения их с собственными потребностями определите перечень компаний, с которыми можно провести пилотный проект. На старте пилота очень важно определить четкие цели. И желательно, чтобы они были выполнимы. Например, целью пилотного проекта не может быть выявление APT в инфраструктуре, ведь не факт, что в момент проведения пилота заказчика атакуют. А вот пример достижимой цели: «показать работоспособность, заявленных сценариев выявления инцидентов и обеспечить необходимый SLA». Это хорошо демонстрирует возможности сервис-провайдера.
Также важны ограничения сервис-провайдера (как общие, так и «пилотные»). Например, у нас в Solar JSOC для пилотных проектов есть несколько ограничений: число подключаемых площадок, общий поток событий, число запускаемых сценариев. Для качественной демонстрации сервиса хватит и одной площадки. А ограничение по числу запускаемых сценариев вызвано нисколько не желанием сделать типовой демо-функционал, а реальными процессами в жизни SOC, когда необходимо начинать с базовых вещей, а не бросаться сразу на выявление APT-группировки.
Наконец, надо определить формат проведения пилота: сразу пилотировать всех возможных подрядчиков или каждого по очереди. У каждого подхода есть свои плюсы и минусы. А именно:
Одновременное пилотирование различных сервис-провайдеров
Плюсы:
- Сравнение сценариев выявления инцидентов на одинаковом потоке данных;
- Сравнение качества расследований инцидентов;
- Сокращение общего времени на пилотирование различных сервис-провайдеров.
Минусы:
- Сложности в настройке источников событий ИБ по требованиям разных сервис-провайдеров;
- Нехватка времени для качественного взаимодействия со всеми сервис-провайдерами;
- Необходимость одновременно вникать в логику выявления инцидентов каждого сервис-провайдера.
Вывод:
Безусловно, данный формат хорош тем, что можно одновременно сравнить несколько разных SOC без временных задержек, но объективность может быть сомнительна. Любой сервис-провайдер в таких условиях найдет объяснение, почему не получилось выявить тот или иной инцидент и почему не было никакой реакции. Также не стоит забывать про огромный объем работы, который предстоит вам выполнить.
Последовательное пилотирование различных сервис-провайдеров
Плюсы:
- Демонстрация сервис-провайдером своих возможностей на фоне отсутствия конфликтов в части настройки источников событий ИБ;
- Возможность погрузиться в особенности работы каждого сервис-провайдера;
- Возможность задействовать меньшее количество ресурсов смежных департаментов.
Минусы:
- Необходимость в создании унифицированного сценария тестирования для разных сервис-провайдеров для объективной оценки;
- Увеличение общего времени тестирования — до года;
- Из-за разницы во времени проведения тестирований может исказиться итоговая оценка сервис-провайдера, например, если во время пилотирования одного из SOC произошел более сложный инцидент ИБ.
Вывод:
Основным преимуществом данного подхода является объективность оценки работы и возможность уделить каждому провайдеру максимум времени. Но количество затраченного времени может негативно сказаться на процедурах бюджетирования/закупок или восприятии проектов со стороны руководства.
Непосредственно пилот
Основная часть пилота, как правило, не отличается от того, что происходит во время коммерческого оказания сервиса. Здесь есть два этапа:
1) Инсталляционный (подготовительный);
2) Основной.
Не будем подробно рассматривать все действия, которые совершает заказчик и сервис-провайдер, а обратим внимание именно на то, что поможет сделать правильный выбор.
- Команда со стороны сервис-провайдера.
Кто проводит вам пилотный проект? Сколько человек и какие у них роли? Например, в Solar JSOC на любой сервисный проект заказчику выделяется сервис-менеджер и аналитик SOC. При этом под пилоты у нас собрана отдельная команда, которая проводит все работы и выступает в роли сервис-менеджеров и аналитиков, не отвлекаясь при этом на рутину. Специалисты, работающие с действующими заказчиками, также не отвлекаются от своих задач. - Помощь в настройке источников.
Иногда предоставленные сервис-провайдером инструкции по настройке источников событий ИБ не подходят для источников заказчика (разные версии, возможная кастомизация). Однако хороший сервис-провайдер всегда пойдет на встречу клиенту и переработает инструкцию. А если это невозможно, то предложит компромиссные варианты, например, совместно с вами посмотрит в консоль СЗИ, которое необходимо настроить, и предложит варианты их настройки. - Детализация расследования и SLA.
Большинство сервис-провайдеров готовы подписаться под очень жестким SLA и даже соблюдать его какое-то время, например, на время пилота. Но проверить, будет ли провайдер и дальше справляться с поставленной задачей невозможно, поэтому стоит обратить внимание на качество расследования. Качество проведенной работы над конкретным инцидентом хорошо демонстрирует то, что вкладывает сервис-провайдер в расследование за отведенный промежуток времени. Согласитесь, соблюдать SLA можно полностью автоматизировано, выявляя инциденты средствами SIEM и формируя оповещения только по корреляционным срабатываниям. Может получиться так, что при одинаковых параметрах SLA качество расследования совершенно разное. Ниже приведены скриншоты сравнения двух оповещений разных сервис-провайдеров об одном и том же подозрении на инцидент ИБ (попытка подбора пароля) с одинаковым SLA.
Пример №1
Пример №2
Первое оповещение сформировано аналитиком первой линии мониторинга, второе – сторонним сервис-провайдером автоматически. В обоих случаях SLA составляет 30 минут на оповещение, но разница в контенте очевидна.
Вывод
К сожалению, а может быть и к счастью, эффективность и качество работы SOC невозможно определить только цифрами. Поэтому сформировав правильные потребности и внимательно изучив возможности сервис-провайдеров в ходе пилота, вы легко сможете сделать вывод о том, насколько качественно будет работать внешний SOC, попытаться спрогнозировать потенциал по эффективности работы в ходе контракта и оценить возможность SOC противостоять актуальным именно для вас угрозам.
Ну, а если вы решили строить свой SOC, пилот позволит оценить каждого сервис-провайдера и понять, кого из них стоит нанять в качестве консультанта и помощника.
Автор: Артем Кильдюшев, руководитель группы экспертного пресейла Solar JSOC компании «Ростелеком-Солар»
