OT Zafiyet Yönetimi: Yama Yapılamayan Sistemlerde Risk Kararı

IT’de zafiyet yönetimi “tara, önceliklendir, yamala” döngüsüdür. OT’de bu döngü son adımda tıkanır. PLC firmware güncellemesi üretim duruşu ister, HMI yazılımı yalnız üreticinin onayladığı Windows sürümünde desteklenir, bazı cihazlar için düzeltilmiş sürüm hiç çıkmaz. Bu rehberde yamanın mümkün olmadığı ya da ertelenmesi gerektiği durumda kararın nasıl verildiğini anlatıyoruz: bilgi kaynakları, önceliklendirme, karar tablosu ve telafi edici kontroller.

OT’de zafiyet yönetimi neden farklı işler

Fark yalnız yamanın zorluğundan gelmez. Zafiyetin bulunma yolu, etkisi ve çözümü de değişir:

• Tespit: OT ağında kimlik doğrulamalı zafiyet taraması çoğu zaman uygun değil. Eşleme, envanterdeki ürün ve firmware bilgisinin tedarikçi bültenleriyle karşılaştırılmasıyla yapılır. Envanterde firmware sütunu boşsa zafiyet listesi de eksiktir; bu yüzden OT pasif varlık keşfi sürecin ön koşulu.
• Etki: CVSS puanı teknik etkiyi ölçer, prosese etkiyi ölçmez. Aynı zafiyet test tezgâhındaki bir PLC’de düşük, kazan kontrol sisteminde yüksek risk demektir.
• Çözüm: Firmware güncellemesi bakım duruşu, devreye alma testi ve bazen OEM onayı gerektirir. Bazı ürünler için üretici yalnız azaltma önerisi yayımlar ya da ürün desteği bitmiştir.
• Zaman: Yama bir sonraki planlı duruşa kadar bekleyebilir; bu süre aylarla ölçülür. Aradaki süre telafi edici kontrollerle yönetilir.

IT tarafındaki tarama, SLA ve raporlama döngüsü zafiyet yönetimi programı rehberinde anlatılıyor; buradaki konu o programın OT kolu.

Zafiyet bilgisinin kaynakları ve tedarikçi bültenleri

OT zafiyetleri için tek kaynak yetmez. Takip edilmesi gereken başlıca kaynaklar:

• Üretici PSIRT bültenleri: Siemens ProductCERT, Rockwell Automation, Schneider Electric, ABB gibi üreticilerin güvenlik bildirimleri. Etkilenen sürümler ve üreticinin önerdiği azaltma adımları en ayrıntılı burada yazar.
• CISA ICS Advisories: Birçok üreticinin bildirimini ortak bir formatta yayımlar; sömürünün uzaktan yapılabilirliği ve saldırı karmaşıklığı gibi bilgileri tek sayfada toplar.
• CISA Known Exploited Vulnerabilities (KEV) kataloğu: Aktif sömürüldüğü bilinen zafiyetler. OT ürünleri ve OT’de kullanılan Windows, VPN ve uzak erişim bileşenleri için güçlü bir önceliklendirme girdisi.
• Makine üreticisi (OEM) ve sistem entegratörü: Makinenin içindeki bileşenlerin hangi sürümde olduğunu ve güncellemenin makine garantisine etkisini bilen taraf.

Bültenleri elle takip etmek, ürün sayısı arttıkça çöker. Birçok üretici ve CISA bültenlerini makine tarafından okunabilir CSAF formatında da yayımlıyor; envanterle otomatik eşleştirme bu formatla kurulabilir. Elle takip edilen bülten, okunmayan bültendir.

ICS bültenini değerlendirme kontrol listesi

• Etkilenen ürün ve sürüm aralığı envanterdeki hangi cihazlarla eşleşiyor?
• Zafiyet hangi arayüzden sömürülüyor: ağ servisi, web arayüzü, mühendislik protokolü, yerel erişim?
• Kimlik doğrulama gerekiyor mu, kullanıcı etkileşimi gerekiyor mu?
• Sonuç ne: bilgi ifşası, servis dışı kalma, kod çalıştırma, program değiştirme?
• Kamuya açık sömürü kodu var mı, KEV kataloğunda yer alıyor mu?
• Üretici yama mı, yapılandırma değişikliği mi, yalnız azaltma önerisi mi sunuyor?
• Yama yeniden başlatma, program yeniden yükleme veya donanım değişikliği gerektiriyor mu?

Önceliklendirme: erişilebilirlik, sömürü ve sonuç

