BIS Journal №1(12)/2014

15 апреля, 2014

PCI DSS. Переход с версии 2.0 на 3.0. Инструкция

В течение всего 2014 года поставщики услуг и торгово-сервисные предприятия вольны выбирать, по какой из версий стандарта они будут проходить аудит – старой или новой. И только с 1 января 2015 года версия 3.0 станет единственной. А пока у нас есть время, мы решили поделиться наработками и рассказать, как сертифицированным организациям плавно перейти с PCI DSS 2.0 на PCI DSS 3.0.

 

КОНФИГУРАЦИЯ ИНФРАСТРУКТУРЫ И ЕЕ КОМПОНЕНТОВ

В новой версии стандарта появился перечень логов, которые обязательно нужно анализировать каждый день. Делать это нужно было и раньше, но однозначного перечня не было. Остальные логи, не вошедшие в перечень, также должны изучаться, но с периодичностью, определяемой по результатам анализа рисков. Таким образом, формулируем первые две задачи:

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

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

Появился запрет на хранение критичных аутентификационных данных даже если в системе нет номера карты, к которой они относятся. Критичные аутентификационные данные – это ПИН-код, его ПИН-блок, полные данные магнитной дорожки или чипа, а также проверочные значения CVC2/CVV2. Хранить их нельзя было и раньше, но во введении стандарта говорилось, что он применим только если в информационной инфраструктуре присутствуют номера карт. Так что, формулируем следующую задачу:

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

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

РАЗРАБОТКА СОФТА. СОБСТВЕННАЯ И ПОД ЗАКАЗ

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

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

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

Задача 5. Проверить, что штатные разработчики программного обеспечения проходят обучение тому, как не допускать общеизвестные уязвимости в коде и как безопасно обрабатывать данные в оперативной памяти.

POS-ТЕРМИНАЛЫ

Пожалуй, самое существенное изменение в стандарте – это появление требования о защите POS-терминалов от подмены и несанкционированного изменения. Совет PCI SSC обратил внимание, что скимминг и прочие способы прямого копирования данных с карт занимают значительную долю среди всех видов карточного мошенничества, но в стандарте до сих пор отсутствовали требования непосредственной защиты от них. Три следующие задачи прямо обозначены в новом требовании:

Задача 6. Создать и постоянно поддерживать в актуальном состоянии перечень POS-терминалов с указанием производителя, модели, месторасположения и серийного номера.

Задача 7. Организовать периодическую инвентаризацию всех POS-терминалов и проверку, что они не подменены и их конфигурация не претерпела несанкционированных изменений.

Задача 8. Организовать регулярное обучение работников тому, что нельзя подпускать посторонних к POS-терминалам, можно использовать только проверенные терминалы, а также тому, как опознать попытки мошенничества с POS-терминалами и куда о них сообщать.

Новое требование пока что ограничивается только этими мерами защиты и применяется только к POS-терминалам.

ДОКУМЕНТЫ И ЗАПИСИ ОБ ИХ ВЫПОЛНЕНИИ

Все изменения, которые вы сделаете для перехода к версии PCI DSS 3.0, должны найти свое отражение во внутренних нормативных документах организации. О некоторых изменениях в документах мы уже упомянули выше. Кроме того, в стандарте появилось новое понятие – business-as-usual. Этот термин призван обозначить собирательный образ заботы о соблюдении требований PCI DSS, которую нужно внедрить в повседневную жизнь организации и всех ее сотрудников.

Действия по обеспечению business-as-usual составлены в основном из элементов тех требований, которые существовали и раньше. Из нового стоит отметить две регулярные процедуры. Речь идет о регулярных внутренних аудитах соответствия организации требованиям PCI DSS и о регулярных проверках того, что используемые в компании технологии и продукты поддерживаются производителем и по-прежнему способны обеспечить требуемый уровень безопасности. Частота внутренних аудитов может быть определена на основе результатов анализа рисков.

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

Задача 9. Разработать и внедрить документированную процедуру регулярных внутренних аудитов. Цель аудита – убедиться в выполнении требований стандарта PCI DSS в организации.

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

Задача 11. После завершения проекта по переходу организации на PCI DSS 3.0 проверить, что все изменения в конфигурациях, технологиях и бизнес-процессах учтены во внутренних нормативных документах.

Задача 12. Проверить, что все регулярные процедуры, предусмотренные стандартом PCI DSS, корректно отражены во внутренних нормативных документах.

Задача 13. Составить и постоянно поддерживать в актуальном состоянии перечень компонентов информационной инфраструктуры.

СОТРУДНИКИ

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

Задача 14. Довести новые и обновленные внутренние нормативные документы до сведения ответственных сотрудников, организовать обучение и проверку знаний.

ЗАКЛЮЧЕНИЕ

Таковы самые яркие нововведения PCI DSS 3.0. Для безошибочного перехода с предыдущей версии на новую необходим тщательный анализ бизнес-процессов и информационной инфраструктуры организации. Поэтому с января 2014 года мы запускаем новую услугу – перевод сертифицированной организации с PCI DSS 2.0 на PCI DSS 3.0.

Эту услугу мы будем продвигать, прежде всего, в составе пакета услуг по ежегодному подтверждению соответствия PCI DSS. Уверен, что она окажется востребованной среди наших постоянных и новых клиентов.

 

BIS СПРАВКА

Deiteriy – поставщик услуг информационной безопасности – обладает статусами PCI QSA и PCI PA-QSA, является организацией-аудитором НП АБИСС и членом технического комитета по стандартизации «Защита информации» (ТК 362).

Аудиторские заключения Deiteriy, выполненные по стандартам PCI DSS и PA DSS признаются международными платёжными системами Visa, MasterCard, American Express, Discover и JCB, а по стандарту СТО БР ИББС и Федеральному закону Российской Федерации № 161-ФЗ «О национальной платёжной системе» – Банком России.

Компания обладает лицензией ФСТЭК России на выполнение работ по технической защите конфиденциальной информации, в том числе персональных данных в соответствии с Федеральным законом Российской Федерации № 152-ФЗ «О персональных данных».

Стать автором BIS Journal

Смотрите также

Подписаться на новости BIS Journal / Медиа группы Авангард

Подписаться
Введите ваш E-mail

Отправляя данную форму вы соглашаетесь с политикой конфиденциальности персональных данных

28.03.2024
Аитов: Ограничения Samsung Pay на использование карт «Мир» можно обойти
28.03.2024
Киберпреступления — 35% всех преступлений в России
27.03.2024
Samsung Pay перестанет дружить с «мировыми» картами
27.03.2024
Канадский университет восстанавливает работу после ИБ-инцидента
27.03.2024
Crypto Summit 2024. Трейдинг, майнинг и перспективы развития рынка ЦФА
27.03.2024
РКН начал работу по контролю за «симками» иностранцев
26.03.2024
Регулятор порекомендовал банкам и МФО списать долги погибших в теракте
26.03.2024
Хакеры не оставляют Канаду в покое
26.03.2024
Binance снова ищет покупателя на свои российские активы
26.03.2024
Безумцы или сознательные соучастники. Кто потворствует кредитным мошенникам

Стать автором BIS Journal

Поля, обозначенные звездочкой, обязательные для заполнения!

Отправляя данную форму вы соглашаетесь с политикой конфиденциальности персональных данных