Стратегия 2. Найти баланс между размером и гибкостью. Часть 2.

4.3 Синхронизация операций по защите сетей между площадками и подразделениями

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

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

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

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

Существует множество доступных возможностей для коммуникации в режиме реального времени — голосовая связь через интернет (VoIP), видеоконференции, чат в реальном времени и веб-камеры на рабочем столе — но крайне редко они могут полностью заменить физическое присутствие. Когда подразделения SOC отделены друг от друга, даже когда находятся в разных помещениях одного здания, качество взаимодействия может пострадать. По этой причине мы часто совмещаем элементы централизованной и распределенной организационных моделей, как например, использование «заранее размещенных» аналитиков для подкрепления 1-й и 2-й Линий в основном рабочем центре SOC.

4.3.1. Цели и предпосылки

Остановимся на некоторых потребностях, которые нужно обеспечить, принимая решение о том, где физически размещать ресурсы SOC.(См. Таблицу 5.)

Мы будем использовать эти факторы в последующих разделах при рассмотрении некоторых стратегий шаблонных SOC из раздела 4.1.2.

Таблица 5. Факторы, которые нужно учитывать при выборе размещения SOC.

ЦельРассуждения
Обеспечить SOC физическое пространство, соответствующее потребностям и задачам SOC.Любому SOC, за исключением виртуальных, требуется физическое рабочее пространство. Обычно оно включает операционный этаж, бэк-офисы и серверную — каждое из помещений с безопасным доступом. Также подразумевается наличие соединения с WAN-сетями заказчиков, филиалами и центрами обработки данных с достаточной пропускной способностью. Текущие офисные помещения и центры обработки данных заказчика лучше всего удовлетворяют этим требованиям.
Синхронизировать операции между подразделениями SOC.Отдельные составляющие функций по защите сетей должны быть объединены в единую структуру — SOC. Весьма полезно объединить их «под одной крышей», поддерживая регулярное здоровое и порой неформальное взаимодействие.
Поддерживать четкое разделение функций SOC, функций ИТ и кибербезопасности.SOC находится в центре политического водоворота — многие представители заказчика считают, что какой-то элемент, обеспечивающий защиту сетей, может им мешать, подпитывая конфликт с SOC. Физическое присутствие неподалеку от других сторон дает SOC преимущество, обеспечивая постоянный тесный контакт, который помогает сохранить интересы и влияние SOC, которые видны другим заинтересованным сторонам.
Поддерживать тесный контакт с руководством заказчика и другими группами из Приложения Б.SOC должен использовать поддержку со стороны стоящих над ним организаций и координировать свои действия с различными группами при реагировании на инциденты, особенно, на крупные. Не смотря на то, что это можно сделать дистанционно, лучше всего сблизить их физически.
Предоставлять аналитикам более качественный контекст в отношении задач заказчика и операций, ускоряя тем самым анализ и реагирование.Располагаясь там же, где сосредоточены ИТ-активы и пользователи, SOC автоматически получает множество преимуществ: способность взаимодействовать с заказчиками, работать с датчиками напрямую и осуществлять реагирование на месте инцидента.
Убедиться, что фокус внимания SOC не смещен в сторону отдельной организации или географического региона.Аналитики будут автоматически вникать в происходящее в той локации, где они находятся. Это и плюс, и минус. Если аналитики предвзято относятся к своей площадке, что-то может быть упущено на других. В крайних случаях, например, в крупных неоднородных организациях удаленные точки будут самостоятельно выполнять функции контроля безопасности и реагирования на инциденты без координации с SOC — во многом потому, что они чувствуют, что находятся за пределами миссии SOC.
Лучше ориентировать часы работы персонала SOC на рабочее время заказчика.Рабочее время SOC должно охватывать рабочее время заказчиков. Практично размещать SOC в том же часовом поясе, где находится большинство клиентов. Если пользователи и ИТ-активы клиентов располагаются по всему миру, у SOC может быть больше возможностей поддерживать операции 24×7, в то время как аналитики будут работать только в дневное время.
Обеспечить непрерывность обеспечения защиты сетей, несмотря на разнообразие географии активов SOC.В идеале SOC следует считать неотъемлемой частью миссии заказчика. В этом случае руководство SOC и заказчика могут создать один или несколько дополнительных резервных или «сбалансированных по нагрузке» рабочих пространств для большего географического разнообразия и гибкости SOC.

