Требования защиты персональной информации для платежных систем очень важны, поскольку в соответствии с ними и выполняется идентификация участников платежей. Если эта информация попадет в ненадлежащие руки или, точнее, базы, то платежной системе и ее пользователям может быть нанесен серьезный финансовый ущерб. Поэтому требования по защите данных уже давно были сформулированы для основных, так называемых принципиальных членов платежных систем — крупных банков и процессинговых центров. Постепенно они распространяются и на мелкие банки и кредитные организации, на торговцев, пользующихся банковскими картами, и даже на производителей программного обеспечения, которое обрабатывает реквизиты платежных карт. Правда, к разработчикам ПО относятся требования несколько другого стандарта — Payment Application Data Security Standard (PA DSS), который предложен тем же PCI Council.
Впрочем, с мелкими банками-агентами и производителями программного обеспечения должны договариваться уже те самые крупные банки, в процессинговом центре которых обрабатываются транзакции. Для небольших банков и торговых компаний требования стандарта остаются на усмотрении принципиальных членов платежной системы, то есть требования по безопасности платежей должны входить в договор о присоединении к платежной системе. Если инцидент произойдет в мелком банке-агенте или в торговой компании, то отвечать за него придется в том числе и крупному банку, к чьему процессинговому центру была подключена незащищенная компания. Поэтому банки, которые привели собственные информационные системы в соответствие со стандартом PCI DSS, теперь стараются транслировать его требования и своим клиентам, и своим поставщикам. «К нам приходят производители программного обеспечения и просят провести экспертизу на соответствие требованиям PA DSS, потому что банки, которым они продают программное обеспечение, уже отказываются устанавливать у себя несертифицированное ПО», — пояснил Юрий Черкас, руководитель направления Центра информационной безопасности компании «Инфосистемы Джет».
Особенности PCI DSS
Стандарты PCI DSS и PA DSS являются низкоуровневыми — они строго определяют, что именно должно быть защищено и какие методы защиты могут для этого использоваться. «В стандарте PA DSS есть требование по аудиту кода приложений, но в нем перечислен строго определенный набор проверок, которые должны быть для этого сделаны, — пояснил ситуацию Рустем Хайретдинов, основатель компании Appercut Security. — При этом в стандарте перечислены не вообще все типы ошибок программирования, а только наиболее опасные ошибки с точки зрения утечки финансовой информации».
От высокоуровневых стандартов безопасности PCI DSS выгодно отличает четко ограниченная сфера применения — в нем требуется только защита реквизитов пластиковой карты. Это, как правило, значительно сужает набор информационных систем, которые нужно проверять на защищенность и приводить в соответствие. Первым шагом на пути к внедрению стандарта как раз и является ограничение по распространению информации о реквизитах пластиковых карт в информационной системе предприятия. «Первое, что нужно сделать в любой организации, становящейся на путь соответствия стандарту PCI DSS, — это определить область применения стандарта, а для этого нужно отследить потоки карточных данных, — рекомендует Павел Федоров, руководитель отдела аудита банков и платежных систем Digital Security. — Зачастую на этом этапе обнаруживается, что карточные данные передаются и обрабатываются не только там, где это необходимо, но и в других системах, в которых вполне можно обойтись и без них. Исключив лишние системы из этого информационного обмена, можно сократить затраты на обеспечение соответствия стандарту. Чем дольше банк занимается обработкой карточных данных, тем выше вероятность нарушений и тем больше возможное количество подобных ситуаций».
Стандарт четко определяет, какие средства защиты должны быть использованы для предотвращения утечки данных. Причем организация PCI Council сама выстроила систему сертификации средств защиты и рекомендует пользователям определенные продукты. Проверяющие из этой организации, впрочем, не настаивают на использовании только этих средств и при определенных условиях признают любые другие. Сертификат лишь упрощает процесс подтверждения соответствия. Кроме того, PCI Council сформировал группу интеграторов и консультантов, которые помогают не просто формально выполнить требования стандарта, но реально защитить данные от утечек. Делается это мягко, но с постепенным усилением давления на нерадивых участников и применением штрафов за неисполнение требований. «На текущий момент существенно возросло понимание ответственности за выполнение требований PCI DSS у организаций-клиентов, — пояснил Федоров. — Выросло количество организаций, желающих достичь соответствия стандарту в связи с требованиями их банков-эквайеров или банков-спонсоров, ранее сертифицированных и обязанных требовать соответствия от всех подключенных к ним нижестоящих платежных шлюзов». Таким образом, участники расчетов проникаются идеей защиты данных и начинают соблюдать общепринятые правила либо просто прекращают работать с соответствующей платежной системой.
Российские требования
PCI DSS — не единственный стандарт безопасности, который относится к банковской сфере. Одним из основных руководящих документов для отечественных банков является стандарт Банка России по обеспечению информационной безопасности организаций банковской системы Российской Федерации (СТО БР ИББС). Этот стандарт определяет требования построения в банковской организации, которая взаимодействует с Центробанком, системы реагирования на инциденты информационной безопасности. Он содержит набор контрольных бизнес-процессов, которые должны реализовать и поддерживать у себя финансовые организации. Стандарт СТО БР ИББС является высокоуровневым и базируется на методологии общего ИБ-стандарта ISO 27001 для построения системы управления информационной безопасности и на общих рекомендациях по защите COBIT. Стандарт до сих пор формально является рекомендательным, но он относится не только к платежной системе банка, но и ко всей информационной системе финансовой организации, что затрудняет его реализацию. В частности, для мелких банков он, скорее всего, является избыточным.
Летом 2011 года был принят новый ФЗ-161 «О национальной платежной системе» (НПС), в котором также предусмотрены требования по информационной безопасности. Они были установлены этим летом Центробанком в «Положении о требованиях к обеспечению защиты информации при осуществлении переводов денежных средств и о порядке осуществления Банком России контроля за соблюдением требований к обеспечению защиты информации при осуществлении переводов денежных средств», которое обычно называют «Положение 382-П Центробанка», оно вступило в силу 1 июля этого года. Распространяется оно на операторов по переводу денежных средств, таких как банк, на банковских платежных субагентов, на операторов платежных систем и на операторов услуг платежной инфраструктуры (процессинговые центры). За соблюдением требований безопасности со стороны субагентов следит уже не ЦБ, а операторы платежной системы. Аналогичная схема ответственности используется и в PCI DSS.
Впрочем, по списку требований положение ЦБ сильно напоминает требования общего стандарта СТО БР ИББС. Вот как прокомментировал ситуацию Алексей Лукацкий, менеджер по развитию бизнеса Cisco: «Для тех, кто так и не решился на внедрение СТО БР ИББС, многое в Положении Центробанка будет в новинку. Ну а для тех, кто уже внедрил или находится в процессе внедрения cтандарта ЦБ, действительно революционных вещей не будет, за исключением, пожалуй, вопросов отчетности».
Можно сказать, что положение о защите НПС объединяет принципы PCI DSS с требованиями стандарта Центробанка России. Аналогичного мнения придерживается и Федоров: «Если говорить кратко – стандарт PCI DSS и российские стандарты дополняют друг друга. Если же вдаваться в подробности, то и стандарт СТО БР ИББС, и ФЗ-161, и документ 382-П, которые между собой в значительной степени пересекаются и в части требований совпадают, требуют в первую очередь полного документирования и фиксации всех процессов и использования тех или иных мер защиты. Стандарт PCI DSS же в первую очередь ориентирован на фактическое выполнение требований по обеспечению информационной безопасности и во многом указывает конкретные меры, которые необходимо предпринять».
Есть и определенная российская специфика в положении 382-П. В частности, российские требования для платежных систем не только касаются защиты сведений о платежной карте, как это определено в PCI DSS, но и относятся к более широкому спектру информации: об остатках на счетах, о переводах денежных средств, об оформленных распоряжениях, о клиринговых позициях и многом другом, включая и персональные данные. Эти данные могут распространяться по информационной системе несколько шире, поэтому и средств защиты придется задействовать больше. Притом, если защита от несанкционированного доступа может быть не сертифицирована, то инструменты, использующие криптографическую защиту, должны иметь лицензию ФСБ. Хотя требования к защите платежных систем определены, российские операторы платежей пока не торопятся реализовывать их. Ситуацию прояснил Лев Фисенко, директор департамента компании «Информзащита» по работе с финансовыми организациями: «В положении Центробанка есть определенные несоответствия с другими требованиями регуляторов, поэтому до выяснения всех подробностей российские банки не торопятся реализовывать изложенные в этом положении требования». Контрольные функции в этой сфере возложены на Центробанк, поэтому дальнейшее развитие средств защиты НПС зависит от действий этого регулятора.
Рекомендации аудитора
В качестве практических рекомендаций приводим список мер, предложенный Павлом Федоровым, руководителем отдела аудита банков и платежных систем компании Digital Security, старшим аудитором PCI QSA и PCI PA-QSA:
Первое, что нужно сделать в любой организации, становящейся на путь соответствия стандарту PCI DSS, — это определить область применения стандарта, для чего необходимо отследить потоки карточных данных. После этого нужно выделить в самостоятельное подразделение всех сотрудников, так или иначе занимающихся обработкой карточных данных. При этом функция проверки состояния информационной безопасности должна лежать на другом подразделении – обычно это служба ИБ банка. Также необходимо выделить в отдельную инфраструктуру все серверы, так или иначе участвующие в обработке, хранении или передаче карточных данных. Таким образом, появятся границы области применения стандарта PCI DSS, в рамках которых и будут разрабатываться документация и выполняться требования стандарта. После этого рекомендуется оценить сложность приведения к соответствию тех или иных системных компонентов: в случае использования морально устаревших систем, возможно, окажется разумнее заменить их на более современные аналоги, чем пытаться привести существующие к соответствию требованиям стандарта. Также можно оценить уровень гетерогенности инфраструктуры и при возможности гомогенизировать ее.
Разобравшись с оборудованием, можно начать документировать процессы, связанные с обеспечением безопасности при обработке карточных данных: в ходе документирования могут выявиться дополнительные задачи. Появившиеся как результат процедуры, скорее всего, не будут соответствовать стандарту, однако при их наличии легче прийти к соответствию, потому что будет видно, в чем именно заключаются проблемы.
Отдельная задача – формирование пакета нормативных документов, регламентирующих те или иные требования к обеспечению информационной безопасности при обработке карточных данных. Обычно пакет документов включает в себя политику информационной безопасности и набор частных политик. Политика информационной безопасности является достаточно общим документом, поэтому нередко требуемые элементы включаются в общую политику информационной безопасности всего банка. В некоторых же случаях политика принимается на уровне подразделения, имеющего доступ к карточным данным. С точки зрения стандарта это неважно — главное, чтобы политика распространялась на всех сотрудников, которые, согласно своим должностным обязанностям, могут иметь доступ к карточным данным.
Дальше остается лишь приводить уже документированные процессы к требованиям нормативных документов. Помочь же в определении важности тех или иных изменений для достижения соответствия может периодическая проверка как собственными силами, так и с привлечением аккредитованных компаний с использованием приоритетного подхода, рекомендуемого Советом PCI Council.