Рекомендации по тестированию безопасности
Применяется к этой рекомендации по безопасности Azure Well-Architected Framework:
| SE:11 | Создайте комплексный режим тестирования, который объединяет подходы к предотвращению проблем безопасности, проверке реализаций предотвращения угроз и тестированию механизмов обнаружения угроз. |
|---|
Строгое тестирование является основой хорошей разработки безопасности. Тестирование является тактической формой проверки, чтобы убедиться, что элементы управления работают должным образом. Тестирование также является упреждающим способом обнаружения уязвимостей в системе.
Устанавливайте строгость тестирования с помощью каденции и проверки с нескольких перспектив. Необходимо включить внутри точки зрения, которые тестируют платформу и инфраструктуру и оценки вне системы, которые проверяют систему, как внешний злоумышленник.
В этом руководстве приведены рекомендации по тестированию состояния безопасности рабочей нагрузки. Реализуйте эти методы тестирования для повышения устойчивости рабочей нагрузки к атакам и поддержанию конфиденциальности, целостности и доступности ресурсов.
Определения
| Срок | Определение |
|---|---|
| Тестирование безопасности приложений (AST) | Метод жизненного цикла разработки безопасности Майкрософт (SDL), использующий методы тестирования "белый ящик" и "черный ящик" для проверки уязвимостей безопасности в коде. |
| Тестирование в черной коробке | Методология тестирования, которая проверяет поведение внешних видимых приложений без знания внутренних элементов системы. |
| Синяя команда | Команда, которая защищается от атак красной команды в военном упражнении. |
| тест на проникновение; | Методология тестирования, которая использует этические методы взлома для проверки защиты безопасности системы. |
| Красная команда | Команда, которая играет роль противника и пытается взломать систему в военном игровом упражнении. |
| Жизненный цикл разработки безопасного ПО (SDL) | Набор методик, предоставляемых корпорацией Майкрософт, которая поддерживает требования к обеспечению безопасности и соответствию требованиям. |
| Жизненный цикл разработки программного обеспечения (SDLC) | Многоэтапный, систематический процесс разработки программных систем. |
| Тестирование в белом поле | Методология тестирования, в которой структура кода известна практикующим. |
Основные стратегии проектирования
Тестирование — это неизменяемая стратегия, особенно для безопасности. Он позволяет заранее обнаруживать и устранять проблемы безопасности, прежде чем их можно использовать, и убедиться, что реализованные элементы управления безопасностью работают должным образом.
Область тестирования должна включать в себя приложения, инфраструктуру и автоматизированные и человеческие процессы.
Примечание.
Это руководство позволяет различать тестирование и реагирование на инциденты. Хотя тестирование является механизмом обнаружения, который в идеале устраняет проблемы до рабочей среды, его не следует путать с исправлением или расследованием, выполненным в рамках реагирования на инциденты. Аспект восстановления от инцидентов безопасности описан в рекомендациях по реагированию на инциденты.
SDL включает несколько типов тестов, которые перехватят уязвимости в коде, проверяют компоненты среды выполнения и используют этические взлома для проверки устойчивости системы безопасности. SDL — это действие влево с клавишами. Вы должны выполнять тесты, такие как статический анализ кода и автоматическое сканирование инфраструктуры в виде кода (IaC) как можно раньше в процессе разработки.
Участие в планировании тестов. Команда рабочей нагрузки может не разрабатывать тестовые варианты. Эта задача часто централизована в организации или выполняется внешними экспертами по безопасности. Команда рабочей нагрузки должна участвовать в этом процессе разработки, чтобы обеспечить интеграцию гарантий безопасности с функциональными возможностями приложения.
Подумайте, как злоумышленник. Создайте тестовые случаи с предположением, что система была атакована. Таким образом, можно выявить потенциальные уязвимости и определить приоритеты тестов соответствующим образом.
Выполните тесты структурированным образом и с повторяемым процессом. Создайте строгость тестирования вокруг каденции, типов тестов, факторов вождения и предполагаемых результатов.
Используйте подходящее средство для задания. Используйте средства, настроенные для работы с рабочей нагрузкой. Если у вас нет инструмента, приобретите его. Не создавайте его. Средства безопасности являются высоко специализированными, и создание собственного инструмента может привести к рискам. Воспользуйтесь опытом и инструментами, предлагаемыми центральными командами SecOps или внешними средствами, если у рабочей нагрузки нет этого опыта.
Настройте отдельные среды. Тесты можно классифицировать как разрушительные или недеструктивные. Недеструктивные тесты не являются инвазивными. Они указывают на проблему, но они не изменяют функциональные возможности, чтобы устранить проблему. Разрушительные тесты являются инвазивными и могут повредить функциональные возможности путем удаления данных из базы данных.
Тестирование в рабочих средах дает лучшую информацию, но вызывает наибольшее нарушение. Как правило, в рабочих средах выполняются недеструктивные тесты. Тестирование в непроизводственных средах обычно является менее разрушительным, но может не точно представлять конфигурацию рабочей среды способами, важными для безопасности.
При развертывании с помощью IaC и автоматизации рассмотрите возможность создания изолированного клона рабочей среды для тестирования. Если у вас есть непрерывный процесс для обычных тестов, рекомендуется использовать выделенную среду.
Всегда оценивать результаты теста. Тестирование является неотратратным усилием, если результаты не используются для определения приоритетов действий и улучшения вышестоящей версии. Задокументируйте рекомендации по безопасности, включая рекомендации, которые вы раскрываете. Документация, которая фиксирует результаты и планы исправления, обучает команду различными способами, которыми злоумышленники могут попытаться нарушить безопасность. Регулярное обучение безопасности для разработчиков, администраторов и тестировщиков.
При разработке планов тестирования думайте о следующих проблемах:
Как часто вы ожидаете, что тест будет выполняться, и как это влияет на вашу среду?
Каковы различные типы тестов, которые следует запустить?
Регулярное тестирование рабочей нагрузки
Регулярно тестируйте рабочую нагрузку, чтобы убедиться, что изменения не подвергаются рискам безопасности и что нет никаких регрессий. Команда также должна быть готова реагировать на проверки безопасности организации, которые могут выполняться в любое время. Существуют также тесты, которые можно выполнить в ответ на инцидент безопасности. В следующих разделах приведены рекомендации по частоте тестов.
Стандартные тесты
Стандартные тесты выполняются по регулярному курсу, в рамках стандартных операционных процедур и соответствия требованиям. Различные тесты могут выполняться по разным частотам, но ключ заключается в том, что они выполняются периодически и по расписанию.
Эти тесты следует интегрировать в SDLC, так как они обеспечивают защиту на каждом этапе. Разнообразьте набор тестов, чтобы проверить гарантии для удостоверений, хранения данных и передачи данных, а также каналов связи. Проводите одни и те же тесты в разных точках жизненного цикла, чтобы гарантировать, что нет никаких регрессий. Стандартные тесты помогают установить первоначальный тест. Однако это всего лишь отправная точка. При обнаружении новых проблем в тех же точках жизненного цикла вы добавляете новые тестовые случаи. Тесты также улучшаются с повторением.
На каждом этапе эти тесты должны проверить код, добавленный или удаленный или измененные параметры конфигурации, чтобы определить влияние этих изменений на безопасность. Вы должны улучшить эффективность тестов с автоматизацией, сбалансированной с одноранговых отзывов.
Рассмотрите возможность выполнения тестов безопасности в рамках автоматизированного конвейера или запланированного тестового запуска. Чем раньше вы обнаружите проблемы с безопасностью, тем проще найти код или изменение конфигурации, вызывающее их.
Не полагаться только на автоматизированные тесты. Используйте ручное тестирование для обнаружения уязвимостей, которые могут перехватывать только специалисты человека. Тестирование вручную подходит для изучения вариантов использования и поиска неизвестных рисков.
Импровизированные тесты
Импровизированные тесты обеспечивают проверку защиты безопасности на определенный момент времени. Оповещения системы безопасности, которые могут повлиять на рабочую нагрузку в то время, активируют эти тесты. Для проверки эффективности стратегий обороны, если оповещение перерастает в чрезвычайные ситуации, может потребоваться приостановленное и тестовое мышление.
Преимуществом импровизированных тестов является готовность к настоящему инциденту. Эти тесты могут быть принудительной функцией для выполнения проверки приемки пользователей (UAT).
Команда безопасности может проверять все рабочие нагрузки и выполнять эти тесты по мере необходимости. Как владелец рабочей нагрузки, необходимо упростить и сотрудничать с группами безопасности. Достаточно времени выполнения с командами безопасности, чтобы подготовиться. Подтвердите и сообщите вашей команде и заинтересованным лицам, что эти нарушения необходимы.
В других случаях может потребоваться выполнить тесты и сообщить о состоянии безопасности системы в отношении потенциальной угрозы.
Компромисс: поскольку импровизированные тесты являются разрушительными событиями, ожидают повтора задач, которые могут отложить другие запланированные работы.
Риск: существует риск неизвестного. Импровизированные тесты могут быть однократными усилиями без установленных процессов или инструментов. Но преобладающим риском является потенциальное прерывание ритма бизнеса. Необходимо оценить эти риски относительно преимуществ.
Тесты инцидентов безопасности
Существуют тесты, которые обнаруживают причину инцидента безопасности в источнике. Эти пробелы в безопасности необходимо устранить, чтобы убедиться, что инцидент не повторяется.
Инциденты также улучшают тестовые случаи с течением времени, обнаруживая существующие пробелы. Команда должна применить уроки, извлеченные из инцидента, и регулярно включать улучшения.
Использование различных тестов
Тесты можно классифицировать по технологиям и по методологиям тестирования. Объедините эти категории и подходы в этих категориях, чтобы получить полное покрытие.
Добавив несколько тестов и типов тестов, можно обнаружить следующее:
Пробелы в элементах управления безопасностью или компенсирующих элементах управления.
Неправильно настроены.
Пробелы в методах наблюдения и обнаружения.
Хорошее упражнение по моделированию угроз может указывать на ключевые области, чтобы обеспечить охват тестов и частоту. Рекомендации по моделированию угроз см . в рекомендациях по защите жизненного цикла разработки.
Большинство тестов, описанных в этих разделах, можно выполнять как обычные тесты. Однако повторяемость может привести к затратам в некоторых случаях и вызвать нарушение. Внимательно рассмотрим эти компромиссы.
Тесты, проверяющие стек технологий
Ниже приведены некоторые примеры типов тестов и их основной области. Этот список не является исчерпывающим. Протестируйте весь стек, включая стек приложений, интерфейсную часть, серверную часть, API, базы данных и любые внешние интеграции.
Безопасность данных. Проверьте эффективность шифрования данных и управления доступом, чтобы обеспечить правильную защиту данных от несанкционированного доступа и изменения.
Сеть и подключение. Проверьте брандмауэры, чтобы гарантировать, что они разрешают только ожидаемый, разрешенный и безопасный трафик к рабочей нагрузке.
Приложение: тестируйте исходный код с помощью методов тестирования безопасности приложений (AST), чтобы убедиться, что вы следуйте безопасным методикам написания кода и перехватываете ошибки среды выполнения, такие как повреждение памяти и проблемы с привилегиями. Дополнительные сведения см. в этих ссылках сообщества.
Удостоверение. Оцените, работают ли назначения ролей и условные проверки.
Методология тестирования
Существует много перспектив на методологии тестирования. Мы рекомендуем тесты, позволяющие охотиться на угрозы, имитируя реальные атаки. Они могут определять потенциальных субъектов угроз, их методы и их эксплойты, которые представляют угрозу для рабочей нагрузки. Сделать атаки как можно более реалистичными. Используйте все потенциальные векторы угроз, которые вы определяете во время моделирования угроз.
Ниже приведены некоторые преимущества тестирования с помощью реальных атак:
При выполнении этих атак в рамках обычного тестирования вы используете внешняя перспектива для проверки рабочей нагрузки и убедитесь, что защита может противостоять атаке.
На основе уроков, которые они узнали, команда обновляет свои знания и уровень навыков. Команда повышает осведомленность о ситуации и может самостоятельно оценивать готовность реагировать на инциденты.
Некоторые примеры имитированных тестов включают в себя черно-прямоугольные и белые тесты, тестирование на проникновение и военные игровые упражнения.
Тестирование в черной коробке и белом поле
Эти типы тестов предлагают две разные перспективы. В черных полях тесты внутренние элементы системы не видны. В тестах белого поля тестировщик хорошо понимает приложение и даже имеет доступ к коду, журналам, топологии ресурсов и конфигурациям для проведения эксперимента.
Тесты, имитирующие атаки с помощью тестирования на проникновение
Специалисты по безопасности, которые не входят в ИТ-отделы организации или группы приложений, проводят тестирование на проникновение или тестирование. Они смотрят на систему таким образом, чтобы вредоносные субъекты охватывали область атаки. Их цель — найти пробелы в безопасности, собирая информацию, анализируя уязвимости и сообщая результаты.
Специалистам может потребоваться доступ к конфиденциальным данным в всей организации. Следуйте правилам взаимодействия, чтобы убедиться, что доступ не используется неправильно. См. ресурсы, перечисленные в связанных ссылках.
Тесты, которые имитируют атаки с помощью военных игровых упражнений
В этой методологии имитации атак существует две команды:
Красная команда — это злоумышленник, пытающийся моделировать реальные атаки. Если они успешны, вы найдете пробелы в проектировании безопасности и оцените радиус взрыва их нарушений.
Синяя команда — это команда рабочей нагрузки, которая защищает от атак. Они проверяют их способность обнаруживать, реагировать и устранять атаки. Они проверяют защиту, реализованную для защиты ресурсов рабочей нагрузки.
Если они проводятся в качестве обычных испытаний, военные игровые упражнения могут обеспечить постоянную видимость и уверенность в том, что ваша защита работает как разработанная. Военные игры упражнения могут потенциально тестировать на разных уровнях в рабочих нагрузках.
Популярным выбором для имитации реалистичных сценариев атак является 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 описывают типы методик тестирования, которые могут тестировать защиту времени сборки и среды выполнения приложения.
Стандарт проведения тестов на проникновение (Penetration Testing Execution Standard, PTES) содержит рекомендации по распространенным сценариям и действиям, необходимым для определения базовых показателей.
OWASP Top Ten | OWASP Foundation предоставляет рекомендации по безопасности для приложений и тестовых случаев, охватывающих распространенные угрозы.
Контрольный список по безопасности
Ознакомьтесь с полным набором рекомендаций.