beveiliging vs. Compliance met PCI DSS Requirement 8

een paar weken geleden sprak ik met een van mijn collega ‘ s over het hele security vs compliance gesprek. Tot dan, hield ik het uitgangspunt dat compliance doet weinig voor de veiligheid. In antwoord op mijn verklaring stelde hij de retorische vraag: “waar zouden deze bedrijven, vanuit een beveiligingsperspectief, zonder compliance zijn?”

Ja, compliance is het minimum dat je moet doen om je te verdedigen tegen aanvallen; echter, als je gaat klagen over het hebben van naleving te doen dan is er niets weerhoudt u zich te concentreren op sterkere it-controles.

In deze blogpost wil ik een moment nemen om enkele van de gemiste nuances van PCI DSS-eis 8 te bespreken, die hoofdzakelijk gericht is op wachtwoordbeheer; maar, vaak betoogd is niet veilig genoeg. Er zijn vaak een paar over het hoofd gezien stukken van informatie die daar die Ik wil licht op te werpen. En, in een verblijf met het thema, als deze controles zijn niet sterk genoeg, voel je vrij om het niveau van de controle te verhogen.

de fijnere punten van PCI DSS-eis 8

wanneer we de preambule van paragraaf 8 van de PCI DSS onderzoeken, wordt de toepasselijkheid van deze eis gedefinieerd. Wat interessant is, is dat deze wachtwoordvereisten niet van toepassing zijn op alle gebruikers, hoewel velen ervan uitgaan dat dit wel het geval is.

hier is de tekst in het hoofdstuk noot van de preambule:

Noot: Deze vereisten zijn van toepassing op alle rekeningen, met inbegrip van verkooppuntrekeningen, met administratieve mogelijkheden en alle rekeningen die worden gebruikt om gegevens van kaarthouders te bekijken of te openen of om toegang te krijgen tot systemen met gegevens van kaarthouders. Dit omvat accounts die worden gebruikt door leveranciers en andere derden (bijvoorbeeld voor ondersteuning of onderhoud). Deze vereisten zijn niet van toepassing op rekeningen die door consumenten worden gebruikt (bijvoorbeeld kaarthouders). Eisen 8.1.1, 8.2, 8.5, 8.2.3 tot en met 8.2.5 en 8.1.6 tot en met 8.1.8 zijn niet bedoeld om van toepassing te zijn op Gebruikersaccounts binnen een betaaltoepassing in een verkooppunt die slechts toegang hebben tot één kaartnummer tegelijk om één enkele transactie te vergemakkelijken (zoals kassierekeningen).

kortom, er zijn tal van wachtwoordvereisten die niet van toepassing zijn op personen die één kaart tegelijk behandelen, zoals een kassier en interessant, zelfs mogelijk callcentermedewerkers. Als de medewerker alleen gegevens van de kaarthouder kan invoeren en deze niet kan bekijken vanuit het perspectief van de toepassing, zijn er verschillende besturingselementen die niet van toepassing zijn. Dit is een gebied waar u kunt gaan boven en buiten om uw veiligheid houding te verhogen. Waar u in staat bent, zorg ervoor dat deze controles worden geïmplementeerd voor alle individuen.

hoewel dit geen vereiste is voor de PCI DSS, raad ik u aan de tijd te nemen en een formele risicobeoordeling uit te voeren. Dit zal ervoor zorgen dat het niet implementeren van deze controles voor dat type account geen onnodige belasting voor uw gegevens veroorzaakt. U kunt ook verder gaan en controles instellen voor de bovengenoemde soorten gebruikersaccounts waarop het niet van toepassing is.

het instellen van Wachtwoordcriteria

vervolgens hebben we taal binnen de rubriek oriëntatie van Eis 8.2.3. In het bijzonder, 8.2.3 Staten:

8.2.3 wachtwoorden / wachtzinnen moeten voldoen aan de volgende:

  • vereist een minimale lengte van ten minste zeven tekens.
  • bevatten zowel numerieke als alfabetische tekens

als alternatief moeten de wachtwoorden / wachtzinnen complexer en sterker zijn dan de hierboven gespecificeerde parameters.

en de afdeling Oriëntatie van dit voorschrift vermeldt:

deze eis specificeert dat ten minste zeven tekens en zowel numerieke als alfabetische tekens moeten worden gebruikt voor wachtwoorden/wachtzinnen. In gevallen waarin door technische beperkingen niet aan dit minimum kan worden voldaan, kunnen entiteiten “gelijkwaardige sterkte” gebruiken om hun alternatief te evalueren. Voor informatie over variabiliteit en equivalentie van wachtwoordsterkte (ook wel entropie genoemd) voor wachtwoorden/wachtzinnen van verschillende formaten, verwijzen we naar industriestandaarden (bijvoorbeeld de huidige versie van NIST SP 800-63.)

wat betekent dit allemaal? Laat me beginnen met te zeggen dat een 7-karakter wachtwoord kan worden gecompromitteerd in een mum van tijd op alle als de hash is gevangen. Als u zich niet bewust bent van hoe dat eruit ziet, neem dan de tijd om Regenboogtafels te onderzoeken.

persoonlijk raad ik wachtwoorden van minstens 15 tekens aan. De reden dat er slechts een vereiste van 7 tekens is, is dat de PCI DSS rekening moet houden met oudere omgevingen en systemen. Is 7 karakters veilig? Ik laat je die beslissing nemen. Maar waar je systemen meer kunnen ondersteunen, is er niets dat je ervan weerhoudt 32 tekens te gebruiken.

wat als uw wachtwoord bestaat uit 32 ” 1 ‘s”? Laten we het wachtwoord entropie berekenen van wat nodig is. Als uw wachtwoord 7 tekens bevat, bestaande uit alfa-en numerieke waarden, meldt http://passwordstrengthcalculator.com dat het minder dan een seconde zou duren om het wachtwoord te kraken met een supercomputer met 36,2 Bits entropie. Terwijl een wachtwoord met 32 1 ‘ s 15.854.896 jaar zou duren met dezelfde computer met 106 Bits entropie.

het gaat dus niet alleen om het wachtwoord. Er zijn een groot aantal waarden die een wachtwoord kunnen beïnvloeden; echter, het gaat niet over het doen van het minimum, het gaat over het doen wat nodig is om uw activa te beschermen tegen ongeautoriseerde aanval.

hoewel compliance niet gelijk is aan beveiliging, hoeft u het minimum niet te doen. Doe uw risicobeoordeling en als een asset nog steeds in gevaar is, zelfs met de minimale vereisten, is het binnen uw vrijheid om uw beveiligingshouding te verhogen en vereisen meer dan alleen de compliance-standaard. Elk bedrijf dat ooit werd geschonden was een klacht met iets. Ze waren echter niet veilig. Focus op veiligheid, en compliance zal normaal gesproken gebeuren als een tweeproduct van veilig zijn.

hopelijk zullen de tips die ik hier heb gegeven u helpen om te voldoen aan PCI DSS eis 8. Klik hier om mijn andere PCI Compliance Guide posts te bekijken.

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd.