|
Календарь мероприятий
апрель  2024
Пн |
Вт |
Ср |
Чт |
Пт |
Сб |
Вс |
1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | | | | | |
показать все 
Новости партнеров
Ассоциация разработчиков «Отечественный софт» отметила 15-летие
Читать далее
РДТЕХ представил Технологическую карту российского ПО 2023
Читать далее
RAMAX Group получила партнерский статус уровня Gold по продукту Tarantool
Читать далее
На RIGF 2024 обсудили ключевые вопросы цифрового развития России
Читать далее
показать все
Статьи
5 способов повысить безопасность электронной подписи
Читать далее
Как искусственный интеллект изменит экономику
Читать далее
Неочевидный САПР: выход ПО за рамки конструкторской деятельности
Читать далее
Скоро некому будет делать сайты и заниматься версткой
Читать далее
Цифровая трансформация в энергетике: как запустить проект с максимальным финансовым эффектом?
Читать далее
Мотивируй, не то проиграешь!
Читать далее
В 2024 году в России и мире вырастут объемы применения AR/VR
Читать далее
Цифровые технологии: надежды и риски
Читать далее
Будут ли востребованы услуги технической поддержки софта Oracle в России в ближайшие годы?
Читать далее
Здания с признаками интеллекта. Как Сергей Провалихин автоматизирует дома и производства
Читать далее
показать все
|
PCI – стандарт надежности ИБ при работе с кредитными картами
Главная /
Архив номеров / 2011 / Выпуск №8 (11) / PCI – стандарт надежности ИБ при работе с кредитными картами
Рубрика:
Безопасность
Facebook
Мой мир
Вконтакте
Одноклассники
Google+
 Константин Кондаков, работает старшим директором по ИТ в сан-францисской фирме Certain Software, обеспечивает бесперебойную работу центров данных и руководит системными администраторами в США, Великобритании и Австралии