4.3.2. Размещение главного SOC

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

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

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

Представителям SOC, скорее всего, придется регулярно организовывать встречи с ключевыми техническими экспертами заказчика (директором по информационной безопасности, системными администраторами, сотрудниками службы безопасности и т.д.), а также периодически с руководством заказчика (техническим директором [CTO], исполнительным директором [COO], ИТ-директором [CIO], генеральным директором [CEO] и т.д.). Постоянные изменения в политиках, архитектуре мониторинга, угрозах и инцидентах требуют постоянной координации. Если на серверах штаб-квартиры недостаточно мощности, места и охлаждения или в здании штаб-квартиры нет рабочего пространства, лучше подобрать подходящее место для SOC в ближайшем офисном здании, лучше всего принадлежащем или арендуемом заказчиком.

4.3.3. Малые и большие централизованные SOC

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

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

  1. Иметь по крайней мере два контактных лица или «доверенных агента» на каждой крупной площадке, где работает заказчик. Доверенные агенты должны соответствовать следующим критериям:
    • Как правило, являются системными администраторами или сотрудниками службы безопасности.
    • Отслеживают проблемы безопасности системы на данной площадке, например, инсталляцию новых систем и изменения сетевой архитектуры.
    • Имеют ключи от стоек с оборудованием SOC и это единственные сотрудники, которым разрешено физически работать с системами SOC.
    • По умолчанию являются контактными лицами по вопросам реагирования на инциденты на данной площадке.
    • Получают результаты аудита SOC, если таковой существует.
    • Представляют интересы SOC на данной площадке.
  2. Рекомендуется контактировать с доверенными агентами по крайней мере раз в квартал, чтобы убедиться, что они все еще занимают эту позицию и их контактные данные актуальны. Наличие нескольких доверенных агентов на одной площадке позволяет быстро заменить сотрудника в случае его отсутствия.
  3. Представители SOC должны участвовать в совещаниях ИТ по управлению конфигурацией систем и обсуждениях инженеров, относящимся к ИТ-активам на удаленных площадках.
  4. Представители SOC должны участвовать ежеквартальных или ежегодных мероприятиях, которые проводят локальные ИТ-службы, где обсуждаются основные IT-инициативы на площадке.
  5. Поддерживайте схемы размещения оборудования SOC в стойках в актуальном состоянии как локального, так и удаленного оборудования.
  6. Обеспечьте доступ к обновленным схемам локальных сетей и сетей в анклавах.

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

4.3.4. Подключение к работе удаленных аналитиков

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

Конечно согласовать работу специалистов SOC, распределенных по нескольким площадкам, будет непросто. Вот несколько рекомендаций, как синхронизировать работу SOC:

  1. Убедитесь, что аналитики на удаленных площадках проходят через такой же процесс отбора и обучения, как и все остальные аналитики SOC.
  2. Процесс локальной эскалации инцидентов и координация с руководством SOC действий по реагированию должны быть описаны в концепции операций SOC (CONOPS), закреплены в должностных инструкциях сотрудников и выполняться в соответствии с ними. Важно избегать ситуации, при которой меры по реагированию будут осуществляться без ведома руководства SOC.
  3. Старайтесь нанимать аналитиков на удаленных площадках, которые ранее занимались вопросами, связанными с информационной безопасностью именно там, поскольку они уже хорошо знакомы с местными особенностями работы и ИТ-культурой.
  4. Персонал на удаленных площадках может чувствовать себя отстраненным от основного SOC. Можно смягчить это ощущение следующими способами:
    1. Ежегодно командируйте удаленных специалистов в центральный SOC на срок от одной до трех недель, в зависимости от бюджета, чтобы наладить общение в команде и освежить знания.
    2. Подумайте о создании «виртуального центра SOC», где аналитики центрального офиса и удаленных площадок смогут подключиться к общему чату, провести совместную видео- или голосую конференцию во время дежурства.
    3. Обратите внимание остальной части команды SOC на успехи аналитиков удаленных площадок.
    4. Запланируйте регулярные встречи и созвоны руководства SOC с аналитиками на удаленных объектах, предоставляя им время для общения и поощряя тем самым их работу.
  5. На точках, где находится несколько аналитиков, подумайте над созданием «мини-центра». Это могут быть небольшие помещения, в которых может общаться персонал SOC этой площадки.
  6. Аналитики на удаленной площадке должны работать в часы, соответствующие рабочему времени данного региона.
  7. Убедитесь, что все потоки данных и сенсоры SOC интегрированы в единую архитектуру. И хотя площадка должна иметь свой собственный источник данных журналов и систем мониторинга, он должен быть частью единой согласованной архитектуры с аналитикой, специфичной для данной площадки или региона.
  8. Некоторые аналитики на площадке могут проявить навыки, достаточные для перевода их на Линию 2, работу по выявлению трендов или управления сигнатурами. Предоставьте им возможности для дальнейшей адаптации потоков данных, информационных панелей и данных SIEM под сценарии, специфичные для данной площадки.
  9. Рассмотрите возможности по расширению анклава SOC (описанного в Разделе 10) для использования аналитиками удаленного объекта, применяя один из следующих подходов:
    1. Подключите рабочие станции SOC к самому SOC через виртуальную частную сеть (VPN) со строгой аутентификацией и убедитесь, что доступ к особо важным материалам SOC тщательно контролируется.
    2. Используйте возможности удаленного тонкого клиента со строгой аутентификацией, если материалы удаленного объекта SOC не могут быть отграничены от других пользователей.

