esperienze pci: key point e suggerimenti per una applicazione ......esperienze pci: key point e...
Post on 13-Oct-2020
7 Views
Preview:
TRANSCRIPT
Esperienze PCI: key point e
suggerimenti per una applicazione
efficiente ed efficace dello
standard
AIEA, SDS 15 Dicembre 2010
Massimo Cotrozzi – Sernet spa
AIEA – SDS 15 dicembre 2010
Sernet SpAManagement Advisory
Company Profile
WWW.SERNET.IT
Governance, Risk & Compliance
ICT Governance & Security
Execution & Organization Restructuring
Energy
AREE DI BUSINESS SERNET
4
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
ICT Governance (ISO 38500, CobiT) IT Service Management (ITIL, ISO 20000) ICT Audit ICT Human Resources Management & Organization
Information Security Management System (ISO 27000) Business Continuity & Disaster Recovery (BS 25999)
Payment Security (PCI DSS) Vulnerability Assessment – Penetration Test Secure SDLC Security technologies advisory
ICT GOVERNANCE & SECURITY SERVIZI SERNET
IT Governance
ICT Security
Security Tech
pag. 6
. IT Governance
ICT security – Business Continuity
CoSO - ERM
CobiT
ISO 27001
SDLC
Application development
ITIL – ISO 20000
ISO 38500
ICT service delivery
Board briefing on IT Governance
BS 25999
• PCI DSS: Assessment e Preparazione alla Certificazione
• Sicurezza applicativa (Ciclo sicuro SDLC)
• Svolgimento Vulnerability assessment-Penetration Test
• Advisory scelte tecnologiche di sicurezza
ICT GOVERNANCE & SECURITY QUADRO D’INSIEME
Security
Tech
pag. 7
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. 8
PCI SSC
Membri del
“Payment card industry - Security Standard Council”
pag. 9
Versione 2.0 dello Standard PCI DSS
Reduce Liabilities, Address Business Risks, Increase Security and
Protect Sensitive Company’s Information
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
pag. 13
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”
6 Obiettivi, 12 Requisiti
pag. 14
pag. 15
Assessment types
pag. 16
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.
Penetration Testing – PCI requires that all Web
applications that handle cardholder data have annual
penetration testing performed.
pag. 17
Certification roadmap
Final Report on Compliance,
which demonstrates full compliance with PCI requirements
PCI DSS: lo stato dell’arte
pag. 18
Diffusione dello standard nel mercato
italiano e internazionale
Come approcciare PCI DSS
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
• Myth 1 – One vendor and product will make us compliant
• Myth 2 – Outsourcing card processing makes us compliant
• Myth 3 – PCI compliance is an IT project
• Myth 4 – PCI will make us secure
• Myth 5 – PCI is unreasonable; it requires too much
• Myth 6 – PCI requires us to hire a Qualified Security Assessor
• Myth 7 – We don’t take enough credit cards to be compliant
• Myth 8 – We completed a SaQ so we’re compliant
• Myth 9 – PCI makes us store cardholder data
• Myth 10 – PCI is too hard
pag. 21
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
Internal Auditing non abbastanza staffato per
effettuare auditi efficacipag. 23
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
pag. 26
Massimo Cotrozzi
Sernet SpAManagement Advisory
Piazza Repubblica 30
20122 Milano
Tel. +39.02.89696835
Fax +39.02.89696834
email: massimo.cotrozzi@sernet.it
www.sernet.it
Grazie dell’attenzione
top related