Стандарт защиты данных Data Security Standard (DSS) спроектирован отраслевой ассоциацией платежных карт Payment Card Industry (PCI) для выпуска и обслуживания кредитных карт. Недавно утвержденная обновленная версия стандарта, PCI DSS 1.1, несомненно, отразится на работе компаний, которые уже применяют или планируют внедрять этот стандарт. Специалистам, незнакомым с PCI DSS, наверняка будет интересно узнать, как стандарт повлияет на их деятельность.

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

Мошенничество с использованием личных данных принимает масштабы эпидемии. Ежедневно происходят взломы сетей, связанные с потерей огромных объемов личных данных, среди которых номера кредитных карт и другая финансовая информация. Учитывая беспокойство общественности, конгресс США и правительства различных штатов обсудили возможность принятия законов для отрасли и потребителей кредитных карт. Стандарт PCI DSS появился в результате сотрудничества ведущих организаций и банков, работающих на рынке кредитных карт, с целью предотвращения кражи личных данных. В прошлом стандарт был просто набором рекомендаций. Однако после того, как CardSystems, одна из крупнейших компаний по обслуживанию кредитных карт, обанкротилась в результате электронного взлома с кражей более 40 млн. кредитных карт, в отрасли убедились в необходимости более строгих и обязательных стандартов. Поэтому консорциум поставщиков кредитных карт пересмотрел стандарт, и теперь в контрактах оговаривается требование о соответствии PCI DSS. Стандарт PCI DSS распространяется на выпуск кредитных карт, безналичные расчеты между банками и системы обработки платежей. Даже владельцы небольших Web-сайтов с компонентами электронной коммерции обязаны обеспечить защиту своих сетей в соответствии со стандартом.

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

Требования PCI DSS 1.1

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

• Построение и обслуживание безопасной сети

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

• Внедрение программы управления риском

5. Использовать и регулярно обновлять антивирусную программу.
6. Разработать и развернуть системы и приложения безопасности.

• Применение надежных мер управления доступом

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

• Регулярный мониторинг и тестирование сетей

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

• Применение политики информационной безопасности

12. Применять политику для решения проблем информационной безопасности.

