Поделиться через

Приложение и глоссарий документации по соответствию приложениям Microsoft 365

  • Статья

Приложение A

Требования к конфигурации профиля TLS

Весь сетевой трафик, будь то в виртуальной сети, облачной службе или центре обработки данных, должен быть защищен с помощью как минимум TLS версии 1.1 (рекомендуется tls версии 1.2+) или другого применимого протокола. Исключениями из этого требования являются:

  • Перенаправление HTTP-to-HTTPS. Приложение может отвечать по протоколу HTTP для перенаправления клиентов на HTTPS, но ответ не должен содержать конфиденциальные данные (файлы cookie, заголовки, содержимое). Другие HTTP-ответы, кроме перенаправления на HTTPS и реагирования на пробы работоспособности, не допускаются. См. ниже.
  • Пробы работоспособности. Приложение может реагировать на пробы работоспособности по протоколу HTTP , только если проверка работоспособности HTTPS не поддерживается проверяющей стороной.
  • Доступ к сертификату. Доступ к конечным точкам CRL, OCSP и AIA в целях проверки сертификата и проверки отзыва разрешен по протоколу HTTP.
  • Локальная связь. Ваше приложение может использовать ПРОТОКОЛ HTTP (или другие незащищенные протоколы) для обмена данными, которые не выходят из операционной системы, например для подключения к конечной точке веб-сервера, предоставляемой на localhost.

Сжатие TLS должно быть отключено.

Приложение B

Требования к конфигурации профиля шифрования

Допускаются только криптографические примитивы и параметры:

Симметричное шифрование

Шифрование

 ✓ Разрешены только AES, BitLocker, Blowfish или TDES. Допускается любая поддерживаемая длина >ключа =128 (128 бит, 192 бит и 256 бит) и может использоваться (рекомендуется использовать 256-разрядные ключи).

 ✓ Разрешен только режим CBC. Каждая операция шифрования должна использовать свежий, случайно созданный вектор инициализации (IV).

 ✓ Использование потоковых шифров, таких как RC4 и IS НЕ разрешено.

Хэш-функции

 ✓ Все новые коды должны использовать SHA-256, SHA-384 или SHA-512 (в совокупности называются SHA-2). Выходные данные могут быть усечены до не менее 128 бит

 ✓ SHA-1 можно использовать только для обеспечения совместимости.

 ✓ Использование MD5, MD4, MD2 и других хэш-функций не допускается даже для приложений, не являющихся криптографическими.

Проверка подлинности сообщений

 ✓ Все новые коды должны использовать HMAC с одной из утвержденных хэш-функций. Выходные данные HMAC могут быть усечены до не менее 128 бит.

 ✓ HMAC-SHA1 можно использовать только для обеспечения совместимости.

 ✓ Ключ HMAC должен быть не менее 128 бит. Рекомендуется использовать 256-разрядные ключи.

Асимметричные алгоритмы

Шифрование

 ✓ RSA разрешено. Ключ должен быть не менее 2048 бит, и необходимо использовать заполнение OAEP. Использование заполнений PKCS разрешено только в целях совместимости.

Подписи

 ✓ RSA разрешено. Ключ должен быть не менее 2048 бит, и необходимо использовать заполнение PSS. Использование заполнений PKCS разрешено только в целях совместимости.

 ✓ Разрешено ECDSA. Значение ключа должно быть не менее 256 бит. Необходимо использовать кривую NIST P-256, P-384 или P-521.

Обмен ключами

 ✓ разрешено ECDH. Значение ключа должно быть не менее 256 бит. Необходимо использовать кривую NIST P-256, P-384 или P-521.

 ✓ разрешено ECDH. Значение ключа должно быть не менее 256 бит. Необходимо использовать кривую NIST P-256, P-384 или P-521.

Приложение В

Сбор доказательств — Delta для ISO 27001

Если вы уже достигли ISO27001 соответствия требованиям, следующие разностные (пробелы), не охваченные СТАНДАРТОМ ISO 27001, как минимум, должны быть проверены в рамках этой сертификации Microsoft 365.

Примечание.

