Публикация MITRE «11 стратегий SOC-центра мирового уровня». Стратегия №3 «Выстраивайте структуру SOC в соответствии с потребностями компании». Часть 2

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

4. Выбор функций и услуг SOC

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

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

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

При принятии решения об объеме планируемых к предоставлению услуг SOC-центра авторы публикации рекомендуют учесть следующие положения:

1. Мониторинг и категорирование в режиме реального времени

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

2. Мониторинг и категорирование в режиме реального времени, анализ и расследование инцидентов

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

3. Анализ ВПО, форензик-анализ артефактов

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

4. Реагирование на инциденты с выездом на площадку заказчика

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

5. Настройка сенсоров и аналитики

В случае, если в ведении SOC находится парк оборудования и СЗИ для мониторинга (например, системы класса EDR, SIEM, UEBA, SOAR), то их настройка должна быть непрерывно поддерживаемой внутренней активностью, учитывающей обратную связь от аналитиков; следовательно, данная функция считается необходимой для SOC-центров, осуществляющих функции мониторинга. Важно отметить, что настройка сенсоров и правил является непрерывным процессом, необходимым для корректной работы парка технологий SOC, поэтому он должен осуществляться в рамках операционной деятельности SOC.

6. Анализ уязвимостей, симуляция атак и проведение аудитов

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

7. Устранение уязвимостей

Установка обновлений и обработка уязвимостей иным способом при росте SOC как правило передается в ИТ или в другое выделенное подразделение.

8. Оценка уязвимостей и сканирование на наличие уязвимостей

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

9. Разработка и управление функциями сетевой защиты

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

При повышении зрелости SOC расширяется и количество возможностей, которые также в определенной мере зависят друг от друга:

1. Сбор и обработка данных о киберугрозах, настройка сенсоров и аналитики, с ростом до проактивного поиска киберугроз и создания кастомизированных сигнатур

Непрерывная работа с различными источниками данных о киберугрозах учит аналитиков более избирательному их применению, способствуют разработке новых методов защиты и выявления атакующих до их проникновения в инфраструктуру ("left of hack"). Понимание TTPs атакующих и инфраструктуры компании, а также приобретаемые аналитические навыки органично способствуют созданию кастомизированных сигнатур и методик выявления киберугроз.

2. Анализ инцидентов, анализ ВПО, создание кастомизированных сигнатур и аналитики, с ростом до создания и распространения собственных данных о киберугрозах

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

3. Анализ инцидентов и анализ форензик-артефактов, с ростом до анализа ВПО и внедренных вредоносных программных закладок-имплантов

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

4. Настройка и установка инструментария SOC, с ростом до разработки собственного инструментария

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

5. Следует ли создавать свой SOC?

Создание собственного SOC не может и не должно быть необходимым условием для обеспечения мониторинга и реагирования на киберинциденты - выбор способа реализации и способа получения данных процессов зависит от различных факторов (чаще всего от размеров компании, её зависимости от информационной инфраструктуры и финансовых возможностей). Некоторым компаниям подойдет и модель аутсорсинга, а кто-то наверняка предпочтет in-house реализацию. Можно выбрать и гибридную схему, при которой часть функций реализуется во внутреннем SOC (например, базовый мониторинг и реагирование), а на аутсорс отдаются выделенные задачи (например, тестирование на проникновение, анализ ВПО.)

5.1. Компания, которой с большой вероятностью подойдет внутренняя, in-house реализация функций SOC-центра, скорее всего характеризуется следующими особенностями:

- Имеет выделенную ИТ-функцию и признает ключевую значимость ИТ для бизнеса;

- Имеет в распоряжении тысячи устройств (IT, OT, сетевые устройства), в инфраструктуре работают тысячи учетных записей;

- Инвестирует в кибербезопасность, управляет рисками, назначает выделенного ответственного за ИБ, выстраивает процессы управления уязвимостями, соответствием законодательству, инженерными сервисами;

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

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

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

