Руководство по отправке сертификации Microsoft 365
В этой статье
- Введение
- Необходимые компоненты
- Спецификация сертификации Microsoft 365 Обновления
- Область сертификации
- Процесс сертификации
- Первоначальная отправка документа
- Действия по сбору и оценке доказательств
- Критерии сертификации
- Application Security
- Операционная безопасность
- Безопасность и конфиденциальность обработки данных
- Необязательная проверка внешних платформ соответствия требованиям
- Приложение A
- Приложение B
- Приложение В
- Приложение D
- Приложение E
- Приложение F
- Приложение G
- Подробнее
- Глоссарий
Введение
В рамках программы соответствия приложений Microsoft 365 сертификация Microsoft 365 обеспечивает корпоративным организациям уверенность в том, что данные и конфиденциальность должным образом защищены и защищены при интеграции приложений и надстроек сторонних разработчиков в платформу Microsoft 365. Приложения и надстройки, которые проходят проверку, будут назначены microsoft 365 Certified в экосистеме Microsoft 365.
Участвуя в программе сертификации Microsoft 365, вы соглашаетесь с этими дополнительными условиями и соблюдать любую сопроводимую документацию, которая относится к вашему участию в программе сертификации Microsoft 365 с корпорацией Майкрософт ("Microsoft", "мы", "нас" или "наш"). Вы заявляете и гарантируете нам, что у вас есть полномочия принимать эти дополнительные условия сертификации Microsoft 365 от имени себя, компании и (или) другой организации, если это применимо. Мы можем изменить, изменить или прекратить действие этих дополнительных условий в любое время. Ваше дальнейшее участие в программе сертификации Microsoft 365 после любого изменения или поправки означает, что вы соглашаетесь с новыми дополнительными условиями. Если вы не согласны с новыми дополнительными условиями или если мы прекратим действие этих дополнительных условий, вы должны прекратить участие в программе сертификации Microsoft 365.
Этот документ предназначен для независимых поставщиков программного обеспечения( независимых поставщиков программного обеспечения), чтобы предоставить сведения о процессе сертификации Microsoft 365, предварительные требования для начала процесса и сведения о конкретных элементах управления безопасностью, которые должны иметь независимые поставщики программного обеспечения. Общие сведения о программе соответствия приложений Microsoft 365 можно найти на странице программы соответствия приложений Microsoft 365.
Важно!
В настоящее время сертификация Microsoft 365 применяется ко всем:
- Приложения Microsoft Teams (вкладки, боты и т. д.) .
- Приложения и надстройки Sharepoint
- Надстройки Office (Word, Excel, PowerPoint, Outlook, Project, OneNote)
- Веб-приложения
Предварительные требования
Аттестация издателя
Прежде чем пройти сертификацию Microsoft 365, необходимо пройти аттестацию издателя. Однако вы можете начать процесс сертификации Microsoft 365 до завершения аттестации издателя.
Ознакомьтесь со спецификацией сертификации Microsoft 365.
Корпорация Майкрософт рекомендует всем независимым поставщикам программного обеспечения прочитать эту спецификацию сертификации Microsoft 365 в полном объеме, чтобы обеспечить соблюдение всех применимых элементов управления в среде область и приложением или надстройкой. Это поможет обеспечить беспроблемный процесс оценки.
Спецификация сертификации Microsoft 365 Обновления
Обновления спецификации сертификации Microsoft 365, как ожидается, будут выполняться примерно каждые шесть–12 месяцев. Эти обновления могут вводить новые целевые домены безопасности и (или) элементы управления безопасностью. Обновления будут основаны на отзывах разработчиков, изменениях в ландшафте угроз и повышении базовых показателей безопасности программы по мере ее развития.
Поставщики программного обеспечения, которые уже начали оценку сертификации Microsoft 365, могут продолжить оценку с версией спецификации сертификации Microsoft 365, которая была действительна на момент начала оценки. Все новые материалы, включая ежегодную повторную сертификацию, должны быть оценены по опубликованной версии.
Примечание.
Вы не обязаны соблюдать все элементы управления в рамках этой спецификации сертификации Microsoft 365, чтобы получить сертификат. Однако для каждого из доменов безопасности, обсуждаемых в этой спецификации сертификации Microsoft 365, применяются пороговые значения (которые не будут раскрыты). Некоторые элементы управления будут классироваться как "Жесткий сбой", что означает, что отсутствие этих элементов управления безопасностью приведет к неудачной оценке.
Область сертификации
Среда в область — это среда, которая поддерживает доставку кода приложения или надстройки и поддерживает любые серверные системы, с которыми может взаимодействовать приложение или надстройка. Любые дополнительные подключенные к средам также будут включены в область, если не выполняется достаточная сегментация и подключенные среды не могут повлиять на безопасность среды в область. Все среды аварийного восстановления также должны быть включены в область оценки, так как эти среды потребуются для выполнения службы, если что-либо произойдет с основной средой. Термин область системных компонентов ссылается на ВСЕ устройства и системы, используемые в среде область. Компоненты область включают, но не ограничиваются следующими:
- Веб-приложения.
- Серверов.
- Брандмауэры (или эквивалентные).
- Переключатели.
- Подсистемы балансировки нагрузки.
- Виртуальная инфраструктура.
- Порталы веб-управления поставщиков облачных служб
Важно!
Среда в область должна иметь периметр, а поддерживающая среда приложения или надстройки должна быть сегментирована от внутренних бизнес-систем и корпоративных сред, что ограничивает область действий оценки только область системами. Аналитики сертификации будут проверять методы сегментации во время оценки, а также просматривать отчеты о тестировании на проникновение, которые должны были включать тестирование для проверки эффективности любых используемых методов сегментации.
Инфраструктура как услуга (IaaS), Платформа как услуга (PaaS) и Программное обеспечение как услуга (SaaS)
Если IaaS и (или) PaaS используется для поддержки инфраструктуры проверяемого приложения или кода надстройки, поставщик облачной платформы будет отвечать за некоторые средства управления безопасностью, оцениваемые в процессе сертификации. Таким образом, аналитикам сертификации потребуется обеспечить независимую внешнюю проверку рекомендаций по обеспечению безопасности от поставщика облачной платформы с помощью внешних отчетов о соответствии требованиям, таких как [PCI DSS] Аттестация соответствия (AOC), ISO27001 или [SOC 2] отчеты типа II.
Приложение F содержит сведения о том, какие элементы управления безопасностью, скорее всего, будут применяться в зависимости от следующих типов развертывания и в зависимости от того, эксфильтрует ли приложение или надстройка данные Microsoft 365:
- Размещено в isv
- Размещено в IaaS
- PaaS/бессерверное размещение
- Гибридное размещение
- Общая размещенная
При развертывании IaaS или PaaS необходимо предоставить свидетельство о среде, размещенной в этих типах развертывания.
Выборки
Запросы на подтверждение в поддержку оценки сертификации должны основываться на выборке область системных компонентов с учетом различных операционных систем, основной функции устройства и различных типов устройств. Подходящий образец будет выбран в начале процесса сертификации. Следующую таблицу следует использовать в качестве руководства по размеру выборки:
| Размер населения | Пример |
|---|---|
| <5 | 1 |
| >5 & <10 | 2 |
| >9 & <25 | 3 |
| >24 | 4 |
Примечание.
Если между устройствами, включенными в исходную выборку, обнаружены несоответствия, во время оценки размер выборки может быть увеличен.
Процесс сертификации
Перед началом процесса сертификации необходимо успешно пройти аттестацию издателя. После завершения процесса сертификации Microsoft 365 выполняется следующим образом:
Подготовка
- Перейдите в Центр партнеров и просмотрите завершенную документацию по аттестации издателя . При необходимости вы можете изменять и обновлять ответы; Однако в этом случае потребуется повторно отправить документацию по аттестации для утверждения. Если ваша отправка старше трех месяцев, потребуется повторно отправить аттестацию издателя для проверки и проверки.
- Внимательно прочитайте руководство по отправке сертификации Microsoft 365 , чтобы понять, что от вас потребуется. Убедитесь, что вы сможете выполнить требования к элементу управления , указанные в руководстве по отправке сертификации Microsoft 365.
- В Центре партнеров выберите "Начать сертификацию". Это приведет к начальному порталу отправки документов. Отправьте первоначальную отправку документа. Это поможет нам определить, что область для вашей оценки на основе архитектуры вашего приложения и обработки данных клиентов. Часто проверяйте эту страницу, чтобы узнать, была ли ваша отправка принята.
Примечание.
Для всех приложений Office вы можете ссылаться на наше руководство пользователя по приложениям Office. Для всех веб-приложений вы можете ссылаться на наше руководство пользователя приложения SaaS.
Оценка
- После принятия первоначальной отправки документа набор элементов управления безопасностью, необходимых для приложения, будет автоматически отображаться на портале. Затем вам потребуется предоставить доказательства для каждого элемента управления, демонстрирующие, что элемент управления установлен. Имейте в виду, что вам будет предоставлено 60 дней , чтобы представить все доказательства. Аналитик проверит ваши доказательства и либо утвердит элемент управления, либо запросит новые или дополнительные доказательства. Часто проверяйте эту страницу, чтобы узнать, были ли приняты ваши доказательства.
Сертификация
- После проверки отправки аналитиком вы получите уведомление о решении о сертификации. Приложения, получиющие сертификацию, получат значок на своих приложениях в AppSource и на страницах документации Майкрософт . Полные преимущества сертификации см. здесь.
Проверка и повторная сертификация
Если ваше приложение в любой момент претерпит существенные изменения , вам потребуется уведомить нас.
Вам также потребуется проходить повторную сертификацию на ежегодной основе. Это потребует повторной проверки элементов управления в область в текущей среде. Этот процесс может начаться до 90 дней до истечения срока действия вашей сертификации. Срок действия имеющейся сертификации не истечет в течение периода повторной сертификации. Срок действия повторной сертификации для всех программ истекает в год сертификации Microsoft 365.
Если ваша сертификация не будет продлена до даты окончания срока действия, состояние сертификации приложений будет отозвано. Все изменения, значки и связанные с ним фирменные символы сертификации будут удалены из приложения, и вам будет запрещено рекламировать приложение как сертифицированное microsoft 365.
Важно!
Интервал времени отправки: Ожидается, что в среднем процесс оценки займет 30 дней при условии, что вы сможете часто проверка состояние отправки и своевременно ответить на комментарии и дополнительные запросы на доказательства. После начала процесса сертификации допускается не более 60 дней для завершения оценки. Если все отправки не были завершены в течение 60-дневного периода времени, отправка будет выдана сбой, и процесс должен начаться снова. Эти результаты не будут обнародованы.
Первоначальная отправка документа
Первоначальная отправка документа поможет аналитикам сертификации выполнить определение области и определить, что будет область для вашей оценки. После этого вам потребуется предоставить подтверждающую документацию и доказательства, используемые для проведения оценки. Ваша первоначальная отправка должна содержать указанные ниже сведения. Дополнительные рекомендации см. в руководстве по первоначальной отправке документов.
| Обзор документации | Сведения о документации |
|---|---|
| Описание приложения или надстройки | Описание назначения и функциональности приложения или надстройки. Это должно дать аналитику сертификации хорошее представление о том, как работает приложение или надстройка и что они предназначены для использования. |
| Отчет о тестировании на проникновение | Отчет о тестировании на проникновение, завершенный за последние 12 месяцев. Этот отчет должен содержать среду, поддерживающую развертывание приложения или добавления, а также любую дополнительную среду, поддерживающую работу приложения или надстройки. Примечание. Если вы не проводите ежегодное тестирование на проникновение, вы можете выбрать, чтобы они выполнялись в процессе сертификации. |
| Схемы архитектуры | Схема логической архитектуры, представляющая общий обзор вспомогательной инфраструктуры приложения или надстройки. Сюда должны входить все среды размещения и вспомогательная инфраструктура, поддерживающая приложение или надстройку. На этой схеме должны быть показаны все различные вспомогательные системные компоненты в среде, чтобы помочь аналитикам сертификации понять системы в область и определить выборку. Укажите также, какой тип среды размещения используется; IsV Hosted, IaaS, PaaS или Hybrid. Примечание: Где используется SaaS, укажите различные службы SaaS, которые используются для предоставления вспомогательных служб в среде. |
| Общедоступная занимаемая площадь | Подробные сведения обо всех общедоступных IP-адресах и URL-адресах, используемых вспомогательной инфраструктурой. Это должно включать полный диапазон IP-адресов, выделенный для среды, если не была реализована достаточная сегментация для разделения используемого диапазона (потребуется адекватное свидетельство сегментации). |
| С помощью схем потока данных | Схемы потоков, подробно описанные ниже. |
| ✓ Данные Microsoft 365 передаются в приложение или надстройку и из нее (включая EUII и OII ). | |
| ✓ Потоки данных Microsoft 365 в вспомогательной инфраструктуре (если применимо) | |
| ✓ Схемы, в которых показано, где и какие данные хранятся, как данные передаются внешним третьим лицам (включая сведения о сторонних сторонах), а также как данные защищаются при передаче через открытые или общедоступные сети и неактивные. | |
| Сведения о конечной точке API | Полный список всех конечных точек API, используемых приложением. Чтобы понять область среды, укажите расположения конечных точек API в среде. |
| Разрешения API Майкрософт | Предоставьте документацию со сведениями обо всех используемых API Майкрософт, а также о том, какие разрешения запрашиваются для работы приложения или надстройки, а также обоснование запрошенных разрешений. |
| Типы хранилищ данных | Хранение данных и обработка документов, описывающих: |
| ✓ В какой степени ваши клиенты Microsoft 365 Data EUII и OII получаются и хранятся | |
| ✓ Срок хранения данных. | |
| ✓ Почему собираются данные клиента Microsoft 365. | |
| ✓ Где хранятся данные Microsoft 365 клиента (должны быть включены в схемы потока данных, предоставленные выше). | |
| Подтверждение соответствия требованиям | Вспомогательная документация по внешним платформам безопасности, включенным в отправку аттестации издателя или которые должны учитываться при проверке элементов управления сертификацией Microsoft 365. В настоящее время поддерживаются следующие три варианта: |
| ✓ Аттестация соответствия требованиям PCI DSS (AOC). | |
| ✓ Отчеты SOC 2 типа I/II. | |
| ✓ ISMS / IEC - 1S0/IEC 27001 Заявление о применимости (SoA) и сертификация. | |
| Веб-зависимости | Документация содержит список всех зависимостей, используемых приложением или надстройкой с текущими запущенными версиями. |
| Инвентаризация программного обеспечения | Актуальный перечень программного обеспечения, включающий все программное обеспечение, используемое в среде область, а также версии. |
| Инвентаризация оборудования | Актуальные данные инвентаризации оборудования, используемого вспомогательной инфраструктурой. Это будет использоваться для упрощения выборки при выполнении этапа оценки. Если ваша среда включает PaaS, укажите сведения об используемых службах. |
Действия по сбору и оценке доказательств
Аналитикам сертификации потребуется проверить доказательства по всем компонентам системы в заданном наборе примеров. Типы доказательств, необходимых для поддержки процесса оценки, включают в себя любые или все следующие:
Сбор доказательств
- Начальная документация, выделенная в разделе "Первоначальная отправка документации " выше
- Документы политики
- Обработка документов
- Параметры конфигурации системы
- Изменение билетов
- Изменения записей элементов управления
- Системные отчеты
Для сбора доказательств, необходимых для завершения процесса оценки, будут использоваться различные методы. Эта коллекция доказательств может быть представлена в следующих формах:
- Документы
- Снимки экрана
- Интервью
- Скринс-шеринг
Используемые методы сбора доказательств будут определены в процессе оценки. Конкретные примеры типов доказательств, необходимых для отправки, см. в руководстве по примерам доказательств.
Действия по оценке
Аналитики сертификации проверят предоставленные вами доказательства, чтобы определить, правильно ли вы выполнили элементы управления в рамках этой спецификации сертификации Microsoft 365.
Там, где это возможно, и чтобы сократить время, необходимое для завершения оценки, любая или вся документация, описанная в первоначальной документации , должна быть предоставлена заранее.
Специалисты по сертификации сначала проверят доказательства, предоставленные из первоначальной документации и сведений об аттестации издателя, чтобы определить соответствующие направления запроса, размер выборки и необходимость получения дополнительных доказательств, как описано выше. Аналитики по сертификации проанализируют всю собранную информацию, чтобы сделать выводы о том, как и если вы выполняете контроль в рамках этой спецификации сертификации Microsoft 365.
Критерии сертификации приложений
Ваше приложение, поддерживающая инфраструктура и сопроводительная документация будут оцениваться в следующих доменах безопасности:
- Application Security
- Операционная безопасность и безопасное развертывание
- Безопасность и конфиденциальность обработки данных
Каждый из этих доменов безопасности включает в себя определенные ключевые элементы управления, охватывающие одно или несколько конкретных требований, которые будут оцениваться в рамках процесса оценки. Чтобы гарантировать, что сертификация Microsoft 365 является инклюзивной для разработчиков всех размеров, каждый из доменов безопасности оценивается с помощью системы оценки для определения общей оценки по каждому из доменов. Оценки для каждого из элементов управления сертификацией Microsoft 365 распределяются между 1 (низким) и 3 (высоким) в зависимости от предполагаемого риска того, что этот элемент управления не будет выполнен. Каждый из доменов безопасности будет иметь минимальную процентную отметку, которую можно считать проходной. Некоторые элементы этой спецификации включают некоторые условия автоматического сбоя:
- Разрешения API не следуют принципу минимальных привилегий (PoLP).
- При необходимости нет отчета о тестировании на проникновение.
- Защита от вредоносных программ отсутствует
- Многофакторная проверка подлинности не используется для защиты административного доступа.
- Нет процессов исправления.
- Нет подходящего уведомления о конфиденциальности GDPR .
Application Security
Домен безопасности приложений сосредоточен на следующих трех областях:
- Проверка разрешений GraphAPI
- Внешние проверки подключения
- Тестирование безопасности приложений
Проверка разрешений GraphAPI
Проверка разрешений GraphAPI выполняется для проверки того, что приложение или надстройка не запрашивает слишком разрешительные разрешения. Это выполняется путем ручной проверки запрашиваемых разрешений. Аналитики сертификации будут перекрестно ссылаться на эти проверки в соответствии с отправкой аттестации издателя и оценивать уровень запрашиваемого доступа, чтобы убедиться, что соблюдаются методы "наименьших привилегий". Если аналитики сертификации считают, что эти методы "минимальных привилегий" не выполняются, аналитики по сертификации будут открыто обсудить с вами, чтобы проверить бизнес-обоснование запрашиваемых разрешений. Любые несоответствия с вашей отправкой аттестации издателя, обнаруженные в ходе этой проверки, также получат отзыв, чтобы можно было обновить аттестацию издателя.
Внешние проверки подключения
В рамках оценки аналитик выполнит простое пошаговое руководство по функциям приложений для выявления подключений за пределами Microsoft 365. Все подключения, которые не определены как microsoft или прямые подключения к вашей службе, будут помечены и обсуждены во время оценки.
Тестирование безопасности приложений
Адекватный анализ рисков, связанных с приложением или надстройкой и вспомогательной средой, имеет важное значение для обеспечения клиентам уверенности в безопасности приложения или надстройки. Тестирование безопасности приложений в форме тестирования на проникновение должно выполняться, если ваше приложение имеет какое-либо подключение к какой-либо службе, не опубликованной корпорацией Майкрософт. Если ваше приложение работает автономно без подключения к какой-либо службе сторонних поставщиков или серверной части, тестирование на проникновение не требуется.
Область тестирования на проникновение
Действия по тестированию на проникновение должны выполняться в рабочей среде, поддерживающей развертывание приложения или надстройки (например, где размещается код приложения или надстройки, который обычно является ресурсом в файле манифеста), а также в любой дополнительной среде, поддерживающей работу приложения или надстройки (например, если приложение или надстройка взаимодействует с другими веб-приложениями за пределами Microsoft 365). При определении область необходимо позаботиться о том, чтобы все системы или среды , подключенные к , которые могут повлиять на безопасность область среды, также включены в все действия по тестированию на проникновение.
Если методы используются для сегментирования сред в область из других сред, действия по тестированию на проникновение должны проверять эффективность указанных методов сегментации. Это должно быть подробно описано в отчете о тестировании на проникновение.
Отчеты о тестировании на проникновение будут проверены, чтобы убедиться, что нет уязвимостей, которые соответствуют следующим критериям автоматического сбоя , описанным в элементах управления ниже.
Требования к тестированию на проникновение
| Тип условия | Элементы управления тестом на проникновение |
|---|---|
| Общие критерии | Controls |
| Тестирование на проникновение приложений и инфраструктуры должно проводиться ежегодно (каждые 12 месяцев) и проводится авторитетной независимой компанией. | |
| Исправление выявленных критических уязвимостей и уязвимостей с высоким риском должно быть завершено в течение одного месяца после завершения тестирования на проникновение или раньше в зависимости от задокументированного процесса исправления. | |
| Полный внешний объем (IP-адреса, URL-адреса, конечные точки API и т. д.) Должны быть включены в область тестирования на проникновение и должны быть задокументированы в отчете о тестировании на проникновение. | |
| Тестирование на проникновение веб-приложений должно включать все классы уязвимостей; например, самый актуальный OWASP Top 10 или SANS Top 25 CWE. | |
| Повторное тестирование обнаруженных уязвимостей компанией по тестированию на проникновение не требуется— исправление и самостоятельная проверка достаточно, однако во время оценки должны быть предоставлены достаточные доказательства, подтверждающие достаточное исправление . | |
| Условия автоматического сбоя: | Controls |
| Наличие неподдерживаемой операционной системы. | |
| Наличие учетных записей администратора по умолчанию, перечисляемых или угадываемых учетных записей. | |
| Наличие рисков внедрения кода SQL. | |
| Наличие междоменных сценариев. | |
| Наличие уязвимостей обхода каталога (путь к файлу). | |
| Наличие уязвимостей HTTP, например разделение ответа заголовка, контрабанда запросов и десинхронные атаки. | |
| Наличие раскрытия исходного кода (включая LFI). | |
| Любая критическая или высокая оценка, определенная в рекомендациях по управлению исправлениями CVSS. | |
| Любая значительная техническая уязвимость, которую можно легко использовать для компрометации большого количества EUII или OUI. |
Важно!
Отчеты должны иметь достаточный уровень уверенности в том, что все подробное описание в разделе Спецификация тестирования безопасности приложений можно продемонстрировать.
Требования и правила бесплатного тестирования на проникновение
- Для поставщиков программного обеспечения, которые в настоящее время не участвуют в тестировании на проникновение, тестирование на проникновение может быть проведено бесплатно по сертификации Microsoft 365. Корпорация Майкрософт организует и покрывает расходы на тест на проникновение в течение 12 дней ручного тестирования. Затраты на тесты на проникновение рассчитываются на основе количества дней, необходимых для тестирования среды. За любые расходы, превышающие 12 дней тестирования, несет isv.
- Поставщики программного обеспечения должны будут представить доказательства и получить одобрение для 50% элементов контроля в область до проведения испытания на проникновение. Чтобы приступить к работе, заполните свою первоначальную отправку документа и выберите, чтобы тестирование на проникновение было включено в рамках оценки. С вами свяжутся, чтобы область и запланировать тест на проникновение после завершения 50 % элементов управления.
- Отчет, выданный после завершения pentest, будет предоставлен независимого поставщика программного обеспечения после завершения сертификации. Этот отчет вместе с сертификацией Microsoft 365 можно использовать, чтобы показать потенциальным клиентам, что ваша среда безопасна.
- Поставщики программного обеспечения также будут нести ответственность за демонстрацию того, что уязвимости, обнаруженные в тесте на проникновение, были устранены до получения сертификации, но им не нужно создавать чистый отчет.
После проведения теста на проникновение isv несет ответственность за сборы, связанные с переносом и отменой, следующим образом:
| Изменение шкалы времени оплаты | Пропорция к оплате |
|---|---|
| Запрос на перенос получил более чем за 30 дней до запланированной даты начала. | 0% к оплате |
| Запрос на перенос был получен за 8–30 дней до запланированной даты начала. | 25% к оплате |
| Запрос на перенос, полученный в течение 2–7 дней до запланированной даты начала с датой перебронирования фирмы. | 50% к оплате |
| Запрос на изменение расписания получен менее чем за 2 дня до даты начала. | 100 % к оплате |
| Шкала времени отмены сбора | Пропорция к оплате |
|---|---|
| Запрос на отмену получен более чем за 30 дней до запланированной даты начала. | 25% к оплате |
| Запрос на отмену получен за 8–30 дней до запланированной даты начала. | 50% к оплате |
| Запрос на отмену получен в течение 7 дней до запланированной даты начала. | 90% к оплате |
Операционная безопасность
Этот домен измеряет соответствие поддерживающей инфраструктуры и процессов развертывания приложения с помощью рекомендаций по обеспечению безопасности.
Элементы управления
| Семейство элементов управления | Controls |
|---|---|
| Защита от вредоносных программ — антивирусная программа | Предоставьте документацию по политикам, которые регулируют антивирусные методики и процедуры. |
| Предоставьте наглядное свидетельство того, что антивирусное программное обеспечение работает во всех образцах системных компонентов. | |
| Предоставьте доказательства того, что антивирусные сигнатуры актуальны во всех средах (в течение 1 дня). | |
| Предоставьте наглядное подтверждение того, что антивирусная программа настроена для проверки доступа или периодического сканирования всех образцов системных компонентов. Примечание. Если проверка при доступе не включена, необходимо включить как минимум ежедневное сканирование и оповещение. | |
| Предоставьте наглядное подтверждение того, что антивирус настроен для автоматической блокировки вредоносных программ или карантина и оповещения во всех примерах системных компонентов. | |
| Элементы управления приложениями: требуется только в том случае, если традиционные средства защиты от вредоносных программ не используются | Предоставьте наглядное подтверждение того, что приложения утверждены перед развертыванием. |
| Предоставьте наглядное свидетельство того, что существует и поддерживается полный список утвержденных приложений с бизнес-обоснованием. | |
| Предоставьте вспомогательную документацию о том, что программное обеспечение для управления приложениями настроено в соответствии с определенными механизмами управления приложениями. (Пример. Разрешенный листинг: sample1, sample3, code подписывание) | |
| Предоставьте наглядное свидетельство того, что управление приложениями настроено так, как описано из всех образцов системных компонентов. | |
| Управление исправлениями — ранжирование рисков | Предоставьте документацию по политике, которая определяет, как выявляются новые уязвимости системы безопасности и присваиваются оценка риска. |
| Предоставьте доказательства того, как выявляются новые уязвимости системы безопасности. | |
| Предоставьте доказательства того, что всем уязвимостям присваивается рейтинг риска после выявления. | |
| Управление исправлениями — исправление | Предоставьте документацию по политикам для исправления область системных компонентов, которая включает подходящие минимальные сроки исправления для уязвимостей с критическими, высокими и средними рисками, а также вывод из эксплуатации любых неподдерживаемых операционных систем и программного обеспечения. |
| Предоставьте демонстрационные доказательства того, что все выборки системных компонентов находятся в исправлении. | |
| Предоставьте наглядное свидетельство того, что в среде не используются неподдерживаемые операционные системы и программные компоненты. | |
| Проверка уязвимостей | Предоставьте ежеквартальные отчеты об уязвимостях инфраструктуры и веб-приложений. Сканирование должно выполняться по всем общедоступным (IP-адресам и URL-адресам) и внутренним диапазонам IP-адресов. |
| Предоставьте демонстрируемые доказательства того, что исправления уязвимостей, выявленных во время проверки уязвимостей, исправляются в соответствии с документированным временем исправления. | |
| Брандмауэры | Предоставьте документацию по политикам, которые регулируют методы и процедуры управления брандмауэром. |
| Предоставьте наглядное свидетельство того, что все учетные данные администратора по умолчанию были изменены перед установкой в рабочие среды. | |
| Предоставьте наглядное свидетельство того, что брандмауэры устанавливаются на границе среды в область и устанавливаются между сетью периметра (также известной как DMZ, демилитаризованная зона и экранированная подсеть) и внутренними доверенными сетями. | |
| Предоставьте наглядное доказательство того, что все открытые доступы прекращаются в демилитаризованной зоне (DMZ). | |
| Предоставьте наглядное доказательство того, что весь трафик, разрешенный через брандмауэр, проходит через процесс утверждения. | |
| Предоставьте наглядное свидетельство того, что база правил брандмауэра настроена для удаления трафика, не определенного явным образом. | |
| Предоставьте наглядное свидетельство того, что брандмауэр поддерживает только надежное шифрование для всех административных интерфейсов, не являющихся консольными. | |
| Предоставьте демонстрируемые доказательства того, что вы выполняете проверку правил брандмауэра по крайней мере каждые 6 месяцев. | |
| Брандмауэр веб-приложений (WAF) (НЕОБЯЗАТЕЛЬНО): дополнительный кредит будет вознагражден за выполнение следующих элементов управления. | Предоставьте наглядное свидетельство того, что Брандмауэр веб-приложений (WAF) настроен для активного мониторинга, оповещения и блокировки вредоносного трафика. |
| Предоставьте наглядное подтверждение того, что WAF поддерживает разгрузку SSL. | |
| Предоставьте наглядное свидетельство того, что WAF защищает от некоторых или всех следующих классов уязвимостей в соответствии с набором основных правил OWASP (3.0 или 3.1). | |
| Управление изменениями | Предоставьте документацию по политике, которая управляет процессами управления изменениями. |
| Предоставьте наглядное свидетельство того, что среды разработки и тестирования обеспечивают разделение обязанностей от рабочей среды. | |
| Предоставьте наглядное свидетельство того, что конфиденциальные рабочие данные не используются в средах разработки или тестирования. | |
| Предоставьте наглядное свидетельство того, что задокументированные запросы на изменение содержат влияние изменения, подробные сведения о процедурах обратного выхода и тестировании, которые необходимо выполнить. | |
| Предоставьте наглядное подтверждение того, что запросы на изменение проходят авторизацию и выход из нее. | |
| Безопасная разработка и развертывание программного обеспечения | Предоставьте политики и процедуры, поддерживающие безопасную разработку и развертывание программного обеспечения, включая рекомендации по безопасному программированию для распространенных классов уязвимостей, таких как OWASP Top 10 или SANS Top 25 CWE. |
| Предоставьте наглядное свидетельство того, что изменения кода проходят проверку и авторизацию вторым рецензентом. | |
| Предоставьте наглядное свидетельство того, что разработчики ежегодно проходят обучение по безопасной разработке программного обеспечения. | |
| Предоставьте наглядное свидетельство того, что репозитории кода защищены многофакторной проверкой подлинности (MFA). | |
| Предоставьте наглядное подтверждение наличия элементов управления доступом для защиты репозиториев кода. | |
| Управление учетными записями | Предоставьте документацию по политике, которая регулирует методы и процедуры управления учетными записями. |
| Предоставьте наглядное свидетельство того, что учетные данные по умолчанию отключены, удалены или изменены в выборочных системных компонентах. | |
| Предоставьте доказательства того, что создание, изменение и удаление учетной записи проходят через установленный процесс утверждения. | |
| Предоставьте наглядное подтверждение того, что выполняется процесс отключения или удаления учетных записей, не используемых в течение 3 месяцев. | |
| Предоставьте наглядное подтверждение наличия политики надежных паролей или других подходящих мер для защиты учетных данных пользователя. В качестве минимального руководства следует использовать следующее: минимальная длина пароля 8 символов, пороговое значение блокировки учетной записи не более 10 попыток, журнал паролей не менее 5 паролей, принудительное использование надежного пароля | |
| Предоставьте наглядное подтверждение того, что уникальные учетные записи пользователей выдаются всем пользователям. | |
| Предоставьте наглядное свидетельство того, что в среде соблюдаются принципы минимальных привилегий. | |
| Предоставьте наглядное свидетельство того, что выполняется процесс защиты или усиления защиты учетных записей службы и что этот процесс выполняется. | |
| Предоставьте наглядное подтверждение того, что MFA настроена для всех подключений удаленного доступа и всех неконсолевых административных интерфейсов. | |
| Предоставление наглядного доказательства того, что для всех подключений удаленного доступа и всех административных интерфейсов, не являющихся консольными, настроено надежное шифрование, включая доступ к любым репозиториям кода и интерфейсам управления облаком. | |
| Предоставьте наглядное свидетельство того, что многофакторная проверка подлинности используется для защиты портала администрирования, который используется для управления всеми записями службы доменных имен (DNS) и обслуживания. | |
| Обнаружение и предотвращение вторжений (НЕОБЯЗАТЕЛЬНО): Дополнительный кредит будет вознагражден за выполнение следующих элементов управления | Предоставьте наглядное свидетельство того, что системы обнаружения и предотвращения вторжений (IDPS) развернуты по периметру область сред. |
| Предоставьте демонстрируемые доказательства того, что подписи IDPS хранятся в актуальном состоянии (в течение 24 часов). | |
| Предоставьте наглядное свидетельство того, что поставщики удостоверений настроены для поддержки проверки TLS всего входящего веб-трафика. | |
| Предоставьте наглядное свидетельство того, что idps настроен для мониторинга всех потоков входящего трафика. | |
| Предоставьте наглядное подтверждение того, что idps настроен для мониторинга всех исходящих потоков трафика. | |
| Ведение журнала событий безопасности | Предоставьте документацию по политике для рекомендаций и процедур, которые управляют ведением журнала событий безопасности. |
| Предоставьте наглядное свидетельство, показывающее, что ведение журнала событий безопасности настроено во всех примерах системных компонентов для регистрации следующих событий: Доступ пользователя к системным компонентам и приложению, Все действия, выполняемые пользователем с высоким уровнем привилегий, Недопустимые попытки логического доступа Создание или изменение привилегированной учетной записи, незаконное изменение журнала событий, Отключение средств безопасности (например, защита от вредоносных программ или ведение журнала событий), ведение журнала защиты от вредоносных программ (например, обновления, обнаружение вредоносных программ и сбои сканирования)., события IDPS и WAF, если настроено | |
| Предоставьте наглядное подтверждение того, что зарегистрированные события безопасности содержат следующие минимальные сведения: Пользователь, Тип события, Дата и время, Индикаторы успеха или сбоя, Метка, которая идентифицирует затронутую систему. | |
| Предоставьте наглядное свидетельство того, что все выборки системных компонентов синхронизированы по времени с тем же основным и вторичным серверами. | |
| Предоставление демонстрируемого доказательства использования общедоступных систем о том, что журналы событий безопасности отправляются в централизованное решение для ведения журнала, не в пределах сети периметра. | |
| Предоставьте наглядные доказательства того, что решение централизованного ведения журнала защищено от несанкционированного изменения данных ведения журнала. | |
| Предоставьте наглядное свидетельство того, что данные журнала событий безопасности немедленно доступны как минимум за 30 дней, а журналы событий безопасности хранятся в течение 90 дней. | |
| Проверки журналов событий безопасности | Предоставьте документацию по политикам, которые регулируют методы и процедуры проверки журналов. |
| Предоставьте наглядное свидетельство того, что журналы ежедневно проверяются людьми или автоматическими средствами для выявления потенциальных событий безопасности. | |
| Предоставьте наглядные доказательства того, что потенциальные события безопасности и аномалии исследуются и устраняются. | |
| Оповещения | Предоставьте документацию по политике, которая регулирует методы и процедуры оповещений о событиях безопасности. |
| Предоставление наглядного доказательства того, что оповещения активируются для немедленного рассмотрения следующих типов событий безопасности: создание или изменение привилегированной учетной записи, события вирусов или вредоносных программ, изменение журнала событий, idps или события WAF | |
| Предоставьте наглядные доказательства того, что сотрудники всегда доступны в течение всего дня, каждый день для реагирования на оповещения системы безопасности. | |
| Управление рисками | Предоставьте демонстрируемые доказательства того, что установлен формальный процесс управления рисками информационной безопасности. |
| Предоставьте наглядные доказательства того, что официальная оценка риска проводится как минимум раз в год. | |
| Предоставьте наглядные доказательства того, что оценка рисков информационной безопасности включает угрозы, уязвимости или эквиваленты. | |
| Предоставьте наглядные доказательства того, что оценка риска информационной безопасности включает в себя влияние, матрицу риска вероятности или эквивалент. | |
| Предоставьте наглядные доказательства того, что оценка рисков информационной безопасности включает регистр рисков и план лечения. | |
| Реагирование на инциденты | Укажите план реагирования на инциденты безопасности (IRP). |
| Предоставьте наглядные доказательства того, что IRP безопасности включает документированные процессы коммуникации, чтобы обеспечить своевременное уведомление ключевых заинтересованных лиц, таких как платежные бренды и приобретатели, регулирующие органы, надзорные органы, директора и клиенты. | |
| Предоставьте наглядные доказательства того, что все члены группы реагирования на инциденты прошли ежегодное обучение или упражнение в таблице. | |
| Предоставьте наглядные доказательства того, что IRP безопасности обновляется на основе извлеченных уроков или организационных изменений. |
Безопасность и конфиденциальность обработки данных
Данные, передаваемые между пользователем приложения, службами-посредниками и системами независимого поставщика программного обеспечения, должны быть защищены с помощью шифрования через TLS-подключение, поддерживающее как минимум TLS версии 1.1. См.приложение A.
Если приложение получает и хранит данные Microsoft 365, вам потребуется реализовать схему шифрования хранилища данных, которая соответствует спецификации, определенной в приложении Б.
Элементы управления
| Семейство элементов управления | Controls |
|---|---|
| Передаваемые данные | Предоставление демонстрационных доказательств того, что конфигурация TLS соответствует или превышает требования к шифрованию в соответствии с требованиями к конфигурации профиля TLS. |
| Предоставьте наглядное свидетельство того, что сжатие TLS отключено во всех общедоступных службах, обрабатывающих веб-запросы. | |
| Предоставьте наглядное свидетельство того, что для всех сайтов включена строгая безопасность транспорта TLS HTTP и настроено значение >= 15552000. | |
| Неактивные данные | Предоставьте наглядное подтверждение того, что неактивные данные шифруются в соответствии с требованиями к профилю шифрования, используя такие алгоритмы шифрования, как AES, Blowfish, TDES и 128-разрядные и 256-разрядные ключи шифрования. |
| Предоставьте наглядное свидетельство того, что хэш-функция или проверка подлинности сообщений (HMAC-SHA1) используется только для защиты неактивных данных в соответствии с требованиями к профилю шифрования. | |
| Предоставьте список всех сохраненных данных, включая расположение хранилища и шифрование, используемое для защиты данных. | |
| Хранение и реализация данных | Предоставьте наглядное подтверждение того, что официально установлен утвержденный и документируемый период хранения данных. |
| Предоставьте наглядное подтверждение того, что сохраненные данные соответствуют определенному сроку хранения. | |
| Предоставьте наглядное подтверждение того, что существуют процессы для безопасного удаления данных по истечении срока хранения. | |
| Управление доступом к данным | Предоставьте список всех лиц, имеющих доступ к данным или ключам шифрования, включая бизнес-обоснование. |
| Предоставьте демонстрационные доказательства того, что выборки, имеющие доступ к данным или ключам шифрования, были официально утверждены, с подробными сведениями о привилегиях, необходимых для их работы. | |
| Предоставьте демонстрационные доказательства того, что выборка пользователей, имеющих доступ к данным или ключам шифрования, имеет только привилегии, включенные в утверждение. | |
| Укажите список всех сторонних поставщиков, которым предоставляется доступ к данным клиентов. | |
| Предоставьте наглядное подтверждение того, что все третьи стороны, использующие данные клиентов, имеют соглашения об обмене. | |
| GDPR (если применимо) | Предоставьте документированную процедуру запроса на доступ к субъекту (SAR) и предоставьте доказательства того, что субъекты данных могут создавать SAR. |
| Предоставьте наглядное свидетельство того, что вы можете определить все расположения данных субъектов данных при реагировании на SAR. | |
| Вы сохраняете уведомление о конфиденциальности, которое должно содержать сведения о компании (имя, адрес и т. д.). | |
| Вы ведете уведомление о конфиденциальности, которое должно объяснять типы обрабатываемых персональных данных. | |
| Вы ведете уведомление о конфиденциальности, которое должно объяснять законность обработки персональных данных | |
| Вы сохраняете уведомление о конфиденциальности, в которых подробно описаны права субъекта данных: право на получение информации, право на доступ со стороны субъекта данных, право на удаление, право на ограничение обработки, право на переносимость данных, право на возражение, права на автоматическое принятие решений, включая профилирование. | |
| Вы ведете уведомление о конфиденциальности, которое должно объяснить, как долго будут храниться персональные данные. |
Необязательная проверка внешних платформ соответствия требованиям
Хотя это не обязательно, если в настоящее время вы соответствуете требованиям ISO 27001, PCI DSS или SOC2, вы можете использовать эти сертификации для удовлетворения некоторых элементов управления сертификацией Microsoft 365. Аналитики сертификации попытаются согласовать существующие внешние платформы безопасности со спецификацией сертификации Microsoft 365. Однако если в вспомогательной документации не удается убедиться, что элементы управления сертификацией Microsoft 365 были оценены как часть аудита и оценки внешних платформ безопасности, вам потребуется предоставить дополнительные доказательства наличия указанных элементов управления.
Документация должна надлежащим образом продемонстрировать, что среда область для сертификации Microsoft 365 была включена в область этих внешних платформ безопасности. Проверка этих платформ безопасности будет выполняться путем принятия подтверждения действительных сертификатов, проведенных авторитетными внешними сторонними компаниями. Эти авторитетные компании должны быть членами международных органов аккредитации для соответствующих программ соответствия. См. статью Стандарты сертификации и соответствия ISO для ISO 27001 и квалифицированных оценщиков безопасности (QSA) для PCI DSS.
В следующей таблице перечислены внешние платформы и документация, необходимые аналитикам сертификации в рамках этого процесса проверки.
| Standard | Требования |
|---|---|
| ISO 27001 | Потребуется общедоступная версия заявления о применимости (SOA) и копия выданного сертификата ISO 27001. SOA суммирует вашу позицию по каждому из 114 элементов управления информационной безопасностью и будет использоваться для определения исключения элементов управления, которые не удовлетворительно подробно описаны в сертификате ISO 27001. Если это не удается определить, просмотрив общедоступную версию SOA, аналитику может потребоваться доступ к полной soA, если ISO 27001 будет использоваться для проверки некоторых элементов управления спецификации сертификации Microsoft 365. Помимо проверки область деятельности по оценке ISO 27001, аналитики также подтвердят действительность аудиторской компании, как описано выше. |
| PCI DSS | Необходимо предоставить допустимый документ по аттестации соответствия требованиям уровня 1 (AOC), четко определяющий компоненты область приложения и системы. AOC для самостоятельной оценки не будет приниматься в качестве доказательства рекомендаций по обеспечению безопасности собраний. AOC будет использоваться для определения того, какие из элементов управления спецификации сертификации Microsoft 365 были оценены и подтверждены в рамках оценки PCI DSS. |
| SOC 2; | Отчет SOC 2 (тип I или II) должен быть текущим (выданным в течение последних 15 месяцев и объявленным периодом времени, начатым в течение последних 27 месяцев), который должен использоваться в качестве доказательства соответствия любому из элементов управления оценкой в рамках этой спецификации сертификации Microsoft 365. |
Если внешние платформы безопасности включены в аттестацию издателя, аналитики по сертификации должны будут проверка допустимость этих платформ соответствия безопасности в рамках оценки сертификации Microsoft 365.
| Платформа | Дополнительные сведения |
|---|---|
| ISO 27001 | Приложение В. Сбор доказательств — дельты для ISO 27001. |
| PCI DSS | Приложение D. Сбор доказательств — разностные значения для PCI DSS. |
| SOC 2; | Приложение Е. Сбор доказательств — разностные значения для SOC 2. |
Примечание.
Хотя упомянутые выше внешние стандарты безопасности и платформы могут быть представлены в качестве доказательства соответствия некоторым из элементов управления сертификацией Microsoft 365, прохождение сертификации Microsoft 365 не означает, что вы успешно пройдете аудит на соответствие этим стандартам и платформам. Спецификация сертификации Microsoft 365 — это лишь небольшое подмножество этих стандартов и платформ безопасности, что позволяет корпорации Майкрософт получить уровень уверенности в отношении вашего состояния безопасности.
Требования к использованию внешних платформ соответствия требованиям
✓ Среда поддержки приложений и надстроек и любые вспомогательные бизнес-процессы должны быть включены в область любых поддерживаемых внешних платформ соответствия безопасности и должны быть четко указаны в документации.
✓ Поддерживаемые внешние платформы соответствия требованиям безопасности должны быть актуальными, то есть в течение последних 12 месяцев (или в течение 15 месяцев, если в настоящее время проводится переоценка и могут быть предоставлены доказательства).
✓ Поддерживаемые внешние платформы соответствия требованиям безопасности должны выполняться независимой аккредитованной компанией.
Приложение 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
*Демилитаризованная зона — это физическая или логическая промежуточная сеть, которая взаимодействует напрямую с внешними или непригодными сетями, сохраняя внутреннюю частную сеть узла отдельной и изолированной.
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;
Безопасность транспортного уровня.