OT’de CVSS temel puanını tek sıralama ölçütü yapmak, yanlış işlerin önce yapılmasına yol açar. Örneğin 9.8 puanlı ama yalnız hücre içinden erişilen bir zafiyet için hat durdurulurken, internete açık bir VPN cihazındaki 7.5 bekletilir. Daha işlevsel bir model üç soruyu birlikte sorar:

1. Erişilebilirlik: Zafiyetli arayüze kim ulaşabilir? İnternetten, IT ağından, yalnız OT DMZ’den, yalnız hücre içinden? Segmentasyonun kâğıtta değil gerçekte nasıl uygulandığı burada belirleyici. Firewall kuralları okunmadan “bu PLC’ye dışarıdan erişilemez” denmez; sahada en sık gördüğümüz sürpriz, unutulmuş bir “any” kuralı veya OEM için açılıp kapatılmamış bir NAT’tır.
2. Sömürülebilirlik: Aktif sömürü (KEV) veya kamuya açık sömürü kodu var mı? Sömürü otomatikleştirilebilir mi?
3. Sonuç: Varlığın proses içindeki rolü ve kritiklik derecesi. Emniyet fonksiyonu taşıyan, darboğaz hatta yer alan veya yedeği olmayan sistemler üst sırada.

CISA’nın SSVC (Stakeholder-Specific Vulnerability Categorization) modeli bu mantığı yapılandırılmış bir karar ağacına çevirir: sömürü durumu, otomatikleştirilebilirlik, teknik etki ve görev/insan güvenliği üzerindeki etki birlikte değerlendirilir, sonuç Track, Track*, Attend veya Act olarak çıkar. OT için “görev ve insan güvenliği” ekseni proses sonuçlarıyla doğal olarak örtüşür.

Karar tablosu: yama, azalt, kabul et

Durum	Önerilen karar	Zamanlama
Aktif sömürü var, arayüz IT’den veya uzaktan erişilebilir	Hemen azalt; yamayı en yakın pencereye planla	Azaltma acil, yama ilk uygun duruş
Kamuya açık sömürü var, arayüz yalnız OT zonundan erişilebilir	Azalt ve izle; yamayı planlı duruşa al	Bir sonraki planlı duruş
Sömürü bilgisi yok, kritik varlık	Yamayı planlı duruşa al; erişimi daralt	Rutin bakım takvimi
Yama yok veya ürün desteği bitmiş	Kalıcı telafi edici kontrol + yenileme planı	Kontrol hemen, yenileme bütçe döngüsünde
Erişim yok denecek kadar sınırlı, sonuç düşük	Gerekçeli risk kabulü, süreli	Belirli tarihte yeniden değerlendirme

Tablodaki “azalt” kararı yamanın yerine geçen kalıcı bir çözüm değil; yamaya kadar riski taşınabilir seviyede tutan bir ara önlem. Ara önlem kalıcılaşırsa sorun büyür. Risk kabulü de süresiz verilmez: her kabulün sahibi ve yeniden değerlendirme tarihi olur.

Telafi edici kontroller

Yama yapılamıyorsa kontrol, zafiyetin sömürülme yoluna göre seçilir. “Segmentasyon yaptık” cümlesi yeterli değil; kontrol, ilgili arayüze giden yolu somut olarak kapatmalı.

Sömürü yolu	Telafi edici kontrol
Ağ servisi (web arayüzü, SNMP, FTP vb.)	Kullanılmıyorsa servisi kapat; kullanılıyorsa hücre firewall’ında yalnız gerekli kaynaklara izin ver
Mühendislik protokolü	PLC erişimini yalnız onaylı mühendislik istasyonlarıyla sınırla; PLC koruma seviyesi/parolasını etkinleştir; yazma işlemlerini izle
Uzaktan erişim	Doğrudan erişimi kaldır; aracı sunucu, MFA ve zamana bağlı erişim
Windows tabanlı HMI	Uygulama izin listesi, gereksiz servislerin kapatılması, USB kısıtlaması, yerel yönetici hesaplarının sınırlanması
Servis dışı bırakma	Hız sınırlama, yayın fırtınası kontrolü, kritik bağlantıların izlenmesi

Her kontrolün çalıştığı kanıtlanmalı. Firewall kuralı eklendiyse, zafiyetli porta izin verilmeyen bir segmentten bağlantı denenir, engellendiği görülür ve kayda geçer. Bunu bir bakım penceresinde, basit bir TCP bağlantı denemesiyle bile yapabilirsiniz. Sızma testi ya da yapılandırma denetimiyle doğrulanmamış telafi edici kontrol kâğıt üzerinde kalır. Kâğıt saldırganı durdurmaz.

