Требования к защите данных

Подготовка к ответу на вопросы о защите данных

Движение данных

Подготовьте (или обновите, если потребуется) диаграмму движения данных или текст, в котором описано, как приложение или система обрабатывает Данные платформы.

1. Сторона клиента — укажите всё клиентское программное обеспечение, такое как браузеры, мобильные устройства и любые другие поддерживаемые типы устройств.
2. Сторона сервера — укажите все связанные серверы или облачные среды и укажите следующее:
1. Компоненты, в которых Данные платформы:
1. входят в серверные среды или покидают их (например, веб-слушатели и REST API);
2. заносятся в постоянное или долговременное хранилище, такое как базы данных, диски или файлы журналов.
2. Модель хостинга, например следующее:
1. Хостинг у себя — собственные серверы организации, работающие в собственном или общем дата-центре.
2. Инфраструктура как услуга (IaaS), например AWS EC2, Microsoft Azure IaaS и Google Compute Engine.
3. Платформа как услуга (PaaS), например AWS Elastic Beanstalk, Google App Engine и Force.com.
4. Бэкенд как услуга (BaaS), например AWS Amplify, Azure Mobile Apps, Firebase и MongoDB Switch.
5. Гибридная модель — сочетание перечисленных выше моделей.

В конечном итоге диаграмма или текст с описанием движения данных должны включать следующую информацию:

1. где в клиентском и серверном программном обеспечении генерируются и передаются/хранятся/обновляются маркеры доступа к API Meta (если применимо к дизайну системы);
2. как вы получаете Данные платформы из API Meta, особенно персональные данные, позволяющие установить личность (PII), например имя, адрес электронной почты, пол, дата рождения и другие данные пользователя;
3. как вы используете, храните и передаете эти данные;
4. любые сторонние лица, которым передаются Данные платформы.

Подготовка доказательств

От вас могут потребоваться доказательства, подтверждающие ваши ответы на вопросы, связанные с применяемыми вами мерами защиты данных. Мы рекомендуем вам ознакомиться с настоящим руководством по доказательствам, в котором приведены примеры приемлемых доказательств, и подготовить доказательства в соответствии с этим руководством. Мы принимаем файлы документов стандартных типов, а также снимки и записи экрана. Убедитесь, что файлы не защищены паролем. Вы можете загрузить несколько файлов объемом до 2 ГБ каждый. Мы принимаем файлы в форматах .xls, .xlsx, .csv, .doc, .docx, .pdf, .txt, .jpeg, .jpg, .png, .ppt, .pptx, .mov, .mp4, .zip и .zipx.

Типы доказательств

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

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

Доказательства наличия политики или процедуры

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

Доказательства внедрения

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

Полнота доказательств

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

1. Доказательства наличия политики или процедуры должны четко соответствовать требованиям Meta или превосходить их
1. Meta проверит доказательства наличия политики или процедуры на предмет утверждений, соответствующих требованиям Meta для данного способа защиты.
2. Вы должны аннотировать документ, чтобы выделить соответствующие разделы
3. Например, приемлемые доказательства наличия способа защиты "Шифрование TLS 1.2 или выше, применяемое ко всем публичным сетевым подключениям, по которым передаются Данные платформы" включают документ, в котором четко указано:
1. Данные платформы Meta ни в коем случае не должны передаваться через ненадежные сети в незашифрованном формате
2. Все веб-слушатели (например, балансировщики нагрузки с выходом в Интернет), которые получают или возвращают Данные платформы, будут настроены таким образом, чтобы был включен протокол TLS 1.2
3. Все веб-слушатели, которые получают или возвращают Данные платформы, будут настроены таким образом, чтобы были отключены следующие протоколы: SSL v2, SSL v3, TLS 1.0 и TLS 1.1
2. Доказательства внедрения должны демонстрировать один или несколько примеров внедрения каждой политики или процедуры.
1. Вы должны загрузить один или несколько документов, снимков экрана или конфигураций инструментов, которые демонстрируют, как вы применили каждый способ защиты.
2. Мета проанализирует доказательства внедрения, чтобы убедиться, что они соответствуют доказательствам наличия политики или процедуры.
3. Например, приемлемые доказательства внедрения способа защиты Шифрование TLS 1.2 или выше, применяемое ко всем публичным сетевым подключениям, по которым передаются Данные платформы включают отчет по тестированию Qualys SSL одного из веб-доменов, настроенного в соответствии с политикой или процедурой.

Конфиденциальные данные, которые необходимо удалить из доказательств

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

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

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

Защита Данных платформы на сервере посредством шифрования при хранении

Вопрос. Выполняется ли автоматическое шифрование Данных платформы при хранении в облаке, на сервере или в среде дата-центра?

Цель

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

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

Обзор требований

При хранении Данных платформы на сервере следует выполнять требования ниже:

• Необходимо ОБЯЗАТЕЛЬНО защитить указанные данные одним из следующих способов:

  • шифрование при хранении;
  • альтернативные приемлемые методы защиты (см. раздел Альтернативные приемлемые методы защиты).

• В зависимости от используемого типа шифрования действуют следующие требования:

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

Если разработчик НЕ хранит Данные платформы на сервере, это требование не является применимым.

Особые случаи

Хранение на сервере с использованием продукта IaaS, собственных ресурсов или гибридной модели