В рамках оценки сертификации Microsoft 365 аналитик по сертификации определит, не включены ли какие-либо из сопоставленных элементов управления ISO 27001 в рамках оценки ISO 27001, а также может принять решение о выборке элементов управления, которые были найдены для включения, чтобы обеспечить дополнительную уверенность. Все требования, отсутствующие в стандарте ISO 27001, должны быть включены в действия по оценке сертификации Microsoft 365.

Защита от вредоносных программ — антивирусная программа

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

  • Продемонстрировать, что антивирусная программа работает во всех примерах системных компонентов.

  • Продемонстрируйте, что антивирус настроен во всех примерах системных компонентов для автоматической блокировки вредоносных программ, карантина & оповещения или оповещения.

  • Антивирусное программное обеспечение должно быть настроено для регистрации всех действий.

Управление исправлениями — установка исправлений

Так как аудит ISO 27001 специально не оценивает эту категорию, для этого потребуется:

  • Программные компоненты и операционные системы, больше не поддерживаемые поставщиком , не должны использоваться в среде. Должны быть введены вспомогательные политики, чтобы гарантировать, что неподдерживаемые компоненты программного обеспечения или операционные системы будут удалены из среды, и процесс определения времени окончания срока службы программных компонентов

Сканирование уязвимостей

Так как аудит ISO 27001 специально не оценивает эту категорию, для этого потребуется:

  • Продемонстрировать, что проводится ежеквартально внутреннее и внешнее сканирование уязвимостей.

  • Убедитесь, что существует вспомогательная документация по исправлению уязвимостей на основе ранжирования рисков и в соответствии со спецификацией следующим образом:

✓ Исправление всех проблем с критическим и высоким риском в соответствии с рейтингом рисков для внутреннего сканирования.

✓ Исправление всех проблем с критическим, высоким и средним риском в соответствии с рейтингом рисков для внешнего сканирования.

✓ Продемонстрировать, что исправление выполняется в соответствии с задокументированной политикой исправления уязвимостей.

Брандмауэр — брандмауэры (или эквивалентные технологии)

Так как аудит ISO 27001 специально не оценивает эту категорию, для этого потребуется:

  • Продемонстрируйте, что брандмауэры установлены на границе среды в область.

  • Продемонстрируйте, что брандмауэры установлены между dmz и доверенными сетями.

  • Продемонстрировать, что в dmz прекращается весь открытый доступ.

  • Продемонстрируйте, что учетные данные администратора по умолчанию были изменены перед установкой в динамическую среду.

  • Продемонстрировать, что весь разрешенный трафик через брандмауэры проходит через процесс авторизации, который приводит к документированию всего трафика с бизнес-обоснованием.

  • Продемонстрировать, что все брандмауэры настроены для удаления трафика, не определенного явным образом.

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

  • Продемонстрировать, что неконсолевые административные интерфейсы брандмауэра, предоставляемые Интернету, поддерживают MFA.

  • Продемонстрировать, что проверки правил брандмауэра выполняются по крайней мере каждые 6 месяцев

Брандмауэр — брандмауэры веб-приложений (WAF)

При развертывании WAF будет предоставлен дополнительный кредит для защиты от множества угроз и уязвимостей веб-приложений, которым может подвергаться приложение. При наличии WAF или аналогичного вам потребуется:

  • Продемонстрируйте, что WAF настроен в активном режиме защиты или мониторинг с помощью оповещений.

  • Продемонстрируйте, что WAF настроен для поддержки разгрузки SSL.

  • Настраивается в соответствии с основным набором правил OWASP (3.0 или 3.1) для защиты от большинства следующих типов атак:

✓ Проблемы с протоколом и кодировкой.

✓ Внедрение заголовка, контрабанда запросов и разделение ответов.

✓ Атаки обхода файлов и путей.

✓ Атаки удаленного включения файлов (RFI).

✓ Атаки на удаленное выполнение кода.

✓ Атаки с внедрением PHP.

✓ Атаки с использованием межсайтовых сценариев.

✓ Атаки путем внедрения кода SQL.

✓ Атаки с фиксацией сеансов.

Управление изменениями

