25 мая, 2011, BIS Journal №2(2)/2011

PCI DSS / PA DSS: как это будет по-русски?


Бурлакова Ирина

Инженер отдела консалтинга и аудита (ЗАО «Энвижн Груп»)

Огородников Дмитрий

Директор департамента информационной безопасности (ЗАО «Энвижн Груп»)

Часть 1: Специфика внедрения

ПРЕДИСЛОВИЕ РЕДАКЦИИ
По мере всё более широкого распространения карточных платежных систем растёт количество трансграничных транзакций. Заблаговременно нейтрализовать потенциальные информационные угрозы этой индустрии в любой стране помогает выполнение требований стандарта информационной безопасности платежных карт PCI DSS (Payment Card Industry Data Security Standard). Разработан он был совместно крупными платежными системами − MasterCard Worldwide, Visa International, American Express, Discover Financial Services и JCB и действует с 30 июня 2006 года.
Какова сегодняшняя практика применения этих норм в России, в чём проблемы и как они решаются, как оцениваются дальнейшие перспективы? Площадкой для обсуждения этой актуальной проблематики была определена Межбанковская конференция «Вопросы применения и соответствия стандартам PCI DSS / PA DSS». Намеченный на 16 июня 2011 года форум при официальной поддержке Банка России проводят Ассоциация российских банков и сообщество ABISS при организационном содействии компаний «Авангард Центр» и «ФортКонсалт».
Список обсуждаемых на форуме вопросов обширный, если не сказать всеобъемлющий. В первую очередь это «национальные особенности» внедрения и применения стандартов PCI DSS / PA DSS, в частности − соотношение с нормами стандарта Банка России по информационной безопасности. Практиков заинтересует, насколько предъявляемые требования удаётся выполнять банкам-эмитентам, процессинговым центрам и другим «звеньям» операционной цепочки. Не останутся без внимания сопутствующие темы − сертификации соответствия, контроля качества предоставляемых услуг и аудит, деятельности PCI Security Standards Council и обучение QSA.
Предваряя дискуссии, редакция на страницах журнала «BIS Journal − Информационная безопасность банков» даёт возможность представить своё видение представителям типичных участников подобных отраслевых деловых мероприятий. С одной стороны − сотрудникам компаний, которые работают на рынке информационных услуг, регулируемых требованиями PCI DSS / PA DSS, с другой − банковским специалистам, отвечающим за информационную безопасность.
Итак, трое на трое: представители компаний делятся своим видением проблематики, сотрудники подразделений информационной безопасности банков комментируют. Представляем первую "пару": точку зрения специалистов компании "Енвижн Груп" комментирует эксперт из "Россельхозбанка".

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

1. НЕКОТОРЫЕ ПРОБЛЕМЫ ПРИ ВНЕДРЕНИИ СТАНДАРТА

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

Требование 3.4 стандарта PCI DSS устанавливает необходимость хранения номеров платежных карт (PAN) в нечитаемом виде, например, используя шифрование. Это требование должно реализовываться везде, где применяется хранение номеров платежных карт, включая любые физические носители, лог-файлы и т.д. У подавляющего большинства организаций до выпуска стандарта PCI DSS номера платежных карт не шифровались. После выхода стандарта они встали перед выбором:

  • внедрить шифрование – самая действенная мера, но зачастую заказчик высказывает опасения, что данная мера может привести к снижению производительности и необходимости тестирования работоспособности существующей базы данных в условиях шифрования;
  • использовать компенсационные меры(1) – в данном случае существует опасность, что аудитор посчитает их недостаточными для соблюдения требования стандарта. Лучше всего заранее обсудить внедряемые меры с аудитором, при этом следует учитывать, что компания не будет застрахована от того, что в будущем данное требование не будет ужесточено или не введут запрет на применение компенсационных мер. Например, хранить PIN-код, полное содержание магнитной полосы (fulltrack) и код проверки подлинности платежной карты (CVC2/CVV2) нельзя ни при каких условиях и компенсационных мерах.