4.3.5. Централизованный SOC с непрерывными операциями

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

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

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

  1. Какие непредвиденные ситуации предусматривает план по обеспечению непрерывности работ? Насколько они реалистичны и как часто они могут возникнуть?
  2. Если основные системы клиентов или анклавы SOC были «взломаны», предусмотрена ли в резервных системах возможность изоляции от скомпрометированных систем
  3. В описанных обстоятельствах, если работа SOC была нарушена вместе с остальной частью объекта, на котором он расположен, какие клиентские системы остаются для защиты?
  4. Если в ходе реализации резервного центра возникали какие-либо препятствия, действительно ли задача по обеспечению защиты сетей была приоритетной для руководства заказчика?
  5. Насколько оправданно создание второго полноценного SOC?
    • Будет ли достаточно частичного дублирования функционала?
    • Будет ли создание резервного центра, пусть даже обеспечивающего лишь часть функций, более приоритетным, чем другие потребности, например, увеличение количества сенсоров или расширение штата?
    • Требуется ли резервному центру персонал, работающий на регулярной основе? Если да, то должен ли он работать в те же часы, что и основной SOC (например, 24×7), или достаточно обычного рабочего времени (8×5 или 12×5)?
  6. В случае непредвиденной ситуации, сколько по времени SOC может быть неработоспособен? Насколько быстро дублирующий центр должен полностью включиться в работу?
  7. Должен ли резервный центр функционально зависеть от инфраструктуры на главном объекте SOC (например, WAN и интернет-соединение)? Подобная зависимость может оказаться не оптимальным вариантом.

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

Даже в SOC, имеющих полноценный резервный центр с серверами и аналитиками на обоих площадках, крайне редко каждый из центров поддерживает весь функционал на двух площадках в полном объеме. Чаще всего во втором центре есть резервные системы, например, управляющие сервера SIEM и IDS, локальные датчики IDS, аналитики 1-й Линии и, возможно, несколько системных администраторов. При таком сценарии гораздо легче координировать взаимодействие, чем если бы мы делили аналитиков 2-й Линии, специалистов по выявлению трендов, работу с данными киберразведки, управление сенсорами, разработку и все остальные функции SOC между двумя площадками.

