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 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 Can Demirel

PCI DSS Kapsamında Sızma Testleri ve Kapsam Belirleme

Bilgi güvenliğinin etkin derecede sürdürülebilmesi için çok sayıda standart, çerçeve ve yasal düzenleme bulunmaktadır. Bunlardan bazıları yönetim sistemi, bazıları uygulama güvenliği, bazıları doğrudan ürünlerin güvenliği ile ilgilenmektedir. PCI DSS (Payment Card Industry Data Security Standard) ise ödeme altyapılarının güvenliği ile ilgilenmektedir. PCI DSS; Visa, MasterCard, Discover, JCB ve American Express gibi çok uluslu kart markaları tarafından  2004 yılında kurulan bir oluşumdur ve temel amacı ödeme hesabı güvenliğini geliştirerek (kredi kartı, debit kart vb) kişisel hassas bilgilerin (Kart Numarası, PIN, CVV vb) ifşasına karşı bilgi güvenliği standardları oluşturmaktır.

PCI DSS denetimine tabi kuruluşların, teknik açıklıkların yönetimine ilişkin politika ve prosedürleri tanımlayarak, belirli periyotlarla güvenlik taraması ve sızma testlerini gerçekleştirmesi beklenmektedir.

Kurumların;

Her  üç aylık dönemde ASV (Approved Scanning Vendor) dış zafiyet taraması,
Yılda bir defa ve kayda değer değişikliklerden sonra sızma testi,
Her üç aylık dönemde iç güvenlik taraması
İşlemlerini gerçekleştirmesi gerekmektedir.
Bu yazımızda PCI DSS kapsamında yapılması zorunlu olan sızma testlerine değineceğiz:
PCI DSS kapsamında yapılması gereken sızma testlerine ilişkin gereksinimler standardın 11.3 numaralı maddesinde ele alınmaktadır.

Sızma testleri ile hedeflenen :

  • Kötü niyetli kullanıcıların sistem, dosyalar, loglar ve/veya kart verisine ait temel güvenliği etkileyecek varlıklara olan varsa erişiminin ve ne şekilde olacağının belirlenmesi
  • PCI DSS için gerekli olan uygulama kontrollerinin, zafiyet yönetiminin, metodolojilerin ve segmentasyonun doğru bir şekilde uygulandığının teyit edilmesidir.

PCI DSS kapsamında gerçekleştirilen testlerde dikkat edilmesi gerekli hususlar aşağıdaki gibidir;

Kapsam Belirleme

PCI DSS kapsamında gerçekleştirilen sızma testlerine ait kapsamın belirlenmesi her zaman en karmaşık konulardan birisi olmuştur. Yanlış belirlenen kapsam, testin etkinliğini ve yeterliliğinin sorgulanmasına sebep olacaktır. Kapsamın belirlenmesine ilişkin hatalar, PCI DSS denetimleri gerçekleştirirken de karşımıza çıkmaktadır.

Sızma testi kapsamını belirlemek kuruluşun sorumluluğundadır. Eksik ve hatalı belirlenen kapsamdan yine kuruluş sorumlu olacaktır. Kapsam belirleme kimi zaman bilinçli kimi zaman da bilinçsiz olarak eksik/hatalı olarak belirlenmektedir.

Kapsam ile ilgili kavramlara geçmeden önce kart sahibi bilgisi ortamı CDE (Card Holder Data Environment) kavramını hatırlamakta fayda olacaktır:

“the people, processes, and technology that store, process, or transmit cardholder data or sensitive authentication data”

Yukarıdaki tanım ışığında sızma testi kapsamı aşağıdaki gibi tariflenebilir;

Tüm CDE (Card Holder Data Environment),
CDE (Card Holder Data Environment)’ye etkisi olabilecek tüm kritik sistemler* sızma testi kapsamında olmalıdır.

*Kritik Sistem: Kritik sistem PCI DSS tarafından CardHolder Data’sına ilişkin işlem yapan veya cardholder data’sını korumaya yönelik sistemler olarak belirlenmektedir. PCI DSS bu sistemleri şu şekilde örneklemektedir. “Güvenlik sistemleri, internet üzerinden erişilebilir sistemler, veritabanları, cardholder data’sını işleyen, depolayan, ileten diğer tüm sistemler”. Bununla birlikte CDE kapsamında olmayan fakat güvenliğine etkisi olabilecek firewal, IPS/IDS, Authentication sunucuları, E-commerce redirection sunucuları v.b ya da yetkili kullanıcılar tarafından yönetilen CDE ortamındaki bileşenlere etkisi olabilecek tüm bileşenler kritik sistem olarak değerlendirilmelidir.