Этот вопрос касается вас, если вы храните Данные платформы в IaaS-продукте (например, AWS EC2, Microsoft Azure IaaS или Google Compute Engine) на своем сервере или в гибридной среде.

Хранение на стороне сервера с использованием продуктов SaaS, PaaS или BaaS

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

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

• BaaS — например, AWS Amplify, мобильные приложения Azure, Azure PlayFab, Google Firebase и MongoDB Switch.
• PaaS — например, AWS Elastic Beanstalk, Google App Engine, Force.com.
• SaaS — например, Mailchimp или Salesforce.

Хранение данных на стороне сервера с помощью API Meta

Если вы храните Данные платформы только через API Meta, например с помощью player.setDataAsync() в SDK моментальных игр, этот вопрос к вам не относится.

Руководство по предоставлению доказательств

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

Пример доказательства внедрения

AWS RDS

AWS RDS — шифрование при хранении настраивается в среде AWS RDS, поэтому разработчикам необходимо применить этот вариант защиты во время настройки конфигурации.

Чтобы вывести конфигурацию StorageEncrypted в репрезентативном экземпляре RDS с Данными платформы, воспользуйтесь инструментом AWS для работы с командной строкой.

# List RDS instances in default region
$ aws rds describe-db-instances \
  --query 'DBInstances[*].DBInstanceIdentifier'

[
    "database-1",
    "database-2"
]

# For each instance returned, retrieve the storage encrypted config
$ aws rds describe-db-instances \
  --db-instance-identifier database-1 \
  --query 'DBInstances[*].StorageEncrypted'
[
    true
]

$ aws rds describe-db-instances \
  --db-instance-identifier database-2 \
  --query 'DBInstances[*].StorageEncrypted'
[
    true
]

AWS DynamoDB

В среде AWS DynamoDB шифрование при хранении настроено по умолчанию. Вывести нужную конфигурацию в виде таблицы можно с помощью следующих команд.

$ aws dynamodb list-tables --output table

--------------
| ListTables |
+------------+
||TableNames||
|+----------+|
||  Users   ||
|+----------+|


$ aws dynamodb describe-table \
 --table-name Users \
 --query "Table.SSEDescription.Status"

"ENABLED"

AWS DocumentDB

В среде AWS DocumentDB шифрование при хранении необходимо настраивать отдельно. Чтобы вывести конфигурацию StorageEncrypted в репрезентативном кластере с Данными платформы, воспользуйтесь следующими командами.

$ aws docdb describe-db-clusters --query 'DBClusters[*].DBClusterIdentifier'

[
    "docdb-users"
]

$ aws docdb describe-db-clusters \
  --db-cluster-identifier 'docdb-users' \
  --query 'DBClusters[*].StorageEncrypted'
[
    true
]

AWS S3

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

$ aws s3api list-buckets --output table --query "Buckets[*].Name"

---------------------------------------------
|                ListBuckets                |
+-------------------------------------------+
|  platform.storage                         |
+-------------------------------------------+

$ aws s3api get-bucket-encryption \
  --bucket  platform.storage \
  --query "ServerSideEncryptionConfiguration.Rules[*].ApplyServerSideEncryptionByDefault" \
  --output table
---------------------
|GetBucketEncryption|
+-------------------+
|   SSEAlgorithm    |
+-------------------+
|  AES256           |
+-------------------+

Microsoft Azure

Изучите документацию Microsoft по шифрованию при хранении в Azure, связанную с использованием сервисов в организации.

Google Cloud Platform

Изучите документацию Google по шифрованию при хранении на платформе Google Cloud Platform.

Альтернативные приемлемые методы защиты

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

1. Конфиденциальность Данных платформы — разные типы хранимых Данных платформы считаются подверженными риску в большей или меньшей степени. Вам необходимо выяснить, какие из атрибутов пользователя в составе Данных платформы хранятся на сервере.
2. Меры предосторожности для снижения вероятности определенных видов ущерба
1. Меры предосторожности для предотвращения взлома сетей с Данными платформы.
2. Меры предосторожности для предотвращения взлома приложений или систем с доступом к Данным платформы.
3. Меры предосторожности для предотвращения потери физических носителей (например, выведенных из эксплуатации сетевых хранилищ), содержащих Данные платформы.
4. Меры предосторожности для предотвращения потери физических носителей (например, выведенных из эксплуатации сетевых хранилищ), содержащих Данные платформы.
5. Меры предосторожности для предотвращения несанкционированного доступа к резервным копиям хранилищ с копиями Данных платформы.
3. Важность доказательств — обязательно отметьте, были ли эти меры предосторожности оценены независимым аудитором, например в ходе аудита на соответствие стандарту SOC2.

Предотвращение утечки Данных платформы, хранимых на устройствах и съемных носителях организации

Вопрос. Касательно данных, хранимых на личных и корпоративных устройствах... Используете ли вы шифрование при хранении или разработали ли вы политики и правила, направленные на снижение риска утечки, в отношении Данных платформы, хранимых на таких устройствах?

Цель

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

Обзор требований

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

  • Технические средства контроля могут включать следующее: 1) предоставление возможности подключаться к корпоративной сети только управляемым устройствам; 2) внедрение полного шифрования диска на управляемых устройствах (например, BitLocker); 3) запрет на подключение съемных носителей (например, USB-накопителей) к управляемым устройствам; 4) использование технологии предотвращения утечки данных (DLP) на управляемых устройствах.
  • Административные средства контроля могут включать письменное документирование политик, а также ежегодные тренинги по приемлемым способам обращения с Данными платформы на личных и корпоративных устройствах.

