Журнал "Information Security/ Информационная безопасность" #5, 2020

ламенты, прописываются процедуры реагирования. В результате на базе этого SIEM достраиваются процессы SOC. – Решение каких задач и какие возможности получает потреби- тель услуг SOC? Алексей Юдин: Это очень зависит от заказчика, его желаний, возможно- стей и даже от зрелости внутренних процессов. Большая часть заказчиков, которые еще не пробовали такой сервис, но которым нужно достаточно быстро решить задачу мониторинга (причиной могут быть регуляторные или внутрен- ние требования), настаивает просто на получении уведомлений. То есть мы подключаем инфраструктуру заказчика к своей системе, настраиваем правила выявления инцидентов, и заказчику начинают приходить уведомления об инцидентах. Роль SOC на этом закан- чивается, и заказчик дальше уже сам решает, как реагировать на инцидент. Это базовый уровень сервиса, который мы оказываем. Второй уровень – это первичное реа- гирование. То есть заказчику не просто поступает уведомление об инциденте на электронную почту, но и начинается обработка этого инцидента специали- стом первой или второй линии, который определяет степень важности и критич- ности инцидента. В этом же уведомлении приходят рекомендации о том, что нужно сделать заказчику на своей стороне, чтобы либо собрать дополнительные данные для понимания критичности инцидента, либо снизить последствия инцидента. Достаточно большое коли- чество компаний работают именно в этом режиме. Третий уровень – действительно ком- плексный. Когда присутствует опреде- ленный уровень доверия к провайдеру услуг, заказчик предоставляет доступ в свою инфраструктуру для частичного управления средствами защиты, ОС, сетевым оборудованием и т.д. Это дела- ется для того, чтобы, во-первых, снизить нагрузку на ИТ-специалистов, а во-вто- рых, чтобы ускорить реагирование. Но таких заказчиков пока не очень много, хотя, на наш взгляд, этот вариант сер- виса самый оптимальный. – Если компания решила, что нужен SOC, с чего следует начать? Алексей Юдин: Сначала нужно ответить себе на вопрос: зачем? Потому что то время, когда иметь SOC было модно, уже прошло. Подход несколько лет назад был сле- дующим: а давайте соберем все данные, будем их хранить и они нам потом, воз- можно, когда-нибудь пригодятся или давайте включим 300 правил корреляции и будем реагировать на все. Но через некоторое время обязательно возникал вопрос: деньги мы потратили, а что в итоге получили? К счастью, ситуация изменилась. Сей- час в основном все компании понимают, что SOC – это необходимость, а основные вопросы касаются окупаемости затрат на построение и эксплуатацию SOC. А начать всегда можно с формули- ровки целей SOC, какой выделен бюд- жет, на каких решениях он будет построен, какие регуляторные требова- ния должен закрыть, кто его будет экс- плуатировать, с какими внутренними системами его нужно интегрировать, кто будет выявлять и реагировать на инциденты и в каком режиме. – Можете ли вы рассказать о публичных внедрениях вашего решения? Александр Дворянский: На сего- дняшний день мы имеем возможность рассказать лишь о двух, но зато инте- ресных, кейсах. Гибридную схему под- ключения к SOC использует государст- венная транспортная лизинговая компа- ния, ПАО "ГТЛК". Проект интересен тем, что в 2017 году компания купила PT SIEM. Затем вместе с развитием компа- нии появилась необходимость контро- лировать несколько разрозненных пло- щадок, включая международные, а сле- довательно пришло понимание, что про- стого SIEM уже недостаточно. То есть нужны регламенты, методология, струк- турированные и отлаженные процессы реагирования на инциденты, а главное – 14 • В ФОКУСЕ