Series · 5 partsATM Security AssessmentPart 2 · 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ıYou are here
- 3Masaüstü Gizlendi. Çalıştırma Sınırı Gizlenmedi.
- 4Cihaz API'si Standarttı. Yetkilendirme Varsayıldı.
- 5Bir ATM Sınırlandırıldı. Filo Güven Yolu Sınırlandırılmadı.
60 saniyede firmware güven zinciri
Bir BIOS veya UEFI parolası, yetkisiz bir kişinin ayarları rastgele değiştirmesini engelleyebilir. Ancak tek başına ATM’nin onaylanmış bir durumdan başladığını kanıtlamaz. Üreticinin kurtarma yolunu kimin çağırabileceği, bir sıfırlamanın kime atfedilebileceği, harici ortamdan önyüklemenin (external boot) hala mümkün olup olmadığı, Secure Boot anahtarlarının değiştirilip değiştirilemeyeceği, disk kilidinin açılmasının ölçülen platform durumuna bağlı olup olmadığı veya güvenlik ekibinin bunlardan haberdar olup olmayacağı hakkında hiçbir şey söylemez.
Asıl sorulması gereken soru “Parola atlatılabilir mi?” değildir. Asıl soru şudur:
Platform; herhangi bir normal, servis, kurtarma, güncelleme veya donanım bakım yolu üzerinden onaylanmamış bir boot durumuna geçebilir mi — ve eğer geçebilirse, merkezi güvenlik mimarisi bu geçişi önleyebilir, tespit edebilir, sınırlandırabilir ve sistemi güvenli duruma döndürebilir mi?
Bu bölüm, söz konusu soruyu savunulabilir bir test planına dönüştürür. Üretici onaylı bir laboratuvar terminali veya mülkiyeti, kurtarma medyası ve geri alma desteği bilinen hurdaya çıkarılmış bir cihaz için tasarlanmıştır. Master parola listelerini, kart seviyesinde sıfırlama noktalarını, EEPROM prosedürlerini, elektriksel manipülasyonları, firmware flash’lama tariflerini ve sahada kurulu bir ATM’yi devre dışı bırakma yönergelerini kasıtlı olarak hariç tutar. Bu detaylar bulgunun kalitesine hiçbir katkı sağlamazken yalnızca bir saldırı kılavuzu üretir. Asıl önemli olan kanıt, güven sınırındaki kontrol kararıdır.
Parola bir güvenlik kapısıdır, kök güven (Root of Trust) değildir
Firmware yapılandırma parolaları faydalıdır. Benzersiz olmalı veya merkezi olarak yönetilmeli, varsayılan parolaların yeniden kullanımına karşı korunmalı, hesap verebilir bir yaşam döngüsüyle idare edilmeli ve güvenlikle ilgili ayarlar değiştirilmeden önce zorunlu kılınmalıdır. Ancak parola çok daha büyük bir sistemin yalnızca bir parçasıdır.
Bu sistem; firmware kodunu, değiştirilebilir yapılandırmayı, imza anahtarı veritabanlarını, boot aygıtı politikasını, Option ROM’ları, kurtarma davranışını, güncelleme doğrulamasını, geri alma (rollback) kurallarını, TPM’i, depolama şifrelemesini, işletim sistemi yükleyicisini ve uzaktan sağlık değerlendirmesini içerir. Aynı zamanda insanları da kapsar: Desteklenen bir kurtarma prosedürüne ihtiyaç duyan saha mühendisi, kurtarma anahtarlarını tutan ekip, bir güncellemeyi imzalayan üretici ve güven kaybını fark etmesi beklenen güvenlik operatörü.
Dolayısıyla bir terminal güçlü bir firmware parolasına sahip olmasına rağmen şu şekillerde başarısız olabilir:
- Mühendise yardımcı olan servis veya kurtarma yolu, güçlü bir kimlik doğrulaması, onay mekanizması veya kalıcı bir denetim kaydı olmaksızın bir güvenlik kontrolünü sıfırlar;
- Boot sırası normal arayüzde kilitli görünür ancak desteklenen farklı bir çalışma durumu daha zayıf bir politika uygular;
- Secure Boot etkindir ancak Platform Key (PK) ve izin verilen imza veritabanlarının (db) sahipliği belirsizdir veya değişiklikler izlenmez;
- İşletim sistemi yalnızca imzalı bileşenlerden başlar ancak onaylanan bir imza terminal taban çizgisinin güvenmeyi amaçlamadığı bir bileşeni yetkilendirir;
- Depolama şifrelenmiştir ancak kilit açma yolu beklenen platform durumuna bağlı değildir veya kurtarma sırrı çok geniş kitlelerin erişimine açıktır;
- Terminal, yapılandırma veya bütünlük değişikliğini yalnızca yerel olarak kaydeder ve aynı güven kaybı tek kanıtı silebilir.
Test, herhangi bir onay kutusunu tek başına kanıt olarak kabul etmemelidir. Güç açılmasından uygulama hazır olana kadar zinciri takip etmeli ve her geçişte bağımsız bir teyit aramalıdır.
Aşama sıfır: güvenli deneyi tanımlayın
Firmware testleri, diğer tüm güvenlik kontrollerinin dayandığı temel durumu değiştirebilir. Bu durum, angajman kurallarını (rules of engagement) teknik kontrolün ayrılmaz bir parçası haline getirir; yalnızca bir formalite evrakı değildir.
Sahada kullanılan model ve taban çizgisiyle eşleşen bir laboratuvar terminali veya hurdaya çıkarılmış bir cihaz kullanın. Seri numarasını, kart revizyonunu, firmware sürümünü, beklenen yapılandırma profilini, depolama durumunu, TPM mülkiyetini, onaylanmış Secure Boot durumunu, kurtarma anahtarı sorumlusunu ve üretici destekli kurtarma prosedürünü kaydedin. Herhangi bir negatif kontrol denenmeden önce orijinal durumu hem yönetim düzlemi üzerinden hem de yerel olarak kayıt altına alın.
Durdurma koşulları net olmalıdır. Terminal canlı anahtarlar, gerçek kart hamili verileri, mutabakatı yapılmamış nakit bakiyesi, müşteri bağlantısı veya müşteri/üretici tarafından önceden tatbik edilmemiş bir kurtarma yolu içeriyorsa ilerlemeyin. Yıkıcı fiziksel kurcalama testleri yapmayın veya kart seviyesinde bir prosedür uydurmayın. Desteklenen kurtarma yöntemi test ünitesini geri getiremiyorsa, bu durum dayanıklılık ve test edilebilirlik hakkında bir kanıttır; canlı donanım üzerinde deney yapma izni değildir.
Her test için önceden dört beklenen sonuç tanımlayın:
- Yerel engelleme veya kurtarma kararı;
- Terminal kimliği ve güvenilir zaman damgasıyla cihaz dışı (off-host) olay kaydı;
- Güven tesis edilemezse sınırlandırma (containment) durumu;
- Terminali onaylanmış taban çizgisine döndüren yöntem.
Bu beklentiler olmadan, “başarılı” olan bir yeniden başlatma yalnızca erişilebilirliği kanıtlar. Bütünlüğü kanıtlamaz.
Aşama bir: firmware üzerindeki her yetkiyi envantere alın
Kimin neyi değiştirebileceğini haritalandırarak başlayın. Cevap nadiren sadece “BIOS yöneticisi”dir. Platform durumu; terminal sahibi, ATM üreticisi, anakart üreticisi, işletim sistemi dağıtım ekibi, saha servis sağlayıcısı, firmware güncelleme hattı, kurtarma medyası sorumlusu ve anahtar yönetim ekibinden etkilenebilir.
Her yetki için kimlik mekanizmasını, onay sınırını, hedef kapsamını, kimlik bilgisi veya anahtar yaşam döngüsünü, denetim hedefini ve acil durum sürecini kaydedin. Platform anahtarının (PK) ve izin verilen imza veritabanlarının kime ait olduğunu; bir firmware paketini kimin yetkilendirebileceğini; bir terminali kimin kurtarma moduna alabileceğini; bir depolama kurtarma sırrını kimin çekebileceğini ve bu işlemlerden herhangi biri gerçekleştiğinde kime bildirim gittiğini sorgulayın.
Bu adım en yaygın tasarım hatasını ortaya çıkarır: Bir kontrol teknik olarak etkindir ancak yaşam döngüsünün sahibi yoktur. Anahtar kaydı, iptal (revocation), firmware bakımı ve sertifika yenilemesi yönetilmiyorsa “Secure Boot: On” yeterli değildir. Bir üretici kurtarma yolu tüm filoda ortaksa veya onaylanmış tek bir müdahaleye atfedilemiyorsa “Password: Set” yeterli değildir.
Çıktı bir ekran görüntüsü koleksiyonu değil, bir yetki grafiği (authority graph) olmalıdır. Durum değiştiren her yolun tanımlı bir sahibe ve bağımsız bir kanıt kaynağına ihtiyacı vardır.
Aşama iki: parola ve kurtarma semantiğini doğrulayın
Amaç, yapılandırma yetkisinin desteklenen tüm çalışma durumlarında geçerliliğini koruyup korumadığını test etmektir. Yalnızca üretici onaylı iş akışını ve test için sağlanan hesapları veya sırları kullanın. Denetçinin, kurtarma tasarımının zayıf olduğunu kanıtlamak için gizli bir arka kapı bulmasına gerek yoktur.
İlk olarak parolanın, sahibinin koruduğuna inandığı güvenlikle ilgili her değişikliği gerçekten koruduğunu doğrulayın: Boot kaynağı, Secure Boot durumu, anahtar kaydı, firmware güncelleme politikası, aygıt güvenliği ve kurtarma yapılandırması. Ardından hata davranışını doğrulayın. Tekrarlanan geçersiz kimlik doğrulamaları, kontrolsüz bir hizmet dışı bırakma (DoS) durumu yaratmadan sınırlı ve belgelenmiş bir yanıt vermelidir.
Ardından meşru kurtarma yolunu ayrıcalıklı bir iş süreci olarak inceleyin. Tanımlı bir kimlik gerektiriyor mu? Onay belirli bir terminale ve tek bir bakım penceresine özgü mü? Yanıt benzersiz mi yoksa merkezi olarak mı yönetiliyor? Eylem, yerel durum değiştirilmeden önce cihaz dışında bir olay üretiyor mu? Kurtarma işlemi Secure Boot, boot sırası, TPM ve disk şifreleme politikasını koruyor veya kasıtlı olarak yeniden tesis ediyor mu? Kurum, bir destek müdahalesini yetkisiz bir kurcalamadan ayırt edebiliyor mu?
Bir kurtarma özelliği sırf var olduğu için bir zafiyet değildir. Aynı güvenlik sınırını daha zayıf bir kimlikle, daha geniş bir kapsamla, eksik telemetriyle veya güvensiz bir kurtarma sonrası varsayılanıyla geçebildiğinde bir bulgu haline gelir.
Aşama üç: negatif kontroller dahil boot politikasını kanıtlayın
Beklenen boot yolu bir politika olarak yazılmalıdır: Onaylanmış firmware kontrolü yalnızca onaylanmış bir boot kaynağına devreder; bu kaynak kabul edilebilir imzalı bir yükleyici sunar; kabul edilen anahtar kümesi sahiplidir ve yönetilir; ve bir hata durumunda sistem daha zayıf bir yoldan sessizce devam etmez.
Laboratuvarda, yalnızca karar mekanizmasını ortaya çıkarmak için tasarlanmış zararsız ve kurum kontrollü medyalar kullanın. Bir artefakt onaylanmış taban çizgisini temsil edebilir; diğeri ise doğru biçimlendirilmiş ancak terminalin onaylı güven kümesinin dışında olabilir. Yakalanması gereken sonuç kod yürütme değil, firmware’in verdiği karardır. Onaylanmamış artefakt yetki kazanmadan önce reddedilmeli ve ret veya beklenmeyen kaynak olayı terminalin silemeyeceği bir şekilde cihaz dışında görünmelidir.
Desteklenen her durumu kontrol edin: Normal başlatma, yetkili bakım, üretici kurtarma modu, güncelleme hatası ve servisten dönüş. Yalnızca sıradan önyükleme sırasında geçerli olan bir politika, gerçek bir platform politikası değildir. Ayrıca boot kaynağı önceliğinde, Secure Boot durumunda, kurulum (setup) modunda veya anahtar veritabanındaki bir değişikliğin sessizce gerçekleşemeyeceğini ve makineyi sanki sağlıklıymış gibi çalışır durumda bırakamayacağını doğrulayın.
Secure Boot imza tabanlı denetim sağlar ancak imzanın geçerliliği ile terminalin onayı aynı şey değildir. Platform geniş kapsamlı bir imza yetkilisine güvenirken, ATM filosu çok daha dar bir imaj kümesine güvenmek isteyebilir. Bu boşluğu belgeleyin ve hangi sonraki kontrolün (allowlist, imaj ölçümü, attestation politikası veya dağıtım kapısı) güven kümesini terminal için yeterince spesifik hale getirdiğini belirleyin.
Aşama dört: measured boot’u operasyonel bir karara bağlayın
Measured boot tek başına bir önleme mekanizması değil, bir kanıttır. TPM, firmware’den erken boot aşamasına kadar güvenlikle ilgili ölçümleri kaydedebilir ancak bir sistemin bu ölçümleri değerlendirmesi ve sağlıksız bir terminalin ne yapabileceğine karar vermesi gerekir.
Onaylanmış taban çizgisi için bilinen iyi ölçümü veya attestation sonucunu yakalayın. Ardından farklı bir durum üretmek için laboratuvarda üretici destekli, geri alınabilir bir yapılandırma değişikliği yapın. Uzak doğrulayıcının (remote verifier) farkı gördüğünü, doğru terminali tanımladığını ve belgelenmiş politikayı uyguladığını doğrulayın. Mimariye bağlı olarak bu karantinaya alma, yönetim eylemlerini engelleme, uygulamanın açılmasını reddetme veya yalnızca bakım moduna geçme anlamına gelebilir. “ATM başka her yerde güvenilmeye devam ederken panodaki rengin değişmesi” anlamına gelmemelidir.
Ölçüm içeriğinin yanı sıra güncelliği (freshness) ve kimliği de test edin. Kaydedilmiş eski bir sağlıklı sonuç, daha sonraki güvenilmeyen bir boot için kanıt olarak yeniden kullanılamamalıdır. Doğrulayıcı kanıtı hangi terminalin ürettiğini, ne zaman üretildiğini, hangi taban çizgisinin kullanıldığını ve taban çizgisi değişikliklerinin nasıl onaylandığını bilmelidir.
Son olarak, ölçüm kanıtı eksik olduğunda ne olduğunu test edin. Attestation servisinin, ağın veya ajanın kaybı, güven eksikliğini otomatik olarak tam bir güvene dönüştürmemelidir. İş birimi erişilebilirlik için sınırlı bir derecelendirilmiş durum (degraded state) seçebilir ancak bu istisnanın açık bir süreye, kapsama, uyarıya ve mutabakata ihtiyacı vardır.
Aşama beş: depolama şifrelemesini platform durumuna bağlayın
Tam disk şifrelemesi (Full-disk encryption), verileri ancak kilit açma yetkisi koruması gereken durum kadar güçlüyse korur. TPM destekli Windows sistemlerinde BitLocker platform doğrulaması, sistem doğru yapılandırıldığında Secure Boot durumu da dahil olmak üzere TPM ölçümlerini kullanabilir. Denetim, şifreleme simgesinin varlığından çıkarım yapmak yerine terminalin fiili politikasını doğrulamalıdır.
Koruyucu (protector) türünü, hedeflenen platform doğrulama profilini, kurtarma anahtarı sahibini, emanet (escrow) konumunu, anahtar çekme onaylarını, rotasyon sürecini ve denetim hedefini kaydedin. Doğrulanan durumu değiştirmesi beklenen, geri alınabilir ve üretici destekli bir laboratuvar değişikliği yapın. Otomatik kilit açmanın hiçbir şey değişmemiş gibi devam etmediğini ve kontrollü kurtarma sürecinin hem kullanılabilir hem de hesap verebilir olduğunu doğrulayın.
Negatif kontrol boot öncesi (pre-boot) kararında durur. Bir anahtarı çıkarmaya, bir diski kopyalamaya veya terminal verilerine erişmeye gerek yoktur. Değişen platform durumuyla ilişkilendirilmiş ve denetlenen bir kurtarma iş akışına sahip engellenmiş bir otomatik kilit açma, bir dosya sistemini açmaktan çok daha güçlü bir kanıttır.
Ayrıca kurtarma operasyonunu yüksek değerli bir yönetimsel eylem olarak test edin. Tek bir destek rolü her terminal için kurtarma materyali çekebiliyorsa veya anahtar çekme işlemi güvenlik ekibine görünmüyorsa, şifreleme teknik olarak doğru olabilir ancak kontrol düzlemi tehlikeli derecede geniş kalmıştır.
Aşama altı: firmware güncelleme ve geri alma bütünlüğünü test edin
NIST’in platform firmware rehberi, dayanıklılığı koruma, tespit ve kurtarma ekseninde tanımlar. Güncelleme kanalı her üçünü de karşılamalıdır. Bir firmware paketi kabul edilmeden önce doğrulanmalı, yetkili bir süreçle uygulanmalı, uygunsuz geri almaya (rollback) karşı korunmalı ve kurulum başarısız olduğunda kurtarılabilir olmalıdır.
Üretici yayınından terminal kurulumuna kadar tüm yolu haritalandırın: Paket kaynağı, imza doğrulaması, onay, hazırlık (staging), hedefleme, bakım penceresi, kurulum sonucu, sürüm envanteri, geri alma kararı ve cihaz dışı denetim. Canlı olmayan bir ortamda üretici tarafından sağlanan test paketleri veya metaverilerle kontrolü doğrulayın. Amaç, kötü amaçlı bir firmware imajı oluşturmak değil; yetkisiz veya politika dışı bir güncellemenin reddedildiğini gözlemlemektir.
Güncelleme yolları arasındaki eşdeğerliğe özellikle dikkat edin. Merkezi olarak yönetilen bir paket iyi denetlenebilirken yerel bir servis iş akışı, acil durum kurtarma imajı veya yedek bir kart farklı bir güven kümesini kabul edebilir. Firmware durumunu belirleyebilen her meşru yol aynı güvence modeline ait olmalıdır.
Kurtarmanın da bilinen iyi bir hedefe ihtiyacı vardır. Geri yüklenen imaj eskiyse, imza anahtarları iptal edilmişse, güvenlik ayarları varsayılana dönmüşse veya yönetim düzlemi hala önceki sürümün yüklü olduğuna inanıyorsa “terminal yeniden başladı” ifadesi yeterli değildir. Kurtarma işlemi ancak yerel durum, uzaktan envanter, attestation, depolama politikası, izleme ve operasyonel sahiplik yeniden uzlaştığında tamamlanmış sayılır.
Aşama yedi: fiziksel ve firmware olaylarını uzaktan görünür kılın
Fiziksel erişim tehdit modelini değiştirir ancak savunucunun görünürlüğünü silmemelidir. Test; yıkıcı manipülasyon yapmadan üretici destekli kasa, servis kapısı, boot politikası, kurtarma girişi, yapılandırma, TPM ve firmware güncelleme olaylarını doğrulamalıdır.
Her olayın terminal kimliğine, olay türüne, sonuca, güvenilir zamana, varsa operatör veya iş akışı kimliğine ve planlı bakımı beklenmeyen değişiklikten ayırt etmeye yetecek bağlama ihtiyacı vardır. İletim, terminalin yazma yetkisinin dışındaki bir sisteme yapılmalıdır. Olay sırasında uç nokta çevrimdışıysa, tasarım dayanıklı arabelleğe almayı, daha sonra mutabakatı ve kabul edilebilir maksimum kör süreyi tanımlamalıdır.
Ardından müdahale sürecini tatbik edin. Operatör bir şubeyi devre dışı bırakmadan tek bir terminali izole edebilir mi? Olay izini koruyabilir, terminali taban çizgisiyle karşılaştırabilir, kurtarma sırlarının kullanılıp kullanılmadığını belirleyebilir ve cihazı onaylanmış bir imajla tekrar hizmete alabilir mi? Uygulanabilir bir kurtarma yolu olmayan tespit, yalnızca kuru bir bildirimden ibarettir.
Kanıt matrisi (Evidence matrix)
| Sinyal | Neyi kanıtlar | Güvenli negatif kontrol | Savunucu doğrulaması |
|---|---|---|---|
| Firmware ayarları parola sorar ancak desteklenen kurtarma yolu daha zayıf kimliğe sahiptir veya onaysızdır | Parola yapılandırma yetkisini değil, yalnızca tek bir arayüzü korur | Lab cihazında yalnızca belgelenmiş kurtarma iş akışını uygulayın ve donanım müdahalesinden önce durun | Tanımlı kimlik, terminal başına onay, sınırlı kapsam, süre sonu ve cihaz dışı olay kaydı zorunlu kılın |
| Boot önceliği veya Secure Boot durumu bir bakım veya kurtarma durumunda eşdeğer kontroller olmadan değişebilir | Normal arayüz tüm çalışma durumlarında bağlayıcı değildir | Üretici onaylı bir lab durumu kullanın ve reddedilmesi beklenen zararsız tek bir politika değişikliğini deneyin | Yerel durumu, uzak envanteri, değişiklik kaydını ve uyarıyı karşılaştırın; beklenmeyen durumu karantinaya alın |
| Onaylı güven kümesinin dışındaki kurum kontrollü bir artefakt ret dışında bir boot kararına ulaşır | İmza politikası veya boot kaynağı politikası ATM taban çizgisinden daha geniştir | Etkisiz, canlı ortamda olmayan test medyası sunun; asla bir payload çalıştırmayın | Firmware kararını, güvenilir anahtar yolunu, terminal kimliğini ve uzaktan tespiti yakalayın |
| TPM ölçümleri değişir ancak terminal tam güvenini korur | Ölçüm, relying-party politikası olmadan mevcuttur | Geri alınabilir, desteklenen tek bir lab yapılandırma değişikliği oluşturun | Güncel attestation, doğru taban çizgisi, terminal eşleşmesi ve karantina/bakım durumu teyit edin |
| Doğrulama profilini bozması beklenen bir değişiklikten sonra otomatik depolama kilit açma devam eder | Şifreleme, sahibinin varsaydığı platform durumuna bağlı değildir | Desteklenen geri alınabilir bir değişiklik yapın ve kilit açma kararında durun | Koruyucu politikasını, kurtarma denetimini, geri yüklemeyi ve anahtar sorumlusu onayını teyit edin |
| Firmware güncelleme reddi, geri alma veya kurtarma yalnızca yerel olarak görünür | Terminal, platform değişikliğinin tek kanıtını kaybedebilir veya yeniden yazabilir | Onaylanan lab iş akışı üzerinden üretici test metaverisi veya politika dışı bir paket gönderin | İmza sonucunu, aktörü, hedefi, sürümü, politikayı, zamanı ve nihai envanteri cihaz dışında ilişkilendirin |
| Kurtarma işlemi boot edilebilir bir terminal döndürür ancak yapılandırma, attestation, envanter veya izleme çelişir | Güven geri yüklenmeden yalnızca erişilebilirlik geri yüklenmiştir | Onaylanmış kurtarma imajını çalıştırın ve her kontrol düzlemi iddiasını karşılaştırın | Canlı hizmet başlamadan önce bir mutabakat kapısı zorunlu kılın |
Bir bulgu nasıl yapılandırılmalıdır?
“BIOS parolası atlatma” başlıklı bir bulgudan kaçının. Bu başlık dikkati bir tekniğe odaklar ve genellikle kanıtlananın ötesinde anlamlar yükler. Bunun yerine başarısız olan güvenlik kuralını (security invariant) raporlayın.
Daha güçlü bir bulgu şöyle yazılır:
Yetkilendirilmiş laboratuvar terminalinde, belgelenmiş firmware kurtarma iş akışı, servis rolünün terminale özel bir onay olmaksızın kurulum (setup) erişimini geri yüklemesine izin vermiştir. Bu eylem merkezi izleme sisteminde bir olay üretmemiş ve uzak envanter önceki firmware güvenlik durumunu bildirmeye devam ederken terminal normal hizmete dönmüştür. Kart seviyesinde hiçbir prosedür, harici boot payload’u, depolama erişimi, PIN verisi, çevre birimi komutu veya nakit durumu kullanılmamıştır. Dolayısıyla güvenliği ihlal edilmiş bir servis kimliği, zamanında tespit veya mutabakat olmaksızın platform güven politikasını değiştirebilir. Terminal başına onay zorunlu kılınmalı, kurtarma işlemi tanımlı bir operatöre bağlanmalı, olay cihaz dışına iletilmeli ve firmware yapılandırması, attestation, depolama politikası ve envanter uzlaşana kadar hizmete dönüş engellenmelidir.
Bu ifade; zafiyetli yetkiyi, eksik kontrolü, gözlemlenen kanıtı, kasıtlı olarak sınırlandırılmış testi ve regresyon koşulunu tanımlar. Mühendislik ekiplerine donanımı sıfırlama yollarının bir listesinden çok daha fazla değer sağlar.
Neleri kanıt olarak kabul etmem?
- Bir fotoğrafta gösterilen firmware parola istemi.
- Anahtar sahipliği, değişiklik denetimi ve negatif doğrulama olmaksızın etkin olduğu bildirilen Secure Boot.
- Koruyucusu ve platform doğrulama politikası hakkında kanıt bulunmayan şifrelenmiş bir disk.
- Güncel bir ölçüm, doğrulayıcı, taban çizgisi ve relying-party kararı olmaksızın envanterde yer alan bir TPM.
- Durum mutabakatı yapılmadan kurtarma sonrasında gerçekleşen başarılı bir yeniden başlatma.
- Güveni sorgulanan terminalin kendisi tarafından kontrol edilen yerel bir denetim kaydı.
- Canlı terminallerin aynı karta, firmware’e, yapılandırmaya veya servis prosedürüne sahip olduğunun kanıtı olarak sunulan bir laboratuvar sonucu.
- Güvenli bir kontrol kararı aynı riski kanıtlayabilecekken yapılan yıkıcı bir donanım gösterisi.
Değerlendirmenin kalitesi, güven kaybını ne kadar kesin kanıtladığıyla ölçülür; cihaza zarar vermeye ne kadar yaklaştığıyla değil.
Savunucu öncelik sırası
İlk olarak, kurtarmayı ayrıcalıklı bir kontrol düzlemi eylemi olarak yönetin. Firmware kurtarma ve depolama anahtarı çekme işlemleri tanımlı kimliğe, terminal başına onaya, sınırlı süreye, bağımsız günlük kaydına ve mutabakata ihtiyaç duyar. Meşru bir amaca hizmet etmeleri onları düşük riskli kılmaz.
İkinci olarak, boot politikasını açık hale getirin. Onaylanan boot kaynağını, imza güven kümesini, firmware yapılandırmasını, Option ROM politikasını, ölçüm taban çizgisini ve hata davranışını tanımlayın. Bir onay kutusu bir politika değildir.
Üçüncü olarak, ölçümleri yaptırıma bağlayın. Uzaktan attestation, sağlıksız veya sessiz bir cihazın ne yapmasına izin verildiğini değiştiren güncel ve terminale bağlı bir sonuç üretmelidir.
Dördüncü olarak, şifreleme ve kurtarmayı aynı güven modeline bağlayın. Otomatik kilit açma beklenen platform durumuna bağlı olmalı; kurtarma materyali dar bir yetkili grubuna ve dayanıklı bir denetim izine sahip olmalıdır.
Beşinci olarak, firmware kurtarma sürecini henüz ihtiyaç duyulmadan tasarlayın. Bilinen iyi bir imajı koruyun, süreci tatbik edin, uygunsuz geri almayı tespit edin ve hizmet devam etmeden önce tüm yerel ve uzak gerçeklik kaynaklarının uzlaşmasını şart koşun.
Kapanış düşüncesi
BIOS parolası önemlidir ancak güvenlik sınırı değildir. Asıl sınır; hangi firmware’in çalışacağına, hangi yapılandırmanın kabul edileceğine, hangi kaynağın önyükleme yapabileceğine, hangi ölçüme güvenileceğine, hangi diskin açılabileceğine ve hangi kurtarmanın terminali hizmete döndüreceğine karar verebilen her bir yetki noktasıdır.
Güçlü bir ATM firmware değerlendirmesi birine bir kutuyu nasıl kıracağını öğretmez. Kurumun kutu bakıma alındığında, sıfırlandığında, güncellendiğinde, ölçüldüğünde, izole edildiğinde ve kurtarıldığında güveni koruyup koruyamayacağını kanıtlar.
Savunucuya bırakılacak soru basittir: Parola yarın ortadan kaybolsaydı, hangi bağımsız kontroller onaylanmamış bir boot’u yine de engellerdi — ve hangi uzaktan kanıtlar bunların çalıştığını ispatlardı?
Kamuya açık kaynaklar ve standartlar
- NIST SP 800-193 — Platform Firmware Resiliency Guidelines
- NIST SP 800-147B — BIOS Protection Guidelines for Servers
- UEFI 2.10 — Secure Boot and Driver Signing
- Microsoft — Secure the Windows boot process
- Microsoft — BitLocker preboot recovery
- PCI Security Standards Council — ATM Security Guidelines
PCI ATM belgesi, geçerli PCI standartlarının veya üretici prosedürlerinin yerine geçen bir belge değil, bilgilendirici bir ektir. Kontrollerin kesin mevcudiyeti terminal jenerasyonuna, firmware üreticisine, işletim sistemine, dağıtım mimarisine ve edinen (acquirer) kuruluşa göre değişir. Canlı mimariyi bu sistemlerin sahipleriyle doğrulayın; aktif firmware ve kurtarma testlerini yetkilendirilmiş laboratuvar ortamında tutun.
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.