Archive | August 2014

Специально для КО: расширенный анализ BadUSB

Перебрал свои записи по этой теме и написал статью для Компьютерного Обозрения.

Содержание:

Немного теории о том, чем BadUSB отличается от того, что мы видели прежде.

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

Своеобразная выжимка из ~ 45 минутного видео + немного аналитики и прогнозов.

Рекомендуется к прочтению как техническим специалистам ИБ/ИТ так и обычным пользователям, особенно тем, кто пропустил сам доклад.

Спасибо за внимание.

Advertisements

Device Control vs DLP Endpoint: отличия решений, выбор оптимального и советы по использованию

dlp_msg_blk2

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

И так, как Вы уже наверно знаете из моей презентации, для защиты от утечки на уровне конечных точек McAfee предлагает использовать либо Device Control (проще функционал, меньше требования к ресурсам системы) или полноценный DLP Endpoint (полный спектр правил и механизмов классификации, выше требования к ресурсам). Проиллюстрирую еще раз для наглядности:

dataprotection

На этом этапе стоит отметить, что оба решения могут интегрироваться с выборочным шифрованием (McAfee File&Removable Media Protection, бывший EEFF, подробности).

По сути консоль с настройками и программный пакет (агент) у этих продуктов один. Просто в зависимости от того какой s/n введен заказчик получает либо минимальный функционал либо полный. Агент один и тот же, просто в режиме Device Control only на конечной точке работает только перехватчик устройств. Соответственно, имя внедренный Device Control очень легко можно перейти на полнофункциональный DLP Endpoint просто сменив серийный номер в панели DLP на еРО, и активировать остальные перехватчики в конфигурации агента.

Давайте теперь коротко рассмотрим отличия:

DevCon_vs_DLPEndpointDevCon_1DevCon_3DevCon_4

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

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

Если заказчику нужно только:

– ограничить использование устройств определенного класса (модемы, адаптеры);

– организовать “черные”/”белые” списки для USB накопителей;

– обеспечить контроль информации, передаваемой через UBS флешки/SDкарты/внешние жесткие диски.

> тогда можно обойтись развертыванием Device Control.

Если же в ТЗ четко указан хотя бы один из следующих пунктов:

– контроль печати;

– контроль буфера обмена;

– контроль Web/Mail;

– контроль снимков экрана;

– тегирование документов;

– контроль сетевых соединений;

– поиск информации на файловой системе.

> значит заказчику необходим DLP Endpoint, поскольку только он может выполнять вышеперечисленные функции + делает то, что “умеет” Device Control.

#~#~#~#~#~

Добавлю пару слов по механизмам классификации.

Возьмем для наглядности слайд из моей презентации:

classificationИ так, в режиме Device Control заказчик может использовать механизм цифровых отпечатков и словари/текстовые шаблоны. Если нужны метки (теги) – понадобиться DLP Endpoint. В чем заключается отличие цифровых отпечатков от меток? Цифровые отпечатки, образно говоря, это совокупность контрольных сумм отдельных “порций” файлов (документов), которые пользователь предоставил системе в качестве примера. Отпечатки отталкиваются от контента передаваемой информации. Если что-то, что сотрудник копирует/посылает на печать/публикует в Интернете похоже (совпадает) с документом, с которого мы предварительно сняли отпечаток, – система отличает эту информацию в общем “потоке/шуме”. Что касается тегов (меток) то они применяются в тех случаях, когда контент (содержимое) документов трудно или невозможно формализовать. Т.е. теги не базируются на контенте документа.

DLP Endpoint позволяет назначать метки четырьмя разными способами:

  • вручную, через контекстное меню (как правило эта привилегия делегируется руководству и ИБшникам);
  • автоматически по местоположению (собрали все секретные документы на сетевой шаре, указали ее системе);
  • автоматически по приложению, которое создало/записало файл на диск (все выгрузки из 1С: Бухгалтерии тегровать меткой “Buh”);
  • автоматически при выполнении Discovery файлоой системы (ищем документы по критериям и помечаем их).

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

Простой пример: сотрудник работает с важным документом. Если документ помечен одним из четырех вариантов, при попытке сотрудника заархивировать документ 7zip с сложным паролем, метка скопируется на созданный архив. Благодаря этому DLP Endpoint сможет предотвратить утечку архива с документом внутри. И системе даже не понадобиться “заглядывать” внутрь этого архива.

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

#######

Подробнее про DLP Endpoint/Device Control можно прочесть по ссылке (ст. 19-20)

