Превосходный SOC, или Рецептура решения инцидентов

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

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

Организационная структура подразделений ИБ

Она часто является следствием уровня зрелости ИБ в организации. В компании X существует один отдел или группа из нескольких человек. Часто есть ответственный за определенную подсистему ИБ. В компании Y есть отдел или департамент с большим количеством сотрудников, между которыми есть четкое разделение обязанностей. Нередко есть целая группа специалистов, ответственных за ту или иную подсистему ИБ.

Широкий спектр задач, высокая сложность и большие масштабы используемых СЗИ, повышенные требования к службе ИБ требуют наличия в компании «узких» специалистов, ответственных за свой участок работы. Например, на каждое направление – сетевая безопасность, защита конечных узлов, инфраструктура открытых ключей и др. – выделяется по специалисту или группе экспертов.

Бизнес-ориентированность подразделений ИБ

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

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

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

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

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

Квалификация персонала

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

Задача руководителя состоит в выстраивании и совершенствовании процессов SOC, а также в управлении командой. Он является ответственным за выполнение SLA. Руководитель должен иметь отличный технический бэкграунд, уметь взаимодействовать с бизнесом и, по сути, быть «прослойкой» между специалистами и высшим руководством. Кроме того, он должен быть наставником и активно развивать своих подчиненных: правильно построенный SOC требует постоянного совершенствования специалистов, иначе можно очень быстро проиграть «гонку вооружений». Выстраивание эффективного взаимодействия с ИТ-подразделением также является важной частью работы руководителя.

В функции аналитика входят создание и эксплуатация ядра SOC, а также расследование инцидентов. Аналитик должен обладать широкими (если не энциклопедическими) знаниями работы операционных систем, ИТ-сервисов, которые ему предстоит защищать, а также СЗИ. В то же время он должен отлично знать продукт, который используется в ядре SOC. Таких специалистов на рынке очень мало, поэтому для их наличия в штате нужно либо создавать хорошие условия, либо растить их годами внутри компании. Вчерашними студентами и недельными курсами по SIEM здесь не обойтись. Неправильно настроенные средства защиты или приложения не смогут детектировать и предотвратить возможный инцидент.

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

Выстраивание процессов SOC

Создание и совершенствование процессов SOC лежит на руководителе. При этом необходимо учитывать, сколько специалистов и с какой степенью вовлеченности будут работать с SOC. Если сотрудники могут выделить на расследование инцидентов максимум 1–2 часа в неделю, разумно тратить это время только на самые критичные из них. Соответственно, при настройке сценариев определения инцидентов необходимо правильно задать критичность. Привлечение ИТ-подразделений при расследовании очень важно, так как только владелец системы знает, какой доступ является легитимным, а какая активность в работе пользователя – подозрительной. Формирование SLA для регламентирования метрик взаимодействия службы ИБ и ИТ-подразделения позволит значительно ускорить время расследования инцидентов.

Метрики управления инцидентами являются внутренним SLA службы ИБ (как для ИТ-службы – выполнение заявок от пользователей). Ключевые из них – время первичной обработки инцидента, время его расследования, количество инцидентов на единицу времени с разбиением по типу.

В правильном SOC должны быть определены роли и их функции. Наложив их на SLA, можно приблизительно оценить количество необходимых специалистов.

Подчеркнем, что есть 2 пути выстраивания процессов SOC – рациональный и идеальный (революционный). Рациональный подход подразумевает прежде всего использование тех ресурсов, которые есть. В качестве аналогии можно привести дизассемблирование бинарного исполняемого файла для получения исходного кода. При его исполнении мы точно так же пытаемся определить, что можно выжать из текущего состоянии. Можно сказать, что это плавное создание и совершенствование SOC. Подход требует меньших ресурсов для внедрения, чем идеальный путь. Правда, тяжелым грузом висит наследие прошлого: неправильная архитектура, устаревшие и некорректно настроенные СЗИ.

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

Выбор оптимальной платформы

При выборе платформы нужно определить функциональные – технические – требования к продукту: поддерживаемые форматы отчетов, масштабируемость архитектуры, лицензионные метрики и т.д. Требования к SIEM-решению, которое является ядром SOC, состоят из более чем 100 верхнеуровневых и около 500 детализированных параметров. Поэтому при отсутствии опыта выбора SIEM-системы рекомендуется обратиться к поставщику услуг. В функциональные требования могут быть также внесены сценарии определения инцидентов, интересные компании. Заказчиком определяются и дополнительные качественные требования – простота настройки правил и отчетов, интуитивно понятный интерфейс и т.д. Зачастую они выходят на первый план, поскольку более понятны конечному пользователю.

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

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

Реализация SOC

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

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

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