Далее в статье мы рассмотрим особенности этих групп и отдельных требований внутри каждой группы. Подробную информацию о PCI DSS можно найти на Web-узле PCI Security Standards Council по адресу (https://www.pcisecuritystandards.org/tech/download_the_pci_dss.htm).

Построение и обслуживание безопасной сети

Требование 1. Установите и настройте конфигурацию брандмауэра для защиты данных держателя карты. На первый взгляд это требование очевидно. Однако понять его сложнее, если попытаться определить, что означает «защита данных держателя карты». Обычные правила брандмауэра недостаточно надежны; в подробном описании требования указаны более строгие правила для Web-узлов и систем платежных карт. Если для совершения транзакций используется сторонний Web-узел, такой как Yahoo Merchant Solutions, то оперативные меры безопасности этого Web-узла, скорее всего, достаточны. Однако все же требуется представить копию результатов аудита безопасности или отчет о проверке, чтобы доказать соответствие Web-узла стандарту. При наличии брандмауэра между приложением обработки платежей и Internet необходимо строго ограничить внешние подключения к любым портам, кроме необходимых (например, HTTP, HTTPS). Следует блокировать порты, не имеющие отношения к Web, особенно такие уязвимые, как Telnet и FTP. При необходимости использования названных протоколов будьте готовы обосновать это. Возможный вариант — разместить компьютер в демилитаризованной зоне (DMZ) в качестве посредника, чтобы разрешить доступ к этим протоколам только из-за брандмауэра. Кроме того, если продажи ведутся не во всех странах мира, можно блокировать огромные массивы IP-адресов, назначенных международным сайтам. Список блоков IP-адресов опубликован на сайте Internet Assigned Numbers Authority (IANA) (http://www.iana.org ). Дополнительные сведения о блокировании IP-адресов приведены в документе «Geo-IP Blocking with IP Tables: Some Common Sense Firewall Rules» по адресу http://www.samag.com/documents/s=9367/sam0511c/0511c.htm. 

Требование 2. Не используйте установленных поставщиком оборудования стандартных паролей и других параметров безопасности. Это элементарное требование. Любые компьютеры, обращенные в Web, в которых используются пароли поставщика, скорее всего, уже взломаны. Однако требование можно поднять на более высокий уровень и применить к другим сетевым устройствам, размещенным за брандмауэром и в одной сети с Web-сервером, таким как коммутатор и маршрутизатор. Злоумышленники могут воспользоваться этой лазейкой, чтобы начать атаку с отказом в обслуживании (DoS). Необходимо изменить все назначаемые по умолчанию беспроводные параметры, так как защита беспроводной сети — важная часть стандарта. Служба SNMP часто располагает стандартными строками сообщества, которые аналогичны паролям и могут послужить причиной утечки конфиденциальной информации о сети компании. Еще одна серьезная угроза безопасности — приложения баз данных, такие как Microsoft SQL Server. Серверы SQL Server могут устанавливаться со стандартной учетной записью sa, обеспечивающей доступ на верхнем уровне. Эти важные приложения необходимо защитить как извне, так и изнутри.

Защита данных держателя карты

Требование 3. Защитите сохраненные данные держателя карты. На первый взгляд это требование сформулировано неопределенно, но в стандарте предусмотрены методы защиты хранимых данных, в частности способы шифрования важных частей базы данных и обработки информации. Особого внимания требуют такие данные, как номер основной учетной записи (PAN), код безопасности (число из трех или четырех цифр, часто запрашиваемое розничными торговцами в сети), дата истечения и почтовый индекс пользователя. Большинство поставщиков шифруют эти поля в своих базах данных, чтобы данные о картах не попали в руки злоумышленников в случае взлома базы. Еще один прием: использовать отдельные логические и физические базы данных для номеров карт и кодов безопасности. Номер карты вместе с кодом безопасности — золотой самородок для сетевого вора; но если они разделены, злоумышленники не могут использовать украденную информацию.

Требование 4. Шифруйте данные держателя карты, передаваемые через открытые общедоступные сети. Это требование очевидно. Администраторов, которые не используют Secure Sockets Layer (SSL) для своих Web-узлов, следовало бы вернуть в 1994-й год. Но даже если SSL применяется, необходимо проверить сертификаты, чтобы убедиться в их корректности и своевременном обновлении, а также проверить версию SSL (злоумышленники легко взламывают некоторые ранние версии). Проверка, выполненная поставщиком, позволит легко выявить эти изъяны. Еще одно условие PCI DSS — защита и ротация ключей шифрования. Широко распространенная практика «установил и забыл» здесь недопустима.

Внедрение программы управления риском

Требование 5. Используйте и регулярно обновляйте антивирусную программу. Администратор должен использовать антивирусную программу и регулярно обновлять ее, в противном случае он будет слишком занят борьбой с вирусами и даже не сможет прочитать эту статью. Среди дополнительных мер защиты — средства для борьбы с сетевыми вирусами и запрет вложенных файлов. Требования к защите от вирусов PCI DSS 1.1 дополнены разделом 5.11, в котором оговорено обязательное применение программ для борьбы со шпионским программным обеспечением и спамом. Эти программы могут входить в антивирусный пакет или поставляться как отдельный продукт, такой как Microsoft Windows Defender или GFI MailEssentials. Существуют и бесплатные продукты, в частности Ad-Aware компании Lavasoft и Spybot Search & Destroy компании PepiMK Software. Однако этим продуктам не хватает управляемости и масштабируемости интегрированных пакетов.

Требование 6. Разработайте и разверните системы и приложения безопасности. Это требование применимо не целиком, если компания не проектирует приложение электронной коммерции самостоятельно. Однако полностью игнорировать требование не удастся. Все компании должны выполнить части этого требования, например, в разделе 6.2 содержится требование о программе управления заплатами, а в разделе 6.4 оговаривается необходимость строгой политики управления изменениями. Версия PCI DSS 1.1 дополнена разделом 6.6, в котором говорится, что весь исходный текст должен пройти проверку на уязвимость независимыми специалистами. Это требование можно обойти, разместив брандмауэр прикладного уровня перед Web-сервером. Независимая проверка всего исходного текста может быть дорогостоящей и дает непредсказуемые результаты, поэтому большинство компаний предпочитают брандмауэр. Брандмауэры уровня Web-приложений выпускаются несколькими поставщиками и сообществом открытого кода (например, Web Application Firewall компании NetContinuum и ModSecurity компании Breach Security). Их цены стали гораздо ниже, а процедура настройки — сравнительно проще.

Применение надежных мер управления доступом

Требование 7. Предоставлять доступ к данным держателей карт только при производственной необходимости. Это требование сложно выполнить; оно связано со строгим внутренним контролем и классификацией информационных ресурсов. В сущности, требование сводится к тому, что базы данных кредитных карт не должны быть доступны всем сотрудникам компании. Можно сформировать группы доступа с детализированными полномочиями с помощью групповой политики Active Directory (AD). Двойное управление — также удачный подход к доступу и изменению базы данных, позволяющий ограничить права разработчиков и сетевых администраторов.

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

Требование 9. Ограничьте физический доступ к данным держателей карт. Это требование предусматривает надежную физическую защиту серверов баз данных (в большинстве компаний это уже сделано). Если серверы размещены в коллективном хранилище, то, как правило, меры физической безопасности хранилища распространяются на все расположенные в нем серверы. Однако в приложении A к стандарту PCI DSS 1.1 указывается, что ответственный за помещение должен выполнять определенные требования. Если компания самостоятельно размещает серверы, то их следует установить в надежном, кондиционируемом помещении с ограниченным доступом и вдали от общей рабочей зоны.

Регулярный мониторинг и тестирование сетей

Требование 10. Отслеживайте и контролируйте любые попытки доступа к сетевым ресурсам и данным держателей карт. Важнейшее условие для выполнения этого требования — аккуратное ведение и регулярный анализ журналов. Слишком часто администраторы допускают разрастание журналов, не заглядывая в них, поскольку боятся гигантских непонятных файлов. Существует несколько программ, позволяющих разобрать файлы и представить данные в понятном виде (например, GFI EventsManager, EventTracker компании Prism Microsystems, LogCaster компании RippleTech, Event Log Manager (ELM) — компании TNT Software). Кроме того, использование внутри сети системы обнаружения несанкционированного проникновения Intrusion Detection System (IDS) — действенная мера, которая защищает от взлома брандмауэра и злоумышленников внутри компании.

Требование 11. Регулярно тестируйте системы и процессы безопасности. Это требование означает, что некоторые поставщики должны проходить независимое тестирование сети. Список утвержденных исполнителей сканирования приведен в документе PCI Security Standards Council ASV (https://www.pcisecuritystandards.org/pdfs/pci_asv_list.pdf ). Поставщики также должны проводить собственные внутренние тесты и, самое главное, устранять обнаруженные проблемы. Слишком часто компании не принимают мер по результатам тестов из-за нехватки времени и ресурсов. Необходимо своевременно реагировать на неполадки, даже если для этого придется обратиться за посторонней помощью. Выполнять это требование частично так же недопустимо, как и полностью игнорировать его.

Применение политики информационной безопасности

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

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

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

Работаем без происшествий

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

Тони Хаулетт (thowlett@netsecuritysvcs.com ) — президент сетевой консалтинговой фирмы Network Security Services. Имеет сертификаты CISSP и GSNA