Введение

Стандарт PCI DSS содержит ряд требований, связанных с физическим размещением информационной инфраструктуры, т.е. с тем, где и в каких условиях расположены ее компоненты. Основная часть этих требований представлена в девятом разделе стандарта, посвященном физической безопасности данных о держателях карт (ДДК). Кроме того, поскольку выбор варианта физического размещения влияет на организацию каналов связи, он также влияет на выполнение следующих требований: межсетевое экранирование (раздел 1), шифрование ДДК при их передаче через сети общего пользования (раздел 4) и применение двухфакторной аутентификации при удаленном доступе (требование 8.3). Еще четыре требования, связанные с привлечением сторонних поставщиков услуг, определенные в подразделе 12.8, должны быть исполнены в случае размещения на площадке хостинг-провайдера.

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

Выполнение требований стандарта PCI DSS при размещении серверов на территории сертифицируемой организации

Начнем с рассмотрения самого, пожалуй, привычного варианта — когда компоненты информационной инфраструктуры расположены в собственной серверной комнате на территории организации.

В части обеспечения физической безопасности информационной инфраструктуры, согласно девятому разделу стандарта PCI DSS, организация должна применять меры, описанные ниже.

1. Ограничить и контролировать физический доступ во все помещения, в которых расположены компоненты среды ДДК, включая серверные комнаты. Для этих целей должны применяться:

   • запирающие устройства на основе смарт-карт или механических замков;

   • системы контроля доступа, включая видеонаблюдение и системы на основе смарт-карт.

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

   Журналы событий систем контроля доступа, должны регулярно анализироваться на предмет наличия нарушений пропускного режима. Необходимо сохранять эти журналы, как минимум, три месяца.

2. Ограничить и контролировать доступ посетителей. Для этого в организации необходимо сделать следующее:

   • обеспечить возможность легко различать сотрудников и посетителей. Например, с помощью выдачи им отличающихся бейджей или пропусков;

   • ограничить доступ, предоставляемый по посетительским пропускам, таким образом, чтобы исключить проникновение посетителей без сопровождения сотрудников в помещения, где расположены компоненты информационной инфраструктуры;

   • ограничить срок действия пропусков, выдаваемых посетителям;

   • вести журнал учета посетителей, содержащий имя посетителя, название представляемой им организации, сотрудника, предоставившего ему доступ. В журнале должны регистрироваться все факты прохода посетителя в помещения, в которых расположены компоненты информационной инфраструктуры.

3. Ограничить доступ к сетевым разъемам, расположенным в общедоступных местах. Для этого необходимо отключать неиспользуемые сетевые разъемы, а также исключать наличие посетителей без сопровождения в помещениях с активными сетевыми разъемами.

4. Обеспечить учет, инвентаризацию и маркирование материальных носителей ДДК, а также контроль их передвижения. К таким носителям относятся и сервера. Например, необходимо учитывать и контролировать отправку серверов в ремонт и утилизацию носителей резервных копий.

Выполнение требований стандарта PCI DSS при размещении серверов на площадке хостинг-провайдера

Второй вариант, распространенный в основном среди небольших организаций индустрии платежных карт, это размещение серверов на площадке хостинг-провайдера.

Стандарт PCI DSS гласит, что все поставщики услуг, имеющие доступ к ДДК, либо способные повлиять на их безопасность, должны пройти сертификацию по PCI DSS. Хостинг-провайдеры относятся к числу таких поставщиков. При этом, согласно требованию 12.8, каждая организация, использующая услуги таких поставщиков, в рамках работ по достижению соответствия стандарту, должна убедиться в том, что все эти поставщики соответствуют его требованиям.

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

• Размещение на площадке сертифицированного по PCI DSS хостинг-провайдера, и

• Размещение на площадке не сертифицированного хостинг-провайдера с применением компенсирующих мер защиты.

Общими для этих вариантов являются следующие требования стандарта (описанные в требовании 12.8):

• необходимо поддерживать актуальный перечень поставщиков услуг, имеющих доступ к ДДК;

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

• необходимо проводить тщательную проверку благонадежности каждого поставщика услуг перед началом взаимодействия с ним.

Размещение на площадке сертифицированного по PCI DSS хостинг-провайдера

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

При этом, в отношении требований, связанных с организацией каналов связи, необходимо учесть следующий момент. В отличие от случая с размещением серверов на территории организации, связь с рабочими станциями и прочими компонентами среды ДДК, находящимися вне дата-центра хостинг-провайдера, будет организована посредством общедоступных каналов связи. Соответственно, для этих каналов связи необходимо в полной мере выполнить требования стандарта в части:

• межсетевого экранирования (раздел 1);

• шифрования ДДК при их передаче (раздел 4);

• применения двухфакторной аутентификации при удаленном доступе (требование 8.3).

