PCI DSS

Основные несоответствия и их причины  

Распространённые мифы о PCI DSS  

1. «Внутренних» злоумышленников не существует. Отчего-то многие до сих пор считают, что все угрозы связаны с действиями «внешних» злоумышленников, и поэтому основные усилия по IT-защите направлены на обеспечение безопасности периметра сети. При этом вопросы защиты ресурсов внутри сети часто вообще не рассматриваются или им не уделяется должного внимания. По статистике, более 70% инцидентов, связанных с информационной безопасностью, происходит по вине инсайдеров.
2. Треки нужны для претензионной работы и поэтому должны храниться вместе с журналами транзакций. Такой подход противоречит требованиям стандарта PCI DSS, в соответствии с которыми данные треков должны удаляться сразу после процедуры авторизации, т. к. именно эти данные чрезвычайно ценны для злоумышленников, и их компрометация позволяет им впоследствии изготавливать поддельные платежные карты и выполнять мошеннические транзакции.
3. Данные платежных карт вообще не следует удалять, вдруг они когданибудь кому-нибудь понадобятся. Такой подход сегодня принципиально ошибочен. Если раньше политикой безопасности регламентировались минимальные сроки хранения данных, то теперь стандарт PCI DSS требует, напротив, ограничения максимальных сроков хранения определенных данных, т. е. в компании должна быть реализована задокументированная политика хранения данных, четко определяющая необходимый для поддержания бизнес-процессов период хранения данных и требования к процедурам их последующего уничтожения.
4. Подключения по выделенным каналам являются защищенными по определению. Многие компании ошибочно полагают, что если они подключат своих клиентов и партнеров по выделенным каналам связи, такое соединение защищать не придется, защищать следует только подключения через Интернет. На самом деле выделенные каналы также требуют защиты, а именно шифрования передаваемых данных и соответствующей настройки VPN и средств межсетевого экранирования.
5. Cоответствия PCI DSS можно достичь, просто разработав комплект нормативной документации, поскольку на практике аудиторы ограничиваются проверкой документов и интервью с персоналом. Это в корне неверно: помимо вышеперечисленного аудиторы осуществляют также проверку настроек ПО и анализ содержимого файлов и таблиц баз данных, а также проверку соответствия сведений, указанных в предоставленных им документах, реальному положению вещей в компании.

Проблемные требования стандарта PCI DSS  

по пунктам:

• № 11: Необходимо проводить регулярное тестирование систем и процессов обеспечения безопасности.
  
  
• № 2: Необходимо запретить использование параметров безопасности и системных паролей, задаваемых производителями по умолчанию.
  
  
• № 3: Необходимо защищать хранимые данные держателей карт.
  
  
• № 10: Необходимо отслеживать и проводить мониторинг всех попыток доступа к сетевым ресурсам и данным держателей карт.
  
  
• № 8: Необходимо назначать уникальный идентификатор каждому, кто имеет доступ к компьютеру.
  
  
• № 12: Необходимо поддерживать и совершенствовать политику информационной безопасности.

• № 9: Необходимо ограничивать физический доступ к данным держателей карт.
  
  
• № 4: Необходимо шифровать данные держателей карт при их передаче по открытым, публичным сетям.
  
  
• № 7: Необходимо ограничивать доступ к данным держателей карт по принципу необходимого знания.

1. Необходимые для обеспечения бизнеспроцессов сетевые протоколы и политики межсетевого экранирования незадокументированы.
2. Авторизационные данные хранятся в журналах транзакций ATM, POS-терминалов и т.д.
3. Внутреннее сканирование уязвимостей сетевых устройств не проводится. 4. Не определена политика хранения данных, т.е. нет четкой установки, где и какие данные платежных карт хранить и когда их нужно удалять.
4. Должным образом не обеспечивается контроль целостности приложений и операционных систем серверов.
5. Не стандартизированы настройки операционных систем и приложений, в том числе с точки зрения обеспечения безопасности.
6. Не устанавливаются вообще или устанавливаются несвоевременно обновления безопасности на серверы процессинга, так как для их установки необходимо перезагружать серверы и останавливать работу.
7. В случае использования ПО собственной разработки последнее ничем не регламентировано, и разработчики всегда поддерживают продукционную систему самостоятельно как наиболее компетентные специалисты.
8. Парольная политика применяется в основном только в доменах Windows. На Unix-серверах, в базах данных, и к приложениям парольная политика применяется крайне редко.
9. Регистрация событий не рассматривается как источник информации для мониторинга уровня безопасности и расследования инцидентов.
10. Обучение рядовых сотрудников в части информационной безопасности обычно ограничивается единственным инструктажем при приеме на работу.

Текст статьи читайте в журнале  "ПЛАС" 2 (132) ’2008 сс. 12