PCI DSS совместимость (Часть 2)

Published on Февраль 3, 2009 by   ·   Комментариев нет

Если вы пропустили предыдущую статью из этого цикла, то, пожалуйста, прочитайте PCI DSS совместимость (Часть 1).

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

Кому надо это делать?

Продавцы первого уровня (Большие парни) Требования
Любой продавец, вне зависимости от канала для приема, обрабатывающий свыше 6,000,000 транзакций в год Любой продавец, который пострадал от взлома или атаки, результатом которой стала утеря данных учетной записи. Ежегодное анкетирование Ежеквартальное сканирование Независимая оценка безопасности или внутренний аудит Квалифицированное независимое сканирование Ратификация не позднее 30 сентября 2007*
Продавцы второго уровня (компании среднего размера) Требования
Любой продавец, обрабатывающий от 150,000 до 6,000,000 электронных транзакций (MasterCard) или от 1,000,000 до 6,000,000 совокупных транзакций (Visa) в год Ежегодное анкетирование Ежеквартальное сканирование Ратификация не позднее 31 декабря 2007*
Продавцы третьего уровня (Маленькие парни) Требования
Любой продавец, обрабатывающий от 20,000 до 150,000 электронных транзакций (MasterCard) или от 20,000 до 1,000,000 электронных транзакций (Visa) в год. Ежегодное анкетирование Ежеквартальное сканирование Ратификация не позднее 31 декабря 2007*
Продавцы четвертого уровня (все остальные) Требования
Все остальные продавцы, вне зависимости от канала для приема Ежегодное анкетирование Ежеквартальное сканирование Совместимость обязательна, проверка настоятельно рекомендуется Ратификация не позднее 30 июля 2007*

* Большинство продавцов второго и третьего уровня не уложатся в срок. Продавцы 4 уровня, с которыми я общался, уже не уложились в срок. Так что теперь? Банки подтвердили, что PCI DSS – это требование, и если будет существовать несовместимость, то последуют ответные меры

Поддержка программы управления уязвимостями

Требование 5: Использовать и регулярно обновлять антивирусное программное обеспечение

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

Требование 6: Разработка и поддержка безопасных систем и приложений

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

Правильная разработка приложений и последующий жизненный цикл разработки программного обеспечения (Software Development Lifecycle) – это не просто рекомендация, а теперь требование PCI DSS. В это также включено разделение среды разработки и работы. Без этого все может начать работать неправильно после внесения изменений в приложении. Перед тем как продукт начнет работать, необходимо удалить все тестовые элементы. Если забыть об этом этапе, то систему можно будет легко взломать.

Изменение управления

Если вы не можете оценить, то вы не можете управлять. Как вы можете узнать, где возникли проблемы, если вы не знаете подробностей изменений, которые имели место при обновлении программного обеспечения? Если вы должны отменить обновление, то нет способа для определения, какое из 101 обновления вызвало проблемы.

Реализация мер по сильному контролю доступа

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

Причина этого заключается в том, что только авторизованный персонал должен иметь доступ к важным данным, защищаемым PCI DSS. Лучшим способом для этого будет подход, называемый белым списком (white list) или другими словами запретить все. Как это сделать? Начните с аннулирования всех привилегий, а затем раздайте привилегии и доступ к ресурсам и данным лишь авторизованному персоналу, которому он нужен. Это контроль доступа можно документировать для создания ACL, которые поддерживаются и контролируются системным контролем среды. Легче сказать, чем сделать Подробная информация о белых списках тут .

Требование 8: Присваивать уникальный ID каждому человеку с компьютерным доступом

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

Удаленные доступ привлекает более безопасный механизм аутентификации, используя такие технологии, как RADIUS и TACACS+. Снова, играет роль шифрование, и все полномочия должны оставаться зашифрованными, особенно во время передачи. Строгий контроль над паролями поможет вам с PCI совместимостью. Лучшие рекомендации должны присутствовать в этом сегменте требований.

Требование 9: Ограничить физический доступ к данным о владельцах карт

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

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

Требование 10: Отслеживание и мониторинг доступа ко всем сетевым ресурсам и данным о владельцах карт

Аудит и журнализация – это ключевые компоненты PCI совместимости. Это помогает доказать, что пользователь получал доступ к данным о кредитной карте, и выявить попытки неавторизованного доступа. Мониторинг и аудит доступа к информации о карте – это требование, которые фиксирует: дату, время, доступ, результат операции. Более подробную информацию можно найти в стандарте. Обычно, я рекомендую, чтобы доступ к информации отфильтровывался с помощью брандмауэра прикладного уровня.

Требование 11: Регулярное тестирование систем и процессов безопасности

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

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

Поддержка политики информационной безопасности

Требование 12: Поддержка политики, которая отвечает за информационную безопасность

Последнее требование PCI DSS – это поддержка политики безопасности. Политика без зубов – бесполезна, а политика безопасности должны касаться всех требований, предъявляемых PCI DSS.

Следуя рекомендациям и придерживаясь базовых линий из ISO 17799, теперь известном как ISO 27001, вы сможете удовлетворить всем требованиям PCI DSS. Двенадцатое требование имеет множество глубинных требований и благодаря своей всесторонней природе, оно лучше всего ссылается на сам PCI DSS.

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

Источник www.windowsecurity.com


Смотрите также:

Readers Comments (Комментариев нет)




Да человек я, человек! =)




Exchange 2007

Проведение мониторинга Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 3)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Проведение мониторинга Exchange 2007 с помощью диспетчера System ... [+]

Практическое рассмотрение перехода с Exchange 2003 на Exchange 2007 (часть 1)

Введение В этой статье из нескольких частей я хочу показать вам процесс, который недавно использовал для перехода с существующей среды Exchange 2003 ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 2)

Если вы пропустили первую часть этой серии, пожалуйста, прочтите ее по ссылке Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (Часть ... [+]

Мониторинг Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 2)

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Мониторинг Exchange 2007 с помощью диспетчера System Center Operations ... [+]

Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 5)

Если вы пропустили предыдущие части этой серии статей, перейдите по ссылкам: Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 1) ... [+]

Установка и настройка Exchange 2007 из командной строки (Часть 3)

If you missed the previous parts in this article series please read: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 1)

Инструмент ExRCA Текущий выпуск инструмента предоставляется только в целях тестирования и оснащен 5 опциями: Тест подключения Outlook 2007 Autodiscover Тест подключения Outlook 2003 RPC ... [+]

Развертывание сервера Exchange 2007 Edge Transport (часть 5)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Развертывание сервера Exchange 2007 Edge Transport (часть 1) Развертывание ... [+]

Установка и настройка Exchange 2007 из командной строки (часть 2)

Если вы пропустили первую статью данного цикла, пожалуйста, перейдите по ссылке: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование интегрированных сценариев Using Exchange Server 2007 – часть 2: генерирование отчетов агента Transport AntiSpam Agent

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Использование интегрированных сценариев Using Exchange Server 2007 – часть ... [+]