

В данной статье изложены некоторые наиболее распространенные проблемы и заблуждения, с которыми сталкиваются специалисты консалтинговых организаций на практике в ходе внедрения и поддержания соответствия уровня защиты требованиям стандарта PCI DSS у заказчиков − компаний разного масштаба.
1. НЕКОТОРЫЕ ПРОБЛЕМЫ ПРИ ВНЕДРЕНИИ СТАНДАРТА
Требования стандарта PCI DSS в общей части понятны, логичны и обоснованы, описаны конкретным и понятным языком. Однако есть требования, которые вызывают некоторые затруднения в ходе внедрения данного стандарта и дальнейшей поддержки соответствия.
Требование 3.4 стандарта PCI DSS устанавливает необходимость хранения номеров платежных карт (PAN) в нечитаемом виде, например, используя шифрование. Это требование должно реализовываться везде, где применяется хранение номеров платежных карт, включая любые физические носители, лог-файлы и т.д. У подавляющего большинства организаций до выпуска стандарта PCI DSS номера платежных карт не шифровались. После выхода стандарта они встали перед выбором:
Смысл термина «компенсационные меры» из контекста понятен, но не следует использовать его без пояснений.
На практике шифрование не так страшно, как кажется поначалу, и пример многих компаний это доказывает. Конечно, это сложнее, чем использование компенсационных мер, но практика показывает, что рано или поздно придется возвращаться к этому вопросу, поэтому лучше сделать это сразу.
Требование 10.6 связано с ежедневным просмотром лог-файлов всех системных компонентов. К сожалению многие считают это требование формальным – обычная ситуация, когда администратор открывает лог-файл, быстро проглядывает не один десяток страниц с сообщениями и пишет в журнале «лог-файлы проверены, замечаний нет». Такой поверхностный просмотр логов вряд ли может помочь обнаружить какие-либо несанкционированные действия или инциденты.
Такое возможно в случае удачи администратора или появления большого количества нетипичных событий. Использование же инструментальных средств анализа лог-файлов на практике позволит более качественно обнаруживать инциденты, а также освободит администратора от лишней нагрузки. Стоит помнить, что необнаруженный вовремя инцидент может в итоге привести к серьезным последствиям - компрометации данных платежных карт, что означает для заказчика потерю репутации и клиентов.
Требование 11.2, 11.3 отвечает за выполнение сканирования внешних IP-адресов компании и внутреннего сканирования сегмента платежных карт, а также за проведение теста на проникновение в информационную систему. Хотя реализация данных требований обычно не вызывает затруднений, приходится часто сталкиваться с недопониманием отличий внешнего и внутреннего сканирования, теста на проникновение и соответственно с неверной реализацией требования стандарта. Согласно этим пунктам, периодически должны выполняться следующие работы:
Важно обратить внимание на две тонкости, которые нельзя упускать из вида:
Помимо установленной частоты выполнения сканирований и тестов (ежеквартально или ежегодно), стандарт требует выполнять их и после совершения значительных изменений в инфраструктуре. Например, был внедрен 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
Отправляя данную форму вы соглашаетесь с политикой конфиденциальности персональных данных
Отправляя данную форму вы соглашаетесь с политикой конфиденциальности персональных данных