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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Образование, осведомленность и политика безопасности

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

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

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

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

Минимальная жизнеспособная группа безопасности для небольших организаций

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

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

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

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, чтобы убедиться, что они соответствуют политикам и стандартам организации.

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

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