PCI – стандарт надежности ИБ
при работе с кредитными картами
На страницах «Системного администратора» мы уже вкратце [1] рассказывали о том, что такое PCI (Payment Card Infrastructure) – полное название PCI Security Standards Council (Совет по стандартам безопасности обслуживания кредитых карт) – и зачем нужен этот стандарт
Напомним суть дела. В 1994-1995 годах, когда Интернет вышел за пределы университетов, специализированных государственных учреждений, военных ведомств и мегакорпораций, стала набирать обороты веб-коммерция. Кредитные карты в широком объеме появились ненамного раньше массового доступа к «Всемирной паутине», но именно быстрый Интернет дал новый толчок электронной коммерции, как мы ее понимаем сейчас, – многочисленным круглосуточным платежам по кредитным картам за товары и услуги.
В конце 1990-х годов, когда появились знаменитый он-лайн аукцион eBay и платежные порталы поменьше, стали очевидны преимущества покупки и продажи через Интернет, минуя посредников, любым покупателям, находящимся где угодно.
Чуть позже появился и PayPal, а затем и банки один за другим стали открывать он-лайн терминалы и платежные системы – и пошло-поехало.
Если раньше расписки по кредитным картам аккуратно хранились возле специального модемного терминала, связывающегося по телефонной сети напрямую с центром авторизации Visa/MasterCard/American Express, то теперь сотни, тысячи, десятки тысяч номеров кредитных карт, а также часто сопровождающие их пин-коды и полные регистрационные и адресные данные хозяев заполонили серверы, а распечатки этой информации горами лежали у принтеров, на столах, в мусорных корзинах, да где угодно!
Понятно, что эти данные довольно быстро были взяты в оборот мошенниками всех уровней. Выяснилось, что горе-владельцы номеров кредитных карт не имели ни малейшего понятия, откуда и как могли появиться их покупки, сделанные без их ведома на другом конце земного шара.
Счет на украденные и «потерянные» номера и пин-коды, практически свободно гуляющие по Интернету, уже шел на десятки миллионов, а СМИ рассказывали ежедневно о новых скандалах, связанных с массовой утечкой номеров из весьма респектабельных фирм.
Банкам, которые выпускали кредитные карты, приходилось совсем несладко – мало того, что все телефоны кипели от ярости владельцев кредитных карт, по которым какие-то несуществующие Джоны Смиты покупили телевизоры и ювелирные украшения, так еще надо было что-то делать с возвратом денег! Убытки начали приобретать поистине астрономические размеры.
Основы он-лайн системы безопасности PCI
Понятно, что проблемы с растущими убытками банков из-за «утечек» номеров кредитных карт надо было как-то решать. Тогда Visa/MasterCard/AmericanExpress сказали «баста!», и фирмы American Express, Discover Financial Services, JCB, MasterCard Worldwide и Visa International в сентябре 2006-го [2] основали международный консорциум для регулирования правил работы с кредитными картами и их безопасности.
В октябре 2010 года вышла вторая версия [3] свода правил и рекомендаций, которые даются всем юридическим и физическим лицам, занимающимся обслуживанием кредитных карт. Все структуры, которые имеют какое-то отношение к этой технологии, расчленяются на два раздела.
- Первый раздел – «продавцы» – то есть те, кто непосредственно авторизует и осуществляет он-лайн продажи по кредитным картам.
- Второй раздел – «посредники» – те, кто собирает, хранит и обрабатывает номера кредитных карт, но сами транзакции осуществляются третьими лицами.
И хотя и «продавцы», и «посредники» обрабатывают в своих информационных системах номера кредитных карт, аудит серверов и сетевого оборудования для них строится несколько по-другому.
В зависимости от типа хранения и ежегодного объема транзакций по картам «клиентов» PCI делят на разные группы – тех, кто обслуживает минимальные (до 10 000 в год) транзакции, обязуют делать внутренний аудит безопасности и давать отчет специально уполномоченной компании, которая занимается сканированием портов и внешних интернет-адресов на предмет уязвимости. Это надо делать ежеквартально. К фирмам, которые осуществляют он-лайн транзакции в более широком объеме, требования еще строже.
Наконец, крупнейшие (свыше 300 000 транзаций в год) или когда-то успешно атакованные хакерами компании требуют ежегодной специальной инспекторской проверки длительностью около недели. В течение всего этого срока въедливые представители PCI аудиторских фирм, наделенные самыми широкими полномочиями (за проверку, кстати, надо платить немаленькие деньги), тщательно проверяют ВСЮ информационную структуру по двенадцати пунктам (см. ниже).
В случае, например, обнаружения незащищенных номеров кредитных карт (поля в базе данных, таблица в Excel, кусок отладочного кода с непонятно как туда попавшим реальным номером карты, случайная распечатка и т.п.) они могут немедленно выставить «неуд» проверяемой фирме и сообщить напрямую в PCI, а те уже на свое усмотрение станут применять следующие санкции:
- поднять процент, отчисляемый банку, на каждую транзацию – например, с 0,5 до 5%;
- еженедельно штрафовать нерадивую фирму на сумму от 500 до 50 000 долларов, пока не будет устранена PCI-уязвимость;
- отозвать лицензию на обслуживание кредитных карт на неопределенный срок (неплохо, да?);
- принять другие жесткие меры – сообщение в полицию, ФБР и т.п.
Всю эту информацию (как положительную, так и отрицательную) PCI-консорциум распространяет достаточно широко, делая достоянием прежде всего банка, который обслуживает фирму. В качестве стимулирующей меры PCI часто настаивает, чтобы компании-заказчики или просто клиенты требовали при заключении любых договоров текущей сертификации по стандарту PCI, которая дается, как правило, сроком на один год.
Понятно, никто не может закрыть фирму, если она не сертифицирована через PCI, но Visa/MasterCard/Discover/JCB/American Express вполне могут запретить ей использовать он-лайн обработку кредитных карт, а банк, в котором организация имеет текущий счет, предпочтет не ссориться с конгломератом, эмитирующим кредитные карты. Конечно, если все расчеты ведутся по «черному налу» или фирма в нарушение всех правил безопасности самовольно ведет несертифицированное PCI он-лайн обслуживание кредитных карт, это отдельный разговор. Заказчики и партнеры такой компании ведут с ней дела на свой страх и риск – мы вас предупреждали!
Параллельно стоит отметить, что указанные ниже правила можно и нужно использовать в своей работе не только ИТ-организациям, работающим с кредитными картами, но и всем другим фирмам, которым не безразлична своя информационная безопасность.
Свод правил – это плод коллективной работы многих информационных аудиторов, которые на своем веку видели много различных нарушений, поэтому просто грех пропустить их рекомендации мимо ушей.
Двенадцать правил, которым неуклонно следуем
До начала аудита в компанию приходит официальное письмо, в котором напоминается, что текущий сертификат информационной безопасности PCI истекает в течение 60 дней. Такой срок дается для того, чтобы у компании было время на исправление мелких ошибок, которые обязательно всплывут во время проверки, а у аудиторов достаточно времени, чтобы документально все оформить, получить исправления ошибок и уточнения, а также для того, чтобы служба внутренней безопасности аудиторской фирмы проверила готовый PCI материал перед тем, как официально разослать свое заключение в Visa/MasterCard/Discover/JCB/American Express.
Непременным общим правилом комплексной проверки является анализ бизнес-составляющей фирмы, ее организационной структуры, целесообразности и смысла проведения операций с кредитными картами. Если на общие положения аудита не может быть дан исчерпывающий ответ, и выясняется, что организация, которую проверяют, достаточно смутно представляет себе весь процесс и не может предоставить требуемых документов, то аудиторы просто разворачиваются и уходят.
Когда фирма будет полностью готова к проверке, то ревизоров снова позовут – разумеется, за повторный визит также надо будет платить. Поэтому, как правило, во время аудита все иные бизнес-проекты уходят на второй план, а инспекторам-аудиторам представляется полная свобода действий – они могут затребовать любой интересующий их документ, если он как-то связан с процессом PCI или переговорить с любым сотрудником фирмы.
Нелишне напомнить, что любой обнаруженный обман, подлог или подтасовка фактов немедленно ведет к аннулированию проверки и срочной телеграмме в PCI.
Фирма-аудитор напрямую подчиняется консорциуму и ни в какие игры играть не намерена, подкуп тем более исключен.
Первое правило. Защита внешнего периметра
Вы будете удивлены, но и сегодня находятся такие фирмы, которые пытаются хранить и (или) обрабатывать номера кредитных карт, не имея ни малейшего представления о том, что такое «межсетевые экраны» (firewall) и как надо защищать внешний периметр информационной системы.
Задача первого правила и всех его положений – проверить и протестировать адекватную системную документацию, свод правил «межсетевых экранов», текущую сетевую топологию системы. Надо отметить, что если в организации существует несколько независимых сетей и центров данных, то периметр и «межсетевые экраны» будут проверяться только там, где расположены серверы, предназначенные для работы с кредитными картами.
Аудитор должен досконально разобраться во всех правилах (см. рис. 1), установленных на межсетевом экране, запущенных сетевых сервисах и уязвимости этих сервисов. Обычно этот раздел проверяется бывшими системными администраторами, инженерами по сетевой безопасности, сертифицированными специалистами Cisco, Microsoft, Juniper Networks.
Рисунок 1. Cтруктура правил для Firewall
Большую помощь может оказать адекватная системная документация. Если разобраться в хитросплетениях конфигурации нет никакой возможности, или аудитор понимает, что его просто водят за нос, то аудит прекращается по причине того, что PCI сертификация не может быть выдана по пункту «защиты периметра». Кстати, и любое иное правило, не выдерживающее сертификацию, также делает недействительным весь аудит. Все двенадцать правил должны быть тщательно проверены и подтверждены на соответствие.
Второе правило. Меняем пароли «по умолчанию»
Проверяется уязвимость системы на «пароли по умолчанию» – типа admin/admin – password/password. Все пароли, необходимые для работы с информационными подсистемами, которые имеют прямой или косвенный выход на кредитные карты, должны обладать определенным «запасом прочности» – как минимум восемь символов, цифро-буквенные комбинации, верхний и нижний регистр, а также обязательное использование нецифро-буквенного символа (например, «плюс» +) для повышения сложности. Верхний предел сложности неограничен – хотите, чтобы был пароль из 20 символов, пожалуйста!
Здесь же проверяется (см. рис. 2), что доступ к виртуальным машинам (см. врезку «Виртуальные машины и PCI») также произведен по шифрованным соединениям (SSL/SSH). А иногда там обнаруживаются любопытные бреши в системе.
Рисунок 2. Опции безопасности в Vmware Sphere
Третье правило. Храним и надежно защищаем информацию о кредитных картах
Кредитные карты, а также полная информация о владельцах, не должны присутствовать в системе в открытом виде (см. рис. 3). Причем речь идет не только о поле в таблице, которое ни при каких условиях не должно быть типа «4123 4568 7890 1282» (Visa), но и любые другие области (отладчик, текстовые файлы, файл свопа) не должны содержать подобную информацию. Это очень жесткое требование, что выполнить непросто. Одни фирмы используют шифрование номеров программными средствами с открытым ключом или пользуются проверенными приложениями PGP/GPG и протоколами SSL, другие вычленяют физически выделенный участок компьютерной сети (например, на отдельном DSL-канале), который НИГДЕ не пересекается с основной сетью фирмы, и сразу же переадресуют все операции по кредитным картам на проверенные и многократно сертифицированные сайты типа paypal.com, pay.gov. Причем речь идет не просто о пересылке информации по VPN, а и о том, что и на физических носителях, и в файловой области данные не могут находиться в открытом виде.
Рисунок 3. Представление номеров кредитных карт в шифрованном виде
Четвертое правило. Шифруем каналы передачи
Понятно (увы, не всем), что все транзакции по передаче номеров кредитных карт надо проводить строго и только по SSL/SSH/VPN-каналам.
PCI-аудит неукоснительно настаивает на этом требовании, и весь путь транзакции кредитной карты должен быть внятно показан аудиторам и защищен коммерческим (типа Verisign) сертификатом, срок годности которого не истек.
Встречаются, к сожалению, фирмы, которые не понимают важность этого пункта. Поскольку нешифрованный сетевой трафик легко перехватывается и инспектируется утилитами типа tcpdump, wireshark и им подобными, а веб-трафик, как правило, проходит через несколько узловых маршрутизаторов и компьютерных подсетей, злоумышленнику легко начать перехватывать сетевой поток, чтобы выловить оттуда интересующую его информацию.
Пятое правило. Правильно и своевременно обновляем антивирусные пакеты и другие системы защиты
Важно не только установить антивирусы и средства для проверки контрольной суммы ключевых файлов (системы типа tripwire [4], ossec [5], которые могут быть использованы и для других целей), но и следить за регулярным обновлением этих программ.
Более тогоантивирусная, антируткитовая и антитроянская защита должна быть установлена в принудительном порядке средствами GPO (Windows) административного приложения антивирусной программы или аналогичными в других ОС, чтобы приложению или пользователю было чрезвычайно трудно остановить антивирусную защиту, заблокировать или как-то иначе понизить ее эффективность-функциональность (см. рис. 4).
Рисунок 4. Проверка системной политики Symantec Antivirus
Все подобные попытки и системные сбои, которые приводят к выводу из строя систем антивирусной и иной защиты, должны сразу же сообщаться системным администраторам – эта процедура проверяется с особой тщательностью. Аудитор должен быть уверен, что антивирусная защита находится на высоте.
Шестое правило. Защищаем приложения, которые работают с кредитными картами
Само приложение, которое принимает и каким-то образом обрабатывает кредитные карты, должно быть не просто защищено от внешних уязвимостей (что будет обязательно протестировано), но и проверено на то, какие методы используются для внесения изменений в исходный код.
В процессе проверки аудиторам важно понять, что ключевое программное обеспечение фирмы, используемое при работе с кредитными картами, не просто написано на коленке, но имеет систему контроля версий, а изменения, вносимые разработчиками, проходят полноценный контроль – кто и зачем вносит изменения, как они тестируются, на что они будут влиять, и как «откатиться» на предыдущую версию в случае чего.
Проверка этих механизмов контроля делается для того, чтобы избежать «экстремального программирования», когда любой программист может внести опасную ошибку в программу, и она вдруг станет массово рассылать открытым текстом номера кредитных карт, хранившиеся до этого за семью печатями.
Седьмое правило. Ограничиваем доступ к служебной информации, связанной с кредитными картами
Обязательно проверяем, какие пользователи (как люди, так и внутренние системные сервисы) установлены и имеют прямой и косвенный доступ к системам, на которых хранятся номера кредитных карт.
В процессе подобной проверки может быть обнаружено, что, например, система мониторинга Nagios имеет неограниченный доступ ко всем системным ресурсам и... работает без пароля!
Часто разграничение доступа пересекается и с аналогичными требованиями Sarbanes-Oxley [6], который регулирует практически те же положения для предотвращения умышленной или случайной подтасовки и порчи данных.
Восьмое правило. Контролируем точки входа и выхода в систему
Аудит проверяет, как контролируются на уровне прав доступа авторизация и учет входа в систему. Существует ли минимальная политика учета системных журналов, а также удаленных пользователей. Здесь же проверяется и наличие явных и «скрытых» туннелей между сетями, по которым можно «случайно» оказаться на привилегированном сервере, минуя все элементы защиты.
Системные администраторы, особенно в крупных сетях, любят строить так называемые bastion hosts (бастионы входа), jump servers (джамп-серверы), с которых можно получить служебный, часто с правами суперпользователя, доступ ко всем ресурсам системы.
Очень часто подобные серверы являются настоящим бедствием как для аудиторов, так и для пострадавших компаний, в логах которых написано, что некто «root» вошел, сделал, посмотрел, стер, и т.д. – а кто такой этот «root»? Ненамного лучше ситуация там, где используется sudo. Но бывает и так: обнаружилось, что вошел какой-то «vasya: sudo cat ...», а сам «vasya» был в это время в отпуске в пустыне Гоби.
Поэтому для точек входа в системы PCI часто выделяют однократно генерируемые пароли или используют специальные брелоки, которые генерируют подобные RSA-ключи [11].
Девятое правило. Ограничиваем физический доступ к серверам
Физический доступ к серверам – это святая святых. Можно поставить сколь угодно хитрые системы защиты, но если злоумышленник имеет возможность получить консольный вход или, что хуже, вытащить дисковый носитель из сервера или получить ленты, используемые для резервного копирования, то безопасность всей системы сразу же падает.
В процессе подобного аудита может выясниться, что серверы, обслуживающие кредитные карты, установлены на кухне или в коридоре, что никто особо не смотрит, если кто-то крутится около системной консоли.
Резервное копирование? Делаем, и даже ленты отвозим за пределы фирмы... на открытый склад, где любой мало-мальски подкованный в ИТ специалист может получить беспрепятственный доступ к ним, чтобы посмотреть, что же мы копируем туда каждый день.
Приходится организовывать краткую поездку (если не очень далеко) или просить провайдера выслать фотографии, которые красноречиво говорят, что все серверы защищены, как в Гохране.
Десятое правило. Отслеживаем все транзакции по безопасности в системе
Системные сообщения или логи – это нервная система ИТ. Через нее до администраторов доводится, что, например, уменьшается дисковое пространство на сервере или что какой-то злоумышленник третий день пытается подобрать пароль.
Поэтому правильно настроенная политика учета системных сообщений проверяется в обязательном порядке (см. рис. 5), равно как и наличие таких логов, и политика их просмотра. Журналы должны ежедневно просматриваться в обязательном порядке. Если системных сообщений очень много, есть способы их агрегации и систематизации (см. системы php-syslog-ng [7], SEC [8], Splunk [9]).
Рисунок 5. Программа php-syslog-ng
Одиннадцатое правило. Регулярно тестируем информационную политику фирмы
Все ранее указанные заповеди и действия хороши, если они используются в комплексе с другими мерами безопасности. Наличие единой информационной концепции, которая является основой cистемы компьютерной безопасности фирмы, обязательно проверяется. И проверяется тут не только отдел информационных систем, но часто и отдел кадров (см. рис. 6), а также служба безопасности фирмы (если она формально есть).
Рисунок 6. Результаты проверки потенциального работника отделом кадров
Например, может «внезапно» выясниться, что новые сотрудники, принятые в отдел системных администраторов, в прошлом... неоднократно привлекались за мошенничество, связанное с кредитными картами. Это, увы, реальный пример из жизни PCI-аудиторов.
Двенадцатое правило. Следим за всеми нарушениями порядка
На фирме должен быть четко выверен и проверяться не реже, чем раз в год, порядок оповещения ключевых ИТ-сотрудников в случае хакерской атаки, связанной с возможной утечкой номеров кредитных карт. Каждый системный администратор должен в случае ЧП обязательно под рукой иметь документ, который предписывает все действия в случае проникновения злоумышленника в информационное пространство фирмы.
Также все системные администраторы должны знать, что делать, если получен звонок от заказчика, который полагает, что его кредитная карта была как-то сворована из проверяемой фирмы. PCI предписывает определенный набор действий [10] – что делать, что не делать, куда звонить.
Виртуальные машины и PCI
В июне 2011 года консорциум PCI выпустил специальное приложение https://www.pcisecuritystandards.org/documents/Virtualization_InfoSupp_v2.pdf, в котором регламентируются правила проверки виртуальных машин и условия прохождения PCI-аудита.
Если внимательно прочитать это приложение, выясняется, что облачные системы типа Amazon EC2, Gogrid, Google Apps в настоящее время не могут быть сертифицированы на PCI. Точнее, сами-то системы вполне даже сертифицированы, а вот приложения пользователей, которые там размещены, – увы. Провайдеры облаков, даже обеспечивая шифрованные каналы связи к приложениям своих заказчиков, не могут дать законодательно закрепленный вразумительный ответ, где конкретно находятся данные фирмы, как должным образом обеспечивается защита верхнего «физического» уровня, на котором работают виртуальные машины, а также как на самом деле построена топология системы.
Поэтому пока многие фирмы, работающие с кредитными картами в больших объемах, не торопятся переводить свои приложения в облака – практически это относится ко всем фирмам, сертифицированным на первом уровне PCI. Свои серверы все же надежнее. Всегда знаешь, где и что лежит, кто и за что отвечает, а также можно организовать приезд дотошного аудитора в центр данных – пусть посмотрят и убедятся, что «граница на замке».
Что в итоге?
Не будем забывать, что PCI – это международный стандарт, следовательно, кредитные конгломераты Visa, Mastercard, American Express распространяют его и на территорию Российской Федерации.
Понятно, что Россия всегда считалась зоной повышенного риска для зарубежных эмитентов кредитных карт, поэтому, мягко говоря, работа с кредитными картами, выпущенными банками США и Западной Европы, сопряжена в России с «особыми условиями».
Например, банк Chase практически сразу блокирует все транзакции на свои карты, произведенные на территории РФ. В моем случае требовалось специальное предупреждение, которое я заблаговременно делал банку, когда собирался в Москву. Иначе попытка расплатиться MasterCard в «Седьмом континенте» могла бы стать последней транзакцией по этой карте.
Российские компании, выходящие на международный рынок, могут обратить это настороженное отношение в свое колоссальное преимущество – сертификация PCI, например, первого (самого высокого) уровня, выданная авторизованным аудитором PCI, сразу же поставит фирму в очень выгодное положение по сравнению со своими конкуретнами, у которых нет такой сертификации.
Так что дело за малым – дерзать!
- Кондаков К. Принципы неуязвимости. Чем руководствуются компании США. //Спецвыпуск-приложение к журналу «Системный администратор», №2, 2011 г. – С.28-31.
- Payment Card Industry – http://en.wikipedia.org/wiki/Payment_card_industry.
- Документы PCI – https://www.pcisecuritystandards.org/security_standards/documents.php.
- Сайт tripwire – http://www.tripwire.com.
- Сайт OSSEC – http://www.ossec.net.
- Акт – Sarbanes-Oxley – http://en.wikipedia.org/wiki/Sarbanes%E2%80%93Oxley_Act.
- php-syslog-ng (LogZilla) – http://www.gdd.net/index.php/PHP-Syslog-NG.
- SEC – http://simple-evcorr.sourceforge.net.
- Splunk – http://www.splunk.com.
- Что делать, если обнаружена брешь в системе информационной защиты – свод правил – http://usa.visa.com/download/merchants/cisp_what_to_do_if_compromised.pdf.
- Костышин М. В чем слабость твоя? //«Системный администратор», №4, 2004 г. – С. 82-86 (http://samag.ru/archive/article/272).
В начало⇑
Facebook
Мой мир
Вконтакте
Одноклассники
Google+
Комментарии отсутствуют
Комментарии могут отставлять только зарегистрированные пользователи
|
Вакансии на сайте Jooble
|
_cover.jpg)