Внутренние каналы связи между расположенными на одной площадке серверами, предоставляемые сертифицированным по PCI DSS хостинг-провайдером, и защищенные межсетевыми экранами, можно рассматривать, как доверенные.

Теперь давайте посмотрим, какие конкретно предложения доступны на рынке сертифицированного по PCI DSS хостинга. Как мы уже упомянули выше, в России, на данный момент, такие предложения отсутствуют. Поэтому, мы вынуждены обратиться к зарубежным поставщикам. При этом, нас, как представителей евразийского континента, будет интересовать, прежде всего, европейский сегмент рынка. Именно ему мы уделим основное внимание в нашем исследовании.

Для получения исходной информации воспользуемся Перечнем поставщиков услуг, подтвердивших соответствие PCI DSS, опубликованным международной платежной системой VISA. Таких документов два: Глобальный перечень сертифицированных поставщиков услуг (от 5 мая 2010 года) и Европейский перечень сертифицированных поставщиков услуг (от 4 мая 2010 года). Эти перечни подходят для наших целей, потому что они содержат информацию о видах предоставляемых провайдерами услуг, а также отделяют европейский сегмент рынка от остального мира. В качестве альтернативы можно рассмотреть аналогичный документ от MasterCard Compliant Service Providers, однако, он не содержит такой информации и, следовательно, не позволяет оперативно сделать выборку хостинг-провайдеров из общего числа поставщиков услуг или произвести их географическое деление. Поэтому, исходя из предположения, что большинство хостинг-провайдеров, получивших статус соответствия PCI DSS, предоставили информацию о себе в обе рассматриваемые платежные системы, остановимся на перечне от VISA.

Из европейского перечня нами были выбраны те компании, которые заявили, что предоставляют хостинг в качестве основного вида сертифицируемых услуг. Уже на этом этапе стало очевидно, что в России сертифицированные по PCI DSS хостинг-провайдеры отсутствуют. Затем, был проведен анализ сайтов выбранных компаний, и из них выделены только те, которые предлагают услуги по размещению физических или виртуальных серверов. В итоге, был получен перечень из шести хостинг-провайдеров, обладающих статусом соответствия PCI DSS и предоставляющих на рынке стран Европы интересующие нас услуги. Мы связались с этими компаниями для получения дополнительной информации.

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

Atos Origin — предлагает размещение как физических, так и виртуальных серверов;

DATAPIPE — предлагает размещение как физических, так и виртуальных серверов. Сертифицированный по PCI DSS дата-центр расположен на территории Великобритании;

DanDomain — предлагает размещение физических или виртуальных серверов, а также аренду собственных физических серверов. Стоимость размещения виртуального сервера начинается от 67 евро в месяц и зависит от набора дополнительных услуг и объема трафика. Размещение физического сервера стоит от 100 евро в месяц;

Foreshore —предлагает размещение физических серверов на своей площадке с соответствием PCI DSS, и планирует распространить действие своего сертификата соответствия на сервис виртуальных серверов в июле 2010 года;

Informations Technlogie Austria — предлагает размещение виртуальных серверов под управлением различных операционных систем;

TelecityGroup — предлагает размещение физических серверов на своей площадке с соответствием PCI DSS, а также множество дополнительных сервисов, таких как управляемый межсетевой экран, системы обнаружения и предотвращения вторжений (IDS/IPS) и резервное копирование.

Информацию об ориентировочной стоимости услуг удалось получить только на сайте DanDomain, она представлена выше. Остальные отреагировавшие на наш запрос компании ответили, что стоимость определяется в зависимости от специфики потребностей каждого конкретного клиента.

Кроме того, мы убедились в том, что наиболее развит рынок хостинга с соответствием PCI DSS на территории США. Мы связались с одной американской хостинговой компанией и получили следующую информацию:

Stafford associates — предлагает размещение физических или виртуальных серверов на собственной площадке с соответствием PCI DSS. Пространство на 20 юнитов с электропитанием на 8 ампер и 16 IP-адресами обойдется клиенту в $480 в месяц;

На территории США действует множество хостинг-провайдеров, обладающих статусом соответствия PCI DSS. Мы не приводим здесь их полный перечень с подробным описанием лишь из соображений краткости изложения материала.

Размещение на площадке не сертифицированного хостинг-провайдера с применением компенсирующих мер защиты

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

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

1. преследовать ту же цель, что и прямое требование PCI DSS;

2. обеспечивать ту же степень защищенности, что и прямое требование PCI DSS, чтобы снизить риск также эффективно, как и прямое требование;

3. не быть выполнением другого требования PCI DSS;

4. быть соизмеримыми с дополнительным риском, вызванным невозможностью выполнить требование PCI DSS.

Какие же меры необходимо принять в качестве компенсирующих?

