Сертификация Microsoft 365 — пример руководства по подтверждению

Обзор

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

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

В сертификации есть два раздела, которые требуют отправки:

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

Совет

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

Структура

Этот документ напрямую сопоставляется с элементами управления, которые будут представлены во время сертификации в Центре партнеров. Инструкции, приведенные в этом документе, подробно описаны ниже.

• Домен безопасности. Три домена безопасности, в которые сгруппированы все элементы управления: безопасность приложений, операционная безопасность и безопасность данных и конфиденциальность.
• Элемент управления: = Описание действия оценки. Эти элемент управления и связанные номера (No.) взяты непосредственно из контрольного списка сертификации Microsoft 365.
• Намерение: = намерение о том, почему элемент управления безопасностью включен в программу, и конкретный риск, который он направлен на снижение. Надежда заключается в том, что эта информация будет предоставлять поставщиков программного обеспечения с обоснованием, стоящим за контролем, чтобы лучше понять типы доказательств, которые должны быть собраны, и что ISV должны обратить внимание и иметь осведомленность и понимание при создании своих доказательств.
• Примеры рекомендаций по подтверждению. Это позволяет независимым поставщикам программного обеспечения четко видеть примеры типов доказательств, которые могут быть использованы аналитиком по сертификации, который будет использовать его для уверенного определения того, что элемент управления установлен и поддерживается. Это ни в коем случае не является исчерпывающим по своей природе.
• Пример доказательства. = В этом разделе приведены примеры снимков экрана и изображений потенциальных доказательств, полученных для каждого из элементов управления в электронной таблице контрольного списка сертификации Microsoft 365, специально для областей операционной безопасности и безопасности данных и конфиденциальности (вкладки в электронной таблице). Обратите внимание на любую информацию с красными стрелками и полями в примерах, чтобы помочь вам понять требования, необходимые для выполнения любого элемента управления.

Домен безопасности: безопасность приложений

Элемент управления 1 — элемент управления 16:

Элементы управления доменом Application Security могут быть удовлетворены отчетом о тестировании на проникновение, выданным в течение последних 12 месяцев, в котором показано, что в вашем приложении нет выдающихся уязвимостей. Единственной необходимой отправкой является чистый отчет авторитетной независимой компании.

Домен безопасности: операционная безопасность и безопасная разработка

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

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

Элемент управления No 1. Предоставьте документацию по политике, которая регулирует антивирусные методики и процедуры.

• Намерение. Цель этого элемента управления — оценить понимание поставщиком программного обеспечения проблем, с которыми они сталкиваются при рассмотрении угрозы от компьютерных вирусов. Создавая и используя отраслевые рекомендации по разработке политики и процессов антивирусной защиты, поставщик программного обеспечения предоставляет ресурс с учетом возможностей своей организации для снижения рисков, с которыми сталкиваются вредоносные программы, перечисляя рекомендации по обнаружению и устранению вирусов, а также дает свидетельство того, что документированные политики предоставляют рекомендации по безопасности для организации и ее сотрудников. Документируя политику и процедуру развертывания параметров защиты от вредоносных программ, поставщик программного обеспечения обеспечивает согласованное развертывание и обслуживание этой технологии для снижения риска вредоносных программ в среде.
• Примеры рекомендаций по подтверждению. Предоставьте копию политики антивирусной или антивредоносной программы с подробными сведениями о процессах и процедурах, реализованных в вашей инфраструктуре для продвижения рекомендаций по антивирусной и вредоносной программе. Пример свидетельства
• Пример доказательства:

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

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

• Намерение. Важно, чтобы в вашей среде была запущена антивирусная программа (AV) (или защита от вредоносных программ), чтобы защититься от рисков кибербезопасности, о которых вы можете знать или не знать, так как потенциально опасные атаки увеличиваются, как в сложности, так и в цифрах. Развертывание AV во всех системных компонентах, которые поддерживают его использование, поможет снизить некоторые риски внедрения вредоносных программ в среду. Требуется только одна конечная точка, чтобы быть незащищенной, чтобы потенциально предоставить вектор атаки для группы действий, чтобы закрепиться в среде. Поэтому AV следует использовать в качестве одного из нескольких уровней защиты для защиты от этой угрозы.
• Примеры рекомендаций по подтверждению. Чтобы доказать, что активный экземпляр av запущен в оцениваемой среде. Предоставьте снимок экрана для каждого устройства в примере, которое поддерживает использование антивирусной программы, на котором показано, как выполняется антивирусный процесс, активна антивирусная программа или если у вас есть централизованный консоль управления для антивирусной защиты, вы можете продемонстрировать его из этого консоль управления. Если используется консоль управления, убедитесь на снимке экрана, что устройства подключены и работают.
• Пример 1. Снимок экрана ниже взят из Центр безопасности Azure. На нем показано, что на виртуальной машине развернуто расширение защиты от вредоносных программ с именем "MSPGPRODAZUR01".

• Пример доказательства 2

Снимок экрана ниже взят с Windows 10 устройств, показывающий, что для имени узла CLARANET-SBU-WM включена защита в режиме реального времени.

Элемент управления No 3. Предоставление демонстрируемого доказательства того, что антивирусные сигнатуры актуальны во всех средах (в течение 1 дня).

• Намерение. Сотни тысяч новых вредоносных программ и потенциально нежелательных приложений (PUA) выявляются каждый день. Чтобы обеспечить адекватную защиту от недавно выпущенных вредоносных программ, сигнатуры av необходимо регулярно обновлять, чтобы учитывать новые выпущенные вредоносные программы.
• Этот элемент управления существует, чтобы гарантировать, что ISV принял во внимание безопасность среды и влияние, которое устаревший av может оказать на безопасность.
• Примеры рекомендаций по подтверждению. Предоставьте файлы журнала антивирусной защиты с каждого устройства, в котором показано, что обновления применяются ежедневно.
• Пример доказательства. На следующем снимку экрана показано, Microsoft Defender обновление по крайней мере ежедневно, показывая "Событие 2000, Защитник Windows", которое является обновлением. Отображается имя узла, показывающее, что оно было взято из область системы CLARANET-SBU-WM.

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

Элемент управления No 4. Предоставьте демонстрационные доказательства того, что антивирусная программа настроена для проверки доступа или периодического сканирования всех образцов системных компонентов.

Примечание: Если проверка при доступе не включена, необходимо включить как минимум ежедневное сканирование и alerting_ обязательно _be.

• Намерение. Цель этого элемента управления заключается в том, чтобы обеспечить быстрое выявление вредоносных программ, чтобы свести к минимуму влияние, которое это может оказать на среду. Если проверка доступа выполняется в сочетании с автоматической блокировкой вредоносных программ, это поможет остановить заражение вредоносными программами, известными антивирусной программе. Если сканирование при доступе нежелательно из-за риска ложноположительных срабатываний, вызывающих сбои службы, необходимо реализовать подходящие ежедневные (или более) механизмы сканирования и оповещения, чтобы обеспечить своевременный ответ на заражение вредоносными программами, чтобы свести к минимуму ущерб.
• Примеры рекомендаций по подтверждению. Предоставьте снимок экрана для каждого устройства в примере, которое поддерживает антивирусную программу, показывая, что антивирусная программа работает на устройстве и настроена для проверки при доступе (сканирование в режиме реального времени) или предоставьте снимок экрана, показывающий, что периодическое сканирование включено для ежедневного сканирования, настроено оповещение и дата последней проверки для каждого устройства в образце.
• Пример доказательства. На следующем снимок экрана показана включенная защита в режиме реального времени для узла CLARANET-SBU-WM.

Элемент управления No 5. Предоставьте демонстрационные доказательства того, что антивирус настроен для автоматической блокировки вредоносных программ или карантина и оповещения во всех примерах системных компонентов.

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

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

• Пример доказательства 1. На следующем снимку экрана показано, что для узла CLARANET-SBU-WM настроена защита в режиме реального времени для антивирусной программы Microsoft Defender. Как говорится в параметре, это позволяет обнаружить и остановить установку или запуск вредоносных программ на устройстве.

Элемент управления No 6. Предоставьте демонстрацию подтверждения утверждения приложений перед развертыванием.

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

• Примеры рекомендаций по подтверждению. Можно предоставить свидетельство, показывающее, что процесс утверждения выполняется. Это может быть предоставлено с подписанными документами, отслеживанием в системах управления изменениями или с помощью azure DevOps или JIRA для отслеживания этих запросов и авторизации.

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

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

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

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

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

Примечание: На этом снимку экрана показан документ. Ожидается, что поставщики программного обеспечения будут предоставлять доступ к фактическому вспомогательному документу, а не предоставлять снимок экрана.

Элемент управления No 8. Предоставьте вспомогательную документацию о том, что программное обеспечение для управления приложениями настроено в соответствии с определенными механизмами управления приложениями.

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

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

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

Примечание: На этом снимку экрана показан документ. Ожидается, что поставщики программного обеспечения будут предоставлять доступ к фактическому вспомогательному документу, а не предоставлять снимок экрана.

Элемент управления No 9. Предоставление демонстрируемого доказательства того, что управление приложениями настроено так, как описано во всех примерах системных компонентов.

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

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

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

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

На следующем снимку экрана показана среда Microsoft 365 и компьютеры, включенные в область, применяемые к объекту групповой политики "Параметры компьютера домена".

На этом последнем снимке экрана показан область сервер DBServer1, который находится в подразделении на снимке экрана выше.

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

Быстрое выявление и устранение уязвимостей системы безопасности помогает свести к минимуму риски, связанные с компрометацией среды или приложения группой действий. Управление исправлениями разделено на два раздела: ранжирование рисков и исправление. Эти три элемента управления охватывают выявление уязвимостей системы безопасности и их ранжирование в соответствии с риском, который они представляют.

Эта группа управления безопасностью находится в область для сред размещения "платформа как услуга" (PaaS), так как сторонние библиотеки программного обеспечения приложений и надстроек должны быть исправлены на основе ранжирования рисков.

Элемент управления No 10. Предоставьте документацию по политике, которая определяет, как выявляются новые уязвимости безопасности и присваиваются оценки риска.

• Намерение. Цель этого элемента управления заключается в том, чтобы иметь вспомогательную документацию, чтобы обеспечить быстрое выявление уязвимостей системы безопасности, чтобы уменьшить возможность использования этих уязвимостей группами действий. Необходимо создать надежный механизм для выявления уязвимостей, охватывающих все системные компоненты, используемые организациями; например, операционные системы (Windows Server, Ubuntu и т. д.), приложения (Tomcat, MS Exchange, SolarWinds и т. д.), зависимости кода (AngularJS, jQuery и т. д.). Организациям необходимо не только обеспечить своевременное выявление уязвимостей в активе, но и соответствующим образом ранжировать все уязвимости, чтобы обеспечить, чтобы исправление выполнялось в течение подходящего периода времени на основе риска, который представляет уязвимость.

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