Bu iki ifadeden hareketle sızma testi sürecinin en az aşağıdaki iki bileşeni içermesi gerektiği yorumunu yapmak yanlış olmayacaktır;

  1. CDE ilişkili internet üzerinden erişilebilir tüm bileşenler (public facing attack surface)- Harici sızma testi
  2. CDE ilişkili yerel ağ üzerinden erişilebilir tüm bileşenler (LAN to LAN attack surface)- Dahili sızma testi

Ayrıca, kapsam belirlenirken, kritik sistem bileşenlerinin CDE ortamı ile olan segmentasyon yöntemi (Açık, Kontrollü Erişim, İzole Edilmiş) belirlenerek, testler esnasında bu segmentasyonların göz önünde bulundurulması gerekmektedir. İlerleyen bölümlerde daha detaylı olarak açıklanacağı üzere; CDE ortamından izole edilmiş sistemlerin/bileşenlerin izolasyonunun testler esnasında teyit edilmesi gerekmektedir.

Aşağıdaki soruların cevabının aranması, sızma testi kapsamını belirlemede yaşanan hataları azaltmamıza katkı sağlayacaktır

  1. Internet üzerinden CDE ve CDE ile ilişkili tüm erişimler/sistemler kapsama alındı mı?
  2. CDE ortamı için Özel IP adreslerine tanımlanmış özel servisler kapsama alındı mı?
  3. Uzaktan erişim servisleri kapsama alındı mı?
    1. Dial-up, modem
    2. VPN altyapısı (IPSEC, SSL VPN v.b)
  4. Internet üzerinden erişilebilir sistemlere yönelik testler hem uygulama hem de ağ seviyesindeki kontrolleri içeriyor mu?
  5. Yerel ağ üzerindeki güvenlik kontrolleri CDE ile ilişkili/erişimi olan tüm VLAN’ları kapsıyor mu?
  6. CDE’nin güvenliğine etkisi olabilecek tüm sistemler yerel ağ güvenlik denetimi kapsamında mı?

Özetle kapsam;

  1. Cardholder Data yerleşkeleri (Birden fazla DataCenter olan yerler, Disaster Recovery v.b)
  2. Cardholder Data’ını işleyen, ileten, depolayan uygulamalar (Web uygulaması, veritabanı)
  3. Hassas/kritik ağ bağlantıları (Firewall, switch v.b)
  4. Kablosuz Ağ Erişim noktaları
  5. CDE ortamına erişim sağlamaya olanak tanıyacak tüm varlıkları içerecek şekilde olmalıdır.

Yerel Ağ Güvenlik Denetimleri

  1. Yerel ağ güvenlik denetimleri CDE ortamına ilişkin yerel ağ üzerinden erişilebilir bileşenlerini ve bu bileşenlerin servislerini içerecek şekilde gerçekleştirilmelidir. CDE’ye veya CDE’nin güvenliğine etkisi olabilecek tüm yerel ağ bileşenleri kapsama alınmalıdır.
  2. CDE ortamını doğrudan CDE ağı içerisinden test etmek bir gereksinim değildir. Bununla birlikte sadece CDE ortamının test edilmesi de gereksinimleri karşılamak açısından yeterli olmayacaktır. Ancak test sırasında CDE ortamına herhangi bir testin sonucu olarak erişim sağlanırsa buradaki bileşenlerin de testi tabi tutulması tavsiye edilir. Ayrıca veri sızıntısı engelleme çözümlerinin, CDE ortamında sızma testi uzmanının veri çıkarmasını engellemesi beklenmektedir.