- Не имеет ресурсного обеспечения и компетенций в ИТ;

- Имеет в распоряжении менее тысячи устройств (IT, OT, сетевые устройства), в инфраструктуре одновременно работает менее тысячи уникальных учетных записей;

- Не инвестирует в кибербезопасность, не выстраивает процесс управления рисками, не обеспечивает ситуационную осведомленность внутри компании;

- Не обладает бюджетом для выделения более двух работников на обеспечение кибербезопасности;

- Не имеет возможности, потребности или желания работать с инструментами мониторинга, аналитики, сканирования, включая облачные и on-prem технологии;

- Осознает, что все ИБ-потребности будут закрыты MSS-провайдером или, в случае принадлежности к холдинговой или другой крупной структуре - SOC-центром родительской организации;

- Положительно оценивает возможность сторонней организации реагировать на инциденты с активами компании без рисков ошибок или высоких затрат на интеграцию;

- Не требует непрерывного участия ИБ-команды в работе компании;

- Ожидает оперативного получения услуг по мониторингу и реагированию, не заинтересована в развитии функции SOC внутри компании.

5.3. Факторы успеха при аутсорсинге

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

- Дефицит квалифицированных ИБ-специалистов;

- Компания не может позволить платить рыночные зарплаты работникам SOC в соответствующем географическом регионе;

- Компания недостаточно крупна для построения своего SOC;

- Невозможность заполнить необходимые штатные единицы в виду редкой востребованности (например, анализ ВПО) или запросов (круглосуточное дежурство, ночные смены);

- Ожидание всплесков потребности в сотрудниках, например, в случае крупных инцидентов;

- Необходимость быстро нарастить штат SOC, без ожидания естественного, постепенного роста в течение длительного времени;

- Одновременный уход большого числа работников SOC и необходимость оперативного временного закрытия образовавшихся пробелов.

5.4. Расширение штата SOC с помощью аутсорсеров

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

5.5. Выбор функций SOC, передающихся на аутсорс

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

- Триаж предупреждений вне стандартного рабочего времени

Данная функция обычно возлагается на SOC-операторов уровня L1, которые работают в режиме 24/7. При аутсорсинге данной функции следует учесть, что компании придется предоставить аутсорсерам доступ к некоторым своим инструментам, а также заранее определить, какие действия будут производиться в рамках триажа предупреждений. Также следует учесть, что зачастую операторы уровня L1 «вырастают» внутри SOC до более ответственных позиций, а если уровня L1 нет, то потребуется набирать уже подготовленных специалистов извне.

- Анализ ВПО и форензик-анализ накопителей

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

- Поддержка при реагировании в критических ситуациях

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

- Тестирование на проникновение и Red Teaming (анализ защищенности с помощью эмуляции действий атакующих)

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

5.6. Использование инструментов «под ключ» как форма аутсорсинга

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

5.7. Модель полного аутсорсинга

В случае небольшой инфраструктуры (менее 10000 устройств/пользователей) содержание собственного SOC может быть нецелесообразным, но мониторинг и реагирование на инциденты ИБ всё равно требуется осуществлять - в этом случае компания может обратиться к MSSP (Managed Security Service Provider, провайдер услуг управляемой кибербезопасности) для полной передачи ему всех функций SOC. Критериями выбора MSS-провайдера могут быть:

- Бизнес-модель и ценовая политика;

- Какие технологии будут использоваться;

- Как MSS-провайдер будет понимать, что именно он защищает (активы, инфраструктуру, бизнес-процессы заказчика);

- Как будет выстроено взаимодействие между MSS-провайдером и заказчиком (например, в форме регулярной отчетности);

- При каких условиях и как инциденты будут эскалироваться на уровень заказчика вне регулярных коммуникаций;

- SLA-метрики реагирования;

- Уровень загруженности аналитиков MSSP;

- Выполнение каких законодательных норм может обеспечить MSS-провайдер;

