Тестването на сегментацията по PCI DSS, обяснено

Тестването на сегментацията е частта от PCI DSS, най-често бъркана с по-малък тест за проникване. Тя не е такава. Тя е доказателството, подпиращо цялото ви твърдение за обхват — и ако се провали, всичко, което сте изключили от оценката, се връща. Тази първа част покрива какво доказва тестът, какво изисква PCI DSS v4.0.1 в 11.4.5 и 11.4.6, кой може да го извършва и колко често.

Какво всъщност е тестването на сегментацията

Тестването на сегментацията е тест на контролите, които държат системите извън вашата среда с данни на картодържателите. То не е тест за проникване на самата CDE. Въпросът, на който отговаря, е тесен: механизмите, отделящи системите в обхвата от тези извън обхвата, наистина ли работят, в конфигурацията, която върви днес?

Това разграничение има значение заради начина, по който работи определянето на обхвата по PCI DSS. Стандартът се прилага към всички системни компоненти, включени в или свързани със средата с данни на картодържателите, и към всичко, което би могло да засегне сигурността на данните на акаунтите. Оставена плоска, типична корпоративна мрежа вкарва почти всичко в оценката: служебната безжична мрежа, сървърите за билдове, базата данни на отдела за човешки ресурси, принтерите. Сегментацията е начинът да намалите това. Поставяте контроли, които пречат на мрежите извън обхвата да достигнат CDE, и на тази основа обявявате тези мрежи извън обхвата.

Логиката е здрава, но условна: изключването важи само ако отделянето важи. Мрежа, обявена извън обхвата, която всъщност може да достигне хранилище с данни на картодържатели, не е извън обхвата — тя винаги е била в обхвата и е останала неоценена за времето, в което грешката е продължила. Сегментацията е единственият контрол, чийто провал обезсилва със задна дата границата на оценката ви, вместо просто да произведе констатация. Оттук идва изискването тя да бъде тествана.

ИЗВЪН ОБХВАТА                    В ОБХВАТА
+-------------------+            +---------------------+
| Корпоративна LAN  |            | CDE                 |
| Служебна Wi-Fi    |  --X-->    | Хранилища с данни   |
| Dev / test        |            | Платежни приложения |
| Гост мрежа        |            +---------------------+
+-------------------+                      ^
                                           |
         X-ът е контролът за сегментация    |
         (набор правила на защитна стена,   |
          ACL, VRF, security group,         |
          граница на VLAN,                  |
          политика за микросегментация)     |
                                           |
+-------------------+                       |
| СВЪРЗАНИ-С /      | ----------------------+
| ЗАСЯГАЩИ          |  позволени, оценени пътища
| СИГУРНОСТТА       |  (те са В обхвата, макар
| Jump хостове, AD, |   да не са CDE)
| наблюдение, admin |
+-------------------+

Тестването на сегментацията се насочва към „X“-а и всичко
вляво от него. То пита: може ли нещо в колоната извън обхвата
да достигне колоната в обхвата? Ако да, колоната извън
обхвата никога не е била извън обхвата.

Формулирано вътрешно: тест за проникване на CDE пита колко зле може нападател, вече вътре в обхвата, да ни навреди? Тест на сегментацията пита вярна ли е диаграмата ни на обхвата? Изискване 11.4.1 очаква методологията ви да покрива и двете, но те не са заместители, а доклад, покриващ само първото, няма да удовлетвори оценител, търсещ второто. За това как се вмества в по-широката програма, вижте нашата страница за PCI DSS.

Какво изисква стандартът

Статията използва PCI DSS v4.0.1, публикуван през юни 2024 г. Проверете библиотеката на PCI SSC и версията за вашата оценка, преди да планирате работата. Предположения за бъдещи версии не са основание за промяна на текущите задължения.

