Очень часто возникает необходимость проверить какой-либо интерфейс на правильность ввода номера кредитной карты, пройти регистрацию на сайте, где требуется карточка, зарегистрироваться в iTunes — во всех этих случаях вам поможет следующая таблица.
Для всех банков
Успешный платёж
| American Express | 15 | 378282246310005 | Любая | Любой |
| American Express | 15 | 371449635398431 | Любая | Любой |
| Amex Corporate | 15 | 378734493671000 | Любая | Любой |
| Australian BankCard | 16 | 5610591081018250 | Любая | Любой |
| Dankort (PBS) | 11 | 76009244561 | Любая | Любой |
| Dankort (PBS) | 16 | 5019717010103742 | Любая | Любой |
| Dinners Club | 14 | 38520000023237 | Любая | Любой |
| Dinners Club | 14 | 30569309025904 | Любая | Любой |
| Discover | 16 | 6011111111111117 | Любая | Любой |
| Discover | 16 | 6011000990139424 | Любая | Любой |
| JCB | 16 | 3530111333300000 | Любая | Любой |
| JCB | 16 | 3566002020360505 | Любая | Любой |
| Master Card | 16 | 5105105105105100 | Любая | Любой |
| Master Card | 16 | 5555555555554444 | Любая | Любой |
| Switch/Solo (Paymentech) | 16 | 6331101999990016 | Любая | Любой |
| Visa | 13 | 4222222222222 | Любая | Любой |
| Visa | 16 | 4111111111111111 | Любая | Любой |
| Visa | 16 | 4012888888881881 | Любая | Любой |
| Visa | 16 | 4300000000000777 | 11/22 | Любой |
Неуспешный платёж
| Visa | 16 | 5000000000000009 | 11/22 | Любой |
| Visa | 16 | 4652060573334999 | 01/17 | 067 |
Отмененный платёж
| Visa | 16 | 4000000000000119 | 11/22 | Любой |
Имя держателя карты и срок её действия, а также CVV можно указывать любые, кроме тех случаев, где указаны конкретные данные в таблице.
спалил номер карты!!
Для Альфа-банка
В качестве Cardholder name (Имя владельца карты) указывайте от 2 слов в английской раскладке (например, IVANOV IVAN).
Для всех карт, вовлечённых в 3-D Secure (veres=y, pares=y или a) пароль на ACS: 12345678.
Тестовая среда не предназначена для нагрузочного тестирования, в случае необходимости его проведения следует обратиться в Банк.
➤Это полезно знать➤Почему нельзя сообщать номер банковской карты.➤
Карты с успешным результатом оплаты
| 4111 1111 1111 1111 | 2024/12 | 123 | veres=y, pares=y |
| 5100 0000 0000 0008 | 2024/12 | 123 | veres=y, pares=y |
| 6011 0000 0000 0004 | 2024/12 | 123 | veres=y, pares=y |
| 6390 0200 0000 000003 | 2024/12 | 123 (необязательный параметр) | veres=y, pares=a |
| 5555 5555 5555 5599 | 2024/12 | 123 | veres=n |
| 4444 0000 0000 1111 | 2024/12 | 123 | veres=n |
| 2200 0000 0000 0004 | 2024/12 | 123 | veres=n |
| 2200 0000 0000 0012 | 2024/12 | 123 | veres=y pares=n |
| 2200 0000 0000 0020 | 2024/12 | 123 | veres=u |
| 2200 0000 0000 0038 | 2024/12 | 123 | veres=y pares=u |
| 2200 0000 0000 0046 | 2024/12 | 123 | veres=y pares=a |
| 2200 0000 0000 0053 | 2024/12 | 123 | veres=y pares=y |
Карты, возвращающие ошибки
| 5555 5555 5555 5557 | 2024/12 | 123 | veres=y, pares=u | Declined. PaRes status is U (-2011) |
| 4444 3333 2222 1111 | 2024/12 | 123 | veres=y, pares=u | Declined. PaRes status is U (-2011) |
| 4000 0000 0000 0002 | 2024/12 | 123 | veres=u | Declined. VeRes status is U (-2016) |
| 5555 5555 4444 4442 | 2024/12 | 123 | veres=u | Declined. VeRes status is U (-2016) |
| 4444 4444 4444 4422 | 2024/12 | 123 | N/A | Invalid message format (913) |
| 4444 4444 4444 4455 | 2024/12 | 123 | N/A | Card limitations exceeded (902) |
| 4444 4444 4444 3333 | 2024/12 | 123 | N/A | Limit exceeded (123) |
| 4444 4444 4444 6666 | 2024/12 | 123 | N/A | BLOCKEDBYLIMIT (-20010) |
| 4444 4444 1111 1111 | 2024/12 | 123 | N/A | Network refused transaction (5) |
| 4444 4444 9999 9999 | 2024/12 | 123 | N/A | TDSECCOMMERROR (151017) |
| 5432 5432 5432 5430 | 2022/12 | 123 | N/A | INSUFFICIENT_FUNDS (116) |
Для RBKmoney
Для проведения платежей в тестовом магазине используются специальные номера карт, которые определяют ответ платформы в зависимости от отправленной информации.
Для тестовых карт принимаются суммы пополнения от 1₽ до 600 000₽ и любые значения CARDHOLDER NAME на латинице.
Таблица тестовых карт
| Success | Visa | 4242424242424242 | 12/20 | 123 |
| MasterCard | 5555555555554444 | 12/20 | 123 | |
| Maestro | 586824160825533338 | 12/20 | 123 | |
| MIR | 2201382000000013 | 12/20 | 123 | |
| 3-D Secure Mock | Visa | 4012888888881881 | 12/20 | 123 |
| MasterCard | 5169147129584558 | 12/20 | 123 | |
| Insufficient Funds | Visa | 4000000000000002 | 12/20 | 123 |
| MasterCard | 5100000000000412 | 12/20 | 123 | |
| Invalid Card | Visa | 4222222222222220 | 12/20 | 123 |
| MasterCard | 5100000000000511 | 12/20 | 123 | |
| CVV Match Fail | Visa | 4003830171874018 | 12/20 | 123 |
| MasterCard | 5496198584584769 | 12/20 | 123 | |
| Expired Card | Visa | 4000000000000069 | 12/20 | 123 |
| MasterCard | 5105105105105100 | 12/20 | 123 | |
| Unknown Failure | Visa | 4111110000000112 | 12/20 | 123 |
| MasterCard | 5124990000000002 | 12/20 | 123 | |
| Apple Pay Success | Visa | 4300000000000777 | 12/20 | 123 |
| Apple Pay Failure | Visa | 5000000000000009 | 12/20 | 123 |
| Google Pay Success | MasterCard | 2222990905257051 | 12/20 | 123 |
| Google Pay Failure | MasterCard | 2222405343248877 | 12/20 | 123 |
| Samsung Pay Success | MasterCard | 2223577120017656 | 12/20 | 123 |
| Samsung Pay Failure | MasterCard | 2223007648726984 | 12/20 | 123 |
Второй способ
Можно воспользоваться онлайн генератором номеров кредитных карт, который позволяет создать неограниченное количество карт. Есть API. Результат выдается в форматах: JSON, CSV, XML.
Источник: www.kobzarev.com
Как проверить PAN карту?
Как проверить правильность текста редактирования для панорамирования, например «ABCDE1234F». Я запутался, как проверить валидацию для этого. Пожалуйста, помогите мне, ребята. Я буду признателен за любую помощь.
Sunil Kumar 16 июль 2013, в 20:46
Поделиться
мог бы использовать регулярное выражение.
Raghunandan 16 июль 2013, в 18:31
как использовать это для проверки правильности панорамирования?
Sunil Kumar 16 июль 2013, в 18:36
Поделиться:
validation
android-edittext
12 ответов
Лучший ответ
Вы можете использовать регулярное выражение с соответствием шаблону
String s = «ABCDE1234F»; // get your editext value here Pattern pattern = Pattern.compile(«[A-Z][0-9][A-Z]»); Matcher matcher = pattern.matcher(s); // Check if pattern matches if (matcher.matches()) < Log.i(«Matching»,»Yes»); >[A-Z] — match five literals which can be A to Z [0-9] — followed by 4 numbers 0 to 9 [A-Z] — followed by one literal which can A to Z
Raghunandan 16 июль 2013, в 19:11
Поделиться
Все работало нормально спасибо
Sunil Kumar 16 июль 2013, в 19:39
Raghunandan 16 июль 2013, в 19:39
Первые три буквы AAA-ZZZ. Четвертая буква — это либо «C», «H», «F», «A», «T», «B», «L», «J», «G», «P». Эта проверка также может быть включается, но на основе четвертой буквы, пятая буква определяется, если четвертая буква — P, пятая буква — первая буква фамилии фамилии, а для всех остальных — первая буква имени. Как мы можем сделать такое регулярное выражение?
inquisitive 26 май 2015, в 10:17
Raghunandan 26 май 2015, в 15:30
inquisitive 27 май 2015, в 04:47
Prashant G Patil 02 фев. 2016, в 09:51
Регулярное выражение может быть упрощено до [AZ]<5>[0-9][AZ] ( является избыточным).
Sumit 19 авг.
2016, в 14:20
Показать ещё 5 комментариев
PAN structure is as follows: AAAAA9999A: First five characters are letters, next 4 numerals, last character letter.
1) The first three letters are sequence of alphabets from AAA to zzz 2) The fourth character informs about the type of holder of the Card. Each assesse is unique:` C — Company P — Person H — HUF(Hindu Undivided Family) F — Firm A — Association of Persons (AOP) T — AOP (Trust) B — Body of Individuals (BOI) L — Local Authority J — Artificial Judicial Person G — Government 3) The fifth character of the PAN is the first character (a) of the surname / last name of the person, in the case of a «Personal» PAN card, where the fourth character is «P» or (b) of the name of the Entity/ Trust/ Society/ Organisation in the case of Company/ HUF/ Firm/ AOP/ BOI/ Local Authority/ Artificial Jurdical Person/ Govt, where the fourth character is «C»,»H»,»F»,»A»,»T»,»B»,»L»,»J»,»G». 4) The last character is a alphabetic check digit.
Надеюсь, это поможет.
Shobhit Puri 16 июль 2013, в 19:22
Поделиться
Вот Это Да! аккуратное объяснение PAN
Raghunandan 16 июль 2013, в 18:56
Sunil Kumar 16 июль 2013, в 19:00
Shobhit Puri 16 июль 2013, в 19:05
Кто-нибудь знает, какой алгоритм используется для контрольной суммы (последняя буквенная контрольная цифра)?
Nishan 27 апр. 2018, в 14:40
Я сделал быструю проверку, кажется, алгоритм Luhn Mod N используется.
Nishan 27 апр. 2018, в 14:57
Показать ещё 3 комментария
В соответствии с Законом о подоходном налоге руководящие принципы для карты PAN следующие:
Формат для пан-карты: например, ABCDE0123F
Карта PAN подоходного налога выдается в соответствии с разделом 139A Закона о подоходном налоге. Структура PAN выглядит следующим образом: AAAPL1234C: пять (5) первых символов — это буквы, за которыми следуют четыре (4) цифры, а последний (10-й) символ — это буква. Четвертый (4-й) символ сообщает о держателе карты.
Для проверки кода: «[AZ] [0-9] [AZ] «
public static boolean isPanCardValid(String pan_number) < Pattern pattern = Pattern.compile(«[A-Z][0-9][A-Z]»); Matcher matcher = pattern.matcher(pan_number); // Check if pattern matches if (matcher.matches()) < return true; >else < return false; >>
где isPanCardValid() — статический метод, который принимает строку как параметр (String pan_number), введенный пользователем, и сопоставляет ее с шаблоном PanCard и возвращает значение как true или false.
Источник: overcoder.net
Информационная безопасность в индустрии платежных карт
В банковских и платежных системах широко применяются пластиковые карточки с магнитной полосой, они позволяют осуществлять оплату товаров и услуг, а кроме того, являются одним из средств аутентификации клиентов. Для их безопасного использования принят комп
24.09.2008 Ростислав Сергеев
- Ключевые слова :
- Защита информации
В банковских и платежных системах широко применяются пластиковые карточки с магнитной полосой, они позволяют осуществлять оплату товаров и услуг, а кроме того, являются одним из средств аутентификации клиентов. Для их безопасного использования принят комплекс мер, сформулированных в виде специального стандарта по информационной безопасности (Payment Card Industry Data Security Standard, PCI DSS).
Требования 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»).
АУДИТ СЕТИ
Помимо проведения аудитов в соответствии с процедурами PCI SSC, компании, обладающие статусом QSA, отвечают за интерпретацию требований стандарта и адекватность компенсационных требований, а также предоставляют отчетность в платежные системы и PCI SSC.
Процедура аудита реализуется поэтапно: (1) проверка документов и определение зоны контроля, (2) оценка соответствия на месте, (3) подготовка и распространение отчета и (4) подготовка плана по устранению несоответствий. Зона контроля охватывает все устройства и сетевые сегменты, в которых производится обработка или передача данных о держателях платежных карт, а также все сетевые сегменты и устройства, подключенные к перечисленным сегментам (в том числе активное сетевое оборудование). Таким образом, зона контроля может быть довольно обширной, особенно если внутренняя сеть компании не сегментирована и для отделения процессингового центра от остальной сети банка не используются внутренние межсетевые экраны.
Продуманная сегментация сети для изоляции систем хранения, обработки или передачи данных карт от других систем, применяемых в организации, позволяет значительно ограничить область оценки среды данных платежных карт. Компания QSA помогает определить соответствующую область и объясняет, как ее уменьшить посредством правильной сегментации сети.
Для подтверждения соответствия стандарту необходимо выполнить каждое его требование, если таковое применимо (см. Рисунок 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
Выход релиза 1.2 запланирован на ноябрь 2008 г. Как ожидается, он будет содержать следующие изменения и дополнения:
Источник: www.osp.ru