Так как аудит ISO 27001 не специально оценивает некоторые элементы процессов запроса на изменение, для этого потребуется:

  • Продемонстрировать, что запросы на изменение содержат следующие сведения:

✓ Задокументировано влияние.

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

✓ Сведения о любых процедурах резервного выхода.

  • Продемонстрировать, что тестирование функциональности выполняется после завершения изменений.

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

Управление учетными записями

Так как аудит ISO 27001 не специально оценивает некоторые элементы процессов управления учетными записями, для этого потребуется:

  • Демонстрация реализации ✓s для устранения атак на воспроизведение (например, MFA, Kerberos).
  • Продемонстрировать, как учетные записи, которые не использовались в течение 3 месяцев, отключаются или удаляются.
  • Для защиты учетных данных пользователя необходимо настроить ✓ или другие подходящие способы устранения рисков. В качестве руководства следует использовать следующую минимальную политику паролей:

✓ Минимальная длина пароля — 8 символов.

✓ Порог блокировки учетной записи не более 10 попыток.

✓ Журнал паролей не менее пяти паролей.

✓ Принудительное использование надежных паролей.

  • Продемонстрировать, что MFA настроена для всех решений удаленного доступа.

  • Продемонстрировать, что для всех решений удаленного доступа настроено надежное шифрование.

  • Если управление общедоступной DNS находится за пределами среды область, все учетные записи пользователей, способные вносить изменения в DNS, должны быть настроены на использование MFA.

Обнаружение и предотвращение вторжений (НЕОБЯЗАТЕЛЬНО)

Так как аудит ISO 27001 не специально оценивает некоторые элементы процессов обнаружения и предотвращения вторжений (IDPS), для этого потребуется:

  • IDPS должны быть развернуты по периметру вспомогательной среды.

  • Подписи IDPS должны быть актуальными в течение последнего дня.

  • IDPS должны быть настроены для проверки TLS.

  • IDPS должны быть настроены для всего входящего и исходящего трафика.

  • IDPS должны быть настроены для оповещений.

Ведение журнала событий

Так как аудит ISO 27001 не специально оценивает некоторые элементы процессов ведения журнала событий безопасности, для этого потребуется:

  • Продемонстрируйте, что общедоступные системы выполняют ведение журнала в централизованном решении ведения журнала, которое не находится в периметре периметра.

  • Продемонстрировать, как можно сразу же получить данные журналов за 30 дней с сохранением 90 дней.

Проверка (ведение журнала данных)

Так как аудит ISO 27001 не специально оценивает некоторые элементы этой категории, для этого потребуется:

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

Оповещения

Так как аудит ISO 27001 не специально оценивает некоторые элементы этой категории, для этого потребуется:

  • Демонстрация настройки событий безопасности для активации оповещений для немедленного рассмотрения.

  • Продемонстрировать, как сотрудники доступны 24/7 для реагирования на оповещения системы безопасности.

Управление рисками

Так как аудит ISO 27001 не специально оценивает некоторые элементы процессов оценки рисков, для этого потребуется:

  • Продемонстрировать, что установлен формальный процесс управления рисками.

Реагирование на инциденты

Так как аудит ISO 27001 не специально оценивает некоторые элементы политик и процессов реагирования на инциденты, для этого потребуется:

  • Продемонстрировать, что план и процедура реагирования на инциденты включают в себя:

✓ Конкретные процедуры реагирования для ожидаемых моделей угроз.

✓ Возможности обработки инцидентов, соответствующие платформе кибербезопасности NIST (определение, защита, обнаружение, реагирование, восстановление).

✓ IRP охватывает системы в область.

✓ Ежегодное обучение для группы реагирования на инциденты.

Приложение D

Сбор доказательств — разностные значения для PCI DSS

Если вы уже достигли соответствия ТРЕБОВАНИЯМ PCI DSS, следующие разностные (пробелы), не охваченные PCI DSS, как минимум, должны быть проверены в рамках этой сертификации Microsoft 365.

Примечание.

В рамках оценки сертификации Microsoft 365 аналитик по сертификации определит, не включены ли какие-либо из сопоставленных элементов управления PCI DSS в рамках оценки PCI DSS, а также может принять решение о выборке элементов управления, которые были обнаружены для обеспечения дополнительной гарантии. Все требования, отсутствующие в СТАНДАРТЕ PCI DSS, должны быть включены в действия по оценке сертификации Microsoft 365.

