3 мая 2018, 16:12
Количество просмотров 1389

PCI DSS в 2018 году: что вами не сделано из того, что нужно было сделать?

Летом 2018 года вступают в силу дополнительные требования PCI DSS, которые до этого момента носили рекомендательный характер. О них было известно еще с 2016 года, с момента выхода версии 3.2 стандарта.
PCI DSS в 2018 году: что вами не сделано  из того, что нужно  было сделать?

C 1 июля 2018 года все участники рынка должны отказаться от использования SSL v3 и TLS 1.0.

А еще до 31 января 2018-го все сервис-провайдеры должны были реализовать у себя дополнительные процессы безопасности.

Многие сегодня считают, что новая версия PCI DSS вступила в силу с 1 февраля 2018 года. Однако это не так – новая минорная версия может появиться в этом году. Итак, обо всем по порядку.

[caption id="attachment_402990" align="alignright" width="200"]PCI DSS в 2018 году: что вами не сделано  из того, что нужно  было сделать? - рис.1 Андрей Гайко, заместитель генерального директора Digital Compliance, дочерней структуры Digital Security[/caption]

Разговоры о необходимости отключения SSL и TLS 1.0 идут давно. Однако основная часть игроков рынка заняла выжидательную позицию, и никто не спешит «опускать рубильник». Если смотреть на предоставленную нашими клиентами статистику, то старыми версиями SSL и TLS пользуется 5–8% пользователей. Именно из-за них отключение и не происходит. Что делать с этими пользователями после 30 июня? Четкого ответа никто пока дать не может. Понятно, что на страницах оплаты интернет-магазинов и в мобильных приложениях уже сейчас выводятся сообщения о необходимости обновления пользовательского аппаратного и программного обеспечения. Но для российских компаний есть одно решение, которое позволяет не отключать SSL 3.0 и TLS 1.0. Так, в PCI DSS сказано: «PCI DSS does not supersede local or regional laws, government regulations, or other legal requirements». Платежи по банковским картам на территории РФ регулируются в рамках Федерального закона № 161-ФЗ и соответствующих подзаконных актов. В 161-ФЗ говорится о необходимости обеспечения бесперебойного функционирования платежной системы. В случае отключения SSL/TLS бесперебойность будет нарушена, а значит, будет нарушен закон. Конечно, использовать SSL 3.0 и TLS 1.0 рискованно, но что делать, если этого требует бизнес?

Однако есть и компании, которые отключают небезопасные протоколы волевым решением.

Еще в 2015 году Совет PCI SSC обнародовал свое стратегическое видение развития стандарта. Было задекларировано, что соответствие стандарту должно осуществляться на постоянной основе, в рамках повседневной деятельности, а не от аудита к аудиту. Для реализации этого подхода в версии PCI DSS 3.2 были добавлены новые требования, которые определяют периодические контрольные процедуры. В частности, это требования 6.4.6, 10.8, 10.8.1, 12.4.1, 12.11, 12.11.1 и Приложение А3. Все эти требования, за исключением 6.4.6, предъявляются только к компаниям, которые являются сервис-провайдерами. Согласно глоссарию PCI SSC, сервис-провайдером является компания, которая предоставляет услуги другим компаниям. К этой категории можно отнести, например, ЦОД с услугами co-location, а также процессинговые центры, к которым подключаются платежные шлюзы для процессинга платежей от подключенных к ним ТСП. К сервис-провайдерам нельзя причислить компании, которые занимаются эквайрингом платежей только по своим собственным картам и не предоставляют услуг интернет- или наземного эквайринга третьим сторонам.

PCI DSS в 2018 году: что вами не сделано  из того, что нужно  было сделать? - рис.2

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

Нельзя не упомянуть о таком важном нововведении, как реализация мультифакторной аутентификации при неконсольном административном доступе к компонентам среды данных держателей карт – ДДК (требование 8.3.1). Это требование обязательно для всех. Рассмотрим каждое из требований более детально.

Требование 3.5.1

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

В первую очередь будет проверяться не корректность заполнения отчета согласно шаблону, а суть изложенного, техническая сторона отчета

