Стратегия 1: Консолидировать защиту сетей в рамках одной организационной структуры

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

  • Операции синхронизируются между элементами CND.
  • Задачи по обнаружению и реагированию выполняются продуктивно без ущерба для точности, эффективности или релевантности.
  • Ресурсы на обеспечение защиты сетей можно задействовать максимально полно.
  • Данные, составляющие ситуационную осведомленность, и данные об инцидентах поступают операторам защиты сетей и на инструменты в замкнутом цикле.
  • Консолидированные непротиворечивые данные, составляющие ситуационную осведомленность, предоставляются руководителю по реагированию на инциденты и его цепочке управления.

В результате, мы выделяем пять неразрывных составляющих обеспечения защиты компьютерных сетей, которые должны находиться под одной командной структурой:

  1. Мониторинг и приоритизация в реальном времени (Линия 1).
  2. Анализ инцидентов, координация и реагирование (Линия 2 и выше).
  3. Сбор и анализ данных киберразведки.
  4. Настройка и управление сенсорами, использование и поддержка инфраструктуры SOC.
  5. Разработка и развертывание инструментария SOC.

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

Функции защиты сетей в SOC
Рис. 10. Все функции защиты сетей в SOC

К сожалению, опыт взаимодействия с несколькими десятками правительственных и коммерческих SOC показывает, что задача по обеспечению защиты сетей часто распределяется между несколькими независимыми структурами. Например, мониторинг системы обнаружения вторжений (IDS) (Линия 1) может осуществляться центром управления сетями (NOC), а реагирование на инциденты (Линия 2) – ИТ-подразделением.

Разделение этих основных функций, как правило, приводит к одному или нескольким последствиям:

  1. Сниженный темп действий,
  2. Нарушенные или неэффективные внутренние процессы,
  3. Неэффективное взаимодействие,
  4. Замедление развития системы по защите компьютерных сетей,
  5. Враждебность/недоверие между различными сторонами, участвующими в обеспечении защиты сетей.

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

  • Мониторинг в реальном времени и приоритизация или анализ инцидентов, координация и реагирование:
    • Эскалация инцидентов и последующие процессы разрозненны и фрагментированы.
    • Инциденты медленно обрабатываются, а Линия 1 получает слабую обратную связь.
  • Консолидация обеспечения защиты сетей в рамках одной структуры:
    • Трудно воздействовать на контроль качества того, что поступает с операционного уровня.
    • Карьерный рост аналитиков осложняется, сложнее удержать аналитиков.
    • В некоторых сценариях архитектура мониторинга защиты сетей и набор инструментов сильно раздроблены, как правило, вследствие некоторых различий в требованиях пользователей и децентрализации ресурсов.
  • Сбор данных киберразведки и аналитики:
    • Мониторинг SOC ни на чем не фокусируется и не улучшается.
    • SOC не успевает реагировать на изменения в ландшафте угроз.
    • SOC не воспринимается клиентами как ресурс для ситуационной осведомленности.
    • В инструментах мониторинга неэффективно используются TTP и индикаторы из доступных источников данных киберразведки и, следовательно, они не соответствуют текущему уровню угроз и уязвимостей.
  • Настройка и управление сенсорами:
    • Системы SOC приходят в неисправное состояние.
    • Время простоя систем SOC увеличивается, поскольку ответственный персонал не подчиняется руководству SOC.
    • В сенсорах отсутствуют актуальные сигнатуры.
    • Результаты мониторинга и обработки инцидентов не приводят к улучшению/настройке пакетов сигнатур или контента SIEM-систем.
    • SOC не может эффективно поддерживать независимость и защищенность от остальной части архитектуры клиентов, потому что его системные администраторы и/или инструменты входят в общий пул ИТ-поддержки.
    • Системы выходят из строя, а персонал SOC не может осуществлять тактические корректирующие действия или решать более серьезные проблемы на уровне проектирования системы.
  • Разработка и развертывание инструментария SOC:
    • Между SOC и разработкой возникает серьезное недопонимание из-за совпадений в технических знаниях и различий в приоритетах и видении проекта.
    • Разработка не удовлетворяет операционным приоритетам SOC, как с точки зрения своевременности реализации новых возможностей, так и потребностей оператора.
    • Искусственное разделение между операторами и разработчиками вызывает путаницу в обязанностях; раздельный процесс работы не позволяет SOC использовать тактические решения.
    • Поскольку инженеры не участвуют в процессах SOC, они не полностью понимают потребности операторов, вне зависимости от качества и детализации требований.
    • Многие возможности SOC лучше всего разрабатывать “по спирали”, что позволяет быстро реализовать нужные возможности для операционистов и менять их по мере необходимости; жизненные циклы разработки, когда проекты кочуют между этапами цикла, не поддерживают этого.
    • Неоднозначность источников финансирования SOC может осложнить процесс координации финансирования, выделения бюджетов на капитальные вложения и техническое обслуживание.
    • Разделение бюджета на обеспечение защиты сетей может привести к дисбалансу денежных средств, выделяемых на инструменты, персонал и обучение.

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

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

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

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

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

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

 

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