Многочисленные случаи компрометации данных регистрируются среди компаний, которые до этого подтвердили соответствие требованиям стандарта PCI DSS. Это стало причиной для широкой дискуссии, которая развернулась в последнее время: можно ли считать PCI DSS эффективным с учетом реалий сегодняшнего дня? Доводы сторон были собраны на страницах сайта CSO.com.
Соответствие стандарту безопасности не гарантирует отсутствие возможностей для киберпреступлений
Стандарт PCI DSS, как и любые другие стандарты в области кибербезопасности, проектировался вовсе не для того, чтобы полностью исключить возможность хакерского взлома или совершения других киберпреступлений. Цель его разработки состояла в том, чтобы компании могли обеспечить себе минимально приемлемый уровень безопасности, позволяющий принимать платежи с использованием платежных карт.
Подтверждение компанией соответствие стандарту PCI DSS в чем-то напоминает выдачу водительских прав. Владелец автомобиля получает право управлять им на дорогах. Однако если его вождение станет причиной инцидента, никто не будет выдвигать обвинения в адрес автоинспекции за выдачу прав. И вряд ли имеет смысл вопрос: эффективна ли выдача водительских прав как таковая?
Очевидно выдача водительских прав не ставит целью искоренить аварийность на автодорогах. То же самое можно сказать и в отношении PCI DSS: он не предназначен для борьбы против всех уязвимостей. Стандарт только задает минимальный уровень защиты. Стать непреодолимым заслоном на пути любых киберпреступлений или утечек данных он не может.
В 99% случаев аварийность на дорогах является следствием ошибок (явных или непреднамеренных). Точно также 99% случаев обнаружения нарушений требованиям PCI DSS в компаниях связаны с тем, что отдельные элементы стандарта не были реализованы в полном объеме на момент совершения кибернарушения.
Примеры из практики: соответствие веб-приложений требованиям PCI DSS
Если классифицировать инциденты, связанные с нарушением PCI DSS, то менее половины связаны с компрометацией данных через доверенные приложения сторонних компаний, атаками на уровне физических устройств (скимминг, кража данных при работе с POS-терминалами и т. д.), угрозами со стороны инсайдеров и др. С другой стороны, более половины инцидентов касаются корпоративных веб-приложений, которые по той или иной причине оказались небезопасными.
Согласно Требованию 6 стандарта, компании должны «разрабатывать системы и приложения с учетом их безопасности и поддерживать этот уровень в актуальном состоянии». Однако большинство организаций неточно трактуют это требование и особенности его применения на практике.
Для примера можно взять Требование 6.2: «убедиться, что установка всех критичных обновлений безопасности произведена в течение одного месяца после выпуска». Совет Security Standards Council допускает столь длительный срок для внедрения, принимая во внимание существование сложных промышленных систем, где установка каждого обновления требует тщательного предварительного тестирования до развертывания в производственный режим. Однако для большинства веб-приложений, имеющих отношение к электронной торговле, максимальный срок для установки обновлений не превышает восьми рабочих часов. Иначе, как считают в Совете, отсутствие «заплатки» является прямым «приглашением» для хакеров посетить данную корпоративную систему.
Аналогичная «неточность» есть в отношении задержек в доступности для торговых электронных систем. В стандарте PCI DSS нет точных значений этого параметра, однако многие отмечают, что работоспособность таких систем должна быть восстановлена в полном объеме в течение не более 24 ч.
В Требованиях 6.3 и 6.4 рассматривается жизненный цикл разработки безопасных систем, стандарты безопасной разработки и управления изменениями внутри организации. На первый взгляд все ясно, но, как показывает практика, даже самые опытные разработчики могут оказаться жертвами ошибок вследствие аврального решения производственных задач, усталости или появления групповых ошибок. В результате небезопасные программы и настройки переносятся в производственный режим, становясь причиной для возникновения уязвимостей. Когда в распоряжении разработчика есть всего один час на написание новой функции, то избежать появления ошибок практически невозможно.
Поэтому какой бы сбалансированной между требованиями рынка и кибербезопасности политики ни придерживается компания, она может столкнуться с ситуацией, что у нее «неожиданно» обнаруживаются проблемы, хотя ранее была проведена проверка на соответствие стандарту PCI DSS.
В Требовании 6.6 прямо cказано: продавец обязан устанавливать веб-брандмауэр либо регулярно проверять веб-приложения на выявление уязвимостей (как минимум тех из них, которые попадают под требования стандарта в разделе 6.5.x; в первую очередь обращают внимание на типовые уязвимости, выделенные в Требованиях
Однако сегодня нет полностью автоматизированных программ, надежно и при любых условиях выявляющих любые уязвимости, указанные в Требованиях 6.5.x. Например, к числу наиболее сложных для выявления относятся уязвимости, относящиеся к Требованиям 6.5.10 «Прерванная аутентификация и нарушения в управлении сессиями пользователей» и 6.5.8 «Ошибки контроля доступа». Они не поддаются 100%-ному выявлению с использованием автоматизированных средств DAST (Dynamic application security testing) или SAST (Static application security testing).
Разработчики практически любого сканера уязвимостей заявляют, что он способен обнаруживать все виды проблем. Поэтому во многих торговых организациях действует правило: для полноценного удовлетворения Требованию 6.6 PCI DSS достаточно сканировать веб-приложения ежеквартально. Если вдруг обнаруживается неучтенная уязвимость, то начинают ошибочно обвинять стандарт в неэффективности. Хотя причина кроется совсем в другом.
Единая политика управления рисками
Однако основные проблемы связаны прежде всего не с недопониманием стандарта PCI DSS, а с неполным или нерегулярным проведении оценки рисков, с которыми сталкивается компания. Даже если обеспечить полную изоляцию рабочего места от Интернета, то эта защита легко обходится в случае компрометации всей корпоративной сети.
Поэтому компаниям не следует ограничиваться только рассмотрением рабочих мест сотрудников на соблюдение правил безопасности. Необходимо рассматривать все применяемые системы и работающие сети. В этой концепции PCI DSS должен рассматриваться как базовый норматив для построения всей корпоративной ИТ-инфраструктуры.
Если продолжить аналогию с водительскими правами, то чтобы их получить, достаточно научиться водить автомобиль. Точно также для обеспечения безопасности корпоративной сети требуется научиться эффективно применять стандарт PCI DSS. Однако для получения полноценной защиты необходимо работать в упреждающем темпе.
