Рекомендации по тестированию безопасности
Применяется к следующей рекомендации по контрольному списку Well-Architected Security в Power Platform:
| SE:09 | Создайте комплексный режим тестирования, который сочетает в себе методы предотвращения проблем безопасности, проверки реализаций предотвращения угроз и тестирования механизмов обнаружения угроз. |
|---|
Тщательное тестирование является основой хорошего проектирования безопасности. Тестирование — это тактическая форма проверки, позволяющая убедиться, что механизмы контроля работают должным образом. Тестирование также является упреждающим способом обнаружения уязвимостей в системе.
Установите строгость тестирования посредством каденции и проверки с разных точек зрения. Вы должны включить точки зрения «изнутри наружу», которые проверяют платформу и инфраструктуру, и оценки «извне внутрь», которые проверяют систему как внешний злоумышленник.
В этом руководстве представлены рекомендации по тестированию состояния безопасности вашей рабочей нагрузки. Внедрите эти методы тестирования, чтобы повысить устойчивость вашей рабочей нагрузки к атакам и обеспечить конфиденциальность, целостность и доступность ресурсов.
Определения
| Термин | Определение |
|---|---|
| Тестирование безопасности приложений (AST) | Метод жизненного цикла разработки безопасности Microsoft (SDL), который использует методологии тестирования белого и черного ящика для проверки уязвимостей безопасности в коде. |
| Тестирование «черного ящика» | Методика тестирования, которая проверяет видимое извне поведение приложения без знания внутреннего устройства системы. |
| Синяя рабочая группа | Рабочая группа, которая защищается от атак красной команды в ходе военных учений. |
| Тест на проникновение | Методика тестирования, использующая методы этического взлома для проверки защиты системы. |
| Красная рабочая группа | Рабочая группа, которая играет роль противника и пытается взломать систему в ходе военных учений. |
| Жизненный цикл разработки безопасности (SDL) | Набор предоставленных Microsoft правил, поддерживающих требования безопасности и соответствия требованиям. |
| Жизненный цикл разработки программного обеспечения (SDLC) | Многоэтапный систематический процесс разработки программных систем. |
| Тестирование «белого ящика» | Методика тестирования, при которой структура кода известна практикующему специалисту. |
Ключевые стратегии проектирования
Тестирование — это непреложная стратегия, особенно в сфере безопасности. Это позволяет вам заранее обнаруживать и устранять проблемы безопасности до того, как они могут быть использованы, а также проверять, что реализованные вами меры безопасности функционируют должным образом.
Объем тестирования должен включать приложение, инфраструктуру, а также автоматизированные и выполняемые человеком процессы.
Заметка
В этом руководстве проводится различие между тестированием и реагированием на инциденты. Хотя тестирование — это механизм обнаружения, который в идеале устраняет проблемы до начала эксплуатации, его не следует путать с исправлением или расследованием, выполняемым в рамках реагирования на инциденты. Аспект восстановления после инцидентов безопасности описан в рекомендациях по реагированию на инциденты безопасности.
Участвуйте в планировании тестирования. Группа рабочей нагрузки может не разработать тестовые примеры. Эта задача часто централизована на предприятии или выполняется внешними экспертами по безопасности. Группа рабочей нагрузки должна участвовать в этом процессе проектирования, чтобы обеспечить интеграцию гарантий безопасности с функциональностью приложения.
Думайте как злоумышленник. Разрабатывайте тестовые сценарии, исходя из предположения, что система подверглась атаке. Таким образом, вы сможете обнаружить потенциальные уязвимости и соответствующим образом расставить приоритеты тестов.
Проводите тесты структурированным образом и с повторяемым процессом. Стройте строгость тестирования с учетом частоты выполнения тестов, типов тестов, движущих факторов и предполагаемых результатов.
Используйте правильный инструмент для работы. Используйте инструменты, настроенные для работы с рабочей нагрузкой. Если у вас нет инструмента, купите его. Не создавайте его. Инструменты безопасности узкоспециализированы, и создание собственного инструмента может привести к рискам. Воспользуйтесь преимуществами опыта и инструментов, предлагаемых центральными группами безопасности или внешними средствами, если у группы рабочей нагрузки нет такого опыта.
Настройте отдельные среды. Испытания можно разделить на разрушающие и неразрушающие. Неразрушающие испытания не являются инвазивными. Они указывают на наличие проблемы, но не изменяют функциональность для ее устранения. Разрушающие тесты являются инвазивными и могут повредить функциональность, удалив данные из базы данных.
Тестирование в производственных средах дает вам лучшую информацию, но вызывает больше всего сбоев. В производственных средах вы склонны проводить только неразрушающие испытания. Тестирование в непроизводственных средах обычно менее разрушительно, но может неточно отражать конфигурацию производственной среды способами, важными для безопасности.
Вы можете создать изолированный клон вашей производственной среды, используя функцию копирования среды. Если у вас настроены конвейеры развертывания, вы также можете развернуть свои решения в выделенной среде тестирования.
Всегда оценивайте результаты теста. Тестирование — это напрасная трата усилий, если результаты не используются для определения приоритетов действий и внесения улучшений в исходную версию. Задокументируйте обнаруженные вами рекомендации по безопасности, включая лучшие практики. Документация, фиксирующая результаты и планы исправления, знакомит команду с различными способами, которыми злоумышленники могут попытаться нарушить безопасность. Проводите регулярное обучение безопасности для разработчиков, администраторов и тестировщиков.
При разработке планов тестирования подумайте над следующими вопросами:
- Как часто вы ожидаете запуска теста и как это повлияет на вашу среду?
- Какие различные типы тестов вам следует запускать?
Как часто вы ожидаете, что тесты будут запускаться?
Регулярно тестируйте рабочую нагрузку, чтобы убедиться, что изменения не создают угрозы безопасности и не происходит регрессий. Команда также должна быть готова реагировать на проверки безопасности организации, которые могут проводиться в любое время. Существуют также тесты, которые можно запустить в ответ на инцидент безопасности. В следующих разделах представлены рекомендации по частоте тестов.
Плановые тесты
Плановые тесты проводятся регулярно, как часть стандартных рабочих процедур и для соответствия требованиям соответствия. Различные тесты могут проводиться с разной частотой, но главное, чтобы они проводились периодически и по расписанию.
Вам следует интегрировать эти тесты в свой SDLC, поскольку они обеспечивают глубокую защиту на каждом этапе. Разнообразьте набор тестов, чтобы проверить гарантии идентификации, хранения и передачи данных, а также каналов связи. Проведите одни и те же тесты на разных этапах жизненного цикла, чтобы убедиться в отсутствии регрессий. Регулярные тесты помогают установить первоначальный ориентир. Однако это только отправная точка. По мере обнаружения новых проблем на тех же этапах жизненного цикла вы добавляете новые тестовые случаи. Тесты также улучшаются при повторении.
На каждом этапе эти тесты должны проверять добавленный или удаленный код или измененные параметры конфигурации, чтобы обнаружить влияние этих изменений на безопасность. Вам следует повысить эффективность тестов с помощью автоматизации, сбалансированной экспертными оценками.
Рассмотрите возможность запуска тестов безопасности в рамках автоматизированного конвейера или запланированного тестового запуска. Чем раньше вы обнаружите проблемы безопасности, тем легче будет найти вызывающее их изменение кода или конфигурации.
Не полагайтесь только на автоматические тесты. Используйте ручное тестирование для обнаружения уязвимостей, обнаружить которые может только человеческий опыт. Ручное тестирование полезно для исследовательских случаев использования и обнаружения неизвестных рисков.
Импровизированные тесты
Импровизированные тесты обеспечивают проверку средств защиты на определенный момент времени. Предупреждения безопасности, которые могут повлиять на рабочую нагрузку в данный момент, запускают эти тесты. Организационные мандаты могут потребовать подхода «пауза и тестирование» для проверки эффективности стратегий защиты, если оповещение перерастает в чрезвычайную ситуацию.
Преимущество импровизированных тестов — готовность к реальному инциденту. Эти тесты могут быть принуждением функции к проведению приемочного тестирования пользователями (UAT).
Рабочая группа безопасности может проводить аудит всех рабочих нагрузок и при необходимости запускать эти тесты. Как владельцу рабочей нагрузки, вам необходимо помогать рабочим группам безопасности и сотрудничать с ними. Согласуйте достаточное время перед началом тестирования с рабочими группами безопасности, чтобы вы могли подготовиться. Признайте и сообщите своей рабочей группе и заинтересованным сторонам, что эти нарушения работы необходимы.
В других случаях вам может потребоваться запустить тесты и сообщить о состоянии безопасности системы относительно потенциальной угрозы.
Компромисс: поскольку импровизированные тесты нарушают обычную работу, следует ожидать изменения приоритета задач, что может привести к задержкам в запланированной работе.
Риск: существует риск неизвестного. Импровизированные тесты могут быть одноразовыми без установленных процессов или инструментов. Но преобладающим риском является потенциальное нарушение ритма бизнеса. Вам необходимо оценить эти риски относительно выгод.
Тестирование инцидентов безопасности
Существуют тесты, которые выявляют причину инцидента безопасности в его источнике. Эти пробелы в безопасности необходимо устранить, чтобы гарантировать, что инцидент не повторится.
Инциденты также со временем улучшают тестовые сценарии, выявляя существующие пробелы. Рабочая группа должна применять уроки, извлеченные из инцидента, и регулярно вносить улучшения.
Каковы различные типы тестов?
Тесты можно разделить на категории по технологиям и по методикам тестирования. Объедините эти категории и подходы внутри этих категорий, чтобы получить полный охват.
Добавляя несколько тестов и типов тестов, вы можете обнаружить:
- Пробелы в средствах контроля безопасности или компенсирующие меры контроля.
- Неправильные конфигурации.
- Пробелы в методах наблюдения и обнаружения.
Хорошее моделирование угроз может указать на ключевые области, в которых необходимо обеспечить охват и частоту тестирования. Рекомендации по моделированию угроз см. в разделе Рекомендации по обеспечению жизненного цикла разработки.
Большинство тестов, описанных в этих разделах, можно запускать как обычные тесты. Однако в некоторых случаях повторяемость может повлечь за собой затраты и привести к сбоям. Внимательно рассмотрите эти компромиссы.
Тесты, проверяющие стек технологий
Вот несколько примеров типов тестов и их направлений. Этот список не является исчерпывающим. Протестируйте весь стек, включая стек приложений, интерфейсную и серверную части, API, базы данных и любые внешние интеграции.
- Безопасность данных: проверьте эффективность шифрования данных и контроля доступа, чтобы убедиться, что данные должным образом защищены от несанкционированного доступа и подделки.
- Сеть и подключение: проверьте свои брандмауэры, чтобы убедиться, что они пропускают только ожидаемый, разрешенный и безопасный трафик для рабочей нагрузки.
- Приложение: протестируйте исходный код с помощью методов тестирования безопасности приложений (AST), чтобы убедиться, что вы соблюдаете методы безопасного программирования, и выявить ошибки времени выполнения, такие как повреждение памяти и проблемы с привилегиями.
- Удостоверение: оцените, работают ли назначения ролей и условные проверки должным образом.
Методика тестирования
Существует множество точек зрения на методологии тестирования. Мы рекомендуем тесты, которые позволяют осуществлять поиск угроз путем моделирования реальных атак. Они могут идентифицировать потенциальных злоумышленников, их методы и эксплойты, которые представляют угрозу для рабочей нагрузки. Сделайте атаки максимально реалистичными. Используйте все потенциальные векторы угроз, которые вы определили во время моделирования угроз.
Вот некоторые преимущества тестирования с помощью реальных атак:
- Когда вы делаете эти атаки частью регулярного тестирования, вы используете взгляд снаружи внутрь, чтобы проверить рабочую нагрузку и убедиться, что защита сможет противостоять атаке.
- На основе полученных уроков рабочая группа повышает уровень своих знаний и навыков. Рабочая группа улучшает ситуационную осведомленность и может самостоятельно оценивать свою готовность реагировать на инциденты.
Некоторые примеры смоделированных тестов включают тестирование «черного ящика» и «белого ящика», тестирование на проникновение и упражнения в военных играх.
Тестирование «черного ящика» и «белого ящика»
Эти типы тестов предлагают две разные точки зрения. В тестах «черного ящика» внутренности системы не видны. В тестах «белого ящика» тестировщик хорошо разбирается в приложении и даже имеет доступ к коду, журналам, топологии ресурсов и конфигурациям для проведения эксперимента.
Тесты, имитирующие атаки посредством тестирования на проникновение
Эксперты по безопасности, которые не входят в состав ИТ-отделов или групп приложений организации, проводят тестирование на проникновение или тестирование проникновения. Они смотрят на систему так, как злоумышленники исследуют поверхность атаки. Их цель — найти бреши в безопасности путем сбора информации, анализа уязвимостей и сообщения о результатах.
Практикующим специалистам может потребоваться доступ к конфиденциальным данным во всей организации. Следуйте правилам взаимодействия, чтобы гарантировать, что доступ не будет использоваться не по назначению. См. ресурсы, перечисленные в разделе См. также.
Тесты, имитирующие атаки посредством военных игр
В этой методологии моделирования атак есть две рабочие группы:
- Красная рабочая группа — это противник, пытающийся смоделировать атаки в реальном мире. Если они добьются успеха, вы находите пробелы в своей системе безопасности и оцениваете радиус сдерживания их нарушений.
- Синяя рабочая группа — это рабочая группа рабочей нагрузки, которая защищается от атак. Они проверяют свою способность обнаруживать атаки, реагировать и устранять их. Они проверяют средства защиты, реализованные для защиты ресурсов рабочей нагрузки.
Если они проводятся в виде обычных тестов, военные учения могут обеспечить постоянную видимость и уверенность в том, что ваша защита работает так, как задумано. Упражнения в военных играх потенциально могут проводить тесты на разных уровнях вашей рабочей нагрузки.
Популярным выбором для моделирования реалистичных сценариев атак является Microsoft Defender для обучения моделированию атак на Office 365.
Дополнительную информацию см. в разделе Аналитика и отчеты по обучению моделированию атак.
Дополнительные сведения о настройке красной и синей рабочих групп см. в разделе Красные рабочие группы в Microsoft Cloud.
Возможности в Power Platform
Решение Microsoft Sentinel для Microsoft Power Platform позволяет клиентам обнаруживать различные подозрительные действия, такие как:
- Исполнение Power Apps из несанкционированных географических регионов
- Подозрительное уничтожение данных Power Apps
- Массовое удаление Power Apps
- Фишинговые атаки, осуществленные через Power Apps
- Активность потоков Power Automate со стороны увольняющихся сотрудников
- Соединители Microsoft Power Platform, добавленные в среду
- Обновление или удаление политик защиты от потери данных Microsoft Power Platform
Дополнительную информацию см. в разделе решение Microsoft Sentinel для обзора Microsoft Power Platform.
Документацию по продукту см. в разделе Возможности поиска в Microsoft Sentinel.
Microsoft Defender для облака предлагает сканирование уязвимостей в различных областях технологий. Дополнительные сведения см. в разделе Включение сканирования уязвимостей с помощью управления уязвимостями Microsoft Defender.
Практика DevSecOps объединяет тестирование безопасности как часть постоянного и непрерывного совершенствования. Учения в военных играх — обычная практика, интегрированная в ритм бизнеса Microsoft. Дополнительные сведения см. в разделе Безопасность в DevOps (DevSecOps).
Azure DevOps поддерживает сторонние инструменты, которые можно автоматизировать в рамках конвейеров непрерывной интеграции/непрерывного развертывания (CI/CD). Дополнительные сведения см. в разделе Включение DevSecOps с помощью Azure и GitHub.
См. также
Последние тесты на проникновение и оценки безопасности можно найти на портале Microsoft Service Trust Portal.
Microsoft проводит тщательное тестирование служб Microsoft Cloud. Это тестирование включает в себя тестирование на проникновение, результаты которого публикуются на портале Service Trust Portal для вашей организации. Ваша организация может провести собственный тест на проникновение для служб Microsoft Power Platform и Microsoft Dynamics 365. Все тесты на проникновение должны соответствовать Правилам участия в тестировании на проникновение в Microsoft Cloud. Важно помнить, что во многих случаях Microsoft Cloud использует общую инфраструктуру для размещения ваших активов и активов, принадлежащих другим клиентам. Вы должны ограничить все тесты на проникновение своими активами и избегать непредвиденных последствий для других клиентов вокруг вас.
Следуйте правилам взаимодействия, чтобы гарантировать, что доступ не будет использоваться не по назначению. Рекомендации по планированию и выполнению симулированных атак см. в статьях:
Вы можете моделировать атаки типа «отказ в обслуживании» (DoS) в Azure. Обязательно следуйте политикам, изложенным в статье Тестирование моделирования защиты от атак DDoS Azure.
Контрольный список безопасности
Обратитесь к полному набору рекомендаций.