SOT

SOT

SOAR
Security Orchestration, Automation and Response

Автоматизация реагирования на инциденты информационной безопасности при помощи динамических плейбуков с применением СЗИ, выстраиванием цепочки атаки и объектно-ориентированным подходом

NG SOAR
Next Generation SOAR

Автоматизация реагирования на инциденты ИБ со встроенной базовой корреляцией, сбором сырых событий непосредственно с СЗИ, динамическими плейбуками, выстраиванием цепочки атаки и объектно-ориентированным подходом

AM
Asset Management

Описание ИТ-ландшафта, обнаружение новых объектов в сети, категорирование активов, инвентаризации и управления жизненным циклом оборудования и ПО на АРМ и серверах организаций

VM
Vulnerability Management

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

ГосСОПКА
Государственная Система Обнаружения Предупреждения и Ликвидации Последствий Компьютерных Атак

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

FinCERT
Financial Computer Emergency Response Team

Двустороннее взаимодействие с Центральным Банком (ЦБ РФ, ЦБ РБ и др.), а именно передача информации об инцидентах и получение оперативных уведомлений/бюллетеней от регулятора

Напишите нам на sales@securityvision.ru или закажите демонстрацию

GRC

GRC

КИИ
Критическая Информационная Инфраструктура

Аудит и исполнение требований ФЗ-187 «О безопасности критической информационной инфраструктуры Российской Федерации» и других нормативных документов

RM
Risk Management

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

ORM
Operational Risk Management

Учёт и фиксация событий операционных рисков (СОР), мониторинг ключевых индикаторов рисков (КИР) и проведение самооценки /контроля согласно положению №716-П ЦБ РФ

CM
Compliance Management

Аудит соответствия и комплаенса различным методологиям и стандартам

BCP
Business Continuity Plan

Автоматизация процесса обеспечения непрерывности и восстановления деятельности (ОНиВД) после наступления чрезвычайных ситуаций

Напишите нам на sales@securityvision.ru или закажите демонстрацию

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

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

  |  Слушать на Google Podcasts  |   Слушать на Mave  |   Слушать на Яндекс Музыке  |  


Руслан Рахметов, 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, который функционирует уже на уровне всей компании и подчиняется руководителям высшего звена.

SOC ГОСТы и документы ИБ Стандарты ИБ Управление ИБ Подкасты ИБ MITRE

Рекомендуем

Защита критической информационной инфраструктуры (конспект лекции)
Защита критической информационной инфраструктуры (конспект лекции)
Зачем и как отображать информацию: конструктор объектов
Зачем и как отображать информацию: конструктор объектов
«Фишки» Security Vision: создание экосистемы
«Фишки» Security Vision: создание экосистемы
Сетевая форензика с помощью ZUI
Сетевая форензика с помощью ZUI
Нормативные документы по ИБ. Часть 15. Обзор российского законодательства в области ИБ финансовых организаций - продолжение
Нормативные документы по ИБ. Часть 15. Обзор российского законодательства в области ИБ финансовых организаций - продолжение
Управление рисками информационной безопасности. Часть 1. Основные понятия и методология оценки рисков
Управление рисками информационной безопасности. Часть 1. Основные понятия и методология оценки рисков
Нормативные документы по ИБ. Часть 14. Обзор российского законодательства в области ИБ финансовых организаций - продолжение
Нормативные документы по ИБ. Часть 14. Обзор российского законодательства в области ИБ финансовых организаций - продолжение
Принципы информационной безопасности
Принципы информационной безопасности
Lessons Learned: почему никогда не стыдно взять и всё переделать
Lessons Learned: почему никогда не стыдно взять и всё переделать
IoCs / Индикаторы компрометации / Indicators of Compromise
IoCs / Индикаторы компрометации / Indicators of Compromise
Сценарии реагирования, или чем процессы ИБ/ИТ похожи на театр
Сценарии реагирования, или чем процессы ИБ/ИТ похожи на театр
Управление и обслуживание ИТ сервисов
Управление и обслуживание ИТ сервисов

Рекомендуем