Защита от вредоносных программ — управление приложениями

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

  • Продемонстрируйте, как выполняется утверждение приложения, и подтвердите, что это завершено.

  • Продемонстрировать наличие полного списка утвержденных приложений с бизнес-обоснованием.

  • Предоставьте или продемонстрировать вспомогательную документацию по настройке программного обеспечения для управления приложениями в соответствии с определенными механизмами управления приложениями (например, списки разрешений, подписывание кода и т. д.).

  • Продемонстрируйте, что для всех образцов системных компонентов управление приложениями настраивается в соответствии с документом.

Управление исправлениями — ранжирование рисков

Так как аудит PCI DSS специально не оценивает эту категорию, вам потребуется:

  • Продемонстрировать, как проводится ранжирование уязвимостей по рискам.

Сканирование уязвимостей

Так как аудит PCI DSS специально не оценивает эту категорию, вам потребуется:

  • Продемонстрируйте, что исправление выполняется в соответствии с задокументированной политикой исправления уязвимостей.

Брандмауэр — брандмауэры (или эквивалентные технологии)

Так как аудит PCI DSS специально не оценивает эту категорию, вам потребуется:

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

  • Продемонстрировать, что неконсолевые административные интерфейсы брандмауэра, предоставляемые Интернету, поддерживают MFA.

Дополнительные кредиты будут предоставлены, если Брандмауэр веб-приложений (WAF) развернуты для защиты от множества угроз и уязвимостей веб-приложения, которым может подвергаться приложение. При наличии WAF или аналогичного вам потребуется:

  • Продемонстрируйте, что WAF настроен в активном режиме защиты или мониторинг с помощью оповещений.

  • Продемонстрируйте, что WAF настроен для поддержки разгрузки SSL.

  • Настраивается в соответствии с основным набором правил OWASP (3.0 или 3.1) для защиты от большинства следующих типов атак:

✓ Проблемы с протоколом и кодировкой.

✓ Внедрение заголовка, контрабанда запросов и разделение ответов.

✓ Атаки обхода файлов и путей.

✓ Атаки удаленного включения файлов (RFI).

✓ Атаки на удаленное выполнение кода.

✓ Атаки с внедрением PHP.

✓ Атаки с использованием межсайтовых сценариев.

✓ Атаки путем внедрения кода SQL.

✓ Атаки с фиксацией сеансов.

Управление изменениями

Так как аудит PCI DSS не специально оценивает некоторые элементы процессов запроса на изменение, для этого потребуется:

  • Продемонстрировать, что запросы на изменение создаются перед выполнением в рабочих средах.

  • Продемонстрировать, что изменения авторизованы, прежде чем перейти в рабочую среду.

  • Продемонстрировать, что тестирование функциональности выполняется после завершения изменений.

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

Безопасная разработка и развертывание программного обеспечения

Поскольку аудит PCI DSS не обращается к некоторым элементам безопасных процессов разработки и развертывания программного обеспечения; Для этого вам потребуется:

  • Репозитории кода должны быть защищены С помощью MFA.

  • Для защиты репозиториев кода от вредоносных изменений кода должны быть доступны соответствующие средства управления доступом.

Управление учетными записями

Поскольку аудит PCI DSS не специально оценивает некоторые элементы процессов управления учетными записями, для этого потребуется:

  • Демонстрация реализации механизмов авторизации для устранения атак на воспроизведение (например, MFA, Kerberos).

  • Для защиты учетных данных пользователя необходимо настроить политики надежных паролей или другие подходящие способы устранения рисков. В качестве руководства следует использовать следующую минимальную политику паролей:

✓ Минимальная длина пароля — 8 символов.

✓ Порог блокировки учетной записи не более 10 попыток.

✓ Журнал паролей не менее пяти паролей.

✓ Принудительное использование надежных паролей.

  • Продемонстрировать, что для всех решений удаленного доступа настроено надежное шифрование.

  • Если управление общедоступной DNS находится за пределами среды область, все учетные записи пользователей, способные вносить изменения в DNS, должны быть настроены на использование MFA.