Уже стало классической ошибкой разделение ключа шифрования данных или ключа шифрования ключа на две половины и получение исходного ключа через конкатенацию двух половин. По оценкам автора настоящей статьи, подобная схема встречается в 80% случаев. Корневой проблемой является непонимание офицером ИБ существующей схемы шифрования защищаемых данных. Обычно в ходе аудита мы с офицерами ИБ по шагам расписываем всю схему шифрования – где и каким образом генерируются ключи, в каком виде и как передаются, кем и куда вводятся, где и в каком виде хранятся после ввода в эксплуатацию, как организована смена ключей. После такого упражнения мы получаем наглядную картину процесса. Становятся понятными все узкие места существующей схемы шифрования данных и управления ключами. Для того чтобы заставить организации самим вникать в процессы шифрования хранимых данных и минимизировать угрозы, связанные с некорректной работой с ключами шифрования, появилось новое требование 3.5.1. Если в целом смотреть на требования PCI DSS к шифрованию хранимых ДДК, то можно провести достаточно четкие параллели с требованиями стандарта PCI PIN Security.

В PCI DSS пропагандируются все те же принципы, но есть и несколько отличий. В PCI DSS такого рода требования указаны в кратком изложении и применяются в отношении данных держателей карт, а не критичных аутентификационных данных (КАД). В PIN Security много говорится о работе с HSM, поскольку это устройство используется для оперативной работы с КАД. В случае шифрования номеров карт обычно используют встроенные функции шифрования прикладного ПО или средства СУБД. Если руководствоваться принципами PIN Security в отношении ключей шифрования ДДК и требованиями к документированию этих процессов, то мы получим раздел 3 требований PCI DSS.

Авторы стандарта вряд ли когда-либо распишут требования к шифрованию PAN так же детально, как это сделано в отношении ПИН-блоков в PCI PIN Security. Но уже сегодня мы можем понять, «откуда ноги растут», что взято за основу и с привязкой к чему будет развиваться раздел 3 PCI DSS.

Требование 6.4.6

PCI DSS в 2018 году: что вами не сделано  из того, что нужно  было сделать? - рис.3Некоторые из новых требований являются обобщением существующих либо уточняющими их. В настоящем пункте мы имеем дело именно с таким случаем. Требование 6.4.6 говорит о необходимости применения всех существующих требований PCI DSS к новым или изменяемым системам. Если говорить более формально, то в рамках существующего процесса управления изменениями должна присутствовать активность по контролю документации, на актуальность которой влияет изменение, а также активность по анализу и настройке новой/изменяемой системы в соответствии с требованиями PCI DSS. Сложность реализации этого требования в том, что в компании должен быть человек, достаточно хорошо разбирающийся в PCI DSS. Он должен быть способен оценить каждое изменение на предмет его влияния на соответствие PCI DSS или добавить в тикет на изменение подзадачи для применения соответствующих настроек безопасности к этому изменению. При отсутствии выделенного сотрудника эти задачи должны выполнять сами сотрудники, участвующие в изменении.

Требования 10.8 и 10.8.1

В отличие от остальных требований PCI DSS, данные требования направлены на обеспечение доступности сервисов, в частности, средств защиты. Для выполнения требования 10.8 большим подспорьем будет наличие в компании SIEM или системы мониторинга (например, Zabbix). Компании необходимо настроить мониторинг событий, связанных с нарушением функционирования МЭ, IDS/IPS, антивируса, СКУД, видеонаблюдения (при наличии), механизмов журналирования событий, механизмов сегментации (например, появления явно небезопасных правил на МЭ). Требование 10.8.1 говорит о порядке реагирования на отказ средства защиты и документировании события.

PCI DSS в 2018 году: что вами не сделано  из того, что нужно  было сделать? - рис.4

Требование 12.4.1

Это требование – наиболее пространное из всех новых и стоит в одном ряду с требованием 12.2 об оценке рисков. Формализм его очевиден, но его практическая составляющая вызывает много вопросов и недопонимания. Стоит начать с разработки высокоуровневого устава PCI DSS, который декларирует цели и задачи компании по соответствию PCI DSS. В уставе или отдельным приказом должна быть определена роль ответственного за программу соответствия и его взаимодействие с руководством компании. На практике подразумевается, что выделенный человек будет следить за статусом соответствия PCI DSS в течение года и при сертификации. Он периодически будет встречаться с руководством и сообщать о текущей ситуации, о проблемах в реализации требований и требуемых стратегических решениях. Основной вопрос, с которым приходится сталкиваться по этому требованию: «кого из руководителей компании следует вовлекать в этот процесс?». Стандарт говорит, что это может быть как совет директоров, так и представители топ-менеджмента, относящиеся к С-level. На практике мы бы советовали включить в процесс руководителя, который понимает влияние статуса соответствия PCI DSS на текущий бизнес компании и благодаря этому мог бы решать стратегические вопросы в рамках программы соответствия.

