Действие PCI DSS распространяется на торгово-сервисные предприятия и поставщиков услуг, работающих с международными платежными системами, т. е. на всех, кто передает, обрабатывает и хранит данные держателей карт. Это касается как общих данных — номер карты (Primary Account Number, PAN), имя держателя карты, код обслуживания, дата выдачи и истечения срока действия, так и критичных данных авторизации (sensitive authentication data) — полное содержание магнитной полосы, коды CVC2/CVV2/CID и PIN-блок. Элементы данных необходимо защищать, если они хранятся совместно с номером карты, а по завершении процедуры авторизации критичные данные не должны сохраняться даже в зашифрованном виде. Требования стандарта PCI DSS не применяются, если не выполняется хранение, обработка или передача номера карты (PAN).

Требования PCI DSS распространяются на все системные компоненты, в том числе на сетевое оборудование, серверы и приложения, входящие в состав среды данных платежных карт (часть сети, в которой обрабатываются данные платежных карт или критичные данные авторизации) или непосредственно к ней подключенные. К сетевым компонентам относятся (но не ограничиваются ими) межсетевые экраны, коммутаторы, маршрутизаторы, беспроводные точки доступа, устройства защиты информации и другое сетевое оборудование. Среди типов серверов — серверы Web, серверы баз данных, аутентификационные и почтовые серверы, proxy-, NTP-, DNS- и другие серверы. В перечень приложений входят все приобретенные и разработанные приложения, как внутренние, так и внешние.

НЕМНОГО ИСТОРИИ

Первая редакция стандарта PCI DSS (1.0) была разработана в 2004 г. на основе требований к безопасности данных платежных систем Visa, Master Card, American Express, Discover Card и JCB. В сентябре 2006 г. вышла новая редакция PCI DSS 1.1, а для развития и продвижения стандарта был создан специальный совет по стандартам безопасности — PCI Security Standards Council (PCI SSC), в который вошли представители перечисленных платежных систем.

Поначалу международные платежные системы требовали от участников программы и торгово-сервисных предприятий обеспечить соответствие стандарту только на территории США и Западной Европы, причем нарушители подвергались штрафам. Для других регионов никаких санкций предусмотрено не было. Однако с сентября 2006 г. жесткие правила выполнения аудита по стандарту были распространены на регион CEMEA, в который входит и Россия, что послужило стимулом для внедрения PCI DSS российскими банками, процессинговыми центрами и торгово-сервисными организациями. В ноябре 2008 г. планируется выход новой редакции стандарта PCI DSS — 1.2, где будут учтены лучшие практики по безопасности, замечания организаций-членов PCI SSC и ряд других новшеств (см. врезку «Ожидаемые изменения в стандарте PCI DSS»).

В зависимости от числа обрабатываемых за год транзакций (до 120 тыс., до 600 тыс., до 6 млн, более 6 млн) компании присваивается определенный уровень с обязательным набором требований по безопасности. Процедуры подтверждения соответствия стандарту включают ежегодный аудит, ежеквартальное сканирование сети на наличие уязвимостей и, в некоторых случаях, заполнение листа самооценки (Self Assessment Questionauire). Для выполнения аудита и сканирования сетей компании должны привлекать стороннюю организацию, имеющую статус Qualified Security Assessor (QSA, для аудита) и Approved Scanning Vendor (ASV, для сканирования сети). Упомянутые статусы присваиваются советом PCI Security Standards Council, и их список размещен на сайте https://www.pcisecuritystandards.org. Там же можно найти официальный текст стандарта PCI DSS на английском языке (https://www.pcisecuritystandards.org/pdfs/pci%20dss%20v1-1.pdf).

