Рекомендации по тестированию безопасности
Применяется к этой рекомендации по контрольным спискам безопасности 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.
Связанные ссылки
Следуйте правилам задействования, чтобы убедиться, что доступ не используется неправильно. Инструкции по планированию и выполнению имитированных атак см. в следующих статьях:
Вы можете имитировать атаки типа "отказ в обслуживании" (DoS) в Azure. Обязательно следуйте политикам, изложенным в статье Тестирование имитации Защиты от атак DDoS Azure.
Ссылки на сообщество
Тестирование безопасности приложений. Средства, типы и рекомендации. Ресурсы GitHub описывают типы методологий тестирования, которые могут тестировать защиту приложения во время сборки и во время выполнения.
Стандарт проведения тестов на проникновение (Penetration Testing Execution Standard, PTES) содержит рекомендации по распространенным сценариям и действиям, необходимым для определения базовых показателей.
OWASP Top Ten | OWASP Foundation предоставляет рекомендации по обеспечению безопасности для приложений и тестовых случаев, охватывающих распространенные угрозы.
Контрольный список по безопасности
См. полный набор рекомендаций.
Обратная связь
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
Отправить и просмотреть отзыв по