• Примеры рекомендаций по подтверждению: предоставьте поддержку документации (не снимки экрана)

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

Примечание: На этом снимку экрана показан документ политики или процесса. Ожидается, что поставщики программного обеспечения будут совместно использовать документацию по поддерживаемым политикам и процедурам, а не предоставлять screenshot._

Элемент управления No 11. Предоставление доказательств того, как выявляются новые уязвимости системы безопасности.

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

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

Примечание Если вы используете Nessus, это потребуется регулярно выполнять для быстрого выявления уязвимостей. Мы рекомендуем по крайней мере еженедельно.

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

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

• Намерение. Исправление должно основываться на риске, чем рискнее уязвимость, тем быстрее ее необходимо исправить. Ранжирование рисков для выявленных уязвимостей является неотъемлемой частью этого процесса. Цель этого элемента управления — обеспечить задокументированный процесс ранжирования рисков, который выполняется, чтобы все выявленные уязвимости были надлежащим образом ранжированы на основе риска. Организации обычно используют рейтинг CVSS (Common Vulnerability Scoring System), предоставляемый поставщиками или исследователями безопасности. Если организация полагается на CVSS, рекомендуется включить в процесс механизм повторного ранжирования, позволяющий организации изменить рейтинг на основе внутренней оценки рисков. Иногда уязвимость может не быть приложением из-за того, как приложение было развернуто в среде. Например, может быть выпущена уязвимость Java, которая влияет на определенную библиотеку, используемую организацией.

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

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

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

Приведенные ниже элементы управления предназначены для элемента patching для управления исправлениями. Для обеспечения безопасной операционной среды приложения, надстройки и вспомогательные системы должны быть соответствующим образом исправлены. Необходимо управлять подходящим временем между идентификацией (или общедоступным выпуском) и установкой исправлений, чтобы уменьшить окно возможностей для использования уязвимости "группой действий". Сертификация Microsoft 365 не предусматривает "Окно исправлений", однако аналитики сертификации будут отклонять сроки, которые не являются разумными.

Эта группа управления безопасностью находится в область для сред размещения "платформа как услуга" (PaaS), так как сторонние библиотеки программного обеспечения приложений и надстроек должны быть исправлены на основе ранжирования рисков.

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

• Намерение. Управление исправлениями требуется для многих платформ соответствия безопасности, то есть PCI-DSS, ISO 27001, NIST (SP) 800-53. Важность правильного управления исправлениями не может быть подчеркнутой, так как это может исправить проблемы безопасности и функциональности в программном обеспечении, встроенном ПО и устранить уязвимости, что помогает сократить возможности для эксплуатации. Цель этого элемента управления заключается в том, чтобы свести к минимуму окно возможностей, которые группа действий должна использовать уязвимости, которые могут существовать в среде область.

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

• Пример свидетельства. Ниже приведен пример документа политики.

Примечание: На этом снимку экрана показан документ политики или процесса. Ожидается, что поставщики программного обеспечения будут делиться фактической документацией по политике или процедуре, а не просто предоставлять screenshot._

Элемент управления No 14. Предоставьте наглядное свидетельство того, что все тестируемые компоненты системы исправляются.

Примечание: Включите любое программное обеспечение или сторонние библиотеки.

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

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

• Пример доказательства. На следующем снимке экрана показано, что системный компонент область CLARANET-SBU-WM выполняет обновления Windows в соответствии с политикой исправления.

Примечание: Исправление всех область системных компонентов должно быть свидетельством. Сюда входят такие вещи, как; Обновления ОС, Обновления приложений и компонентов (i.e__.,_ Apache Tomcat, OpenSSL и т. д.), зависимости программного обеспечения (например, JQuery, AngularJS и т. д.) и т. д.

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

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

• Примеры рекомендаций по подтверждению. Предоставьте снимок экрана для каждого устройства в примере с версией операционной системы (включая имя сервера на снимке экрана). Кроме того, предоставьте сведения о том, что программные компоненты, работающие в среде, работают с поддерживаемыми версиями. Это можно сделать, предоставив выходные данные внутренних отчетов о проверке уязвимостей (включая проверку подлинности) и (или) выходные данные средств, которые проверка сторонних библиотек, таких как Snyk, Trivy или NPM Audit. Если выполняется только в PaaS, группы элементов управления исправлениями должны охватывать только исправления сторонних библиотек.

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

Примечание: Полный отчет должен быть предоставлен аналитикам сертификации.

• Пример свидетельства 2

На этом снимке экрана показано, что системный компонент CLARANET-SBU-WM в область работает в поддерживаемой версии Windows.

• Пример доказательства 3

На следующем снимку экрана приведены выходные данные Trivy , в которых полный отчет не содержит списка неподдерживаемых приложений.

Примечание: Полный отчет должен быть предоставлен аналитикам сертификации.

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

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

Элемент управления No 16. Предоставляет ежеквартальные отчеты об уязвимостях инфраструктуры и веб-приложений. Сканирование должно выполняться по всем общедоступным (IP-адресам и URL-адресам) и внутренним диапазонам IP-адресов.

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

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

• В отчете Метрики безопасности, озаглавленном "Руководство по метрикам безопасности 2020 года по соответствию PCI DSS", говорится, что "в среднем потребовалось 166 дней с момента обнаружения в организации уязвимостей, чтобы злоумышленник скомпрометировал систему. После компрометации злоумышленники имели доступ к конфиденциальным данным в среднем в течение 127 дней, поэтому этот контроль направлен на выявление потенциальной уязвимости системы безопасности в область среде.

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

• Пример доказательства. Пример доказательства будет предоставлять отчеты о проверке из используемого средства сканирования. Для проверки должны предоставляться отчеты о проверке каждого квартала. Сканирование должно включать все системные компоненты сред. каждая внутренняя подсеть и каждый общедоступный IP-адрес или URL-адрес, доступный для среды.

Элемент управления No 17. Предоставьте наглядное свидетельство того, что исправления уязвимостей, выявленных во время проверки уязвимостей, исправляются в соответствии с вашими документированными сроками исправления.

• Намерение. Сбой в выявлении, управлении и исправлении уязвимостей и неправильной конфигурации может повысить риск компрометации организации, что приведет к потенциальному нарушению данных. Правильная идентификация и устранение проблем рассматривается как важное значение для общего состояния безопасности и среды организации, что соответствует рекомендациям различных платформ безопасности для; Например, ISO 27001 и PCI DSS.

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

• Пример доказательства. На следующем снимке экрана показана проверка Nessus среды в область (один компьютер в этом примере с именем "THOR"), показывающая уязвимости 2 августа 2021 г.

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

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

Брандмауэры

Брандмауэры часто обеспечивают границу безопасности между доверенными (внутренняя сеть), ненадежными (Интернет) и полунадежными (DMZ) средами. Как правило, это первая линия защиты в рамках стратегии глубокой безопасности организации, предназначенная для управления потоками трафика для служб входящего и исходящего трафика, а также для блокирования нежелательного трафика. Эти устройства должны строго контролироваться, чтобы обеспечить их эффективную работу и обеспечить их некорректную настройку, которая может поставить под угрозу окружающую среду.

Элемент управления No 18. Предоставьте документацию по политике, которая регулирует методы и процедуры управления брандмауэром.

• Намерение. Брандмауэры являются важной первой линией защиты в многоуровневой стратегии безопасности (глубинной защиты), защищающей среды от менее доверенных сетевых зон. Брандмауэры обычно управляют потоками трафика на основе IP-адресов и протоколов и портов. Более функциональные брандмауэры также могут обеспечить дополнительную защиту на уровне приложений, проверяя трафик приложений для защиты от неправильного использования, уязвимостей и угроз на основе приложений, к которым осуществляется доступ. Эти средства защиты так же хороши, как и конфигурация брандмауэра, поэтому должны быть установлены надежные политики брандмауэра и процедуры поддержки, чтобы убедиться, что они настроены для обеспечения адекватной защиты внутренних ресурсов. Например, брандмауэр с правилом, разрешающим весь трафик из любого источника в любое назначение, просто выступает в качестве маршрутизатора.

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

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

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

• Намерение. Организации должны помнить о предоставленных поставщиком административных учетных данных по умолчанию, которые настраиваются во время настройки устройства или программного обеспечения. Учетные данные по умолчанию часто являются общедоступными для поставщиков и могут предоставить внешней группе действий возможность скомпрометировать среду. Например, простой поиск в Интернете учетных данных по умолчанию iDrac (интегрированный контроллер удаленного доступа Dell) выделит root::calvin в качестве имени пользователя и пароля по умолчанию. Это предоставит удаленный доступ к удаленному управлению сервером. Цель этого элемента управления — убедиться, что среды не подвержены атакам с помощью учетных данных поставщика по умолчанию, которые не были изменены во время усиления защиты устройства или приложения.

• Примеры рекомендаций по подтверждению

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

• Пример свидетельства

На приведенном ниже снимку экрана показано, что аналитик по сертификации увидит из недопустимого имени пользователя или пароля из брандмауэра WatchGuard.

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

• Намерение. Брандмауэры позволяют управлять трафиком между различными зонами сети с разными уровнями безопасности. Так как все среды подключены к Интернету, брандмауэры должны быть установлены на границе, то есть между Интернетом и средой в область. Кроме того, необходимо установить брандмауэры между менее доверенными сетями dmz (de-Militarized Zone) и внутренними доверенными сетями. DmZ обычно используются для обслуживания трафика из Интернета и поэтому являются целью атаки. При реализации dmz и использовании брандмауэра для управления потоками трафика компрометация DMZ не обязательно будет означать компрометацию внутренних доверенных сетей и корпоративных данных или данных клиентов. Необходимо обеспечить надлежащее ведение журналов и оповещений, чтобы помочь организациям быстро определить компрометацию, чтобы свести к минимуму возможность для группы действий дополнительно скомпрометировать внутренние доверенные сети. Цель этого элемента управления — обеспечить достаточный контроль между доверенными и менее доверенными сетями.

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

• Пример доказательства. Ниже показан снимок экрана брандмауэра WatchGuard, демонстрирующего две dmZ: одна для входящих служб (с именем DMZ), другая обслуживает jumpbox (узел Bastian).

Элемент управления 21. Предоставьте наглядное доказательство того, что весь открытый доступ прекращается в демилитаризованной зоне (DMZ).