Руководство по предоставлению доказательств

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

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

Технические средства контроля могут включать:

• запрет на подключение неуправляемых устройств к конфиденциальным сервисам, таким как производственная сеть;
• внедрение шифрования диска на управляемых устройствах (например, с помощью BitLocker в Windows или FileVault на компьютерах Mac);
• запрет на использование съемных носителей (например, USB-накопителей) на управляемых устройствах;
• использование программного обеспечения DLP на управляемых устройствах для блокирования ненадлежащего обращения с Данными платформы (например, отправки во вложении электронной почты).

Правила и политики должны включать следующее:

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

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

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

Защита Данных платформы, передаваемых по сетям, посредством шифрования при передаче

Вопрос. Используете ли вы при передаче Данных платформы протокол безопасности TLS версии 1.2 или более новой для всех сетевых подключений, которые проходят по общедоступным сетям, подключаются к ним или пересекаются с ними? Уточните также, принимаются ли необходимые меры, чтобы Данные платформы не передавались по общедоступным сетям в незашифрованном виде (например, посредством протоколов HTTP и FTP) и чтобы не использовались протоколы безопасности SSL версий 2 и 3.

Цель

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

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

Обзор требований

Независимо от того, обрабатываете ли вы Данные платформы на стороне сервера:

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

  • Включить TLS версии 1.2 или более новой.
  • Отключить SSL v2 и SSL v3.
• TLS 1.0 и TLS 1.1 можно использовать только для обеспечения совместимости с клиентскими устройствами, не поддерживающими TLS 1.2+.
• Meta рекомендует, но не требует использовать технологию шифрования при передаче для Данных платформы, передаваемых по частным сетям, например в виртуальном частном облаке (VPC).

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

Руководство по предоставлению доказательств

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

• Примените инструмент Qualys SSL Server Test к одному или нескольким веб-слушателям, которые настроены одинаково (включая запущенные на нестандартных портах).
• Установите флажок "Do not show the results on the boards (Не показывать результаты на панелях)", чтобы не отправлять результаты проверки на сайт Qualys. Распечатайте всю страницу с результатами тестирования в PDF. Повторите те же действия в отношении любых веб-слушателей с другой конфигурацией TLS, на/с которых вы передаете Данные платформы.

Пример доказательства внедрения

Это пример результатов, полученных с помощью инструмента Qualys SSL Server Test. Обратите внимание на красные аннотации в разделе конфигурации, где представлена общая информация о поддерживаемых версиях SSL/TLS. Примечание. Этот пример включает только первые две страницы, но вы должны включить все результаты тестирования.

Альтернативные приемлемые способы защиты

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

• Это симметричное или асимметричное шифрование?
• Какой алгоритм шифрования (например, AES, BitLocker, TDES, RSA) вы применяете?
• Какова минимальная длина ключа?

Тестирование приложений и систем на наличие уязвимостей и проблем безопасности

Вопрос. Осуществляете ли вы тестирование приложений и систем на наличие уязвимостей и проблем безопасности как минимум раз в 12 месяцев? (Например, проводите ли вы ручное тестирование на проникновение?)

Цель

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

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

Обзор требований

Применимо ко всем разработчикам:

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

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

Дополнительные требования для разработчиков, обрабатывающих Данные платформы на стороне сервера:

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

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

Руководство по предоставлению доказательств

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

Если организация обрабатывает Данные платформы в облачной/серверной среде:

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

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

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

Если организация НЕ обрабатывает Данные платформы в облачной/серверной среде:

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

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

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

Тестирование на проникновение — организация осуществляет тестирование на проникновение для своего ПО, выполняемого на стороне сервера, которое интегрируется с API-интерфейсами Meta и используется для обработки Данных платформы. Компания, проводящая тестирование, выполняет тест и предоставляет письмо-отчет (см. пример ниже). Обратите внимание на примечания красным цветом: они подчеркивают, что дата проведения теста указана (не позднее 12 месяцев назад) и имеется сводка по обнаруженным неустраненным критическим/серьезным уязвимостям по завершении тестирования (или повторного тестирования при необходимости). Перед отправкой отчета удалите из него конфиденциальные сведения (в частности, подробное описание действий по воспроизведению уязвимости).

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

Проверка конфигурации облака

Разработчик использует NCC Scout Suite с набором правил по умолчанию для данного поставщика облачных сервисов (в этом случае AWS) для проверки конфигурации облака на предмет уязвимостей и проблем безопасности. Данный инструмент формирует JSON-файл с подробными результатами проверки. В этом примере выявлен ряд проблем (отмечены флагом "Danger (Опасность)"), которые разработчик должен проверить и устранить.

$ python3 scout.py aws –-no-browser
2022-08-22 11:39:38 localhost scout[76981] INFO Saving data to scoutsuite-report/scoutsuite-results/scoutsuite_results_aws-043954759379.js

$ cd scoutsuite-report/scoutsuite-results
$ tail -n +2 scoutsuite_results_aws-043954750000.js| jq '. | {last_run}' | pbcopy

