Att säga att en extern tjänsteleverantör är ”PCI-kompatibel” är inte en slutsats, utan utgångspunkten för ytterligare granskning.

För många organisationer innebär tredjepartsgranskning fortfarande att man skaffar ett intyg om efterlevnad (AOC), sparar det i ett arkiv och antar att ingen ytterligare granskning krävs. PCI DSS kräver dock mer än bara bevis på att en leverantör vid någon tidpunkt har genomfört en bedömning.

Ni måste fastställa om leverantören omfattas av kraven, vilka tjänster som har bedömts, vilka ansvarsområden leverantören har åtagit sig, om valideringen fortfarande är giltig och om bevisningen faktiskt stöder de tjänster som er organisation använder.

PCI PCI Security Standards Council har klargjort hur tredjepartsleverantörer ska omfattas, valideras och dokumenteras under en PCI DSS-bedömning. Vägledningen lyfter fram en viktig punkt: leverantörer behöver inte lagra, behandla eller överföra kontouppgifter för att omfattas av tillämpningsområdet. De kan också omfattas av tillämpningsområdet eftersom deras tjänster bidrar till att uppfylla PCI DSS-kraven eller kan påverka säkerheten i kortinnehavardatamiljön.

Detta har betydande konsekvenser för handlare, tjänsteleverantörer och granskare.

 

 

Vad är en extern tjänsteleverantör enligt PCI DSS?

I samband med en kunds PCI DSS-bedömning är en relation med en extern tjänsteleverantör relevant när leverantören tillhandahåller tjänster som:

• lagrar, behandlar eller överför kontouppgifter på kundens vägnar;
• hanterar system eller kontroller som kunden använder för att uppfylla ett eller flera PCI DSS-krav;
• kan påverka säkerheten för kundens kontouppgifter eller kortinnehavarens datamiljö.

Det är i den tredje punkten som organisationer ofta underskattar sin omfattning.

En leverantör behöver inte se ett primärt kontonummer (PAN) för att påverka säkerheten kring detta. En leverantör av hanterade säkerhetstjänster, molnleverantör, identitetsleverantör, webbhotell, leverantör av applikationshantering eller leverantör av fjärrsupport hanterar kanske inte betalningsdata direkt, men dess åtkomst eller tjänster kan ändå påverka säkerheten för system som omfattas av tillämpningsområdet.

Detta innebär att den rätta frågan inte bara är:

Hanterar denna leverantör kortuppgifter?

Utan:

Kan denna leverantörs system, personal, åtkomst eller tjänster påverka säkerheten för kontouppgifter eller hjälpa oss att uppfylla ett PCI DSS-krav?

Om svaret är ja måste de relevanta tjänsterna, åtkomstvägarna, systemberoendena och de ansvarsområden som hanteras av leverantören beaktas i kundens PCI DSS-omfattning och bedömning.

Varför ”PCI-kompatibel” inte är ett tillräckligt svar

Efterlevnaden av PCI DSS gäller för ett definierat tillämpningsområde, en viss tjänst och en viss tidsperiod.

En leverantör kan driva flera produkter, plattformar eller tjänsteutbud. Dess intyg om efterlevnad (AOC) kan omfatta en av dessa, men inte den tjänst som din organisation använder. Det bedömda tillämpningsområdet kan vara begränsat till specificerade juridiska enheter, tjänster, miljöer, platser, regioner eller leveransmodeller, enligt vad som dokumenteras i AOC och kompletterande bedömningsmaterial.

Uttalandet ”vår leverantör uppfyller PCI-kraven” säger i sig väldigt lite.

Du måste fortfarande fastställa:

• Vilken juridisk person som har granskats
• Vilka tjänster och platser som ingick
• Vilken version av PCI DSS som användes
• Datum för slutförande av granskningen
• Om AOC fortfarande är giltigt
• Vilka PCI DSS-ansvar som tilldelas leverantören, kunden eller båda parter; och
• Om den tjänst som levereras till er organisation överensstämmer med den tjänst som beskrivs i AOC.

Utan en sådan analys kan ett AOC skapa ett falskt förtroende.

En organisation kan ha ett giltigt dokument samtidigt som den förlitar sig på en tjänst som ligger utanför leverantörens bedömda omfattning.

Hur kan en tjänsteleverantör verifiera efterlevnaden av PCI DSS?

En extern tjänsteleverantör har i allmänhet två sätt att validera sina PCI DSS-ansvar.

Årlig PCI DSS-validering

Leverantören kan genomföra en årlig PCI DSS-granskning och förse kunderna med lämpliga bevis, vanligtvis ett AOC.

Beroende på valideringskraven kan leverantören genomföra:

• Ett SAQ D för tjänsteleverantörer
• En rapport om efterlevnad som upprättats tillsammans med en kvalificerad säkerhetsbedömare

