Series · 5 partsATM Security AssessmentPart 4 · You are here
- 1ATM Penetrasyon Testinde Güven Sınırları: OS ve XFS Katmanı
- 2ATM Firmware Boot Güven Zinciri: Donanım Güvenlik Sınırları
- 3Masaüstü Gizlendi. Çalıştırma Sınırı Gizlenmedi.
- 4Cihaz API'si Standarttı. Yetkilendirme Varsayıldı.You are here
- 5Bir ATM Sınırlandırıldı. Filo Güven Yolu Sınırlandırılmadı.
60 saniyede cihaz yetkilendirmesi
Finansal hizmetler middleware’ı, özel cihazları ortak arayüzler üzerinden kullanılabilir kılar. Bu işlevsel uyumluluk operasyonel açıdan değerlidir; ancak standart bir istek formatı şu güvenlik sorusuna yanıt vermez: kim, hangi işlem durumunda, hangi terminal için ve ne tür kanıtla erişim talep etmeye yetkilidir?
Tehlikeli varsayım, bir işlemin yerel broker’a erişebildiği için o cihazı kullanabileceğidir. Bağlantı, otorite haline gelir. Daha iyi değişmez kural şudur:
Bir çevre birimi işlemi ancak çağıran kimliği, uygulama bütünlüğü, terminal durumu, transaction state, cihaz kimliği ve politika birbiriyle uyumlu olduğunda ve karar endpoint dışında kaydedildiğinde kabul edilir.
Bu metodoloji, emülatörler, tedarikçi test modları, zararsız durum işlemleri ve beklenen reddetmeler ile bu değişmez kuralı kanıtlar. Canlı nakit komutları çıkarmaz, PIN materyali yakalamaz, şifreleme anahtarlarını değiştirmez, kart verilerini saklamaz veya dağıtılmış cihazları kontrol etmek için komut dizilerini yayınlamaz.
Middleware bir politika sınırlamasıdır
CEN XFS, uygulamaların bir XFS Yöneticisi üzerinden finansal çevre birimleriyle çalışabilmesi için API’ler ve hizmet sağlayıcı arayüzlerini tanımlar. Mimari değer ayrılıktır: uygulama her cihaz için tedarikçiye özgü mantığa ihtiyaç duymaz. Güvenlik riski de aynı şekilde ayrılıktır: politika kararı, uygulama, yönetici, hizmet sağlayıcı, sürücü, cihaz ve yukarı akış işlem sistemi arasında bölünebilir ve yetkilendirme açıkça bir bileşen tarafından sahip edilene kadar devam edebilir.
Yöneticiye yapılan bağlantı, iki bileşenin iletişim kurabildiğini kanıtlar. Başarılı bir açma veya durum isteği, bir arayüzün varlığını kanıtlar. Hiçbiri, hassas bir işlemin onaylanmış uygulamaya veya meşru bir işlemle bağlandığını kanıtlamaz.
Sıfır aşama: yetenek sınıflarını tanımlayın ve durma koşullarını belirleyin
Test yapmadan önce bir capability kataloğu oluşturun. Salt okunur durum sorgularını, müşteri girdisi işlemeyi, medya hareketini, fiş çıktısını, sensör durumunu, bakımı, kriptografik fonksiyonları ve nakdi etkileyen işlemleri ayırın. Her sınıf için bir sahip, gerekli çağıran, gerekli çalışma durumu, izin verilen ortam, beklenen telemetri ve güvenli test ikamesi tanımlayın.
En yüksek riskli yetenekler asla gerçek dünya etkisi üzerinden kanıtlanmamalıdır. Tedarikçinin simülatörünü, sertifikasyon ortamını veya test modunu kullanın. Hiçbiri yoksa, yetkilendirme kararını broker veya politika katmanında doğrulayın ve güvenli bir doğrulama ortamının eksikliğini bir test edilebilirlik açığı olarak kaydedin.
Açık metinli PIN toplamasını, şifreleme anahtarı erişimini, gerçek kart sahibi verilerini, kontrolsüz medya hareketini, canlı nakit durumu değişikliklerini, yıkıcı bozulma olaylarını ve hizmet reddini açıkça yasaklayın. Testi durdurabilir ve durumu eşleştirebilecek isimli bir cihaz sahibi ve şalter operatörü tanımlayın.
Birinci aşama: çağıran-capability grafiğini oluşturun
Middleware’nin her bir müşterisini envanterleyin: kiosk uygulaması, tanı, servis araçları, sağlık acentesi, uzaktan destek, güncelleştirici, kurtarma aracı ve tedarikçi bileşenleri. Çalıştırılabilir kimliği, imzalayıcıyı, hesabı, bütünlük politikasını, yerel IPC uç noktasını, istenen mantıksal hizmeti ve erişilebilir yetenek sınıflarını kaydedin.
Ardından yöneticiyi, hizmet sağlayıcıları, sürücüleri, cihaz yapılandırmasını, mantıksaldan fiziksel eşlemeyi ve çevre birimi tanımlayıcılarını envanterleyin. Dağıtılmış durumu onaylanmış temel çizgiyle karşılaştırın. Uygulamayı değiştirmeden yetki modelini değiştirebilen sessizce yerini tedarikçiye veya tanı aletine gösteren bir mantıksal isim olabilir.
Kanıt erişilebilirliği gösterdiğinde kenarları çizin. Her kenarı yetkilendirme kararını veren bileşenle not edin. Bir kenarda isimli politika sahibi yoksa, mimari muhtemelen konum, işlem konvansiyonu veya gizlilik üzerine dayanmaktadır.
İkinci aşama: broker’da çağıran kimliğini doğrulayın
Yöneticinin veya komşu bir politika bileşeninin onaylanmış uygulamayı, eşdeğer ağ veya IPC erişilebilirliğine sahip başka yerel bir işlemden ayırt edip etmediğini test edin. Tedarikçi bir yeleme veya yalnızca zararsız durum veya kasıtlı olarak reddedilmiş bir test işlemi talep eden minimal inert bir istemci kullanın.
Çağırancının nasıl tanımlandığını kaydedin: işletim sistemi jetonu, hizmet SID’i, sertifika, çalıştırılabilir imzalayıcı veya hash, paket kimliği, kimlik doğrulanmış kanal, broker tarafından verilen yetenek veya bunların bir kombinasyonu. İşlem adı, dosya sistemi yolu, pencere başlığı veya kaynak adresi tek başına zayıf bir kimliktir.
Testi normal, bakım, güncelleme ve kurtarma durumlarında tekrarlayın. Bir tanılama aracının daha geniş bir capability’ye ihtiyaç duyması meşru olabilir; ancak bu yetki isimli bir operatör, onay, sınırlı terminal kapsamı, süre sonu ve daha güçlü bir denetim izi gerektirmelidir. Host’a yüklenen bir tedarikçi aracı otomatik olarak yetkilendirilmiş bir çağıran değildir.
Üçüncü aşama: işlemleri işlem durumuna bağlayın
Çağrıran kimliği kim olduğunu yanıtlar; neden şimdi olmadığını yanıtlamaz. Bir cihaz işlemi ayrıca terminal durumu ve beklenen işlem dizisine de bağlı olmalıdır.
Onaylanmış iş akışı için bir durum makinesi modelleyin: oturum başlar, giriş toplanır, yukarı akış yetkilendirme istenir, sınırlı bir yanıt alınır, ilgili cihaz eylemi uygun hale gelir, tamamlama kaydedilir ve işletme durumu eşleştirilir. Zaman aşımı, iptal, kısmi hata, tekrar mesaj, cihaz kullanılamazlık, yeniden başlatma ve ağ kaybını dahil edin.
Sentetik işlemler ve simüle edilmiş cihazlar kullanın. Yanlış durumda zararsız bir istek gönderin, daha önce tamamlanmış bir isteği tekrarlayın, eski bir yetkilendirme bağlamı sunun ve bir test dizisini kesintiye uğratın. Beklenen sonuç reddetme veya güvenli bir kurtarma durumudur, cihaz etkisi değil. Her geçişin middleware, uygulama, cihaz veya yukarı akış sistem tarafından sahiplenip olmadığını kaydedin.
Rate limit ve freshness de politikanın parçasıdır. Onaylanmış bir çağıran bile hassas bir sınıfı süresiz tekrarlayamamalı veya eski durumu yeniden kullanamamalıdır. Tespit; olağandışı sıralamayı, oranı, çağıranı, terminali ve sonucu belirlemelidir.
Dördüncü aşama: hizmet sağlayıcılarını ve yapılandırmayı koruyun
Hizmet sağlayıcı ikili dosyaları ve yapılandırması soyut işlemleri tedarikçiye özgü cihaz davranışına dönüştürür. Bu nedenle güvenilen yolda yer alırlar ve uygulama kontrolü, korunmuş depolama, imzalı güncellemeler, en az yetkili yürütme ve geri alma yönetimi gerektirirler.
Kimin bir sağlayıcıyı değiştirebileceğini, mantıksal hizmet eşlemesini düzenleyebileceğini, cihaz parametrelerini değiştirebileceğini, tanı bileşenini kaydedebileceğini veya yükleme sırasını değiştirebileceğini gözden geçirin. İntert yapılandırma işaretleri ve imza kontrolleri kullanın; üretim bir sağlayıcıyı değiştirin. Daha düşük güven kimliğinin yönetici tarafından veya yetkili hizmet tarafından daha sonra yüklenen bir dizine içerik yerleştiremeyeceğini doğrulayın.
Tedarikçi destekli simülasyonlarla hata davranışını test edin: sağlayıcı kullanılamaz, geçersiz yapılandırma, cihaz eşleşmesi, eski sürüm ve kısmi başlatma. Sistem yönetimsiz bir sağlayıcıya geri düşmemeli veya mevcutlığı korumak için bilinmeyen bir cihazın sağlıklı olduğunu işaretlememelidir.
Beşinci aşama: PIN alanını ayrı tutun
Şifreleyen PIN klavyesi, özel güvenlik ve uyumluluk alanına aittir. Genel host açık metinli PIN materyali almamalı veya şifreleme anahtarı yetkisine sahip olmamalıdır. PCI PIN Güvenliği, güvenli PIN işleme ve anahtar yönetimi gereksinimlerini yönetir; resmi doğrulama bu kontrollerden sorumlu nitelikli program ve değerlendirici ile birlikte olmalıdır.
Pentest host tarafındaki sınırlamayı hala doğrulayabilir. Onaylanmış cihaz kimliğini ve yaşam döngü durumunu, mimarinin sağladığı yerinde kimlik doğrulanmış iletişimi, bozulma durumu görünürlüğünü, kontrol edilmiş değiştirme ve uygulama günlüklerinde, destek paketlerinde, çöküş boşaltmalarında, izlemelerde veya biletlerde hassas kimlik doğrulama verisinin bulunmamasını onaylayın.
Sentetik giriş ve tedarikçi test modları kullanın. Güvenli iddia, onaylanmayan host çağırancının açık metinli PIN verisi veya şifreleme yetkisine sahip olamayacağı ve beklenmedik cihaz durumunun reddedildiği ve bildirildiğidir. Asla gerçek bir PIN’i kanıtlamak için girmeyin, saklamayın veya bildirin.
Altıncı aşama: cihaz kimliğini ve durumunu belirleyici hale getirin
Mantıksal hizmet isimleri kullanışlıdır; ancak politika nihayetinde bilinen fiziksel bir cihaza ve kabul edilebilir duruma başvurmalıdır. Mevcut olduğunda çevre birimi seri numarasını veya doğrulanmış kimliği, firmware sürümünü, onay durumunu, yapılandırmasını, bozulma durumunu, değiştirme kaydını ve terminal bağlamasını karşılaştırın.
Laboratuvarda değiştirme ve kurtarma iş akışlarını test edin. Yeni eklenmiş veya sıfırlanmış bir cihaz, beklenen arayüzde görünmesi nedeniyle yalnızca güveni miras almamalıdır. Kayıt, onaylanmış bir iş akışı ve envanter güncellemesi, izleme ve sahiplik birlikte gerektirmelidir.
Güçlü bir şifreleme kimliği olmayan sıradan çevre birimleri için telafi edici kontrolleri dokümante edin: fiziksel muhafaza, port kısıtlamaları, imzalı firmware, yapılandırma bütünlüğü, bozulma tespiti, servis onayı ve sıkı eşleştirme. Zayıf bir kimliği güçlü olarak tanımlamayın.
Yedinci aşama: kararı, etkiyi ve mutabakatı ilişkilendirin
En güçlü kanıt zinciri; uygulama isteğini, çağıran kimliğini, politika kararını, service provider’ı, cihaz kimliğini, cihaz sonucunu, transaction state’i ve off-host kaydı tek bir correlation ID altında birbirine bağlar. Her katman farklı bir saat ve tanımlayıcı kaydediyorsa kurum, meşru bir yeniden denemeyi yetkisiz bir diziden ayırt edemeyebilir.
Reddedilen istekleri, zaman aşımını, simüle edilmiş cihaz arızalarını ve kurtarmayı egzersiz yapın. İzlemenin neyin denenip neyin gerçekleştiğini gösterdiğini doğrulayın. Ardından işletme eşleştirmesini doğrulayın: yerel bir başarı ile yukarı akış başarısızlığı belirsiz bir durumu bırakmamalı ve yukarı akış onayı ile cihaz tamamlaması yoksa dokümante edilmiş bir çözüm yolunu takip etmelidir.
Kanıt matrisi
| Sinyal | Ne kanıtlar | Güvenli negatif kontrol | Savunucu doğrulama |
|---|---|---|---|
| Başka bir yerel süreç, onaylanmış uygulamayla aynı capability üzerinden broker’a erişir | Yerel erişimin çağıran yetkilendirmesi yerine kullanıldığını kanıtlar | Tedarikçi emülatörü üzerinden zararsız bir durum sorgusu veya reddedilmesi gereken test isteği gönderin | Politikayı güçlü çağıran kimliğine, uygulama bütünlüğüne, terminale ve çalışma durumuna bağlayın |
| Onaylanmış çağıran, beklenen transaction state dışında bir işlem talep edebilir | Kimlik vardır ancak iş bağlamı yetkilendirmesi eksiktir | Simülatörle sıra dışı veya eski bir istek gönderin | Çağıranı, durumu, sırayı, freshness değerini, politikayı ve sonucu reddetme olayıyla ilişkilendirin |
| Daha düşük güven kimliği sağlayıcıyı veya mantıksal hizmet yapılandırmasını değiştirebilir | Yazılabilir yapılandırma güvenilen cihaz yetkisini yönlendirebilir | İntert bir işaret yerleştirin veya reddedilmiş bir yapılandırma değişikliğine çalışın | Dosyaları koruyun, politika imzalayın, değişiklikleri kaydedin ve host dışı dağıtılmış eşlemeyi doğrulayın |
| Bilinmeyen veya değiştirilmiş çevre birimi mantıksal hizmetin güvenini miras alır | Mantıksal isimlendirme cihaz kimliğine yer tutar | Tedarikçi onaylı bir değiştirme simülasyonu kullanın | Kaydı, onaylanmış durumu, envanter güncellemesi ve terminal bağlamını gerektirin |
| PIN alanı durumu veya hassas veri genel host günlüklerinde görünür | Şifreleme sınırlaması daha düşük güven düzlemine sızar | Sadece sentetik giriş kullanın ve onaylanmış test günlüklerini gözden geçirin | Hassas veriyi kaldırın, tanıları kısıtlayın ve destek paketini işleme doğrulayın |
| Cihaz sonucu, politika kararı ve işlem kaydı korelasyon edilemez | İşlemler güvenilir şekilde araştırılamaz veya eşleştirilemez | Sentetik bir zaman aşımı, iptal ve tekrar dizisi çalıştırın | Ortak korelasyon, güvenilen zaman, terminal kimliği ve açık nihai durumu kullanın |
Bir bulgunun nasıl görüneceği
Tedarikçi laboratuvarında, standart kiosk hesabı altında çalışan inert bir test istemcisi, onaylanmış uygulama kimliğini veya sentetik transaction context’i sunmadan middleware broker üzerinden zararsız bir cihaz durumu geçişi talep edebildi. Broker mantıksal servisi kaydetti ancak çağıran kimliğini veya politika kararını kaydetmedi; merkezi izleme de olay almadı. Hiçbir nakit işlemi, PIN girişi, anahtar materyali, kart hamili verisi veya üretim cihazı kullanılmadı. Cihaz capability’si yerel erişilebilirliğe göre değil, çağıran kimliği ve çalışma durumuna göre yetkilendirilmelidir. Güçlü istemci kimliği, işlem düzeyinde politika, transaction state’e bağlama, off-host karar kaydı ve reddedilen isteği kullanan bir regresyon testi zorunlu kılınmalıdır.
Bulguya eksik yetkilendirme ile ilgilidir, API çağrısının adı ile değil.
Ne olduğunu kanıt olarak adlandırmayacağım
- Host’ta keşfedilen bir XFS uç noktası veya mantıksal hizmet.
- Nakit cihaz kontrolünün kanıtı olarak sunulan başarılı bir durum sorgulaması.
- Dosya, yapılandırma ve güncelleme yönetimi olmadan varsayılan güvenli kabul edilen tedarikçi tarafından imzalanmış bir bileşen.
- Doğrulanmış çağıran kimliği yerine sunulan bir süreç adı.
- Üretim bir işlem olarak sunulan simüle edilmiş bir sonuç.
- Bağlı politika kararı veya işletme eşleştirmesi olmayan bir cihaz etkisi.
- Şiddeti artırmak için toplanan PIN veya kart sahibi verisi.
Savunucu öncelik sırası
İlk olarak, yetkilendirmeyi broker sınırlamasına koyun. Çağırancuyu, uygulama bütünlüğünü, işlemi, terminal durumunu, işlem durumunu, tazelik ve oranı doğrulayın.
İkinci olarak, her istemcinin daraltılmasını sağlayın. Tanı, izleme, destek ve güncelleme bileşenleri miras yerel güven yerine açık yetenek setlerine ihtiyaç duyar.
Üçüncü olarak, sağlayıcıları ve eşlemeyi koruyun. İmzalı ikili dosyalar yeterli değildir; yapılandırma, yükleme yolları, mantıksal hizmet eşlemesi ve geri alma bütünlük gerektirir.
Dördüncü olarak, PIN sınırlamasını koruyun. Açık metinli PIN ve anahtar yetkisini genel host dışında tutun ve hassas veriyi tanıdan uzak tutun.
Beşinci olarak, her belirsiz sonucu eşleştirin. Cihaz, middleware, uygulama ve yukarı akış sistemi tek bir nihai duruma ulaşmalıdır.
Kapanış düşüncesi
Standart arayüzler karmaşık bir ATM varlığını yönetilebilir kılar. İşlemlerini yetkilendirmez. Güvenlik sınırlaması, isimli bir çağırıcıyı ve taze bir işletme durumunu dar tanımlı bir cihaz yeteneğine bağlayan karardır.
Mimari bu kararın nerede alındığını gösteremiyorsa, pentest en önemli soruyu zaten bulmuştur.
Kamu kaynakları ve standartlar bağlamı
- CEN-CENELEC — XFS workshop and releases
- CEN CWA 16926-61:2025 — XFS Manager command-programming reference
- PCI Security Standards Council — PIN Security
- PCI Security Standards Council — ATM Security Guidelines
- NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment
Middleware sürümleri, tedarikçi uygulamaları, cihaz sınıfları ve uyumluluk yükümlülükleri farklıdır. Değerlendirilen varlık için geçerli spesifikasyonları ve tedarikçi sertifikasyon ortamını kullanın.
Bu teknik not ne kadar güncel?
En son kaynak incelemesi, içerik güncellemesi veya yayın tarihi gösterilmektedir.
Birincil kamu kayıtları kontrol edildi. Ortama özgü davranış, ayrıca yeniden üretilmedikçe iddianın dışındadır.