Начнем с физической безопасности, т.к. именно она претерпевает наибольшие потрясения в момент, когда мы размещаем серверное оборудование на «чужой» территории. Задачу компенсирующих мер, направленных на исполнение требований девятого раздела стандарта, можно рассматривать как задачу создания на территории хостинг-провайдера замкнутого пространства, контролируемого клиентом. Для ее исполнения рекомендуем принять следующие меры:

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

• Систему запирания шкафов следует дополнить системой контроля и управления доступом, основанной на личных картах или других технологиях, позволяющих выполнять автоматическую идентификацию лиц, получающих физический доступ к компонентам информационной инфраструктуры. Журналы регистрации фактов физического доступа, должны сохраняться, как минимум, в течение трех месяцев;

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

• Шкафы следует оборудовать системой видеонаблюдения. В случае согласия со стороны хостинг-провайдера, должен просматриваться весь наружный периметр серверных шкафов. В противном случае, систему видеонаблюдения необходимо установить внутри каждого шкафа, обеспечив просмотр проема его дверцы. Получаемые от системы данные должны сохраняться, как минимум, в течение трех месяцев;

• Необходимо обеспечить моментальное автоматическое информирование ответственного сотрудника компании о каждом факте открытия серверного шкафа. Такое информирование может быть выполнено на основе сервисов sms или e-mail. Желательно, но не обязательно, с приложением фотоснимка того, кто открыл дверцу, сделанного системой видеонаблюдения в момент регистрации события;

• Разработать, внедрить и выполнять ежедневные процедуры контроля физического доступа, анализа журналов событий физического доступа и данных системы видеонаблюдения.

• Разработать, поддерживать в актуальном состоянии и регулярно тестировать планы реагирования на инциденты, связанные с физическим доступом к ИТ-инфраструктуре.

Все эти меры должны обеспечиваться и контролироваться самим клиентом, а не хостинг-провайдером, которого, при отсутствии у него сертификата соответствия PCI DSS, следует рассматривать как недоверенную среду.

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

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

Выполнение требований стандарта PCI DSS для рабочих станций сотрудников

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

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

Заключение

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

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

Кто будет первым?

Если перейти от более общей проблемы к платежной среде и рассмотреть подробнее статистику того, какие системы чаще всего подвергаются атакам (Отчет Verizon), то это будут: POS-терминалы (32%), СУБД (30%), серверы приложений (12%), web-серверы (10%). На рабочие станции, серверы аутентификации, серверы резервного копирования, файловые хранилища и прочее выпадает только 10%. Из данной статистики также наглядно видна актуальность безопасности именно приложений, так как через их уязвимости чаще всего становится возможным получение доступа к данным.

Что же крадут злоумышленники и какие данные им интересны? Данный вопрос был освящен в двух различных отчетах: компании Verizon и Trustwave. По их данным, в 85% и 98% соответственно, целью атаки были именно карточные данные. Честно говоря, цифры шокирующие. Еще два интересных исследования были проведены данными компаниями. Компания Verizon проводила поверхностную проверку на соответствие PCI DSS компаний, у которых произошел инцидент, связанный с кражей данных. В результате данных проверок была получена статистика, показывающая, на сколько процентов в среднем соответствовали компании различным требованиям стандарта PCI DSS. Самым последним в этом списке было требование 6 («Безопасность приложений»), которому компании в среднем соответствовали на 5%. В отчете компании Trustwave было показано что ни одна из компаний, в которой произошел инцидент, не соответствовала полностью пункту 6 стандарта PCI DSS, отвечающему за безопасность приложений. Что мы имеем в итоге, на самом деле парадоксально. С одной стороны, «Безопасность приложений» одно из наименее часто выполняемых требований, а, с другой стороны, через уязвимые приложения происходит большинство инцидентов, что странно со стороны компании, которая пытается защитить свои данные, но логично со стороны злоумышленника.

Если бы вы спросили у злоумышленника как украсть деньги, он бы без тени сомнения ответил: “Естественно через уязвимые приложения”. Нельзя не согласиться с этим мнением, озвученным в статье на портале Pcworld, ведь, действительно, какой смысл придумывать какие-то сложные схемы, если через банальную SQL-инъекцию в платежном приложении можно получить базы номеров карт. Данная атака была не раз продемонстрирована в ряде отчетов по инцидентам, даже в тех компаниях, в которых были выполнены требования стандарта PCI DSS.

К слову об инцидентах, прямые потери финансовых структур в США от инцидентов составляют 7.5 млрд долларов в год. Для сравнения эти потери составляют стоимость порядка 50 крупных островов. В Англии потери от фрода, по данным APACS, составили порядка 500 млн долларов. Что касается России, то цифры тоже существенные. По данным АРБР, годовой ущерб от действий кардеров составляет порядка 30 млн долларов. Это все были прямые потери компаний, в которые не входят удар по репутации и потеря клиентов, а также возможная потеря бизнеса. Например, если вспомнить всем известный инцидент с Heartland, то стоимость акций этой компании на нью-йоркской бирже упала в 10 раз за 1 неделю, а такие падения даже в недавний кризис случалась крайне редко.

