[ This article was originally published here ]
Bu, bir AT&T Siber Güvenlik danışmanı tarafından yazılan, PCI DSS’ye odaklanan serideki beşinci blogdur. IAM ve PCI DSS ile ilgili ilk bloga bakın . Üç ayda bir CDE testleri sözleşmesi yaparken emin olmak için PCI DSS raporlama ayrıntılarıyla ilgili ikinci bloga bakın . PCI DSS uyumluluğu için ağ ve veri akış diyagramları hakkındaki üçüncü blog . Uyumluluk için API testiyle ilgili dördüncü blog .
Suçlular tarafından sistemlerimize yapılan sürekli ve çeşitli saldırılara karşı risk tabanlı bir yanıt olarak PCI DSS standardı, satıcılar için tam yılda en az 20 ve üçüncü taraf hizmet sağlayıcılar (TPSP’ler) için 21 teknik tarama gerektirir. Aşağıdaki tablo onları listeler.
Uyumluluktan ilk kez geçen yeni kuruluşlar, “temiz” oldukları sürece, yani gerekli tüm unsurları kritik bir sorun olmadan geçtikleri sürece, geçerli taramaların (ve gerekirse yeniden taramaların) her birinin yalnızca en son üç aylık dönem değerini sağlayabilir. veya ciddi bulgular.
Standardın bazı gereklilikleri, standart o terimin kapsadığı süreyi tanımlamadığından tırnak içinde “periyodik olarak” gerçekleştirilmelidir. Sonuç olarak, QSA’lar, DSS’nin değerlendirilen varlığa takdir yetkisi verdiği çeşitli bağlamlar için periyodikliği tanımlamak ve gerekçelendirmek için müşterilerin risk değerlendirmelerini kullanmalarını bekler. Bu şekilde elde edilen her dönem daha sonra Kuruluşun Politikasında, Prosedüründe, uyum takviminde veya uygun şekilde belirlenen dahili standart belgelerinde belgelenmelidir.
Standart tarafından öngörülen bazı taramaların üç ayda bir, diğerlerinin yılda bir tamamlanması gerekir ve hepsinde şu ihtar vardır: “ve önemli bir değişiklikten sonra tekrarlanır”, bu, yukarıdaki ilk tarama sayımlarının yanındaki “minimum” niteleyicisini açıklar.
Lütfen neyin “önemli değişiklik” teşkil ettiğine ilişkin ayrı kılavuza bakın.
ASV taramaları 90-92 günlük bir sıklıkta oluşmazsa, PCI ÇOK affetmez. Düzeltici veya düzeltme taramaları, CDE’nin en kısa pratik süre için savunmasız olduğunu kanıtlamak için mümkün olan en kısa sürede sağlanmalıdır. Müşteri, düzeltmenin yapıldığını kanıtlamak için bir sonraki ayın taramasını beklemeyebilir. Ancak, bir güvenlik açığının düzeltilmesi uzun zaman alıyorsa, bunun yerine süreci takip etmeye ve hafifletici düzenlemelere (ek güvenlik duvarı veya IDS/IPS yapılandırmaları gibi) ilişkin belgelerin gösterilmesi gerekecektir.
Çoğu kuruluş, Standartta açıkça tanımlanmadıkları, ancak CDE’nin kapsamını doğrulamak için kullanılan ortam ve metodoloji hakkında sorular soran Uyumluluk Raporunun Bölüm (Gereksinim değil) 3.1’de atıfta bulunulduğu için gerekli üç aylık taramalardan dördünü kaçırır. (Gereksinim 3.1 Bölüm ÇHC’nin 6’sı).
Kaçırdıkları tarama, “Kart Sahibi Veri Ortamı (CDE) dışında hiçbir kart sahibi verisi (CHD) olmadığını nasıl kanıtladınız” sorusuna cevap veren taramadır. Gereksinim 3.1.b, saklama limiti sona erdiğinde tüm meşru KKH’nin tanımlanmasını ve kaldırılmasını sağlamak için üç aylık bir sürecin kanıtını istediğinden, beklenmeyen KKH taramalarının en azından aynı periyodikliğe tabi olması gerektiği sonucu çıkar.
Aslında, beklenmeyen KKH bir ihlal riski olabilir ve süreçler beklenmedik KKH’nin yaratılmasının imkansız olmasını sağlamalıdır, ancak personel bazen yaptırım uygulananların sınırlamalarının üstesinden gelmek için geçici süreçler oluşturabilir. Beklenmeyen KKH birçok yönden sorunlu hale gelebilir. Fiziksel ve mantıksal erişim, işe özgü işlevi olanlarla sınırlı olmayabilir; şifreleme gerçekleştirilemez; süreç belgelenmemiştir ve bu nedenle sürdürülmemiştir; saklama, politikalarla uyumlu olmayabilir; elden çıkarma güvenli olmayabilir veya hiç olmayabilir.
Beklenmeyen CHD bulmak için iki olası yer, test (QA) ortamı ve işletim sistemi veya web sunucusu uygulaması düzeyinde kilitlenme dökümleridir. Çok sayıda personeli olan büyük bir kuruluş için, doğrudan birincil hesap numarası (PAN) erişimi olan tüm personelin sistemlerini taramanızı veya her şeyi gerçek zamanlı olarak izleyen bir DLP çözümü uygulamanızı öneririz.
Kapatmak için, her taramanın günlük bilgileri ve hatta muhtemelen güvenlik sorunları hakkında uyarılar üretmesi gerekir. Bazı kuruluşlar, kimliği doğrulanmamış testler tamamlandıktan sonra veya engelleme eşiği çok düşükse daha ayrıntılı testlere izin vermek için test kullanıcısını beyaz listeye alır.
Testi gördüğünüzden ve eşikleri veya yapılandırmaları uygun şekilde ayarladığınızdan emin olmak için lütfen günlükleri kontrol edin. Test cihazını beyaz listeye eklerseniz veya “testten geldiğini bildiğiniz” için uyarıları susturursanız, onları beyaz listeden çıkarmayı ve test tamamlandıktan sonra uyarıları yeniden etkinleştirmeyi unutmayın. Ayrıca, hiç kimsenin hain bir şey elde etmek için teste binmediğinden emin olmak için günlükleri ve uyarıları yine de gözden geçirmek iyi bir uygulamadır.
gerekli taramalar
Sıklık |
Tanım |
PCI DSS v3.2.1 Referansı |
Üç ayda bir |
Kaçan CHD için CDE olmayan taramalar |
ROC Bölüm 3.1 Soru #2 |
Üç ayda bir |
kablosuz taramalar |
11.1 |
Üç ayda bir |
Dahili ağ güvenlik açığı taraması |
11.2.1 |
Üç ayda bir |
Harici güvenlik açığı taraması ASV |
11.2.2 |
İhyaç olduğu gibi |
Sorun bulunursa yeniden tarar |
11.2.3 |
Yıllık ve gerektiğinde |
Harici penetrasyon testi |
11.3.1 |
Yıllık ve gerektiğinde |
Dahili sızma testi |
11.3.2 |
İhyaç olduğu gibi |
Düzeltme ve yeniden tarama |
11.3.3 |
Yıllık (Hizmet Sağlayıcılar için altı ayda bir) |
Segmentasyon testi |
11.3.4 (Hizmet Sağlayıcılar için 11.3.4.1) |
Yıllık ve gerektiğinde |
Yazılım güvenlik açığı taraması (11.3’ten farklı) |
6.6 |
İhyaç olduğu gibi |
Önemli değişikliklerden sonra |
çoklu |
AT&T Cybersecurity, riski yönetme ve şirketinizi güvende tutma yolculuğunuzda size yardımcı olacak çok çeşitli danışmanlık hizmetleri sunar. PCI-DSS danışmanlığı, yardımcı olabileceğimiz alanlardan yalnızca biridir. Çıkış yapmak .
reklam