Мошенничество в платежной сфере. Бизнес-энциклопедия - Коллектив авторов

Для защиты от вмешательства в работу программного обеспечения банкоматов предлагаются разные методы и способы. В большинстве случаев заражение или вмешательство в штатную работу происходит путем доступа к компьютеру банкомата через верхний кабинет. Обычно крышка верхнего кабинета открывается одним ключом для большой серии (типа) банкоматом данного производителя. Можно обеспечить защиту от несанкционированного доступа в верхний кабинет банкомата путем монтажа дополнительного замка. При реализации данной защитной меры необходимо учитывать следующие вопросы. Если монтируется механический замок, то это будет накладывать дополнительные сложности управления доступом к механическим ключам. При этом необходимо иметь ввиду, что остается вероятность изготовления дубликата механического ключа. Электронные системы контроля доступа более предпочтительны. Но и они обладают определенными недостатками. Необходимо обеспечить оперативное обновление базы идентификаторов, разрешающих открытие замка. Данная задача может быть решена удаленно, но при этом потребуется организация канала связи к системе контроля доступом, либо локально, но в таком случае необходимо будет каждый раз совершать объезд банкоматов. Важное значение будет иметь и тип запирающего механизма. Если используется нормально закрытый (при отсутствии электрического питания замок закрыт), то в случае какой-либо неисправности (обрыв, повреждение провода, электронных компонентов и т. п.) возникнет сложность санкционированного открытия крышки верхнего кабинета. В некоторых моделях банкоматов при этом невозможно будет получить доступ и к сейфу (открыть его). При использовании нормально открытого замка (при отсутствии электрического питания замок открыт) необходимо решить вопрос с источником бесперебойного питания и определиться с требованием по времени его работы (после окончания емкости такого источника крышка откроется). Дополнительно механический замок будет защищать и от установки скимминговых устройств внутри банкомата (потребуется разрушение корпуса).

Защиту от установки вредоносного программного обеспечения можно обеспечить и программными средствами. Как уже упоминалось выше, необходимо использовать решения по обеспечению контроля целостности программного обеспечения: Diebold — SEP 11 (Symantec Endpoint Protection 11), NCR — Solidcore for APTRA. Существуют также предложения сторонних производителей, например GMV — checker ATM security, SafenSoft — TPSecure.

Серьезную угрозу для технологии платежных карт представляет компрометация криптографических ключей. При несоблюдении процедур по безопасному управлению криптографическими ключами возможна их компрометация. При несанкционированном доступе к криптографическому модулю (HSM) возможен подбор ПИН-кода, генерация нового ПИН-кода, перешифрование ПИН-блока форматов «О», «1», «3» (ISO 9564-1) в ПИН-блок формата «2» (дает возможность определить ПИН-код по заранее введенным и зашифрованным ПИН-блокам), генерация зонального мастер-ключа (ZMK) и выгрузка под ним других криптографических ключей (терминального мастер ключа — ТМК, терминального рабочего ключа — ТРК, ключа эмитента — IWK, ключа эк-вайрера — AWK, ключа проверки ПИН — PW), с использованием данных ключей можно получить ПИН-код. Формат ПИН-блока «2» считается небезопасным. В «Правилах платежной системы “Виза” по осуществлению операций на территории Российской Федерации» (утверждены генеральным директором Стивеном Паркером 29 ноября 2012 г.) определены «Требования к обеспечению безопасности ПИН-кодов»: «Участник платежной системы — эквайрер обязан обеспечить безопасность ПИН-кода, используемого для удостоверения личности клиента — физического лица при проведении операции в соответствии с Руководством по реализации требований к обеспечению безопасности ПИНа в индустрии платежных карт (PCI PIN Security Requirements). В том случае, если участник платежной системы — эмитент получает от Visa незащищенный ПИН-блок, он обязан перевести его в безопасный формат». Допустимые форматы ПИН-блока согласно PCI PIN Security Requirements (документ распространяется только на эквайреров): для транзакций в режиме реального времени шифрование ПИН-кодов должно проводиться только согласно ISO 9564-1 ПИН-блок форматы «О», «1» или «3». Формат «2» должен использоваться для ПИН-кодов, которые передаются из картридера на карту. Таким образом, эквайрер обязан использовать защищенный формат ПИН-блока, Visa может его перешифровать в незащищенный формат и отправить эмитенту, эмитент обязан его перешифровать в защищенный формат. Все, кроме Visa, обязаны выполнять PCI PIN Security Requirements. В этом же документе определен порядок использования формата «2» (незащищенного) — только в связи с офлайновой верификацией ПИН-кода или для операции по смене ПИН-кода в связи со средой смарт-карты. В данном случае, а именно операции по смене ПИН-кода, имеет место снижение уровня безопасности из-за необходимости обеспечения бизнес-требования. Так как необходимо использовать (разрешить) на криптографическом модуле (HSM) формат ПИН-блока 34 (Thales)/2 (ISO), который формирует одинаковые ПИН-блоки для одинаковых ПИН-кодов на идентичных ключах. При инсайде можно посылать на HSM хостовые команды (KU или KY) и перешифровать ПИН-блок из формата О (ISO) в формат 2 (ISO). Далее злоумышленник сохраняет полученные ПИН-блоки формата «2» и путем их сравнения находит ПИН по известным значениям.