На сегодня это все. Следите за обновлениями. В ближайшее время будет следующая часть “Наставления по криптографическому делу“, а после нее я планирую поделиться своими наработками в области политик DLP Endpoint.

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

Наставление по криптографическому делу. Часть вторая.

de_preboot

Рекомендую начать с первой части.

Тема данного наставления: правильная последовательность действий при развертывании McAfee Drive Encryption (DE).

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

И так, by default, упрощенно процесс описан следующим образом:

(так делать не нужно, ниже я объясню почему)

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

Я бы хотел немного расширить эту стандартную схему, чтобы облегчить задачу админам/безопасникам и упредить возникновение многих проблем, которых можно избежать, если правильно пользоваться тем инструментарием, который есть “из коробки” в McAfee Drive Encryption.

Правильная последовательность выглядит так:

1) Перед шифрованием бэкапим данные с целевых систем (простите, что напоминаю, но это должно быть сделано прежде всего);

2) Перед началом развертывания шифрования проверяем список известных проблем с актуальной версией:

KB79753 Drive Encryption 7.1 Known Issues

3) Прежде чем устанавливать непосредственно пакеты DE сперва разворачиваем диагностическую утилиту DE GO.

KB72777 Overview of Endpoint (Drive) Encryption GO

Она предназначена для проверки состояния жестких дисков и поиска конфликтующего ПО (TrueCrypt*/BitLocker…). К следующему шагу переходим только если в отчетах DE GO нет замечаний по целевым системам.

(Важно!) В политиках есть настройка а-ля «защита от дурака» – не активировать шифрование пока DE GO не даст «зеленый свет».

4) Устанавливаем модули шифрования на целевую систему, процесс шифрование пока не активируем, назначаем пользователей системе, определяем нужные политики (SSO, сложность пароля, тип токена, варианты восстановления и т.д.)

5) Для устранения возможных проблем связанных с несовместимостью/устаревшей версией BIOS при активации шифрования задействуем т.н. Pre-Boot Smart Check (по умолчанию не включено, т.к. увеличивает кол-во перезагрузок при активации шифрования)
Этот режим активации помогает избежать ситуации, когда после шифрования жесткого диска pre boot не работает из-за BIOS/AHCI и т.д..

Разница между DE GO и Pre-Boot Smart Check в том, что DE GO проверяет возможные проблемы на уровне ОС, а Pre-Boot Smart Check проверяет аппаратный уровень.

(Важно!)

Совет: перед внедрением шифрования убедитесь в том, что режим SATA контроллера в настройках BIOS = AHCI. Про обновление/установку драйверов AHCI для Windows нужно позаботиться заранее. Как показала практика – переключение на ACHI на старых ноутбуках позволяет упредить проблемы с preboot.

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

Без необходимости не перезагружаем систему, не мешаем DE криптовать данные.

7) После того как жесткий диск зашифрован на 100% и модуль попросил перезагрузку – перезагружаемся и проходим процедуру инициализации пользователя.

В случае проблем с загрузкой системы используем загрузочный CD/USB с DETech для аварийной загрузки без аутентификации/ исправления MBR или расшифровки диска.

Видео по использованию DE Tech через Deep Command (Intel AMT/vPro)

#~#~#~#~#~

Если будете придерживаться этих 7 пунктов – вероятность “наступить на грабли” существенно уменьшается.

Шифрование вещь серьезная и халатности/расхлябанности не терпит. Помните об этом, когда будете криптовать ноут вашего руководителя.

p.s.

Совет для ценителей TrueCrypt

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

Что нужно сделать:

  1. Если TrueCrypt был установлен (его драйвер был прописан в реестре), нужно удалить приложение на время установки и активации DE;
  2. После активации DE продолжаем использовать TrueCrypt в т.н. portable режиме, т.е. не устанавливая его, а запуская каждый раз по запросу, когда нужно примонтировать криптоконтейнер;
  3. Для того, чтобы DE не начал шифровать содержимое криптоконтейнера TrueCrypt, необходимо в свойствах последнего активировать опцию “Mount volumes as removable media” (монтировать криптоконтейнеры как съемные диски).

Таким образом мы получили защиту данных от НСД с двойным запасом прочности и некоторой морокой (при запуске TrueCrypt в portable режиме, если вы не сидите под административной учетной записью, вас будет мучить UAC, но это ведь мелочи, да и безопаснее).

Опять же, повторюсь –  этот совет для тех, кому критично использование TrueCrypt.

Спасибо тем, кто дочитал. Следите за обновлениями.

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

Влад Радецкий, McAfee Security Product Advisor