Две изисквания разглеждат конкретно сегментацията. Изискване 11.4.5 се прилага към всички организации: ако сегментацията се използва за изолиране на CDE от други мрежи, тестовете за проникване се извършват на контролите за сегментация поне веднъж на всеки 12 месеца и след всякакви промени в контролите или методите за сегментация; покривайки всички използвани контроли и методи за сегментация; според определената от организацията методология за тестване за проникване; потвърждавайки, че тези контроли и методи са работещи и ефективни и изолират CDE от всички системи извън обхвата; и потвърждавайки ефективността на всяко използване на изолация за отделяне на системи с различни нива на сигурност, с кръстосана препратка към Изискване 2.2.3. Тестът трябва да бъде извършен от квалифициран вътрешен ресурс или квалифицирана външна трета страна, с организационна независимост на тестера.

Изискване 11.4.6 е допълнително изискване само за доставчици на услуги. Съдържанието му е идентично с 11.4.5, с изключение на една промяна: интервалът е поне веднъж на всеки шест месеца, а не дванадесет, със същото задължение за тестване след всякакви промени. Доставчик на услуги не удовлетворява 11.4.6, като прави 11.4.5 добре; удовлетворява го, като прави същото нещо два пъти по-често.

Три детайла си заслужават вниманието. Казва тестове за проникване, не преглед на конфигурацията — очакването е опит за преминаване на границата, не кабинетна проверка на набор правила. Казва всички използвани контроли и методи за сегментация: всеки механизъм, на който разчитате, не извадка. И казва всички системи извън обхвата, което е трудната част, защото тестът трябва да се движи от всяка отделна позиция извън обхвата, а не от една удобна наблюдателна точка.

Те не стоят самостоятелно. 11.4.1 изисква документирана, внедрена методология за тестване за проникване, чиито елементи изрично включват тестване както отвътре, така и отвън на мрежата, и тестване за валидиране на всякакви контроли за сегментация и намаляване на обхвата — така че тестването на сегментацията трябва да е описано в методологията ви, преди да бъде извършено, не измислено на място. 11.4.2 и 11.4.3 покриват вътрешно и външно тестване за проникване, всяко поне веднъж на всеки 12 месеца и след всяка значителна инфраструктурна или приложна надстройка или промяна. 11.4.4 изисква използваемите уязвимости и слабости в сигурността, намерени по време на тестването, да бъдат коригирани в съответствие с оценката ви на риска по Изискване 6.3.1 и тестването да се повтори, за да провери корекциите — включително констатациите за сегментацията. 11.4.7 задължава доставчиците на услуги, които обслужват множество клиентски организации да подкрепят външното тестване на клиентите си.

Един-единствен ангажимент често произвежда вътрешни, външни резултати и резултати за сегментацията заедно, но те са три отделни набора констатации спрямо три отделни изисквания, а вашият Доклад за съответствие ги третира като такива.

Кой може да го извършва

Изискването е изрично и по-разрешително, отколкото много организации допускат. Тестването на сегментацията по 11.4.5 и 11.4.6 трябва да бъде извършено от квалифициран вътрешен ресурс или квалифицирана външна трета страна, а организационната независимост на тестера трябва да съществува. Стандартът после заявява, в скоби и с тези думи, че тестерът не е длъжен да бъде QSA или ASV. Същата формулировка се появява в 11.4.2 и 11.4.3.

И така, има две проверки на тестера, и нито една не е сертификационна схема. Първата е квалификация: може ли този човек да докаже уменията и опита да върши работата? Оценителят ви търси доказателство — удостоверения, документирана методология, предишна работа със сравним обхват. Квалификацията е преценка за компетентност, не лиценз, който държите.

Втората е организационна независимост, където се случват повечето спорове. Принципът: човекът, тестващ контрол, не бива да е човекът, отговорен за него. Независимостта е свойство на йерархичните линии и отчетността, не на трудовия статус. Вътрешен екип, отчитащ се на CISO, без оперативна собственост на защитните стени или мрежовата политика, може да е организационно независим. Външна консултантска фирма, която е проектирала и поддържа архитектурата ви за сегментация, може да не е — това, че е отделно юридическо лице, не премахва конфликта.