Обнаружение и предотвращение вторжений (НЕОБЯЗАТЕЛЬНО)

Так как аудит PCI DSS не специально оценивает некоторые элементы процессов обнаружения и предотвращения вторжений (IDPS), для этого потребуется:

  • IDPS должны быть настроены для проверки TLS.

  • IDPS должны быть настроены для всего входящего и исходящего трафика.

Управление рисками

Так как аудит PCI DSS не специально оценивает некоторые элементы процессов оценки рисков, для этого потребуется:

  • Продемонстрируйте, что оценка рисков включает матрицы влияния и вероятности.

Реагирование на инциденты

Так как аудит PCI DSS не специально оценивает некоторые элементы политик и процессов реагирования на инциденты, разработчику потребуется:

  • Демонстрация возможностей обработки инцидентов в соответствии с NIST Cybersecurity Framework (определение, защита, обнаружение, реагирование, восстановление).

Приложение E

Сбор доказательств — разностные данные для SOC 2

Если вы уже достигли соответствия SOC 2, в рамках этой сертификации Microsoft 365 необходимо будет проверить следующие разностные (пробелы), не охваченные SOC 2.

Примечание.

В рамках оценки сертификации Microsoft 365 аналитик по сертификации определит, не включены ли какие-либо из сопоставленных элементов управления SOC 2 в рамках оценки SOC 2, а также может принять решение о выборке элементов управления, которые были найдены для включения, чтобы обеспечить дополнительную уверенность. Все требования, отсутствующие в оценке SOC 2, должны быть включены в действия по оценке сертификации Microsoft 365.

Защита от вредоносных программ — управление приложениями

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

  • Предоставьте или продемонстрировать вспомогательную документацию по настройке программного обеспечения для управления приложениями в соответствии с определенными механизмами управления приложениями (например, списки разрешений, подписывание кода и т. д.).

  • Продемонстрируйте, как выполняется утверждение приложения, и подтвердите, что это завершено.

  • Продемонстрировать наличие полного списка утвержденных приложений с бизнес-обоснованием.

  • Продемонстрируйте, что для всех образцов системных компонентов управление приложениями настраивается в соответствии с документом.

Управление исправлениями — установка исправлений

Так как аудит SOC 2 не специально оценивает эту категорию, вам потребуется:

  • Любая проблема низкого, среднего, высокого или критического уровня должна быть исправлена в обычных окнах действия исправления.

  • Программные компоненты и операционные системы, больше не поддерживаемые поставщиком, не должны использоваться в среде. Должны быть введены вспомогательные политики, чтобы гарантировать удаление из среды неподдерживаемых компонентов программного обеспечения или операционных систем, а также процесс определения момента окончания срока службы программных компонентов.

Брандмауэр — брандмауэры

Так как аудит SOC 2 не специально оценивает элементы управления изменениями в списках управления доступом к брандмауэру, для этого потребуется:

  • Продемонстрировать, что весь разрешенный трафик через брандмауэры проходит через процесс авторизации, который приводит к документации по всему трафику с бизнес-обоснованием.

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

Дополнительные кредиты будут предоставлены, если развернута Брандмауэр веб-приложений (WAF) или аналогичная для защиты от множества угроз и уязвимостей веб-приложения, которым может подвергаться приложение. При наличии WAF или аналогичного вам потребуется:

  • Продемонстрируйте, что WAF настроен в активном режиме защиты или мониторинг с помощью оповещений.

  • Продемонстрируйте, что WAF настроен для поддержки разгрузки SSL.

  • Настраивается в соответствии с основным набором правил OWASP (3.0 или 3.1) для защиты от большинства следующих типов атак:

 ✓ Проблемы с протоколом и кодировкой.

 ✓ Внедрение заголовка, контрабанда запросов и разделение ответов.

 ✓ Атаки обхода файлов и путей.

 ✓ Атаки удаленного включения файлов (RFI).

 ✓ Атаки на удаленное выполнение кода.

 ✓ Атаки с внедрением PHP.

 ✓ Атаки с использованием межсайтовых сценариев.

 ✓ Атаки путем внедрения кода SQL.

 ✓ Атаки с фиксацией сеансов.