Требования 12.11 и 12.11.1

Появление данных требований является достаточно предсказуемым событием. Как соблюдать их без периодического контроля? Именно поэтому в PCI DSS появились зачатки требований по внутреннему аудиту. Для их реализации следует выделить сотрудника, который независим от проверяемых процессов. Для него можно сделать подробный чек-лист и форму отчета. Раз в квартал сотрудник будет проверять корректность выполнения процессов мониторинга событий ИБ и реагирования на них, пересмотра правил МЭ, применения стандартов конфигураций к новым системам, соблюдение установленного порядка управления изменениями. Стоит обратить внимание на периодичность проведения проверок. «Ежеквартально» значит проведение мероприятия максимум каждые 90 дней. Т. е. последующая проверка должна быть проведена через 3 месяца со дня окончания предыдущей. Некоторые трактуют понятие «ежеквартально» иначе. Например, проводят мероприятие 1 января, а последующее – 1 июня. Получается разбег в пять месяцев. Обосновывают это тем, что первая проверка была в первом квартале, вторая во втором. Но это неверный подход.

PCI DSS в 2018 году: что вами не сделано  из того, что нужно  было сделать? - рис.5

Требование 8.3.1

Данное требование говорит о необходимости использования мультифакторной аутентификации (далее – МФА) при неконсольном административном доступе к сис-темным компонентам в области дейст-вия стандарта PCI DSS. Как известно, под мультифакторной подразумевается

аутентификация по двум и более факторам. Таким образом, сотрудники, обладающие административными правами на системном уровне, должны проходить мультифакторную аутентификацию при подключении к системам в контуре PCI DSS. Для системных учетных записей и учетных записей приложений МФА не требуется. Это требование не применяется и к администраторам прикладного карточного ПО.  Стоит понять, на каком уровне и в каких случаях применять МФА. Если среда ДДК является выделенной, изолированной сетью, то МФА может быть настроена только на пограничном jump-хосте. Если jump-хост отсутствует, то МФА следует настроить на каждом узле (сервере, сетевом оборудовании) в среде ДДК. Если АРМ администратора размещен внутри среды ДДК, то МФА может быть настроено на самом АРМ.

Своевременное выполнение требований. Примеры

При использовании услуг сторонних организаций вам следует обратить особое внимание на требования 2018 года

Отдельного упоминания заслуживает тот факт, что если компания обязалась выполнять требования PCI DSS, то она должна это делать вовремя. Поясним на примере. В середине весны 2018 года у одного клиента был сертификационный аудит. В середине лета 2017 года клиент перенес всю свою платежную инфраструктуру в «облако» одного IaaS-провайдера. IaaS-провайдер сертифицировался в начале лета 2017 года. На аудите выяснилось, что IaaS-провайдер не предоставил вовремя матрицу разделения ответственности за выполнение требований PCI DSS между собой и клиентом (требование 12.8.5). К IaaS-провайдеру были предъявлены претензии. В итоге матрица была разработана только после нашего обращения. Доступ к панели управления виртуальными серверами клиента предоставлялся через веб-консоль провайдера. Как уже было сказано выше, с 1 февраля 2018 года вступило в силу требование 8.3.1 о мультифакторной аутентификации. Поскольку веб-консоль предоставляет неконсольный административный доступ к платежной инфраструктуре клиента, то здесь должна применяться мультифакторная аутентификация. IaaS-провайдер на момент аудита клиента не реализовал этот функционал и сообщил, что реализует его к своей сертификации летом 2018 года. В итоге процесс сертификации нашего клиента подвис. К счастью, у клиента был толковый специалист, который за неделю смог решить эту проблему своими силами.

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


PCI DSS в 2018 году: что вами не сделано  из того, что нужно  было сделать? - рис.6Анна Гольдштейн, заместитель начальника управления безопасности АО «НСПК»

