Стратегия 3. Предоставление SOC полномочий для работы

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

  1. Какие полномочия нужны SOC?
  2. Какая организационная структура наилучшим образом поможет выполнению миссии по защите сетей?

5.1 Письменные полномочия

Каждый SOC существует, опираясь на некую политику в письменном виде, которая предоставляет ему полномочия для работы, использования ресурсов и внесения изменений. Кроме того у заказчика должен быть набор политик по ИТ и кибербезопасности, чтобы SOC мог выполнять свою миссию. В этом разделе мы рассмотрим оба документа. При подготовке политики вы можете посмотреть дополнительные рекомендации в разделе 2.5 из [8] и шаблоны политик, приведенные в [61].

5.1.1 Полномочия по регламенту

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

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

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

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

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

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

5.1.2 SOC нижнего уровня

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

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

5.1.3 Центральный координирующий SOC

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

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

5.1.4 Другие полезные политики

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

  • Согласие пользователей на мониторинг: предоставление SOC и аудиторам однозначных полномочий на мониторинг и осуществление любой деятельности во всех системах и сетях организации-заказчика.
  • Политика приемлемого использования: правила использования ИТ-систем, включая ограничения на использование веб-сайтов в Интернете, социальных сетей и авторизованного программного обеспечения на клиентских системах.
  • Политики конфиденциальности и обработки конфиденциальных данных: инструкции по управлению и защите разных типов информации, проходящей через контролируемую сеть, включая личную, медицинскую, финансовую и информацию, относящуюся к госбезопасности.
  • Внутренне разрешенные порты и протоколы: перечисление портов и протоколов, разрешенных внутри клиентской организации, внутри ядра и через границы анклава.
  • Внешние разрешенные порты и протоколы: перечисление портов и протоколов, которым разрешен доступ через внешние границы, например, доступ через демилитаризованную зону (DMZ), выход к деловым партнерам и в интернет.
  • Соглашения об именах хостов: описание соглашений для именования ИТ-активов и понимания их базового типа и роли на основе соответствующей DNS записи.
  • Другие политики конфигурации и соответствия ИТ: все, начиная от сложности пароля до совершенствования и настройки систем.
  • Политики использования личного оборудования (BYOD) и мобильных устройств (если применимо): правила, регулирующие взаимодействие личного оборудования и мобильных устройств сотрудников с сетями, приложениями и данными.
  • Утвержденные ОС, приложения и системные образы: общий утвержденный список ОС, приложений и базовых конфигураций систем для хостов каждого типа настольных компьютеров, ноутбуков, серверов, маршрутизаторов/коммутаторов и других устройств.
  • Авторизованное стороннее сканирование: правила уведомления SOC в случае, когда другая организация хочет выполнить сканирование, например, на предмет поиска уязвимостей или обнаружения сетей.
  • Политики аудита: высокоуровневое описание типов событий, которые должны быть зафиксированы для разных типов систем, длительность хранения данных, кто отвечает за просмотр данных и кто несет ответственность за сбор и сохранение данных – с определением влияния собранных данных на эффективность.
  • Роли и обязанности других организаций по реагированию на инциденты: Наиболее важные роли и обязанности, выделенные в Приложении A.
  • Письменные соглашения об уровне обслуживания (SLA), где это применимо:
    • Требования к пропускной способности и доступности сети.
    • Планирование на случай непредвиденного сбоя у поставщика сетевых услуг.
    • Сообщения о сбоях в сети (инцидентах), а также время на восстановление и эскалацию/отчетность.
    • Предупреждения об инцидентах информационной безопасности и процедуры обработки, а также время на эскалацию/отчетность.
    • Четкое понимание ответственности каждой стороны за внедрение, эксплуатацию и обслуживание инструментов или механизмов безопасности, которые следует применять к приобретаемым сетевым услугам.
  • Правовая политика: описывает классификацию информации, конфиденциальности, хранения информации, приемлемость доказательств и предоставления свидетельств во время расследований и судебного разбирательства по инцидентам.

5.2 Наследуемые полномочия

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

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

  • Организационная глубина – насколько низко в организационной структуре размещается SOC. Отчитывается ли SOC непосредственно перед ИТ-директором или погребен на 15 уровней вниз? Во втором случае, какие политики и процессы могут быть созданы для смягчения этого?
  • Какими полномочиями обладает материнская организация – как на бумаге, так и на практике?
  • Сила и влияние, которыми обладают руководители головных организаций. Согласованы ли они с миссией по защите сетей, могут ли они поддерживать модели полномочий, рассмотренные в разделе 2.3.3, и какова вероятность, что они не будут вмешиваться в повседневные процессы безопасности?
  • Установленный порядок финансирования и бюджет родительской организации. Могут ли они финансировать инструменты для всестороннего мониторинга и оплачивать персонал, необходимый для реализации всех возможностей, предусмотренных регламентом SOC?
  • Какие возможности предоставляет SOC?
  • Какова организационная модель SOC? Если он многоуровневый, могут ли подчиненные «мини-SOC» находиться в бизнес-подразделениях, а координационный SOC находиться под руководством ИТ-директора? Или если это централизованный SOC, может ли он находиться рядом с сетевым операционным центром и контролировать заказчика целиком?

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

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

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

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

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

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

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

5.2.1 Подчинение CIO или CISO

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

5.2.2 Подчинение главному операционному директору

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

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

5.2.3 Подчинение руководителю службы безопасности

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

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

5.2.4 Взаимодействие с сетевым операционным центром в рамках ИТ-операций

Наиболее распространенным организационным положением SOC является его логическое и/или физическое размещение в составе сетевого операционного центра или рядом с ним. Это обеспечивает ряд очевидных преимуществ: объединение операций 24х7, быстрое рассмотрение действий по реагированию единой структурой, которая балансирует сиюминутные потребности в безопасности и доступности. Кроме того, существует множество устройств, таких как межсетевые экраны и системы предотвращения вторжений, которые рассматриваются как разделяемые между сетевыми операциями и операциями по безопасности. Объединение обеих функций на одном уровне наблюдений (со специальным персоналом и инструментами) сэкономит деньги, особенно для предприятий, для которых не оправдано наличие отдельного SOC.

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

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

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

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

5.2.5 Встраивание внутрь отдельной миссии или бизнес-подразделения

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

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