Nessun titolo diapositiva

Esperienze PCI: key point e
suggerimenti per una applicazione
efficiente ed efficace dello
standard
AIEA, SDS 15 Dicembre 2010
Massimo Cotrozzi – Sernet spa
Sernet SpA
Management Advisory
Company Profile
WWW.SERNET.IT
AIEA – SDS 15 dicembre 2010
AREE DI BUSINESS SERNET
 Governance, Risk & Compliance
 ICT Governance & Security
 Execution & Organization Restructuring
 Energy
ICT Governance & Security
Obiettivo
assicurare servizi ICT efficaci, efficienti e con livelli di
sicurezza coerenti con le esigenze dei processi aziendali e
con le valutazioni di rischio
Contenuti
supporto consulenziale per la adozione e preparazione alla
certificazione di metodologie e standard di ICT Governance
& Security, per lo svolgimento di progetti di ICT audit e per
la
ottimizzazione
delle
soluzioni
tecnologiche
e
organizzative ICT
4
ICT GOVERNANCE & SECURITY
SERVIZI SERNET
ICT Governance (ISO 38500, CobiT)
IT Service Management (ITIL, ISO 20000)
ICT Audit
ICT Human Resources Management & Organization
IT Governance




ICT Security
 Information Security Management System (ISO 27000)
 Business Continuity & Disaster Recovery (BS 25999)
Security Tech  Payment Security (PCI DSS)
 Vulnerability Assessment – Penetration Test
 Secure SDLC
 Security technologies advisory
ICT GOVERNANCE & SECURITY
QUADRO D’INSIEME
CoSO - ERM
IT Governance
ISO 38500
CobiT
Board briefing on IT Governance
ICT security – Business Continuity
ICT service delivery
ITIL – ISO 20000
pag. 6
•
•
•
•
ISO 27001
BS 25999
Application development
SDLC
PCI DSS: Assessment e Preparazione alla Certificazione
Sicurezza applicativa (Ciclo sicuro SDLC)
Svolgimento Vulnerability assessment-Penetration Test
Advisory scelte tecnologiche di sicurezza
Security
Tech
Obiettivo della Presentazione
Delineare il quadro d’insieme di uno Standard emergente (PCI
DSS), dedicato alla sicurezza delle transazioni tramite carta di
credito, che interessa:
• issuers (es. banche)
• merchant (es. grande distribuzione o esercenti)
• service providers (es. outsourcers ICT)
La versione attuale dello standard (versione 2.0), è stata
pubblicata nell’ottobre 2010.
pag. 7
PCI SSC
Membri del
“Payment card industry - Security Standard Council”
pag. 8
Versione 2.0 dello Standard PCI DSS
Reduce Liabilities, Address Business Risks, Increase Security and
Protect Sensitive Company’s Information
pag. 9
La norma PCI DSS
• PCI (Payment Card Industry) DSS (Data
Security Standard) è stato sviluppato per
 favorire e migliorare la protezione dei dati di
titolari di carta
 semplificare l'implementazione di misure di
sicurezza dei dati coerenti a livello globale.
• Il documento, PCI DSS - Requisiti e
procedure di valutazione della sicurezza, si
basa sui 12 requisiti PCI DSS e li abbina
alle corrispondenti procedure di test in uno
strumento formale e rigoroso di valutazione
della sicurezza.
pag. 10
Obiettivo della norma
• Ridurre la portata delle frodi ai
consumatori con le carte di credito
• Ridurre il rischio di sicurezza sulla
filiera dei pagamenti con carte
• Ridurre i costi a carico degli emittenti
e trasferirli (implementazioni di
sicurezza e multe)
pag. 11
Obiettivo della norma
• Ridurre al minimo all’interno del
Sistema Informativo l’utilizzo delle
Carte di Credito ed esclusivamente
per motivi di business
• Laddove le carte sono presenti solo
utenti autorizzati devono potere
accedere
pag. 12
L’importanza di PCI DSS
• Autorevolezza di
• Penali a carico i trasgressori (es. merchant che non proteggono le
carte di credito)
• Novità dello standard, che nasce in un contesto di difesa dagli
attacchi di cybercriminali
• Ampio ambito di copertura dello standard (infrastrutture ICT,
software applicativo, aspetti organizzativi, etc)
• Misure preventive di sicurezza allo stato dell’arte
• Progressivo ampliamento del set di standard di
(es. PA DSS per il contrasto alla vulnerabilità applicativa)
• Focus sullo standard da parte di Associazioni internazionali di
sicurezza ICT (es. ISSA) e di auditing (es. AIEA), per i trattamenti di
dati critici: non solo “cardholders”, ma anche “dati sensibili”
pag. 13
6 Obiettivi, 12 Requisiti
pag. 14
Assessment types
pag. 15
PCI DSS – What to do for compliance
Assessments – Merchants and service providers have to
select an approved assessor to conduct annual security
assessments to validate compliance with PCI requirements
as detailed in the document Payment Card Industry (PCI)
Security Audit Procedures (available at
www.pcisecuritystandards.org).
Perimeter Network Scans – PCI requires quarterly
perimeter scans performed by a vendor approved by the PCI
Security Standards Council.
Internal Network Scans – PCI requires Level 1 and 2
service providers to have quarterly internal scans
performed. Internal scans can be performed by any party,
including internal resources.
pag. 16
Penetration Testing – PCI requires that all Web
applications that handle cardholder data have annual
penetration testing performed.
Certification roadmap
pag. 17
Final Report on Compliance,
which demonstrates full compliance with PCI requirements
PCI DSS: lo stato dell’arte
 Diffusione dello standard nel mercato
italiano e internazionale
 Come approcciare PCI DSS
pag. 18
PCI DSS – Compliance, si…
ma come?
• Approccio security:
Proteggere tutto
Espandere il perimetro
Mitigare il rischio
e i processi?
e chi controlla?
pag. 19
PCI DSS – Compliance, si…
ma come?
• Un approccio efficace alla gestione
della compliance PCI
Capire l’obiettivo aziendale
Verificare la strada migliore da seguire
Partire dai processi
Possibilmente modificare i processi
Gap Analysis
Verifica impatti IT
Eventualmente reiterare il ciclo
pag. 20
Miti, ma non troppo
•
•
•
•
•
•
•
•
•
•
pag. 21
Myth
Myth
Myth
Myth
Myth
Myth
Myth
Myth
Myth
Myth
1 – One vendor and product will make us compliant
2 – Outsourcing card processing makes us compliant
3 – PCI compliance is an IT project
4 – PCI will make us secure
5 – PCI is unreasonable; it requires too much
6 – PCI requires us to hire a Qualified Security Assessor
7 – We don’t take enough credit cards to be compliant
8 – We completed a SaQ so we’re compliant
9 – PCI makes us store cardholder data
10 – PCI is too hard
Application Security
• Non esiste “uno” standard
PA DSS
“Build Security IN” (US GOV)
“Comprehensive, Lightweight
Application Security Process” (OWASP)
Microsoft SDL
pag. 22
Application Security
• Problematiche
 Awareness
 Software engineer non a conoscenza di tematiche
di security
 Timings
 Nuove funzioni e procedure da svilupparsi “per
ieri”
 Accountability
 Nessuno e’ responsabile per errori di security
 Monitoring
 Nessuno controlla che esistano SLA di security per
i software applicativi
 Auditing
pag. 23
 Internal Auditing non abbastanza staffato per
effettuare auditi efficaci
Application Security
• Cosa si fa per rimediare
Code reviews con tools automatizzati
OWASP top 10
Pentesting
Checklist
• Security generalmente non
strutturata ma “per eccezioni”
• Gestione “contrattuale” della
sicurezza applicativa (se va bene)
pag. 24
Conclusioni
PCI DSS
Friend or Foe?
pag. 25
Massimo Cotrozzi
Sernet SpA
Management Advisory
Grazie dell’attenzione
Piazza Repubblica 30
20122 Milano
Tel. +39.02.89696835
Fax +39.02.89696834
email: [email protected]
www.sernet.it
pag. 26