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

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

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

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

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

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

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

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

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 описывают типы методик тестирования, которые могут тестировать защиту времени сборки и среды выполнения приложения.

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

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

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

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