В данный момент в этом списке присутствуют три российские компании: московские «Информзащита» и «Инфосистемы Джет», а также Digital Security из Санкт-Петербурга (см. врезку «Аудит по-российски»). На сайте компании «Информзащита» опубликованы неофициальный перевод стандарта PCI DSS на русский язык (http://www.infosec.ru/files/articles/2284/Стандарт%20PCI%20DSS%201_1.pdf)  и три сопутствующих документа на русском языке: «Процедуры аудита безопасности PCI DSS», «Ориентирование в PCI DSS: понимание требований» и «Процедуры сканирования безопасности».

АУДИТ СЕТИ

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

Процедура аудита реализуется поэтапно: (1) проверка документов и определение зоны контроля, (2) оценка соответствия на месте, (3) подготовка и распространение отчета и (4) подготовка плана по устранению несоответствий. Зона контроля охватывает все устройства и сетевые сегменты, в которых производится обработка или передача данных о держателях платежных карт, а также все сетевые сегменты и устройства, подключенные к перечисленным сегментам (в том числе активное сетевое оборудование). Таким образом, зона контроля может быть довольно обширной, особенно если внутренняя сеть компании не сегментирована и для отделения процессингового центра от остальной сети банка не используются внутренние межсетевые экраны.

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

Рисунок 1. Структура стандарта PCI DSS

Для подтверждения соответствия стандарту необходимо выполнить каждое его требование, если таковое применимо (см. Рисунок 1 и врезку «Шесть задач и 12 основных требований стандарта PCI DSS»). Как показывает практика, наиболее проблемными для компаний оказываются требования 11, 2, 3, 10, 8 (в порядке убывания числа несоответствий), в то время как выполнение требований 9, 4 и 7 обычно не вызывает трудностей, а требование 6 имеет отношение только к тем компаниям, которые занимаются разработкой ПО.

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

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

Далее подробнее рассмотрим цели и требования стандарта PCI DSS.

ПОСТРОЕНИЕ И ПОДДЕРЖАНИЕ ЗАЩИЩЕННОЙ СЕТИ

В соответствии с Требованием 1 в целях защиты платежных карт необходимо обеспечить разработку и управление конфигурацией межсетевых экранов (МСЭ). В терминологии PCI DSS межсетевые экраны — это вычислительные устройства, контролирующие входящий извне и исходящий за пределы корпоративной сети трафик, а также трафик к внутренним критичным подсетям.

Конфигурирование МСЭ должно удовлетворять следующим требованиям:

  • формализация и документирование процесса утверждения и тестирования всех соединений с внешними сетями, а также изменений, вносимых в конфигурацию МСЭ;
  • полная актуальная схема сети с указанием всех подключений (включая беспроводные точки доступа в сегментах с данными платежных карт; без такой схемы некоторые сетевые устройства можно упустить из виду и, не обеспечив их должной защитой, подвергнуть угрозе компрометации);
  • размещение МСЭ на каждом канале подключения к Internet, а также на границе между каждой демилитаризованной зоной и внутренней сетью;
  • описание групп, ролей и обязаннос-тей в отношении логического управления сетевыми компонентами;
  • документирование перечня сервисов и портов, необходимых для функционирования бизнес-процессов;
  • документирование и обоснование применения всех протоколов, за исключением HTTP, SSL, SSH и VPN;
  • документирование всех небезопасных протоколов (например, FTP) с указанием причины использования протокола и реализованных механизмов защиты;
  • ежеквартальный пересмотр правил для МСЭ и маршрутизаторов и своевременное удаление ненужных, некорректных и устаревших правил;
  • документация всех правил для маршрутизаторов, которые, наряду с МСЭ, являются частью архитектуры, контролирующей точки входа в сеть.

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

В соответствии с Требованием 2 стандарта PCI DSS запрещается использовать параметры безопасности и системные пароли, заданные производителем по умолчанию, поскольку эти данные хорошо известны в хакерских сообществах и могут применяться злоумышленниками для компрометации систем. В частности, для беспроводных сред должны быть изменены значения ключей WEP, идентификаторов сетей (SSID), пароли и строки SNMP. Необходимо отключить широковещательную рассылку SSID и осуществлять шифрование и аутентификацию при помощи технологии WPA и WPA2.

Для всех системных компонентов следует разработать стандарты конфигурирования, учитывающие все известные уязвимости и рекомендации по обеспечению безопасности (составленные, например, организациями SANS, NIST и CIS). На каждом сервере должна быть реализована только одна основная функция, т.е. сервер Web, сервер баз данных и сервер DNS развертываются на различных устройствах. Все необязательные и небезопасные протоколы и сервисы отключаются, избыточный функционал, например, сценарии, драйверы, файловые подсистемы и неиспользуемые серверы Web, удаляется, а административный доступ, если он осуществляется не с консоли, шифруется. При управлении с помощью интерфейса Web рекомендуется использовать технологии SSH, VPN или SSL/TLS.

ЗАЩИТА ДАННЫХ ПЛАТЕЖНЫХ КАРТ

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

Хранение данных платежных карт должно быть сведено к минимуму — это касается как объема хранимой информации, так и продолжительности хранения. Для хранения и уничтожения данных платежных карт следует разработать соответствующую политику. Хранение критичных данных авторизации запрещается (даже в зашифрованном виде). Отображаемые номера PAN необходимо маскировать (максимальным количеством разрешенных при отображении цифр являются первые шесть и последние четыре цифры): независимо от места хранения, они приводятся к нечитаемому виду с помощью одного из перечисленных ниже способов: 1) стойкие односторонние хеш-функции (хешированные индексы); 2) усечение; 3) Index Token и PAD; 4) надежная криптография совместно с процессами и процедурами управления ключами. Это же касается и номера PAN счета.

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

  • обеспечивают дополнительный уровень сегментации/абстракции (например, на сетевом уровне);
  • ограничивают доступ к данным платежных карт или базам данных в зависимости от IP/MAC-адресов, приложений/сервисов, учетных записей пользователей групп, типа данных (фильтрация пакетов);
  • ограничивают логический доступ к базе данных (независимо от Active Directory или LDAP);
  • позволяют предотвратить/обнаружить известные виды атак на приложения или базы данных.

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