После такого отнюдь не радужного вступления встает резонный вопрос - Что делать?

Первым на помощь пришел документ Visa PABP, который являлся набором лучших практик по безопасности платежных приложений и состоял из различных требований к платежным приложениям. Тем не менее, множество действительно важных требований, относящихся к безопасности, через которые и осуществляются атаки на приложения, не были освещены в данном стандарте. К таким требованиям можно отнести: удаление критичных данных после истечения максимально допустимого срока хранения данных, хранение и передача паролей в зашифрованном виде, ряд требований по безопасному программированию, аудит управления изменениями и прочее.

Следующим этапом в повышении безопасности платежных систем было появление стандарта PCI DSS, который, в отличие от PABP, стал обязательным и регламентировал выполнение требований по безопасности для систем, обрабатывающих карточные данные. В нем уже достаточно четко были прописаны требования, относящиеся к любым приложениям и системам, которые обрабатывают карточные данные. Тем не менее, данный стандарт был направлен на компании, осуществляющие обработку карточных данных, а не на приложения, что на практике породило множество проблем, мешающих компаниям достичь соответствия PCI DSS из-за приложений, которые не поддерживают эти требования или напрямую им противоречат. Ведь в случае если у приложения, которое использует компания, передаются пароли в открытом виде, необходимо «накручивать» дополнительные средства защиты в виде шифрования и оформлять компенсирующие меры; если не был проведен аудит на наличие программных уязвимостей, то необходимо приобрести и установить межсетевой экран уровня приложений, а если приложение, не дай Бог, хранит TRACK после авторизации, то компания и вовсе лишается возможности получить сертификат соответствия PCI DSS.

Учитывая важность требований безопасности к платежным приложениям с одной стороны, и совместимость этих приложений с требованиями стандарта PCI DSS с другой стороны, советом PCI SSC был разработан стандарт PA-DSS. Стандарт призван обеспечить безопасность приложений и совместимость с требованиями PCI-DSS и перенести ответственность за это на производителей программного обеспечения, у которых до этого момента руки были развязаны.

На самом деле, производитель, проходя аудит, получит ряд преимуществ. Во-первых, это возможность оставаться на рынке, так как после 1 июля 2012 года использование не сертифицированных приложений компаниями, попадающими под действие стандарта PCI DSS, будет запрещено. Во–вторых, это повышение защищенности приложения, что само по себе стоит не малых денег, и гораздо выгоднее его осуществить в связке сертификацией по PA-DSS, чем в рамках отдельной работы. В-третьих, это конкурентное преимущество на рынке, так как компании, выбирающие платежные приложения или собирающиеся поменять поставщика услуг, уже сейчас будут смотреть в сторону сертифицированных приложений. Ну и наконец, громкий пресс-релиз и листинг приложения на сайте PCI SSC в списке сертифицированных приложений – это еще один шаг для повышения “веса” приложения на рынке.

Преимущества использования сертифицированных по PA-DSS приложений компаниями, попадающим под действие стандарта PCI DSS очевидны. Во-первых, они так же получают возможность оставаться на рынке после начала даты действия стандарта, во-вторых, компания уменьшает количество необходимых для выполнения требований PCI DSS, перенося их на разработчика приложений и сокращая расходы на соответствие PCI DSS, в-третьих, компания получает руководство по безопасному внедрению (Implementation Guide), которое также помогает привести систему в соответствие стандарту PCI DSS и, наконец, в-четвертых, что наиболее важно – они получают безопасное приложение, тем самым существенно уменьшая риск компрометации данных.

Причем следует отметить, что эта безопасность не формальна. За ней стоит реальный аудит безопасности с применением общепризнанных методик, таких как OWASP и WASC на наличие программных уязвимостей. Стоит отметить, что аудит на наличие программных уязвимостей – это далеко не только статический анализ кода стандартными утилитами на наличие типовых строк, таких как strcpy, указывающих на возможное наличие уязвимости переполнения буфера, и не только blackbox fuzzing с использованием типовых программных средств, это еще и глубокий интеллектуальный анализ бизнес-логики приложения и поиск соответствующих уязвимостей в процессе реальной работы приложения. Как следует из опыта DSecRG по анализу защищенности бизнес-приложений, значительная доля уязвимостей относится именно к классу логических ошибок, которые не обнаруживаются стандартными утилитами, что также подтверждается известными западными компаниями в их отчетах. В списке TOP 10 уязвимостей, составленном компанией Cenzic (производитель сканера для поиска уязвимостей в WEB-приложениях), на 2 месте (22% уязвимостей) находятся логические уязвимости, связанные с контролем доступа, а в аналогичном списке компании Trustwave логические ошибки занимают второе место, а третье и четвертое принадлежит ошибкам авторизации и аутентификации. Для поиска ошибок такого класса в отличие от переполнений буфера и различных инъекций кода, не существует программных средств, полностью автоматизирующих данный процесс, поэтому уповать можно только на опыт конкретного эксперта в области анализа защищенности приложений.

