BiznetBiznet

By Caner Aşçıoğlu

BANKALAR ve PCI DSS UYUMLULUĞU

Bankalar PCI DSS Kapsamında Mıdır?

Bankalar; sanal pos, fiziksel pos, issuing, acquiring, raporlama, şube ve dijital bankacılık, resmi yazılar…vb. hizmetler nedeniyle ve Üye İşyerleri (merchant), Servis Sağlayıcılar (service provider), müşteriler ve çeşitli kurumlar tarafından kart bilgilerinin iletildiği, saklandığı ve işlendiği kurumlardır. Bu durum Bankaların yoğun şekilde kartlı işlemler görmesi ile birlikte PCI DSS kapsamına da girmesini sağlamaktadır.

PCI DSS’te Bankalara İlişkin İstisna Maddeleri Bulunmakta Mıdır?

Issuing hizmeti veren kurumlar haricindeki kuruluşlar PCI DSS’e göre CVV ve PIN bilgilerini saklayamazlar. Buna karşın, Bankalar kartlı işlemlerde kendi kartlarına ait CVV ve PIN bilgilerini doğruladıklarından bu bilgileri açık şekilde (clear-text) olmamak kaydıyla saklayabilirler. (CVV doğrulama esnasında geçici olarak da tutulabilir.)

Bu istisna dışında Bankalar, geri kalan tüm kontrolleri sağlamak zorundadırlar. Buna kart numarasının (PAN) açık şekilde saklanmaması da dahildir. (Ancak şifrelenmiş, maskeli, hash’li, tokenize edilmiş şekilde…vb. saklanabilir.)

Bankaların PCI DSS Uyumluluğu ve Uyumluluk Denetimi?

PCI SSC (PCI Konseyi), Mastercard ve Visa bankaların PCI DSS standardına uyumlu olmak zorunda olduğunu ifade etmektedirler. Zaten PCI DSS Standardı içerisinde de bankalara yukarıda bahsedilen istisna dışında başka bir istisna tanımlı durumda değildir.

Bankanın Ayrı Bir Teknoloji Firmasına Sahip Olması PCI DSS Uyumluluğunu Nasıl Etkiler?

İki ayrı tüzel kişi olduğundan bu teknoloji firması, her ne kadar sahibi banka olsa da banka açısından 3.parti firma konumundadır. Ve bu teknoloji firmasının bankaya verdiği hizmetler kapsamında PCI DSS uyumsuz olması aynı zamanda Banka’nın da PCI DSS uyumsuzluğuna yol açacaktır.

Bankaların Ortak Ödeme Sayfaları PCI DSS Kapsamında Mıdır?

Evet PCI DSS kapsamındadır. Son zamanlarda bazı bankalar kendi ortak ödeme sayfalarını geliştirerek Üye İşyerlerine hizmet vermeye başladılar. Bankaların sağladığı Acquiring hizmeti haricinde kalan bu tip hizmetlerde bankalar, hizmeti verdikleri Üye İş Yerleri açısından Service Provider (Hizmet Sağlayıcı) konumunda bulunmaktalar ve ortak ödeme sayfaları üzerinden kart bilgileri geçmekte. Yani bir Üye İşyeri PCI DSS kapsamında denetlenirken anlaşmalı olduğu ve kullandığı bankaların ortak ödeme sayfaları da PCI DSS kapsamında denetlenmek durumundadır, zira ortak ödeme sayfası ile ilgili hizmet veren bankalar anlaşmalı oldukları Üye İşyerlerinin servis sağlayıcısı konumundadır. Bu yüzden bankaların ortak ödeme sayfaları PCI DSS uyumlu değilse, bu sayfayı kullanan Üye İşyerleri de uyumsuz olacaktır.

Bankalar Kurumlara Service Provider Hizmeti Verirse PCI DSS Kapsamında Denetlenir mi?

Bankaların bir Üye İşyerine veya Service Provider’a, kart bilgileri ile ilişkili hizmet vermesi durumunda (kart saklama, ortak ödeme sayfası, veri merkezi, DRC, yazılım geliştirme, altyapı yönetimi, güvenlik yönetimi…vb.) ilgili Üye İşyeri veya Service Provider denetlenirken, banka tarafından PCI DSS kapsamında verilen hizmetler de denetim kapsamına girer ve denetlenir. Bankanın verdiği hizmet kapsamında PCI DSS uyumsuz olması durumunda hizmeti alan kurum da PCI DSS uyumsuz olur.

Bankaların Service Provider Hizmeti Veren İştirakleri PCI DSS Kapsamında Denetlenirken Bankacılık Sistemleri de Denetime Girer mi?

Bazı bankalar kurdukları iştirak firmaları aracılığıyla service provider hizmetleri vermekteler. Eğer verilen hizmet kapsamında kart bilgileri iletiliyorsa, saklanıyorsa veya işleniyorsa bu firmalar PCI DSS kapsamına girer. Ancak, bu hizmetlerin verildiği sistemler ile bankaların sistemleri arasındaki ilişki kritiktir. Çünkü bu sistemler eğer bankacılık sistemleri ile izole durumda değilse bu kez bankacılık sistemleri de PCI DSS kapsamında değerlendirilmek zorunda kalınır.

By Caner Aşçıoğlu

PCI SECURE SOFTWARE FRAMEWORK NEDİR?

PCI Secure Software Framework, Güvenli Yazılım Standardı (Secure Software Standard) ve Güvenli Yazılım Yaşam Döngüsü Standardı’ndan (Secure Software Lifecycle (SLC) Standard) oluşmaktadır.

Kurumunuzun geliştirdiği uygulama ve yazılımların PCI Secure Software Framework altındaki standartların kapsamında olunabilmesi için kartlı ödeme yapılmasını sağlayan;

  • Kurumlara satılan ödeme yazılımlarının,
  • Dağıtım yoluyla kullandırılan ödeme yazılımlarının,
  • Lisanslanarak kullandırılan ödeme yazılımlarının,
  • İnternet üzerinden “hizmet olarak (as a service)” dağıtımı sağlanan ödeme yazılımlarının,
  • Kurumların sistemlerine kurulması amaçlanan ödeme yazılımlarının

Kullanılıyor olması gerekir. Bununla birlikte, PCI Secure Software Framework altındaki standartlar, sadece geliştiren kurum tarafından kullanılan ödeme yazılımlarını veya tek bir kurum için geliştirilen ve tek bir kurum tarafından kullanılan ödeme yazılımlarını kapsamamasına rağmen yine de bu standarttaki ilkelerin ve amaçların uygulanması önerilmektedir.

  • Güvenli Yazılım Standardı (Secure Software Standard) ödeme yazılımlarının, ödeme işlemlerinin ve verilerinin gizliliğini ve bütünlüğünü korumasını sağlamaya ilişkin güvenlik gereksinimlerini ve değerlendirme prosedürlerini belirler.
  • Güvenli Yazılım Yaşam Döngüsü (Secure Software Lifecycle (SLC) Standard) yazılım üreticilerinin tüm yazılım yaşam döngüsü boyunca ödeme yazılımlarının güvenliğini nasıl yöneteceklerine ilişkin güvenlik gereksinimlerini ve değerlendirme prosedürlerini belirler.

Güvenli Yazılım Yaşam Döngüsü (SSLC) Standardı 4 adet güvenlik hedefinden ve buna bağlı toplamda 10 adet kontrol hedefinden ve 52 kontrol maddesinden oluşmaktadır:

  • Güvenlik Hedefi: Yazılım Güvenliği Yönetişimi
    • Kontrol Hedefi 1: Güvenlik Sorumlulukları ve Kaynakları
    • Kontrol Hedefi 2: Yazılım Güvenliği Politikası ve Stratejisi
  • Güvenlik Hedefi: Güvenli Yazılım Mühendisliği
    • Kontrol Hedefi 3: Tehditlerin Tanımlanması ve Azaltılması
    • Kontrol Hedefi 4: Zafiyetlerin Tespiti ve Azaltılması
  • Güvenlik Hedefi: Güvenli Yazılım ve Veri Yönetimi
    • Kontrol Hedefi 5: Değişiklik Yönetimi
    • Kontrol Hedefi 6: Yazılım Bütünlüğünün Korunması
    • Kontrol Hedefi 7: Hassas Verinin Korunması
  • Güvenlik Hedefi: Güvenli İletişim
    • Kontrol Hedefi 8: Üçüncü Parti Firma Güvenlik Rehberi
    • Kontrol Hedefi 9: Paydaş İletişimi
    • Kontrol Hedefi 10: Yazılım Güncelleme Bilgileri

