Сложный путь от SIEM к SOC

Сложный путь от SIEM к SOC

«Если хочется иметь то, что никогда не имел,
придётся делать то, что никогда не делал».
Коко Шанель

Начатая в 2007 году сертификация по PCI DSS существенно изменила ландшафт защиты инфраструктуры большинства банковских организаций: появились новые сложные системы и средства защиты, произведено описание и регламентирование внутренних процессов взаимодействия и обеспечения безопасности.

Одним из наиболее распространённых на сегодняшний день решений, приобретаемых в рамках подготовки к сертификации, является SIEM (Security Information and Event Management) – платформа, позволяющая закрыть сразу несколько требований регулятора. Специалисты по информационной безопасности финансовых организаций получили в свои руки мощный инструмент мониторинга, выявления и расследования возникающих инцидентов ИБ.

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

ДЕЖУРНАЯ СМЕНА: ПЕРЕПЛАТИТЬ, НО ПОДСТРАХОВАТЬСЯ?..

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

Бизнес-руководители традиционно ожидают, что все критические инциденты информационной безопасности будут выявляться в круглосуточном режиме и длительность их разбора составит минуты, но никак не часы или дни. Наряду с этим в рамках подразделения ИБ крайне редко существует полноценная дежурная смена, функционирующая в режиме 24х7 и готовая выдерживать высокий уровень SLA по анализу инцидентов. В свою очередь, расширение подразделения (в среднем от 6 человек в штат), необходимое для создания такой смены, не всегда удаётся обосновать, так как инциденты, происходящие вне стандартных пределов рабочего времени, не слишком часты, а расходы на персонал, напротив, очень существенны.

...ИЛИ ЭКОНОМИТЬ С РИСКОМ?

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

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

ОТДАТЬ SIEM В НАДЁЖНЫЕ РУКИ: «ЗА» И «ПРОТИВ»

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

Последствия таких изменений для SOC достаточно существенны. С одной стороны, система начинает генерировать большое количество ошибок первого рода (ложных срабатываний), тем самым делая практически невозможными эффективную работу оператора и тем более соблюдение внутренних SLA. С другой стороны, всё больше инцидентов информационной безопасности остаются за пределами «радара» SIEM и их практически невозможно эффективно выявлять и расследовать. Поэтому эволюция SOC должна как минимум не отставать от развития компании.

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

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

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

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

Подобные услуги имеют длительную историю развития в рамках международного рынка и программ MSS (Managed Security Services) и сейчас становятся всё более востребованы среди компаний российского рынка. Как показывает практика, если у компании нет стойкого неприятия идеи использования внешних подрядчиков в вопросах обеспечения информационной безопасности, то указанный вариант является одним из оптимальных путей по запуску собственного Security Operation Center и переходу к оперативному и эффективному управлению инцидентами информационной безопасности.

BIS-СПРАВКА:

Использование лучших мировых практик и накопленная экспертиза в сфере управления ИБ позволили компании «Инфосистемы Джет» создать собственный коммерческий SOC (Jet Security Operation Center). Данный SOC может как предоставлять услуги по управлению инцидентами ИБ из «облака» (когда оборудование и лицензии SIEM предоставляются компании в аренду, что позволяет значительно снизить капитальные затраты), так и принимать на обслуживание уже существующий SIEM с адаптацией его состояния и выстраиванием полноценного процесса мониторинга и реагирования на инциденты.