http://www.pcisecurity.ru/blog/Информзащитаhttp://www.pcisecurity.ru/_i/blog/logo_ru.gif http://www.pcisecurity.ru/blog/post/97/ <P>Шпаргалка по соблюдению требований стандарта касаемо беспроводных сетей.</P> <P><A class=editor_img_small_a href="/_upload/editor_img/wifi_for_pci2.jpg" target=_blank><IMG class=editor_img_small height=260 alt="Шпаргалка по беспроводным сетям PCI DSS (JPEG, 47,8 КБ)" src="/_upload/editor_img/wifi_for_pci_small.jpg" width=400 border=0></A></P>Mon, 01 Feb 2010 12:37:56 +0300 http://www.pcisecurity.ru/blog/post/87/ <P>Не&nbsp;так давно в&nbsp;сети развернулась дискуссия относительно противоречивости мнений аудиторов различных компаний, толчком к&nbsp;которой явилось мнение о передаче номеров платежных карт в&nbsp;открытом виде во&nbsp;внутренней сети компании. Тема оказалось достаточно интересной и&nbsp;её&nbsp;подхватили авторитетные в&nbsp;области информационной безопасности <A href="http://sgordey.blogspot.com/2009/06/pci-pan.html">специалисты</A>, что ещё больше «<A href="http://lukatsky.blogspot.com/2009/07/blog-post_30.html">подлило масла в огонь</A>», а&nbsp;вместе с&nbsp;тем добавило замешательства специалистам относительно выполнений требований стандарта PCI DSS. Попробуем разобраться, опираясь на официальные документы консула, в&nbsp;ставшем «камнем преткновения» вопросе.</P> <a href="http://www.pcisecurity.ru/blog/post/87/"> Статья полностью → </a> Fri, 18 Sep 2009 16:05:57 +0400 http://www.pcisecurity.ru/blog/post/74/ <P>При использовании небезопасных (передающих логин и пароль пользователя в открытом виде, таких как: telnet, ftp), всегда имеются риски компрометации серверов и данных платежных карт, которые в них обрабатываются. Подобные риски компрометации имеются и при использовании ненужных для бизнеса протоколов и сервисов, которые также могут содержать уязвимости, т.к. их никто не исправляет (например, потому что сервис никто не использует и не администрирует). Данные виды рисков, в соответствии с требованиями стандарта, каждая организация должна осознавать и стараться минимизировать.</P>Выполнение требования 1.1.5 направлено на решение этой задачи и включает в себя: документирование всех необходимых для ведения бизнеса протоколов и сервисов, а также обоснование их&nbsp; применения. Небезопасные протоколы также можно использовать, но только в случае если разработаны и описаны защитные меры при их использовании. <a href="http://www.pcisecurity.ru/blog/post/74/"> Статья полностью → </a> Tue, 14 Jul 2009 11:38:28 +0400 http://www.pcisecurity.ru/blog/post/73/ <P>Часто приходится сталкиваться с неправильной интерпретацией требований 8.1, 8.5.8 и 8.5.16.b стандарта PCI DSS и адресуемых ими рисков: </P> <UL> <LI>«в стандарте написано, что нельзя использовать групповые идентификаторы для выполнения административных задач и других критичных функций, но наши пользователи не имеют полномочий на изменение данных, а значит можно под одной учетной записью работать»; <LI>«в стандарте написано идентификаторы пользователей, а к администраторам систем эти требования не относятся»; <LI>«в стандарте написано, что нельзя использовать встроенные идентификаторы, то есть нельзя пользоваться учетной записью oracle или root». Как следствие, непонимание сути требования приводит к неправильной его реализации. </LI></UL> <a href="http://www.pcisecurity.ru/blog/post/73/"> Статья полностью → </a> Fri, 10 Jul 2009 17:26:15 +0400 http://www.pcisecurity.ru/blog/post/72/ <P><IMG class=border style="MARGIN-BOTTOM: 3px; MARGIN-RIGHT: 15px" height=146 alt="" src="/_upload/editor_img/lock_icon.jpg" width=114 align=left border=0>Эта статья является продолжением <A href="/blog/post/53/">начатой темы</A> про&nbsp;соответствие стандарту (PCI compliance)&nbsp;и&nbsp;проверкой соответствия (PCI Validation).</P> <P>Итак, начнем с области применения стандарта PCI DSS. Несмотря на то, что исходно стандарт PCI&nbsp;DSS &nbsp;разрабатывался в основном для крупных торгово-сервисных организаций (миллионы транзакций в год) и сервис-провайдеров и нацелен на снижение рисков утечки данных «чужих» платежных карт в рамках, в основном, процессов авторизации, его требования должны выполнять любые компании, в которых происходит обработка, хранение или передача как минимум PAN.</P> <P>Данную позицию PCI SSC (организация, ответственная за разработку стандарта PCI DSS) изложила в ответе на один из вопросов аудиторов Информзащиты в своем&nbsp;<A href="http://selfservice.talisma.com/display/2n/kb/article.aspx?aid=5391&amp;n=1&amp;s=" target=_blank>FAQ</A>.</P> <P>Сложности при выполнении требований стандарта испытывают банки, которые занимаются выпуском платежных карт, их системы, обеспечивающие выпуск карт, особенно если они интегрированы с АБС, в большинстве случаев разрабатывались без оглядки на требования PCI DSS такие, как шифрование PAN, протоколирование доступа к PAN и т.п. Доработка существующих систем (или замена, что может быть <A href="http://blog.chirkov.net/2008/11/29/vremya-peremen/" target=_blank>даже дешевле</A>) под выполнение требований по безопасности&nbsp;—&nbsp;задача затратная и по времени, и по ресурсам и для бизнеса не совсем очевидная особенно сейчас, в условиях мирового финансового кризиса.&nbsp;</P> <a href="http://www.pcisecurity.ru/blog/post/72/"> Статья полностью → </a> Fri, 03 Jul 2009 09:35:01 +0400