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

Поэтому однократное нарушение сроков ASV-сканирования, представляет серьезный риск с точки зрения соответствия стандарту PCI DSS. В случае возникновения такого нарушения, единственным способом подтвердить соответствие организации требованиям стандарта PCI DSS будет:

Дождаться, пока пройдет один год с момента последнего нарушения срока. А на время ожидания, статус соответствия PCI DSS будет утерян организацией.

Вопрос о корректности такого вывода был недавно задан представителям Совета PCI SSC. Представители Совета подтвердили, что вывод сделан верно и уточнили, что другого способа исправить нарушение сроков ASV-сканирования не существует.

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

И пусть Ваше соответствие будет непрерывным отражением Вашей безопасности!

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

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

Форма имеет значение!

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

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

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

16 июня, компания Azox — один из лидеров в области электронной коммерции для продуктов Microsoft Dynamics GP, проводит веб-семинар, целью которого будет обсуждение следующих вопросов:

• обзор требований стандарта PCI DSS;
• почему так важно соответствовать стандартам безопасности;
• какие риски существуют при «non-compliance»;
• и многие другие.

Также будут представлены программные решения компании Azox — Azox Credit Card Extension (CCE), сертифицированные по стандарту PA-DSS, и специалисты компании расскажут, как эти решения помогут Вашей компании добиться соответствия стандарту в необходимый срок до 1-го июля 2010 г.

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

Зарегистрироваться для участия можно здесь.

Англоязычный оригинал: http://azoxecommerce.blogspot.com/2010/06/prepare-yourself-for-july-1st-pci.html

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

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

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

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

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

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

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

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

Foreshore – предлагает размещение физических серверов на своей площадке;

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

TelecityGroup - предлагает размещение физических серверов на своей площадке.

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

PSI DSS часто критикуют, основываясь на мнении, что главной целью стандарта является прохождение аудита. Для многих будет сюрпризом узнать, что стандарт требует выполнение определенных задач постоянно, а не только перед аудитом. Цель статьи — сосредоточить внимание на конкретных процедурах, которые необходимо осуществлять, для того что бы сохранить соответствие, а не только выполнять ASV-сканирование, проходить ежегодный QSA-аудит, или же заполнять лист самооценки (SAQ).

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

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

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

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

Таблица 1. Периодические действия

Что мы можем извлечь полезного из вышеприведенной информации? Мы можем составить список задач, которые необходимо выполнять периодически:

Каждый год:
   • QSA-аудит или заполнение листа самооценки;
   • тест на проникновение;
   • проверка безопасности веб-приложений;
   • пересмотр политики безопасности;
   • обучение персонала;
   • другое.

Каждые 6 месяцев:
   • пересмотр конфигураций межсетевых экранов и маршрутизаторов.

Каждый квартал:
   • выполнение внешнего и внутреннего сканирования сети на наличие уязвимостей.

Каждую неделю:
   • выполнение процедур проверки целостности критичных файлов.

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

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

Об авторе:
Антон Чувакин является известным независимым консультантом по информационной безопасности, автор книг «PCI Compliance», «Security Warrior», соавтор «Know Your Enemy II», «Information Security Management Handbook», «Hackers Challenge 3», «OSSEC HIDS», а также многих публикаций по безопасности. Автор многих докладов по вопросам информационной безопасности на конференциях в США, Великобритании, Сингапуре, Испании, Канаде, Польше, Чехии, России и других стран. Защитил диссертацию на соискание ученой степени Ph. D. в Университете Стони Брук, Нью-Йорк, США.

Источник:
http://www.ethicalhacker.net/content/view/283/2/

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

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

Что необходимо протоколировать, чтобы соответствовать требованиям PCI?

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

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

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

Эффективное управление журналами протоколирования

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

Приоритетом должен являться тот минимум протоколируемых событий, который необходим для соответствия PCI, однако многие компании внедряют комплексное решение по управлению информацией о событиях безопасности (security information management, SIM), чтобы извлекать с его помощью другие важные с точки зрения обеспечения безопасности данные. Другие компании отдают управление протоколированием на аутсорсинг, что является неплохим решением для компаний с ограниченным штатом в части поддержки информационной инфраструктуры и её безопасности.

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

Приведение протоколирования в соответствие PCI DSS

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

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

Поддержка соответствия протоколирования требованиям PCI DSS

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

Стоимость дискового пространства может стать важным фактором, при принятии решения о применении аутсорсинга, либо модели «программное обеспечение как услуга» (SaaS) для процесса управления журналами протоколирования, так как сервис-провайдеры и дата-центры имеют возможность увеличивать объем памяти «на лету». Помимо всего прочего, тремя основными элементами процесса управления протоколированием являются: регулярный просмотр журналов, архивация журналов для хранения в течение необходимого периода времени, и предоставление их QSA-аудитору по необходимости. Все три элемента можно относительно безболезненно отдать на аутсорсинг.

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

Об авторе:
Джон Киндервэг, CISSP, CEH, CPISM, CCNA, в прошлом QSA, главный аналитик исследовательской компании Forrester Research. Имеет 25-летний опыт, область интересов охватывает безопасность сетей, в том числе беспроводных, управление информацией о событиях безопасности и защиту данных в соответствии с PCI DSS.

Источник:
http://searchsecurity.techtarget.com/tip/0,289483,sid14_gci1362394_mem1,00.html

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

Знать, какие именно данные нужно защищать, может быть достаточно сложно.

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

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

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

Особое внимание следует обратить на требования по защите данных о держателях карт (включающие Требование 3: обеспечить безопасное хранение данных о держателях карт и Требование 4: обеспечить шифрование данных о держателях карт при их передаче через сети общего пользования) и внедрению строгих мер контроля доступа (Требование 7: ограничить доступ к данным о держателях карт в соответствии со служебной необходимостью, Требование 8: назначить уникальный идентификатор каждому лицу, имеющему доступ к информационной инфраструктуре, и Требование 9: ограничить физический доступ к данным о держателях карт). Требование 8 непосредственно направляет нас к Требованию 10 : Контролировать и отслеживать любой доступ к сетевым ресурсам и данным о держателях карт. И наконец, есть Требование 6: Разрабатывать и поддерживать безопасные системы и приложения. Таким образом, в общем и целом, больше половины требований непосредственно относятся к вопросам целостности данных.

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

Следующим действием (или даже параллельно с предыдущим), настройте журнал протоколирования и аудита приложений и сетей, чтобы иметь возможность определить, кто получает доступ к данным, когда они изменяются, и важнее всего - куда эти данные отправляются. Для этого требуется мониторниг сети. Ведение журналов протоколирования необходимо, это дает такое преимущество, как быстрое обнаружение появления новых или изменения существующих путей передачи критичных данных, что потенциально может являться нарушением. Из того немногого, что мы слышали об утечке в Heartland Payment Systems Inc., использование протоколирования и аудита способствовало бы более оперативному обнаружению проблемы и позволило бы избежать таких серьезных последствий.

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

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

Об авторе:
Работая в должности CSO, Дэвид Мортман отвечает за программу исследований и анализа компании Echelon One. Ранее Дэвид занимал должность CISO компании Siebel Systems Inc., и занимался обеспечением безопасности её IT-инфраструктуры, распределенной по всему миру. Имея статус CISSP, Дэвид входит в экспертные советы многих компаний, включая Qualys.

Источник:
http://searchsecurity.techtarget.com/tip/0,289483,sid14_gci1368155_mem1,00.html

В документе "Лучшие практики Visa по шифрованию полей данных" международная платежная система выделила ряд задач, которые необходимо решить при внедрении криптографических средств защиты данных о держателях карт, что в свою очередь необходимо для выполнения требований стандарта PCI DSS:

- ограничить циркуляцию данных о держателях карт и критичных аутентификационных данных в открытом виде только точками шифрования и расшифрования;

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

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

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

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

Рекомендации Visa по этим вопросам на русском языке можно прочитать здесь.

В ноябре этого года планируется публикация новой версии руководства OWASP, где традиционно будут описаны наиболее распространенные уязвимости web-приложений.

Следует обратить внимание на то, что для оценки соответствия требованиям 6.5.1 - 6.5.10 стандарта PCI DSS необходимо опираться на последнюю опубликованную версию OWASP.

Выход предварительной версии OWASP Top 10 планируется в ноябре на конференции OWASP AppSec DC в Вашингтоне. Эта версия не будет официальным релизом, и, следовательно, не вступит в силу немедленно после завершения конференции. Однако, как только будет подготовлена финальная версия документа, приведённые в нём принципы станут обязательными для соответствия PCI, так что советуем обеспокоиться данным вопросом заранее.

Стала доступна для скачивания новая версия СУБД Oracle 11g Release 2. В новой версии появились нововведения, касающиеся повышения отказоустойчивости системы при помощи технологии Real Application Clusters (RAC), позволяющей развертывать базы данных на нескольких серверах одновременно. Кроме того было внесено несколько изменений, коснувшихся повышения безопасности конфигурации по умолчанию, а также достижения соответствия стандартам безопасности, в частности PCI DSS. Одно из самых интересных обновлений, касающихся PCI DSS, заключается в поддержке автоматической смены мастер-ключа шифрования при использовании TDE, что позволяет соответствовать требованию 3.6.4 "Periodic cryptographic key changes" стандарта, не прибегая к ручной смене или установке дополнительных средств.