Ето защо мрежовият екип, тестващ собствените си правила на защитната стена, обикновено е погрешен избор, колкото и способни да са инженерите. Три проблема се натрупват. Те оценяват собствената си работа, затова отрицателна констатация е самообвинение и стимулът върви в погрешната посока. Те знаят какво правилата трябва да правят, затова тестват предвидените пътища — докато стойността на упражнението лежи изцяло в пътищата, които никой не е проектирал. И те тестват оттам, където седят, привилегирована административна позиция, не от позициите извън обхвата, които нападател би заел. Резултатът обикновено е документ, потвърждаващ, че наборът правила съответства на дизайна: преглед на конфигурацията, не това, което 11.4.5 иска.

За да сме ясни за собствената си позиция: PXL Security е фирма за тестване за проникване. Ние не сме QSA, ASV или какъвто и да е PCI оценител, не извършваме оценки по PCI DSS и не издаваме Атестации за съответствие. Извършваме тестване на сегментацията като квалифицирана, организационно независима трета страна и произвеждаме доказателство, което вашият QSA може да оцени спрямо 11.4.5 или 11.4.6. Оценителят ви решава дали това доказателство удовлетворява изискването; ние не можем да направим това определяне.

Колко често и какво се зачита за промяна

Честотата е проста на хартия. Всички организации, използващи сегментация: поне веднъж на всеки 12 месеца. Доставчици на услуги: поне веднъж на всеки шест месеца. И двете, допълнително: след всякакви промени в контролите или методите за сегментация.

Този второ условие за повторен тест е там, където живее трудността, а една подробност в редакцията е лесна за пропускане. Изисквания 11.4.2 и 11.4.3 се задействат от всяка значителна инфраструктурна или приложна надстройка или промяна. Изисквания 11.4.5 и 11.4.6 казват всякакви промени в контролите или методите за сегментация — без определителя. Прочетено буквално, прагът за повторно тестване на сегментацията е по-нисък от този за повторно тестване на всичко друго, което има смисъл, предвид какво сегментацията подпира.

Не заменяйте основанието за повторен тест на сегментацията с общ праг за значителна промяна. Дефинираното изискване се отнася до промени в контролите или методите за сегментация. Чрез change management определяйте тези промени и планирайте необходимата проверка; примерите по-долу помагат да откриете засегнатите граници, а не освобождават други промени в контролите:

• Нови или премахнати правила, позволяващи трафик през граница на сегментация.
• Въвеждане или извеждане от употреба на механизъм за сегментация.
• Замяна или голяма надстройка на налагащото устройство или платформа.
• Нови сегменти, VLAN, VRF, VPC или облачни акаунти от която и да е страна на границата.
• Нова свързаност с трети страни или допълнителни обекти.
• Промени в маршрутизацията, които биха могли да създадат път около контрола.
• Преместване на системи между сегменти в обхвата и извън обхвата.

Промяна, описана само като patch или вътрешна, също изисква оценка на въздействието: тя може да промени поведението на контрола или да създаде обход. Запишете защо сегментацията е или не е засегната и уточнете спорните случаи с оценителя. Самият етикет не създава изключение.

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

Оттам идва и въпросът за времето. Промяна в сегментацията, направена през март и тествана при годишния тест през ноември, оставя осем месеца, в които документацията ви за обхвата е заявявала нещо, което никой не е проверил. Където гранична промяна има значение, третирайте теста като част от промяната, а не като по-късна задача за съответствие.

Правилно определяне на обхвата на теста

Тестването на сегментацията се проваля на етапа на определяне на обхвата далеч по-често, отколкото на техническия етап. Текстът на изискването е изричен, че тестът покрива всички използвани контроли и методи за сегментация, затова първият резултат, който предаваме не е сканиране — той е списък. Ако контрол не е в списъка, той не е тестван, и нищо в доклада не казва друго.