В рамках Требования 4 стандарта PCI DSS обеспечивается шифрование данных платежных карт, передаваемых по сетям общего пользования: Internet, Wi-Fi, GSM и GPRS.

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

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

Для выполнения Требования 6 должна обеспечиваться безопасность при разработке и поддержке систем и приложений. Все системные компоненты и ПО необходимо снабдить самыми последними обновлениями безопасности, предоставленными производителями. Обновления следует устанавливать в течение месяца со дня их выпуска. Для выявления вновь обнаруженных уязвимостей должен быть предусмотрен соответствующий процесс (например, подписка на рассылки).

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

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

РЕАЛИЗАЦИЯ МЕР ПО СТРОГОМУ КОНТРОЛЮ ДОСТУПА

В рамках этой задачи должны быть реализованы три требования стандарта (7-9).

Требование 7 обязывает предоставлять доступ к данным платежных карт только в случае служебной необходимости. Чем больше людей имеют такой доступ, тем выше риск злонамеренного использования учетных записей. Для многопользовательских систем предусматривается механизм предоставления доступа по принципу необходимого знания (need-to-know), т.е. доступ запрещается, если он не разрешен явным образом. В соответствии с Требованием 8 каждому лицу, имеющему доступ к вычислительным ресурсам, присваивается уникальный идентификатор. В результате, действия с критичными данными и системами смогут выполнять только авторизованные пользователи, а все их операции будут отслеживаться. В дополнение к назначению уникального идентификатора должен использоваться, по крайней мере, один из следующих механизмов аутентификации: пароль, биометрические или технические устройства аутентификации (SecureID, сертификаты или открытые ключи).

Для предоставления удаленного доступа служащим компании, администраторам или третьим лицам должна быть реализована двухфакторная идентификация, что выполняется при помощи либо технологий RADIUS или TACACS и аппаратных устройств аутентификации, либо VPN (на базе протоколов SSL/TLS или IPSEC) и пользовательских сертификатов.

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

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

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

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

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

РЕГУЛЯРНЫЙ МОНИТОРИНГ И ТЕСТИРОВАНИЕ СЕТЕЙ

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

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

В соответствии с Требованием 11 осуществляется регулярное тестирование систем и процессов обеспечения безопасности, поскольку уязвимости постоянно обнаруживаются злоумышленниками и исследователями, а также вносятся вместе с новым ПО. Сканирование уязвимостей сети (как внутреннее, так и внешнее) выполняется ежеквартально или после любого значительного изменения в инфраструктуре сети. Внешнее сканирование осуществляет организация, имеющая статус ASV, а внутреннее может выполняться силами самой компании.

ПОДДЕРЖАНИЕ ПОЛИТИКИ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ

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

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

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

ВЫСОКИЙ ОРИЕНТИР

Выше были кратко рассмотрены задачи и требования стандарта PCI DSS, которые более подробно описаны в тексте стандарта на официальном сайте и сопутствующих документах. Хотя тематика платежных и систем карт напрямую касается только участников платежных систем, содержание стандарта представляет собой интерес для любых систем защиты конфиденциальной информации в компьютерных сетях. Многие процедуры и требования напрямую применимы к системам защиты персональной информации, закон о которой был недавно принят в России. В свете вышеизложенного, статья должна быть полезной как для системных администраторов, работающих с подобными системами, так и для их рядовых пользователей. Появление стандарта PSI DSS имеет чрезвычайно большое значение для отрасли ИТ в целом, а его дальнейшее совершенствование и адаптация будут способствовать повышению уровня защищенности систем с конфиденциальной информацией.

Ростислав Сергеев — заместитель главного редактора «Журнала сетевых решений/LAN». С ним можно связаться по адресу: rsergeev@lanmag.ru.

Ожидаемые изменения в стандарте PCI DSS

Выход релиза 1.2 запланирован на ноябрь 2008 г. Как ожидается, он будет содержать следующие изменения и дополнения:

  • учет текущих лучших практик по безопасности и замечаний организаций-членов Совета (PCI SSC);
  • уточнение границ применения стандарта и требований к отчетности;
  • исключение пересекающихся требований и консолидация требований к документированию;
  • разъяснение и уточнение подпунктов всех 12 требований без внесения новых элементов;
  • доработка FAQ и глоссария.

