По изискване
Тестване за проникване по PCI DSS, изградено около изискване 11.4
PCI DSS v4.0.1 очаква документирана методология, вътрешни и външни тестове поне веднъж на 12 месеца и след значима промяна, тестване на сегментацията и повторни тестове на корекциите. Ние провеждаме този тест и ви даваме доказателства, които оценителят ви може да проследи.
Какво изисква
Какво всъщност изисква изискване 11.4
Изискване 11.4.1 започва с метода, а не с инструментите. Нужна ви е документирана методология за тестване за проникване, базирана на утвърдени в бранша подходи, която обхваща целия периметър на средата с данни на картодържатели и критичните системи, тества отвътре и отвън на мрежата, валидира сегментацията и контролите за намаляване на обхвата, включва тестване на ниво приложение поне за уязвимостите, изброени в изискване 6.2.4, и покрива мрежовите компоненти и операционните системи. Тя трябва също да отчита заплахите и уязвимостите от последните 12 месеца, да определя как констатациите, годни за експлоатация, се оценяват по риск и се адресират, и да пази резултатите и записите за отстраняване поне 12 месеца.
След това изисквания 11.4.2 и 11.4.3 задават ритъма: вътрешни и външни тестове поне веднъж на 12 месеца и след всяко значимо надграждане или промяна на инфраструктурата или приложенията, изпълнени от квалифициран вътрешен ресурс или квалифицирана трета страна с организационна независимост. Тестерът не е задължително да бъде QSA или ASV. Изискване 11.4.4 налага констатациите, годни за експлоатация, да бъдат коригирани според вашата оценка на риска и тестът да бъде повторен, за да се проверят корекциите. Тримесечното сканиране за уязвимости по 11.3 е отделно задължение и не удовлетворява 11.4.
11.3.1 и 11.3.2 Сканиране за уязвимости
Вътрешните сканирания и външните ASV сканирания се изискват поне веднъж на три месеца. Сканиранията откриват известни слабости автоматично; те стоят редом с, но никога не заместват воденото от експлоатация ръчно тестване, изисквано по 11.4.
11.4.1 Методология за тестване за проникване
Вашата методология трябва да бъде записана и следвана, обхващайки периметъра на средата с данни на картодържатели, критичните системи, мрежовия и приложния слой, сегментацията, скорошните заплахи, подход към констатациите, основан на риска, и 12-месечно съхранение на резултатите.
11.4.2 и 11.4.3 Вътрешно и външно тестване
Тествайте отвътре на средата с данни на картодържатели, към нея от вътрешните мрежи и срещу изложения външен периметър, поне веднъж на 12 месеца и след значима промяна, с квалифициран и организационно независим тестер.
11.4.4 Корекция и повторно тестване
Уязвимостите, годни за експлоатация, и слабостите в сигурността се отстраняват съгласно вашите оценки на риска по 6.3.1, след което тестът за проникване се повтаря, за да се потвърди, че корекциите действително работят.
11.4.5 и 11.4.6 Тестване на сегментацията
Ако сегментацията намалява обхвата, тествайте всеки контрол за сегментация, за да докажете, че средата с данни на картодържатели е изолирана от системите извън обхвата: на всеки 12 месеца за всички субекти, на всеки шест месеца за доставчиците на услуги и след промени.
6.4.3 и 11.6.1 Скриптове на страниците за плащане
Скриптовете на страниците за плащане трябва да бъдат разрешени, проверени за цялост и описани, а неразрешените промени в скриптовете и в HTTP заглавките със значение за сигурността — засичани седмично или съгласно целеви анализ на риска. Тестването може да провери дали тези контроли издържат.
Какво да се тества
Какво трябва да обхване един тест по изискване 11.4
Външен периметър
Всяка система, достъпна от интернет, която е свързана със средата с данни на картодържатели или може да я достигне, включително отдалечен достъп, страници за плащане, API и хостинг или облачни услуги пред тях.
Вътрешно и в средата с данни
Тестване отвътре на средата с данни на картодържатели и към нея от доверени и недоверени вътрешни мрежи, обхващащо мрежови устройства, операционни системи, директорийни услуги и пътищата, по които нападател би достигнал до данните за сметки.
Контроли за сегментация
Всеки набор от правила на защитна стена, VLAN, облачна група за сигурност или друг контрол, на който разчитате за намаляване на обхвата, тестван от всеки сегмент извън обхвата, за да се потвърди, че не може да достигне средата с данни.
Приложения и платежни потоци
Тестване на приложния слой за обработката на плащания и данни за сметки поне за класовете уязвимости по изискване 6.2.4, плюс преглед на начина, по който се контролират скриптовете и заглавките на страниците за плащане.
Какво получавате
Какво получавате и как то подкрепя вашата оценка
Методология, съотнесена към 11.4.1
Писмена методология, показваща как се изпълнява всеки елемент от 11.4.1, която можете да приемете или да цитирате, за да види оценителят ви определен подход, а не инцидентен тест.
Доклад, готов за оценителя
Обхват, дати, данни за тестера и независимостта му, подход на тестване и всяка констатация със степен на критичност, доказателства и стъпки за възпроизвеждане, за да може вашият QSA или вътрешен оценител да проследи какво е тествано и открито.
Доклад от повторния тест
Отделен повторен тест, документиращ кои констатации са потвърдени като отстранени и кои остават отворени, което ви дава записа, изискван по 11.4.4, и чиста следа за отстраняването.
Резултати от сегментацията
Изложение на всеки тестван контрол за сегментация — от кои сегменти, с каква техника и с какъв резултат — в подкрепа на 11.4.5 или 11.4.6 и на вашите решения за обхвата.
Чести капани
Къде тестването за проникване по PCI DSS се обърква
Грешки, които струват време при одит, и как да ги избегнете.
Третиране на сканирането като тест за проникване
Успешно ASV сканиране подкрепя 11.3.2, а не 11.4.3. Оценителите очакват ръчно тестване, което прави опити за експлоатация, а доклад само от сканиране рядко демонстрира методологията, изисквана по 11.4.1.
Частично тестване на сегментацията
Тестването на извадка от сегменти или на една защитна стена оставя намаляването на обхвата недоказано. Всеки използван контрол за сегментация се нуждае от тестване, а доставчиците на услуги трябва да го повтарят на всеки шест месеца.
Пренебрегване на значимата промяна
Годишният тест е минимум. Тестване се изисква и след всяко значимо надграждане или промяна на инфраструктурата или приложенията, а нови платежни потоци, миграции към облак или преработки на мрежата спокойно могат да се квалифицират — затова определете какво се брои за значима промяна преди оценката, а не по време на нея.
Констатации без повторен тест
Доклад с неотстранени констатации и без повторна проверка на поправките не изпълнява изискване 11.4.4. Предвидете време за отстраняване и повторен тест преди оценката.
Кой решава какво се приема
PXLSec е независима фирма за офанзивна сигурност, не одитор, оценител, сертифициращ орган или регулатор. Ние осигуряваме тестването и доказателствата; вашият одитор, оценител или компетентен орган решава какво приема. Тази страница е обща насока, не юридически съвет. Обобщаваме тези изисквания със свои думи въз основа на публично достъпни указания; винаги проверявайте точната формулировка спрямо официалния стандарт, преди да се позовавате на нея.
Често задавани въпроси
Често задавани въпроси
Достатъчно ли е тримесечното сканиране за уязвимости за PCI DSS?
Не. Изискване 11.3 покрива вътрешни сканирания и външни ASV сканирания на всеки три месеца, докато изискване 11.4 отделно изисква тестване за проникване по определена методология. Сканирането открива известни слабости автоматично; тестването за проникване прави опит да ги експлоатира и свързва проблемите така, както би го направил нападател.
Колко често ни е нужен тест за проникване по PCI DSS?
Вътрешни и външни тестове за проникване се изискват поне веднъж на 12 месеца и след всяко значимо надграждане или промяна на инфраструктурата или приложенията. Ако използвате сегментация, тя трябва да бъде тествана на всеки 12 месеца, или на всеки шест месеца при доставчиците на услуги, и след всяка промяна в контролите за сегментация.
Може ли собственият ни екип да извърши теста?
PCI DSS v4.0.1 допуска квалифициран вътрешен ресурс или квалифицирана външна трета страна, при условие че тестерът е организационно независим от тестваните системи. Тестерът не е задължително да бъде QSA или ASV. Много организации използват външен тестер, за да е лесно независимостта да бъде доказана.
Използваме вградена форма за плащане и SAQ A. Имат ли значение скриптовете на страницата за плащане?
Редакцията на SAQ A от януари 2025 г. премахна изисквания 6.4.3 и 11.6.1, но добави критерий за допустимост, според който сайтът ви не е податлив на атаки през скриптове, които биха могли да засегнат вашите системи за електронна търговия. Насоките на PCI SSC посочват, че търговците с вградени форми могат да изпълнят това, като приложат тези защити сами или получат потвърждение от своя доставчик на платежни услуги, съответстващ на PCI DSS. Потвърдете подхода си с вашата обслужваща банка.
PXLSec наш QSA или ASV ли е?
Не. PXLSec не е QSA, ASV или какъвто и да е оценител по PCI и не валидира, нито сертифицира съответствие. Ние извършваме тестването за проникване, което изискване 11.4 налага, и го документираме така, че вашият QSA, вътрешен оценител или обслужваща банка да може да го оцени.
Тази страница съвет за съответствие или правен съвет ли е?
Не. Това е насока, основана на нашия прочит на PCI DSS v4.0.1 и публикациите на PCI SSC. Вашият QSA, обслужваща банка или картова организация решава как изискванията се прилагат към вашата среда, затова потвърдете обхвата и честотата с тях, преди да разчитате на какъвто и да е тест.
Услуги, които осигуряват това
Официални източници
- PCI SSC — общ преглед на стандарта PCI DSS
- PCI SSC — библиотека с документи, PCI DSS v4.0.1
- PCI SSC — обществено обсъждане на PCI DSS v4.0.1, юни 2026 г.
- PCI SSC — важни промени за търговци, използващи въпросника за самооценка SAQ A
- PCI SSC — разяснения за новите критерии за допустимост по SAQ A
- PCI SSC — сигурност на платежните страници и предотвратяване на електронно източване на картови данни
Нека обсъдим обхвата на теста.
Кажете ни какво искате да защитите. Опитен специалист ще ви помогне да определите обхвата и следващите стъпки. Обикновено отговаряме в рамките на един работен ден.
Поверителност от първия разговор
Можем да подпишем вашето NDA, преди да споделите чувствителни детайли. За запитването ви се прилага политиката ни за поверителност.
Как защитаваме информацията ви · Политика за поверителност