Rambler's Top100
 
Статьи
Яков ГРОДЗЕНСКИЙ   03 сентября 2019

SOC – свой или чужой: размышления вслух

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

Идея создания единого центра обеспечения безопасности (Security Operations Center, SOC) родилась внутри больших корпораций. Если в ИТ-инфраструктуре работают сотни или тысячи узлов, то в систему SIEM (Security Information and Event Management) попадает огромное количество событий. Отличить реальные инциденты от пользовательских или от технических ошибок в таком случае очень сложно – ресурсов одного человека или небольшой команды для этого не хватает. Практика показывает, что большинство взломанных компаний не могли сразу определить атаку и тратили слишком много времени на поиск внутренних проблем. Для первичного реагирования на инциденты и дальнейшего распределения их по ответственным службам необходима мощная команда аналитиков и наличие соответствующей экспертизы. Здесь возникают два важных вопроса: готова ли корпоративная система безопасности к созданию такой структуры и целесообразно ли строить ее внутри компании или же лучше воспользоваться внешним сервисом?

Зрелость корпоративной ИТ-инфраструктуры

Чтобы вопрос о необходимости центра обеспечения безопасности вообще возник, бизнес должен быть достаточно крупным, а ИБ-департамент – достаточно зрелым. Централизованная команда обрабатывает ежесекундно регистрирующиеся в различных информационных системах события, и если посадить людей на ручной разбор журналов, они погрязнут в потоке данных и за деревьями не увидят леса. Создание SOC – это заключительная стадия. Для начала в компании должны быть развернуты решения, регистрирующие события и вычленяющие возможные инциденты: современные межсетевые экраны, системы класса DLP, системы поведенческого анализа, антивирусные продукты, песочницы и другие аппаратные и программные средства.

Если всего этого нет, то проанализировать вручную огромное количество разрозненных данных и вычленить из них инциденты попросту невозможно, а самое главное – непонятно, как на эти инциденты реагировать. Информацию из разных источников потребуется собрать в одном месте, поэтому до создания SOC нужно внедрить систему класса SIEM или арендовать ее у внешнего провайдера услуг обеспечения безопасности (Managed Security Service Provider, MSSP). Кроме того, важно и наличие решения  для реагирования на инциденты класса IRP (Incident Response Platform) или его новейшей реинкарнации SOAR (Security Operations, Analytics and Reporting).

Зрелость бизнеса

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

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

Требования законодательства

Часто необходимость создания SOC обусловлена требованиями российского законодательства о защите критической информационной инфраструктуры (КИИ). Согласно Федеральному закону № 187, все субъекты КИИ должны отправлять данные об инцидентах в НКЦКИ (ГосСОПКА), а финансовые организации – еще и в отдельный центр мониторинга.

Хотя закон напрямую не требует наличия корпоративного центра обеспечения безопасности, неизбежно возникает вопрос: а кто будет заниматься отправкой данных? Если инцидентов достаточно много (с точки зрения ФСБ даже спам считается инцидентом), возникает все та же ситуация: один человек или небольшая команда не справятся с потоком данных. Придется либо замалчивать большую часть происшествий и ждать последствий, либо вкладывать ресурсы в создание полноценного SOC.
Важный момент: под действие закона подпадают не только организации, имеющие значимые объекты КИИ, взаимодействовать с государственными центрами мониторинга должны все субъекты.

Свой или чужой?

Если после анализа и оценки рисков в организации приходят к решению о необходимости SOC, возникает главная дилемма: создавать новую структуру внутри или воспользоваться услугами внешнего центра обеспечения безопасности. В первую очередь нужно учесть наличие в штате аналитиков, способных писать грамотные и проверенные экспертизой правила корреляции инцидентов. Кроме того, может потребоваться система класса SOAR, способная обобщить и обогатить данные об инцидентах информацией из внешних источников (репутационных баз, баз компрометации). Если этих ресурсов нет, нужно четкое понимание того, в какую сумму обойдется их приобретение и содержание внутри компании и как эта сумма соотносится со стоимостью получения экспертизы и услуг SOC на стороне.

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

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

Чтобы определиться с выбором, лучше обратиться к оказывающему консалтинговые услуги в сфере ИБ системному интегратору. Потраченные на обследование деньги могут многократно снизить стоимость лечения проблемы – избежать ошибок на начальном этапе обычно проще (и дешевле), чем потом их исправлять.

Яков Гродзенский, руководитель направления информационной безопасности, «Системный софт»
Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!