Управление изменениями

Так как аудит SOC 2 не специально оценивает некоторые элементы процессов запроса на изменение, разработчику потребуется:

  • Продемонстрировать, как среды разработки и тестирования отделяются от рабочей среды, обеспечивая разделение обязанностей.

  • Демонстрация того, как динамические данные не используются в средах разработки и тестирования.

  • Продемонстрировать, что тестирование функциональности выполняется после завершения изменений.

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

Безопасная разработка и развертывание программного обеспечения

Так как аудит SOC 2 специально не обращается к некоторым элементам безопасных процессов разработки и развертывания программного обеспечения; Для этого вам потребуется:

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

  • Разработчики должны проходить обучение по безопасному кодированию программного обеспечения по крайней мере раз в год.

  • Репозитории кода должны быть защищены С помощью MFA.

  • Для защиты репозиториев кода от вредоносных изменений кода должны быть доступны соответствующие средства управления доступом.

Управление учетными записями

Так как аудит SOC2 не специально оценивает некоторые элементы процессов управления учетными записями, для этого потребуется:

  • Демонстрация реализации механизмов авторизации для устранения атак на воспроизведение (например, MFA, Kerberos).

  • Продемонстрировать, как учетные записи, которые не использовались в течение 3 месяцев, отключаются или удаляются.

  • Для защиты учетных данных пользователя необходимо настроить политики надежных паролей или другие подходящие способы устранения рисков. В качестве руководства следует использовать следующую минимальную политику паролей:

 ✓ Минимальная длина пароля — 8 символов.

 ✓ Порог блокировки учетной записи не более 10 попыток.

 ✓ Журнал паролей содержит не менее 5 паролей.

 ✓ Принудительное использование надежных паролей

  • Продемонстрировать, что уникальные учетные записи пользователей выдаются всем пользователям.

  • Если управление общедоступной DNS находится за пределами среды область, все учетные записи пользователей, способные вносить изменения в DNS, должны быть настроены на использование MFA.

Обнаружение и предотвращение вторжений (НЕОБЯЗАТЕЛЬНО).

Так как аудит SOC 2 не специально оценивает некоторые элементы процессов службы обнаружения и предотвращения вторжений (IDPS), для этого потребуется:

  • Подписи IDPS должны быть актуальными в течение последнего дня

  • IDPS должны быть настроены для проверки TLS

  • IDPS должны быть настроены для всего входящего и исходящего трафика

Ведение журнала событий

Так как аудит SOC 2 не специально оценивает некоторые элементы процессов ведения журнала событий безопасности, для этого потребуется:

  • Демонстрация того, как для всех системных компонентов в наборе примеров следующая система настроена для регистрации следующих событий

 ✓ Доступ пользователя к системным компонентам и приложениям.

 ✓ Все действия, выполняемые пользователем с высоким уровнем привилегий.

 ✓ Недопустимые попытки логического доступа.

Продемонстрировать, что зарегистрированные события содержат; как минимум, следующие сведения:

 ✓ Пользователь.

 ✓ Тип события.

 ✓ Дата и время.

 ✓ Индикатор успешности и сбоя.

 ✓ Метка для идентификации затронутой системы.

  • Продемонстрируйте, что все системные компоненты в наборе примеров настроены для использования синхронизации времени и что они совпадают с основными или вторичными серверами времени.

  • Продемонстрируйте, что общедоступные системы выполняют ведение журнала в централизованном решении ведения журнала, которое не находится в периметре периметра.

  • Продемонстрируйте, что общедоступные системы выполняют ведение журнала в централизованном решении ведения журнала, которое не находится в периметре периметра.

  • Продемонстрировать, как централизованное решение ведения журнала защищено от несанкционированного изменения данных ведения журнала.

  • Продемонстрировать, как можно сразу же получить данные журнала за минимум 30 дней с сохранением 90 дней или более.

Управление рисками

Так как аудит SOC2 не специально оценивает некоторые элементы процессов оценки рисков, для этого потребуется:

  • Продемонстрировать, что официальная оценка рисков проводится по крайней мере раз в год.

