Здание SOC: от чертежа до заселения

Таким образом, формула работающего SOC выглядит так: SOC = персонал + процессы + технические инструменты

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

Конечно же, это не означает, что технические системы вторичны. Без SIEM, IPS, сканеров уязвимости, систем управления заявками, средств анализа дампов памяти и трафика, систем подготовки отчетности и визуализации представить современный SOC невозможно. Мы довольно подробно обсуждали техническую начинку SOC в Jet Info № 8, 2015. В этой статье мы сосредоточимся на вопросах выстраивания процессов и формирования команды SOC.

Формулирование целей, задач и ключевых параметров SOC

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

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

На данном этапе имеет смысл задуматься о разработке целевых показателей эффективности создаваемой системы и методов их подсчета.

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

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

SOC, обслуживающие внешние компании, обычно рассматриваются отдельно. К таким SOC относятся, например, отраслевой центр внутри группы компаний, SOC, предоставляющий услуги аутсорсинга, и т.п. Вопреки ожиданиям, основные подходы к построению таких SOC те же, что и в случае «стандартных» корпоративных Security Operation Center.

Определение основных процессов и процедур в SOC

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

Каждый процесс декомпозируется на отдельные подпроцессы и процедуры. Не стоит недооценивать объем этой задачи: за вечер функциональную архитектуру SOC не накидаешь. За 2 дня до написания этих строк мы участвовали в совещании, на котором различные подразделения одной из российских компаний обсуждали процедуру сбора для SOC инвентаризационных данных от дочерних компаний. В итоге возникло такое количество технических, организационных и «политических» спорных моментов, что к концу совещания дискуссия по своему жару не уступала обсуждению годового бюджета. А ведь это, казалось бы, небольшая деталь.

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

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

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

Персонал SOC

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

Кто нам нужен?

В деле подбора персонала стоит исходить из принципа «качество важнее количества». На ключевых позициях должны быть профессионалы высочайшего уровня. Это тот случай, когда лучше нанять одну «звезду», чем двух рядовых аналитиков (особенно на старте создания SOC).

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

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

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

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

Конечно, не каждый SOC может позволить себе 2 линии. Однако такое разделение позволяет наиболее эффективно использовать знания персонала.

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

Где искать сотрудников?

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

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

Костяк команды должен быть сформирован как можно раньше, чтобы он участвовал во внедрении систем и отладке процессов. Если есть такая возможность, стоит привлечь к работе в SOC часть работающих в компании сотрудников, знающих особенности ее ИТ-инфраструктуры, ИБ-систем и бизнес-процессов.

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

Обучение сотрудников

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

Режим работы SOC

Важный вопрос, который часто вызывает много споров, – режим работы SOC. Ясно, что идеальным вариантом является 24х7 в полную мощность. Многие, особенно направленные атаки, осуществляются ночью. Это приводит к тому, что при работе в режиме 8х5 полноценная реакция последует только к обеду следующего рабочего дня, когда аналитики разгребут завал данных за ночь (или выходные) и разберутся в ситуации.

Однако наш опыт проектов показывает, что расходы на режим 24х7 могут оказаться неподъемными. В сменах работают живые люди, которым необходимы выходные и отпуск. Работа более 8 часов в день в первой линии и 12 во второй не желательна, так как от специалистов требуются внимание и быстрая реакция. Таким образом, только на первую линию нужны минимум 4–5 человек на полную ставку (а ведь желательно, чтобы аналитики еще и страховали и перепроверяли друг друга, а также передавали дела между сменами, получаем все 8 человек). Поэтому зачастую компании формируют промежуточные варианты. Например, 12х5 с двумя пересекающимися сменами по 8 часов в будни и 8 часов в выходные. Аналитики второй линии могут работать при этом в режиме 8х5. На ночь консоль SIEM можно выводить дежурной ИТ-смене, чтобы они отслеживали хотя бы самые критичные ситуации (если для компании это приемлемо с точки зрения безопасности).

Отметим, что найти аналитиков второй линии, готовых работать в ночное время, довольно сложно. С первой линией в этом вопросе, как правило, проще.

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

Использование аутсорсинга

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

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

Сравнение основных параметров своего SOC и аутсорсингового варианта показаны на рис 3.

Понятно, что аутсорсинг подразумевает определенный набор стандартных сервисов. Построить SOC полностью под себя можно только внутри компании. Немаловажны и вопросы безопасности. Аутсорсинговый SOC обрабатывает крайне чувствительную к разглашению информацию: построение системы защиты, ход расследования инцидентов, учетные записи для удаленного доступа и др. Далеко не каждая компания готова рисковать такими данными. Однако за последние 5 лет заказчики стали относиться к этому несколько проще.

