Коммерческие SOC в 2023 году: мотивация и развитие. Часть 2

Каким должен быть первый шаг для подключения к SOC, если принципиальное решение уже принято, и что SOC точно не сделает за заказчика? На эти и другие вопросы редакция журнала “Информационная безопасность” попросила ответить практикующих экспертов в области коммерческих SOC.

Что SOC точно не сделает за заказчика?

Александр Матвеев, IZ:SOC:

1. Внешний SOC может помочь повысить эффективность и модернизировать внутренние процессы заказчика, но никогда не сможет их поменять без его участия.
2. Внешний SOC может помочь с поиском и обучением собственных аналитиков заказчика, но никогда не сможет гарантировать целостность данной команды.
3. Внешний SOC может идеально осуществлять мониторинг и реагирование на инциденты, но никогда не сможет помочь повысить уровень ИБ заказчика, если его специалисты не следуют предоставленным рекомендациям.

Валерия Суворова, Инфосистемы Джет:

1. SOC не ответит на вопрос, какие внутренние процессы, плейбуки и регламенты в области ИБ не работают, однако сможет подсветить проблемные места.
2. Принятие решений о том, куда инвестировать ресурсы (деньги, время, силы) для развития системы защиты, всегда остается на стороне заказчика. SOC может указать на некоторые слабые места, требующие особого внимания.
3. Техническое реагирование на инциденты и донастройка средств защиты – эти работы не каждый SOC может взять на себя. В Jet CSIRT такая опция доступна при необходимости.

Андрей Дугин, МТС RED:

SOC не может в одиночку выставить значения критичности для всех типов инцидентов, поскольку некоторые из них напрямую зависят от бизнеса и того, насколько те или иные кибератаки влияют на его непрерывность и устойчивость. Выявление аномалий в бизнес-процессах также требует взаимодействия с заказчиком, так как только он знает, какие этапы должен включать процесс, что является легитимными действиями, а что – нарушением. Кроме того, полномочия по принятию управленческих решений по результатам расследования инцидента – прерогатива заказчика.

Сергей Солдатов, Лаборатория Касперского:

1. SOC не обоснует необходимость инвестирования в ИБ перед руководством.
2. Безопасность работает, только если ею занимаются все подразделения, поэтому CISO – это в первую очередь эффективный переговорщик. Внешний SOC не сможет построить эффективные внутренние коммуникации с подразделениями, с которыми нет договоренностей.
3. SOC не оценит бизнес-ценность своих услуг для заказчика. SOC – это инструмент достижения одной из целей корпоративной безопасности, насколько он эффективен и результативен с позиции руководства компании, решать CISO.

Максим Акимов, Innostage CyberART:

Нельзя делегировать SOC-центру административную и уголовную ответственность, то есть принимать риски по локализации инцидента и механизму реагирования должен заказчик. К примеру, мы можем заблокировать скомпрометированный IP-адрес, но при этом встанет банкинг или процессинг и организация понесет финансовые потери, превышающие риски ИБ. В случае промышленной организации может остановится производство.

Теймур Хеирхабаров, BI.ZONE:

SOC точно не организует за заказчика взаимодействие между ИТ-подразделением и отделом кибербезопасности, которое крайне важно для качественного и своевременного реагирования на инциденты. SOC также не построит за заказчика систему кибербезопасности, не будет выполнять за него Hardening инфраструктуры, не выстроит внутренние процессы. Безусловно, коммерческий SOC может выступать консультантом, давать рекомендации в рамках инцидентов по усилению системы безопасности, но их непосредственное выполнение остается за заказчиком.

Артём Савчук, ПМ:

SOC не примет на себя полномочия и ответственность работников организаций, четко определенных нормативно-правовыми актами Российской Федерации.

Даниил Вылегжанин, RuSIEM:

