Вопрос создания и функционирования центров мониторинга и реагирования на инциденты информационной безопасности является актуальным для многих компаний уже более четырех лет. Крупные организации, прежде всего субъекты критической информационной инфраструктуры, создали собственные центры или пользуются услугами специализированных компаний. Но некоторые предприятия все еще пытаются понять, как правильно выстроить процессы мониторинга и реагирования на инциденты, что делать самим, а что передать на аутсорсинг, – рассмотрим несколько подходов к решению этого вопроса.
Автор: Константин Саматов, руководитель комитета по безопасности КИИ, член Правления Ассоциации руководителей служб информационной безопасности
Вспомним, что из себя представляет SOC.
SOC (Security Operation Center) – аббревиатура, принятая в российском деловом сообществе, скорее всего придуманная маркетологами, используемая для обозначения центров мониторинга и реагирования на инциденты информационной безопасности. Существует мнение, что аббревиатура SOC абсолютно неверно используется, потому что в ней нет и намека на информационную безопасность. Тем не менее это практичнее, чем длинное название "центр мониторинга и реагирования на инциденты информационной безопасности" или даже его сокращение – ЦМРИИ.
Классический SOC базируется на триаде "люди, процессы, технологии" и имеет три уровня (см. таблицу).
Помимо линий, в SOC есть руководитель, осуществляющий функции управления, координации и контроля.
В зависимости от наличия этих линий SOC бывают разных классов, от начального, где в наличии только первая линия, до выполняющего полный набор функций, имеющего все три линии.
Кроме того, существуют различные уровни зрелости SOC [2]. Чем выше уровень, тем более зрелым, функциональным и совершенным является SOC.
Переведя теоретические знания в практическую плоскость, можно ответить на вопрос "Что делать самим, а что передать на аутсорсинг?".
Принято считать, что есть три варианта SOC:
Из анализа структуры SOC понятно, что невозможно передать подрядчику полностью все реализуемые процессы. Очевидно, что руководство деятельностью и контроль в части процессов мониторинга и реагирования должен осуществлять сотрудник заказчика. Такая же ситуация в части функций взаимодействия с пользователями информационных ресурсов и правовым обеспечением деятельности SOC – они не могут быть переданы, по крайней мере, в полном объеме. Таким образом, аутсорсинга всех процессов SOC на практике не существует. Заказчик всегда делает выбор между набором функций, выполняемых собственными силами, и передающимися внешней организации.
Анализ структуры SOC показывает, что выполнять собственными силами необходимо следующие функции:
Силами подрядчика целесообразно проводить экспертизу по различным направлениям, связанным с расследованием инцидентов. Такие услуги лучше приобретать у провайдера SOC по мере необходимости, так как экономически невыгодно содержать штат узкоспециализированных экспертов, ведь экспертиза требуется не повседневно, а лишь для конкретных случаев. Например, ежедневная криминалистическая экспертиза и каждодневный анализ вредоносного программного обеспечения в обычных условиях функционирования организации не требуется.
В части остальных процессов SOC решение об их передаче подрядчику будет в каждом конкретном случае и для каждого конкретного заказчика различным. Иными словами, руководитель службы информационной безопасности компании должен провести анализ плюсов и минусов (можно еще и нейтральных сторон) передачи той или иной функции на аутсорсинг.
Последний момент, на который следует обратить внимание: свой SOC – это всегда долго и дорого: такое мнение транслируют представители подрядчиков практически на каждой конференции по информационной безопасности. Но так ли это? Ответить на этот вопрос снова поможет теория.
Есть различные уровни зрелости SOC: создание SOC 4-го уровня зрелости в среднем займет у компании порядка трех лет, но SOC 1-го уровня зрелости можно сделать практически за 2–3 месяца, получив функционал, позволяющий мониторить критичные системы и осуществлять первичное реагирование на атаки и инциденты. Кстати, аналогичный срок обычно требуется и подрядчику для подключения инфраструктуры заказчика к своему SOC.
Что касается "дорого", то это понятие – не более чем баланс статей на обеспечение информационной безопасности в бюджете организации – капитальных и оперативных затрат. Услуги внешнего SOC отнюдь не дешевы, а внутренний SOC может строиться постепенно. При аутсорсинге всегда есть риск "потери" оперативных затрат и, как следствие, части функционала; такого риска нет в случае с собственным SOC.
Так что же все-таки лучше, свой SOC или внешний? Безусловно, ответ на этот вопрос сугубо индивидуален для каждой конкретной организации (руководителя службы информационной безопасности), но в основе его лежит общее правило: необходимо посмотреть на процессы SOC и оценить, какие из них выгодно передать на аутсорсинг, а какие – выгодно оставить "себе".