{
  "last_run": {
    "ruleset_about": "This ruleset consists of numerous rules that are considered standard by NCC Group. The rules enabled range from violations of well-known security best practices to gaps resulting from less-known security implications of provider-specific mechanisms. Additional rules exist, some of them requiring extra-parameters to be configured, and some of them being applicable to a limited number of users.",
    "ruleset_name": "default",
    "run_parameters": {
      "excluded_regions": [],
      "regions": [],
      "services": [],
      "skipped_services": []
    },
    "summary": {
      "acm": {
        "checked_items": 4,
        "flagged_items": 2,
        "max_level": "warning",
        "resources_count": 2,
        "rules_count": 2
      },
      "awslambda": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "cloudformation": {
        "checked_items": 11,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 11,
        "rules_count": 1
      },
      "cloudfront": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 3
      },
      "cloudtrail": {
        "checked_items": 153,
        "flagged_items": 4,
        "max_level": "danger",
        "resources_count": 17,
        "rules_count": 9
      },
      "cloudwatch": {
        "checked_items": 2,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 2,
        "rules_count": 1
      },
      "codebuild": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "config": {
        "checked_items": 17,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 1227,
        "rules_count": 1
      },
      "directconnect": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "dynamodb": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 1,
        "rules_count": 0
      },
      "ec2": {
        "checked_items": 760,
        "flagged_items": 108,
        "max_level": "danger",
        "resources_count": 44,
        "rules_count": 28
      },
      "efs": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "elasticache": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "elb": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 3
      },
      "elbv2": {
        "checked_items": 42,
        "flagged_items": 4,
        "max_level": "danger",
        "resources_count": 0,
        "rules_count": 5
      },
      "emr": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "iam": {
        "checked_items": 801,
        "flagged_items": 27,
        "max_level": "danger",
        "resources_count": 87,
        "rules_count": 37
      },
      "kms": {
        "checked_items": 15,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 15,
        "rules_count": 1
      },
      "rds": {
        "checked_items": 1,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 27,
        "rules_count": 9
      },
      "redshift": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 6
      },
      "route53": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 1,
        "rules_count": 3
      },
      "s3": {
        "checked_items": 121,
        "flagged_items": 34,
        "max_level": "warning",
        "resources_count": 7,
        "rules_count": 18
      },
      "secretsmanager": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 1,
        "rules_count": 0
      },
      "ses": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 4
      },
      "sns": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 7
      },
      "sqs": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 8
      },
      "vpc": {
        "checked_items": 271,
        "flagged_items": 211,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 9
      }
    },
    "time": "2022-08-22 11:42:25-0400",
    "version": "5.11.0"
  }
}

Другой подход к проверке конфигурации облака для разработчиков, использующих набор правил Amazon Web Services.

# Show that AWS Foundational Security Best Practices are enabled
$ aws securityhub get-enabled-standards                                                                                                            
{
    "StandardsSubscriptions": [
        {
            "StandardsSubscriptionArn": "arn:aws:securityhub:us-west-1:043954759379:subscription/aws-foundational-security-best-practices/v/1.0.0",
            "StandardsArn": "arn:aws:securityhub:us-west-1::standards/aws-foundational-security-best-practices/v/1.0.0",
            "StandardsStatus": "READY"
        }
    ]
}

# Show that aggregator is configured for a representative region used to process Platform Data
$ aws securityhub list-finding-aggregators

$ aws securityhub get-finding-aggregator --finding-aggregator-arn '{REPLACE-WITH-FINDING-AGGREGATOR-ARN}'


# Demonstrate that the ruleset is running by fetching active findings and counting the number of lines of output
$ aws securityhub get-findings --query 'Findings[?RecordState==`ACTIVE`]' --filters '{"GeneratorId":[{"Value": "aws-foundational-security","Comparison":"PREFIX"}]}' --output text | wc -l                                     

4876
# Demonstrate that there are no active critical severity findings
$ aws securityhub get-findings --query 'Findings[?Severity.Label==`CRITICAL`] | [?RecordState==`ACTIVE`] | [*][Title, GeneratorId]' --filters '{"GeneratorId":[{"Value": "aws-foundational-security","Comparison":"PREFIX"}]}'

[]

Альтернативные приемлемые методы защиты

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

• отсутствие исключений в области тестирования VDP, связанных с тем, как вы обрабатываете Данные платформы;
• проведение текущего исследования уязвимостей (и генерации соответствующих отчетов) в течение последних 12 месяцев (как правило, подтверждаемое минимум одним действительным отчетом об уязвимостях в месяц);
• отправленным (действительным) уязвимостям назначена оценка уровня серьезности, например по шкале CVSS 3.1;
• уязвимости устранены в разумные сроки, как правило, в течение менее чем 90 дней с момента отправки.

В этом случае доказательство должно включать следующее:

• заявление об объеме тестирования и о том, как оно связано с программным обеспечением, используемым для обработки Данных платформы;
• отчет о фактических уязвимостях, данные о которых были переданы в программу за последние 12 месяцев. Отчет должен включать следующие сведения: название уязвимости, дату отправки, дату устранения (если уязвимость устранена) и категорию/оценку уровня серьезности.

Защита маркеров доступа API и секретов приложений Meta

Вопрос. Осуществляется ли защита маркеров доступа API и секретов приложений Meta следующими двумя способами?