Yama testi ve tedarikçi onayı

Yama kararı verildikten sonra uygulama da kontrollü yürür:

1. Uyumluluk kontrolü: HMI/SCADA üreticileri genellikle Windows güncellemeleri ve antivirüs ürünleri için uyumluluk listesi yayımlar. Listede olmayan güncelleme destek kapsamını etkileyebilir.
2. OEM onayı: Makine içindeki bileşende güncelleme öncesi makine üreticisinin yazılı onayı alınır; onaysız değişiklik garantiyi ve makinenin emniyet fonksiyonlarına ilişkin üretici sorumluluğunu etkileyebilir.
3. Test: Mümkünse test tezgâhında, değilse yedek hatta veya kritik olmayan bir hücrede uygulanır.
4. Geri dönüş planı: Mevcut firmware, proje dosyası ve sistem imajı yedeklenir; geri dönüş adımları ve süresi önceden bilinir. Geri dönüş yolu olmayan firmware güncellemesi, kumardır.
5. Devreye alma: Güncelleme sonrası I/O, haberleşme ve emniyet fonksiyonları test edilir.

Bu adımlar değişiklik yönetimi sürecinin parçası. Değişiklik penceresinin mühendislik tarafı için endüstriyel sitedeki OT değişiklik penceresi rehberi ayrıntı verir.

Kararların kayıt altına alınması

OT zafiyet yönetiminin kurumsal siber güvenlik programı içinde denetlenebilir olması, kararın gerekçesiyle birlikte saklanmasına bağlı. Her zafiyet–varlık eşleşmesi için kayıtta şu alanlar bulunur:

• CVE ve bülten referansı, etkilenen varlıklar ve sürümler.
• Erişilebilirlik, sömürülebilirlik ve sonuç değerlendirmesi ile değerlendiren kişi.
• Karar (yama, azaltma, kabul), gerekçesi ve onaylayan yetkili.
• Uygulanan telafi edici kontroller ve doğrulama kanıtı.
• Planlanan yama tarihi veya yeniden değerlendirme tarihi.

Bu kayıt, yeni bir bülten çıktığında hangi kararların yeniden açılacağını da gösterir. Aynı varlık için “sömürü bilgisi yok” gerekçesiyle ertelenen bir zafiyet KEV kataloğuna girdiğinde karar otomatik olarak yeniden değerlendirmeye düşmeli. Bunu elle hatırlamaya kalkarsanız unutulur. Değerlendirmeyi OT bağlamında kurmak için OT/ICS güvenlik hizmeti, IT tarafındaki tarama altyapısı için zafiyet analizi ve taramalar hizmeti kullanılabilir. Önceliklendirmedeki sonuç kategorileri OT güvenlik risk değerlendirmesi çalışmasıyla aynı ölçekte tutulmalı; iki ayrı ölçek, iki ayrı öncelik listesi üretir.

Sık sorulan sorular

OT ağında zafiyet taraması yapılabilir mi?

Genel amaçlı aktif tarama OT cihazlarında beklenmeyen etkiler yaratabilir; temkinli kullanılmalı. Yaygın yöntem, envanterdeki ürün ve firmware bilgisini tedarikçi bültenleriyle eşleştirmek, gerekirse bakım penceresinde kontrollü tarama yapmaktır.

CVSS puanı OT’de önceliklendirme için yeterli mi?

Hayır. CVSS teknik etkiyi ölçer; zafiyetli arayüze kimin erişebildiğini ve prosese etkisini hesaba katmaz. Erişilebilirlik, aktif sömürü durumu ve proses sonucu birlikte değerlendirilmeli.

Yaması olmayan bir PLC için ne yapılmalı?

Zafiyetin sömürü yoluna göre telafi edici kontrol uygulanır: erişimi onaylı kaynaklarla sınırlamak, kullanılmayan servisleri kapatmak, PLC koruma seviyelerini etkinleştirmek ve yazma işlemlerini izlemek. Uzun vadede ürün yenileme planı yapılır.

Risk kabulü ne kadar süreyle geçerli olmalı?

Risk kabulü süresiz olmaz. Her kabulün bir sahibi ve yeniden değerlendirme tarihi bulunur; zafiyet aktif sömürü listesine girdiğinde veya varlığın erişilebilirliği değiştiğinde karar erken yeniden açılır.