Security Operation Center (SOC) становятся все более популярными среди представителей различных секторов экономики. Атаки постоянно совершенствуются, а потому необходим эффективный инструмент, чтобы им противодействовать. Правильно расставленные приоритеты при построении SOC помогают достичь конкретных результатов в короткие сроки. Об этом подробно рассказано в данной статье.
2. Что такое SOC и чем он не является
3.1 Формулирование целей, задач и ключевых параметров SOC
3.2. Определение основных процессов и процедур в SOC
3.3. Обследование инфраструктуры и выбор технических средств
3.4. Подбор персонала и определение режимов работы
3.6. Использование аутсорсинга
Введение
Сегодня вопросами построения Security Operation Center (SOC) интересуются практически все представители отечественной экономики: от страховых компаний и банков до крупных промышленных предприятий. Такой интерес вызван прежде всего постоянно совершенствующимися атаками и потребностью в современном инструменте противодействия им. Действительно, SOC является одним из ключевых компонентов подразделения информационной безопасности любой организации. В первую очередь он нацелен на мониторинг, детектирование и оперативную реакцию на инциденты, и, как следствие, на сокращение ущерба и финансовых потерь, к которым тот или иной инцидент может привести.
Как расставить приоритеты, с чего стоит начать построение SOC для достижения конкретных результатов в короткие сроки? На эти вопросы мы дадим ответы в этой статье.
Что такое SOC и чем он не является
При построении SOC важно помнить несколько моментов. Security Operation Center — это не только технические средства. Это команда, задача которой обнаруживать, анализировать, реагировать, уведомлять о возникновении и предотвращать инциденты информационной безопасности. Еще один немаловажный компонент SOC — это процессы, поскольку подразумевается взаимодействие между сотрудниками подразделения, отвечающего за мониторинг и реагирование на инциденты, а также между различными подразделениями (например, ИБ и ИТ). От того, насколько качественно выстроены эти процессы, будет зависеть эффективность работы SOC. Технические средства являются лишь инструментами, позволяющими автоматизировать часть процессов, которые функционируют в SOC. Ярким доказательством этому может послужить SOC одной из региональных энергетических компаний, в котором разбор инцидентов осуществляется сотрудниками подразделения без использования средств автоматизации. Но здесь нельзя забывать о том, что конкретно в этом примере поток событий от компонентов инфраструктуры невелик. Если же поток событий довольно большой, без SIEM-системы не обойтись, поскольку скорость реакции на инциденты будет низкой. Таким образом, формула идеального SOC выглядит так: SOC = Персонал + Процессы + Технические инструменты.
Рисунок 1. Функции 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.
Полезные ссылки по теме
- Одна из лучших книг для людей, которые хотят погрузиться в тему SOC:
" HYPERLINK "http://www.mitre.org/sites/default/files/publications/pr-13-1028-mitre-10-strategies-cyber-ops-center.pdf"Ten Strategies of a World-ClassCybersecurity Operations Center" (http://www.mitre.org/sites/default/files/publications/pr-13-1028-mitre-10-strategies-cyber-ops-center.pdf) - Журнал JetInfo №8 от 2015 года, посвященный тематике SOC и выбору SIEM-платформы для SOC: http://www.jetinfo.ru/jetinfo_arhiv/soc-kak-chasovoj-mekhanizm/2015
- Лучшие практики в области управления инцидентами ИБ:
- ISO/IEC 27035:2011 Information technology — Security techniques — Information security incident management
- NIST SP800-86 Guide to Integrating Forensic Techniques into Incident Response
- NIST SP800-83 Guide to Malware Incident Prevention and Handling
- SANS. "Security Operations Centre (SOC) in a Utility Organization"
- SANS. "Building a World-Class Security Operations Center: A Roadmap
- SANS. "Knitting SOCs"
Авторы:
Тимур Ниязов
Андрей Янкин