Насоките на Съвета за определяне на обхвата поставят позицията: приемайте, че всичко е в обхвата, докато не бъде проверено, че контролите са налице и действително осигуряват ефективна сегментация. Те също заявяват, че всички контроли, установяващи сегментация, се включват във всяка оценка, за да се валидира ефективността им, включително онези, които ограничават връзките до конкретни портове или услуги на конкретни системи. Единицата на покритие е следователно контролът, не устройството: защитна стена не е един контрол, а всяко правило, на което разчитате, за да държите сегмент извън обхвата далеч от средата с данни на картодържателите, се нуждае от упражняване.

Избройте тези класове, преди някой да докосне терминал:

• Защитни стени и набори правила — физически, виртуални и базирани на хост. Запишете назованото правило или политика, които налага границата, не само името на хоста на устройството.
• VLAN и ACL — ACL на суичове и рутери, частни VLAN и всеки дизайн на маршрутизация (включително липсата на маршрут), който третирате като контрол.
• Облачни security groups и мрежови политики — security groups, NACL, подмрежи, таблици за маршрутизация, peering и transit gateways, и мрежови политики на Kubernetes. Допълнението на Съвета от 2024 г. за съвременните мрежови архитектури изтъква, че единично сканиране на портове от един хост извън сегмента не е достатъчно тестване тук, че политиките може да препращат към назовани ресурси, а не към адреси, и че резултатите, получени вътре в контейнеризирано натоварване, се различават от получените извън него.
• Граници на виртуализация — виртуални суичове, виртуални защитни стени и споделеният основен хост. Виртуалните устройства обикновено споделят общи ресурси, затова хипервайзорът и слоевете на оркестрация са част от границата, не декор зад нея.
• Jump хостове, брокери и проксита — всичко, което правомерно пресича границата: jump box, шлюз за отдалечен достъп, TLS прокси, sidecar, файлов брокер, пайплайн за внедряване. В разработените примери на Съвета jump box седи в споделените услуги и се третира като свързан със средата или засягащ сигурността, напълно в обхвата. Той е компонентът, най-вероятно да пренесе нападател през границата, и онзи, най-често пропускан, защото е „само“ администрация.

Превърнете този инвентар в матрица източник-към-дестинация. Всеки ред е един тест: наблюдателна точка, цел, контролът, който трябва да спре или ограничи трафика, и очакваният резултат. Планът тогава е одитируем, преди да се изпълни, а пропуските се появяват на хартия, а не по средата на оценката.

ИЗТОЧНИК (наблюдат. точка)     -->  ДЕСТИНАЦИЯ (в обхвата)     РАЗЧИТАН КОНТРОЛ             ОЧАКВАНО
corp-user-vlan-120            -->  cde-pos-10.20.0.0/24       fw-core policy "CDE-DENY"    deny all
corp-user-vlan-120            -->  shared-ad-10.30.0.5        fw-core + host firewall      389,636/tcp only
ot-print-vlan-140             -->  cde-app-10.20.1.0/24       vfw-dc01 rule 31             deny all
aws-dev-vpc / sg-dev-app      -->  aws-cde-vpc / sg-cde-web   sg-cde-web ingress           443/tcp from alb
k8s ns=build                  -->  k8s ns=cde-pay             netpol "cde-pay-deny"        deny all
vendor-vpn-pool-172.22.9.0/24 -->  cde-pos-10.20.0.0/24       vpn-gw policy "VND-3"        jump-01:3389 only
cde-pos-10.20.0.0/24          -->  corp-user-vlan-120         fw-core "CDE-EGRESS"         deny all

Тестване в двете посоки и от правилните места

Честата техническа грешка е тест, който винаги сочи само навътре: един сканиращ хост в корпоративната мрежа, стрелящ по средата с данни на картодържателите. Това доказва едно нещо за един път. То не казва нищо за другите сегменти, които сте обявили извън обхвата, нито за това какво компрометиран хост в обхвата може да достигне на връщане навън.