И, естественно, самый главный мотиватор – это официальные сроки, установленные платежными системами. Условия Visa таковы: начиная с 1 июля 2010 года, вновь подключаемые к эквайерам торгово-сервисные предприятия должны использовать только сертифицированные по стандарту PA-DSS платежные приложения или быть проверены по PCI DSS. Начиная с 1 июля 2012 года, эквайеры должны гарантировать, что все торгово-сервисные предприятия и агенты используют только сертифицированные по стандарту PA-DSS платежные приложения. Условия MasterCard немного мягче. Они требуют, чтобы начиная с 1 июля 2012 года, все торгово-сервисные предприятия и поставщики услуг должны использовать только сертифицированные по стандарту PA-DSS платежные приложения.

Рекомендации по устранению найденных несоответствий: краткие или детальные?

При проведении предварительного аудита на соответствие стандарту PCI DSS QSA-аудитор в своем отчете по каждому обнаруженному несоответствию может привести краткие рекомендации по устранению данного несоответствия, например: «безопасно настроить СУБД Oracle в соответствии с такими-то конкретными лучшими практиками и т. д.». Обычно это входит в базовую стоимость предварительного аудита. Для QSA-аудитора является жестом доброй воли выдать краткие типовые рекомендации даже при официальном сертификационном аудите, результатом которого не явилась констатация факта полного соответствия.

Однако заказчику с уровнем соответствия менее 50% стоит обратить внимание на то, что на практике такой подход означает следующее: при дальнейшей подготовке к сертификации он сам будет изучать обозначенную QSA-аудитором проблему и искать варианты, как именно ему выполнить данное требование. Очевидно, что для заказчика (особенно крупного) это часто бывает затруднительно, поскольку требует серьезных затрат времени и ресурсов. В результате такая схема автоматически приведет к необходимости заказа дополнительного расширенного консалтинга при внедрении решений по устранению несоответствий.

На этом фоне заказчику стоит обратить внимание на возможность получения от QSA-аудитора экспертного заключения по результатам проведенного аудита с детальными рекомендациями по приведению информационной инфраструктуры в соответствие PCI DSS. Такое заключение предоставляется в качестве дополнительной услуги сразу после проведения предварительного аудита в виде отдельного документа объемом 20–100 страниц. Это значительно упростит дальнейший процесс подготовки к сертификации, хотя по своей сути является не более чем полезной опцией предварительного аудита для заказчика.

План приведения к соответствию PCI DSS (Action Plan)

Очень часто заказчик в предложении от QSA может обнаружить фразу: «План приведения информационной инфраструктуры в соответствие требованиям PCI DSS (Action Plan)». При этом сама фраза зачастую подается очень пафосно в контексте отдельной части коммерческого предложения. заказчика, тем самым, пытаются убедить в том, что именно этот документ решит все его проблемы с соответствием. Однако парадокс ситуации заключается в следующем: под достаточно громким названием скрывается сугубо формальный документ на одну страницу (!), который отправляется в международные платежные системы и который обычно заполняется … самим же заказчиком (QSA-аудитор лишь консультирует заказчика при его заполнении или оказывает в этом некую помощь). Этот документ необходим только в том случае, если аудит был сертификационным (не предварительным), и его результаты не показали полного соответствия. Содержанием данного документа является не более чем перечень из основных этапов достижения соответствия с указанием сроков их планируемого выполнения. Цель у документа единственная – проинформировать международные платежные системы (МПС) о том, когда именно в следующий раз (но не далее, чем через один год) можно обоснованно требовать от компании соответствия PCI DSS. Для формальной процедуры сертификационного аудита Action Plan – это просто форма отчетности и не более того.

В случае предварительного аудита, цель которого – сделать первый шаг на пути к соответствию, заказчик обычно не сообщает о его результатах в МПС, и поэтому формальный Action Plan не является обязательным, так как ни коим образом не приближает к достижению соответствия. Самое главное, что должен понимать заказчик: что несмотря на пафосное название, речь идет не более чем о кратком сугубо формальном документе, который не имеет отношения к содержательной части процесса устранения несоответствий и практически никак не поможет при дальнейшей подготовке к сертификации, разве что обозначит временные ориентиры.

Достижение соответствия PCI DSS

Технический проект, детально описывающий все вносимые в IT систему изменения

