Блог

Опубликован стандарт PCI Card Production and Provisioning версии 2.0

Автор: Кристина Андреева

Новому 2017 году в платежной индустрии положила начало публикация версии 2.0 стандарта индустрии платежных карт по обеспечению безопасности изготовления и подготовки платежных карт (PCI Card Production and Provisioning) на сайте Совета PCI SSC. Напомню, что действие стандарта распространяется на такие операции, как изготовление платежных карт, кодирование и запись магнитной полосы, эмбоссирование данных на карте, инициализация, внедрение и персонализация чипа, хранение карт, их перевозка и отправка.

Публикация новой версии стандарта и количество нововведений, относящихся к мобильным технологиям, свидетельствует от том, что Совет PCI SSC о них не забывает. Еще в 2012 году Совет выпустил ряд рекомендаций по мобильным платежам, это две версии документа «PCI Mobile Payment Acceptance» — одна для мерчантов и конечных пользователей, а вторая для разработчиков. А на PCI DSS Middle East Forum в 2016 году Совет высказал свою озабоченность следующими проблемами в работе с мобильными устройствами: вездесущая неосведомленность пользователей, подключение к небезопасным сетям передачи данных, потеря устройств или же их кража и использование слабых паролей доступа к устройствам. Да и в целом, информацию нетрудно перехватить с использованием сотовой связи, WI-FI-каналов, бесконтактных технологий и путем внедрения различных вредоносов.

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

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

Хранение в мобильном устройстве данных, необходимых для оплаты, включает в себя использование элемента безопасности, или Secure Element (SE), а также решения Host Card Emulation (HCE). SE — это особый чип в мобильном телефоне, который может быть размещен на съемной microSD карточке, встроен в SIM-карту или же встроен в само устройство, его использование необходимо в случае, если вы хотите оплачивать свои покупки путем использования мобильного телефона. HCE — это режим эмуляции платежной карты, который позволяет мобильному устройству привязать платежную карту и выполнять оплату в случае, если в устройство не встроен SE.

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

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

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

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

Напомню, что стандарт включает в себя два документа: документ по физической безопасности (PCI Card Production and Provisioning: Physical Security Requirements) и документ по логической безопасности (PCI Card Production and Provisioning: Logical Security Requirements).

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

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

• раздел 4.1.4 по защите данных в соответствии с классификацией (секретные, конфиденциальные и общедоступные);
• раздел 4.9 по ведению вендором электронного журнала успешных и неуспешных операций по мобильной персонализации;
• раздел 4.10 по выводу из эксплуатации;
• раздел 5.1.6 по защите сетей мобильной персонализации;
• раздел 6.5 по резервированию и восстановлению сетей мобильной персонализации;
• раздел 6.7. по использованию веб-сервисов как интерфейсов эмитента.

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

Что касается использования веб-сервисов, Совет ввел требования об обеспечении взаимной аутентификации клиента и сервера путем использования x.509 сертификатов, установки VPN-соединений в соответствии с разделом 5.6.2, внедрения межсетевого экрана прикладного уровня и обеспечение контроля целостности сообщений. Также отдельное требование касается использования последней одобренной версии протокола TLS. Я надеюсь, что все читатели этой статьи уже давно выгнали пуделей (уязвимость протокола SSL под номером CVE-2014-3566, «POODLE») из своей инфраструктуры или активно работают над этим.

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

Появилось и так называемое «future-dated requirement». С января 2018 года, все развертываемые устройства по загрузке ключей должны быть SCD: или PCI-approved, или иметь сертификацию FIPS 140–2 уровня 3 и выше по физической безопасности.

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

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

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

• анализ журналов событий СКУД — еженедельно;
• анализ журналов событий IDS/IPS систем — ежедневно;
• анализ журналов событий WiFi устройств и серверов аутентификации — еженедельно;
• анализ журналов событий роутеров и мониторинг использования учетных записей для доступа к БД, приложениям, ОС — ежемесячно;
• мониторинг доступа администраторов к БД — еженедельно;
• пересмотр прав физического доступа работника при смене должностных обязанностей — в течении дня;
• пересмотр правил и конфигурации межсетевого экрана — ежемесячно или ежеквартально при условии выполнения анализа после каждого изменения конфигурации.

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

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

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

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

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

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

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

В оба документа добавились новые довольно полезные приложения. Новое приложение, А определяет применимые требования документов к различным бизнес-процессам:

• персонализация физических карт;
• мобильная персонализация с использованием SE;
• мобильная персонализация с использованием HCE.

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

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

И все это — только малая часть изменений. На самом деле их гораздо больше, поэтому всем безотлагательно рекомендую ознакомиться с новой версией стандарта, которая доступна на сайте Совета по ссылке: https://www.pcisecuritystandards.org/document_library. Думаю, вы найдете ее познавательной.

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

0

Добавить комментарий