SOC не решит задачи управления сетевой инфраструктурой, управления физической безопасностью предприятия и решением физических проблем, таких как отказ оборудования или проблемы с подключением. В таких случаях без специалистов "на месте" просто не обойтись. То же касается и принятия стратегических решений: SOC может предоставлять данные и аналитику о безопасности, но принятие стратегических решений по обеспечению безопасности остается ответственностью заказчика.

Каким должен быть первый шаг для подключения к SOC, если принципиальное решение уже принято?

Сергей Солдатов, Лаборатория Касперского:

1. Определение объема услуг, передаваемых в SOC, требований к их качеству (SLA), шаблоны отчетности, порядок коммуникации, матрица ответственности.
2. Построение эффективного взаимодействия внутренних служб (ИБ, ИТ, HR, PR, руководство и пр.) в рамках процесса управления инцидентами.

Александр Матвеев, IZ:SOC:

1. Конечно же, проконсультироваться с экспертами, которые годами занимаются предоставлением услуги SOC.
2. Определить функции, которые планируется возложить на внешнюю команду SOC.
3. Определить элементы инфраструктуры, мониторинг которой планируется осуществлять.
4. Воспользоваться услугой пробного бесплатного периода, который предоставляет внешний SOC, чтобы понять, устраивает ли качество, стоимость и экспертиза услуги именно выбранной команды. Желательно параллельно сравнить несколько SOC, если есть такая возможность.
5. Делать выводы, основываясь не на маркетинговых материалах, а на основе комплекса факторов, включая стоимость услуги, полученный результат, экспертизу и комфорт работы с внешней командой.

Руслан Амиров, Инфосистемы Джет:

Если речь идет о принятом принципиальном решении, первым шагом может быть запуск процедуры выбора поставщика услуг. Рынок коммерческих SOC в России представлен множеством организаций, и выбор можно провести по качественным и объективным критериям. В процессе взаимодействия с коммерческим SOC заказчик получит исчерпывающую информацию об услугах, технических особенностях подключения и определит область покрытия мониторинга. Пилотный запуск услуг SOC полезен как для проверки компетентности поставщика, так и для готовности заказчика к получению и использованию результатов.

Даниил Вылегжанин, RuSIEM:

В этом случае однозначно выбор поставщика услуг, оптимального по бюджету и SLA.

Андрей Дугин, МТС RED:

Первый этап – подготовка взаимодействия инфраструктур MSSP-провайдера и заказчика, инвентаризация ИТ-активов в контуре мониторинга SOC. Без четкого понимания защищаемой инфраструктуры и сервисов полноценно обеспечить их безопасность крайне затруднительно.

Теймур Хеирхабаров, BI.ZONE:

Определиться с границами подключения инфраструктуры к SOC, а также с набором услуг и функций, ожидаемых от коммерческого SOC. Это позволит очертить круг возможных сервис-провайдеров, а также оценить требуемый бюджет. При этом если у компании не было до этого опыта потребления услуг коммерческого SOC либо планируется смена сервис-провайдера, то крайне рекомендуется провести пилотный проект с одним-двумя игроками рынка. Это нужно для того, чтобы ожидания сошлись с возможностями рассматриваемых партнеров.

Артём Савчук, ПМ:

1. Формирование ТЗ.
2. Сбор ТКП.
3. Определение НМЦ.
4. Возможно, пилотное подключение к различным SOC, для сравнения.
5. Выбор подрядчика или подрядчиков.

Максим Акимов, Innostage CyberART:

Наш подход к приему в работу нового проекта включает последовательные шаги:

1. Запрос сведений об инфраструктуре заказчика.
2. Построение защищенного канала.
3. Подготовка инфраструктуры заказчика.
4. Подготовка инфраструктуры SOC. 5. Внедрение контента.
5. Согласование SLA-параметров сервиса.
6. Инвентаризация.
7. Наполнение базы знаний.
8. Настройка источников.
9. Обогащение индикаторами компрометации (IoC, TI).
10. Сдача приемочных испытаний. Передача на сервис.