Рекомендации по анализу угроз
Применяется к этой рекомендации по безопасности Azure Well-Architected Framework:
| SE:02 | Создайте базовые показатели безопасности, соответствующие требованиям к соответствию, отраслевым стандартам и рекомендациям по платформе. Регулярно измеряйте архитектуру и операции рабочей нагрузки по базовым показателям, чтобы поддерживать или улучшать состояние безопасности с течением времени. |
|---|
Связанное руководство. Рекомендации по обеспечению безопасности жизненного цикла разработки
Комплексный анализ для выявления угроз, атак, уязвимостей и мер противодействия имеет решающее значение на этапе проектирования рабочей нагрузки. Моделирование угроз — это инженерное упражнение, включающее определение требований к безопасности, выявление и устранение угроз, а также проверку этих мер. Этот метод можно использовать на любом этапе разработки приложения или в рабочей среде, но он наиболее эффективен на этапах разработки новых функциональных возможностей.
В этом руководстве описываются рекомендации по моделированию угроз, чтобы вы могли быстро выявлять пробелы в безопасности и разрабатывать средства защиты.
Определения
| Термин | Определение |
|---|---|
| Жизненный цикл разработки программного обеспечения (SDLC) | Многоэтапный систематический процесс разработки программных систем. |
| STRIDE | Таксономия, определяемая корпорацией Майкрософт, для классификации типов угроз. |
| Моделирование угроз | Процесс выявления потенциальных уязвимостей системы безопасности в приложении и системе, снижения рисков и проверки элементов управления безопасностью. |
Ключевые стратегии проектирования
Моделирование угроз — это важный процесс, который организация должна интегрировать в свою SDLC. Моделирование угроз не является исключительно задачей разработчика. Это общая ответственность между:
- Группа рабочей нагрузки, которая отвечает за технические аспекты системы.
- Заинтересованные лица, которые понимают бизнес-результаты и заинтересованы в безопасности.
Между руководством организации и техническими командами часто возникают разночтения в отношении бизнес-требований для критически важных рабочих нагрузок. Это отключение может привести к нежелательным результатам, особенно для инвестиций в безопасность.
Когда команда рабочей нагрузки выполняет упражнение по моделированию угроз, она должна учитывать как бизнес-, так и технические требования. Команда рабочей нагрузки и заинтересованные лица бизнеса должны договориться о потребностях рабочей нагрузки в области безопасности, чтобы они могли сделать адекватные инвестиции в контрмеры.
Требования к безопасности служат руководством для всего процесса моделирования угроз. Чтобы сделать это эффективным упражнением, команда рабочей нагрузки должна иметь установку на безопасность и пройти обучение средствам моделирования угроз.
Общие сведения о область упражнения
Четкое понимание область имеет решающее значение для эффективного моделирования угроз. Это помогает сосредоточить усилия и ресурсы на наиболее важных областях. Эта стратегия включает определение границ системы, инвентаризацию активов, которые необходимо защитить, и понимание уровня инвестиций, необходимых для средств контроля безопасности.
Сбор сведений о каждом компоненте
Схема архитектуры рабочей нагрузки является отправной точкой для сбора информации, так как она предоставляет визуальное представление системы. На схеме выделены технические аспекты системы. Например, здесь показаны потоки пользователей, перемещение данных по сети, уровни конфиденциальности данных и типы информации, а также пути доступа к удостоверениям.
Этот подробный анализ часто позволяет получить представление о потенциальных уязвимостях в проекте. Важно понимать функциональные возможности каждого компонента и его зависимости.
Оценка потенциальных угроз
Анализ каждого компонента с внешней точки зрения. Например, как легко злоумышленник может получить доступ к конфиденциальным данным? Если злоумышленники получают доступ к среде, могут ли они перемещаться в боковом плане и потенциально получать доступ к другим ресурсам или даже управлять ими? Эти вопросы помогут понять, как злоумышленник может использовать ресурсы рабочей нагрузки.
Классификация угроз с помощью отраслевой методологии
Одной из методологий классификации угроз является STRIDE, которая используется в жизненном цикле разработки безопасности Майкрософт. Классификация угроз помогает понять характер каждой угрозы и использовать соответствующие средства управления безопасностью.
Устранение угроз
Задокументируйте все обнаруженные угрозы. Для каждой угрозы определите элементы управления безопасностью и ответ на атаку в случае сбоя этих элементов управления. Определите процесс и временная шкала, которые сводят к минимуму уязвимость к любым обнаруженным уязвимостям в рабочей нагрузке, чтобы эти уязвимости не могли оставаться без устранения.
Используйте подход предполагать нарушение. Он может помочь определить элементы управления, необходимые в проекте, чтобы снизить риск в случае сбоя основного элемента управления безопасностью. Оцените вероятность сбоя основного элемента управления. Если он завершается сбоем, какова степень потенциального риска организации? Кроме того, какова эффективность компенсирующего контроля? На основе оценки примените меры глубокой защиты для устранения потенциальных сбоев средств управления безопасностью.
Приведем пример:
| Задайте этот вопрос | Чтобы определить элементы управления, которые... |
|---|---|
| Проходят ли подключения проверку подлинности с помощью Microsoft Entra ID, протокола TLS с взаимной проверкой подлинности или другого современного протокола безопасности, утвержденного группой безопасности: — Между пользователями и приложением? — Между компонентами и службами приложения? |
Предотвращение несанкционированного доступа к компонентам и данным приложения. |
| Вы ограничиваете доступ только учетными записями, которым нужно записывать или изменять данные в приложении? | Предотвращают несанкционированное изменение данных. |
| Регистрируется ли действие приложения и подается ли в систему управления информационной безопасностью и событиями безопасности (SIEM) с помощью Azure Monitor или аналогичного решения? | Быстро выявляют и исследуют атаки. |
| Защищены ли критически важные данные с помощью шифрования, утвержденного командой безопасности? | Предотвращают несанкционированное копирование неактивных данных. |
| Шифруется ли входящий и исходящий сетевой трафик по протоколу TLS? | Предотвращают несанкционированное копирование передаваемых данных. |
| Защищено ли приложение от распределенных атак типа "отказ в обслуживании" (DDoS) с помощью таких служб, как Защита от атак DDoS Azure? | Обеспечивают защиту от атак, направленных на перегрузку приложения, чтобы его нельзя было использовать. |
| Хранит ли приложение учетные данные или ключи входа для доступа к другим приложениям, базам данных или службам? | Определяют, может ли атака использовать ваше приложение для атаки на другие системы. |
| Позволяют ли элементы управления приложениями выполнять нормативные требования? | Защита личных данных пользователей и предотвращение штрафов за соответствие требованиям. |
Отслеживание результатов моделирования угроз
Настоятельно рекомендуется использовать средство моделирования угроз. Средства могут автоматизировать процесс выявления угроз и создавать полный отчет обо всех выявленных угрозах. Не забудьте сообщить результаты всем заинтересованным командам.
Отслеживайте результаты в рамках невыполненной работы группы рабочей нагрузки, чтобы обеспечить своевременную подотчетность. Назначьте задачи отдельным лицам, которые отвечают за устранение определенного риска, обнаруженного моделированием угроз.
По мере добавления новых функций в решение обновите модель угроз и интегрируйте ее в процесс управления кодом. Если вы обнаружили проблему безопасности, убедитесь, что существует процесс для рассмотрения проблемы на основе серьезности. Этот процесс должен помочь определить, когда и как устранить проблему (например, в следующем цикле выпуска или в более быстром выпуске).
Регулярно проверяйте требования к критически важным для бизнеса рабочим нагрузкам
Регулярно встречаться с исполнительными спонсорами, чтобы определить требования. Эти обзоры дают возможность согласовать ожидания и обеспечить выделение оперативных ресурсов для инициативы.
Упрощение azure
Жизненный цикл разработки безопасности (Майкрософт) предоставляет средство моделирования угроз, помогая в процессе моделирования угроз. Этот инструмент предоставляется бесплатно. Дополнительные сведения см. на странице Моделирование угроз.
Пример
В этом примере используется среда информационных технологий (ИТ), созданная в базовом плане безопасности (SE:01). Этот подход обеспечивает широкое понимание ландшафта угроз в разных ИТ-сценариях.
Пользователи жизненного цикла разработки. В жизненном цикле разработки участвует множество пользователей, включая разработчиков, тестировщиков, конечных пользователей и администраторов. Все они могут быть скомпрометированы и поставить вашу среду под угрозу из-за уязвимостей или угроз, созданных намеренно.
Потенциальные злоумышленники. Злоумышленники рассматривают широкий спектр средств, которые можно легко использовать в любое время для изучения уязвимостей и начала атаки.
Элементы управления безопасностью. В рамках анализа угроз определите службы безопасности Azure, которые будут использоваться для защиты вашего решения, и насколько эффективны эти решения.
Сбор журналов. Журналы из ресурсов Azure и некоторых локальных компонентов могут отправляться в Azure Log Analytics, чтобы вы могли понять поведение разработанного решения и попытаться зафиксировать первоначальные уязвимости.
Решение для управления информационной безопасностью (SIEM). Microsoft Sentinel можно добавить даже на ранней стадии решения, чтобы вы могли создавать аналитические запросы для устранения угроз и уязвимостей, предвосхищая среду безопасности, когда вы находитесь в рабочей среде.
Microsoft Defender для облака может предоставлять некоторые рекомендации по обеспечению безопасности для повышения уровня безопасности.
Связанные ссылки
Ссылки на сообщество
Организация Open Web Application Security Project (OWASP) задокументировала подход к моделированию угроз для приложений.
Контрольный список по безопасности
Ознакомьтесь с полным набором рекомендаций.
Обратная связь
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
Отправить и просмотреть отзыв по