Аудит по-российски

На российском рынке услуги аудита в соответствии с требованиями QSA предоставляют всего несколько компаний. Первой статус QSA весной 2006 г. получила компания «Информзащита», когда вопрос о необходимости обеспечения соответствия стандарту PCI DSS в банках еще не поднимался. В России PCI Data Security Standard вступил в действие в сентябре 2006 г., после того как международная платежная система VISA утвердила стандарт как обязательный на территории региона CEMEA.

В результате процессинговые центры, кредитно-финансовые организации, а также те компании, которые хранят и обрабатывают сведения о держателях платежных карт, столкнулись с необходимостью привести свои платежные системы в соответствие PCI DSS. При несоблюдении требований стандарта кредитно-финансовые организации могут быть не только оштрафованы регулирующим органом (в данном случае платежной системой, входящей в PCI Security Standard Council), но и лишиться прав осуществлять какие-либо действия с платежными картами. Поэтому неудивительно, что в последние два года компании, работающие с международными платежными системами Visa и MasterCard, проявляют повышенный интерес к получению сертификата по PCI DSS.

С возникновением спроса эта отрасль стала привлекать и других игроков рынка информационной безопасности. В частности, в июне 2008 г. статус QSA был присвоен компании «Инфосистемы Джет». Обладание таким статусом дает право проводить работы в области сертификации по PCI DSS. Соответствующая услуга предусматривает проведение следующих работ:

  • оценка соответствия платежной системы стандарту PCI DSS;
  • подготовка к сертификации на соответствие стандарту PCI DSS;
  • сертификационный аудит;
  • послесертификационная поддержка.

Для выполнения необходимых процедур нужны высококвалифицированные специалисты, чем отчасти и объясняется малое количество компаний, предлагающих эту услугу. Как считает Олег Слепов, менеджер по продвижению консалтинговых услуг компании «Инфосистемы Джет», значительное превышение спроса над предложением опасно для рынка. Во-первых, финансово-кредитная организация будет вынуждена провести такой проект в более сжатые сроки, что непременно скажется на качестве результатов проекта. Во-вторых, ей придется потратить незапланированные средства и выделить ресурсы. А в-третьих, к аудиторам выстроятся огромные очереди, что весьма усложнит задачу приведения системы в соответствие с требованиями стандарта к определенному сроку.

Как отмечает Максим Эмм, директор департамента аудита компании «Информзащита», в целом, для большинства организаций, в первый раз столкнувшихся с необходимостью обеспечить соответствие требованиям западного стандарта, объем работы оказывается весьма значительным. В первую очередь, это касается документирования процессов управления и обеспечения безопасности, поскольку разработка процедур, стандартов и других документов требует немалых усилий. Во вторую очередь, это вопросы управления инфраструктурой ИТ, включая контроль изменения конфигураций, стандарты конфигурирования типовых элементов инфраструктуры ИТ и т.п. Меньше всего проблем возникает в области физической безопасности — у банков защита реализована на достаточно высоком уровне. Впрочем, задачу несколько облегчает то, что из 232 требований стандарта не все применимы к конкретному банку, например, в финансовых учреждениях в России, в отличие от США, не используются беспроводные технологии, зачастую не разрабатывается собственное программное обеспечение и т.п.

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

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

Шесть задач и 12 основных требований стандарта PCI DSS

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

Задача 2. Защита данных платежных карт.
Требование 3: При хранении данные платежных карт следует надежно защитить.
Требование 4: Данные платежных карт, передаваемые по сетям общего пользования, необходимо шифровать.

Задача 3. Реализация программы управления уязвимостями.
Требование 5: Обязательное использование и регулярное обновление антивирусного ПО.
Требование 6: Обеспечение безопасности при разработке и поддержке систем и приложений.

Задача 4. Реализация мер по строгому контролю доступа.
Требование 7: Доступ к данным платежных карт должен быть ограничен в соответствии со служебной необходимостью.
Требование 8: Каждому лицу, имеющему доступ к вычислительным ресурсам, назначается уникальный идентификатор.
Требование 9: Физический доступ к данным платежных карт следует ограничить.

Задача 5. Регулярный мониторинг и тестирование сетей.
Требование 10: Доступ к сетевым ресурсам и данным платежных карт следует конт-ролировать.
Требование 11: Системы и процессы обеспечения безопасности необходимо регулярно тестировать.

Задача 6. Поддержание политики информационной безопасности.
Требование 12: Деятельность сотрудников и контрагентов регламентируется в рамках политики информационной безопасности.