Независимо от того, какие функции находятся в дублирующем центре, концепция работы (CONOPS) SOC должна включать подробное описание компенсирующих элементов управления, чтобы поддерживать синхронную работу двух центров. Полезно также назначить руководителя резервного центра для координации с руководством основного центра и обеспечения комфортной работы локальных аналитиков. Одна из стратегий, которую можно использовать для SOC с резервным центром в другом часовом поясе — совмещать или смещать смены. Сдвигая смены на двух площадках, можно добиться постоянного мониторинга консоли. Например, если основной центр работает в режиме 8×5, время работы для второй площадки, размещенной с разницей на два часовых пояса, можно сдвинуть на два часа, что даст четыре часа пересечения. Таким образом, каждый центр работает в течение восьми часов, но вместе они обеспечивают покрытие временного диапазона 12×5.

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

  1. Найдите имеющееся помещение заказчика или центр обработки данных с несколькими запасными рабочими местами.
  2. Разверните там резервный экземпляр ключевых систем SOC — SIEM, хранилища данных PCAP и системы управления IDS для использования в случае сбоя.
  3. Подберите хорошее место для размещения некоторых рабочих станций SOC, например, рядом с офисом или рабочим местом доверенного агента.
  4. Настройте движение потоков данных безопасности в оба центра или обеспечьте постоянное их зеркалирование с первичного на вторичный.
    1. В случае выхода из строя основного центра, наличие данных журнала, которые будут сразу же доступны на резервной площадке, может быть очень ценно.
    2. Для обеспечения непрерывности работы, время на включение в работу резервного центра должно быть минимальным. Если системы мониторинга всегда готовы к работе, но не используются, включение осуществляется намного быстрее.
  5. Регулярно проверяйте (возможно, ежемесячно), что серверы и резервные системы работоспособны и имеют все актуальные обновления, в том числе патчи и изменения конфигурации.
  6. Раз в полгода проводите практическое обучение в резервном центре SOC.

Наличие резервных систем SOC очень удобно. Разместив их на второй площадке, SOC становится более устойчивым. Главный недостаток этой стратегии заключается в том, что любая работа непосредственно на системах резервной площадки потребует времени доверенного агента и расходов на командировку системных администраторов.

Таким образом, есть два ключевых элемента для эффективного обеспечения бесперебойной работы SOC:

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

4.3.6. Централизованный SOC с распределением по часовым поясам

Модель SOC, распределенного по часовым поясам (Follow the sun), включает три операционных центра, каждый из которых работает с разницей в восемь часовых поясов. Каждый центр дежурит в рабочие часы по местному времени (например, с 9 до 17). В 17 часов по местному времени, операционный центр передает полномочия следующему, где по местному времени 9 часов утра. И так повторяется каждые восемь часов, обеспечивая работу 24×7 без необходимости привлекать сотрудников к работе в ночную смену.

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

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

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

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

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

4.3.7. Многоуровневый SOC

Мы ввели концепцию многоуровневой архитектуры обеспечения защиты сетей, где несколько SOC функционируют как подразделения единого SOC в рамках крупной организации. Существует много примеров, когда такая структура может быть оправдана: в каждом подразделении Министерства обороны, Казначейства, Министерства юстиции, Министерства внутренней дел и т.д. Хотя у каждого из этих подразделений есть один SOC с полномочиями, распространяющимися на весь департамент, для каждого такого SOC существует несколько подчиненных, которые выполняют большую часть «тяжелой работы» по обеспечению безопасности сетей в организации. К ним относятся региональные Сетевые операционные центры безопасности (NOSC) Армии США, Служба финансового управления в рамках Казначейства, Администрация по борьбе с наркотиками при Министерстве Юстиции, а также Иммиграционная и таможенная служба в рамках Министерства внутренних дел. Во всех этих случаях у нас есть SOC на уровне отделов или министерств, а также несколько подчиненных SOC в каждом.

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

В многоуровневом сценарии задача центрального SOC  — обеспечить безопасность заказчика и поддерживать стратегическую перспективу.

Как различить эти роли? Используя типовые возможности раздела 4.1.2, рассмотрим, как эти два SOC взаимодействуют и распределяют задачи по защите сетей (См. таблицу 6.).

