La sfarsitul lunii martie am finalizat auditul intern pentru certificarea PCI DSS, ultima versiune a standardului v1.2. Este un standard impus de organizatiile de carduri, inspirat din ISO 27001. Am fost auditati atat la sediul din Bucuresti timp de cateva zile cat si direct la hosting providerul din Olanda, pentru validarea la fata locului a elementelor impuse de standard.

De ce il consideram un lucru demn de mentionat? Pentru ca este cel mai important standard din industria platilor online, este o certificare greu de obtinut si in acelasi timp cea mai puternica dovada a securitatii un sistem de procesare.

Concret, standardul contine 12 capitole care trebuie acoperite. La nici un punct din capitol nu exista posibilitatea unui raspuns gen “may be“. Variantele de raspuns sint simple: DA sau NU (”in place” sau “not in place”). Orice element care nu este “in place” inseamna ca nu poti fi certificat. Atata timp cat nu sint acoperite TOATE punctele nu se poate vorbi de certificare.

Capitolele din standard acopera:

• instalarea de firewall-uri pentru protejarea datelor de card
• schimbarea periodica a parolelor si cheilor de codare
• protejarea datelor de card (din aplicatii, de acces neautorizat din firma sau extern etc).
• criptarea datelor la transmiterea electronica (nu doar cand utilizatorul introduce datele dar si in alte procese gen backup)
• folosirea antivirusilor cu baze de date la zi
• dezvoltarea si testarea aplicatiilor (un capitol complex in care este vorba atat de procesul de dezvoltare cat si de testare functionala si de securitate)
• restrictionarea accesului la informatiile stocate (doar echipa departamentului de Risk care monitorizeaza tranzactiilor online are acces la aceste informatii)
• obligativitatea folosirii conturilor individuale si a schimbarii regulate a cheilor si parolelor
• restrictionarea accesului fizic la servere
• logarea si urmarirea tuturor resurselor din retea sau din afara ei care ar putea avea acces la procesul de tranzactionare
• testarea regulata a retelelor si a aplicatiilor (sintem scanati zilnic de McAfee Secure ex Hackersafe) dar si teste de penetrare retea si aplicatie realizate intern.
• mentinerea unor politici de securitatea informatiei (Information Security Policy, Disaster Recovery Plan, Incident Response Plan etc).

Practic pregatirea pentru auditarea finala a inceput cu cateva luni mai devreme, cu pregatirea documentatiei. PCI nu este doar un standard care impune un set de reguli de securitate a retelei interne (din firma), a retelei externe (de la hosting provider), a aplicatiilor web dezvoltate ci necesita si foarte multa formalizare, proceduri scrise, documentare de procese, planuri in caz de dezastru si politici interne. Partea cu formalizarea si scrisul documentatiei a fost cea care ne-a dat cea mai mare bataie de cap.

In pregatirea pentru audit am realizat si o serie de ajustari ale platformei ePayment, gen expirarea sesiunilor utilizatorilor care au acces la informatii despre clienti la 15 minute, expirarea parolelor la 90 de zile, blocarea automata a conturilor dupa mai multe incercari succesive esuate dar si o serie de elemente in reteaua interna si la locul de munca, precum implementarea Sentinet, adaugarea unor camere de supraveghere suplimentare, restrictionarea accesului pe wireless pe VPN, logarea tuturor vizitatorilor, blocarea automata a statiei de lucru automat la 15 minute de inactivitate, masuri care au fost mai mult sau mai putin populare.

Din punctul de vedere al securitatii platformei ePayment, modificarile infrastructurii clusterului de servere au fost cele care au generat atat costuri de implementare cat si modificarea aplicatiilor pentru acomodarea acestor schimbari.

Infrastructura de securitate

Bazele de date au fost izolate in retele private, switch-urile provider-ului de hosting au fost inlocuite cu switch-uri private, firewall-urile au fost dublate cu masini dedicate si nu doar firewall-uri locale. Toate aceste modificari s-au realizat cu un timp de neaccesibilitate minim, incercand sa fie cat mai transparente pentru cumparatori. Acest lucru a fost posibil si datorita load-balancing-ului la nivelul serverelor de web si a mecanismelor de fail-over la nivelul serverelor de baze de date.

Pregatirea pentru audit a avut si momente mai funny, chiar si la scrierea documentatiei. Una dintre proceduri specifica cum se distrug datele sensibile, atat varianta electronica cat si varianta fizica (hard-disk-uri care nu mai functioneaza). Un hard-disk se poate distruge fizic prin mai multe metode, cea mai eficienta este destul de costisitoare. Este vorba de procesul de degauss, care se poate realiza cu echipamente speciale. Din motive de costuri nu am apelat la asemenea device-uri si am implementat procedura de distrugere cu … barosul.

Extrag un paragraf din procedura: “In a company administrative room wearing appropriate safety equipment, subject the media drive to physical force (e.g., pounding with a sledgehammer) that will disfigure, bend, mangle, or otherwise mutilate the media drive so that it cannot be re-inserted into a functioning computer. Sufficient force should be used directly on top of the media drive unit to cause shock/damage to the media surfaces. In addition, any connectors that interface into the computer must be mangled, bent, or otherwise damaged to the point that the media drive could not be re-connected without significant rework.”

Aaa, si ca sa nu uit: ePayment nu stocheaza numere de card, date de expirare sau codurile de securitate CVC/CV2 de pe spatele cardurilor. Acum sistemul este si auditat pentru o garantie suplimentara a acestui fapt.

Taguri: baros, certificare, PCI DSS, plati online, Securitate online

Articolul a fost adaugat pe data de Friday, May 8th, 2009 la ora 12:31 pm in categoriile Comert Electronic, ePayment.
Poti urmari comentariile la acest articol prin intermediul feed-ului RSS 2.0.
Te invitam sa ne scrii un mesaj, sau sa pui un link trackback de pe site-ul tau.