Sedan 2005 har drygt 11 miljarder konsumentuppgifter exponerats vid drygt 8 500 dataintrång. Det här är de senaste siffrorna från The Privacy Rights Clearinghouse, som rapporterar om dataintrång och säkerhetsintrång som påverkar konsumenter från 2005 och framåt.
För att förbättra säkerheten för konsumentdata och förtroendet för betalningsmiljön har en minimistandard för datasäkerhet skapats. Visa, Mastercard, American Express, Discover och JCB bildade 2006 Payment Card Industry Security Standards Council (PCI SSC) för att administrera och hantera säkerhetsstandarder för företag som hanterar kreditkortsuppgifter. Innan PCI SSC etablerades hade de här fem kreditkortsföretagen alla sina egna program för säkerhetsstandarder – vart och ett med i stort sett liknande krav och mål. De gick samman i PCI SSC för att enas om en standardpolicy, PCI Data Security Standards (känd som PCI DSS), och säkerställa en grundnivå av skydd för konsumenter och banker i internettidsåldern.
Det kan vara komplicerat och utmanande att förstå PCI DSS
Om din affärsmodell innebär att du måste hantera kortdata kan du behöva uppfylla var och en av de drygt 300 säkerhetskontrollerna i PCI DSS. Det finns mer än 1 800 sidor officiell dokumentation, som publiceras av PCI Council, om PCI DSS, och drygt 300 sidor som beskriver vilka formulär som ska användas för att validera efterlevnaden. Det skulle ta mer än 72 timmar att bara läsa allt detta.
För att göra bördan lättare följer här en vägledning steg-för-steg för hur du validerar och upprätthåller efterlevnad av PCI.
PCI DSS version 4.0 träder i kraft den 31 mars 2024
Allmän information om PCI Data Security Standard (PCI DSS)
PCI DSS är den globala säkerhetsstandarden för alla enheter som lagrar, hanterar eller överför kortdata och/eller känsliga autentiseringsuppgifter. PCI DSS sätter en grundläggande standard avsedd att skydda konsumenter och hjälper till att förebygga bedrägeri och informationsläckage i hela betalningsekosystemet. Standarden tillämpas på alla organisationer som tar emot eller hanterar betalningskort.
PCI DSS-efterlevnad involverar tre huvudkomponenter:
- Hantering av kundens kreditkortsdata, dvs. att känslig kortinformation samlas in och överförs på ett säkert sätt
- Säker datalagring, uppdelat på 12 säkerhetsdomäner i PCI-standarden, däribland kryptering, pågående övervakning och säkerhetsprovning av åtkomst till kortdata
- Årlig validering avsedd att säkerställa att de obligatoriska säkerhetskontrollerna är på plats, vilket kan inkludera formulär, undersökningar, externa skanningstjänster och tredjepartsrevisioner (den detaljerade guiden nedan innehåller en tabell över de fyra kravnivåerna)
Hantering av kortdata
En del affärsmodeller kräver att man hanterar känsliga kortuppgifter direkt, medan andra inte gör det. Företag som måste hantera kortdata (t.ex. för att godkänna icke-tokeniserade kortnummer på en betalningssida) kan behöva uppfylla samtliga 300+ säkerhetskontroller i PCI DSS. Fastän kortdata vistas en mycket kort tid på företagets servrar måste det ändå köpa in, implementera och underhålla säkerhetsprogram och hårdvara.
Om ett företag inte måste hantera känsliga kortdata är det något att undvika. Tredjepartsleverantörer (t.ex. Stripe Elements) tar emot och lagrar data i en säker miljö och minskar därmed komplexiteten, kostnaden och risken förknippad med dessa korttransaktioner. Eftersom kortinformationen aldrig ligger på deras servrar måste företaget bara klara av några få säkerhetskontroller, varav de flesta är relativt oproblematiska (t.ex. att använda starka lösenord).
Säker datalagring
Om en organisation hanterar eller lagrar kreditkortsdata måste den definiera omfattningen på sin kortdatamiljö (CDE). PCI DSS definierar CDE som de människor, processer och tekniska lösningar som lagrar, behandlar eller överför kreditkortsdata – plus eventuella system med koppling till dessa. Eftersom alla 300 säkerhetskraven i PCI DSS tillämpas på CDE är det viktigt att separera betalningsmiljön från resten av verksamheten för att på så sätt kunna begränsa omfattningen av PCI-valideringen. Om en organisation skulle misslyckas med att separera kortdatamiljön kommer alla den organisationens system, bärbara datorer och enheter på företagsnätverket att omfattas av PCI-efterlevnaden. Ajaj!
Årlig validering
Oavsett hur kortdata erhålles måste organisationer fylla i ett PCI-formulär en gång per år. Hur PCI-efterlevnaden valideras beror på ett antal olika faktorer, se nedan för mer information. Här följer tre scenarion i vilka en organisation skulle kunna bli ombedd att visa att den uppfyller gällande PCI-krav:
- Betalleverantörer kan komma att be om det som en del av sin obligatoriska rapportering till kortnätverken.
- Samarbetspartner kan komma att be om det som en förutsättning för att ingå ett affärsavtal.
- Kunder kan komma att begära det av plattformsföretag (dvs. företag vars tekniska lösning möjliggör digitala transaktioner mellan separata användargrupper) för att själva kunna visa sina kunder att de hanterar deras data i en säker miljö.
PCI DSS-säkerhetsstandarderna inkluderar 12 huvudkrav med över 300 underkrav som speglar ledande praxis på säkerhetsområdet.
UTVECKLA OCH UNDERHÅLL SÄKRA NÄTVERK OCH SYSTEM
- 1. Installera och underhåll nätverkssäkerhetskontroller.
- 2. Konfigurera alla systemkomponenter på ett säkert sätt.
SKYDDA KONTODATA
- 3. Skydda data som lagras om kortinnehavare.
- 4. Skydda data om kortinnehavare med stark kryptografi vid överföring över öppna, offentliga nätverk.
UPPRÄTTA OCH UNDERHÅLL EN POLICY FÖR RISKBASERAD HANTERING AV HOT OCH SÄKERHETSRISKER
- 5. Skydda alla system och nätverk mot skadlig programvara.
- 6. Utveckla och underhåll säkra system och säker programvara.
IMPLEMENTERA STRIKT ÅTKOMSTKONTROLL
- 7. Begränsa åtkomst till systemkomponenter och data om kortinnehavare till berörda parter.
- 8. Identifiera användare och autentisera åtkomst till systemkomponenter.
- 9. Begränsa fysisk åtkomst till data om kortinnehavare.
ÖVERVAKA OCH TESTA NÄTVERKEN REGELBUNDET
- 10. Spåra och övervaka all åtkomst till systemkomponenter och data om kortinnehavare.
- 11. Testa regelbundet systemens och nätverkens säkerhet.
UPPRÄTTA OCH UNDERHÅLL EN INTEGRITETSPOLICY
- 12. Upprätta policyer och rutiner inom organisationen som främjar integriteten.
För att göra det "lättare" för nya företag att validera sin PCI-efterlevnad har PCI Council tagit fram nio olika så kallade självbedömningsformulär (SAQ:er) som utgör en undergrupp till det övergripande PCI DSS-kravet. Tricket ligger i att identifiera vilket formulär som gäller för ditt företag och huruvida det är nödvändigt att anlita en PCI Council-godkänd revisor för att verifiera att samtliga PCI DSS-krav har uppfyllts. Än mer komplicerat blir det av att PCI Council justerar dessa regler var tredje år samt släpper mindre uppdateringar flera gånger om året.
Steg för steg-guide till efterlevnad av PCI DSS
1. Ta reda på vilka krav som gäller för dig
Det första steget mot efterlevnad av PCI är att veta vilka krav som gäller för din organisation. Det finns fyra olika nivåer för efterlevnad av PCI, som vanligtvis baseras på volymen kreditkortstransaktioner ditt företag hanterar under en period på 12 månader.
Efterlevnadsnivå
|
Gäller för
|
Krav
|
---|---|---|
Nivå 1
|
|
|
Nivå 2
|
|
|
Nivå 3
|
|
|
Nivå 4
|
|
|
För nivå 2–4 finns det olika SAQ-typer beroende på din integreringsmetod för betalningar. Här är en kortfattad tabell:
Integration
|
Krav
|
Rekommendation
|
---|---|---|
Checkout eller Elements
|
SAQ A |
All inmatning av inhämtade kortuppgifter baseras på Checkout och Stripe.js och Elements inom en iframe som ligger på Stripes domän (och inte på din). På så sätt passerar dina kunders kortuppgifter aldrig dina servrar.
|
Connect
|
SAQ A | Om du enbart inhämtar kortuppgifter via en Connect-plattform (exempelvis Squarespace) kan vi fastställa huruvida plattformen tillhandahåller nödvändig PCI-dokumentation. |
Mobil SDK
|
SAQ A |
Stripes utveckling och ändringskontroll för mobilt SDK uppfyller PCI DSS-kraven (krav 6.3–6.5) och implementeras via våra PCI-validerade system. När du enbart använder gränssnittskomponenter från våra officiella SDK:er för iOS eller Android, eller bygger ett betalningsformulär med Elements i en WebView, skickas kortnummer direkt från dina kunder till Stripe. Därmed minskar dina arbetsinsatser för att uppfylla PCI-kraven. Om du gör på något annat sätt, exempelvis skriver din egen kod för att hantera kortuppgifter, kan du behöva uppfylla ytterligare PCI DSS-krav (6.3–6.5) och är inte behörig för en SAQ A. Prata med en PCI QSA för att ta reda på hur du på bästa sätt validerar att du uppfyller kraven enligt gällande vägledning från PCI Security Standards Council. Om din ansökan kräver att dina kunder anger sina uppgifter på sina egna enheter då uppfyller du kraven för SAQ A. Om din ansökan tar emot kortuppgifter för flera kunder på din enhet (exempelvis en betalapp) ska du rådgöra med en PCI QSA för att ta reda på hur du på bästa sätt validerar att du uppfyller PCI-kraven. |
Stripe.js v2
|
SAQ A-EP |
Om du använder Stripe.js v2 för att skicka kortuppgifter som angetts i ett formulär på din webbplats, som finns på en egen server, måste du fylla i SAQ A-EP varje år för att visa att ditt företag uppfyller PCI-kraven. Både Checkout och Elements erbjuder dig samma flexibilitet och anpassningsbarhet som ett formulär på en egen server, samtidigt som du uppfyller PCI-kraven för SAQ A. |
Terminal
|
SAQ C |
Om du enbart inhämtar kortuppgifter via Stripe Terminal kan du validera med hjälp av SAQ C. Om du integrerar med Stripe med hjälp av andra metoder som anges i denna tabell måste du visa att du uppfyller kraven för var och en av dem i enlighet med beskrivningen. |
Dashboard
|
SAQ C-VT |
Manuella kortbetalningar via Dashboard är endast möjliga under särskilda omständigheter – och inte vid rutinmässig behandling av betalningar. Tillhandahåll ett lämpligt betalningsformulär eller en mobilapp där dina kunder kan ange sina kortuppgifter. Vi kan inte verifiera att manuellt inmatade kortuppgifter är skyddade utanför Stripe. Därför måste du skydda kortuppgifter i enlighet med kraven för PCI-efterlevnad och fylla i SAQ C-VT varje år för att visa att ditt företag uppfyller PCI-kraven. |
Direct API
|
SAQ D |
När du skickar kortuppgifter direkt till Stripes API hanterar din integration dessa data direkt och du måste årligen visa att du uppfyller PCI-kraven med hjälp av SAQ D – den mest krävande av alla SAQ:er. Du kan minska arbetsbelastningen genom:
Dessutom är Radar, vårt verktyg för förebyggande av bedrägerier som inkluderar riskbedömning och regler, endast tillgängligt när man använder någon av våra metoder för tokenisering på klientsidan. |
2. Kartlägg dina dataflöden
Innan du kan skydda känsliga kortdata måste du veta var de bor och hur de tar sig dit. Vi rekommenderar att du tar fram en detaljerad karta över de system, nätverksanslutningar och applikationer som kommunicerar med kreditkortsdata i din organisation. Beroende på din arbetsroll kan du behöva samarbeta med IT- och säkerhetsteamen för att åstadkomma detta.
- Börja med att identifiera samtliga av företagets kundinriktade områden som involverar betalningstransaktioner. Företaget kanske tar emot betalningar via digitala kundvagnar, betalningsterminaler i fysisk miljö eller beställningar per telefon.
- Identifiera därefter hur data om kortinnehavare hanteras på företaget. Det är viktigt att veta exakt var uppgifterna lagras och vem som har åtkomst till dem.
- Sen är det dags att identifiera de interna system eller den underliggande teknik som är involverade i betalningstransaktionerna. Detta inkluderar nätverkssystem, datacentraler och molntjänster.
3. Kontrollera säkerhetskontroller och protokoll
När du har kartlagt alla potentiella beröringspunkter för kreditkortsdata i din organisation kan du samarbeta med IT- och säkerhetsteamen för att se till att rätt säkerhetskonfigurationer och protokoll är på plats (se listan med 12 säkerhetskrav för PCI DSS ovan). Dessa protokoll är utformade för att säkra överföringen av data, som till exempel Transport Layer Security (TLS).
De 12 säkerhetskraven för PCI DSS har sitt ursprung i ledande praxis för skydd av känsliga företagsdata. Då många krav överlappar med de som krävs för att uppfylla GDPR, HIPAA och andra säkerhetskrav kan en del redan vara implementerade i din organisation.
4. Övervaka och underhåll
Det är viktigt att notera att PCI-efterlevnad inte är en engångsgrej. Det är en pågående process som ser till att ditt företag uppfyller gällande krav även när dataflöden och kundrelationer förändras. En del kreditkort kräver att du skickar in rapporter en gång i kvartalet eller en gång per år, medan andra vill att du fyller i en platsbaserad bedömning för att validera pågående efterlevnad, särskilt om du överskrider 6 miljoner transaktioner om året.
För att ett företag ska kunna hantera PCI-efterlevnaden under årets gång (samt år efter år) krävs det ofta att man får stöd och samarbetar med olika avdelningar. Om du inte har gjort det ännu bör du fundera på att skapa ett separat internt team vars uppgift är att se till att efterlevnaden bibehålls. Varje företags behov är förstås unika, men man kan utgå ifrån att de flesta PCI-team kan dra fördel av representation från följande avdelningar:
- Säkerhet: Företagets säkerhetschef (CSO) och informationssäkerhetschef (CISO) och deras team säkerställer att organisationen fortsätter att investera i nödvändig datasäkerhet, integritetsresurser och policyuppdateringar.
- Teknik/betalningar: Företagets teknikchef (CTO), betalningsdirektör och deras team säkerställer att företagets kärnverktyg, integrationer och infrastruktur fortsätter att uppfylla gällande krav i takt med att organisationens system utvecklas.
- Ekonomi: Företagets ekonomichef (CFO) och hens team säkerställer att alla betalningsdataflöden beaktas vad gäller betalningssystem och samarbetspartner.
- Juridik: Det här teamet kan hjälpa företaget navigera de många juridiska frågor som kan uppstå i anslutning till PCI DSS-efterlevnad.
Om du vill ha mer information om PCI-efterlevnadens komplicerade värld kan du gå till PCI Security Standards Councils webbsida. Om du endast avser läsa den här guiden och ett fåtal andra PCI-dokument skulle vi rekommendera att du börjar med dessa: prioriterad strategi för PCI DSS, SAQ-instruktioner och -riktlinjer, vanliga frågor om hur man använder behörighetskriterier för SQA för att identifiera platsbaserade bedömningskrav och vanliga frågor om vilka skyldigheter man har som apputvecklare när det gäller konsumentenheter som tar emot betalningsuppgifter.
Så hjälper Stripe organisationer uppfylla och underhålla PCI-efterlevnad
Stripe gör det betydligt lättare för företag som använder Checkout, Elements, mobila SDK:er och SDK:er i Terminal att uppfylla gällande PCI-krav. Stripe Checkout och Elements använder ett värdbaserat betalningsfält för att hantera alla betalningsrelaterade kortdata, så att kortinnehavaren anger all känslig information i ett betalningsfält som härrör direkt från våra PCI DSS-validerade servrar. Stripes mobila och terminalbaserade SDK:er gör det även möjligt för kortinnehavaren att skicka känslig betalningsinformation direkt till våra PCI DSS-validerade servrar.
Stripe agerar PCI-representant för alla sina kunder oavsett integrationstyp, och kan hjälpa till på olika sätt.
- Vi analyserar din integrationsmetod och beskriver hur du kan minska ditt efterlevnadsarbete.
- Vi meddelar dig i förväg om en växande transaktionsvolym kan leda till att du behöver ändra hur du validerar efterlevnad.
- Om du är en större handlare (nivå 1) och måste arbeta med en PCI QSA (qualified security assessor) (för att du lagrar kreditkortsdata eller har ett mer invecklat betalningsflöde) kan vi introducera dig till ett av de mer än 350 QSA-företag som finns i världen och hjälpa dig hitta en revisor som förstår sig på Stripes olika integrationsmetoder.