Тествайте от всеки сегмент извън обхвата, от който намаляването ви на обхвата зависи. Примерният доклад на Съвета показва точно тази форма: таблица на перспективите за тестване, всяка сдвояваща мрежа-източник с целевата среда. Където среда наистина има твърде много изолирани сегмента, за да бъдат покрити поотделно, насоките за тестване за проникване от 2015 г. позволяват представителна подгрупа, при условие че всяка уникална методология за сегментация се изследва и дълбочината на тестването дава увереност, че е ефективна във всички случаи на употреба. Това позволява извадка на наблюдателни точки с обосновка, не на типове контроли. Запишете защо тези сегменти представят останалите.

Изходящите редове заслужават мястото си, защото разрешаващият изходящ трафик и пътищата за връщане са начинът, по който една опорна точка се превръща в маршрут за ексфилтрация. После има пътищата, които минават около очевидната граница, а не през нея:

• Мрежи за управление. Управление извън канала, интерфейси на хипервайзора, управляващи слоеве на устройствата и облачната конзола или контролен слой. Допълнението за съвременните архитектури иска от тестерите да обмислят сценарии, които атакуват конзолата или контролния слой, за да променят конфигурация и да победят контрола за сегментация — най-бързият маршрут в сегмент често е промяна на правилото, което го определя.
• Архивиране и наблюдение. Агенти за архивиране, инструменти за наблюдение и сканиране, сървъри за внедряване на актуализации за сигурност и антивирус. Съветът изброява тези сред честите споделени услуги, в обхвата, където се свързват със средата с данни на картодържателите. Те също така обикновено държат широки данни за достъп.
• Споделени директорийни услуги. Active Directory, LDAP, AAA, DNS, NTP и поща. Съветът отбелязва, че администраторски акаунт, компрометиран в мрежа извън обхвата, не бива да е използваем за достигане на средата с данни на картодържателите, и че свързаността за удостоверяване трябва да бъде ограничена до бизнес нуждата. Граница, през която унаследени данни за достъп минават право, не е граница.
• Отдалечен достъп на доставчици. VPN пулове на трети страни, инструменти за поддръжка и jump пътища на доставчици. За хибридни среди насоките питат как нападател би могъл да заобиколи шлюз за отдалечен достъп — атакувайки шлюза пряко, атакувайки системата за осигуряване като Active Directory или IAM, или имитирайки привилегирован потребител.

Какво трябва да покаже доказателството

Оценителите се различават, но доказателството, което оцелява при преглед, следва структурата на отчитане в насоките на Съвета за тестване за проникване: обхват, методология, ограничения, разказ за тестването, отделно резюме на резултатите за сегментацията и констатации. На практика:

• Дати — кога е извършено тестването, не само кога е издаден документът, така че честотата да може да се провери спрямо предишния тест и спрямо промените в контролите за сегментация.
• Обхват и списъкът със сегментите — средата в обхвата и сегментите, претендирани като извън обхвата. Насоките искат изрично уточнение на CDE спрямо не-CDE системи и разгледани сегменти.
• Методология — какво е направено и как, обвързано с документираната ви методология за тестване за проникване, плюс всяко наложено ограничение: прозорци, ограничения на честотната лента, изключени остарели системи.
• Източник и дестинация за всеки тест — матрицата, възпроизведена с резултати. Това е най-полезната страница в доклад за сегментацията.
• Резултат за всеки контрол — преминал или провален спрямо всеки назован контрол за сегментация, не глобална присъда.
• Отстраняване и повторен тест — използваемите уязвимости и слабости в сигурността, намерени по време на тестването за проникване, трябва да бъдат коригирани и тестването повторено, за да провери корекциите. Насоките скицират доклад за повторен тест, носещ първоначалната дата на теста, датата на повторния тест, първоначалните констатации и резултатите от повторния тест.

Подкрепящото доказателство означава екранни снимки, суров изход от инструменти, прихващания и извлечения от конфигурации. Съхранението само по себе си не е изискване на PCI DSS, но Съветът го препоръчва и очаква съхранението и унищожаването да бъдат съгласувани предварително — уредете го в правилата за ангажимента.