Uygulama Güvenlik Denetimleri

  1. Öncelikle kuruluşa özgü olarak geliştirilmiş veya özelleştirilmiş tüm uygulamalar denetim kapsamına alınmalıdır.
  2. Uygulama kapsamında kimlik doğrulama mekanizmaları mevcutsa rol ve erişim tiplerine göre kontroller gerçekleştirilmelidir. Bu testler özellikle cardholder datasına erişim yetkisi olmayan rollerin bu türden verilere erişim sağlayıp sağlayamadığı kontrolleri içermelidir. Ek olarak testler kullanıcı gözü ile gerçekleştirilmeli ve kullanıcıların sadece kendilerine ait verileri görüntülemesine olanak tanıyan kontrollerin etkinliği ölçülmelidir. Bu noktada testi yaptıran kuruluş gerekli hesapları sağlamaktan sorumludur.
  3. Test kapsamında PA-DSS uyumluluğu olan uygumalar denetime tabi tutulacaksa uygulamanın fonksiyonellik testlerine tabi tutulmasına gerek yoktur. (Oturum yönetimi, anahtar yönetimi, transcation yönetimi). Bununla birlikte uygulamanın implementasyonu ile kontroller gözden geçirilmelidir. (İşletim sistemi seviyesi, servisler v.b)
  4. Kuruluşa özgü olarak geliştirilmeyen fakat kuruluşa özgü özelleştirilen uygulamalarda (dosya paylaşım uygulamaları, portal, cihaz yönetim arayüzleri, web-mail bileşenleri veya kısaca kuruluşun kaynak kod üzerinde doğrudan söz sahibi olmadığı uygulamalar) uygulama seviyesinde kontrollere gereksinim yoktur. Bunun yerine bu türden bileşenlerin uygulanması (implementation), yapılandırması, konumlandırması ve ağ seviyesinde kontrollerin gerçekleştirilmesi faydalı olacaktır.
  5. Eğer uygulama Back-End API’lerle işlem yapıyorsa bu API’lerde denetim kapsamında alınmalıdır.
  6. Uygulama güvenlik denetimleri minumum PCI DSS 6.5 maddesinde belirtilen gereksinimleri karşılayacak şekilde gerçekleştirilmelidir.

Test Ortamı mı? Canlı Ortam mı?

PCI DSS kapsamında gerçekleştirilen denetimlerde sıkça gündeme gelen konulardan bir tanesi de testlerin “test ortamı” ve “canlı ortam” üzerinde gerçekleştirilmesidir. Eğer test edilecek sistemin  kesintiye toleransı düşükse ve canlı sistem üzerindeki kontroller güvenlik denetim süresini uzatacaksa canlı ortamın birebir eşleniği olan izole bir test ortamında testler gerçekleştirilebilir. Burada birebir eşlenik kavramı uygulama ve ağ seviyesindeki tüm alt birimleri adreslemektedir. Ek olarak test ortamında tespit edilen sömürülebilir tüm açıklıklar canlı ortam da geçerli olduğu doğrulanmalıdır.

Segmentasyon (Segmentation) Testleri/Bölümlendirme Testleri

PCI DSS 11.3.4 maddesi sızma testleri kapsamında segmentasyon kontrollerinin etkinliğinin ölçülmesini gerekli kılmaktadır. Segmentasyon testlerinde kullanılacak yöntem tüm ağlar için doğru sonuçlar üretecek şekilde belirlenmelidir.

Segmentasyon değerlendirmeleri non-CDE ağların/ortamların CDE izolasyonun tam olarak sağlanıp sağlanmadığını belirlemeye yönelik olmalıdır.

Bir sistemin PCI-DSS kapsamında dışında değerlendirilebilmesi için ilgili sistemin ele geçirilmesi halinde CDE’nin güvenliğine etkisi olup olmadığı gözden geçirilir. Eğer etkisi varsa, CDE’nin kart işlemeye yönelik, iletim, saklama, işleme alma tanımı gözetmeksizin çalışma kapsamına alınmalıdır.

Eğer segmentasyon kontrolleri sırasında doğru olarak izole edilmemiş bir ağ tespit edilirse bu ağa yönelik iki kontrol uygulanabilir. İlk olarak bu ağ üzerinde izolasyon kuruluş tarafından sağlanmalı ya da ikinci bir yöntem olarak ilgili ağ bir bütün olarak ağ seviyesinde sızma testine tabi tutulmalıdır.

Sosyal Mühendislik Testleri

Sosyal mühendislik testleri doğrudan bir PCI DSS gereksinimi değildir. Bununla birlikte sosyal mühendislik testleri son kullanıcıya yönelik risk ve tehditleri adreslemek açısından önem taşır. Özellikle son kullanıcı farkındalığının ölçümlenmesinde girdi olarak kullanılabilir. Sosyal mühendislik testleri gerçekleştirilirlen kuruluşun olgunluk seviyesi, kültürü dikkate alınmalı ve bu testler sırasında  veri modellemesinde kullanılabilecek yeterince tesadüfi örnek alınmalı ve örnek rastgeleliği sağlanmalıdır. Son toplamda sosyal mühendislik testleri sadece belirli bir gruba yönelik olacağından tüm kuruluşa ilişkin yorum yapmak kimi zaman sakıncalı olabilir. Bu bağlamda oransal olarak yaklaşmak faydalı olacaktır. Sosyal mühendislik testleri kapsamında, tailgating gibi fiziksel kontrollerin yanı sıra, telefon, e-posta gibi yöntemler de ihtiyaca göre kapsama alınabilir.

