säkerhet vs. överensstämmelse med PCI DSS krav 8

för några veckor sedan pratade jag med en av mina medarbetare om hela säkerhet vs efterlevnad konversation. Fram till dess höll jag förutsättningen att efterlevnad gör lite för säkerheten. Som svar på mitt uttalande frågade han den retoriska frågan: ”Var skulle dessa företag, ur ett säkerhetsperspektiv, vara utan efterlevnad?”

ja, efterlevnad är det minsta du behöver göra för att försvara dig mot attacker; men om du kommer att klaga på att du måste göra efterlevnad finns det inget som hindrar dig från att fokusera på starkare it-kontroller.

i det här blogginlägget vill jag ta en stund och diskutera några av de missade nyanserna i PCI DSS-krav 8, som i huvudsak är inriktad på lösenordshantering; men argumenterade ofta inte tillräckligt säkert. Det finns ofta några förbisedda bitar av information som finns där som jag skulle vilja belysa. Och när du bor med temat, om dessa kontroller inte är tillräckligt starka, Känn dig fri att öka kontrollnivån.

de finare punkterna i PCI DSS-kravet 8

när vi undersöker ingressen till Avsnitt 8 i PCI DSS definierar det tillämpligheten av detta krav. Det som är intressant är att dessa lösenordskrav inte gäller för alla användare, även om många antar att det gör det.

här är den text som finns i anteckningssektionen i ingressen:

notera: Dessa krav gäller för alla konton, inklusive försäljningskonton, med administrativa funktioner och alla konton som används för att visa eller komma åt kortinnehavardata eller för att komma åt system med kortinnehavardata. Detta inkluderar konton som används av leverantörer och andra tredje parter (till exempel för support eller underhåll). Dessa krav gäller inte konton som används av konsumenter (t.ex. kortinnehavare). Kraven 8.1.1, 8.2, 8.5, 8.2.3 till 8.2.5 och 8.1.6 till 8.1.8 är inte avsedda att tillämpas på Användarkonton inom en betalningsansökan som endast har tillgång till ett kortnummer i taget för att underlätta en enda transaktion (t.ex. kassakonton).

kort sagt, det finns många lösenordskrav som inte gäller för personer som hanterar ett kort i taget, till exempel en kassör och intressant, till och med möjligen callcenterpersonal. Om den anställde bara har möjlighet att ange kortinnehavardata och inte kan se den, ur ett applikationsperspektiv, finns det flera kontroller som inte är tillämpliga. Detta är ett område där du kan gå utöver för att öka din säkerhetsställning. Där du kan, se till att dessa kontroller genomförs för alla individer.

även om det inte är ett krav på PCI DSS, jag rekommenderar att du tar dig tid och utföra en formell riskbedömning. Detta kommer att säkerställa att inte genomföra dessa kontroller för den typen av konto inte orsakar onödig börda för dina data. Du kan också gå utöver och upprätta kontroller för de ovan nämnda typerna av användarkonton som det inte gäller för.

Inställning av Lösenordskriterier

därefter har vi språk inom Vägledningsavsnittet i krav 8.2.3. Specifikt anger 8.2.3:

8.2.3 lösenord / lösenfraser måste uppfylla följande:

  • Kräv en minsta längd på minst sju tecken.
  • innehåller både numeriska och alfabetiska tecken

alternativt måste lösenorden/lösenfraserna ha komplexitet och styrka som minst motsvarar de parametrar som anges ovan.

och Vägledningsavsnittet för detta krav anger:

detta krav anger att minst sju tecken och både numeriska och alfabetiska tecken ska användas för lösenord/lösenfraser. I fall där detta minimum inte kan uppfyllas på grund av tekniska begränsningar kan enheter använda ”motsvarande styrka” för att utvärdera sitt alternativ. För information om variabilitet och likvärdighet av lösenordsstyrka (även kallad entropi) för lösenord/lösenfraser i olika format, se branschstandarder (t.ex. den nuvarande versionen av NIST SP 800-63.)

så vad betyder allt detta? Låt mig börja med att säga att ett lösenord på 7 tecken kan äventyras på nolltid om hash har fångats. Om du inte är medveten om hur det ser ut, ta dig tid att undersöka Regnbågstabeller.

jag rekommenderar personligen lösenord på minst 15 tecken. Anledningen till att det bara finns ett krav på 7 tecken är att PCI DSS måste rymma äldre miljöer och system. Är 7 tecken säkra? Jag låter dig fatta det beslutet. Men där dina system kan stödja mer finns det inget som hindrar dig från att kräva 32 tecken.

vad händer om ditt lösenord består av 32 ”1”? Låt oss beräkna lösenordet entropi av vad som krävs. Om ditt lösenord är 7 tecken som består av alfa-och numeriska värden, rapporterar http://passwordstrengthcalculator.com att det skulle ta mindre än en sekund att knäcka lösenordet med en superdator med 36,2 bitar entropi. Medan ett lösenord med 32 1 skulle ta 15 854 896 år med samma dator med 106 bitar entropi.

så det handlar inte bara om lösenordet. Det finns många värden som kan påverka ett lösenord; det handlar dock inte om att göra det minsta, det handlar om att göra vad som är nödvändigt för att skydda dina tillgångar från obehörig attack.

medan överensstämmelse inte motsvarar säkerhet behöver du inte göra det minsta. Gör din riskbedömning och om en tillgång fortfarande är i fara, även med minimikraven, ligger det inom din frihet att öka din säkerhetsställning och kräva mer än bara efterlevnadsstandarden. Varje företag som någonsin har brutits var klagomål med något. Men de var inte säkra. Fokus på säkerhet, och efterlevnad kommer normalt att ske som en biprodukt av att vara säker.

förhoppningsvis tips jag har gett här kommer att hjälpa dig på vägen till överensstämmelse med PCI DSS krav 8. Klicka här för att se mina andra PCI Compliance Guide-inlägg.

Lämna ett svar

Din e-postadress kommer inte publiceras.