После проведения предварительного аудита и разработки экспертного заключения с детальными рекомендациями для последующего перехода к стадии внедрения (приведение IT-системы в соответствие) заказчику необходим детальный технический проект, описывающий все вносимые в систему изменения для ее приведения в соответствие требованиям стандарта. Без подобного проекта тем более никак не обойтись в случае необходимости внесения масштабных изменений, особенно если речь идет о крупном банке, где в наших реалиях процессинг часто не выделен из информационной инфраструктуры банка, а наоборот, глубоко в нее интегрирован. Данный проект разрабатывается на основе отчета о проведенном на первом этапе аудита и экспертного заключения, выданного QSA-аудитором. Проект разрабатывается либо самим заказчиком (если он планирует самостоятельную реализацию технических мероприятий по достижению соответствия) или компанией – системным интегратором, которого заказчик планирует привлечь для реализации проекта достижения соответствия PCI DSS.

На данном этапе одной из важнейших консалтинговых задач для QSA-аудитора является согласование итогового технического проекта с точки зрения его соответствия требованиям стандарта PCI DSS во избежание возможных дальнейших проблем при внедрении. Это крайне важный этап, про который ни в коем случае не стоит забывать заказчику.

Консалтинг при внедрении, контрольные проверки и предсертификационный аудит

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

1. Консалтинг при внедрении

В этом случае QSA-аудитор (хотя здесь более уместным будет употребить термин QSA-консультант) отвечает на все вопросы, которые возникают у специалистов заказчика или интегратора в ходе реализации проекта по достижению соответствия PCI DSS.

2. Контрольные проверки

Практика показывает, что имеет смысл разбить весь проект на этапы, между которыми расставляются контрольные точки, по которым QSA-консультант имеет возможность контролировать ход проекта, оценивая на объекте все внесенные к моменту проверки изменения (после предыдущей проверки) с точки зрения корректности выполнения требований стандарта.

3. Предсертификационный аудит

Для 100%-ной гарантии успешного прохождения итогового сертификационного аудита при масштабном проекте достижения соответствия PCI заказчику может потребоваться предсертификационный аудит, который выявит мелочи, которые могли быть упущены в процессе реализации проекта достижения соответствия. При этом наличие контрольных проверок в ходе внедрения, очевидно, не отменяет необходимости проведения предсертификационного аудита, хотя оба этих контрольных элемента и являются опцией.

Сертификация

Тесты на проникновение, ASV-сканирование

Про специфику предлагаемых на рынке России и стран СНГ «тестов на проникновение» (то, что в 99% случаев предлагается у нас на рынке под этим ярлыком, было бы некорректно упоминать иначе как в кавычках), обязательных для достижения соответствия PCI DSS, написана уже не одна статья. Заказчику стоит обращать внимание на то, что любая попытка выдать за пентест обычное сканирование (чем часто грешат, к сожалению, в том числе и некоторые QSA-компании) является заведомым нарушением требований стандарта и ведет к лишению QSA-компании этого статуса и проблемам для заказчика, которому данная QSA-компания выдала сертификат, – последний неминуемо будет отозван Советом PCI SSC. Низкая цена на пентест автоматически означает то, что это будет простой запуск сканера, и свидетельствует об отсутствии необходимой квалификации у компании, которая его проводит. Иными словами, «опасайтесь подделок!».

Что же касается ASV-сканирования, то здесь на нашем рынке наблюдается прямо противоположная, но не менее парадоксальная картина в виде необоснованно дорогого сканирования. ASV-сканирование у большинства ASV-вендоров является автоматической услугой, позволяющей заказчику самостоятельно запустить через web-сайт вендора в удобное для заказчика время сканер и получить отчет об ASV-сканировании. Процедура полностью автоматизирована, из-за этого число проверок практически не ограничено – соответственно, ASV-сканирование, по определению, не может стоить дорого. Разговоры о качестве ASV-сканирования лишены всякого смысла, так как все ASV-вендоры имеют официальный статус и сканируют в строгом соответствии с процедурой, определенной Советом PCI SSC. Во-вторых, даже если кто-то сканирует чуть лучше, а кто-то чуть хуже – в любом случае существует дополнительная ручная проверка – тест на проникновение, не имеющий никакого отношения к ASV-сканированию, который дает дополнительные гарантии защищенности внешнего периметра.

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

Вывод

Как наглядно показывают вышеприведенные примеры из практики, заказчику стоит очень внимательно подходить к выбору QSA-аудитора, поскольку здесь существует масса различных нюансов, имеющих далеко идущие последствия.

Область соответствия и область аудита

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

Для начала следует сказать, что есть разница между тем, какие системы должны соответствовать стандарту PCI DSS и тем, какие системы подлежат проверке в ходе QSA-аудита. Эти области не всегда совпадают.

Любая система, хранящая, обрабатывающая, либо передающая данные о держателях карт, должна соответствовать требованиям стандарта PCI DSS. Пусть даже если это PAN одной единственной карты. Эту область назовём термином «область соответствия».

