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