Ödeme kartı veri hırsızlığı büyük bir sorun olmaya devam ediyor ve Verizon 2024 Veri İhlali Soruşturmaları Raporu’na (DBIR) göre ihlallerin neredeyse beşte birini (%19) oluşturuyor ve perakende sektöründe bu oran %25’e çıkıyor. Dahası, raporda ayrıca e-ticaret sitelerine yönelik fidye yazılımı saldırıları sırasında ödeme kartı verilerinin de sifonlandığı ve bu şekilde elde edilen bilgilerin çalınan ödeme kartlarını içeren ihlallerin %57’sinden sorumlu olduğu bulundu. Bu verileri korumak zorunludur ve bu nedenle Ödeme Kartı Endüstrisi Veri Güvenliği Standardı (PCI DSS) standardında bir revizyon gördük.
PCI DSS 4.0, v3.2.1 emekliye ayrıldığında Nisan ayında getirildi ancak 51 gereklilikten yalnızca 13’ü artık zorunlu. Bunun nedeni, çoğunun karmaşık olarak sınıflandırılması ve bu nedenle kuruluşun süreçlerde ve sistemlerde önemli değişiklikler yapmasını gerektirmesidir. Sonuç olarak, bu kuruluşların uyum sağlamasını sağlamak için bu gerekliliklere ekstra zaman ayrıldı ve bu nedenle bugün en iyi uygulama olarak sınıflandırılıyorlar ve Nisan 2025’e kadar zorunlu olmayacaklar.
En son sürüm olan PCI DSS 4.0.1, daha esnek, daha az kuralcı olan ve güvenliği devam eden bir süreç olarak ele alan sonuç odaklı yaklaşımı nedeniyle memnuniyetle karşılandı. Ayrıca artık çok daha alakalı, ortaya çıkan tehditleri ve teknolojileri yansıtıyor ve terminolojideki değişiklikler ödeme verilerinin nasıl işlendiğini daha doğru bir şekilde yansıtıyor. Teknolojik kontroller de güncellendi, bu nedenle örneğin kart sahibi veri ortamına (CDE) erişirken çok faktörlü kimlik doğrulama (MFA) gibi ek kimlik doğrulamanın sunulduğunu görüyoruz.
Ancak PCI DSS 4.0, sistemleri birbirine bağlamada, sorunsuz işlemleri etkinleştirmede ve gerçek zamanlı veri alışverişini kolaylaştırmada önemli bir rol oynayan Uygulama Programlama Arayüzlerine (API’ler) gösterilen ilgiyi artırmasıyla da dikkat çekicidir. Bir saldırganın bakış açısından, uygulamayı atlayıp doğrudan API’ye gitmek çok daha uygundur. Bu, ödeme kartı verilerini yakalamak için uygulama kullanıcı arayüzünü değiştirme veya karmaşık ve genellikle kırılgan ekran kazıma kodu yazma ihtiyacını ortadan kaldırır; bu uygulama, skimming olarak bilinir. Dahası, API saldırıları daha fazla bilgi sağlayabilir ve bu da saldırganın kuruluşun sistemlerine daha derinlemesine nüfuz etmesine olanak tanır. Ödeme işleme bağlamında API güvenliğinin acil bir sorun haline gelmesinin nedenleri bunlardır.
PCI DSS 4.0.1, API güvenliğiyle ilgili bir dizi yeni gereklilik içerir. Örneğin, Gereklilik 4.2.1 artık kuruluşun açık, genel ağlar üzerinden Birincil Hesap Numarası (PAN) iletimi için kullandığı sertifikaların geçerli olduğunu ve süresinin dolmadığını veya iptal edilmediğini doğrulamasını talep eder. Bu, PAN verilerinin harici ağlar üzerinden iletildiğinde güçlü kriptografisinin uygulanmasını gerektirecektir, bu nedenle daha karmaşık gerekliliklerden biri olarak sınıflandırılır, gerekliliği karşılamanın ilk adımı, bu PAN verilerini ileten API uç noktalarını belirlemek olacaktır.
6. Gereklilik, güvenli uygulamaların ve sistemlerin geliştirilmesiyle ilgilidir ve 6.2’nin özel veya özelleştirilmiş yazılımlara uygulanacak şekilde revize edildiği görülmüştür. Ayrıca, üretim öncesinde potansiyel kodlama açıklarını belirlemek ve düzeltmek için uygulama kodunun incelenmesini gerektiren 6.2.3 gibi API geliştirme için bazı önemli maddeler içerir. Bunun için kritik olan, kütüphaneler, çerçeveler ve API’ler gibi harici bileşenlerin güvenli bir şekilde entegre edilmesidir. İkincisiyle ilgili olarak, bu, API’lerin yanlış yapılandırmalar, açıkları veya zayıf şifreleme şifreleri gibi daha sonra yönetilmesi veya düzeltilmesi gereken zayıflıklar açısından değerlendirilmesini gerektirir.
Elbette, test yalnızca ön üretim aşamasında gerçekleştirilmemelidir. Çalışma zamanı sırasında test etmek ve API davranış kalıplarını izlemek de aynı derecede önemlidir. Bu daha sonra, yazılım mühendisliği teknikleri veya diğer yöntemlerle yaygın yazılım saldırılarının ve ilgili güvenlik açıklarının etkisini önlemeyi veya azaltmayı amaçlayan Gereksinim 6.2.4’e uyumu sağlamaya yardımcı olabilir; bu, API saldırıları durumunda basit enjeksiyon saldırılarından son derece incelikli iş mantığı suistimallerine kadar büyük ölçüde değişebilir.
Bir diğer yeni gereklilik ise, yazılıma entegre edilmiş üçüncü taraf yazılım bileşenleriyle birlikte API’ler gibi özel ve özelleştirilmiş yazılımların envanterinin tutulması ihtiyacını belirten 6.3.2’dir. Yazılımın güvenliğini sağlamak söz konusu olduğunda, kuruluşun yazılımında hangi üçüncü taraf bileşenlerinin kullanıldığını bilmek ve bilinen güvenlik açıklarını gidermek için güvenlik yamalarının kullanılabilirliğini izlemek hayati önem taşır.
Kritik öneme sahip olan 6.4.1’in yerini alan 6.4.2 gereksinimi, bir kuruluşun tespit edici bir kontrol olarak zafiyetlerini manuel olarak değerlendirebileceğini veya önleyici bir kontrol kullanabileceğini önceden belirtmiştir. Yeni gereksinim, kamuya açık uygulamaları korumak için web tabanlı saldırıları sürekli olarak tespit eden ve engelleyen otomatik, önleyici bir kontrolün dağıtılmasını talep eder.
Birçok kuruluş zaten otomatik uygulama güvenliği çözümlerine sahip olsa da, API’lerle ilgili saldırıları hem tespit etme hem de önleme yetenekleri muhtemelen sınırlı olacaktır. Örneğin, Web Uygulama Güvenlik Duvarları (WAF’ler), imza tabanlı bir yaklaşım benimser; bu da keşif faaliyetlerini ve her amaca ve maksada göre normal meşru trafik gibi görünen saldırıları tespit etme olasılıklarının düşük olduğu anlamına gelir. Bir saldırıyı engelleseler bile, tehdit dönüştüğünde onu takip edemez ve ardından saldırganın kaynaklarını tüketmek için aldatma gibi kaçamak eylemlerde bulunamazlar. Bu nedenle, bu yalnızca kuruluşların manuel bir yaklaşımdan otomatik bir yaklaşıma geçmeleri gerekeceği için değil, aynı zamanda saldırıları tespit etme ve tırmanmasını önleme yeteneklerini değerlendirmeleri gerekeceği için de karmaşık olarak sınıflandırılır.
Bunlar, PCI DSS 4.0.1 kapsamındaki API güvenliğiyle ilgili olan karmaşık gerekliliklerden bazılarıdır ve bunları karşılamak muhtemelen zorlu olacaktır. Bunu yapmak için, kuruluşun mevcut hükümlerini ve hangi ek önlemlerin alınması gerektiğini gözden geçirmesi gerekecektir ve bunun er ya da geç yapılması zorunludur. Son tarihe yakın bir zamana kadar ertelemek, kuruluşu uyum sağlama konusunda baskı altına sokacaktır ve ana odak noktası, yeni düzenlemelerin öngördüğü sürekli uyumluluk yaşam döngüsünü elde etmek yerine QSA’yı karşılamak olacaktır. PCI DSS’yi devam eden bir süreç olarak görmek, değişiklikleri aşamalı olarak uygulamayı daha az acı verici hale getirecek ve ayrıca kuruluşun güvenlik duruşunun verimli bir şekilde sürdürülmesini ve PCI DSS’nin günlük operasyonların bir parçası haline gelmesini sağlayarak en fazla faydayı sağlayacaktır.