- Каким образом MSS-провайдеры обучают, удерживают, поддерживают своих сотрудников, велика ли у них кадровая текучка;

- Каким образом обрабатывается и защищается информация, получаемая от заказчиков; как выстроена работа с используемыми инструментами и облачными провайдерами.

6. Необходимость работы SOC в режиме 24/7

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

- Какова вероятность активности атакующих вне стандартного рабочего времени?

- Каков размер компании, используются ли её ресурсы вне стандартного рабочего графика, есть ли у работников круглосуточный доступ к ресурсам компании?

- Есть ли в компании критичные круглосуточные бизнес-процессы, зависящие от ИТ-инфраструктуры?

- Бывали ли случай выявления киберинцидентов, которые могли бы быть предотвращены, если бы SOC работал круглосуточно?

- Если кибератаку заметил аналитик SOC вне стандартного рабочего времени, можно ли оперативно привлечь ресурсы для реагирования до наступления следующего рабочего дня?

- Какова штатная численность SOC, есть ли возможности по расширению команды SOC для введения круглосуточного режима работы?

- Можно ли попасть в офис компании вне стандартного рабочего времени, можно ли сделать для SOC исключение?

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

- Допустима ли задержка при обработке накопленных событий ИБ, которые произошли не в рабочее время (особенно с утра в понедельник, в случае не круглосуточной работы)?

Если SOC не имеет возможности работать в круглосуточном режиме, то можно рассмотреть гибридные варианты, например, когда только часть команды SOC работает круглосуточно (операторы L1), когда SOC работает в режиме 12/5 (охватывая самые активные часы работы компании), когда ограниченное количество работников SOC выходит на дежурство в выходные дни, когда у SOC есть несколько географически распределенных локаций и можно распределить нагрузку на них с учетом разницы во времени (модель "Follow the Sun", буквально «следуй за солнцем»), также можно рассмотреть вариант передачи обязанностей по мониторингу и реагированию вне рабочего времени на родительский SOC или MSS-провайдеру.

Если же принято решение о круглосуточной работе SOC, то следует учесть, что на дежурстве в любое время должны быть как минимум двое работников SOC, каждая круглосуточная должность эквивалентна примерно пяти FTE (Full-Time Equivalent, эквивалент полной занятости) с учетом отпусков и больничных, а аналитики на ночных сменах могут ощущать себя недооцененными и незаметными для остальной команды (поэтому рекомендуется ротировать ночные и дневные смены).

7. Выбор местоположения для SOC центра

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

- Следует предоставить SOC-центру физическую локацию и инфраструктуру для работы (помещения, серверные комнаты, СКС, сетевую связность с сегментами сети компании и интернет): лучше всего для этого могут подойти помещения внутри офиса компании или дата-центра;

- Необходимо обеспечить обмен информацией и согласованность действий между подразделениями SOC;

- Следует разграничить зоны ответственности между SOC и ИТ/ИБ-подразделениями компании; физическое присутствие SOC в офисе компании поможет сгладить возможные трения;

- Коллективу и руководителям SOC следует тесно общаться с руководством компании и подразделениями компании;

- Аналитикам SOC следует предоставлять информацию о бизнес-процессах компании и контексте бизнес-операций для более эффективного выявления и реагирования на киберугрозы; физическое присутствие аналитиков в офисе компании поможет более тесно взаимодействовать с работниками компании и производить физические действия с элементами ИТ-инфраструктуры в рамках реагирования;

- SOC не следует фокусироваться только на том офисе/подразделении компании, в котором физически находятся члены команды SOC; следует уделять внимание проблемам в других локациях и подразделениях для сохранения контроля за функцией мониторинга и реагирования в них;

- Следует синхронизировать график работы большинства работников SOC с графиком работы компании;

- Рекомендуется предусмотреть географически распределенную структуру SOC для обеспечения непрерывности работы (COOP, англ. Continuity of Operations); инфраструктуру и операции SOC-центра следует включить в процессы обеспечения непрерывности деятельности и восстановления работоспособности.