Очень часто, в презентациях про SOC говорят про классическую триаду, которая позволяет создать хороший центр мониторинга, - "люди - процессы - технологии". Эта триада так въелась в головы многих, что ее уже никто не воспринимает критически. В то время как она является некорректной по сути и уводящей многие SOC не туда. Я, во время рассказа о наших сервисах про проектирование или аудит SOCов постоянно сталкиваюсь с этой проблемой и так как она носит уже хронический характер, то я решил посвятить ей отдельную заметку. Тем более, что и после публикации в блоге презентаций по теме
SOC меня стали часто спрашивать, что такое сервисная стратегия SOC, зачем она нужна и чем сервисы SOC отличаются от его процессов. Причиной тому служит слайд, который я постоянно использую во всех своих презентациях по SOC - и в 30-тиминутных, и в 8-мичасовых.
 |
| Составные части сервисной стратегии SOC |
Идея разделения сервисов и процессов SOC очень проста. Представим, что у нас в организации есть две стороны - потребитель услуг SOC и их исполнитель (то есть служба ИБ или внешняя организация). Так вот существует два совершенно отличных друг от друга подхода к организации деятельности SOC (да и любой другой деятельности тоже). Первый заключается в непосредственном управлении деятельностью центра мониторинга, которая обычно представляется в виде процессов (мониторинга, реагирования, threat intelligence и т.п.). В этом случае за конечный результат отвечает потребитель, который и должен установить правила для процессов, а поставщик должен эти правила соблюдать. Второй подход заключается в том, что мы управляем только значимыми для потребителя результатами деятельности без погружения в детали ее организации. В контексте SOC разумнее именно так и поступать, так как врядли бизнес будет сам устанавливать правила для непонятных ему процессов. Особо внимательные читатели заметили, что второй подход - это классический сервисный подход, описываемый ITIL или CoBIT. В этом варианте за конечный результат отвечает поставщик, а заказчик SOC - только за корректные требования к результату.
Сервисный подход требует более высокого уровня зрелости от службы ИБ и по сути взаимодействие с ней строится по тем же самым принципам, что и с внешней аутсорсинговой компанией (разве что без заключения юридически значимого договора). У нас также прописывается SLA между бизнесом и SOC, в соответствие с которым мы начинаем предоставлять бизнес-ориентированные услуги, которые
понятны бизнесу. А с внутренними поставщиками (либо с отделами/группами SOC, либо с внешними поставщиками услуг TI, реверс-инжиниринга вредоносного ПО, фишинговых симуляций и т.п.) прописываются OLA (operational level agreement), которые фиксируют обязательства внутренних поставщиков в части работоспособности софта и железа, выполнения операций (например, реагирования на инциденты) в заданные временные рамки и т.п.
 |
| Пример каталога сервисов SOC |
И вот тут стоит вновь вернуться к тому, с чего я начал заметку. В чем же разница между процессами и сервисами SOC? В процессной модели правила организации того, что и как делает SOC, должен определять потребитель, то есть бизнес, которому мы и "продаем" идею SOC. Но бизнес не способен это сделать по вполне банальной причине - мониторинг ИБ и реагирование на инциденты не входят в список основных функций и задач бизнеса. В итоге роль установщика правил для SOC переносится с потребителя на поставщика. Получается двуединый организм - служба ИБ сама устанавливает правила для SOC, сама их реализует и контролирует. Получается классическая "безопасность ради безопасности" и SOC не в состоянии продемонстрировать свою нужность бизнесу, так как он с самого начала устранил бизнес из процесса установления правил игры.
Отличие же сервисной модели не только в активном вовлечении бизнеса в процесс установления правил игры и невмешательства в процессы их реализации - не важно как, важно, чтобы было сделано в рамках установленных границ времени, бюджета, издержек, качества и т.п. Важно, что в сервисной модели SOC
берет на себя ответственность за оказываемые услуги. Службы ИБ сегодня, к сожалению, не готовы к такой модели своего функционирования. Они не хотят брать ответственность за свои действия и бездействие, а также не могут сформулировать на понятном бизнесу языке, что они ему "дают", в чем их ценность. Тоже самое относится и к SOC, который в итоге не может похвастаться сервисным каталогом (ни внешним, для бизнеса, ни внутренним, для подразделений SOC) и концентрируется только на процессах.
 |