Black Hat2014_Bruce Schneier

“more vendor control – less user control… more clouds – less data control” (с) Bruce Schneier

Доклад признанного эксперта о трендах и проблемах ИТ/ИБ.

Психологические, экономические аспекты, которые оказывают влияние на ИБ.

Видеозапись доклада про BadUSB

На youtube-канале конференции BlackHat наконец-то выложили видео доклада “BadUSB”.

Как защититься от угрозы, для которой пока не придумали сигнатур, при этом не отказываться от USB?

1. Использовать комплекс решений McAfee, о которых я писал ранее;

2. Использовать накопители IronKey, которые имеют защиту на аппаратном уровне (цифровая подпись firmware+возможность запрещать произвольное обновление прошивки).

Главное, помнить, что просто “белым списком” устройств ограничиваться нельзя.

Будьте предельно осторожны и вспоминайте о BadUSB каждый раз, когда подключаете свой %device_name% к USB порту.

BadUSB, первые подробности и возможные контрмеры

infected_usbНа конференции BlackHat, которая проходила в Лас Вегасе 2-7 августа, сотрудниками компании SRlabs был представлен доклад под названием “BadUSB“, который был посвящен уязвимости USB контроллеров.  Поскольку информация о докладе уже проходила по Интернет СМИ, я не буду пересказывать все, сосредоточусь на основном: сонм USB устройств (планшеты, смартфоны, флешки, камеры, гарнитуры, принтеры и т.д.), к которому мы так привыкли в повседневной жизни может стать новым вектором кибер-угроз. Проблема заключается в том, что атакующие могут инфицировать не только файловую систему (к чему мы уже привыкли и более-менее научились защищаться), но также возможна модификация прошивки (firmware) USB устройств. Взгляните на слайд ниже:

badusb1

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

BadUSB серьезно расширяет возможности атакующего, взгляните на перечень возможных сценариев:

badusb2

А теперь о главном – о контрмерах.

Как только информация о BadUSB была опубликована в Интернете, некоторые игроки рынка DLP поспешили заявить о том, что их продукта будет достаточно для защиты от подобных угроз. Фактически заказчикам предлагалось ввести ограничение на использование устройств из “белого списка”. Мера правильная, но недостаточная (смотрите слайд выше). Почему? Потому, что “белые/черные списки” не защитят систему в случае если сотрудник подключит уже инфицированную разрешенную флешку. Этого будет достаточно для того, чтобы инфицированная система стала “нулевым пациентом”. К тому времени когда департамент ИБ обнаружит угрозу все USB устройства из “белого списка” будут инфицированы. Исследователи в своем докладе отмечают, что ограничение на использование определенных устройств само по себе не может быть достаточной мерой, хотя бы потому, что полностью исключить USB заказчик не сможет, а оставшиеся устройства рано или поздно могут быть инфицированы.

Я исхожу из тех соображений, что запущенный эксплойт уже скомпрометировал систему (либо модифицировал BIOS, либо внедрил руткит в системный процесс). Если это уже произошло – мы не имеем права полагаться на те защитные средства, которые запущены из-под ОС. Фактически, ни DLP, ни классический антивирус пока не могут дать гарантии, что злоумышленник не сможет украсть данные из целевой системы. Что нужно предпринять пока разработчики не реализовали эффективного метода проверки прошивок USB устройств?

Мои рекомендации:

(частично они будут опираться на содержимое доклада, частично – на мой опыт работы с решениями McAfee)

  1. отключить автоматическое обновление BIOS конечных точек, отключить загрузку с USB, защитить BIOS паролем;
  2. пользователи McAfee VSE могут использовать функционал Access Protection Policy* для усиления защиты ОС от перехвата системных процессов, паролей и т.д.;
  3. пользователи McAfee Device Control/DLPEndpoint могут использовать “черные/белые” списки USB устройств, однако этого не достаточно;
  4. там, где это возможно отключить авто обновление прошивки (МФУ, принтеры, сканеры);
  5. по возможности задействовать McAfee Deep Defender**, который позволит защитить ОС от выполнения эксплойта с BadUSB.

* Теперь пару слов почему я акцентирую внимание на разработках McAfee.

Во-первых, пока обычные (классические) антивирусы не научились сканировать firmware USB устройств, соответственно нет сигнатур, по которым можно было бы детектировать BadUSB и отличать обычные устройства от инфицированных. Функционал Access Protection Policy, о котором незаслуженно забывает большая часть пользователей, позволяет отсекать часть атак, направленных на механизмы ОС. К тому же, данные правила применяются для всех запущенных процессов/драйверов, не зависимо от сигнатур. Т.е. пока нет сигнатур эти настройки должны быть активированы, чтобы предотвратить изменение сетевых настроек (которое уже возможно, докладчики представили рабочий PoC), перехват системных процессов и т.д.