Detta är vanligtvis den enklaste vägen för kunderna eftersom leverantören redan har fastställt sitt tillämpningsområde, utvärderat de tillämpliga kontrollåtgärderna och dokumenterat resultatet.

Kunden måste dock fortfarande granska AOC noggrant. Att ta emot dokumentet innebär inte att man slipper bekräfta att det täcker den relevanta tjänsten.

Bedömning genom kundens ROC

Om leverantören inte har genomfört sin egen årliga bedömning kan denne delta i en kunds PCI DSS-bedömning.

Leverantören måste ställa tillräckliga bevis, personal, system och processer till förfogande för att kundens bedömare ska kunna utföra de tillämpliga PCI DSS-testförfarandena och nå en underbyggd slutsats. Leverantörens ansvar utvärderas sedan som en del av kundens efterlevnadsrapport (ROC). Detta är inte en enkel försäkran från leverantören. Det kräver detaljerad dokumentation och tester utförda av utvärderaren. Det är inte heller ett alternativ som är tillgängligt för alla handlare.

Kan en SAQ-handlare inkludera en leverantör i sin egen bedömning?

En handlare kan inte använda sin egen SAQ för att validera den interna PCI DSS-efterlevnaden hos en icke-validerad tjänsteleverantör. Handlarens SAQ omfattar handlarens berättigade miljö och de krav som gäller för just den handlaren.

Handlaren bör inte vara skyldig att:

• Fastställa leverantörens PCI DSS-omfattning
• Besluta vilka krav som gäller för leverantören
• Granska leverantörens interna underlag
• Genomföra en egenbedömning av leverantörens kontrollmiljö

En leverantör som betjänar en SAQ-handlare förväntas validera sin egen efterlevnad genom ett SAQ D för tjänsteleverantörer eller ett ROC.

När en leverantör utan egen validering därför säger till en SAQ-handlare att denne helt enkelt kan ”omfattas av kundens bedömning”, bör handlaren ifrågasätta den ståndpunkten.

Metoden att införliva leverantörens kontroller i kundens bedömning gäller för organisationer som fyller i en ROC och väljer att bedöma dessa leverantörsansvar direkt. Det är inte ett allmänt alternativ till validering av tjänsteleverantörer.

 

 

Vad bör man kontrollera i ett PCI DSS-AOC?

Ett intyg om efterlevnad är ett viktigt bevis, men endast om det granskas ordentligt.

Det räcker inte att kontrollera leverantörens namn och datumet för när bedömningen slutfördes. Din due diligence bör bekräfta att AOC:n gäller just den tjänsten, miljön och relationen i fråga.

Bekräfta den bedömda enheten

Kontrollera att den juridiska enhet som anges på AOC är den enhet som tillhandahåller din tjänst.

Stora koncerner kan bedriva verksamhet genom flera dotterbolag. En bedömning av moderbolaget omfattar inte automatiskt alla dotterbolag eller regionala verksamheter.

Kontrollera att tjänsten ingår

Granska beskrivningen av de bedömda tjänsterna.

Leverantören kan erbjuda flera molnmiljöer, värdtjänster, betalningsprodukter eller hanterade tjänster. AOC:n måste omfatta just den tjänst som du använder, inte bara en annan tjänst som tillhandahålls av samma företag.

Kontrollera bedömningsdatumet

PCI DSS-valideringen är inte permanent.

Ett AOC bör inte förvaras i arkivet på obestämd tid utan att man har kontrollerat om leverantörens PCI DSS-efterlevnadsstatus fortfarande är aktuell och om uppdaterad valideringsdokumentation finns tillgänglig.

Kontrollera PCI DSS-versionen

Kontrollera vilken version av PCI DSS som användes vid leverantörens bedömning.

Detta hjälper till att avgöra om leverantörens validering baseras på den tillämpliga versionen av PCI DSS och är lämplig för kundens bedömnings- och rapporteringsperiod.

Granska informationen om ansvar

Avtalet och den tillhörande dokumentationen bör tydligt ange vilka PCI DSS-krav som:

• Leverantörens ansvar
• Kundens ansvar
• delas mellan båda parter

Ett AOC överför inte allt ansvar till leverantören. Kunderna förblir ansvariga för att förstå och sköta sin del av kontrollmiljön.

Hur ska tredjepartsleverantörer redovisas i en ROC?

Varje leverantör som uppfyller PCI DSS-kriterierna för tillämpningsområde ska dokumenteras i avsnitt 4.4 i rapporten om efterlevnad.

Detta inkluderar leverantörer som:

• lagrar, behandlar eller överför kontouppgifter
• hanterar system inom kortinnehavardatamiljön
• Tillhandahåller tjänster som används för att uppfylla PCI DSS-kraven
• Kan påverka säkerheten för kontouppgifter

I tillämpliga fall bör leverantörens tjänster, anslutningar, åtkomst och beroenden också återspeglas i de avsnitt i ROC som behandlar omfattning, systemkomponenter, nätverksanslutningar, segmentering, dataflöden och bedömda platser.

Det viktiga är konsekvens.

De leverantörer som anges i ROC bör överensstämma med:

• De system och tjänster som ingår i tillämpningsområdet
• Organisationens dataflödesdiagram
• dess nätverksdiagram
• Organisationens inventering av tredjepartstjänster
• Skriftliga avtal
• Ansvarstabeller
• Det bevismaterial som granskats under utvärderingen

En leverantör bör inte förekomma i ett dokument men saknas i de övriga.

Vad innebär ”på plats” när det gäller krav som hanteras av leverantören?

När en extern leverantör ansvarar för ett PCI DSS-krav kan kravet rapporteras som ”på plats”.

Men den slutsatsen kräver underbyggande bevis.

Bedömningsdokumentationen bör ange:

• Den leverantör som ansvarar för kravet
• Det skriftliga avtalet som tilldelar detta ansvar
• Det AOC som granskats av bedömare
• AOC-datum och PCI DSS-version
• Resultatet av leverantörens bedömning
• Bekräftelse på att AOC:n omfattar den tjänst som kunden använder
• De bedömningsförfaranden som ligger till grund för slutsatsen

”In Place” är inte en förkortning för ”leverantören sa till oss att det var i enlighet med kraven”.

Det är en dokumenterad bedömningsslutsats som stöds av avtal, valideringsbevis och tester.

Om dessa element saknas kan slutsatsen kanske inte försvaras.

Vad kräver PCI DSS-krav 12.8?

Krav 12.8 i PCI DSS behandlar hur organisationer hanterar externa tjänsteleverantörer som har tillgång till kontouppgifter eller som kan påverka säkerheten kring dessa.

Det kräver att organisationer upprätthåller en kontinuerlig övervakning av relationen, istället för att betrakta leverantörens försäkran som en årlig dokumentinsamlingsövning.

Upprätthåll en fullständig förteckning över leverantörer

Krav 12.8.1 kräver en förteckning över relevanta externa tjänsteleverantörer, inklusive en beskrivning av de tjänster som varje leverantör tillhandahåller.

Förteckningen ska återspegla den aktuella situationen vad gäller kortinnehavarnas uppgifter. Den ska uppdateras när tjänster införs, ändras eller tas ur bruk.

Upprätta skriftliga avtal

Krav 12.8.2 kräver skriftliga avtal med berörda leverantörer.

Dessa avtal ska bekräfta leverantörens ansvar för att skydda kontouppgifter eller för de PCI DSS-krav som denne hanterar på kundens vägnar.

Vaga avtalsformuleringar kan leda till osäkerhet om vem som är ansvarig för vissa kontroller.

Genomför en due diligence-granskning innan samarbetet inleds

Krav 12.8.3 föreskriver att organisationer ska upprätthålla en process för anlitande av tjänsteleverantörer, inklusive lämplig due diligence innan samarbetet inleds.

Hänsyn till PCI DSS bör därför ingå i upphandlings- och introduktionsprocessen, och inte endast behandlas när den årliga bedömningen inleds.

Innan ett avtal undertecknas bör organisationer ha kunskap om följande:

• Om leverantören omfattas av kraven
• Hur leverantören validerar efterlevnaden av PCI DSS
• Vilka bevis leverantören kommer att tillhandahålla
• Vilka kontroller leverantören kommer att genomföra
• Vilka ansvar som kvarstår hos kunden
• Hur förändringar av tillämpningsområdet eller efterlevnadsstatusen kommer att kommuniceras

Omfattningen av due diligence-granskningen bör stå i proportion till tjänsten, åtkomsten, de uppgifter som hanteras, tekniska beroenden och den potentiella inverkan på CDE.

Var brister i tredjeparts efterlevnad av PCI DSS vanligtvis uppstår

De flesta brister hos tredjeparter beror inte på att organisationerna saknar dokumentation helt och hållet.

De beror på att dokumentationen verkar tillräcklig tills någon granskar den noggrant.

Leverantörens validering är inte längre aktuell

Ett äldre AOC finns kvar i efterlevnadsarkivet, men ingen har kontrollerat om leverantören har genomfört sin senaste bedömning.

AOC:n avser en annan tjänst

Dokumentet är giltigt, men det avser en annan produkt, en annan värdmodell, en annan plats, en annan region eller en annan juridisk person.

Leverantörens inventarium är inaktuellt