Смысл термина «компенсационные меры» из контекста понятен, но не следует использовать его без пояснений.

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

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

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

Требование 11.2, 11.3 отвечает за выполнение сканирования внешних IP-адресов компании и внутреннего сканирования сегмента платежных карт, а также за проведение теста на проникновение в информационную систему. Хотя реализация данных требований обычно не вызывает затруднений, приходится часто сталкиваться с недопониманием отличий внешнего и внутреннего сканирования, теста на проникновение и соответственно с неверной реализацией требования стандарта. Согласно этим пунктам, периодически должны выполняться следующие работы:

  • внешнее сканирование, выполняемое специально аккредитованной компанией, называемой ASV-вендором. Список их приведен на сайте PCISSC. Сканирование проводится ежеквартально;
  • внутреннее сканирование, которое может выполняться сотрудниками самой компании, тоже в ежеквартальном режиме;
  • тестирование на проникновение выполняется ежегодно сторонней компанией или внутренним подразделением, имеющим соответствующую квалификацию. Тестирование выполняется как извне организации (попытка взлома корпоративной сети из Интернета), так и внутри – с точки зрения действий внутреннего злоумышленника-сотрудника, имеющего обычный доступ к ресурсам компании. Сканирование инструментальными средствами является только одним из этапов. Распространенной ошибкой является то, что работы ограничиваются только сканированием, что является поводом для аудитора усомниться в результатах проведенных работ и квалификации тестировщика. Требования к тестированию детально описаны в официальном документе, выпущенном PCICouncil: ttps://www.pcisecuritystandards.org/documents/information_supplement_11.3.pdf

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

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

Вторая тонкость – выполнение работ после устранения серьезных уязвимостей, в терминологии PCI DSS- до получения «чистого результата». Неоднократно приходилось сталкиваться с тем, что после устранения критичных уязвимостей, найденных по результатам сканирования или теста на проникновение, не выполняется повторное сканирование (тестирование) как того требует стандарт.

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

Кроме того, аудитор вправе попросить предоставить подтверждение устранения найденных уязвимостей (отчетов, служебных записок об устранении уязвимостей) и отчет о выполненном повторном тестировании на проникновение (или отчет о повторном ASV-сканировании, внутреннем сканировании).

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

Следует обратить внимание, что кроме развернутой документации (требования к которой приведены в пункте 12.9.1 стандарта PCI DSS) необходимо:

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

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

2. РЯД ОСОБЕННОСТЕЙ ВНЕДРЕНИЯ СТАНДАРТА И ПРОВЕДЕНИЯ ОЦЕНКИ СООТВЕТСТВИЯ

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

На практике бывает так - документ создан, процедура отлично описана, но персонал не знает, каким образом нужно действовать, отсутствуют необходимые документы, прописанные в процедуре (например, создание и утверждение необходимых заявок, написание отчетов по результатам выполнения процедуры). На вопрос: «Как данная процедура реализована у вас», аудитор слышит странный ответ: «Давайте прочитаем в документе».

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

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

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

* * *

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

 

КОММЕНТАРИЙ БАНКА

Евгений БОЛОТИН,
начальник отдела управления информационной безопасности департамента безопасности
ОАО «Россельхозбанк»:

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

Именно квалифицированной аудитор, при просмотре результатов сканирования и тестирования (требование 11.2 и 11.3) укажет все текущие тонкие проблемы, на которые по ряду причин не обратит внимания персонал процессинга. И опять же превалирующая задача не только заказчика, но и QSA-аудитора, в минимальные сроки устранить обнаруженные уязвимости.

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

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

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

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

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


[1] Меры защиты, которые применяются в случае невозможности реализации в полной мере того или иного требования стандарта PCI DSS. Подробное описание и требования, предъявлемые к компенсационным мерам, приведены в Приложении Bстандарта PCI DSS

 

 

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

Подпишись на новости!
Подписаться