Güvenli Yazılım Standardı ise 4 adet güvenlik hedefinden ve buna bağlı toplamda 10 adet kontrol hedefinden ve 150 kontrol maddesinden oluşmaktadır:

  • Güvenlik Hedefi: Saldırı Yüzeyinin Azaltılması
    • Kontrol Hedefi 1: Kritik Varlıkların Tanımlanması
    • Kontrol Hedefi 2: Ön Tanımlı Bilgilerin Güvenli Hale Getirilmesi
    • Kontrol Hedefi 3: Hassas Verilerin Tutulması
  • Güvenlik Hedefi: Yazılım Koruma Mekanizmaları
    • Kontrol Hedefi 4: Kritik Varlıkların Korunması
    • Kontrol Hedefi 5: Kimlik Doğrulama ve Erişim Kontrolü
    • Kontrol Hedefi 6: Hassas Verilerin Korunması
    • Kontrol Hedefi 7: Kriptografi Kullanımı
  • Güvenlik Hedefi: Güvenli Yazılım Operasyonları
    • Kontrol Hedefi 8: Yazılım Aktivitelerinin Takibi
    • Kontrol Hedefi 9: Saldırı Tespiti
  • Güvenlik Hedefi: Güvenli Yazılım Yaşam Döngüsü Yönetimi
    • Kontrol Hedefi 10: Tehdit ve Zafiyet Yönetimi
    • Kontrol Hedefi 11: Güvenli Yazılım Güncellemeleri
    • Kontrol Hedefi 12: Üçüncü Parti Firma Güvenlik Rehberi

Her ne kadar Ocak 2019 itibariyle söz konusu standartlar yayınlanmış olsa da PCI Secure Software Framework’ünün doğrulama programına ilişkin program rehberi, denetçi yeterlilik gereksinimleri, raporlama şablonları gibi dökümanlarının 2019 yıl ortası itibariyle yayınlanması beklenmektedir.

PCI Secure Software Assessor (PCI SSA) sertifikasına sahip denetçiler tarafından yapılacak denetim sürecinin ardından, denetçi ROV (Report on Validation) ve AOV (Attestation on Validation) raporlarını PCI SSC’ye (PCI Güvenlik Standartları Konseyi) gönderecektir. Konsey; denetim kapsamındaki yazılıma ait raporları, kanıtları ve denetçi yorumlarını gözden geçirdikten sonra kendi web sayfasında Onaylanmış Ödeme Yazılımları Listesinde yer almasına onay verecektir.

Mevcutta kullanılan PA-DSS standardı da güvenli yazılıma yönelik bir standart olmakla birlikte, 2022 itibariyle PA-DSS standardı geçerliliğini yitirecek olup güvenli yazılıma yönelik tüm standartlar PCI Secure Software Framework altında toplanmış olacaktır.

Son olarak, PCI güvenlik standartlarından birine uyum sağlanması durumunda diğer bir standarda da uyumlu olunduğu anlamına gelmediği unutulmamalıdır. Yani PCI Secure Software Framework altında yer alan standartlara uyumlu olunması PCI DSS, PCI PTS…vb. standartlara uyum sağlandığı anlamına gelmemekle beraber PCI DSS, PCI PTS…vb. standartlara uyumlu olunması da PCI Secure Software Framework altında yer alan standartlara uyumlu olunduğu anlamına gelmemektedir.

By Oben Kuyucu

PCI DSS ve Çok adımlı kimlik doğrulama

Derler ki bir elin nesi var, iki elin sesi var. Aynı durum kimlik doğrulama için de geçerli. Eposta hesabımıza, şirket bilgisayarımıza, uygulamalara girerken ne kadar karmaşık parola kullanırsak kullanalım, bu parola başkasının eline geçtiği zaman maalesef kimlik hırsızlığı veya bilgi sızıntısı gerçekleşebilir. Bunu engellemenin basit ve güvenilir yolu en az iki faktörlü bir kimlik doğrulaması gerçekleştirmek. Örneğin bir uygulamaya girdiğimizde “bildiğimiz” bir parolanın yanında “sahip olduğumuz” bir telefona mesaj olarak gelen tek kullanımlık bir parolayı da yazdığımız zaman ek bir güvenlik katmanı eklemiş oluruz. Ayrıca biyometrik özelliklerimizi kullanarak da bu güvenlik katmanını geliştirebiliriz. Buna kısaca çok faktörlü kimlik doğrulama ya da çok adımlı kimlik doğrulama (multi-factor authentication) diyoruz. “Bildiğimiz bir şey” örneğin parola, “sahip olduğumuz bir şey” örneğin cep telefonu ya da “olduğumuz bir şey” örneğin parmak izimizden en az ikisini kullandığımız zaman daha güvenilir bir kombinasyon oluşturabiliriz. Bu da hesabımızın ya da bilgilerimizin kötü niyetli kişilerin eline geçmesini zorlaştıracaktır.

Kullanabileceğimiz adımlar neler;

Bildiğimiz bir şey (Something we know)

  • Karmaşık karakterlerden oluşan parolalarımız
  • Sadece numerik karakterlerden oluşan PIN’ler
  • Gizli soru ve cevapları

 

 

Sahip olduğumuz bir şey (Something we have)

  • Cep Telefonu
  • USB Akıllı kartlar
  • Bilgisayarınıza yüklenmiş bir sertifika
  • Yeni nesil T.C. Kimlik Kartlarımız
  • Sayı üreteçleri

 

Olduğumuz bir şey ya da biyometrik özelliklerimiz (Something we are)

  • Göz retinamız veya göz çevremiz
  • Parmak izimiz
  • Avuç içimiz (Damar haritası)
  • Sesimiz veya sesimizin özellikleri
  • Klavyede veya dokunmatik ekranda yazma hızımız
  • İmzamızı atma tarzımız

Denetimlerini yaptığımız PCI Güvenlik Standartları Konseyi de bu konuda bir makale yayınladı. Makaleye https://www.pcisecuritystandards.org/pdfs/Multi-Factor-Authentication-Guidance-v1.pdf adresinden ulaşabilirsiniz. Şimdiye kadarki sürümler, sadece uzaktan erişimlerde (VPN gibi) çok adımlı kimlik doğrulamayı zorunluluk olarak istiyordu. 1 Şubat 2017’de zorunlu hale gelecek bir diğer maddeye göre (8.3.1) artık iç ağınızda kart verisi içeren/işleyen/aktaran sistemlere girişte de çok adımlı kimlik doğrulama gerekecek. Bu makale, bu gereksinim zorunlu hale gelmeden sistemlerinizi hazırlamanız için faydalı bir kaynak olacaktır.

Ufak bir hatırlatma: Doğrulama adımlarından (faktörlerden) aynısını birden fazla kullanmanız (örneğin; 2 farklı parola) maalesef aynı güvenlik olgunluğunu sağlamayacaktır.

By Caner Aşçıoğlu

Güvenli Yazılım Geliştirme Sürecine PCI DSS Bakışı

PCI DSS gereksinim ve güvenlik değerlendirme prosedürüne göre, kurum içinde kullanılan veya kurum dışına açık olan uygulamalardan kart verilerini işleyen, saklayan, ileten veya etkileyen uygulamalar PCI DSS kapsamındadır. Söz konusu uygulamaların geliştirilmesi aşamasında gereksinim analizi, tasarım, kod geliştirme, test, canlı ortama geçiş ve bakım aşamalarında sürecin güvenliğini sağlama adına PCI DSS gereksinimleri ortaya konulmuştur.   Read more

By Oben Kuyucu

SSL v3.0 ve TLS v1.0 Artık Güvensiz – PCI DSS 3.2 için Örnek Geçiş Planı

PCI DSS’in 3.1 ve 3.2 versiyonu ile birlikte, SSL v3.0 ve TLS v1.0 kullanımları artık güvensiz sayılmaktadır. SSL v3.0’da ve TLS v1.0’da çıkan POODLE, BEAST, CRIME adı verilen açıklar sebebi ile İstemci – sunucu arasına giren kötü niyetli bir kullanıcı aradaki bağlantı HTTPS bile olsa, içeriği okuyabilir, içeriği (bütünlüğü) değiştirebilir, hatta kriptografik anahtarlarınızı ele geçirebilir.

PCI DSS 3.1 ve 3.2, yeni SSL (ya da TLS) kurulumlarında mutlaka TLS v1.1 ve üzeri bir ayar istiyor. Var olan kurulumlarda ise, SSL v3.0 ya da TLS v1.0 varsa, kullanılabilir, ancak 30 Haziran 2018’e kadar TLS v1.1 ve üzerine geçilmesi konusunda bir Risk Giderme ve İyileştirme Planı istiyor. Hem PCI DSS Yerinde Denetimlerde, hem de ASV taramalarında baktığımız bu plan konusunda bir denetçi olarak baktığımız kontrolleri yazmak ve örnek bir plan sunmak istedim.

  Read more

1 2