Защита критической информационной инфраструктуры (конспект лекции)
Защита критической информационной инфраструктуры (конспект лекции)
Зачем и как отображать информацию: конструктор объектов
Зачем и как отображать информацию: конструктор объектов
«Фишки» Security Vision: создание экосистемы
«Фишки» Security Vision: создание экосистемы
Сетевая форензика с помощью ZUI
Сетевая форензика с помощью ZUI
Нормативные документы по ИБ. Часть 15. Обзор российского законодательства в области ИБ финансовых организаций - продолжение
Нормативные документы по ИБ. Часть 15. Обзор российского законодательства в области ИБ финансовых организаций - продолжение
Управление рисками информационной безопасности. Часть 1. Основные понятия и методология оценки рисков
Управление рисками информационной безопасности. Часть 1. Основные понятия и методология оценки рисков
Нормативные документы по ИБ. Часть 14. Обзор российского законодательства в области ИБ финансовых организаций - продолжение
Нормативные документы по ИБ. Часть 14. Обзор российского законодательства в области ИБ финансовых организаций - продолжение
Принципы информационной безопасности
Принципы информационной безопасности
Lessons Learned: почему никогда не стыдно взять и всё переделать
Lessons Learned: почему никогда не стыдно взять и всё переделать
IoCs / Индикаторы компрометации / Indicators of Compromise
IoCs / Индикаторы компрометации / Indicators of Compromise
Сценарии реагирования, или чем процессы ИБ/ИТ похожи на театр
Сценарии реагирования, или чем процессы ИБ/ИТ похожи на театр
Управление и обслуживание ИТ сервисов
Управление и обслуживание ИТ сервисов

Похожие статьи

Основы риск- и бизнес-ориентированной информационной безопасности. Часть 3. Основные понятия и парадигма - продолжение
Основы риск- и бизнес-ориентированной информационной безопасности. Часть 3. Основные понятия и парадигма - продолжение
Что такое фактор аутентификации, зачем нужен второй и сколько их всего
Что такое фактор аутентификации, зачем нужен второй и сколько их всего
Публикация MITRE «11 стратегий SOC-центра мирового уровня». Стратегия №8 «Используйте инструменты автоматизации для обеспечения работы аналитиков SOC»
Публикация MITRE «11 стратегий SOC-центра мирового уровня». Стратегия №8 «Используйте инструменты автоматизации для обеспечения работы аналитиков SOC»
ChatGPT в ИБ - на темной и светлой стороне
ChatGPT в ИБ - на темной и светлой стороне
The Hive. Разбор open source решения
The Hive. Разбор open source решения
Обзор публикации NIST SP 800-207 "Zero Trust Architecture"
Обзор публикации NIST SP 800-207 "Zero Trust Architecture"
Управление информационной безопасностью (ISO 27000)
Управление информационной безопасностью (ISO 27000)
Нормативные документы по ИБ. Часть 5. Обзор российского и международного законодательства в области защиты персональных данных
Нормативные документы по ИБ. Часть 5. Обзор российского и международного законодательства в области защиты персональных данных
Защита веб-приложений: WAF
Защита веб-приложений: WAF

Похожие статьи

Основы риск- и бизнес-ориентированной информационной безопасности. Часть 3. Основные понятия и парадигма - продолжение
Основы риск- и бизнес-ориентированной информационной безопасности. Часть 3. Основные понятия и парадигма - продолжение
Что такое фактор аутентификации, зачем нужен второй и сколько их всего
Что такое фактор аутентификации, зачем нужен второй и сколько их всего
Публикация MITRE «11 стратегий SOC-центра мирового уровня». Стратегия №8 «Используйте инструменты автоматизации для обеспечения работы аналитиков SOC»
Публикация MITRE «11 стратегий SOC-центра мирового уровня». Стратегия №8 «Используйте инструменты автоматизации для обеспечения работы аналитиков SOC»
ChatGPT в ИБ - на темной и светлой стороне
ChatGPT в ИБ - на темной и светлой стороне
The Hive. Разбор open source решения
The Hive. Разбор open source решения
Обзор публикации NIST SP 800-207 "Zero Trust Architecture"
Обзор публикации NIST SP 800-207 "Zero Trust Architecture"
Управление информационной безопасностью (ISO 27000)
Управление информационной безопасностью (ISO 27000)
Нормативные документы по ИБ. Часть 5. Обзор российского и международного законодательства в области защиты персональных данных
Нормативные документы по ИБ. Часть 5. Обзор российского и международного законодательства в области защиты персональных данных
Защита веб-приложений: WAF
Защита веб-приложений: WAF