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

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

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

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

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

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

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

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

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

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

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

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

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

• Теперь угрозы безопасности надежно обходят сетевые средства управления безопасностью, поэтому командам безопасности необходимо применять подход Zero Trust, включающий идентификацию, безопасность приложений, защиту конечных точек, облачную безопасность, 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 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.

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

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

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

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

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

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

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

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

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

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