Стандарт PCI Card Production and Provisioning версии 2.0. Ответ «мобильным» вызовам времени
Напомню, что действие стандарта распространяется на такие операции, как изготовление платежных карт, кодирование и запись магнитной полосы, эмбоссирование данных на карте, инициализация, внедрение и персонализация чипа, хранение карт, их перевозка и отправка.
Акцент на мобильные технологии
Публикация новой версии стандарта и количество нововведений, относящихся к мобильным технологиям, свидетельствует о том, что Совет PCI SSC о них не забывает. Еще в 2012 году Совет выпустил ряд рекомендаций по мобильным платежам: две версии документа «PCI Mobile Payment Acceptance» – одна для мерчантов и конечных пользователей, а другая для разработчиков.
А на PCI DSS Middle East Forum в 2016 году Совет выразил свою озабоченность следующими проблемами в работе с мобильными устройствами: вездесущая неосведомленность пользователей, подключение к небезопасным сетям передачи данных, потеря устройств или же их кража и использование слабых паролей доступа к устройствам. Да и в целом критичную информацию нетрудно перехватить с использованием сотовой связи, Wi-Fi-каналов, бесконтактных технологий и путем внедрения различных вредоносов.
На фоне бурного развития индустрии мобильных платежей выпуск новых требований по безопасности регулятором стал жизненно необходим. Об этом свидетельствует хотя бы тот факт, что сегодня появилась и по-прежнему активно применяется возможность использования мобильного телефона вместо платежной карты с привязкой карточных данных к телефону. Оплата в этом случае происходит с использованием технологии бесконтактных платежей NFC, а для ее проведения необходима установка на мобильное устройство специального мобильного приложения.
Поэтому рядом с золотым правилом Совета «не нужно – не храни» появилось новое – «сделай информацию бесполезной для злоумышленника». В качестве решения этой задачи предлагается вместо номера карты использовать токены, что не позволит злоумышленнику перехватить полные номера карт (наглядный пример – Samsung Pay и Apple Pay).
при выводе из эксплуатации является немаловажной даталью, о которой многие забывают
Хранение в мобильном устройстве данных, необходимых для оплаты, включает в себя использование элемента безопасности, или 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 минут простоя сессию можно прерывать вручную до истечения данного срока. Разрешено также использование встроенной учетной записи администратора СКУД, если ее блокировка технически невозможна.
С точки зрения физического доступа, довольно важно то, что в стандарте теперь в явном виде прописали разрешение не запечатывать коробки с инвентарем (например, заготовками карт или ПИН-конвертами) в случае, если доступ к ним в течение дня довольно частый. При этом понадобится внедрение процедуры учета и инвентаризации содержимого каждого ящика.
Немаловажным является изменение критериев использования бронированных и небронированных транспортных средств при перевозке платежных карт. Например, в случае использования бронированного средства остановки при перевозке груза разрешены только в том случае, если при этом груз остается под присмотром.
При изучении нового текста стандарта весьма порадовала конкретизация требования по разделению обязанностей:
работник, задействованный в производстве ПИН-конвертов, может быть задействован в любой другой деятельности, не позволяющей ему получить доступ к ДПК;
- персонал, задействованный в персонализации, никогда не должен быть задействован в печати ПИН-конвертов.
Требование стало звучать более ясно и определенно. Также обнаружила много пересечений с уже давно разработанными требованиями стандарта PCI DSS, как, например, следующие:
- только администратор БД может иметь прямой доступ к базе данных, иные пользователи могут подключаться только программными методами;
- пароль пользователя должен шифроваться при передаче и храниться в нечитаемом виде;
- должен быть разработан и внедрен стандарт конфигурации межсетевого экрана в соответствии с лучшими практиками;
- процедура управления изменениями должна включать в себя утверждение каждого изменения ответственным лицом, описание возможного влияния изменения и процедуры отката изменения, ведение лога изменения, фиксирование результатов изменения даже в случае его неуспеха;
- поток карточных данных и данных, используемых в облачной персонализации, от момента получения/генерации данных и до конца их жизненного цикла должен быть задокументирован;
- все авторизованные на устройстве межсетевого экранирования сервисы должны быть обоснованы, документированы и утверждены менеджером по ИБ;
- входящий и исходящий трафик на устройстве межсетевого экранирования должен быть явно ограничен, для всех остальных соединений должно быть однозначно прописано правило «deny all».
Незначительные изменения коснулись терминологии. В стандарт были добавлены новые термины, а также внесены терминологические правки в текст стандарта, например, термин «непробиваемое» стекло заменен на «пуленепробиваемое», а термин «датчик удара» – на «защитное средство обнаружения взлома».
В оба документа добавились новые довольно полезные приложения. Новое приложение «А» определяет применимые требования документов к различным бизнес-процессам:
- персонализация физических карт;
- мобильная персонализация с использованием SE;
- мобильная персонализация с использованием HCE.
Приложение «Б» документа по физической безопасности определяет требования по логическому управлению системами видеозаписи и контроля доступа.
Приложение «Б» документа по логической безопасности определяет вполне полезные примеры корректной топологии сети. Так, например, одним из требований является наличие устройства межсетевого экранирования между любой внешней сетью и DMZ-сетью, а также между DMZ-сетью и сетью облачной персонализации. Это приложение может оказаться полезным при организации сетевой инфраструктуры.
И все это – только малая часть изменений. На самом деле их гораздо больше, поэтому всем безотлагательно рекомендую ознакомиться с новой версией стандарта, которая доступна на сайте Совета по ссылке: https://www.pcisecuritystandards.org/document_library. Думаю, вы найдете ее познавательной.
Что касается внедрения новых требований в своей инфраструктуре, стоит не затягивать и уже начинать планирование. Сам Совет PCI SSC рекомендует вендорам обратиться к международным платежным системам и уточнить сроки, к которым новые требования по безопасности должны быть выполнены.