Как быстро запустить свой Security Operation Center (SOC)

Как быстро запустить свой Security Operation Center (SOC)

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

 

 

 

1. Введение

2. Что такое SOC и чем он не является

3. SOC с нуля: основные шаги

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

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

3.3. Обследование инфраструктуры и выбор технических средств  

3.4. Подбор персонала и определение режимов работы

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

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

3.7. Контроль результатов

4. Заключение

5. Полезные ссылки по теме

 

 

Введение

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

Как расставить приоритеты, с чего стоит начать построение SOC для достижения конкретных результатов в короткие сроки? На эти вопросы мы дадим ответы в этой статье.

 

Что такое SOC и чем он не является

При построении SOC важно помнить несколько моментов. Security Operation Center — это не только технические средства. Это команда, задача которой обнаруживать, анализировать, реагировать, уведомлять о возникновении и предотвращать инциденты информационной безопасности. Еще один немаловажный компонент SOC — это процессы, поскольку подразумевается взаимодействие между сотрудниками подразделения, отвечающего за мониторинг и реагирование на инциденты, а также между различными подразделениями (например, ИБ и ИТ). От того, насколько качественно выстроены эти процессы, будет зависеть эффективность работы SOC. Технические средства являются лишь инструментами, позволяющими автоматизировать часть процессов, которые функционируют в SOC. Ярким доказательством этому может послужить SOC одной из региональных энергетических компаний, в котором разбор инцидентов осуществляется сотрудниками подразделения без использования средств автоматизации. Но здесь нельзя забывать о том, что конкретно в этом примере поток событий от компонентов инфраструктуры невелик. Если же поток событий довольно большой, без SIEM-системы не обойтись, поскольку скорость реакции на инциденты будет низкой. Таким образом, формула идеального SOC выглядит так: SOC = Персонал + Процессы + Технические инструменты.

 

Рисунок 1. Функции SOC на основе классификации MITRE

Функции SOC на основе классификации MITRE

 

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

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

 

SOC с нуля: основные шаги

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

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

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

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

К ключевым параметрам SOC можно отнести:

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

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

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

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

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

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

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

Обследование инфраструктуры и выбор технических средств  

Итак, в компании появилось понимание того, какие процессы необходимо автоматизировать, чтобы подразделение SOC не погрязло в рутинной работе, разбирая все инциденты вручную. Какие же инструменты SOC необходимо использовать для повышения эффективности самого SOC? Мы отмечали ранее, что SOC прочно ассоциируется с SIEM. И это не случайно. Хотя теоретически возможно построение SOC и вовсе без SIEM, на практике такое сегодня встречается крайне редко. Для того чтобы внедрить SIEM и качественно настроить источники информации, необходимо собственно определиться с этими источниками и понять, какие правила корреляции потребуются. Для этого проводится инвентаризация ИТ- и ИБ-активов организации. Как показывает многолетний опыт, в вопросе инвентаризации очень помогают решения класса Vulnerability Management или, как принято их называть, сканеры уязвимостей. Эти решения позволяют в короткие сроки собрать информацию об имеющихся компонентах инфраструктуры и об их уязвимостях, а также в будущем предоставляют возможность отслеживать появление новых компонентов в инфраструктуре организации.

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

При подключении источников к SIEM важно понимать, что не все они смогут предоставить необходимые данные для SIEM. Во многом это зависит от уровня аудита, который настроен на источнике. Например, хорошо известна проблема с подключением баз данных к SIEM, связанная с деградацией производительности. Мы рекомендуем использовать наложенные средства защиты (Database Activity Monitoring / DAM). Данные решения позволяют получать более детальную информацию о каждой транзакции базы данных без ущерба для ее производительности. Аналогичная ситуация может быть и с другими источниками.

Еще одним неотъемлемым инструментом SOC является система Service Desk. У ряда производителей SIEM данный функционал предусмотрен, либо поддерживается интеграция со сторонними производителями. Этот инструмент позволит соблюдать сроки реакции на тот или иной инцидент и оценить эффективность работы подразделения в целом. Если сроки реакции не соблюдаются, то это повод задуматься над корректировкой процессов либо изменением схемы взаимодействия внутри подразделения.

Подбор персонала и определение режимов работы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

Заключение

«Как съесть слона? — По кусочкам!» —  эта шутка очень точно отражает процесс строительства SOC. Делать это с наскока не стоит, вас гарантированно ждет провал. Определите цели, доступные ресурсы, составьте план и двигайтесь последовательно, решая задачу за задачей. И в результате вы сможете создать для своей организации мощнейший инструмент по борьбе с инцидентами ИБ, живой и уникальный организм под названием SOC.

 

Полезные ссылки по теме

 

Авторы:

Тимур Ниязов
Андрей Янкин

Anti-Malware Яндекс ДзенПодписывайтесь на канал "Anti-Malware" в Telegram, чтобы первыми узнавать о новостях и наших эксклюзивных материалах по информационной безопасности.

RSS: Новые статьи на Anti-Malware.ru