Что касается области, подлежащей проверке на соответствие требованиям стандарта в ходе QSA-аудита, то для большинства организаций она совпадает с изолированной областью соответствия (средой данных о держателях карт, CDE). Назовём множество систем, подлежащее проверке, «областью аудита».

Однако для банков здесь не всё так просто. Позиция Совета PCI SSC изложена на его официальном сайте в разделе «Часто задаваемые вопросы». В ответе на вопрос «применим ли стандарт PCI DSS к эмитентам?» Совет сообщает следующее: «Стандарт PCI DSS применим ко всем сущностям, хранящим, обрабатывающим или передающим данные о держателях карт и все эти сущности должны соответствовать PCI DSS, включая эмитентов. Однако каждая международная платежная система применяет свою собственную программу управления соответствием PCI DSS, определяющую кто проверяет соответствие PCI DSS, уровни поставщиков услуг и торгово-сервисных предприятий, а также крайние сроки достижения соответствия. По своему усмотрению международные платежные системы могут потребовать у эмитентов проверить соответствие PCI DSS. Для уточнения детальных требований к проверке соответствия связывайтесь с международными системами».

Ответы международных платежных систем на вопрос о том, входит ли эмиссионная часть карточной инфраструктуры банка в область QSA-аудита, определенности не добавляют. Письма содержат общие слова о том, что все карточные системы должны соответствовать стандарту. При этом акцент ставится на слова «должны соответствовать», и без этого очевидные. От прямого ответа на конкретный вопрос о вхождении в область QSA-аудита эмиссионной части инфраструктуры международные платежные системы предпочитают уклоняться, оставляя за собой право выборочной проверки.

Сложившаяся на рынке практика QSA-компаний, причем как российских, так и западных, предполагает следующий подход: соответствовать должны все системы, так или иначе связанные с данными о держателях карт, но проверке соответствия стандарту PCI DSS подлежит только эквайринговая часть платежной инфраструктуры, если речь идет о банке. Граница между эквайринговой и эмиссионной частью, которую, к слову, бывает очень непросто провести, проходит по обработке «On-Us» транзакций. Поток данных эквайринговой «On-Us» транзакции проверяется на соответствие стандарту, а всё, что связано с процессом выпуска карт, остается за рамками аудита. Безусловно, подразумевается то, что эмиссионная часть отделена от эквайринговой корректно настроенным межсетевым экраном, иначе эмиссия попадет в область аудита по формальному признаку связанной системы.

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

Минимизация области соответствия

Приводить в соответствие требованиям стандарта необходимо всю область соответствия, к которой относятся все системы, хранящие, обрабатывающие и передающие данные о держателях карт. При правильном подходе эту область можно значительно сократить. Вывести из неё информационные системы можно двумя основными способами:

• исключение данных о держателях карт из отдельных систем, если это позволяют бизнес-требования;

• изоляция области соответствия при помощи межсетевых экранов.

Исключение данных о держателях карт из отдельных систем

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

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

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

Изоляция области соответствия и внедрение DMZ

После того, как в перечне остались только те системы, которым работа с карточными данными необходима с точки зрения бизнеса компании, необходимо подумать об их изоляции. Дело в том, что по правилам, определенным в стандарте, в область аудита входят все системы хранящие, передающие или обрабатывающие данные о держателях карт, а также связанные с ними системы. Под связанными понимаются системы, соединения с которыми не защищены корректно настроенными межсетевыми экранами.

Особенно остро проблема выделения карточных систем в отдельный сегмент стоит в банках, которые имеют масштабные информационные инфраструктуры, часто бывающие распределенными территориально.

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

На рисунке 1 приведен пример не рекомендуемой схемы изоляции среды данных о держателях карт, когда DMZ устанавливается на входе каждого канала связи с внешней средой. Терминалы торгово-сервисных предприятий и банкоматы могут подключаться к сети банка через его филиалы (каналы связи C-1, C-2 и C-3), и им требуется соединение с CDE. В этом случае на маршрутизаторе (межсетевом экране) R-2 потребуется открыть входящие соединения из сетей DMZ-1, DMZ-2, DMZ-3. Эти сети попадут в область аудита, так как будут являться связанными. Такое решение имеет право на жизнь, однако потребует от банка значительных ресурсов на достижение и поддержание соответствия. Филиалы, где расположены такие DMZ, придется приводить к соответствию PCI DSS, а аудитору придется их все обследовать в ходе QSA-аудита, что значительно повысит затраты банка.

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

Рисунок 1. Не рекомендуемое решение

Рисунок 2. Рекомендуемое решение

Основной задачей стандарта, как известно, является обеспечение безопасности данных о держателях платёжных карт. И чуть ли не первым действием после решения о начале подготовки системы к соответствию, которое логично провести, - это анализ того, где эти данные в системе находятся и как передаются.

