Создание ситуационного центра информационной безопасности (Security Operation Center, SOC) требует детальной разработки регламентов, процессов, поиска квалифицированных кадров и создания грамотного технического решения. Как показывает практика, создание собственного SOC редко бывает оправданным. Намного проще и выгодней обратиться в компанию, предоставляющую SOC в качестве услуги. О том, как происходит такое взаимодействие, нам рассказал руководитель департамента разработки платформы анализа данных компании «Инфосекьюрити» (ГК Softline) Андрей Титов.
- Один из самых злободневных вопросов, который волнует потенциальных заказчиков сервиса SOC, это насколько глубоко в ИТ-систему нужно пустить провайдера.
На данный вопрос нельзя ответить однозначно, потому что все зависит от того, чего именно хочет заказчик. Допустим, если клиенту достаточно реактивных контролей, включающих только корректировку процессов и выявление инцидентов, то он может самостоятельно отправлять нам логи событий и этим ограничиться. При этом варианте мы не сможем управлять пограничными устройствами, корректно реагировать на вредоносные рассылки и корректировать правила фильтрации почты. Если заказчику требуется более высокий уровень обеспечения безопасности, то ситуация в корне меняется. Для того чтобы сервис SOC был полноценным, интегратору понадобится изучить инфраструктуру заказчика. Он должен узнать, как реализуется выход в интернет, как происходит сегментирование на уровне сетей, сколько у клиента ЦОДов, что нужно сделать, чтобы попасть из незащищенных сегментов в критичные, насколько отгорожен пользовательский сегмент от серверного. Без хорошего знания инфраструктуры заказчика невозможно заниматься расследованием инцидентов и их предотвращением.
- Как клиенты обычно реагируют на запрос прав доступа к сетевым устройствам или другим элементам инфраструктуры?
Нормально. У наших клиентов это уже сложившаяся практика. Даже банки не видят в этом ничего крамольного, потому что нам не требуется доступ к критичным вещам, например коммутаторам и гипервизорам. Что касается пограничных устройств: почтовые релеи, IDS/IPS, продукты Касперского, то нам без проблем предоставляют полноценный доступ к ним.
- Это фиксируется в SLA?
Да, конечно. SLA полностью определяет, какие конкретно услуги и на каких условиях предоставляются, ведь практически невозможно, к примеру, предоставлять качественный сервис по контролю рабочих станций, не имея доступ к установленному на них антивирусу.
- Если у компании-клиента уже есть накопленные годами практики, что с этим делать? Что означает для таких заказчиков переход на SOC?
Переход на SOC - это не ломание старого. Только совершенствование процессов. Своего рода эволюция. На практике это выглядит так: сначала мы просто мониторим систему и выявляем проблемы, ни во что особенно не вмешиваясь. Потом даем некоторые рекомендации по изменению наиболее уязвимых процессов. Правки вносятся плавно и постепенно, чтобы не нанести ущерб бизнесу или сложившимся процессам.
- Как выглядит proof of concept для SOCа? Наличие чего говорит о том, что у клиента есть SOC?
SOC - это процесс, при котором у заказчика должны быть выстроены процессы мониторинга событий, выявления инцидентов из этих событий и последующего реагирования на инциденты. Также необходима реализация и ревью созданных настроек на пограничных системах, системах обеспечения безопасности. Наконец, у заказчика должны быть люди, которые в состоянии определить потенциальный класс вредоноса и получить его бинарный образ. Я намеренно не упоминаю SIEM-системы. SIEM-системы по большому счету собирают все, но собранную информацию нужно использовать. SIEM-системы позволяют только упростить корреляцию событий, но это не означает, что самим ничего делать не нужно. С их помощью ручная аналитика переносится на уровень автоматизированной системы.
Если у вас остались вопросы, обращайтесь к руководителю продуктового направления отдела SOC департамента информационной безопасности Softline Михаилу Апостолову по тел. +7 (495) 232 00 23 | М +7 (916) 456-81-85 или e-mail Mikhail.Apostolov@softline.com