Organisationens lista över tredjepartsleverantörer stämmer inte längre överens med dess nuvarande system, integrationer, betalningsflöden eller molntjänster.

Ansvarsfördelningen är oklar

Kunden utgår från att leverantören sköter en kontroll, medan leverantörens dokumentation anger att kunden fortfarande är ansvarig.

Resultaten av ”In Place”-granskningen saknar beviskedja

Krav markeras som ”In Place” enbart utifrån leverantörens rapporterade status, utan att den aktuella tjänsten, ansvarsfördelningen, valideringsbevis eller tester som stöder slutsatsen identifieras.

En SAQ-handlare försöker bedöma leverantören

Leverantören har ingen oberoende validering och förväntar sig att handlaren ska inkludera leverantörens kontroller i en SAQ, trots att handlaren inte är ansvarig för att bedöma leverantörens miljö.

Dessa brister förblir ofta dolda tills den formella bedömningen pågår. I det skedet kan det innebära att man måste jaga leverantörer, granska avtal, omdefiniera omfattningen och samla in bevis under betydande tidspress för att åtgärda dem.

Hur man stärker due diligence-processen för tredje part enligt PCI DSS

En effektiv hantering av tredjeparter kräver en repeterbar process som sammanför inköps-, juridik-, informationssäkerhets-, betalnings- och efterlevnadsteamen.

Börja med att skapa en fullständig förteckning över leverantörer som antingen hanterar kontouppgifter eller som kan påverka säkerheten kring dessa. Koppla varje leverantör till den tjänst som denne tillhandahåller, de system som denne har åtkomst till samt de relevanta PCI DSS-kraven.

För varje leverantör som omfattas av kraven ska du inhämta aktuella valideringsbevis och bekräfta att de täcker den tjänst du använder. Dokumentera vilka kontroller leverantören hanterar och vilka som fortfarande är ditt ansvar.

Denna granskning bör inte genomföras en gång och sedan glömmas bort. Leverantörernas tjänster förändras. Avtal ändras. Plattformar migreras. En leverantör kan ändra sitt bedömda tillämpningsområde eller ersätta en tjänst med en annan.

En välutvecklad process omfattar därför:

• Due diligence före uppstart
• Avtalsenlig ansvarsfördelning
• Inledande granskning av PCI DSS-bevis
• Regelbundna kontroller av AOC:s giltighet
• Omprövning efter väsentliga förändringar i tjänsten
• Fastställda eskaleringsrutiner vid saknade eller otillräckliga bevis
• Borttagning av leverantörer som upphört med sin verksamhet från PCI DSS-omfattningen och inventariet

Syftet är inte enbart att samla in dokument. Det handlar om att fastställa att leverantörens kontroller, ansvarsområden och validering stöder er egen efterlevnad av PCI DSS.

Hur Integrity360 kan hjälpa till

Tredjepartsleverantörer kan avsevärt komplicera avgränsningen och bedömningen av PCI DSS, särskilt när ansvaret är fördelat mellan flera leverantörer, plattformar och interna team.

Integrity360:s specialister på betalningsregelefterlevnad kan hjälpa organisationer att:

• Identifiera tredjeparter som omfattas av PCI DSS
• Granska AOC:er och underlag som styrker efterlevnaden
• Bekräfta om valideringen omfattar de tjänster som utnyttjas
• Att utvärdera ansvarsmatriser och avtalsvillkor
• Sammanställ information om TPSP:s tillämpningsområde, ansvar och underlag för att inkluderas i en ROC
• Granska processer som stöder krav 12.8
• Identifiera brister i bevisningen innan den formella bedömningen inleds
• Upprätta ett mer hållbart program för efterlevnad av PCI DSS

Integrity360 har tillhandahållit tjänster för bedömning av betalningssäkerhet sedan 2009 och stödjer organisationer när det gäller kraven inom PCI DSS, 3DS, P2PE, Secure Software Framework, Token Service Provider, PIN-säkerhet samt korttillverkning och kortutfärdning.

Nöj dig inte med att bara vara ”PCI-kompatibel”

En leverantörs PCI DSS-status är viktig, men den kan inte accepteras utan sammanhang.

Du måste veta vad som har granskats, när det granskades, vilka tjänster som ingick och om leverantörens ansvar tydligt stöds av avtal och bevis.

Det är bra att ha ett AOC i arkivet.

Ett AOC som är aktuellt, relevant och tillämpligt på rätt tjänst kan stödja en försvarbar PCI DSS-bedömning när det beaktas tillsammans med ansvarsfördelningen, avtalsenliga åtaganden, kontroller på kundsidan och tillämpliga testbevis.

Kontakta Integrity360 för att granska omfattningen av era tredjepartsleverantörer, validera era bevis och förbereda er inför er nästa PCI DSS-bedömning.