Другими словами, это можно назвать составлением матрицы данных о держателях карт с описанием тех систем, где хранятся данные о держателях платёжных карт. Подробнее о матрице данных вы можете прочитать в статье Сергея Шустикова «Подготовка к аудиту – схема сети и матрица данных о держателях карт».

Кстати, аналогичные действия рекомендуются экспертами при составлении так называемой карты персональных данных при подготовке к соответствию ФЗ-152. Данный подход более чем логичен, так как перед тем как разбираться, как защищать, следует понять, ГДЕ у нас находится то, что необходимо защищать, чтобы на следующем этапе, по возможности, уменьшить количество таких мест.

В результате составление матрицы данных значительно облегчит работу как специалистам компании, так и консультантам или аудиторам, что в итоге значительно ускорит процесс первоначального анализа системы и сэкономит драгоценное время на решение задач, связанных с подготовкой к сертификации и разработкой необходимых для достижения соответствия решений.

Как оказалось, далеко не каждая компания может с уверенностью сказать, где конкретно в их системах хранятся данные о держателях карт (PAN), и даже если у компаний имеется хоть какая-либо схема потоков данных, то на деле оказывается, что данные обнаруживаются в любых, даже самых неожиданных местах. Основные, но не единственные места, где можно обнаружить PAN - это trace, log, tlog, debug файлы СУБД, приложений и web-служб, а также файловые и почтовые сервера, рабочие станции операторов, POS –сервера и пр.

Составление матрицы данных - это первый этап выяснения мест нахождения PAN, но не последний, так как кроме известных мест всегда встречаются и неизвестные, поиск которых и позволяет увидеть реальную картину. Для облегчения работ по обнаружению данных о держателях карт Советом PCI SSC были даны регулярные выражения для поиска PAN:

Visa: ^4[0-9]{12}(?:[0-9]{3})?$

MasterCard: ^5[1-5][0-9]{14}$

Эти регулярные выражения можно ввести в любую систему поиска, к примеру, встроенную в Total Commander, и получить на выходе список файлов с PAN. После чего следует провести дополнительно проверку того, что найденная последовательность действительно является PAN по формуле mod 10.

На самом деле это только простейшие регулярные выражения, позволяющие найти PAN, в котором нет разделителей между цифрами. В случае если в качестве разделителей используются пробел или тире, то необходимо применять более сложные регулярные выражения. К примеру, приведенное ниже выражение проверяет наличие номеров кредитных карт от Visa, MasterCard и Amex как в виде строки из цифр, так и с разделителями (http://regexlib.com/REDetails.aspx?regexp_id=340)

^((4\d{3})|(5[1-5]\d{2}))(-?|\040?)(\d{4}(-?|\040?)){3}|^(3[4,7]\d{2})(-?|\040?)\d{6}(-?|\040?)\d{5}

Для тех кто предпочитает проводить данные проверки в автоматическом режиме в удобной оболочке со встроенной проверкой было разработано множество как коммерческих, так и бесплатных утилит для поиска PAN в системе.

Бесплатные утилиты:

• Spider

• ccsrch

• SENF

• FTimes

• Nessus

• Snort

• Open Source Forensic Tools

Коммерческие утилиты:

• Symantec Vontu

• RSA DLP Suite (Tablus)

• Vericept

• Orchestria

• Code Green Networks

• Reconnex

• Workshare

• Websense

• EnCase Forensic

Данная тема достаточно обширна, и описать все существующие решения не представляется возможным, поэтому рассмотрим одну из бесплатных утилит под названием Spider, которая выпущена сотрудниками университета Cornell и позволяет искать в системах такие данные, как номера кредитных карт (PAN), номера социального страхования и прочие данные.

Утилита имеет множество различных настроек, позволяющих фильтровать поиск по последней дате изменения файлов, что актуально для проведения регулярных проверок, а также позволяет добавлять директории исключения и даже сканировать EFS разделы, если к таким имеется доступ.

Совет: при использовании данной утилиты рекомендуется изменить приоритет в диспетчере задач на “ниже среднего”, так как процедура поиска достаточно ресурсоемка.

На рисунке 1 изображен пример запуска утилиты Spider на директорию D:\WORK\, где мы можем наблюдать файл tlog.txt, в котором обнаружены PAN.

Рис. 1. Утилита Spider

После использования не забудьте удалить лог файлы, созданные утилитой. Директория, в которой хранятся лог-файлы, указана во вкладке Settings->Runtime->Administrative options.

Данная утилита рассмотрена как один из возможных способов поиска PAN и приведена лишь в качестве примера. В статье были рассмотрены основные способы поиска PAN, которые можно использовать на серверах и рабочих станциях. В следующих статьях будут рассмотрены особенности поиска PAN в СУБД, а также обнаружение передачи PAN по сети.