Стратегии архитектуры для тестирования безопасности

Применяется к этой рекомендации по контрольным спискам безопасности Azure Well-Architected Framework:

Строгое тестирование является основой хорошей разработки безопасности. Тестирование также является упреждающим способом обнаружения уязвимостей в системе.

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

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

Терминология

Совместная работа с экспертами по безопасности для разработки тестов

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

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

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

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

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

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

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

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

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

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

Воспользуйтесь преимуществами сторонних специалистов

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

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

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

Проверка элементов управления соответствием и создание готовых к аудиту доказательств

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

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

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

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

Защита тестовых ресурсов

Тестовые ресурсы сами по себе являются поверхностью атаки. Защищайте их конфиденциальность, целостность и доступность, чтобы ваше тестирование не раскрывало конфиденциальную информацию и не открывало новые векторы атак.

• Используйте санизированные или синтетические данные, которые не содержат персональных данных (PII) или рабочих данных.
• Сохраняйте тестовые данные только до тех пор, пока это необходимо, и удалите их безопасно.
• Убедитесь, что в тестовых средах, охватывающих несколько регионов, соблюдаются трансграничные правила хранения данных.
• Создайте отдельные тестовые учетные данные, ключи API и сертификаты. Храните их в отдельном экземпляре хранилища ключей с собственными политиками доступа.
• Настройте изолированные тестовые среды, которые отражают рабочие элементы управления безопасностью, такие как группы безопасности сети (NSG), политики управления доступом на основе ролей (RBAC), брандмауэр и правила защиты от потери данных (DLP). Используйте те же правила сегментации, что и в продакшене. Дополнительные сведения см. в рекомендациях по стратегии сегментации.

Регулярное сканирование уязвимостей на тестовых ресурсах

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

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

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

Стандартные тесты

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

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

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

Импровизированные тесты

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

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

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

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

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

Риск: Существует риск неизвестности. Импровизированные тесты могут быть однократными усилиями без установленных процессов или инструментов. Но преобладающим риском является потенциальное прерывание ритма бизнеса. Оцените эти риски относительно преимуществ.

Тесты инцидентов безопасности

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

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

Проверьте меры безопасности по всей поверхности атаки

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

Проверка элементов управления шифрованием. Сбои шифрования происходят незаметно. Данные кажутся защищёнными, пока нарушение безопасности не покажет обратное.

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

Тестирование сетевых элементов управления. Границы сети находятся в том месте, где применяется сегментация.

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

Тестируйте код приложения. Защита уровня приложений — это последняя граница перед тем, как злоумышленник достигнет данных.

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

Смоделируйте атаки с использованием учетных данных и проверьте их обнаружение

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

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

При разработке тестов следует учитывать следующие шаблоны атак:

• Обход авторизации
• Кража токенов и их повторное использование
• Боковое перемещение между учетными записями или службами
• Повышение привилегий

Проверьте обе стороны каждого элемента управления:

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

Тестирование обнаружения угроз и оповещения

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

Выполните сквозное моделирование атак, а затем подтвердите каждый этап конвейера обнаружения:

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

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

Усильте защиту с помощью тестирования, имитирующего действия злоумышленников

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

Ниже приведены некоторые преимущества тестирования с помощью реальных атак:

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

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

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

Тестирование черного ящика и белого ящика

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

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

Тесты, имитирующие атаки с помощью тестирования на проникновение

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

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

Риск. Упражнение по выполнению проверки может повлиять на среду выполнения и может нарушить доступность для обычного трафика.

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

Тесты, которые имитируют атаки с помощью военных игровых упражнений

В этой методологии имитации атак две команды участвуют:

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

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

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

Популярный выбор для имитации реалистичных сценариев атак — это обучение по имитации атак в Microsoft Defender для Office 365.

Дополнительные сведения см. в статье "Аналитика" и отчеты для обучения имитации атак.

Сведения о настройке red-team и blue-team см. в разделе Microsoft Cloud Red Teaming.

Упрощение функций Azure

Microsoft Sentinel — это встроенное средство, которое объединяет возможности управления событиями безопасности (SIEM) и автоматизации реагирования на угрозы (SOAR). Он анализирует события и журналы из различных подключенных источников. На основе источников данных и их оповещений Microsoft Sentinel создает инциденты и выполняет анализ угроз для раннего обнаружения. Благодаря интеллектуальной аналитике и запросам вы можете активно искать проблемы безопасности. При возникновении инцидента можно автоматизировать рабочие процессы. Кроме того, с помощью шаблонов рабочих книг можно быстро получать ценную информацию благодаря визуализации.

Документацию продукта см. в разделе "Возможности охоты" Microsoft Sentinel.

Microsoft Defender для облака предлагает сканирование уязвимостей для различных технологических областей. Дополнительные сведения см. в статье "Включение сканирования уязвимостей с помощью службы "Управление уязвимостями Microsoft Defender" — Microsoft Defender для облака.

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

Azure DevOps поддерживает сторонние средства, которые можно автоматизировать в рамках конвейеров непрерывной интеграции и непрерывного развертывания. Дополнительные сведения см. в статье "Включить DevSecOps" с помощью Azure и GitHub — Azure DevOps.

Связанные ссылки

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

• Правила проведения тестирования на проникновение

• Выполнение тестов на проникновение

Вы можете имитировать атаки типа "отказ в обслуживании" в Azure. Обязательно следуйте политикам, описанным в тестировании имитации защиты от атак DDoS Azure.

Ссылки на ресурсы сообщества

Тестирование безопасности приложений: средства, типы и рекомендации . Ресурсы GitHub описывают типы методик тестирования, которые могут тестировать защиту времени сборки и среды выполнения приложения.

Стандарт выполнения тестирования на проникновение (PTES) предоставляет рекомендации по общим сценариям и действиям, необходимым для установления базовых показателей.

OWASP Top Ten | OWASP Foundation предоставляет рекомендации по безопасности для приложений и тестовых случаев, охватывающих распространенные угрозы.

Контрольный список безопасности

Ознакомьтесь с полным набором рекомендаций.