| Пример высокоуровневого описания одного из сервисов SOC в сервисной стратегии |
Говоря о потребителе услуг SOC надо уточнить, что под словом "бизнес" я понимаю не только классические бизнес-подразделения, которые зарабатывают деньги. Например, в банке это может быть розничный блок, корпоративный блок или инвестиционный блок. Это также может быть подразделение внутреннего контроля, HR, бэкофис или ИТ. У каждого из них могут быть свои "хотелки", которые могут быть реализованы в рамках SOC. И для таких потребителей каталог бизнес-сервисов должен быть описан понятным именно им языком (например, "мониторинг увольняющихся сотрудников", "мониторинг негативного фона в социальных сетях", "мониторинг VPN-сервисов", "мониторинг корпоративной почты", "мониторинг доступности ДБО" или "мониторинг удаленного доступа руководства").
Формирование такого каталога и набора сервисов, с понятным наполнением, не будут пустой тратой времени - как минимум, это позволит сформулировать и определить метрики оценки качества оказываемых SOCом услуг именно для бизнеса, а также понять, кто именно может быть заказчиком такой услуги? Если у услуги больше одного заказчика (например, у услуги "мониторинг ИБ"), тем сложнее будет договориться с ними со всеми, определить содержание услуги, критерии оценки ее качества и, в перспективе, определить стоимость такой услуги для внутреннего заказчика. Гораздо проще детализировать услуги по бизнес-подразделениям или бизнес-процессам (хотя внутри SOC это будут практически одни и те же процессы, технологии и люди). Например, мониторинг ИБ розничного и корпоративного блоков в финансовой организации (немного утрируя, конечно) хоть и отличаются, но незначительно. Зато у этих двух сервисов появляется четкий заказчик, с которым можно обсуждать детали оказания услуг.
 |
| Именно сервисная стратегия определяет все последующее - процессы, технологии, людей в SOC |
Надо ли переходить на сервисную модель в SOC? Это большой вопрос. С одной стороны это позволит показать свою нужность бизнесу и заручиться его поддержкой, в том числе и финансовой. С другой, это требует определенной зрелости от службы ИБ и готовность брать на себя ответственность за принимаемые решения и получаемые результаты. Не все к этому готовы. Кроме того, переход к сервисной модели и определение SLA и OLA может привести к обострению внутренних конфликтов между группами SOC, которые не привыкли работать в четко оговоренных рамках. Представьте, что вы начинаете требовать от своей группы Threat Intelligence, чтобы она не просто тратила деньги на источники фидов и в реактивном режиме сообщала в группу мониторинга о новых индикаторах компрометации с задержкой в пару дней ("так выходные же были"), но и прогнозировала новые атаки и проактивно сообщала о том, как с ними бороться, а также обновляла каталог use case'ов, playbook'и и др.
Поэтому сервисная модель для SOC - это не то, что надо брать и реализовывать прямо сейчас. Мы в рамках своих услуг про нее говорим всегда и всегда начинаем сервисы по проектированию или аудиту уже построенных SOC с ее разработки, но ее наполнение сильно зависит от того, к чему готов сам владелец SOC. Если с бизнесом у него контакт не налажен, то SOC - это набор привычных нам процессов. Если же налажен, то можно говорить в сервисном подходе так, как это понимает ITIL или CoBIT. Возможны оба подхода.
ЗЫ. И, кстати. Не стоит забывать, что SOC может быть не только набором процессов, но и проектом. Когда его строят или когда проводят аудит и обновление, тогда SOC превращается в проект со сроками начала и конца работ, менеджером проекта, временными участниками, конечной целью.