Доказателството обикновено се отхвърля по една причина: изход от инструменти без съпоставяне с назовани контроли за сегментация. Сканиране на портове от неуточнен хост, показващо филтрирани портове спрямо диапазон адреси, не установява кой контрол е филтрирал трафика, дали всеки контрол от този тип се държи по същия начин, или дали тази наблюдателна точка представя сегментите, които изключвате. Ако читателят не може да проследи линия от „VLAN 140 не може да достигне средата с данни на картодържателите“ до правилото, което я налага, и теста, който я доказа, документът е доклад от сканиране, не тест на сегментацията.

Къде тестването на сегментацията се обърква

Повтарящите се модели са малко, а повечето са организационни, а не технически:

• Извадка, където се изисква покритие. Намаляването на броя наблюдателни точки е документирано, обосновано решение за сегментите. Тихото прескачане на тип контрол — облачни security groups, мрежови политики, хост защитни стени — не е извадка, то е пропуск.
• Тестване на представителна защитна стена. Едно устройство се тества, останалите устройства се приемат за идентични, а допускането никога не се записва или проверява. Отклонението на конфигурацията е рутинно.
• Пропускане на по-кратката честота, където се прилага. Организации, които са променили статуса си, или които предоставят услуги на други, без да мислят за себе си като доставчик на услуги, обикновено откриват шестмесечния цикъл късно.
• Игнориране на промени през годината. Изискването важи също и след промени в контролите или методите за сегментация. Допълнението за съвременните архитектури предупреждава, че дори прости изменения в дефиниция на инфраструктура-като-код могат неволно да премахнат контрол за сегментация, и че контролите трябва да бъдат проверени и документирани като непокътнати след всяка промяна, засягаща ги.
• Откриване на път, отстраняване на проблема и пропускане на повторния тест. Затворена заявка не е доказателство. Насоките също отбелязват, че където привидно изолиран сегмент се окаже с достъп до средата с данни на картодържателите, опциите са да се ограничи този достъп или да се изпълни пълен тест за проникване на мрежовия слой, за да се оцени реалният му риск — сегментът може никога да не е бил извън обхвата.
• Третиране на чисто сканиране като теста. Сканирането и тестването за проникване на сегментацията отговарят на различни въпроси. Чисто сканиране не казва нищо за това дали граница може да бъде победена.

Вместване в годишния цикъл

Три навика правят това рутинно, а не събитийно.

Дръжте инвентара на сегментите като жив документ. Той е същият артефакт, от който потвърждението ви на обхвата зависи, затова го поддържайте наред с мрежовите диаграми и диаграмите на потока от данни, вместо да го изграждате наново всяка година по памет. Той трябва да назовава всеки контрол за сегментация, неговия собственик и сегментите от двете страни. За облачни среди, където натоварванията са ефимерни, Съветът предлага инструменти за автоматизиран инвентар и база данни за управление на конфигурациите, за да се върви в крак.

Тествайте сегментацията преди основната оценка, не наред с нея. Оставете място да поправите това, което тестът намери, и да го тествате повторно. Провал на сегментацията, намерен по време на оценка, не е просто констатация — той може да вкара цял сегмент в обхвата и да промени самата оценка. Намерен тримесечие по-рано, той е заявка за промяна. Това е практическият довод да изпълните това като отделна част от тестване за проникване, водено от съответствие, със собствени дати и собствен доклад, вместо да го свивате в общ вътрешен тест.

Свържете го с управлението на промените. Нов VLAN, security group, мрежова политика, peering връзка или път за достъп на доставчик трябва да задейства документирана проверка спрямо инвентара и, където изменя контрол за сегментация, тест. Насоките препоръчват управление на промените, което автоматично идентифицира изменения в контролите за сегментация като IAM или мрежова конфигурация, подкрепено от превантивни и откриващи проверки. Проверка в пайплайна, която проваля билд, когато правило, налагащо граница, се промени, ще намери повече от всяко упражнение веднъж годишно.

Направено така, тестът потвърждава това, което вече знаете. Направено по другия начин, то е упражнение за откриване с прикачена дата за одит.