1. Путем запрета хранения маркеров доступа API Meta на клиентских устройствах, где доступ к ним не ограничен текущим приложением и пользователем.
2. Путем использования хранилища данных (например, Hashicorp Vault) с отдельной службой управления ключами (KMS) при условии хранения в облачной, серверной среде или среде дата-центра.

Цель

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

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

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

Обзор требований

Маркеры доступа

1. На клиентских устройствах — маркеры доступа Meta нельзя записывать так, чтобы их смог считать другой пользователь или процесс.
2. На стороне сервера — если вы осуществляете обработку или хранение маркеров доступа Meta на стороне сервера, такие маркеры доступа:
1. необходимо защищать с помощью хранилища данных (например, Hashicorp Vault) с отдельной службой управления ключами (KMS) и предоставлением доступа к ключу расшифровки только приложению;
2. запрещается записывать в файлы журналов.

Секрет приложения — должно выполняться одно из двух условий:

1. секрет приложения не должен покидать защищенную серверную среду (например, он никогда не возвращается, если сеть отправляет вызов в браузер или мобильное приложение, и не встраивается в код, передаваемый на мобильные или нативные/настольные клиенты) или
2. приложение необходимо обозначить как нативное/настольное, чтобы API Meta больше не доверяли вызовам API, включающим секрет приложения.

Руководство по предоставлению доказательств

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

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

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

Организация использует AWS Secrets Manager для безопасного хранения конфиденциальных данных, включая секреты приложений Meta.

Организация настроила требование подтверждения секрета приложения для вызовов API в приложении Meta.

Альтернативные приемлемые методы защиты

1. Если у вас не реализована защита маркеров доступа, хранимых на стороне сервера, с помощью хранилища данных или шифрования на уровне приложения, вы можете сделать следующее:
1. защитить секрет приложения с помощью хранилища или шифрования на уровне приложения, если ключ доступен только приложению;
2. а также настроить в приложении требование подтверждать секрет приложения для всех вызовов API к Meta.
2. Если способ 1 выше применить невозможно (например, невозможно требовать подтверждения секрета приложения, так как это приведет к блокировке необходимых вызовов API), Meta рассмотрит другие средства контроля, которые вы реализуете для снижения риска несанкционированного использования маркеров доступа по сравнению с риском ненадлежащего использования хранимых маркеров доступа.

Наличие плана реагирования на инциденты и тестирование систем и процессов реагирования на инциденты

Вопрос. Выполняется ли тестирование систем и процессов реагирования на инциденты безопасности (например, утечки данных или кибератаки) по крайней мере раз в 12 месяцев?

Цель

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

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

Обзор требований

Разработчик должен иметь следующее:

• План реагирования на инциденты, соответствующий минимальным критериям Meta.
• В этом документе должны быть представлены (как минимум): (1) роли и обязанности, (2) процедура обнаружения, (3) ответные действия — реагирование в соответствии с применимыми юридическими обязательствами (например, уведомление соответствующих надзорных органов и субъектов данных об утечке данных) и восстановление, а также (4) процедура анализа ситуации после инцидента.
• Документ, подтверждающий, что вы недавно (не менее 12 месяцев назад) протестировали этот план и в тестировании участвовали все упомянутые в нем сотрудники.

Руководство по предоставлению доказательств

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

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

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

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

План реагирования на инциденты

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

Полная версия шаблона плана реагирования на инциденты от Counteractive (в формате DOCX) доступна здесь.

Тестирование реагирования на инциденты

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

Требование многофакторной аутентификации для удаленного доступа

Вопрос. Является ли многофакторная аутентификация обязательным требованием для удаленного доступа всех аккаунтов, которые могут подключаться к облачным и серверным средам и/или получать доступ к сервисам, которые вы используете для развертывания, обслуживания, отслеживания и обеспечения работы систем, в которых хранятся Данные платформы Meta?

Цель

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

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

Обзор требований

В организации, обрабатывающей Данные платформы, удаленный доступ к этим инструментам должен быть защищен многофакторной аутентификацией (не только паролем):

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

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

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

  • инструменты развертывания ПО, с помощью которых вы развертываете программный код в облачной или серверной среде, например Jenkins или другие CI/CD-инструменты;
  • инструменты администрирования, например портал или другое средство доступа для управления облачными и серверными средами или их мониторинга;
  • удаленный доступ к серверам, например SSH, удаленные рабочие столы и аналогичные инструменты, используемые для удаленного входа на серверы, функционирующие как сторона сервера.

Требования к реализации многофакторной аутентификации

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

Руководство по предоставлению доказательств

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

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

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

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

AzureAD

Организация использует AzureAD в качестве решения SSO. Данная политика включает требование многофакторной аутентификации.

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

Okta

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

AWS IAM

Это пример политики AWS IAM, которая разрешает настройку многофакторной аутентификации и запрещает другие действия в отсутствие многофакторной аутентификации.

GitHub

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

Альтернативные приемлемые методы защиты

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

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

Наличие системы управления пользовательскими аккаунтами

Вопрос. Имеется ли у вас система управления аккаунтами (с функциями назначения, отзыва и проверки доступа и прав)?

Цель

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

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

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

Обзор требований

• У вас должен быть инструмент или процесс управления аккаунтами следующих инструментов/систем/приложений:

  • инструменты коммуникации, например Slack или рабочая электронная почта;
  • инструменты для передачи программного обеспечения, например репозиторий кода; и
  • инструменты администрирования системы и управления ею (в той мере, в которой это применимо к обработке Данных платформы).
