Команды безопасности, роли и функции

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

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

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

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

Преобразование ролей безопасности

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

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

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

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

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

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

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

• Теперь угрозы безопасности надежно обходят средства управления безопасностью на основе сети, поэтому группам безопасности необходимо применить подход к удостоверению, безопасности приложений, безопасности конечных точек, облачной безопасности, CI/CD, обучению пользователей и другим элементам управления.

• Внедрение процессов DevOps/DevSecOps требует, чтобы роли безопасности были более гибкими для интеграции безопасности изначально в результирующий жизненный цикл разработки решений.

Общие сведения о ролях и командах

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

Роли, выполняющие задачи безопасности, включают следующие роли.

• Поставщик облачных услуг

• Команды инфраструктуры и платформы (архитектура, проектирование и операции)

• Архитектура безопасности, инженерия и группы управления состоянием:

  • Архитекторы и инженеры безопасности (безопасность данных, управление удостоверениями и доступом (IAM), сетевая безопасность, серверы и безопасность контейнеров, безопасность приложений и DevSecOps)

  • Инженеры по безопасности программного обеспечения (безопасность приложений)

  • Управление состоянием (управление уязвимостями / управление поверхностью атаки)

• Операции безопасности (SecOps/SOC):

  • Аналитики триажа (уровень 1)

  • Аналитики исследования (уровень 2)

  • Поиск угроз

  • Аналитика угроз

  • Проектирование обнаружения

• Управление безопасностью, риск и соответствие требованиям (GRC)

• Обучение безопасности и осведомленность

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

Поставщик облачных услуг

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

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

Команды инфраструктуры и платформы (архитектура, проектирование и операции)

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

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

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

Архитектура безопасности, инженерия и группы управления состоянием

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

• Архитекторы безопасности и инженеры адаптируют политики безопасности, стандарты и рекомендации по облачным средам для разработки и реализации элементов управления в партнерстве с их коллегами инфраструктуры и платформы. Архитекторы и инженеры по безопасности помогают с широким спектром элементов, в том числе:

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

  • IAM. Архитекторы доступа (удостоверения, сети, приложения и другие) сотрудничают с инженерами и специалистами по управлению удостоверениями и инфраструктурой и платформой для разработки, реализации и управления доступом решений. Эти решения защищают от несанкционированного использования бизнес-ресурсов организации, позволяя авторизованным пользователям следовать бизнес-процессам, чтобы легко и безопасно получать доступ к ресурсам организации. Эти команды работают над решениями, такими как каталоги удостоверений и решения единого входа ,без пароля и многофакторная проверка подлинности (MFA), решения условного доступа на основе рисков, удостоверения рабочей нагрузки, управление привилегированными удостоверениями и доступом (PIM/PAM), облачной инфраструктурой и управлением правами (CIEM) и многое другое. Эти команды также сотрудничают с сетевыми инженерами и операциями для разработки, реализации и эксплуатации решений пограничных служб безопасности (SSE). Команды рабочей нагрузки могут воспользоваться этими возможностями, чтобы обеспечить простой и более безопасный доступ к отдельным компонентам рабочей нагрузки и приложению.

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

  • Безопасность сети. Архитекторы и инженеры безопасности сотрудничают с сетевыми архитекторами и инженерами , чтобы помочь командам инфраструктуры и платформы создать базовые возможности сетевой безопасности, такие как подключение к облаку (частные или арендованные линии), стратегии удаленного доступа и решения, входящий трафик и исходящие брандмауэры , брандмауэры веб-приложений (WAFs) и сегментация сети. Эти команды также сотрудничают с архитекторами удостоверений, инженерами и операциями для проектирования, реализации и эксплуатации решений SSE. Команды рабочей нагрузки могут воспользоваться этими возможностями, чтобы обеспечить дискретную защиту или изоляцию отдельных рабочих нагрузок и компонентов приложений.

  • Серверы и безопасность контейнеров. Архитекторы и инженеры безопасности сотрудничают с архитекторами и инженерами инфраструктуры, чтобы помочь командам инфраструктуры и платформы создать базовые возможности безопасности для серверов, виртуальных машин (виртуальных машин), контейнеров, оркестрации и управления, CI/CD и связанных систем. Эти команды устанавливают процессы обнаружения и инвентаризации, базовые и эталонные конфигурации безопасности, процессы обслуживания и исправления, список разрешений для исполняемых двоичных файлов, образов шаблонов, процессов управления и т. д. Команды рабочей нагрузки также могут воспользоваться этими базовыми возможностями инфраструктуры, чтобы обеспечить безопасность серверов и контейнеров для отдельных компонентов рабочей нагрузки и приложений.

  • Основы безопасности программного обеспечения (для безопасности приложений и DevSecOps). Архитекторы и инженеры безопасности сотрудничают с инженерами по обеспечению безопасности программного обеспечения, помогая командам инфраструктуры и платформы создавать возможности безопасности приложений, которые могут использоваться отдельными рабочими нагрузками, сканированием кода, средствами программного обеспечения (SBOM), WAFs и сканированием приложений. Дополнительные сведения о создании жизненного цикла разработки безопасности (SDL) см . в элементах управления DevSecOps. Дополнительные сведения о том, как команды рабочей нагрузки используют эти возможности, см . в руководстве по жизненному циклу разработки безопасности в хорошо спроектированной платформе.