Significant Change Kavramı

PCI DSS 11.3.1 ve 11.3.2 maddelerinde güvenlik testlerinin periyodunu en az bir yıl ve “significant change”-önemli bir değişiklik- olduğunda olacak şekilde belirlemiştir. Bu kavram bir miktar yoruma açıktır. Değişiklik yapılan ortama ve kuruluşa göre farklı yorumlanabilir. Significant change kavramı ağ güvenliğine veya cardholder data’sına erişim sağlamaya olanak verecek herhangi bir değişim olarak tanımlanabilir. Bu durumda değişiklik sonrası alınan önlemlerin güvenlik denetimine tabi tutularak alınan kontrollerin etkinliğinin doğrulanması gerekmektedir.

Raporlama Kılavuzu

PCI kapsamında yapılan sızma testine ait sonuçlar, iyi bir şekilde dokümante edilmeli ve aşağıdaki başlıklar raporda detaylandırılmalıdır:

  • Testin kapsamı
  • Test kapsamına ilişkin kısıtlamalar
  • Testler ve zafiyetler hakkında detay bilgiler
  • Segmentasyon doğrulamasına ilişkin test sonuçları
  • Kullanılan araçlar
  • Ortamın temizlenmesine yönelik gerekli aksiyon planları
  • Nihai test sonuçları
  • Kanıtları ile beraber tekrar doğrulama sonuçları

By Ateş Sünbül

PCI DSS 3.2’nin Sesi Uzaktan Hoş Geliyor…

Nisan 2015 itibariyle PCI DSS v3.1 yürürlüğe girmiş ve denetimler bu standart üstünden yapılmaya başlanmıştı. PCI konseyinin yaşam döngüsü gereğince 3 yıllık bir yaşam döngüsü içinde standartlar güncelleniyor ve yeni kontrol maddeleri tasarlanıyor.

Bu çerçevede standartın 3.2 sürümü için PCI konseyi ilk tasarılarını açıkladı ve geçerlilik tarihi 1 Ocak 2018 olacaktır.

3.2 standartında özetle gelecek kontroller:

  • Eski TLS / SSL teknolojilerinin kullanımı için artık uzatma olmayacaktır.
  • PAN bilgisinin ilk 6 ve son 4 hanesinden fazlasının gösterilmesine imkan verecek esneklikler tanımlanacak.
  • İki faktörlü doğrulamanın kapsamı değişecek ve genişleyecektir.

Değişikliklerin detaylarını biraz irdeleyecek olursak:

  • Designated Entities Supplemental Validation (DESV) ve Eski TLS / SSL kullanım maddeleri raporun bir eki haline geliyor.
  • PAN bilgisinin ilk 6 ve son 4 hanesinden fazlasının gösterilmesine imkan verecek esneklikler tanımlanacak. Esnekliklerin sınır ve istisnaların tanımı henüz net olmamakla birlikte iş ihtiyaçları gözetileceği ifade edilmektedir.
  • Değişiklik yönetim sürecinin bir kontrol adımı olarak her yapılan değişikliğin PCI DSS kontrollerine etkisinin varlığı sorgulanacaktır.
  • Servis sağlayıcı statüsünden PCI DSS kapsamına giren şirketler için ek olarak:
    • Kriptolama mimarisini çizmeleri ve tanımlamaları gerekliliği tanımlanmıştır.
    • Kritik güvenlik sistemlerindeki hata ve devredışı kalmaları tespit etmeleri ve raporlamaları gerekliliği tanımlanmıştır.
    • Güvenlik sızma testleri yılda 2 kere yapılması gerekliliği tanımlanmıştır.
    • PCI DSS uyum programı tasarlamaları ve işletmeleri gerekliliği tanımlanmıştır.
    • En az fazla her çeyrekte olacak şekilde personelin güvenlik kurallarını takip ettiğini teyit etmesi gerekliliği tanımlanmıştır.
  • Kart Veri Envanterine (CDE) yapılacak yönetimsel (Admin) müdahalelerin iç ağda dahi olsa iki faktörlü doğrulamadan geçmesi mecburiyeti tanımlanmıştır.
1 2