 Стандарт PCI DSS требует от организации проведения теста на проникновение не реже одного раза в год, а также после внесения значительных изменений в информационную инфраструктуру. Требование 11.3 говорит о том, что тест на проникновение должен выполняться как на сетевом уровне, так и на уровне приложений, при этом тестирование должно выполняться как извне, так и изнутри сети организации.
Выполнить тест на проникновение может как внешний консультант, так и штатный специалист организации, административно независимый от сотрудников и подразделений, ответственных за поддержку и эксплуатацию тестируемых систем.
Как оказалось, в среде специалистов по карточной безопасности встречается заблуждение о том, по каким критериям определяется успех или провал теста на проникновение. Заблуждение заключается в том, что якобы для того, чтобы «засчитать» проникновение, пентестер должен непременно ознакомиться с данными о держателях карт. Кроме того, часто поднимается вопрос о том, проникновения в какие системы считать критичными.
Для того, чтобы развеять заблуждение, обратимся к первоисточнику, а именно – Совету PCI SSC, в частности - к опубликованному им документу Information Supplement: Penetration Testing, дающему однозначные ответы на оба вопроса.
Что касается вопроса «куда надо проникнуть», то есть понятие области тестирования (scope), в которую входит вся среда данных о держателях карт, а также связанные с ней системы. При этом особо отмечается, что если имеет место сегментация сети, надежно изолирующая среду данных о держателях карт, и при этом аудит соответствия PCI DSS доказал адекватность изоляции, то область тестирования можно сократить до границ среды данных о держателях карт. Всё что вошло в область тестирования – всё априори критично, так как имеет отношение к обработке, хранению и передаче данных о держателях карт.
Теперь о критериях тестирования. Совет PCI SSC написал вполне однозначно: целью теста на проникновение является выяснение того, может ли быть получен неавторизованный доступ к ключевым системам и файлам. То есть иными словами – исследовать область тестирования на предмет наличия уязвимостей и проверить возможность их эксплуатации с целью повышения привилегий в системах, входящих в неё. Обнаруженные уязвимости должны быть устранены и затем проведено повторное тестирование. Ни в коем случае ни целью пентестера, ни критерием успешности теста на проникновение не является ознакомление с данными о держателях карт.
В самом деле, давайте представим такую ситуацию – в области тестирования взломано 90% систем, при этом несколькими способами, через десятки уязвимостей. Но данные о держателях карт в соответствии с требованием 3.4 PCI DSS хранились в зашифрованном виде и поэтому пентестер не смог с ними ознакомиться. Что же, считать в таком случае, что тест на проникновение организацией успешно пройден, и ничего устранять не надо? Абсурд.
Тест на проникновение и сканирование ASV являются важными элементами мониторинга информационной безопасности организации, нацеленными на выявление и устранение уязвимостей в крайне критичной информационной инфраструктуре – среде данных о держателях карт. Здесь важно внимательное отношение к любой, даже потенциальной возможности получения несанкционированных привилегий в отношении входящих в неё систем.
| 
А какие средства используете обычно для эксплуатации обнаруженных уязвимостей? Разрабатыавете сами каждый раз или используете готовые?
Если пентестер взломал множество систем, но не смог получить доступ к карточным данным - значит карточные данные защищены адекватно.
И системы, которые он взломал - никак не участвуют в обработке карточных данных и находятся вне скопа (иначе он таки смог бы эти данные получить/перехватить/изменить итд итп).
http://forum.pcidss.ru/index.php?topic=39.0
http://forum.pcidss.ru/index.php?topic=37.0
что и привело к написанию этой заметки.
Вы рассуждаете как стандартные пентестеры, да уязвимость есть и надо ее устранять.
Да хоть там 99,99% систем взломано, всеравно ДДК ЗАШИФРОВАНЫ... (не надо называть это абсурдом)
Вы советуете: "Для того, чтобы развеять заблуждение нужно обратиться к первоисточнику", так переведите и приведите конкретно пример, где там однозначные ответы на наши "заблуждения"?
Вам приводили пример из этого документа:
"Выжимка из документа Data Security Standart. Information Supplement: Requirement 11.3 Penetration Testing.
Важные замечания
1. С точки зрения соответствия требованиям PCI тестирование уязвимостей и недостатков в настройке систем безопасности, которое может привести к DоS атакам, нарушающим доступность ресурсов, не должно входить в тестирование на проникновение, поскольку это не приведет к компрометации данных держателей карт."
На что вы даете ответ:
"DoS компрометации любых данных и получению любых привилегий не поможет"
...из чего следует, что вы признаете о том, что при тесте должна произойти компрометация каких-то данных...
Пример: Вы увидели ведро(обнаружили уязвимость) в углу комнаты, понимаете что вы теоретически можете туда попасть комком бумаги, и попав убедить всех что это возможно, только пока не кинете, вы не будете знать на 100%(т.е. пока не узнаете что это ддк). Вдруг там сквозняк и бумагу сдует или она отскочит от края ведра и т.д., но это все мелочи. Главное в том, что вы даже не имеете право кинуть туда бумагу (проводить тест) и проверить попали или нет! (и только не надо говорить, что мы разрешим вам это сделать в договоре)
И то что вы подразумеваете под собственными разработками или готовыми средствами для обнаружения уязвимостей, все равно попадает под статью.
Ну постеснялись бы хоть выставлять на всеобщее обозрение свою глухую некомпетентность в технических вопросах. Мухин, вы что всерьез думаете, что шифрование - это панацея??? Вы что правда думаете, что получив рута на системе, где лежат зашифрованные данные, в которым ПОСТОЯННО идет обращение (!, то есть они так или иначе в памяти расшифровываются) у хакера возникнут серьезные сложности с получением к ним доступа? А вам не приходит в голову, что, например, попав на рабочую станцию админа через троян или снифер можно "снять" пароль доступа к зашифрованным даным?
Вам уже 10 раз объяснили, что доступ к любому объекту в процессинге - это крайне критично. Будь там хоть 100 шифрований - хакера это не остановит, если к зашифрованным данным регулярно осуществляется логический доступ. Что тут не понятного????
Что касается УК, то почитайте УК и обсуждения в инете. Это все бред и все это давно поняли. Где там умысел? И где там вредоносное ПО - Nmap???
Наш проект - это не обычный форум, где можно троллить и флудить, уводя беседу не в то русло. Это форум профессионалов, задача которого не просто поговорить, а на выходе получить правильные ответы на актуальные вопросы по теме PCI Compliance. Поэтому мы, как модераторы проекта, пресекали и всегда будем пресекать здесь любые попытки увода беседы в сторону от проблемы, что может ввести в заблуждение как участников дискуссии, так и остальных читателей.
Предлагаю вернуть беседу в конструктивное русло.
Меня, как возможного, будущего клиента некой компании-аудитора, волнуют следующие вопросы:
1. Чем отличается сканирование от пентеста? В случае обнаружения уязвимостей в последнем случае я должен буду их устранить, но ведь то же я делаю и при их обнаружении в результате сканирования. В чем разница?
2. Что считать успехом пентеста - отсутствие уязвимостей или невозможность для аудитора получения доступа к данным держателей карт?
Поясните, пожалуйста.
1. Сканирование отличается от пентеста тем, что сканирование - это поиск уязвимостей по поверхности при помощи автоматизированного сканера, а пентест - это ручная работа специалиста, который не только ищет уязвимости, но и пытается их эксплуатировать. Получив доступ к какому-либо компоненту информационной инфраструктуры он развивает атаку далее вглубь инфраструктуры, в поисках уязвимых компонентов и возможностей дальнейшего повышения привилегий. То есть пентест - это гораздо более глубокий анализ.
2. Успехом пентеста для тестируемой компании является отсутствие уязвимостей, которые можно эксплуатировать и тем самым повышать привилегии в информационной инфраструктуре. Получение доступа к данным о держателях карт не является критерием успеха или неуспеха пентеста - в любом случае найденные бреши в безопасности необходимо устранить. Сразу хочу оговориться - это не только наше мнение, но также и официальное мнение Совета PCI SSC, озвученное им на ежегодном собрании QSA-аудиторов.
http://forum.pcidss.ru/index.php?topic=39.0
http://forum.pcidss.ru/index.php?topic=37.0).