• Инженеры по обеспечению безопасности программного обеспечения оценивают код, скрипты и другую автоматизированную логику, которая используется для управления инфраструктурой, включая инфраструктуру как код (IaC), рабочие процессы CI/CD и любые другие пользовательские средства или приложения. Эти инженеры должны быть вовлечены в защиту формального кода в скомпилированных приложениях, сценариях, конфигурациях платформ автоматизации и любой другой форме исполняемого кода или скрипта, которые могут позволить злоумышленникам управлять операцией системы. Эта оценка может влечь за собой простое выполнение анализа модели угроз системы или может включать средства проверки кода и проверки безопасности. Дополнительные сведения о создании SDL см. в руководстве по использованию SDL.

• Управление состоянием (управление уязвимостями / управление поверхностью атак) — это операционная группа безопасности, которая посвящена включению безопасности для технических рабочих групп. Управление состоянием помогает этим командам определять приоритеты и реализовывать элементы управления для блокировки или устранения рисков атак. Команды по управлению постом работают во всех рабочих группах технических операций (включая облачные команды) и часто служат основным средством понимания требований безопасности, требований к соответствию требованиям и процессам управления.

  Управление состоянием часто служит центром превосходства (CoE) для групп инфраструктуры безопасности, аналогично тому, как инженеры программного обеспечения часто служат в качестве центра безопасности для команд разработчиков приложений. Типичные задачи для этих команд включают следующие.

  • Отслеживайте состояние безопасности. Отслеживайте все технические системы с помощью таких средств управления состоянием, как управление безопасностью Майкрософт, Управление разрешениями Microsoft Entra, уязвимость, отличные от Майкрософт, а также средства управления внешними атаками (EASM) и средства CIEM, а также пользовательские средства защиты и панели мониторинга. Кроме того, управление состоянием выполняет анализ для предоставления аналитических сведений:

    • Прогнозирование весьма вероятных и разрушительных путей атаки. Злоумышленники "думают в графах" и ищут пути к критически важным для бизнеса системам путем объединения нескольких ресурсов и уязвимостей в разных системах (например, компрометации конечных точек пользователей, а затем использовать хэш/билет для записи учетных данных администратора, а затем получить доступ к критически важным для бизнеса данным). Группы управления по вопросам безопасности работают с архитекторами безопасности и инженерами, чтобы обнаружить и устранить эти скрытые риски, которые не всегда отображаются в технических списках и отчетах.

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

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

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

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

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

  • Предоставьте отчеты. Предоставление своевременных и точных отчетов об инцидентах безопасности, тенденциях и метрик производительности старшим руководителям и заинтересованным лицам для обновления процессов риска организации.

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

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

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

    • Потерянные объекты, разрешающие несанкционированный доступ к таким элементам, как записи DNS и членство в группах.

    • Чрезмерные административные роли или разрешения на ресурсы.

    • Использование более слабого протокола проверки подлинности или криптографического алгоритма, имеющего известные проблемы с безопасностью.

    • Слабые конфигурации по умолчанию или пароли по умолчанию.

  • Операционные уязвимости являются слабыми местами в стандартных операционных процессах и методиках, которые позволяют несанкционированным доступом или контролем систем. Вот некоторые примеры.

    • Администраторы используют общие учетные записи вместо собственных отдельных учетных записей для выполнения привилегированных задач.

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

Операции безопасности (SecOps/SOC)

Команда SecOps иногда называется Центром управления безопасностью (SOC). Команда SecOps сосредоточена на быстром поиске и удалении злоумышленника доступа к ресурсам организации. Они работают в тесном партнерстве с технологическими операциями и инженерными командами. Роли SecOps могут работать во всех технологиях организации, включая традиционные ИТ-технологии, операционные технологии (OT) и Интернет вещей (IoT). Ниже приведены роли SecOps, которые чаще всего взаимодействуют с облачными командами:

• Аналитики триаджа (уровень 1). Реагирует на обнаружение инцидентов для известных методов атак и следует документированные процедуры, чтобы быстро устранить их (или повысить их до аналитиков расследования в соответствии с соответствующим образом). В зависимости от области и зрелости SecOps это может включать обнаружения и оповещения от электронной почты, решений защиты от вредоносных программ конечных точек, облачных служб, обнаружения сети или других технических систем.

• Аналитики исследования (уровень 2). Отвечает на более сложные и более сложные расследования инцидентов с более высоким уровнем серьезности, которые требуют больше опыта и опыта (помимо хорошо документированных процедур разрешения). Эта команда обычно расследует атаки, которые ведутся живыми злоумышленниками и нападениями, влияющими на несколько систем. Он работает в тесном партнерстве с технологическими операциями и инженерными командами для расследования инцидентов и их устранения.

• Поиск угроз. Упреждающее поиск скрытых угроз в техническом пространстве, которые избегали стандартных механизмов обнаружения. Эта роль использует расширенную аналитику и исследования на основе гипотез.

• Threat Intelligence. Собирает и распространяет информацию о злоумышленниках и угрозах всем заинтересованным лицам, включая бизнес, технологию и безопасность. Группы аналитики угроз выполняют исследования, делятся своими результатами (официально или неофициально) и распространяют их различным заинтересованным лицам, включая команду облачной безопасности. Этот контекст безопасности помогает этим командам сделать облачные службы более устойчивыми к атакам, так как они используют информацию о реальных атаках в разработке, реализации, тестировании и операциях, а также непрерывном улучшении.

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

Управление безопасностью, риск и соответствие требованиям

Управление безопасностью, риск и соответствие требованиям (GRC) — это набор взаимосвязанных дисциплин, которые интегрируют техническую работу групп безопасности с целями и ожиданиями организации. Эти роли и команды могут быть гибридной из двух или более дисциплин или могут быть дискретными ролями. Облачные команды взаимодействуют с каждой из этих дисциплин в течение жизненного цикла облачных технологий:

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

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

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

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

Команды по проектированию облачных технологий и эксплуатации могут работать с ролями управления постами, группами соответствия требованиям и аудитом , архитектурой безопасности и инженерией, а также с ролью главного сотрудника по информационной безопасности (CISO) в разделах GRC.

Образование и политика безопасности

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

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

Образование и политика безопасности должны помочь каждой роли понять:

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

• Что. Сводные сведения о задачах безопасности, которые они должны выполнять на языке, который они уже понимают. Если люди не знают, что они просят сделать, они будут полагать, что безопасность не важна или актуальна для них, и перейти к чему-то другому.

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

Пример сценария: типичное взаимодействие между командами

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

1. Планирование и проектирование
   1. Команда управления определяет необходимость повышения безопасности веб-приложений и выделяет бюджет для WAF.
   2. Архитектор сетевой безопасности разрабатывает стратегию развертывания WAF, гарантируя, что она легко интегрируется с существующими элементами управления безопасностью и соответствует архитектуре безопасности организации.
2. Реализация
   1. Инженер безопасности сети развертывает WAF в соответствии с проектом архитектора, настраивая его для защиты конкретных веб-приложений и обеспечивает мониторинг.
   2. Инженер IAM настраивает элементы управления доступом, гарантируя, что только авторизованный персонал может управлять WAF.
3. Мониторинг и управление
   1. Команда по управлению состоянием предоставляет инструкции для SOC по настройке мониторинга и оповещений для WAF и настройке панелей мониторинга для отслеживания действий WAF.
   2. Группы разработчиков аналитики угроз и обнаружения угроз помогают разработать планы реагирования на инциденты, которые включают WAF и проводить имитации для тестирования этих планов.
4. Управление соответствием требованиям и рисками
   1. Сотрудник по управлению соответствием и рискам проверяет развертывание WAF, чтобы обеспечить соответствие нормативным требованиям и проводить периодические аудиты.
   2. Инженер по безопасности данных гарантирует, что меры ведения журнала и защиты данных WAF соответствуют нормативным требованиям о конфиденциальности данных.
5. Непрерывное улучшение и обучение
   1. Инженер DevSecOps интегрирует управление WAF в конвейер CI/CD, обеспечивая автоматическое и согласованное выполнение обновлений и конфигураций.
   2. Специалист по вопросам безопасности и участия разрабатывает и предоставляет учебные программы, чтобы все соответствующие сотрудники понимали, как эффективно использовать WAF и управлять ими.
   3. Член группы управления облаком проверяет процессы развертывания и управления WAF, чтобы убедиться, что они соответствуют политикам и стандартам организации.

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

Следующий шаг