• Намерение. Общедоступные ресурсы открыты для множества атак. Как уже обсуждалось выше, цель dmz заключается в сегментации менее доверенных сетей из доверенных внутренних сетей, которые могут содержать конфиденциальные данные. DmZ считается менее доверенным, так как существует большой риск того, что узлы, которые являются общедоступными, могут быть скомпрометированы внешними группами действий. Общедоступный доступ всегда должен завершаться в этих менее доверенных сетях, которые должным образом сегментированы брандмауэром для защиты внутренних ресурсов и данных. Цель этого элемента управления заключается в том, чтобы убедиться, что все открытые доступы в этих менее доверенных dmZ, как если бы ресурсы в доверенных внутренних сетях были общедоступными, компрометация этих ресурсов обеспечивает группе действий плацдарм в сети, где хранятся конфиденциальные данные.

• Примеры рекомендаций по подтверждению

• Для этого могут быть предоставлены конфигурации брандмауэра, в которых отображаются правила для входящего трафика и где эти правила завершаются, либо путем маршрутизации общедоступных IP-адресов к ресурсам, либо путем предоставления NAT (преобразование сетевых адресов) для входящего трафика.

• Пример свидетельства

На снимке экрана ниже приведены три правила для входа, каждое из которых показывает NAT для подсетей 10.0.3.x и 10.0.4.x, которые являются подсетями dmz

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

• Намерение. Так как брандмауэры являются защитным барьером между ненадежным трафиком и внутренними ресурсами, а также между сетями разных уровней доверия, брандмауэры должны быть настроены безопасно и обеспечить включение только трафика, необходимого для бизнес-операций. Если разрешить ненужный поток трафика или слишком разрешительный поток трафика, это может привести к недостаткам в защите на границе этих различных зон сети. Благодаря созданию надежного процесса утверждения для всех изменений брандмауэра снижается риск введения правила, которое представляет значительный риск для среды. Отчет verizon о расследовании нарушений безопасности данных за 2020 год подчеркивает, что "Ошибка", которая включает в себя неправильные настройки, является единственным типом действий, который постоянно увеличивается из года в год.

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

• Пример доказательства. На следующем снимок экрана показано, как изменение правила брандмауэра запрашивается и авторизоваться с помощью бумажного процесса. Это может быть достигнуто с помощью, например, DevOps или Jira.

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

• Намерение. Большинство брандмауэров будут обрабатывать правила в подходе сверху вниз, чтобы попытаться найти соответствующее правило. Если правило совпадает, будет применено действие этого правила, и вся дальнейшая обработка правил прекратится. Если соответствующие правила не найдены, трафик по умолчанию отклоняется. Цель этого элемента управления заключается в том, что если брандмауэр по умолчанию не сбрасывает трафик, если соответствующее правило не найдено, то база правил должна содержать правило "Запретить все" в конце списков брандмауэра ALL . Это необходимо для того, чтобы брандмауэр по умолчанию не переходил в состояние разрешения по умолчанию при обработке правил, таким образом разрешая трафик, который не был определен явным образом.

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

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

Следующая ссылка на Справочный центр WatchGuard: https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/policies/policies_about_c.html содержит следующие сведения:

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

• Намерение. Для предотвращения атак типа "злоумышленник в середине" административного трафика все неконсоляные административные интерфейсы должны поддерживать только надежное шифрование. Main целью этого элемента управления является защита учетных данных администратора при настройке подключения, не являющегося консолью. Кроме того, это также может помочь защититься от перехвата подключения, попытки воспроизведения административных функций для перенастройки устройства или в рамках рекогносцировки.

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

• Пример свидетельства. На приведенном ниже снимку экрана показаны выходные данные SSLScan для интерфейса веб-Администратор брандмауэра WatchGuard на TCP-порте 8080. Здесь показан протокол TLS версии 1.2 или более поздней версии с минимальным шифром шифрования AES-128bit.

Примечание. Брандмауэры WatchGuard также поддерживают административные функции, использующие SSH (TCP-порт 4118) и Диспетчер системы WatchGuard (TCP-порты 4105 & 4117). Кроме того, потребуется предоставить свидетельство об этих неконсолевых административных интерфейсах.

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

• Намерение. Со временем возникает риск ползучести конфигурации в системных компонентах с область среде. Это часто может привести к небезопасности или неправильной конфигурации, что может увеличить риск компрометации среды. Сползание конфигурации может быть введено по многим причинам, например, временные изменения для устранения неполадок, временные изменения для нерегламентированных функциональных изменений, чтобы ввести быстрые исправления проблем, которые иногда могут быть чрезмерно разрешительными из-за давления, связанного с внедрением быстрого исправления. Например, можно ввести временное правило брандмауэра "Разрешить все", чтобы устранить неотложную проблему. Цель этого элемента управления двояко: во-первых, определить, в каких случаях имеются неправильные настройки, которые могут привести к небезопасности, и, во-вторых, чтобы помочь определить правила брандмауэра, которые больше не нужны и, следовательно, могут быть удалены, т. е. если служба была прекращена, но правило брандмауэра осталось позади.

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

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

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

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

развертывание Брандмауэр веб-приложений (WAF) в решении необязательно. Если используется WAF, это будет считаться дополнительными кредитами для матрицы оценки в домене безопасности "Операционная безопасность". WaFs могут проверять веб-трафик для фильтрации и мониторинга веб-трафика между Интернетом и опубликованными веб-приложениями для выявления атак, относящихся к веб-приложениям. Веб-приложения могут страдать от множества атак, характерных для веб-приложений, таких как внедрение кода SQL (SQLi), межсайтовые скрипты (XSS), подделка межсайтовых запросов (CSRF/XSRF) и т. д., а WAFs предназначены для защиты от этих типов вредоносных полезных данных, чтобы защитить веб-приложения от атак и потенциального компрометации.

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

• Намерение. Этот элемент управления используется для подтверждения того, что WAF имеется для всех входящих веб-подключений и что он настроен на блокировку или оповещение о вредоносном трафике. Чтобы обеспечить дополнительный уровень защиты веб-трафика, wafs необходимо настроить для всех входящих веб-подключений. В противном случае внешние группы действий могут обойти WAFs, предназначенные для обеспечения этого дополнительного уровня защиты. Если WAF не настроен для активной блокировки вредоносного трафика, WAF должен иметь возможность немедленно предупреждать сотрудников, которые могут быстро реагировать на потенциальный вредоносный трафик, чтобы обеспечить безопасность среды и остановить атаки.

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

• Пример доказательства. На следующих снимках экрана показана включенная политика Contoso Production Шлюз приложений Azure WAF и настроен режим "Предотвращение", который будет активно удалять вредоносный трафик.

На приведенном ниже снимку экрана показана ip-конфигурация внешнего интерфейса

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

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

На следующем снимок экрана показан Contoso_AppGW_CoreRules, показывающий, что это предназначено для службы api.contoso.com.

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

• Намерение. Важно настроить WAF для поддержки разгрузки SSL, иначе WAF не сможет проверить трафик HTTPS. Так как эти среды должны поддерживать трафик HTTPS, это важная функция для WAF, обеспечивая выявление и остановку вредоносных полезных данных в трафике HTTPS.

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

• Пример доказательства. В Шлюз приложений Azure конфигурации разгрузки SSL-прослушивателя с поддержкой SSL см. страницу Общие сведения о завершении TLS и сквозном tls с Шлюз приложений Документация Майкрософт. На следующем снимку экрана показана настройка для рабочей Шлюз приложений Azure Contoso.

Элемент управления 28: "Предоставьте наглядное свидетельство того, что WAF защищает от некоторых или всех следующих классов уязвимостей в соответствии с набором основных правил OWASP (3.0 или 3.1):

• проблемы с протоколом и кодировкой,

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

• атаки обхода файлов и путей,

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

• атаки на удаленное выполнение кода,

• Атаки с внедрением PHP,

• атаки на межсайтовые скрипты,

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

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

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

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

• Пример доказательства. На следующем снимку экрана показано, что политика Contoso Production Шлюз приложений Azure WAF настроена для проверки на соответствие набору основных правил OWASP версии 3.2.

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

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

Элемент управления 29. Предоставьте документацию по политике, которая управляет процессами управления изменениями.

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

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

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

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

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

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

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

• Пример доказательства. На следующем снимку экрана показана подписка Azure для тестовой среды Contoso.

На следующем снимку экрана показана отдельная подписка Azure для рабочей среды Contoso.

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

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

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

• Примеры рекомендаций по подтверждению. Доказательства можно предоставить путем предоставления общего доступа к снимкам экрана выходных данных того же SQL-запроса в рабочей базе данных (отредактировать любую конфиденциальную информацию) и базе данных разработки или тестирования. Выходные данные одних и того же команд должны создавать разные наборы данных. Там, где хранятся файлы, просмотр содержимого папок в обеих средах также должен демонстрировать различные наборы данных.

• Пример доказательства. На следующем снимке экрана показаны первые 3 записи (для отправки доказательств укажите первые 20) из рабочей базы данных.

На следующем снимку экрана показан тот же запрос из базы данных разработки с разными записями.

Это показывает, что наборы данных отличаются.

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

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

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

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

В приведенных ниже билетах отображаются сведения, которые были заданы или добавлены в билет при его пути к разрешению.

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

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

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

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

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

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

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

• Пример свидетельства. На приведенном ниже снимку экрана показан пример билета Jira, в котором показано, что изменение должно быть авторизовано перед реализацией и утверждением кем-либо, кроме разработчика или инициатора запроса. Вы увидите, что изменения утверждены кем-то с соответствующими полномочиями. Справа был подписан DP после завершения.

В приведенном ниже запросе вы увидите, что после завершения изменения было выполнено и указано, что задание завершено и закрыто.

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

Организации, участвующие в разработке программного обеспечения, часто сталкиваются с конкурирующими приоритетами между безопасностью и давлением TTM (время на рынок), однако реализация действий, связанных с безопасностью на протяжении жизненного цикла разработки программного обеспечения (SDLC), может не только сэкономить деньги, но и сэкономить время. Если безопасность остается запоздалой мыслью, проблемы обычно выявляются только на этапе тестирования (DSLC), что часто может быть более трудоемким и дорогостоящим решением. Цель этого раздела безопасности — обеспечить соблюдение безопасных методов разработки программного обеспечения, чтобы снизить риск внедрения ошибок кода в разрабатываемое программное обеспечение. Кроме того, в этом разделе содержатся некоторые элементы управления, помогающие безопасному развертыванию программного обеспечения.

Элемент управления 34. Предоставление политик и процедур, которые поддерживают безопасную разработку и развертывание программного обеспечения, включая рекомендации по безопасному написанию кода для распространенных классов уязвимостей, таких как OWASP Top 10 или SANS Top 25 CWE.

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

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

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