Стоит отметить, что требования по безопасности к эмитентам со стороны стандарта PCI DSS несколько ниже, чем к эквайрерам. Пункт 3.2 Payment Card Industry (PCI) Data Security Standard говорит, что эмитенты и компании, обеспечивающие услуги эмиссии, могут иметь обоснованную необходимость хранения критичных аутентификационных данных. Такая необходимость должна иметь обоснование с точки зрения бизнеса, а хранимые данные должны быть надежно защищены. Получается, что стандарт разрешает эмитентам использовать технологии, которые для эквайреров считаются небезопасными. Например, эмитент может даже передавать ПИН-коды держателям электронным методом в незашифрованном виде — пункт 10.1, подпункт n) Payment Card Industry (PCI) Card Production Logical Security Requirements Version 1.0 May 2013: «n) The PIN must only be decrypted immediately before it is passed to the final distribution channel (e.g., the telephone or e-mail system)». В пункте 3.2.3 PCI DSS version 3.0 говорится, что если ПИН или ПИН-блок будут храниться и будут украдены, то злоумышленник получит возможность совершения мошеннических операций с использованием ПИН-кода (например, для получения наличных через банкомат). При этом указанные данные эквайреру хранить запрещено, а эмитенту они должны быть известны: «These values should be known only to the card owner or bank that issued the card. If this data is stolen, malicious individuals can execute fraudulent PIN-based debit transactions (for example, ATM withdrawals)». Это означает, что, когда банк заявляет о получении сертификата соответствия стандарту PCI DSS, то можно говорить о безопасности чужих карт, а обеспечена ли безопасность собственных карт, неизвестно! Например, многие банки предоставляют услугу по получению ПИН-кода посредством SMS-сообщений. В этом случае ПИН-код передается держателям карт в открытом виде по незащищенному каналу.

Уязвимость эмитентов, сертифицированных на соответствие PCI DSS, подтверждена инцидентами по компрометации критичных аутентификационных карточных данных. 8 ноября 2008 г. в течение 30 минут денежные средства банка Royal Bank of Scotland снимались в более чем 130 банкоматах 49 городов мира, в том числе в Нью-Йорке, Атланте, Чикаго, Монреале, Гонконге, Москве, похищено $ 9 млн. Процессингом Royal Bank of Scotland являлся RBS WorldPay Inc., который на момент компрометации имел сертификат соответствия PCI DSS (дата проверки 31 июля 2008 г., QSA — Trustwave). RBS WorldPay в марте 2009 г. на основании правил PCI DSS был исключен из списка соответствующих стандарту. Но сразу же сделал заявление, что вновь пройдет сертификацию в мае 2009 г. Что и было выполнено (31 мая 2009 г., QSA — Verizon Business). Вероятно, уязвимости, использованные злоумышленниками, не были связаны с невыполнением требований стандарта PCI DSS. Позднее Федеральная служба безопасности России по данному инциденту задержала Виктора Плещука и Евгения Аникина, которым было предъявлено обвинение по пункту «б» части 4 статьи 158 УК РФ «Кража в особо крупном размере». Виктор Плещук заключил досудебное соглашение о сотрудничестве со следственными органами и был приговорен Калининским райсудом Петербурга к шести годам условно. Евгений Аникин был приговорен Заельцовским районным судом Новосибирска к пяти годам лишения свободы условно.