Riktlinjer för pentester

What the PCI standard explicitly mandates about penetration testing is illustrated in Requirement 11.3, requiring organizations to perform annual penetration tests that would mainly:

  • Utvärdera både nät och applikationslager
  • Inkludera både interna och externa tester

Nätverkstesterna sätts ihop av den som testar, men nedan faktorer måste inkluderas i en test av applikationslagret:

  • Injektionsbrister, särskilt SQL-injektion
  • Buffer overflow vulnerabilities
  • Insecure kryptografisk lagring
  • Osäker kommunikation
  • Hanteringsfel
  • Cross-site scripting (XSS)
  • Felaktig åtkomstkontroll
  • Cross-site request-förfalskning (XSRF, CSRF)
  • Bruten autentisering och sessionshantering
  • Andra sårbarheter som identifierats som hög risk under riskbedömningen


Ovanstående lista består av de vanligaste secure code-rutinerna som gällde när PCI DSS version 3.0 publicerades. När secure coding-rutiner förändras, som t ex med OWASP, SANS CWE Top 25, CERT Secure Coding, osv. förväntas att även organisatoriska rutiner uppdateras.

Men, de exempel på secure coding-resurser som tillhandahålls av PCI SSC är endast där som vägledning. En organisation är alltid skyldig att ta under beaktning det praxis som gäller för tekniken i sin specifika miljö.

Inga ytterligare riktlinjer eller föreskrifter tillhandahålls annat än vad som nämnts. Så ett välstrukturerat tillvägagångssätt för penetrationstestning är acceptabelt, så länge som ovanstående punkter täcks och att fokus ligger på korddata.

Generellt är det lämpligt att alltid titta på alla kärnområden för säkerheten av applikationen, som:

  • Applikationslogik (kontroller av klientsidan, logiska brister, osv.)
  • Åtkomsthantering (autentisering, session hantering, åtkomstkontroll)
  • Input-hantering(parameter fuzzing)
  • Applikationsdrift (delad driftmiljö, säkerhet av webbserver)
  • Övriga diverse kontroller (lokala sekretessproblem, informationsläckor, SSL/TLS-svagheter osv.)


Om gjort på rätt sätt bör man täcka det nödvändiga för PCI DSS, om än t o m lite mer.

PCI penetration test infrastructure level

När det kommer till infrastrukturen vid ett PCI-penetrationstest dvs. brandväggar, routrar, system, webbservrar, databaser, applikationsservrar osv. så har inte rådet gett några tydliga riktlinjer. Men, oavsett så bör några grundläggande principer hållas i åtanke:

  • gå in så djupt och brett som möjligt
  • var alltid uppmärksam gällande kortdata


Network level penetration test

Det här ämnet täcker ett av de vanligaste testerna och innebär att man letar måltavlor i nätverket, öppningar i underliggande operativsystem och tillgängliga nätverkstjänster och utnyttjar sedan det på distans. Det verkar faktiskt rimligt att begränsa den interna bedömningen till nätverksnivå snarare än ett lokalt perspektiv, vilket innebär att fokus bör vara på att hitta problem på remote visible ports/services. I de flesta fall skulle det inte finnas något värde i att dyka ner i ett kompromissat filsystem eller databas-tabeller eftersom det är en QSA:s ansvar.

Ett penetrationstest på nätverksnivå bör fokusera helt på att upptäcka möjliga brister som påverkar nätverkstjänsterna och då ur perspektivet av en host som finns på samma nätverkssegment/subnet. Några av nätverksteststester görs på distans via Internet och riktar in sig på organisationens perimeter-nätverk. Andra lanseras lokalt, från organisationens egna anläggningar, för att utvärdera säkerheten på det interna nätverk och/eller DMZ från insidan, för att se vilka sårbarheter en intern användare kan hitta.

Ett penetrationstest kan vara ganska omfattande och komplicerat till skillnad på kraven på en QSA som utför ett test i en PCI DSS-miljö. QSA:er måste därför vara otroligt noggranna för att ett penetrationstest ska vara effektivt.

Kontakta

Vill du veta mer om Complior och våra lösningar?

24Solutions AB
officially changes name
to Complior AB

We are happy to announce an exciting new chapter for our company!

New company name and logo.

Stronger organization and more focus on our compliance