Следует отметить, что теперь при установке СУБД в конфигурации по умолчанию (в случае использования Database Configuration Assistant) будут установлена требуемая парольная политика, а также включён аудит системных событий. Подробнее об этом и о других изменениях, связанных с безопасностью, вы сможете прочитать в ближайшее время в подробном обзоре на нашем ресурсе.

В качестве одного из последних аргументов в пользу откладывания мероприятий по достижению соответствия PCI на неопределенное время часто приходится слышать, что «и рады бы, да денег нет, тем более кризис на дворе». Многие убеждены в том, что дорога к соответствию требует немыслимых финансовых затрат, не идущих в сравнение с потенциальными штрафными санкциями. Более того, приходилось слышать даже такие крайности, что «под каждое требование стандарта надо покупать что-то большое, сложное и дорогое». На мой взгляд, такие мнения основаны не более чем на поверхностном знании о PCI. Позволю себе предположить, что люди, заявляющие подобное, просто не нашли времени прочитать стандарт, что часто бывает из-за присущего некоторым отделам ИТ ощущения постоянного аврала.

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

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

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

Книга является первым исследованием, написанным отечественным автором, которое посвящено проблеме безопасности СУБД Oracle. Материал книги основан на практическом опыте автора, полученном им в результате проведения тестов на проникновение, анализе защищённости бизнес-приложений и обширной исследовательской деятельности в области безопасности СУБД.

Автор книги - Александр Поляков, ведущий аудитор информационной безопасности компании Digital Security, является одним из основателей и руководителем исследовательского центра Digital Security Research Group [DSecRG], занимающегося поиском и анализом уязвимостей приложений и систем. Помимо этого, Александр входит в состав Экспертного Совета Сообщества PCIDSS.RU, а также является известным экспертом по безопасности бизнес-приложений, обнаружившим и опубликовавшим информацию о большом количестве уязвимостей в приложениях таких производителей, как Oracle, SAP и др.

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

Следует отметить, что второй части книги помимо различных методов защиты СУБД Oracle затронуты вопросы соответствия требованиям стандарта PCI DSS.

«Я уверен, что эта книга, основанная исключительно на практическом опыте автора из DSecRG, вызовет у вас безусловный интерес, предоставив обширный материал для размышлений о специфике защищенности систем управления базами данных», отметил Илья Медведовский, к.т.н., директор компании Digital Security.

Приобрести книгу можно в крупнейших книжных магазинах на территории РФ и интернет-магазинах.

Автор Сергей Шустиков

Однажды в ходе аудита я заметил выделенный канал связи, соединяющий сеть исследуемой компании с сетью другой организации, с которой осуществлялся информационный обмен. Это соединение привлекло мое внимание тем, что не было защищено межсетевым экраном. На мой вопрос, почему сеть сторонней организации не отгорожена файрволлом, ИТ-специалист ответил: «А зачем? Это выделенный канал, мы покупаем у них услугу, у нас с ними подписано Соглашение о конфиденциальности».

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

Между такими механизмами нельзя ставить «или». Их выбор должен быть обоснован наличием соответствующих рисков. Они могут органично дополнять, но ни в коем случае не подменять друг друга.

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

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

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

Довольно часто поднимается вопрос о применении требований о запрете передачи PAN в открытом виде по открытым каналам связи (4.2) и запрете хранения PAN в открытом виде (3.4) к сообщениям электронной почты.

Электронная переписка состоит из двух технологических этапов - передачи сообщения по каналу связи и хранения сообщения на почтовом сервере или клиенте.

Что касается хранения сообщений, содержащих PAN, на почтовом сервере или клиенте, то здесь в любом случае применимо требование 3.4, предписывающее приведение PAN в нечитаемый вид во всех местах его хранения, и тут без шифрования уже не обойтись. Вот с передачей сообщения ситуация особая. Что касается передачи по открытым каналам, то тут всем всё понятно - при выходе почтового трафика во внешние сети, передаваемый PAN однозначно должен быть зашифрован. Больше вопросов вызывает ситуация, когда почтовый трафик не выходит за пределы среды обработки карточных данных, ведь в таком случае может показаться, что требование 4.2 не применимо и передача PAN в открытом виде допускается. Однако это не так, Совет PCI SSC даёт однозначное толкование этого требования - PAN должен быть зашифрован при почтовой пересылке как по внешним так и по внутренним каналам связи.