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