• Вы должны регулярно (как минимум раз в 12 месяцев) проверять предоставленные права доступа и иметь процедуру отзыва таких прав, если они: (1) больше не нужны и (2) больше не используются.
• Кроме того, должен быть реализован процесс немедленной отмены доступа к этим инструментам, если сотрудник покидает организацию.
• Meta не требует:

  • использовать какой-либо конкретный инструмент — разработчик может использовать службы каталогов, такие как Google Cloud Identity или Microsoft Azure Active Directory, облачные службы, например AWS Identity и Access Management (IAM), и даже электронные таблицы, которые поддерживаются в актуальном состоянии;
  • наличия единственного консолидированного инструмента для управления аккаунтами с различным типом доступа.

Руководство по предоставлению доказательств

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

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

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

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

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

Пример внедрения: доступ сотрудников, покинувших организацию, отозван

Разработчик использует Workday в качестве официального источника данных о кадрах, включая сведения о текущем статусе трудоустройства. В качестве поставщика служб идентификации (IdP) этот разработчик использует Google Cloud Identity для управления пользовательскими аккаунтами и предоставления доступа к информационным системам и инструментам.

Разработчик отправляет доказательство отзыва доступа уволившихся сотрудников в виде отчета, демонстрирующего проведение недавнего (в течение последних 12 месяцев) акта сверки, из которого видно, что в Google Cloud Identity нет активных пользовательских аккаунтов для пользователей, не являющихся текущими сотрудниками, согласно отчету Workday о текущих сотрудниках.

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

В качестве поставщика служб идентификации (IdP) разработчик использует Google Cloud Identity для управления пользовательскими аккаунтами и предоставления доступа к информационным системам и инструментам.

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

Пример внедрения: GitHub (репозиторий кода)

Разработчик использует инструмент единого входа (SSO) для управления идентификационными данными и предоставления доступа к информационным системам и инструментам. Разработчик настроил требование аутентификации SSO в GitHub.

Регулярное обновление программного обеспечения

Вопрос. Есть ли у вас система обновления системного кода и сред, включая серверы, виртуальные машины, дистрибутивы, библиотеки, пакеты и антивирусное ПО?

Цель

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

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

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

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

Обзор требований

Ниже перечислены программные компоненты, к которым относятся эти требования:

1. библиотеки, SDK, пакеты, контейнеры приложений и операционные системы, используемые в облачной или серверной среде;
2. библиотеки, SDK, пакеты, используемые на клиентских устройствах, например в мобильных приложениях;
3. операционные системы и приложения, которые сотрудники используют в ходе разработки приложений или систем либо управления ими, например операционные системы и браузеры на рабочих ноутбуках.

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

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

Руководство по предоставлению доказательств

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

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

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

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

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

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

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

NPM Audit

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

Trivy

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

Служба обновления Windows Server (WSUS)

Служба обновления Windows Server (WSUS) позволяет управлять всем парком серверов и ПК или ноутбуков. На иллюстрации ниже показан интерфейс администратора WSUS. Он позволяет просматривать, утверждать и развертывать обновления для Windows.

Наличие системы регистрации доступа к Данным платформы и отслеживания того, куда они отправляются и где хранятся

Цель

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

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

Обзор требований

При обработке Данных платформы на стороне сервера необходимо соблюдать следующие требования:

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

Руководство по предоставлению доказательств

Если вас просят загрузить доказательства, они должны продемонстрировать:

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

Отслеживание передачи Данных платформы и основных точек, через которые Данных платформы могут покидать систему (например, третьих сторон или общедоступных конечных точек)

Цель

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

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

Обзор требований

При обработке Данных платформы на стороне сервера необходимо соблюдать следующие требования:

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

Руководство по предоставлению доказательств

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

Вы должны предоставить доказательства следующего:

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

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

Цель

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

Обзор требований

При обработке Данных платформы на стороне сервера необходимо соблюдать следующие требования:

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

Руководство по предоставлению доказательств

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

• McAfee Enterprise Security Manager
• SolarWinds Security Event Manager
• Splunk Enterprise Security
• Sumo Logic

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

Глоссарий

A

Третья сторона. В контексте управления рисками "третья сторона" — это разработчики на платформе Meta ("первая сторона" — это сама компания Meta; "вторая сторона" — это люди, использующие продукты Meta).

Четвертая сторона. В контексте управления рисками "четвертая сторона" — это фирмы, предоставляющие разработчикам услуги, от которых зависит их бизнес. ("Первая сторона" — это сама компания Meta, "вторая сторона" — это люди, использующие продукты Meta, "третья сторона" — это разработчики на платформе Meta.) Маркер доступа — это учетные данные, например пароль, позволяющие программному обеспечению отправлять вызовы API для выполнения какого-либо действия (например, чтения данных из профиля пользователя).

Amazon Web Services (AWS) — это пакет сервисов облачных вычислений от Amazon.

ID внутри приложения (App scoped ID, ASID) — уникальный идентификатор, который Meta генерирует, когда человек начинает использовать приложение. ASID помогает обеспечить конфиденциальность информации пользователей, поскольку затрудняет наборам данных сопоставление пользователей в разных приложениях, так как один и тот же пользователь, использующий два приложения, имеет в них разные ASID.

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

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

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