«ПС «Мир» действительно вводит собственную программу контроля качества аудитов, цель которой – повышение уровня доверия к результатам проводимых аудитов. Наша задача – оперативно выявлять типовые проблемы и недоработки аудиторов или методик аудита, которые не позволяют оценить фактический уровень защищенности участников платежной системы и постоянство реализованных ими процессов обеспечения безопасности. Такие недоработки не дают уверенности в поддержании требуемого уровня без-опасности, который важен не только для отдельно взятого банка или платежного шлюза, но и в контексте платежной системы в целом, как гарантия безопасности выполняемых в ней платежей».

PCI DSS в 2018 году: что вами не сделано  из того, что нужно  было сделать? - рис.7Евгений Бабицкий, QSA-аудитор

«Новые требования PCI DSS 3.2 в очередной раз показали нам направление, в котором будут двигаться разработчики стандарта и все, кто имеет отношение к этой сфере. Если посмотреть на эволюцию стандарта с версии 1.0 до 3.2, то можно заметить несколько важных вещей:

  • Стремление к внедрению лучших практик в day-to-day процессы компаний;
  • Сохраняющийся баланс между требованиями, направленными на техническую и документационную реализацию.

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

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


О новой версии PCI DSS

В 2018 году планируется выход новой минорной версии стандарта PCI DSS. В стандарт будут внесены несущественные изменения. Будут удалены упоминания старых версий небезопасных алгоритмов и протоколов, нотации о вступлении в силу требований в 2018 году.

В настоящий момент в рабочей группе по PCI DSS в PCI SSC ведутся работы над новой мажорной версией, но даты выхода пока неизвестны.

PCI DSS в 2018 году: что вами не сделано  из того, что нужно  было сделать? - рис.8

Программа безопасности ПС «Мир»

Стандарт PCI DSS глобальный и действует по всему миру. Совет не может принимать меры быстро и контролировать всех потребителей стандарта. Поэтому новые требования вводятся постепенно и «не спеша». Если говорить о нашем локальном рынке, то у нас те же самые проблемы, что и у коллег из других стран – часть организаций демонстрирует соответствие PCI DSS только во время аудита. На 10-м Уральском форуме «Информационная безопасность финансовой сферы», прошедшем в феврале этого года, состоялось выступление представителя НСПК, курирующего программу безопасности ПС «Мир». В рамках выступления было рассказано о схемах подтверждения соответствия PCI DSS для процессоров, сервис-провайдеров и торгово-сервисных предприятий. Данную программу безопасности планируется вводить в действие в 3-м квартале 2018 года.

Года через два требуемые практики безопасности могут быть гармонично интегрированы в существующие бизнес-процессы и перестанут вызывать раздражение

Одним из наиболее значимых нововведений в этой программе является контроль качества аудиторов по PCI DSS. При беглом рассмотрении может показаться, что это формальная процедура, которая ни на что не влияет. Но на самом деле в ней есть важный подтекст. Контроль будет проводиться путем изучения отчетов Report on Compliance, которые должны будут предоставляться НСПК вместе с АОС по результатам аудита. В настоящий момент подобная схема действует и у Visa. В первую очередь будет проверяться не корректность заполнения отчета согласно шаблону, а суть изложенного, техническая сторона отчета. Будет даваться оценка корректности, полноты и достаточности проведенного аудита.

Вспомним о концепции непрерывного соответствия. Аудитор всегда понимает, какие данные ему дает клиент в качестве доказательств – будет ли это годовой журнал, который заполнили 30 минут назад, или это действительный журнал, заполняемый в течение года. Таким образом, НСПК может составлять свое мнение и о непосредственно самих QSA-аудиторах, и о QSA-компаниях, в которых эти аудиторы работают. В итоге участникам ПС «Мир» и QSA-аудиторам придется более качественно выполнять свою работу.

Резюме

Подводя итоги обсуждения вступивших в силу требований направления развития стандарта и планов ПС «МИР», можно сделать вывод о том, что все текущие и будущие изменения ставят своей целью непрерывное соответствие требованиям PCI DSS. Если говорить проще, то защита информационных активов должна быть постоянной и непрерывной. Чтобы начать всерьез этим заниматься, не нужно ждать череды инцидентов. Нужно постоянно действовать на опережение. Как показывает практика, если в компании нет скептического отношения к стандартам безопасности, то года через два требуемые практики безопасности могут быть гармонично интегрированы в существующие бизнес-процессы и перестанут вызывать раздражение.

Рубрика:
{}
Теги:
#

PLUSworld в соцсетях:
telegram
vk
dzen
youtube