Антон Чувакин - директор направления PCI Compliance компании Qualys, Ph. D.
Введение
Стандарт безопасности данных индустрии платежных карт (PCI DSS или просто PCI) буквально в корне изменил отношение многих компаний к безопасности. В то время как множество стандартов только обещали «переместить информационную безопасность из коммутационных шкафов в зал заседаний совета директоров», стандарту PCI действительно удалось это сделать для многих организаций (и не только для крупных). Несмотря на то, что следование требованиям стандарта PCI DSS не сделает вашу компанию защищенной по мановению волшебной палочки и не избавит от всех возможных инцидентов, в стандарте содержится много разумных требований к безопасности.
Однако, прежде чем выяснить отношения между соответствием (и особенно - соответствием PCI) и безопасностью, следует вкратце упомянуть, чем же по сути является PCI DSS.
PCI DSS вобрал в себя отдельные требования безопасности различных международных платежных систем, разработанные для повышения безопасности торгово-сервисных предприятий, принимающих платежные карты, тем самым уменьшив риски, связанные с проведением карточных транзакций. Исторически, требования безопасности PCI берут свое начало от попыток международных платежных систем справиться с наплывом карточного мошенничества. С начала 2000-х годов кража карточных данных стала головной болью для организаций любых размеров. На текущий момент самым серьезным инцидентом была кража и последующая продажа более 100 миллионов номеров кредитных и дебетовых карт крупного процессингового центра. Сегодня соответствие стандарту PCI является обязательным для каждого торгово-сервисного предприятия и любой другой организации, обрабатывающей карточные данные, и все крайние сроки достижения соответствия уже прошли.
В статье мы рассмотрим подходы организаций к проектам по достижению соответствия PCI и их влияние на безопасность. А именно, выполняют ли организации требования PCI буквально, т.е. «для галочки», или же они оценивают цели этих требований и их применимость к своему бизнесу? Вдобавок, мы рассмотрим методы, позволяющие упростить этот процесс, для тех, кто считает слишком сложными, как соответствие PCI, так и информационную безопасность.
Многие профессионалы в области безопасности подчеркивают тот факт, что требования соответствия были установлены с целью обеспечения безопасности. Следовательно, поддержание должного уровня безопасности приведет к соблюдению соответствия (равно как и к самой безопасности). Так, девиз “Безопасность на первом месте!” увидел свет.
Однако повышение безопасности - задача не из легких, учитывая сложность современных сетей, быстроту разработки приложений, развитие Web 2.0 и другие нововведения в области информационных технологий. Доктор Дэн Гир (Dan Geer), известный эксперт в области безопасности, однажды сказал, что «обеспечение безопасности, пожалуй, самая сложная в мире интеллектуальная профессия». Многие организации оказались неспособны уделять должное внимание безопасности, и вместо этого стали искать «легкие пути решения» связанных с нею вопросов.
Соответствие против безопасности
Этот принцип критикуется большинством экспертов, допускается некоторыми людьми, и, к большому сожалению, многие его действительно придерживаются. А именно, несмотря на разговоры в стиле: «Соответствие еще не означает безопасность!» и «Безопасность в первую очередь!», существует немало специалистов, считающих, что соответствие PCI DSS это просто очередной тактический ИТ-проект внедряемый «для вида».
Чтобы показать это наглядно, рассмотрим вымышленную ситуацию: до руководства организации средних размеров доходит информация о необходимости внедрения PCI , и оно решает разобраться с этим вопросом. Возможно, банк-эквайер потребовал от них соответствия, или поставщик ИТ-услуг начал регулярно напоминать о необходимости соответствия PCI. Что же происходит дальше?
Следуя описанному принципу «Соответствие на первом месте», руководство организации вызывает ИТ-менеджера (предположим, что компания не настолько велика, чтобы обладать собственным штатом сотрудников в области безопасности) и выдает ему текст двенадцати требований PCI DSS вместе с поручением все их выполнить, не выделяя при этом дополнительного бюджета. В результате, ИТ-менеджер должен решать проблему соответствия PCI в этих весьма стесненных обстоятельствах.
Что происходит дальше? ИТ-менеджер просматривает список требований и замечает, что некоторые из них уже выполнены. К примеру, на стене величественно висит схема сети (требование 1.1.2). А как насчет остальных требований? Представим, как выстраиваются внутренние рассуждения ИТ-менеджера и его реакция по мере того, как он просматривает список требований.
Прочтя это, ИТ-менеджер с удовольствием подтвердит, что антивирус установлен. Хотя, думать о том, развернуто ли антивирусное программное обеспечение действительно на всех системах «подверженных воздействию вирусов» скорее всего он не будет – «слишком сложно».
Здесь менеджер, возможно, подумает: «А что они здесь имеют в виду? Ведь антивирусное программное обеспечение работает, да?» Таким же образом будет пропущено, или «отложено» решение «сложного» вопроса с журналами протоколирования событий, о котором говорится в этом требовании.
Мнение о том, что это требование относится к межсетевому экрану, развернутому перед веб-сервером (веб-приложение + межсетевой экран = межсетевой экран перед веб-сервером) является весьма распространенным! Однако любой эксперт в области безопасности знает, что на самом деле это относится к другой системе, а именно к межсетевому экрану для Web-приложений (WAF). В случае с этой компанией ИТ-менеджер возможно и не будет думать в этом направлении.
ИТ-менеджер, наверно, вспомнит, что сервер syslog, который был развернут несколько месяцев назад, все еще на своём месте. Думать о серверах syslog только в контексте протоколирования - распространенная ошибка. На самом деле, требование PCI DSS 10.6 охватывает изучение и анализ журналов, поэтому одного его наличия будет недостаточно.
Установка и запуск системы Snort с целью обнаружения тревожных сигналов IDS/IPS - это то, что обычно приходит здесь на ум. Многие ИТ-менеджеры слышали, что IDS - это «кошмар», но они по-прежнему надеются на то, что развертывание NIDS «позволит их системам соответствовать требованиям».
В целом, ИТ-менеджер читает требование за требованием и смотрит, что из этого выполняется в его сети. Иногда он решает внести некоторые изменения. После прочтения последнего, 12-го требования и внесения запланированных изменений ИТ-менеджер считает, что с задачами проекта по достижению соответствия PCI DSS он справился.
Соответствует ли теперь организация требованиям PCI? Ответ - «Всё зависит от обстоятельств». При отсутствии аудита они спокойно могут считать, что их организация соответствует требованиям PCI DSS, раз их система может успешно пройти сканирование (требование 11.2). Но покажет ли соответствие аудит, проведенный после инцидента?
Повысилась ли теперь защищенность организации? И опять ответ – «Всё зависит от обстоятельств». Есть шанс, что если бы ИТ-менеджер осознавал риски для своей компании (что редко для малых организаций) и принял бы простые меры по устранению конкретно этих рисков (что является исключением для малых организаций), то безопасность была бы на более высоком уровне. Тем не менее, существует некая вероятность того, что защищенность этой организации повысилась по причине её стремления соответствовать требованиям PCI DSS. Например, если ИТ-менеджер установил более жесткие правила парольной политики или отключил несколько учетных записей по умолчанию, то уровень безопасности в организации действительно повысился.
В любом случае, у компании появилось больше уверенности при заполнении опросных листов (SAQ) и проведении ASV-сканирования.
| 
22 января 2010