Шифрование приложения — метод защиты данных, при котором программное приложение само выполняет операции шифрования и дешифрования. В отличие от данного способа защиты протокол Transport Layer Security (TLS) незаметно для пользователя шифрует данные при передаче, когда приложение устанавливает безопасное соединение с удаленным сервером (например, с помощью HTTPS), а поставщики облачных услуг предлагают услуги прозрачного шифрования данных при хранении.

Интерфейс программирования приложений (Application Programming Interface, API) позволяет двум компьютерам обмениваться данными по сети, например когда мобильное приложение получает из централизованной системы прогнозов погоды сегодняшний прогноз погоды для определенного региона.

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

B

Бэкенд как услуга (Backend as a Service, BaaS) — это облачные сервисы, предоставляющие разработчику приложений ряд возможностей на стороне сервера, позволяющих ему сосредоточиться на разработке клиентской части (т. е. той части приложения, с которой взаимодействуют пользователи). BaaS-решения похожи на PaaS, однако также предоставляют такие сервисы, как аутентификация пользователей и мобильные push-уведомления. Примеры популярных BaaS-продуктов: AWS Amplify, Azure Mobile Apps, Firebase и MongoDB Switch.

C

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

Сторона клиента. Чтобы использовать услуги, доступные через Интернет, люди обычно открывают веб-сайт в браузере или запускают мобильное приложение на телефоне или планшете. В данном контексте браузер или мобильное приложение — это локальные клиенты, или "сторона клиента". Клиенты отправляют запросы с удаленных компьютеров (серверов) через Интернет.

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

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

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

D

База данных — программное обеспечение, позволяющее хранить, читать, обновлять и удалять данные. Базы данных могут выполняться на клиентах и на серверах. Организации, интегрированные с платформой Meta, обычно хранят данные, получаемые из API Graph, в базе данных, которая выполняется на стороне сервера.

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

E

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

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

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

Устаревшее программное обеспечение. Если организация решает прекратить поддержку (например, разработку патчей для устранения уязвимостей в системе безопасности) программного продукта, данное программное обеспечение считается устаревшим. Из-за отсутствия поддержки использовать любое устаревшее программное обеспечение весьма рискованно.

G

Google Cloud Platform (GCP) — набор облачных вычислительных сервисов Google. API Graph — основной способ чтения и записи данных в социальный граф Meta, который используют приложения. Все SDK и продукты Meta так или иначе взаимодействуют с API Graph.

H

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

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

I

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

Управление идентификационными данными и доступом — категория инструментов и процессов, которые используются для управления аккаунтами и предоставления доступа к системам.

Инфраструктура как услуга (Infrastructure as a Service, IaaS) — облачные технологии, позволяющие клиентам настраивать сервисы вычислительных ресурсов, хранилища и сети, не управляя физическими ресурсами (например, не нужно управлять дата-центром с большим количество серверов, сетевых устройств и массивов хранения данных). По сравнению с PaaS модель IaaS предоставляет организации больше контроля над конфигурацией облачных ресурсов, однако при этом данными ресурсами сложнее управлять. Примеры популярных IaaS-продуктов: AWS EC2, Microsoft Azure IaaS и Google Compute Engine.

L

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

M

Мобильный клиент или мобильное приложение — приложение, которое человек устанавливает на телефон или планшет из магазина мобильных приложений (например, iOS App Store или Google Play). Обычно мобильные клиенты взаимодействуют через Интернет с REST API организации; они также могут взаимодействовать с другими сторонами (например, с API Graph через Facebook SDK для Android).

Многофакторная аутентификация (МФА) — подход к аутентификации, при котором доступ к приложению или системе предоставляется по более чем одному фактору. В отличие от однофакторной аутентификации, которая требует только пароля, МФА требует предоставить пароль плюс один или несколько из следующих типов данных: код, отправленный на электронный адрес или в SMS, код из приложения для аутентификации, результат биометрического сканирования или ключ безопасности. МФА защищает аккаунт от перехвата, затрудняя несанкционированное проникновение в аккаунт, например многократные попытки входа под известным электронным адресом путем перебора паролей.

N

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

Взлом сети. Если злоумышленник получает несанкционированный доступ к внутренней сети организации через неправильную конфигурацию или уязвимость в самой сети, это называется "взломом сети". Для защиты сети от взлома используется процедура сканирования сети, выявляющая неправильные настройки конфигурации и уязвимости в сети, подключенной к Интернету. См. также "взлом приложения".

Сканирование сети — процесс управления рисками, в рамках которого программное обеспечение выполняет следующие задачи: (1) определяет активные серверы в сети, которые будут отвечать на удаленные подключения, а затем (2) проверяет, не запущены ли на этих серверах старые версии программного обеспечения, о которых известно, что они не защищены от одного или нескольких эксплойтов системы безопасности. Организация может периодически выполнять сканирование сети — например, чтобы убедиться, что на периметре сети нет случайно открытых портов.

Node Package Manager (NPM) — инструмент, ускоряющий разработку на языке JavaScript за счет добавления готовых пакетов в приложение или систему разработчика. NPM включает функции, позволяющие анализировать набор пакетов, используемых приложением, и выявлять пакеты с известными уязвимостями в системе безопасности.

O

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