Осознавая все pro et contra аутсорсинга, ряд наших заказчиков выбрал гибридную схему: на первых этапах большая часть задач выносится на аутсорс, параллельно строится свой SOC. Плюсы подхода очевидны. К минусам относится, разумеется, стоимость. К тому же все разработанные правила корреляции и настройки оборудования сервис-провайдер вам наверняка не передаст, особенно бесплатно. Все это, скорее всего, придется делать заново.

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

ИБ внутри SOC

Quis custodiet ipsos custodes? Лат. «Кто устережёт самих сторожей?»

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

Для SOC нужно разработать отдельные стандарты обеспечения ИБ, строже, чем для всей остальной компании. Инфраструктура SOC должна быть максимально разделена с корпоративной, сетевой сегмент отделен межсетевыми экранами и построен на отдельном сетевом оборудовании. Идея добавить машины SOC в общий домен компании, например, кажется абсурдной, однако мы видим, что это довольно распространенная практика. Стоит исходить из того, что вся ИТ-инфраструктура компании уже скомпрометирована. При построении SOC не стоит забывать, что его глаза и уши – это сетевые сенсоры, IPS, СЗИ, раскиданные по всей компании. Безопасный доступ к ним и их защита должны быть тщательно проработаны. Аналитикам SOC нужен постоянный доступ в интернет и к корпоративным сервисам, и тут рекомендуемое нашей ФСТЭК применение 2 отдельных рабочих станций с KVM-свитчем вполне актуально.

Как и в случае с любой компанией, самые большие риски ИБ для SOC исходят изнутри. Здесь нужно разделять злой умысел и разгильдяйство. Шанс взять на работу потенциального внутреннего злоумышленника не так мал: лучшие ваши аналитики могут иметь практический опыт, лежащий если не в черной, то в серой зоне. А хорошее понимание механизмов защиты и детектирования, а также существующих возможностей подзаработать за счет компании делают внутреннего нарушителя очень опасным врагом. Ловить такого инсайдера техническими методами не слишком перспективно. Лучше сосредоточиться на тщательном отборе персонала, внедрить перекрестный контроль работ, ротацию сотрудников и просто не терять бдительности. Что же касается разгильдяйства, выражение «сапожник без сапог» справедливо в отношении доброй половины ИБ-шников. В любой компании первыми кандидатами на владение 5 лет не обновляющейся ОС являются администраторы ИТ, а вторыми – сами специалисты по ИБ.

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

Горячей темой для споров всегда было предоставление информации о работе SOC сотрудникам компании и внешним структурам. Не стоит впадать в одну из крайностей: превращаться в тайную полицию или водить по SOC экскурсии для всех желающих. На наш взгляд, стоит впадать в обе. С одной стороны, SOC должен быть другом и помощником каждого сотрудника компании: сюда можно обратиться при подозрении на инцидент, здесь повышают осведомленность в области ИБ, тут можно получить актуальную информацию о рисках, консультацию, совет. С другой – информация о средствах, методах мониторинга и защиты, ходе расследований должна быть доступна единицам. Причем даже внутри SOC следует проработать ограничения по ее распространению. По поводу обмена информацией с коллегами из других SOC и CERT лучше принять решение сразу: или свести его на нет или же четко его регламентировать. Никакая конфиденциальная информация не должна попасть к СМИ, в программу конференции или security feed. Второй подход помогает установить полезные дружеские отношения с коллегами и реализовать амбиции лучших аналитиков SOC.

Как контролировать результаты

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

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

Еще в 1954 году в своей книге «The Practice of Management» Питер Друкер сформулировал критерий SMART, которому должны удовлетворять KPI, чтобы быть эффективными. Показатели должны быть конкретными, понятными, измеримыми, достижимыми, но амбициозными, они должны рассчитываться за строго определенный период или к определенному сроку.

К примеру, параметр типа «хакеры никогда не должны к нам пролезть» – это не KPI. Как это измерить и что это значит? Примерами KPI могут быть, например, «число просроченных критичных инцидентов не более N за месяц» или «суммарное время простоя ключевой системы по вине инцидентов ИБ не более M минут в квартал».

Использованию измеримых показателей эффективности ИБ мы посвятили отдельную статью. Применение KPI позволит быстро выявлять слабые места созданного «штаба компьютерной обороны» и вносить корректировки в его работу.

«Физика»

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

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

Один из наших заказчиков из сферы строительства рассказывал, как принято строить большие здания во Франции: 2 года идут детальное проектирование и планирование работ и затем за 1 год возводится постройка. Этот подход уместен и при строительстве «здания» SOC, если вы не хотите потом по живому прорубать отверстия для забытых труб и копать подвал под построенным домом.

Сейчас мы наблюдаем тенденцию к усложнению внутренних процессов SOC и появлению в них новых «измерений»: единые центры отслеживают не только инциденты ИБ, но и физическую безопасность, внутреннее и внешнее мошенничество.

В таких условиях детальная проработка целей, задач, процессов, макро- и микро-KPI становится залогом успеха построения SOC.