Во-вторых, пока разработчики популярных ОС не осознали критичности BadUSB и не внедрили возможность блэклистинга подключаемых устройств, нужно использовать McAfee Device Control, который позволит отсекать “чужие”/недоверенные устройства как по serial number, VIP/PID так и по классу. Исследователи отмечали в докладе одной из проблем блеклистинга то, что не все устройства имеют уникальный sn. Это правда. Частично эту проблему можно решить если отталкиваться не от sn, а от комбинации vendor IS/product ID либо от класса устройства, что позволяет делать McAfee Device Control / DLP Endpoint, см. слайд ниже:

devicecontrolВ-третьих, только McAfee, благодаря алиансу с intel, располагает средствами анализа выполняемого кода, которые не зависят от ОС и работают параллельно. Я говорю о McAfee Deep Defender, который использует возможности процессоров Intel, а конкретно Intel-VT. Фактически, Deep Defender является развитием идеи руткита т.н. blue pill от Joanna Rutkowska, которую McAfee повернули против самих руктитов. Фактически, Deep Defender является гипервизором первого уровня, внутри которого функционирует ОС. За счет такой архитектуры все атаки, направленные на уязвимости ОС (zero-day) а также атаки на BIOS, MBR и .т.д. будут перехватываться и блокироваться Deep Defender`ом. А поскольку он сам запускается не из-под ОС, соответственно атаки, направленные на отключение/обход классических антивирусов ему не страшны, т.к. он не зависит от ОС, которая является целью атакующего.

Пока только McAfee может предоставить такой инструмент. Остальные игроки AV/ИБ рынка могут предложить только классический антивирус, надежность которого зависит от стойкости ОС, из-под которой он запущен. (а мы с вами знаем, что любая ОС, как комплексное ПО, всегда будет содержать в себе уязвимости)

Важно то, что Deep Defender может работать параллельно с классическим антивирусом.

Таким образом, для полноценной защиты, конечные точки предприятия должны быть закрыты следующим перечнем ПО:

  • McAfee Deep Defender – защитит от эксплойтов BadUSB, упредит модификацию BIOS
  • McAfee Device Control/DLP Endpoint – позволит ограничить использование USB устройств
  • McAfee VSE – будет отсекать базовые атаки на механизмы ОС, не используя сигнатуры (которых пока на BadUSB ни у кого нет

Я бы еще добавил McAfee Drive Encryption, который позволит сразу “убить двух зайцев”:

  • обеспечить защиту от НСД и pre-boot аутентификацию;
  • защита системного раздела и раздела с данными от модификации/кражи в случае когда целевую систему систему загружают с  live CD/USB.

Если на шифрование бюджета не хватает – можно обойтись отключением загрузки с внешних накопителей в BIOS и защитой настроек последнего паролем.

В случае использования DLP Endpoint, я также советую на усиление дать ему File & Removable Media Protection (выборочное шифрование файлов и каталогов), которое будет последним эшелоном обороны – даже если эксплойт BadUSB сможет скомпрометировать систему, связка DLP Endpoint + выборочное шифрование позволит шифровать критичные данные при сохранение их на USB, не зависимо от того, кто отдал команду на копирование – пользователь или эксплойт. Даже если данные и покинут систему, воспользоваться ими злоумышленник не сможет. Эту связку я особо рекомендую тем, кто не может воспользоваться DeepDefender. (в случае использования устаревших CPU или версий ОС)

Выводы:

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

Доп. материалы:

Презентация доклада BadUSB (pdf файл, ~1.2 Mb)

Более детальная информация о McAfee Deep Defender

Будьте предельно осторожны и помните о BadUSB каждый раз, когда подключаете свое %device_name% к USB порту.

Наставление по криптографическому делу. Часть первая.

(или как управлять встроенным шифрованием Mac и Windows из одной консоли)

Суть данной заметки можно охарактеризовать простым выражением: BitLocker + FileVault + McAfee Drive Encryption = McAfee ePO. Разработчики McAfee (Intel Security) выпустили обновление Management of Native Encryption 2.0 (MNE), которое позволяет производить управление встроенными средствами шифрования Microsoft и Apple из консоли еРО, наряду с McAfee Drive Encryption (который обладает рядом преимуществ перед встроенными средствами Microsoft).

I. Пару слов о том, зачем это нужно или почему это важно для ИБ.

Во-первых, рано или поздно, независимо от сферы бизнеса, украинские компании приходят к необходимости шифрования данных на рабочих станциях персонала. Своеобразным катализатором этого процесса становится повсеместное использование ноутбуков (как личных, так и рабочих) для обработки данных компании. Очевидно, что чем солиднее бизнес предприятия, и чем выше должность сотрудника, тем дороже обойдется утеря его ноутбука. С точки зрения департамента ИБ мы получаем на входе «зоопарк» операционных систем, средства шифрования которых необходимо контролировать. Задача осложняется тем, что у Microsoft свои инструменты, а у Apple – свои и никто из них управлять «чужими» технологиями не позволяет. Таким образом, если появляется необходимость задействовать механизмы шифрования Microsoft, Apple и McAfee – раньше приходилось иметь дело с 2-3 отдельными консолями, что не лучшим образом сказывалось на безопасности. Теперь же, с появлением Management of Native Encryption 2.0 департамент ИБ может управлять тремя разными технологиями шифрования из единой консоли McAfee ePO. ePO_encryption_mgmt

Консоль ePO. Теперь можно контролировать шифрование трех вендоров из одной панели.

Во-вторых, предоставление возможности управления не только своими, но и сторонними решениями – это практическое воплощение идеологии McAfee Security Connected, согласно которой, по мере развития консоли McAfee ePolicy Orchestrator (ePO), она сможет использоваться как единая точка входа для управления всеми компонентами системы безопасности предприятия. Таким образом, заказчики могут уже сейчас ощутить преимущества управления средствами шифрования через консоль еРО. Задачи аудита и контроля зашифрованных систем значительно упрощаются, политики (настройки) для разных ОС применяются централизованно, а портал самообслуживания позволяет сотрудникам облегчить восстановление доступа к их зашифрованным системам (подробнее об этом ниже).

II. Теперь о самом решении.

Изначально, Management of Native Encryption (MNE) разрабатывался компанией McAfee как средство контроля встроенного шифрования Mac OS после выхода Mavericks 10.9 (подробнее об этом тут). Эволюция решений McAfee по шифрованию проиллюстрирована ниже:

mcafee_encryption_evolution3Процесс эволюции решений шифрования от компании McAfee

Среди нововведений второй версии MNE стоит особо выделить:

Управление встроенным шифрованием MS и Apple из консоли еРО. Преимущества данного подхода описаны выше. Остается только добавить, что MNE облегчает заказчикам процесс миграции BitLocker -> Drive Encryption. Простой пример: если сотрудник приносит на работу свой Windows ноутбук уже зашифрованный BitLocker`ом, то для контроля достаточно всего лишь установить McAfee Agent и модуль MNE из консоли еРО. В дальнейшем, если руководство/департамент ИБ определяет, что для защиты данных возможностей BitLocker не достаточно, из консоли еРО BitLocker легко отключается и вместо него разворачивается McAfee Drive Encryption. Если раньше, при установке Drive Encryption в случае наличия конфликтующего BitLocker администратору приходилось задействовать инструменты MS для отключения встроенного шифрования, то теперь, при использовании MNE 2.0 совместно с Drive Encryption 7.1 через консоль еРО этот процесс можно автоматизировать. Кроме того, состояние BitLocker на управляемых системах отражается в отчетах на консоли еРО (статус, использование портала, свойства системы, авторизованные пользователи). ePO_MNE_FV_BL_policy

Консоль еРО. Политики управления BitLocker и FileVault.

Портал самообслуживания для пользователей, чьи рабочие станции зашифрованы FileVault2 либо BitLocker`ом. Т.н. The Data Protection Self Service Portal (DPSSP) был внедрен в MNE с целью упрощения процесса восстановления доступа к зашифрованным системам. Теперь пользователи могут самостоятельно аутентифицироваться на этом портале и получить т.н. recovery key для своей системы без необходимости обращения к администратору. Все операции по выдаче ключей восстановления учитываются и сохраняются в логах аудита консоли еРО.

MNE_portalТак выглядит портал самообслуживания.

Standalone дистрибутив MNE для упрощенной установки на Mac OS системах. Представляет собой .dmg пакет, который включает в себя McAfee Agent 4.8 patch 2 и MNE. После установки данного пакета пользователь может указать данные для синхронизации с сервером еРО.

Более детально особенности Management of Native Encryption v2 описаны в базе знаний.

p.s.

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