ОбязанностьРоль центрального SOCРоль подчиненного SOC
МестонахождениеРасположен в штаб-квартире заказчика или рядом с ней.Расположен в офисе или штабе нижестоящего заказчика.
Мониторинг, обнаружение инцидентовВ отношении активов заказчика, не относящихся к подчиненным SOC, например, интернет-шлюзы.В пределах выделенных клиентов.
Ситуационная осведомленностьСтратегическая для всей организации.Тактическая в пределах собственной клиентской организации.
Анализ угроз и киберразведкаСтратегическое взаимодействие между организациями, отчетность перед подчиненными организациями, детальный анализ тактик, техник и процедур злоумышленника.Тактический внутри клиентской организации, потребителя централизованного анализа угроз, направлен на отдельные инциденты.
Реагирование на инцидентыКоординация между клиентами, операционное направление.Реагирование внутри клиентской организации.
Управление данными, относящимися к безопасностиПолучение сводной информации и отчетов об инцидентах от подчиненных; анализ и хранение данных из активов, не относящихся к подчиненным, таких как интернет-шлюзы.Анализ и накопление собственных данных, дополненных данными других организаций.
ОбучениеСогласованная программа для всех аналитиков в клиентской организации.Выполнение общего и специализированного обучения для собственного SOC.
Отчетность передРуководство клиентских организаций, внешние организации.Собственное руководство заказчика, центральный SOC.
Возможности и инструменты мониторингаЛицензирование на всю организацию, руководящие действия по развертыванию и обновлению инструментов.Выбор размещения средств мониторинга и специализированного оборудования при необходимости.

Таблица 6. Различия ролей для многоуровневого подхода к организации SOC.

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

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

Риc. 15. Потоки данных между центральными и подчиненными SOC

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

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

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

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

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

4.3.8. Координационные SOC

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

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

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

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

  1. Обеспечение безопасных форумов для взаимодействия между подчиненными SOC (например, wiki и безопасные онлайн-форумы)
  2. Выполнение стратегического анализа по тактикам, техникам и процессам злоумышленника с использованием отчетов о завершенных инцидентах. Мега-SOC занимает уникальное положение, фокусируясь на отслеживании и выявлении трендов в отношении ключевых участников кибер-пространства.
  3. Организация центра по обработке сообщений от поставщиков информации, сигнатур IDS и контента SIEM, данные которых другие SOC смогут использовать напрямую без дополнительных трудозатрат. Мега-SOC может собирать показатели из данных кибер-разведки в адаптированной для человека форме и предоставлять их обратно как в форме, понятной для человека, для использования аналитиками подчиненных SOC, так и в машиночитаемой форме для SIEM-систем. Однако, чтобы это сработало, данные разведки должны транслироваться с нужной скоростью и обогащаться необходимыми подробностями. Скорее всего, это потребует обработки и трансляции данных киберразведки в пределах нескольких часов или дней, при этом потребуется сохранить как можно больше исходных подробностей и признаков.
  4. Сбор и обмен передовым опытом операций по защите сетей, технологическими документами и техническими рекомендациями.
  5. Обеспечение анализа вредоносных программ и расследования инцидентов для клиентских SOC, которые собрали необходимые файлы или образцы, но не имеют персонала для их анализа.
      • Из всего набора функций, которые может выполнить мега-SOC, эта может оказывать наибольшее влияние, потому что многие SOC с трудом поддерживают набор навыков, необходимый для расследования инцидентов или анализа вредоносных программ при возникновении крупного инцидента.
      • Сюда может также входить автоматический веб-обменник для детонации вредоносного ПО (см. Раздел 8.2.7.) или углубленный анализ человеком носителей или образов жестких дисков.
  6. Предоставление корпоративных лицензий на ключевые технологии обеспечения безопасности сетей, например, инструменты мониторинга сети и узлов, сканеры уязвимостей, инструменты маппинга сетей и SIEM, при соблюдении следующих двух условий: (1) подчиненные не обязаны использовать конкретный продукт и (2) спрос со стороны подчиненных SOC достаточен для приобретения корпоративной лицензии.
  7. Проведение обучения аналитиков:
  • По использованию популярных коммерческих и open-source инструментов, таких как IDS и инструментов для анализа вредоносных программ.
  • Процессу реагирования на инциденты.
  • Оценке уязвимостей и тестированию на проникновение.
  • Использованию виртуального «кибер-полигона», где аналитики смогут по очереди атаковать и защищать изолированную сеть, созданную для операций Red Team/Blue Team.
  • Тренировка аналитиков SOC с помощью сценариев вторжений, используя реальные инструменты для анализа реалистичных данных о вторжении.

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

Более подробную информацию о создании национальной SOC см. в [60].

Поделиться записью: