Mart ayında, PCI Konseyi, Veri Güvenliği Standardına (DSS) yönelik en son güncellemeyi yayınladı. PCI DSS 4.0, Mayıs 2018’de piyasaya sürülen mevcut sürüm 3.2.1’in önemli bir yenilemesidir. Tehdit ortamı son dört yılda kesinlikle değişti, bu nedenle DSS’nin bu sürümünde önemli değişiklikler görmek şaşırtıcı değil. , banka ve kredi kartı veri kaybı riskini azaltmak ve tüccarları ve kart sahiplerini korumak içindir.
Ancak, sürüm 4.0’daki değişikliklerin hiçbiri hemen eyleme geçmeyi gerektirmez. Sürüm 3.2.1, 2023’ün ikinci çeyreğine kadar kullanımdan kaldırılmayacak ve sürüm 4.0’daki daha yeni gereksinimlerin çoğu, Mart 2025’e kadar en iyi uygulama olarak kabul ediliyor – yani zorunlu değil. Etkilenen kuruluşlar için bu son tarihin görülmesi alışılmadık bir durum değil. ve uzatılmış, iki yıllık bir zaman çizelgesine dayalı bir plan oluşturun. Bununla birlikte, uygulamayı geciktirmek aynı zamanda en fazla riski kabul etmeyi içeren stratejidir.
Tam Uyum Zor
Gerçek şu ki, 3.2.1 sürümüne uyum çoğu kuruluş için kolay bir iş olmadı. Verizon’un en son “Ödeme Güvenlik Raporu” (kayıt gerekli), 2020’de yayınlanan, kuruluşların yalnızca %27,9’unun PCI DSS ile tam uyumluluğu sürdürebildiğini ve önceki yıla göre %8,8 düşüş olduğunu buldu. Bu düşüş, uyumluluk düşüşüyle birlikte daha uzun bir eğilimin parçası. Tam uyumun %55,4 ile zirve yaptığı 2016 yılından bu yana %27,5.
Bu gerçekle ve 4.0 sürümündeki değişikliklerle karşı karşıya kalan kuruluşların bu geçiş yoluyla farklı bir yaklaşım benimsemeleri için bir fırsat var. Kuruluşlar, uyumluluk son tarihlerini karşılamak için bir plan oluşturmak yerine, uyumluluk gereksinimlerini de karşılayan güvenliği artırmak için bir plan oluşturmalıdır. Bir gereklilik için bu tür bir piste sahip olmak nadirdir ve bu, israf edilmemesi gereken bir fırsattır.
Bu noktayı açıklamak için, gruplar halinde ve eğilimleri belirleyerek KDS’deki değişikliklere bakmak önemlidir. Sonuçta, bu değişiklikler keyfi değil. Tehdit ortamına göre dikkatlice yapılmışlardır.
Örnek olarak, dikkate alınması gereken üç değişiklik vardır. İlk olarak, Gereksinim 2, “Sistem parolaları ve diğer güvenlik parametreleri için satıcı tarafından sağlanan varsayılanları kullanmayın”dan “Güvenli yapılandırmaları tüm sistemlere uygula”ya güncellenmiştir. Gereksinim 8.3.9 artık parola döndürme yerine varlıkların güvenlik durumunun dinamik değerlendirmesini kullanma seçeneği sunar. Son olarak, Gereksinim 8.5.1, çok faktörlü kimlik doğrulamanın uygulanması için güvenli yapılandırma gereksinimini belirtir.
Bu değişikliklerin her birini bir geçiş planında ele alınacak ayrı öğeler olarak düşünmek mümkündür, ancak bunlar toplu olarak ortak bir temel güvenlik denetimine işaret eder: güvenlik yapılandırma yönetimi. Bir kuruluş, bunları tek tek ele almak yerine, uyum ihtiyaçlarını da karşılayan kapsamlı bir SCM programı uygulamalıdır. İlgili bir yana, İnternet Güvenliği Merkezi, kendi Topluluk Savunma Modeli “Güvenli bir yapılandırma süreci (CIS Safeguard 4.1) oluşturmanın ve sürdürmenin, beş saldırı türünün tümü için temel bir koruma olduğunu ve bu, CIS Benchmarks’ta bulunanlar gibi yapılandırmaların önemini pekiştiriyor.” Başka bir deyişle, yalnızca PCI uyumluluğundan elde edilecek daha fazla güvenlik avantajı vardır.
Elbette dikkate alınması gereken başka örnekler de var. Gereksinim 8.3.9, daha kapsamlı bir sıfır güven mimarisi (ZTA) projesini yürütmek için MFA çevresinde Gereksinim 8.4 ve 8.5 ile birleştirilebilir. PCI uyumluluğu kesinlikle ZTA gerektirmez, ancak veriler, güvenliğin en iyi uygulamalı bir ZTA uygulamasıyla artırılabileceğini gösteriyor. Güvenlik odaklı bir hedefe öncelik vererek ve PCI’daki geçişi bir sürücü olarak kullanarak, kuruluşlar gerekli bir projeden faydalarını en üst düzeye çıkarabilir.
Bu tür bir strateji, yeni gereksinimlerle de sınırlı değildir. Verizon raporu, Gereksinim 11’in, “Güvenlik Sistemlerini ve Süreçlerini Düzenli Olarak Test Etme”nin, 10 yıl önce raporun başlangıcından bu yana kuruluşlar için en sorunlu durum olduğunu gösteriyor. Gereksinim 11’de büyük değişiklikler olmadığı iddia edilebilirken, kesinlikle işe yarayacak değişiklikler var. Örneğin, Gereksinim 11.3.1.2 artık dahili varlıklar için kimliği doğrulanmış güvenlik açığı taraması gerektiriyor. Bu tür değişiklikler, güvenlik açığı yönetimine yönelik daha kapsamlı bir yaklaşımla hem güvenlik hem de uyumluluğa yönelik uzun süredir devam eden engelleri ele alma fırsatı sunar.
Yük Değil Araç Olarak Uyum
Denklemin diğer tarafı, değişiklikleri bireysel gereksinimler olarak ele almanın maliyetidir. Bu gereksinimlerin bazılarını uygulamak ve PCI ile tam uyumlu kalmak tam iki yıl sürebilir, ancak bunu yapmak işinize önlenebilir riskler de ekler. İlk olarak, bu arada PCI uyumluluğundan kaçmıyorsunuz. Hala kaynakları tüketen 3.2.1 sürümüne uymanız yeterlidir. Daha da önemlisi, sürüm 4.0’daki değişiklikler şu anda karşı karşıya olduğumuz tehdit ortamını ele almak için yapıldı ve genişletilmiş MFA ve güvenlik kontrollerinin izlenmesi gibi şeylerin uygulanmasını geciktirerek, ortamınızda tanınan, bilinen risklerin devam etmesine izin veriyorsunuz.
PCI uyumluluğu, kart markalarının kendilerini korumaya hizmet ederken, uygulamayı seçtiğiniz güvenlik kontrolleri, kuruluşunuzu ve verilerini korumalıdır. Güvenliği bir öncelik olarak belirleyin ve uyumluluğu bir yük olarak görmek yerine bir araç olarak kullanın.