Примечание: На этих снимках экрана показан документ по безопасной разработке программного обеспечения. Ожидается, что поставщики программного обеспечения поделиться фактической вспомогательной документацией, а не просто предоставить снимок экрана.

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

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

• Примеры рекомендаций по подтверждению. Предоставьте доказательства того, что код проходит рецензирование и должен быть авторизован, прежде чем его можно будет применить в рабочей среде. Это может быть через экспорт билетов на изменения, демонстрируя, что проверки кода были выполнены и изменения авторизованы, или это может быть через программное обеспечение для проверки кода, например Crucible (https://www.atlassian.com/software/crucible).

• Пример свидетельства

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

На рисунке ниже показано, что проверка кода была назначена другому разработчику, как показано в выделенном разделе в правой части изображения ниже. В левой части можно увидеть, что рецензент кода проверил код и получил состояние "ПЕРЕДАННАЯ ПРОВЕРКА КОДА".

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

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

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

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

Элемент управления 36. Предоставьте наглядное свидетельство того, что разработчики ежегодно проходят обучение по безопасной разработке программного обеспечения.

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

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

• Пример доказательства. Ниже приведено сообщение электронной почты с просьбой о том, чтобы сотрудники команды DevOps были зарегистрированы в OWASP Top Ten Training Annual Training

Ниже показано, что обучение было запрошено с бизнес-обоснованием и утверждением. Затем следуют снимки экрана, сделанные из обучения, и запись о завершении, показывающая, что человек завершил ежегодное обучение.

Элемент управления 37. Предоставление демонстрируемого доказательства того, что репозитории кода защищены с помощью многофакторной проверки подлинности (MFA).

• Намерение. Если группа действий может получить доступ к базе кода программного обеспечения и изменить ее, она может внести уязвимости, backdoor или вредоносный код в базу кода и, следовательно, в приложение. Было несколько случаев этого уже, с, вероятно, наиболее широко освещаемым является атака Программы-шантажиста NotPetya, которая, как сообщается, заражена через скомпрометированное обновление украинского налогового программного обеспечения под названием M.E.Doc (см . раздел Что неPetya).

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

• Пример доказательства. На следующем снимку экрана показано, что MFA включена для всех 8 пользователей GitLab.

Элемент управления 38. Предоставьте наглядное подтверждение наличия элементов управления доступом для защиты репозиториев кода.

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

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

• Пример доказательства. На следующем снимке экрана показаны члены проекта "Клиенты" в GitLab, который является "Клиентским порталом" Contoso. Как видно на снимке экрана, пользователи имеют разные "роли", чтобы ограничить доступ к проекту.

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

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

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

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

• BeyondTrust каждый год создает "Отчет об уязвимостях Майкрософт", который анализирует уязвимости системы безопасности Майкрософт за предыдущий год и подробно описывает процент этих уязвимостей, которые зависят от учетной записи пользователя с правами администратора. В недавней записи блога "Новый отчет об уязвимостях Майкрософт показывает 48%-е увеличение уязвимостей & как они могут быть устранены с наименьшими привилегиями", 90% критических уязвимостей в Интернете Обозреватель, 85% критических уязвимостей в Microsoft Edge и 100% критических уязвимостей в Microsoft Outlook были бы устранены путем удаления прав администратора. Для поддержки безопасного управления учетными записями организации должны обеспечить наличие вспомогательных политик и процедур, которые повышают рекомендации по безопасности, и следовать ей для устранения этих угроз.

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

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

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

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

• Намерение. Хотя это становится все менее популярным, по-прежнему существуют случаи, когда группы действий могут использовать учетные данные пользователя по умолчанию и хорошо задокументированные учетные данные для компрометации компонентов рабочей системы. Популярным примером этого является dell iDRAC (интегрированный контроллер удаленного доступа Dell). Эту систему можно использовать для удаленного управления сервером Dell, который может использоваться группой действий для получения контроля над операционной системой сервера. Учетные данные по умолчанию root::calvin задокументированы и часто могут использоваться группами действий для получения доступа к системам, используемым организациями. Цель этого элемента управления — убедиться, что эти учетные данные по умолчанию отключены или удалены.

• Примеры рекомендаций по подтверждению. Существуют различные способы сбора доказательств для поддержки этого элемента управления. Снимок экрана настроенных пользователей во всех системных компонентах может помочь, то есть снимки экрана файлов Linux /etc/shadow и /etc/passwd помогут продемонстрировать, отключены ли учетные записи. Обратите внимание, что файл /etc/shadow потребуется для демонстрации того, что учетные записи действительно отключены, замечая, что хэш паролей начинается с недопустимого символа, например "!", указывающего, что пароль непригоден для использования. Совет состоит в том, чтобы отключить только несколько символов пароля и отредактировать остальные. Другие варианты — это сеансы скринсхинга, в которых проверяющий мог вручную попробовать учетные данные по умолчанию. Например, в приведенном выше обсуждении на dell iDRAC проверяющий должен попытаться пройти проверку подлинности по всем интерфейсам Dell iDRAC, используя учетные данные по умолчанию.

• Пример доказательства. На следующем снимке экрана показаны учетные записи пользователей, настроенные для системного компонента область CLARANET-SBU-WM. Отображает несколько учетных записей по умолчанию; Администратор, DefaultAccount и Гость, однако на следующих снимках экрана показано, что эти учетные записи отключены.

На следующем снимке экрана показано, что учетная запись администратора отключена в область системном компоненте CLARANET-SBU-WM.

На следующем снимке экрана показано, что учетная запись гостя отключена в область системном компоненте CLARANET-SBU-WM.

На следующем снимке экрана показано, что defaultAccount отключен в системном компоненте область CLARANET-SBU-WM.

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

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

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

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

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

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

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

• Примеры рекомендаций по подтверждению. Доказательства должны быть двукратными. Во-первых, снимок экрана или экспорт файла, показывающий "последний вход" всех учетных записей пользователей в среде область. Это могут быть локальные учетные записи, а также учетные записи в централизованной службе каталогов, например Microsoft Entra ID. Это покажет, что учетные записи старше 3 месяцев не включены. Во-вторых, свидетельство о процессе ежеквартальной проверки, которое может быть документальным свидетельством выполнения задачи в рамках ADO (Azure DevOps) или JIRA-билетов, или с помощью бумажных записей, которые должны быть подписаны.

• Пример свидетельства. На первом снимке экрана показаны выходные данные скрипта, который выполняется ежеквартально для просмотра атрибута последнего входа для пользователей в Microsoft Entra ID.

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

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

• Минимальная длина пароля : 8 символов

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

• Журнал паролей не менее 5 паролей

• Принудительное использование надежного пароля

• Намерение. Как уже обсуждалось, учетные данные пользователя часто являются целью атаки со стороны групп действий, пытающихся получить доступ к среде организации. Политика надежных паролей заключается в том, чтобы попытаться заставить пользователей выбирать надежные пароли, чтобы снизить вероятность того, что группы действий смогут выполнить их метод подбора. Цель добавления "или других подходящих мер по устранению рисков" заключается в том, чтобы признать, что организации могут реализовать другие меры безопасности для защиты учетных данных пользователей на основе отраслевых событий, таких как "Специальная публикация NIST 800-63B".

• Примеры рекомендаций по подтверждению. Свидетельство для демонстрации надежной политики паролей может быть в виде снимка экрана параметров организации, групповая политика объектной или локальной политики безопасности "Политики учетных записей à политика паролей" и "Политики учетных записей à политика блокировки учетных записей". Доказательства зависят от используемых технологий; То есть для Linux это может быть файл конфигурации /etc/pam.d/common-password, для BitBucket — раздел "Политики проверки подлинности" на портале Администратор (https://support.atlassian.com/security-and-access-policies/docs/manage-your-password-policy/) и т. д.

• Пример доказательства. В приведенном ниже свидетельстве показана политика паролей, настроенная в рамках локальной политики безопасности область системного компонента CLARANET-SBU-WM.

На снимке экрана ниже показаны параметры блокировки учетных записей для брандмауэра WatchGuard.

Ниже приведен пример минимальной длины парольной фразы для брандмауэра WatchGaurd.

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

• Намерение. Цель этого элемента управления — подотчетность. Выпустив пользователей с собственными уникальными учетными записями пользователей, пользователи будут отвечать за свои действия, так как действия пользователя могут отслеживаться отдельным пользователем.

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

• Пример доказательства. На следующем снимке экрана показаны учетные записи пользователей, настроенные для системного компонента область CLARANET-SBU-WM.

На следующем снимке экрана показано, что учетная запись администратора отключена в область системном компоненте CLARANET-SBU-WM.

На следующем снимке экрана показано, что учетная запись гостя отключена в область системном компоненте CLARANET-SBU-WM.

На следующем снимке экрана показано, что defaultAccount отключен в системном компоненте область CLARANET-SBU-WM.

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

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

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

• Например: в Azure группа "Владельцы" должна быть ограничена, поэтому она должна быть задокументирована и в ней должно быть назначено ограниченное число людей. Другим примером может быть ограниченное число сотрудников с возможностью внесения изменений в код. Группа может быть настроена с этой привилегией с сотрудниками, которые считаются нуждающимися в этом разрешении. Это должно быть задокументировано, чтобы аналитик сертификации смог перекрестно ссылаться на документ с настроенными группами и т. д.

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

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

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

• Намерение. Учетные записи служб часто предназначены для групп действий, так как они часто настраиваются с повышенными привилегиями. Эти учетные записи могут не следовать стандартным политикам паролей, так как срок действия паролей учетных записей службы часто нарушает функциональные возможности. Таким образом, они могут быть настроены с использованием слабых паролей или паролей, которые повторно используются в организации. Другой потенциальной проблемой, особенно в среде Windows, может быть то, что операционная система кэширует хэш паролей. Это может быть большой проблемой, если либо: учетная запись службы настроена в службе каталогов, так как эта учетная запись может использоваться для доступа в нескольких системах с настроенным уровнем привилегий или учетная запись службы является локальной, вероятность того, что одна и та же учетная запись или пароль будут использоваться в нескольких системах в среде. Описанные выше проблемы могут привести к тому, что группа действий получает доступ к дополнительным системам в среде и может привести к дальнейшему повышению привилегий и/или боковому смещению. Таким образом, цель состоит в том, чтобы обеспечить правильную защиту учетных записей служб, чтобы защитить их от переключения группы действий, или путем ограничения риска в случае компрометации одной из этих учетных записей службы.

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

• Ограничение учетных записей набором компьютеров в Active Directory,

• Настройка учетной записи для интерактивного входа запрещена.

• Установка чрезвычайно сложного пароля,

• Для Active Directory включите флаг "Учетная запись является конфиденциальной и не может быть делегирована". Эти методы рассматриваются в следующей статье Сегментация и общий каталог Active Directory для среды данных владельца карточки.

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

На следующем снимок экрана показан выбранный параметр "Учетная запись является конфиденциальной и подключение должно быть делегировано" в учетной записи службы "_Prod учетной записи службы SQL".

На следующем снимке экрана показано, что учетная запись службы "_Prod учетная запись службы SQL" заблокирована на SQL Server и может выполнять вход только на этом сервере.

На следующем снимке экрана показано, что учетная запись службы "_Prod учетная запись службы SQL" разрешена только для входа в качестве службы.

Элемент управления 47. Предоставление демонстрируемого доказательства того, что MFA настроена для всех подключений удаленного доступа и всех административных интерфейсов, не относящихся к консоли.

Термины, определенные как:

• Удаленный доступ — обычно это относится к технологиям, используемым для доступа к вспомогательной среде. Например, УДАЛЕННЫй доступ IPSec VPN, SSL VPN или Jumpbox/Bastian Host.

• Неконсольные административные интерфейсы . Как правило, это относится к сетевым административным подключениям к системным компонентам. Это может быть удаленный рабочий стол, SSH или веб-интерфейс.

• Намерение. Цель этого элемента управления — обеспечить защиту от подбора привилегированных учетных записей и учетных записей с безопасным доступом к среде. Предоставляя многофакторную проверку подлинности (MFA), скомпрометированный пароль по-прежнему должен быть защищен от успешного входа, так как механизм MFA по-прежнему должен быть защищен. Это помогает гарантировать, что все действия по доступу и администрирование выполняются только авторизованными и доверенными сотрудниками.

• Примеры рекомендаций по подтверждению. Доказательства должны показывать, что MFA включена во всех технологиях, которые соответствуют указанным выше категориям. Это может быть снимок экрана, показывающий, что MFA включена на уровне системы. На уровне системы нам нужны доказательства того, что она включена для всех пользователей, а не только для примера учетной записи с включенной MFA. Если технология откатывается к решению MFA, нам нужны доказательства, чтобы продемонстрировать, что она включена и используется. Что подразумевается под этим: Если технология настроена для проверки подлинности Radius, которая указывает на поставщика MFA, необходимо также доказать, что сервер Radius Server, на который он указывает, является решением MFA и что учетные записи настроены для его использования.

• Пример свидетельства 1. На следующих снимках экрана показаны области проверки подлинности, настроенные в Pulse Secure, которые используются для удаленного доступа к среде. Проверка подлинности отключается службой SaaS Duo для поддержки MFA.

На этом снимке экрана показано, что включен дополнительный сервер проверки подлинности, указывающий на "Duo-LDAP" для области проверки подлинности "Duo — маршрут по умолчанию".

На этом заключительном снимке экрана показана конфигурация для сервера проверки подлинности Duo-LDAP, которая показывает, что это указывает на службу SaaS Duo для MFA.

Пример доказательства 2. На следующих снимках экрана показано, что для всех пользователей Azure включена MFA.

Примечание. Необходимо предоставить доказательства для всех подключений, не относящихся к консоли, чтобы продемонстрировать, что для них включена многофакторная проверка подлинности. Например, если вы используете протокол RDP или SSH к серверам или другим системным компонентам (то есть брандмауэрам).

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

Термины, определенные как:

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

• Интерфейсы управления облаком . Если часть или вся среда размещается в поставщике облачных служб (CSP), сюда входит административный интерфейс для управления облаком.

• Намерение. Цель этого элемента управления — обеспечить надлежащее шифрование всего административного трафика для защиты от атак типа "злоумышленник в середине".

• Примеры рекомендаций по подтверждению. Доказательства можно предоставить на снимках экрана, показывающих параметры шифрования для интерфейсов удаленного доступа, RDP, SSH и веб-Администратор. Для интерфейсов веб-Администратор можно использовать сканер Qualys SSL Labs (если он является общедоступным, то есть интерфейсы управления облаком, репозитории кода SaaS или VPN-подключения SSL).

• Пример доказательства. В приведенном ниже свидетельстве показан уровень шифрования RDP для "Webserver01", настроенный с параметром "Высокий уровень". Как видно из текста справки, в этом случае используется строгое 128-разрядное шифрование (это самый высокий уровень для Microsoft Windows RDP).

Приведенные ниже данные также показывают, что безопасность транспорта RDP настроена для использования TLS 1.0 в "Webserver01" (что является самым высоким для Windows Server).

Элемент управления 49. Предоставьте наглядное свидетельство того, что MFA используется для защиты портала администрирования, который используется для управления всеми записями службы доменных имен (DNS) и ведения его.

• Намерение. Если группа вредоносных действий может получить доступ к общедоступным записям DNS, существует риск изменения URL-адресов, используемых приложением, или если файл манифеста указывает на ввод вредоносного кода или направление пользовательского трафика в конечную точку под управлением субъектов. Это может привести к потере данных пользователя или заражению вредоносными программами или программами-шантажистами в базе пользователей приложения.

• Примеры рекомендаций по подтверждению. Предоставьте доказательства, демонстрирующие, что общедоступные административные порталы DNS защищены С помощью MFA. Даже если общедоступный DNS размещается на серверах в среде область (то есть контролируется и управляется организацией), возможно, где зарегистрировано доменное имя на портале Администратор, а записи DNS были "Управляемыми", чтобы указать DNS-серверы на вашу собственную инфраструктуру. В этом случае в административном интерфейсе регистратора доменов должна быть включена MFA, если записи DNS доменов можно изменить. Должен быть предоставлен снимок экрана, показывающий, что административный интерфейс включен для MFA на уровне системы (то есть все привилегированные учетные записи).

• Пример доказательства. На следующем снимку экрана показано, как contoso.com DNS управляется в Microsoft Azure for Contoso Corporation.

Примечание: IP-адреса являются частными адресами RFC 1918 и не являются общедоступными. Это только для демонстрационных целей.

На следующих снимках экрана показано, что для всех пользователей Azure включена MFA.

Обнаружение и предотвращение вторжений (необязательно)

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

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

Элемент управления 50. Предоставление демонстрируемого доказательства того, что системы обнаружения и предотвращения вторжений (IDPS) развернуты по периметру область сред.

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

• Примеры рекомендаций по подтверждению. Должно быть предоставлено свидетельство, которое показывает, что поставщики удостоверений установлены по периметру. Это может быть непосредственно на брандмауэре при запуске брандмауэра NextGen, или датчики IDPS развертывания, настроенные на зеркало переключение портов, чтобы убедиться, что развернутые датчики видят весь трафик. Если используются датчики IDPS, может потребоваться предоставить дополнительные доказательства, чтобы продемонстрировать, что датчики могут видеть все внешние потоки трафика.

• Пример доказательства. На следующем снимок экрана показана функция IDPS, включенная в брандмауэре WatchGuard.

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

Элемент управления 51. Предоставьте доказательства того, что подписи IDPS сохраняются в актуальном состоянии (в течение 24 часов).

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

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

• Пример доказательства. Хотя на этом снимок экрана не показано, что подписи IDPS были обновлены в течение последних 24 часов, на нем показано, что установлена последняя версия, которая была выпущена неделю назад (доказательства, собранные в 18__thмае). В сочетании с приведенным ниже снимкам экрана показано, что сигнатуры будут обновлены в течение 24 часов.

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

• Намерение. Так как IDPS использует сигнатуры, он должен иметь возможность проверять все потоки трафика для выявления трафика атаки. Трафик TLS шифруется, поэтому idps не сможет должным образом проверить трафик. Это критически важно для трафика HTTPS, так как существует множество угроз, которые являются общими для веб-служб. Цель этого элемента управления заключается в том, чтобы убедиться, что зашифрованные потоки трафика также могут проверяться на наличие idps.

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

• Пример свидетельства: на этом снимку экрана показаны правила HTTPS в брандмауэре

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

На следующем снимку экрана показано, как действие прокси-сервера применяется к правилу "Inbound_Bot_Traffic", которое используется для включения проверки содержимого.

На следующем снимку экрана показана включенная проверка содержимого.

Элемент управления 53. Предоставление демонстрируемого доказательства того, что поставщики удостоверений настроены для мониторинга всех потоков входящего трафика.

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

• Примеры рекомендаций по подтверждению. Чтобы продемонстрировать мониторинг всех потоков входящего трафика, необходимо предоставить свидетельство на снимках экрана. Это может быть брандмауэр NextGen, показывающий, что для idps включены все входящие правила, или с помощью датчиков IDPS и демонстрации того, что весь трафик настроен для доступа к датчику IDPS.

• Пример доказательства. На этом снимку экрана показано, что поставщики удостоверений настроены во всех правилах (политиках) брандмауэра WatchGuard.

Элемент управления 54. Предоставление демонстрируемого доказательства того, что поставщики удостоверений настроены для мониторинга всех потоков исходящего трафика.

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

• Примеры рекомендаций по подтверждению. Чтобы продемонстрировать мониторинг всех исходящих потоков трафика, необходимо предоставить свидетельство на снимках экрана. Это может быть брандмауэр NextGen, показывающий, что все исходящие правила включены для idps, или с помощью датчиков IDPS и демонстрации того, что весь трафик настроен для доступа к датчику IDPS.

• Пример доказательства. На этом снимку экрана показано, что поставщики удостоверений настроены во всех правилах (политиках) брандмауэра WatchGuard.

• Пример доказательства 2. Azure предлагает поставщиков удостоверений через сторонние приложения. В приведенном ниже примере сбор пакетов Netwatcher используется для захвата пакетов и используется вместе с Suricata, которая является инструментом Open-Source IDS.

Объединяя сбор пакетов, предоставляемый Наблюдатель за сетями и инструментами IDS с открытым кодом, такими как Suricata, можно выполнять обнаружение сетевых вторжений для широкого спектра угроз. На рисунке ниже показан интерфейс Suricata.

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

На приведенном ниже рисунке показано, как отслеживать настройку поставщика удостоверений для стороннего программного обеспечения Netwatcher и Suricata с помощью Sentinel SIEM/SOAR.

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

На рисунке ниже показано, как вывести список всех конфигураций обнаружения вторжений с помощью ИНТЕРФЕЙСА командной строки

• Пример свидетельства 4. Azure недавно начал предлагать поставщики удостоверений с именем Брандмауэр Azure Premium, что позволит настраивать TLS, аналитику угроз, IDPS с помощью политик. Однако обратите внимание, что для разгрузки входящего трафика SSL потребуется использовать Front Door или шлюз приложений, так как Брандмауэр Azure Premium не поддерживает idps для входящих SSL-подключений.

В приведенном ниже примере параметры premium по умолчанию использовались для настройки правил политики и проверки TLS, режима IDPS, аналитики угроз включены вместе с защитой виртуальной сети.

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

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

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

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

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

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

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

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

• Доступ пользователей к системным компонентам и приложению

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

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

• Создание или изменение привилегированной учетной записи

• Изменение журнала событий

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

• Ведение журналов защиты от вредоносных программ, таких как обновления, обнаружение вредоносных программ и сбои сканирования

• События IDPS и WAF, если настроены

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

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

• Пример свидетельства 1. На следующем снимке экрана показаны параметры конфигурации одного из примеров устройств с именем "VICTIM1-WINDOWS". В параметрах отображаются различные параметры аудита, включенные в параметрах "Локальная политика безопасности  Локальные политики  Политика аудита".

На следующем снимке экрана показано событие, в котором пользователь очистил журнал событий с одного из образцов устройств с именем "VICTIM1-WINDOWS".

На этом последнем снимке экрана показано сообщение журнала, отображаемое в решении централизованного ведения журнала.

Примечание. Снимки экрана требуются для всех образцов системных компонентов ИДОЛЖНЫ свидетельствовать обо всех событиях безопасности, описанных выше.

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

• Пользователь

• Тип события

• дата и время;

• Индикаторы успеха или сбоя

• Метка, идентифицирующая затронутую систему

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

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

• Пример доказательства. На следующем снимке экрана показаны сведения о событиях безопасности в Windows Просмотр событий из область системного компонента "SEGSVR02".

Примечание. Снимки экрана требуются для всех образцов системных компонентов И ДОЛЖНЫ свидетельствовать обо всех событиях безопасности, описанных в элементе управления выше. вполне вероятно, что доказательства, собранные для указанного выше элемента управления, также будут соответствовать этому элементу управления, предоставляя достаточные сведения о ведении журнала.

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

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

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

• Пример свидетельства. На этой схеме показана используемая топология синхронизации времени.

На следующем снимку экрана показан элемент WatchGuard, настроенный в качестве NTP-сервера и указывающий на time.windows.com в качестве источника времени.

На этом заключительном снимке экрана показан системный компонент область. Параметр CLARANET-SBU-WM настроен для NTP, чтобы он указывал на основной сервер, который является брандмауэром WatchGuard (10.0.1.1).

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

• Намерение. Цель этого элемента управления заключается в обеспечении логического или физического разделения между dmz и конечной точкой ведения журнала. Поскольку периметр является общедоступным, он подвергается внешним группам действий и, следовательно, подвергается большему риску, чем другие компоненты в среде. Если компонент dmz будет скомпрометирован, необходимо сохранить целостность данных ведения журнала, чтобы не только предотвратить незаконное изменение журналов группой действий, чтобы скрыть компрометацию, но и помочь в любых судебных исследованиях, которые могут потребоваться. Путем ведения журнала в системах за пределами ДМЗ средства управления безопасностью, используемые для ограничения трафика из DMZ в эти системы безопасности, должны помочь защитить их от вредоносных действий и попыток незаконного изменения.

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

• Пример доказательства. Системы периметра Contoso используют NXLog для доставки файлов журналов. На следующем снимке экрана показана служба nxlog, запущенная в перемычки DMZ DESKTOP-7S65PN, которая используется для управления всеми серверами DMZ.

На следующем снимок экрана показан фрагмент из файла nxlog.conf, показывающий, что назначением является внутренний сборщик журналов в подсети приложения версии 10.0.1.250, который используется для отправки в AlienVault.

Следующий URL-адрес для NXLog (https://nxlog.co/documentation/nxlog-user-guide/modes.html) показывает, что доставка журналов осуществляется в режиме реального времени с помощью следующего извлечения:

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

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

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

• Пример доказательства. Аутсорсинговая soC Contoso использует AlienVault в качестве централизованного инструментария SIEM. AlienVault был выкуплен AT&T в 2018 году и теперь идет USM Anywhere. На следующей веб-странице (https://cybersecurity.att.com/documentation/usm-anywhere/deployment-guide/admin/usm-anywhere-data-security.htm) описывается, как USM Anywhere защищает данные от несанкционированного изменения. По следующей ссылке (https://cybersecurity.att.com/documentation/usm-appliance/raw-logs/raw-log-management.htm) показано, как продукт USM Anywhere также обеспечивает целостность архивных журналов.

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

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

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

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

• Пример доказательства 1. На следующих снимках экрана показано, что журналы стоимостью 30 дней доступны в AlienVault.

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

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

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

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

Проверка журнала событий безопасности

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

Элемент управления 62. Предоставьте документацию по политике, которая регулирует методы и процедуры проверки журналов.

• Намерение. В отчете IBM, озаглавленном "Стоимость отчета о нарушении данных за 2020 год", подчеркивается, что среднее время для выявления и сдерживания утечки данных может занять 280 дней. Это больше, если нарушение относится к группе вредоносных действий, о которой сообщается как 315 дней. Учитывая, что средняя стоимость утечки данных составляет миллионы долларов, очень важно сократить жизненный цикл утечки данных, чтобы не только свести к минимуму окно подверженности данным, но и сократить сроки, которые группа действий должна изымать данные из среды. Уменьшая это окно, организации могут снизить общие затраты на утечку данных.

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

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

• Пример доказательства. Ниже приведена выписка из политики или процедуры проверки журнала.

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

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

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

• Примеры рекомендаций по подтверждению. Как правило, доказательства предоставляются на снимке экрана или на снимке экрана, демонстрируя проведение проверок журналов. Это может быть с помощью форм, которые заполняются каждый день, или путем билета JIRA или DevOps с соответствующими комментариями, которые публикуются, чтобы показать, что это выполняется ежедневно. Например, можно создать еженедельный запрос JIRA "Daily Log Review W/C 26 июня 2021 г." каждый день, когда кто-то публикует результаты ежедневной проверки журнала. Если какие-либо аномалии помечены, это можно задокументировать в этом же билете, чтобы продемонстрировать следующий элемент управления в одном JIRA.

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

• Пример доказательства. Компания Contoso использует стороннего поставщика SOC, Claranet Cyber Security, для корреляции журналов и проверок. AlienVault используется поставщиком SOC, который имеет возможности предоставления автоматического анализа журналов для аномальных журналов и связанных событий, которые могут подчеркнуть потенциальное событие безопасности. На следующих трех снимках экрана показаны правила корреляции в AlienVault.

На этом первом снимку экрана показано, где пользователь был добавлен в группу "Администраторы домена".

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

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

На следующем снимку экрана показано, что запрос автоматически создается в средстве ServiceNow SOC, активируя приведенное выше правило.

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

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

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

• Пример доказательства. На следующем снимку экрана показано, как оповещение системы безопасности отслеживается в ServiceNow с помощью SOC Claranet Cyber Security MDR (Managed Detection and Response).

На следующем снимку экрана показано подтверждение того, что это было разрешено Дэвидом Эштоном @Contoso с помощью обновления на портале клиента ServiceNow.

Оповещение о событиях безопасности

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

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

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

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

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

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

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

• Создание или изменение привилегированной учетной записи

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

• Изменение журнала событий

• События IDPS или WAF, если настроены

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

• Примеры рекомендаций по подтверждению. Доказательства должны быть предоставлены снимками экрана конфигурации оповещений И свидетельством полученных оповещений. На снимках экрана конфигурации должна отображаться логика, которая активирует оповещения, и способ их отправки. Оповещения можно отправлять через SMS, Email, каналы Teams, каналы Slack и т. д.

• Пример доказательства. Компания Contoso использует стороннюю SOC, предоставляемую Claranet Cyber Security. В следующем примере показано, что оповещение в AlienVault, используемое SOC, настроено для отправки оповещений участнику команды SOC Дэну Тернеру из Claranet Cyber Security.

На следующем снимку экрана показано, как Дэн получает оповещение.

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

• Намерение. Важно как можно скорее обходить оповещения системы безопасности, чтобы ограничить воздействие на окружающую среду и (или) данные. Сотрудники всегда должны быть доступны для реагирования на оповещения и проведения критически важных следственных действий в случае выявления нарушений. Чем быстрее запускается этот процесс, тем быстрее можно сдержать инцидент безопасности для защиты данных или ограничения влияния брещи.
• Пример рекомендаций по подтверждению. Необходимо предоставить свидетельство, которое показывает, что сотрудники могут 24 часа в сутки реагировать на оповещения системы безопасности. Это может быть с ротой по вызову.
• Пример доказательства. На следующем снимке экрана показана рота по вызову за декабрь 2020 г. для Contoso. Команда SOC по кибербезопасности Claranet будет оповещать членов группы по вызову Contoso.

Управление рисками информационной безопасности

Управление рисками информационной безопасности — это важная деятельность, которую все организации должны выполнять по крайней мере ежегодно. Организации должны понимать свои угрозы и риски, чтобы эффективно устранять эти угрозы. Без эффективного управления рисками организации могут внедрять рекомендации по обеспечению безопасности в областях, которые они считают важными, и, следовательно, инвестировать ресурсы, время и деньги в эти области, когда другие угрозы гораздо более вероятны и, следовательно, должны быть устранены. Эффективное управление рисками поможет организациям сосредоточиться на рисках, представляющих наибольшую угрозу для бизнеса. Это должно осуществляться ежегодно по мере того, как ландшафт безопасности постоянно меняется, и поэтому угрозы и риски могут изменяться сверхурочными. Хорошим примером этого является COVID-19, в котором наблюдается массовый рост фишинговых атак и массовое (и быстрое) развертывание удаленной работы для сотен или тысяч работников.

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

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

Важно, чтобы оценка рисков была включена в состав рисков информационной безопасности, а не только общих "бизнес- рисков".

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

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

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

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

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

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

На этих двух снимках экрана показаны минуты собрания с двух встреч по оценке рисков.

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

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

Примечание: Вместо снимка экрана необходимо предоставить полную документацию по оценке рисков.

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

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

Примечание: Вместо снимка экрана следует указать полный assessment_ _document__ation риска.

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

• Намерение. Организациям необходимо эффективно управлять рисками. Это необходимо должным образом отслеживать, чтобы либо обеспечить запись одного из четырех применяемых методов лечения риска. К методам лечения риска относятся:
• Избегайте и завершайте работу. Компания может определить, что стоимость работы с риском больше, чем доход, полученный от службы. Таким образом, компания может прекратить выполнение службы.
• Передача и совместное использование. Компания может передать риск третьей стороне, переместив обработку стороннему поставщику.
• Принять, разрешить и сохранить . Компания может решить, что риск является приемлемым. Это во многом зависит от аппетита бизнеса к риску и может отличаться в зависимости от организации.
• Обрабатывать, устранять и изменять . Компания решает реализовать средства управления устранением рисков, чтобы снизить риск до приемлемого уровня.
• Цель этого контроля заключается в том, чтобы получить уверенность в том, что организация выполняет оценку рисков и действует на этом соответствующим образом.
• Примеры рекомендаций по подтверждению. Необходимо предоставить план обработки рисков или регистр рисков (или что-то эквивалентное), чтобы продемонстрировать, что процесс оценки рисков выполняется должным образом.
• Пример доказательства. Ниже приведен регистр рисков для Contoso.

Примечание: Вместо снимка экрана необходимо предоставить полную документацию по оценке рисков.

На следующем снимках экрана показан план лечения рисков.

Реагирование на инциденты безопасности

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

В докладе IBM, озаглавленном "Стоимость отчета о нарушении данных за 2020 год", подчеркивается, что в среднем время, затраченное на сдерживание нарушения, составило 73 дня. Кроме того, в том же докладе определяется самая большая экономия затрат для организаций, которые пострадали от нарушения, была готовность к реагированию на инциденты, обеспечивая в среднем 2 000 000 долл. США.

Организациям следует следовать рекомендациям по обеспечению соответствия требованиям к безопасности, используя отраслевые стандартные платформы, такие как ISO 27001, NIST, SOC 2, PCI DSS и т. д.

Элемент управления 73. Укажите план реагирования на инциденты безопасности (IRP).

• Намерение. Как уже обсуждалось, целью этого элемента управления является требование официально задокументированного плана реагирования на инциденты. Это поможет более эффективно управлять реагированием на инциденты безопасности, что в конечном итоге может ограничить риск потери данных организации и снизить затраты на компрометацию.
• Примеры рекомендаций по подтверждению. Укажите полную версию плана или процедуры реагирования на инциденты. Сюда следует включить документированные коммуникационные процессы, которые рассматриваются в следующем элементе управления.
• Пример доказательства. На приведенном ниже снимку экрана показано начало плана реагирования на инциденты компании Contoso. В рамках отправки доказательств необходимо предоставить весь план реагирования на инциденты.

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

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

• Намерение. У организаций могут быть обязательства по уведомлению о нарушениях в зависимости от страны или стран, в которых они работают (например, Общий регламент по защите данных; GDPR) или на основе предлагаемых функциональных возможностей (например, PCI DSS, если платежные данные обрабатываются). Сбой своевременного уведомления может иметь серьезные последствия, поэтому, чтобы обеспечить выполнение обязательств по уведомлению, планы реагирования на инциденты должны включать процесс коммуникации, включая общение со всеми заинтересованными лицами, процессы коммуникации со средствами массовой информации и которые могут и не могут говорить со средствами массовой информации.
• Примеры рекомендаций по подтверждению. Предоставьте полную версию плана или процедуры реагирования на инциденты, которая должна включать раздел, охватывающий процесс передачи данных.
• Пример доказательства. На следующем снимку экрана показана выписка из плана реагирования на инциденты, показывающая процесс взаимодействия.

Контроль 75. Предоставьте наглядное доказательство того, что все члены группы реагирования на инциденты прошли ежегодное обучение или упражнение в таблице.

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

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

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

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

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

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

• Намерение. Со временем план реагирования на инциденты (IRP) должен развиваться на основе организационных изменений или уроков, извлеченных при принятии IRP. Изменения в операционной среде могут потребовать внесения изменений в IRP, так как угрозы могут измениться или могут измениться нормативные требования. Кроме того, по мере того как выполняются настольные упражнения и фактические реагирования на инциденты безопасности, часто можно определить области IRP, которые можно улучшить. Это необходимо встроить в план, и цель этого элемента управления заключается в том, чтобы обеспечить включение этого процесса в IRP.

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

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

В журнале изменений IRP отображается обновление, внесенное на задней стороне упражнения, выполненного в июле 2021 года.

Домен безопасности: безопасность и конфиденциальность обработки данных

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

Передаваемые данные

В связи с требованиями к подключению приложений и надстроек, разработанных Microsoft 365, обмен данными будет осуществляться через общедоступные сети, а именно Через Интернет. По этой причине передаваемые данные должны быть надлежащим образом защищены. В этом разделе рассматривается защита передачи данных через Интернет.

Элемент управления 1. Предоставление демонстрируемого доказательства того, что конфигурация TLS соответствует или превышает требования к шифрованию в соответствии с требованиями к конфигурации профиля TLS.

• Намерение. Цель этого элемента управления — обеспечить безопасную передачу данных Microsoft 365, используемых вашей организацией. Конфигурация профиля TLS определяет конкретные требования TLS, чтобы обеспечить безопасность трафика от атак "злоумышленник в середине".

• Примеры рекомендаций по подтверждению. Самый простой способ доказать это — запустить средство проверки СЕРВЕРА SSL Qualys для всех веб-прослушивателей, включая все, которые выполняются на нестандартных портах.

• Не забудьте установить флажок "Не показывать результаты на досках", чтобы запретить добавление URL-адреса на веб-сайт.

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

• Пример доказательства. На приведенном ниже снимку экрана показаны результаты для веб-прослушивателя www.clara.net:443 .

Примечание. Аналитики сертификации проверят полные выходные данные, чтобы убедиться, что выполнены все требования к конфигурации профиля TLS (предоставьте снимки экрана с выходными данными полного сканирования). Depending_ на _what доказательства были предоставлены, аналитики могут запустить собственное сканирование Qualys.

• Пример свидетельства 2. На следующем снимку экрана показано, что в хранилище настроен протокол TLS 1.2.

Примечание: Этот снимок экрана сам по себе не сможет удовлетворить это требование.

• Пример свидетельства 3. На следующих снимках экрана показано, что TLS версии 1.3 включен только на сервере.

В этом примере разделы реестра используются для отключения или включения протокола путем настройки значений следующим образом:

Двоичный файл: 0 - выкл. 1 - вкл.

Шестнадцатеричный: 0x00000000 - off 0xffffffff - on

Обратите внимание : не используйте эту методологию, если вы не понимаете ее, так как мы (Майкрософт) не несем ответственности за использование или выполнение этого примера, а также за любые последствия, которые ее использование может иметь для ваших систем. Здесь можно просто проиллюстрировать другой способ показать, включен или отключен протокол TLS.

Примечание. Эти снимки экрана сами по себе не смогут удовлетворить это требование.

Элемент управления 2. Предоставление демонстрируемого доказательства того, что сжатие TLS отключено во всех общедоступных службах, обрабатывающих веб-запросы.

• Намерение: существует определенная уязвимость TLS CRIME (CVE-2012-4929), которая влияет на сжатие TLS. По этой причине отраслевые рекомендации по отключению этой функции.

• Примеры рекомендаций по подтверждению. Это может быть свидетельством с помощью инструмента Qualys SSL Labs.

• Пример доказательства. На следующем снимку экрана показано это с помощью инструмента Qualys SSL Labs.

Элемент управления 3. Предоставление демонстрируемого доказательства того, что для всех сайтов включена строгая безопасность транспорта TLS HTTP и настроено значение >= 15552000.

• Намерение: HTTP Strict Transport Security (HSTS) — это механизм безопасности, предназначенный для защиты веб-сайтов от атак типа "злоумышленник в середине", путем принудительного подключения TLS с помощью поля заголовка ответа HTTPS с именем Strict-Transport-Security.

• Примеры рекомендаций по подтверждению. Это может быть свидетельством с помощью средства Qualys SSL Labs или других средств и надстроек веб-браузера.

• Пример доказательства. На следующем снимке экрана показано это с помощью надстройки веб-браузера с именем "Шпион заголовков HTTP" для веб-сайта www.microsoft.com .

Неактивные данные

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

Элемент управления 4. Предоставление демонстрируемого доказательства того, что неактивные данные шифруются в соответствии с требованиями к профилю шифрования, используя такие алгоритмы шифрования, как AES, Blowfish, TDES и ключи шифрования размером 128-разрядных и 256-разрядных.

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

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

• Пример доказательства. На следующем снимку экрана показано, что В базе данных Contoso включен TDE (прозрачное шифрование данных). На втором снимок экрана показана страница документации Майкрософт "Прозрачное шифрование данных для База данных SQL, Управляемый экземпляр SQL и Azure Synapse Analytics", на которой показано, что шифрование AES 256 используется для TDE Azure.

• Пример свидетельства 2. На следующем снимке экрана показано, как служба хранилища Azure, настроенная с шифрованием больших двоичных объектов и файлов. На следующем снимку экрана показана страница Документация Майкрософт "Шифрование службы хранилища Azure для неактивных данных", на которой показано, что служба хранилища Azure использует AES-256 для шифрования.

Элемент управления 5. Предоставление демонстрируемого доказательства того, что хэш-функция или проверка подлинности сообщений (HMAC-SHA1) используется только для защиты неактивных данных в соответствии с требованиями профиля шифрования.

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

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

• Пример доказательства. Компания Contoso использует функциональность хэширования в своем приложении. На снимках экрана ниже показано, что SHA256 используется как часть функции хэширования.

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

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

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

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

Хранение и реализация данных

Если поставщики программного обеспечения потребляют и хранят данные Microsoft 365, это будет подвержено риску компрометации данных, если группа действий скомпрометировать среду поставщика программного обеспечения. Чтобы свести к минимуму этот риск, организации должны хранить только данные, необходимые им для служб доставки, а не данные, которые "могут" пригодиться в будущем. Кроме того, данные должны храниться только до тех пор, пока это необходимо для предоставления служб, для которые были записаны данные. Хранение данных должно быть определено и доведено до сведения пользователей. После того как данные превышают определенный срок хранения, их необходимо безопасно удалить, чтобы данные не могли быть восстановлены или восстановлены.

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

• Намерение. Задокументированная и соблюдаемая политика хранения важна не только для выполнения некоторых юридических обязательств, например законодательства о конфиденциальности данных, такого как, помимо прочего, Общего регламента по защите данных (GDPR) ЕС и Закона о защите данных (UK DPA 2018), но и для ограничения риска организации. Понимая требования к данным организации и время, необходимое для выполнения бизнесом своих функций, организации могут обеспечить надлежащее удаление данных по истечении срока их использования. Уменьшая объемы хранящихся данных, организации сокращают объем данных, которые будут предоставляться в случае компрометации данных. Это ограничит общее влияние.

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

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

• Пример доказательства. На снимку экрана ниже показана политика хранения данных Contoso.

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

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

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

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

Примечание: Все личные или конфиденциальные данные клиента должны быть отредактированы на снимок экрана.

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

Примечание: Это тестовая база данных, поэтому в ней не так много исторических данных.

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

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

• Пример рекомендаций по подтверждению. Если процесс удаления выполняется программным способом, предоставьте снимок экрана скрипта, который используется для этого. Если оно выполняется по расписанию, предоставьте снимок экрана, показывающий расписание. Например, сценарий для удаления файлов в общей папке может быть настроен как задание CRON. Снимок экрана: задание CRON с расписанием и скриптом, который выполняется, и предоставить скрипт с используемой командой.

• Пример доказательства 1. Это простой скрипт, который можно использовать для удаления всех записей данных, хладевших на основе даты -WHERE DateAdd — -30 дней, который очистит все сохраненные записи старше 30 дней после выбранной даты хранения данных. Обратите внимание, что нам потребуется скрипт, а также свидетельство выполнения задания и результаты.

• Пример доказательства 2. Приведенный ниже пример взят из плана хранения данных Contoso в элементе управления 7. Здесь показаны процедуры, используемые для уничтожения данных.

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

• Пример доказательства 3. В этом примере был создан модуль Runbook и соответствующее расписание в Azure для безопасного удаления записей с датой окончания, созданной через 30 дней после истечения срока действия политики хранения записей данных. Это задание настроено для выполнения каждый месяц в последний день месяца.

В окне ниже показано, что модуль Runbook был изменен для поиска записей, а команды удаления не отображаются, как в сценарии. Обратите внимание, что для этих снимков экрана должны отображаться полный URL-адрес и имя пользователя, и для отображения снимка экрана с количеством записей перед удалением и снимок экрана после удаления записей. Эти снимки экрана являются чисто примерами различных подходов к этому.

Управление доступом к данным

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

Control 10:P rovide — список всех лиц, имеющих доступ к данным или ключам шифрования, включая бизнес-обоснование.

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

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

• Пример доказательства. В следующем документе показан задокументирован список пользователей с доступом к данным и бизнес-обоснование.

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

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

• Примеры рекомендаций по подтверждению. Как правило, доказательства, предоставленные для предыдущего элемента управления, могут помочь в поддержке этого элемента управления. Если в предоставленной документации нет официального утверждения, то подтверждение может состоять в том, что запрос на изменение создается и утверждается для доступа в таком средстве, как Azure DevOps или Jira.

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

На этом изображении показано, что в Jira создан запрос для получения утверждения Sam Daily для ключей шифрования в серверной среде систем. Это делается в качестве следующего шага для управления значением 10 выше, где была получена письменная авторизация.

Это показывает, что запрос на предоставление Доступа Сэм Daily был одобрен ДжонОм Смитом человек из руководства, который можно увидеть в контроле 10. (Обратите внимание, что утверждение должно исходить от пользователя с достаточными полномочиями, чтобы разрешить запрос на изменение. Это не может быть другой разработчик).

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

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

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

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

Выше вы видите, что доступ был утвержден и подписан, как сделано.

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

• Намерение. Цель этого элемента управления заключается в том, чтобы убедиться, что доступ к данным и (или) ключу шифрования настроен в соответствии с документом.

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

• Пример доказательства. На этом снимку экрана показаны разрешения, предоставленные пользователю "John Smith", которые будут перекрестно ссылаться на запрос на утверждение для этого же пользователя в качестве доказательства для предыдущего элемента управления.

Элемент управления 13. Укажите список всех сторонних поставщиков, которым предоставляется доступ к данным клиента.

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

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

• какие услуги предоставляются,

• к каким данным предоставлен общий доступ;

• почему данные являются общими,

• ключевые контактные данные (т. е. основной контакт, контакт с уведомлением о нарушении, DPO и т. д.),

• продление или истечение срока действия контракта

• правовые обязательства и обязательства по соответствию (то есть GDPR, HIPPA, PCI DSS, FedRamp и т. д.)

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

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

• Пример свидетельства 1

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

Элемент управления 14. Предоставьте наглядное доказательство того, что все третьи стороны, потребляющие данные клиентов, имеют соглашения об обмене.

• Намерение. Если данные Microsoft 365 передаются третьим лицам, важно, чтобы данные обрабатывались надлежащим образом и безопасно. Соглашения об обмене данными должны быть приняты, чтобы третьи стороны обрабатывали данные только по мере необходимости и понимали свои обязательства по обеспечению безопасности. Безопасность организации так же сильна, как самое слабое звено. Цель этого элемента управления заключается в том, чтобы третьи стороны не стали слабым звеном организации.

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

• Пример доказательства. На следующем снимку экрана показан упрощенный пример соглашения об обмене данными.

Примечание: Полное соглашение должно быть предоставлено, а не снимок экрана.

GDPR

Большинство организаций будут обрабатывать данные, которые потенциально являются данными европейского гражданина (субъектов данных). При обработке данных ЛЮБОГО субъекта данных организации должны будут соблюдать Общий регламент по защите данных (GDPR). Это относится как к контроллерам данных (вы напрямую собираете указанные данные), так и к обработчикам данных (вы обрабатываете эти данные от имени Контроллера данных). Хотя этот раздел не охватывает все регулирование, в нем рассматриваются некоторые ключевые элементы GDPR, чтобы получить некоторую уверенность в том, что организация серьезно относится к GDPR.

Элемент управления 15. Предоставление задокументированного процесса запроса на доступ к субъекту (SAR) и предоставление доказательств того, что субъекты данных могут создавать SAR.

• Намерение. GDPR включает конкретные обязательства, которые должны выполняться организациями, обрабатывающими данные субъектов данных. Обязательства организаций по управлению запросами на доступ к субъекту (SAR) включены в статью 12, которая в соответствии со статьей 12.3 предоставляет контролеру данных один месяц с момента получения SAR для ответа на запрос. При необходимости продление может быть продлено еще на два месяца. Даже если ваша организация выступает в качестве обработчика данных, это по-прежнему потребуется, чтобы помочь клиентам (контроллеру данных) выполнить свои обязательства по SAR.

• Примеры рекомендаций по подтверждению. Предоставьте задокументированную процедуру обработки SAR.

• Пример доказательства. В следующем примере показан задокументирован процесс обработки SAR.

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

Элемент управления 16. Предоставьте наглядное доказательство того, что вы можете определить все расположения данных субъектов данных при реагировании на SAR.

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

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

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

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

Этот запрос подтверждает используемые учетные записи хранения. Вы можете запрашивать и удалять хранилище, большие двоичные объекты и (или) файлы с помощью Resource Graph Обозреватель (Kusto) или PowerShell (см. ниже).

На приведенном выше рисунке показаны данные, найденные в контейнере BLOB-объектов для клиента, которые необходимо удалить, а ниже показано действие по удалению или обратимому удалению информации в blob-объекте.

Элемент управления 17. Укажите ссылку на уведомление о конфиденциальности, которое должно содержать все необходимые элементы следующим образом:

• Сведения о компаниях (имя, адрес и т. д.).

• Сведения о типах обрабатываемых персональных данных.

• Сведения о законности обработки персональных данных.

• Сведения о правах субъекта данных:

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

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

• Намерение. Статья 13 GDPR включает конкретную информацию, которая должна быть предоставлена субъектам данных во время получения персональных данных. Цель этого элемента управления заключается в том, чтобы уведомление организации о конфиденциальности данных предоставлял субъектам данных некоторые ключевые сведения, включенные в статью 13.

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

• Пример свидетельства

Изображения уведомления о конфиденциальности выше и рядом показывают пример политики конфиденциальности в Интернете с включенной статьей 13 GDPR.

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

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

Книги

Мердок Д. (2018) Blue Team Handbook: Incident Response Edition: сокращенное руководство по реагированию на инциденты кибербезопасности. 2-й выпуск, Publisher: CreateSpace Independent Publishing Platform.

Ссылки

• Отчеты о мошенничестве с действиями о киберпреступности Доступны по адресу: https://www.actionfraud.police.uk/ (Доступно 21.08.08.21).
• ЕС. (2021) Контрольный список GDPR для контроллеров данных Доступен по адресу( https://gdpr.eu/checklist/ Доступ к 21.01.02.21).
• Microsoft. (2018) Ведение журнала событий (установщик Windows) доступно по адресу: Ведение журнала событий (установщик Windows) (доступ: 23/12/20).
• Положительные технологии. (2020) Как подходить к безопасной разработке программного обеспечения Доступно по адресу ( https://www.ptsecurity.com/ww-en/analytics/knowledge-base/how-to-approach-secure-software-development/Доступно: 21/12/20).
• Регламент (ЕС) 2016/679 Европейского парламента и Совета от 27 апреля 2016 года о защите физических лиц в отношении обработки персональных данных и о свободном перемещении таких данных, и отмена Директивы 95/46/EC (Общий регламент по защите данных) (текст с релевантностью ЕЭЗ) (2016 г.) Доступно по адресу( https://www.legislation.gov.uk/eur/2016/679/contents Доступ: 01.11.2021).
• Метрики безопасности. (2020) Руководство по метрикам безопасности для соответствия требованиям PCI DSS. Доступно по адресу: https://info.securitymetrics.com/pci-guide-2020(Дата обращения: 06.01.21).
• Williams J. OWASP Risk Ranking Available at: https://owasp.org/www-community/OWASP_Risk_Rating_Methodology (Доступно: 12.08.20).
• Qualys. (2014) Ssl Labs: new grades for Trust (T) and Mismatch (M) Issues Available at: https://blog.qualys.com/product-tech/2014/06/17/ssl-labs-new-grades-for-trust-t-and-mismatch-m-issues (Accessed: 29/01/21).
• NIST SP800-61r2: Руководство по обработке инцидентов безопасности компьютеров доступно по адресу:https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final (доступно 24/01/21).

Изображения, полученные из документов Майкрософт

• https://www.sans.org/information-security-policy/(Дата обращения: 18.02.21). в разделе Получение анализа поведения и обнаружения аномалий(доступ к 21.02.16). в разделе Что такое оповещения Azure Monitor? (доступ к 21.02.17). в разделе Получение поведенческой аналитики и обнаружения аномалий (доступ к 21.02.22). в разделе Управление оповещениями системы безопасности в Microsoft Defender для облака и реагирование на них (доступ к ней: 24.02.21). в разделе Управление оповещениями системы безопасности в Microsoft Defender для облака и реагирование на них (доступ к ней: 24.02.21).
• https://microsoft.github.io/AzureTipsAndTricks/blog/tip272.htmlв статье Что такое Azure Information Protection? в разделе Прозрачное шифрование данных для База данных SQL, Управляемый экземпляр SQL и Azure Synapse Analytics в кратком руководстве. Создание назначения политики для определения несоответствующих ресурсов в Настройка Расширенной защиты от угроз для базы данных Azure SQL