Реагирование на инциденты.

Так как аудит SOC2 не специально оценивает некоторые элементы политик и процессов реагирования на инциденты, для этого потребуется:

  • Продемонстрировать, что план и процедура реагирования на инциденты включают в себя:

 ✓ Конкретные процедуры реагирования для ожидаемых моделей угроз.

 ✓ Задокументирован процесс коммуникации, обеспечивающий своевременное уведомление ключевых заинтересованных лиц (платежных брендов/эквайеров, регулирующих органов, надзорных органов, директоров, клиентов и т. д.).

Приложение F

Типы развертывания размещения

Корпорация Майкрософт подтверждает, что вы будете развертывать приложения и хранить код приложений и надстроек в разных средах размещения. Общие обязанности некоторых элементов управления безопасностью в рамках сертификации Microsoft 365 будут зависеть от используемой среды размещения. В приложении F рассматриваются распространенные типы развертывания и сопоставляются с элементами управления безопасностью, которые оцениваются в рамках процесса оценки. Определены следующие типы развертывания размещения:

Типы размещения Описание
Размещено в isv Типы, размещенные в isV, можно определить, где вы отвечаете за инфраструктуру, используемую для поддержки среды приложения или надстройки. Они могут быть физически расположены в собственных центрах обработки данных или сторонних центрах обработки данных с помощью службы совместного размещения. В конечном счете вы имеете полный контроль владения и административного контроля над вспомогательной инфраструктурой и операционной средой.
Инфраструктура как услуга (IaaS) (https://azure.microsoft.com/overview/what-is-iaas/) Инфраструктура как услуга — это служба, которая предоставляется, в которой физическая инфраструктура поддержки управляется и обслуживается от их имени поставщиком облачных служб (CSP). Как правило, за сеть, хранилище, физические серверы и инфраструктуру виртуализации отвечает поставщик служб CSP. Вы несете ответственность за операционную систему, ПО промежуточного слоя, среду выполнения, данные и приложения. Возможности брандмауэра также будут управляться и поддерживаться сторонними разработчиками, однако обслуживание базы правил брандмауэра обычно будет по-прежнему отвечать на потребителей.
Платформа как услуга/бессерверная (PaaS) (https://azure.microsoft.com/overview/what-is-paas/) С помощью платформы как услуги вы подготовлены к работе с управляемой платформой, представляющей службу, которую можно использовать. Вам не нужно выполнять функции sysadmin, так как операционная система и поддерживающая инфраструктура управляется CSP. Обычно это используется, когда организации не хотят представлять веб-службу и вместо этого могут сосредоточиться на создании исходного кода веб-приложения и публикации веб-приложения в облачных управляемых веб-службах. Другим примером может быть служба базы данных, в которой предоставляется подключение к базе данных, однако поддерживающая инфраструктура и приложение базы данных абстрагируются от потребителя. Примечание. Бессерверные и PaaS похожи, поэтому для бессерверных типов развертывания сертификации Microsoft 365 и PasS считаются одинаковыми.
Гибридное размещение При использовании гибридного размещенного типа можно использовать несколько размещенных типов для поддержки различных частей вспомогательной среды. Это может быть в большей ситуации, когда приложения и надстройки используются в нескольких стеках Microsoft 365. Хотя сертификация Microsoft 365 будет поддерживать разработку приложений и надстроек в нескольких службах Microsoft 365, оценка всей среды поддержки (между приложениями и надстройками) должна быть оценена в соответствии с каждым из применимых сопоставлений типов. Иногда для одной надстройки можно использовать различные размещенные типы. В этом случае применимость условий должна по-прежнему соответствовать условиям сопоставления размещенных типов для различных размещенных типов.
Общий хостинг Общее размещение — это место, где вы размещаете среду в пределах платформы, к которой совместно используются несколько отдельных потребителей. Спецификация сертификации Microsoft 365 не была написана с учетом этого из-за внедрения облака, а общее размещение не является распространенным. Если вы считаете, что это используется, обратитесь в корпорацию Майкрософт, так как необходимо создать дополнительные требования, чтобы учесть дополнительные риски, связанные с этим типом размещения.

Приложение G

Дополнительные сведения

Обзор программы соответствия приложений Microsoft 365Что такое аттестация издателя приложений Microsoft 365?Что такое сертификация Microsoft 365?

Глоссарий

AIA

*Доступ к данным центра — это дескриптор расположения службы, используемый для поиска сертификата выдающего центра сертификации.

CRL

*Список отзыва сертификатов предоставляет средства для конечной точки SSL, чтобы убедиться, что сертификат, полученный от удаленного узла, является допустимым и надежным.

Оценка CVSS

*Общая система оценки уязвимостей — это опубликованный стандарт, который измеряет уязвимость и вычисляет числовую оценку на основе ее серьезности.

Рекомендации по управлению исправлениями CVSS

  • Критический (9.0 –10.0)
  • Высокий (7,0–8,9)
  • Средний (4.0 –6.9)
  • Низкий (0,0–3,9)

DMZ

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

FedRAMP

Федеральная программа управления рисками и авторизацией (FedRAMP) — это федеральная государственная программа США, созданная в 2011 году. Он обеспечивает стандартизированный подход к оценке безопасности, авторизации и непрерывному мониторингу облачных продуктов и служб.

EUII

Сведения, идентифицируемые пользователем.

GDPR

*Общий регламент по защите данных — это регулирование конфиденциальности и защиты данных для всех граждан ЕС, независимо от того, где расположен сайт вашего приложения.

HSTS

*Http Strict Transport Security использует заголовок ответа HTTP, который предписывает веб-браузеру получать доступ только к содержимому по протоколу HTTPS. Это предназначено для защиты от атак с понижением уровня и перехвата файлов cookie.

IEC

*Международная электротехническая комиссия.

ISMS

*Система управления информационной безопасностью.

Независимый поставщик программного обеспечения

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

ISO 27001

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

LFI

Включение локальных файлов позволяет злоумышленнику включать файлы на сервер через веб-браузер.

NIST

Национальный институт стандартов (NIST), нерегулируемое агентство Министерства торговли США, предоставляет рекомендации для организаций частного сектора в США по оценке и утверждению их способности предотвращать, обнаруживать и реагировать на кибератаки.

Незначаемые изменения

  • Незначительные исправления ошибок.
  • Незначительные улучшения производительности.
  • Исправления операционных систем, библиотек, клиентских и серверных приложений.

OCSP

Протокол состояния онлайн-сертификатов используется для проверка состояния отзыва цифровых сертификатов X.509.

OII

Сведения, идентифицируемые организации.

OWASP

Откройте проект по безопасности веб-приложений.

PCI DSS

Стандарт безопасности данных индустрии платежных карт— организация, которая поддерживает стандарты безопасности данных владельцев карт по всему миру.

Тестирование пера

Тестирование на проникновение — это метод тестирования веб-приложения путем имитации вредоносных атак для поиска уязвимостей системы безопасности, которые злоумышленник может использовать.

SAML

Язык разметки утверждений безопасности — это открытый стандарт для обмена данными проверки подлинности и авторизации между пользователем, поставщиком удостоверений и поставщиком услуг.

Конфиденциальные данные

  • Данные управления доступом.
  • Содержимое клиента.
  • Сведения об удостоверении конечного пользователя.
  • Поддержка данных.
  • Общедоступные персональные данные.
  • Сведения о псевдонимах конечного пользователя.

Значительные изменения

  • Перемещение среды размещения.
  • Крупные обновления вспомогательной инфраструктуры; например, реализация нового брандмауэра, крупные обновления внешних служб и т. д.
  • Добавление возможностей и расширений /или в приложение.
  • Обновления к приложению, которое собирает дополнительные конфиденциальные данные.
  • Изменения в потоках данных или моделях авторизации приложения
  • Добавление конечных точек API или функций конечных точек API.

SOC 2;

Service Organization Control 2— процедура технического аудита, состоящая из пяти принципов службы доверия, чтобы поставщики услуг безопасно управляли данными и конфиденциальностью клиентов организации.

SSL

Уровень безопасных сокетов.

TLS;

Безопасность транспортного уровня.