15 апреля 2015 года Совет по стандартам безопасности Индустрии платежных систем (PCI SSC) опубликовал внеочередную версию стандарта безопасности данных (PCI DSS v.3.1), ограничивающую использование протоколов SSL и TLS ранних версий.
| SSL – Secure Sockets Layer v3.0 – криптографический протокол, предназначенный для защиты соединений в компьютерных сетях, считался стойким криптографическим протоколом с 1996 по 2014 год. |
Ограничение на использование протоколов SSL и TLS вводится в связи с признанием Государственным институтом стандартов и технологий (США) протоколов SSL всех версий, протокола TLS версии 1.0 и отдельных реализаций TLS версии 1.1 (далее – уязвимые версии протоколов) не соответствующих понятию «стойкая криптография», а также в связи с появлением атак, использующих уязвимости данных протоколов.
| TLS – Transport Layer Security – протокол, предназначенный для обеспечения конфиденциальности и целостности данных, передаваемых между двумя приложениями. Первая версия протокола была разработана в 1999 году. В 2008 году вышла версия 1.2, которая используется по настоящее время.
В 2011 году в TLS были запрещены к использованию для обеспечения обратной совместимости SSL v2.0 и более ранние версии. Сервер должен отвечать отказом на подключение клиентов, использующих устаревшие версии протоколов. C 2014 года многие производители стали использовать TLS Fallback Signaling Cipher Suite Value (TLS_FALLBACK_SCSV) для предотвращения перехода на уязвимые версии протоколов, когда и клиент и сервер поддерживают более безопасные версии. |
Необходимость издания внеочередной версии стандарта связана с тем, что уязвимые протоколы были упомянуты в качестве примеров стойкой криптографии в ряде требований PCI DSS v3.0.
В соответствии с новой версией стандарта в решениях, в которых нет обоснованной необходимости использовать уязвимые версии протоколов, использование этих версий должно быть запрещено незамедлительно.
| Государственные агентства США должны были перейти на TLS 1.2 до 1 января 2015 года. |
Организации, использующие решения, в которых есть обоснованная необходимость использовать уязвимые версии протоколов, обязаны разработать план обработки рисков и миграции, для каждого такого решения. Работы по планам должны быть завершены до 30 июня 2016 года.
После 30 июня 2016 года уязвимые версии протоколов не могут использоваться в качестве защитной меры.
Терминалы в точках продаж (POS) и точках взаимодействия с клиентом (POI) могут продолжать использовать уязвимых версий протоколов (в том числе после 30 июня 2016 года), при наличии подтверждения, что имеющиеся уязвимости не могут быть использованы.
На сайте PCI SSC, также опубликовано информационное дополнение (Migrating from SSL and Early TLS), которое содержит рекомендациями по миграции с уязвимых версий проколов и ответы на наиболее острые вопросы.
| В 2014 году была успешно проведена атака PODDLE на SSL 3.0 использующий режим сцепления блоков шифротекста (CBC). Атака позволяет злоумышленнику расшифровывать предаваемую информацию направив 256 запросов серверу от имени клиента.
Эта уязвимость является уязвимостью протокола и не может быть исправлена разумными усилиями. Использование потоковых шифров в SSL 3.0 ограничено RC4, который и стал практически единственной альтернативой использованию CBC после появления атак на TLS типа BEAST в 2011 году. Однако и RC4 в 2013 году был взломан. |
В новой версии стандарта внесено также несколько уточнений, улучшающих восприятие стандарта, из наиболее существенных следует отметить следующие:
– Перед проведением ежегодной оценки соответствия требованиям PCI DSS организации должны кроме прочего идентифицировать системы, подключенные к среде данных владельцев карт, и системы, компрометация которых может повлиять на эту среду;
– Отчетные документы (SAQ – вопросник для самооценки или ROC – отчет о соответствии и AOC – аттестат соответствия для поставщиков услуг и торгово-сервисных предприятий) должны быть заполнены и совместно с результатами ASV-сканирования отправлены в контролирующие организации, даже если в ходе оценки соответствия были выявлены несоответствия. После устранения несоответствий должен быть представлен обновленный отчет.
– В ходе оценки соответствия в среде, в которой присутствуют усеченные и хешированные номера одних и тех же платежных карт, необходимо проверить невозможность восстановления полного номера карты путем соотнесения усеченного и хешированного значения.
– В явном виде запрещена отправка незащищенного номера платежной карты через SMS.
– Если системы обнаружения web-атак не блокируют их, должны применяться соответствующие процедуры реагирования на эти атаки.
– Процедуры, позволяющие отличить посетителей от работников, должны предусматривать идентификацию всего персонала (не только нового) и посетителей.
– Тестирование на проникновение должно предусматривать проверку изоляции среды данных платежных карт (а не всех систем, на которые распространяются требования PCI DSS) от систем, на которые эти требования не распространяются.
– Сканирование на уязвимости может осуществляться не только с использованием автоматизированных средств, но и иных средств, способов и методов выявления уязвимостей.
– Требования 3.6, 8.5.1, 12.9 PCI DSS v3.1 и процедуры проверки 8.1.6.b, 8.2.1.d, 8.2.1.e, 8.2.3.b, 8.2.4.b, 8.2.5.b распространяются только на организации, выступающие в роли поставщиков услуг.
Для тех, кто уже начал проводить оценку соответствия по PCI DSS v3.0, предыдущая версия стандарта продолжает действовать до 30 июня 2015 года.