Операционная система — программное обеспечение на компьютере или мобильном устройстве, позволяющее приложениям работать и использовать процессор, память, хранилище и сетевые ресурсы компьютера. Например, Microsoft Windows, Apple macOS, iOS и Linux.

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

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

P

Условия использования платформы 6.a.i — ссылка на пункт (i) заголовка (a) раздела (6) Условий использования платформы Meta, в котором изложены обязательства разработчиков платформы, связанные с безопасностью данных.

Пакет — то же самое, что "библиотека".

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

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

Простой текст, или незашифрованные данные, — данные, не защищенные шифрованием. Платформа как услуга (Platform as a Service, PaaS) — подход к облачным вычислениям, при котором клиент развертывает приложение на платформе, управляемой поставщиком облачных сервисов. По сравнению с IaaS у PaaS удобнее управление, поскольку облачный хост управляет не только физическими ресурсами (например, серверами, устройствами хранения данных и сетевыми устройствами), но и операционной системой и контейнером приложений, в котором выполняется приложение клиента. Примеры популярных PaaS-продуктов: AWS Elastic Beanstalk, Google App Engine, Force.com.

Порт. Когда клиент устанавливает соединение с сервером через Интернет, адрес назначения состоит из двух частей: (1) адреса сервера по протоколу Интернета (IP) и (2) номера порта на этом сервере, на который будет отвечать конкретное приложение. Обычные протоколы используют зарезервированные порты (например, протокол HTTPS использует порт 443), однако при желании разработчик может использовать для сетевых коммуникаций произвольно выбранные порты.

R

REST API — широко распространенный стиль разработки веб-сервисов, где клиент и сервер взаимодействуют по протоколу HTTP. Разработчик на платформе Meta может разместить REST API на субдомене (например, api.example.com), на который его мобильное приложение отправляет и с которого оно получает Данные платформы.

S

Secure Shell (SSH) — схема коммуникации, позволяющая администраторам удаленно входить на серверы и запускать на них программы. Этот протокол считается безопасным, поскольку защищает канал связи между клиентом и сервером от прослушивания, в отличие от более ранних протоколов, таких как Telnet. Также называется Secure Socket Shell.

Secure Sockets Layer (SSL) — устаревшая и небезопасная технология шифрования при передаче данных. Ее современная защищенная версия называется Transport Layer Security (TLS).

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

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

Сторона сервера — данные или вычисления на другой стороне сетевого подключения (т. е. на сервере) называются "стороной сервера". В отличие от них данные или вычисления на локальном устройстве, таком как ноутбук или мобильное устройство, называются "стороной клиента".

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

Комплект для разработки программного обеспечения (Software Development Kit, SDK) — готовый блок кода, упрощающий процесс разработки под конкретные нужды. Например, Meta создает и поддерживает SDK, которые упрощают работу с API Graph для разработчиков на iOS и Android. Как и в случае с библиотеками, разработчики, использующие в приложениях SDK, должны своевременно их обновлять.

Программное обеспечение как услуга (Software as a Service, SaaS) позволяет клиентам использовать облачные приложения через Интернет. В отличие от PaaS или IaaS пользователь SaaS-приложения не развертывает пользовательский код и не отвечает за конфигурацию, обновление или исправление SaaS-приложения, так как за это отвечает поставщик программного обеспечения SaaS. Примеры популярных SaaS-продуктов: Dopbox, MailChip, Salesforce, Slack.

Статический анализ — см. "статическое тестирование безопасности приложений".

Статическое тестирование безопасности приложений (Static Application Security Testing, SAST) — поиск уязвимостей в программном обеспечении путем применения специализированного инструмента к исходному коду. Инструмент SAST выявляет потенциальные уязвимости, например перечисленные в проекте OWASP Top 10. Затем разработчик обязан проанализировать результаты, отличить истинные срабатывания от ложных и устранить уязвимости в программном обеспечении. SAST позволяет разработчикам находить уязвимости в программном обеспечении до развертывания в производственной среде, но в отличие от теста на проникновение этот инструмент не может находить уязвимости, связанные с производственной конфигурацией приложения.

T

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

Transport Layer Security (TLS) — схема шифрования при передаче, при которой шифрование используется для защиты данных, передаваемых по сетям, от подслушивающих устройств. TLS — это современная защищенная версия старой технологии SSL.

Двухфакторная аутентификация (2ФА) — то же самое, что многофакторная аутентификация. Защищенное хранилище — система управления конфиденциальными данными, например ключами шифрования, маркерами доступа и другими учетными данными. Защищенное хранилище позволяет строго контролировать доступ к секретным данным, которые в нем содержатся, а также предлагает дополнительные сервисы, например журналы аудита.

V

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

Виртуальное частное облако (Virtual Private Cloud, VPC) — термин, которым AWS обозначает набор облачных ресурсов, похожий на традиционную сеть, которая использовалась в дата-центрах до появления облачных технологий.

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

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

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

W

Веб-приложения — программы, которые запускаются в браузерах и состоят из таких ресурсов, как HTML-документы, код JavaScript, видео и другие медиаресурсы, а также стили CSS. В отличие от мобильного приложения, которое нужно установить на мобильный телефон из магазина приложений, веб-приложение не нужно устанавливать — оно извлекается с удаленного сервера, и пользователь получает доступ к нему через браузер (например, открывает сайт www.facebook.com).