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

Руслан Рахметов, Security Vision

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

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

В Уставе SOC должны присутствовать такие положения, как:

1. Назначение SOC единым центром киберопераций и мониторинга кибервторжений, киберзащиты, реагирования на киберинциденты заказчика

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

3. Полномочия SOC на выполнение следующих действий:

· Развертывание, эксплуатация, поддержка хостовых и сетевых систем активного и пассивного мониторинга;

· Проактивное и реактивное сканирование хостов и сетей для составления карты сети и выявления активов, определения их настроек безопасности и статуса уязвимостей, установки патчей;

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

· Реагирование на подтвержденные киберинциденты при прямом взаимодействии и сотрудничестве с необходимыми лицами и подразделениями

· Сбор, хранение, анализ цифровых артефактов, включая носители, логи, сетевой трафик, в целях обеспечения анализа инцидентов (как по требованию, так и на постоянной основе), с соблюдением применимых законодательных норм и ограничений.

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

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

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

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

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

1. Обладать самыми высокими полномочиями для подчиненных SOC-центров

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

3. Координировать действия подчиненных SOC при реагировании на инциденты;

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

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

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

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

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

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

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

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

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

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

5. Перечень внешних разрешенных портов и протоколов, которые могут использоваться при пересечении периметра компании для доступа через DMZ, к ИТ-инфраструктуре контрагентов и открытых в/из Интернет;

6. Стандарты присвоения имен хостам, включая требования по наименованию устройств для понимания их типа и роли на основании их DNS-имени;

7. Иные политики по конфигурированию ИТ-систем и соответствию требованиям, от требований к сложности паролей до стандартов защищенной настройки устройств;

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

9. Перечень согласованных ОС, ПО, системных образов, стандартных baseline-настроек устройств различного типа (серверы, ПК, ноутбуки, сетевое оборудование, ПАК);

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

11. Политика аудита с описанием типов событий ИБ, которые должны собираться на определенных видах систем, сроками хранения журналов аудита, перечнем ответственных за обработку, сбор и хранение журналов аудита;

12. Роли и ответственные со стороны контрагентов применительно к реагированию на киберинциденты;

13. Юридически значимые документы, касающиеся классификации информации, персональных данных, хранения информации, сбора улик и их применимости в суде, правила дачи разъяснений работниками и проведения внутренних проверок (расследований) по фактам выявленных киберинцидентов.

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

1. Требования по сетевой доступности и пропускной способности;

2. Планирование на случай недоступности потребляемых/предоставляемых услуг;

3. Порядок уведомления о сетевых сбоях и инцидентах, временные нормативы по восстановлению, эскалации, отчетности;

4. Порядок уведомления о киберинцидентах, процедуры восстановления, временные нормативы по эскалации и отчетности;

5. Четкое разделение зон ответственности за внедрение, эксплуатацию, поддержку средств и мер защиты, которые должны применяться для приобретаемых сервисов.

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

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

2. Полномочия организации, которая является родительской для SOC;

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

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

5. Перечень услуг и возможностей, которые SOC будет предоставлять;

6. Выбранная организационная модель SOC: Tier-модель с дочерними SOC и родительским SOC или централизованная модель SOC.

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

1. Подчиненность CIO или CISO

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

2. Подчиненность COO

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

3. Подчиненность CSO

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

4. Объединение с NOC

Объединение SOC с NOC (Network Operations Center, центр сетевого мониторинга, как правило находится в подчинении департамента ИТ) может дать преимущества как в разрезе экономии бюджета (за счет объединения двух структур), так и в части объединения компетенций (например, сетевое оборудование, оснащенное функциями обеспечения сетевой безопасности, может администрироваться как в SOC, так и в NOC).

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

5. Размещение SOC в структуре бизнес-подразделения

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