Bir trafo merkezini düşünelim. Kesicilerin konumunu, hat akımlarını ve alarmları merkeze taşıyan cihaz bir RTU. Yıllardır sorunsuz çalışıyor; kimse dokunmuyor, çünkü dokunmak için telekontrolü kesip merkezi bir süre yerel kontrole almak gerekiyor.
6 Ekim 2026'da CISA bu cihaz ailesi için bir uyarı yayımladı. Listedeki açıklardan birinin kimliği CVE-2010-2965. Yani on altı yıl önce numaralanmış bir açık, bugün sahadaki bir cihaz için yeniden duyuruluyor. CISA, ICSA-26-279-06
Bu uyarı üzerinden şunu soruyorum: OT cihazları neden bu kadar uzun yaşıyor ve yaması olmayan bir cihazla sahada nasıl baş ediyoruz?
RTU (Remote Terminal Unit), trafo merkezi ya da pompa istasyonu gibi uzak bir noktadaki ölçümleri toplayıp merkez SCADA'ya gönderen ve merkezden gelen komutları sahaya ileten cihazdır. İçinde firmware denen gömülü yazılım çalışır; birçok RTU'da bu yazılımın altında VxWorks gibi bir gerçek zamanlı işletim sistemi bulunur. CVE, bilinen bir güvenlik açığına verilen kimlik numarasıdır; CVE-2010-2965 ifadesindeki 2010, açığın numaralandığı yılı gösterir. EOL (end of life) ise üreticinin bir ürüne artık güncelleme ve yama üretmediği durumdur.
Uyarı ne diyor?
Hitachi Energy'nin RTU500 serisi, haberleşme birimi (CMU) firmware'inin 11.x ve önceki sürümleri için uyarı yayımlandı. Bu sürümler üretici tarafından EOL ilan edilmiş. Açıkları Dragos bildirmiş. Listede 2026 tarihli iki kritik açık var: kimlik doğrulaması olmadan firmware yükleme ve dizin geçişiyle dosya yazma. Ayrıca kimliği doğrulanmış bir kullanıcının yetkisiz yeniden başlatma tetikleyebilmesi ve çok daha eski üç kayıt var: 2010'dan VxWorks hata ayıklama servisi, 2014'ten kimlik doğrulamasız komut çalıştırma ve 2023'ten bütünlük kontrolü olmadan kod indirme. CISA, ICSA-26-279-06
Üreticinin ifadesi dikkat çekici: bulgular "şu anda desteklenen RTU500 CMU firmware sürümlerini etkilemiyor"; ancak EOL sürümlerin etkilenme "olasılığı var" ve bu sürümler "artık güvenlik güncellemeleriyle bakılmıyor". Çözüm olarak 12.7.8, 13.9.1 ya da güncel sürüme geçiş öneriliyor. CISA, ICSA-26-279-06
Öneri, desteklenen bir firmware dalına geçmek. Sahada bunun için büyük sürüm geçişinin ve mevcut yapılandırmayla uyumun planlanması gerekiyor.
2010'daki açık neydi?
VxWorks, gömülü cihazlarda yaygın kullanılan bir gerçek zamanlı işletim sistemidir. Geliştiriciler cihazdaki yazılımı test ederken bir hata ayıklama aracı kullanır: WDB ajanı. Bu ajan UDP 17185 numaralı porttan dinler, cihazın belleğini okuyup yazmaya ve fonksiyon çağırmaya izin verir. Geliştirme masasında çok işe yarar. Üretim cihazında açık kalırsa, RTU'ya ağdan ulaşabilen herkes için bir arka kapıdır: istasyon LAN'ındaki bir bilgisayar, merkez WAN'ından gelen bir bağlantı ya da bakım için açılan bir hat.
ABD'nin ICS-CERT'i bunu 2010'da duyurmuştu. Öneri iki satırdı: üreticiler üretim sistemlerinde hata ayıklama ajanını kapatmalı; kullanıcılar 17185/udp portuna erişimi güvenlik duvarı kurallarıyla kısıtlamalı. CISA, ICSA-10-214-01
On altı yıl sonra aynı tavsiye, aynı port, aynı mekanizma. Bugünkü uyarı bu servisin "RTU500 CMU firmware'inin birkaç eski sürümünde" kullanıldığını söylüyor. Yani bütün eski sürümlerde değil; ama hangi sürümlerde olduğunu sahadaki firmware'i kontrol etmeden bilemeyiz. CISA, ICSA-26-279-06
Normal trafik neye benzer?
Peki RTU'nun normal haberleşmesi nasıl görünüyor? Merkez ile RTU arasındaki IEC 60870-5-104 genel sorgusunu TShark ile çözümledim.
Merkezin yaptığı işlemlerden biri "bütün güncel durumu bana bildir" demektir; buna genel sorgu denir. Çözüm şöyle görünüyor:
IEC 60870-5 ASDU <- I ASDU=1 C_IC_NA_1 Act IOA=0
TypeId: C_IC_NA_1 (100)
CauseTx: Act (6)
QOI: Station interrogation (global) (20)
IEC 60870-5 ASDU -> I ASDU=1 C_IC_NA_1 ActCon IOA=0
CauseTx: ActCon (7)
Ayrıntıları büyüt
İşte RTU'ya güvenlik duvarında izin verdiğimiz trafik budur: 2404 portu, bilinen ASDU tipleri, merkezle öngörülebilir bir alışveriş. Önceki bölümde anlattığımız VxWorks hata ayıklama servisi (17185/udp) bu konuşmanın parçası değildir; onunla aynı cihazda duran, ayrı ve kapatılması gereken bir kapıdır. Bir cihazın "ne konuşması gerektiğini" bilmek, "ne konuşmaması gerektiğini" kapatmanın ilk adımıdır. Aşağıdaki tabloda güvenlik duvarı kuralı derken kastımız tam olarak bu ayrım.
Bu örnek de scapy ile oluşturulup TShark 4.2.2 ile dosyadan çözümlendi.
Neden hâlâ sahada?
IT'den gelen biri "neden güncellemediniz?" diye sorar. Soru haklı, cevabı da var.
Ayrıntıları büyüt
Bir trafo merkezi ya da üretim hattı için cihaz, yazılım değil tesisat gibidir. Birkaç neden üst üste biner:
- Kesinti penceresi. RTU'yu güncellemek için merkezin telekontrolünü kesip yerel kontrole geçmek gerekir; RTU kilitleme ya da otomasyon mantığı da yürütüyorsa iş daha da büyür. Bu pencere yılda bir, bazen üç yılda bir açılır.
- Doğrulama yükü. Yeni firmware'in koruma röleleriyle, SCADA protokolüyle ve yerel mantıkla aynı şekilde çalıştığını kanıtlamak gerekir. "Güncelledik, çalışıyor gibi" kabul edilmez.
- Büyük sürüm atlaması. Uyarıdaki çözüm 11.x'ten 12.x ya da 13.x'e geçmek. Bu çoğu zaman yapılandırmanın yeniden oluşturulması, bazen donanım değişimi demektir.
- Sahiplik. Cihazı kuran entegratör gitmiş, projeyi bilen mühendis emekli olmuş olabilir. Dokunmaktan korkmanın arkasında çoğu zaman bilgi kaybı vardır.
Bu yüzden OT'de yirmi yıllık cihaz normaldir. NCSC'nin Ağustos 2026 tavsiyesi bile "sınır cihazlarını ömür sonundan önce değiştirin" derken, sahadaki herkes bunun bütçe ve planlama işi olduğunu bilir. NCSC, 27 Ağustos 2026
"Yaması yok, değiştirin"
Aynı ömür sorununun başka bir yüzünü Eylül 2026'daki bir Rockwell uyarısında görüyoruz. 1756-ENBT, ControlLogix PLC'lerini Ethernet'e bağlayan bir haberleşme modülü. Uyarı, özel hazırlanmış bir CIP paketinin modülü çökertebildiğini, cihazın düzelmesi için yeniden başlatma gerektiğini söylüyor. Etkilenen sürüm: hepsi. CISA, ICSA-26-246-05
Önerilen çözüm firmware yaması değil; modülü 1756-EN2T ya da 1756-EN4TR ile değiştirmek. Çünkü üreticinin ürün sayfasına göre 1756-ENBT 31 Aralık 2021'de üretimden kalkmış. Rockwell Automation, 1756-ENBT ürün sayfası
Modül çökünce ne olur? PLC'nin kendisi çalışmaya devam eder, mantık yürür. Ama HMI o PLC'yi göremez, SCADA veri alamaz, operatör kör kalır; buna "görünürlük kaybı" diyoruz. Modül aynı zamanda uzak I/O ya da başka PLC'lerle paylaşılan verileri de taşıyorsa iş daha ciddi: o bağlantılar kopar, çıkışlar projede tanımlı arıza durumuna düşer. Yani aynı çökme bir projede yalnız ekranı karartır, başka projede prosesi durdurur.
Sahada bu modüllerden onlarca olabilir ve hiçbiri kendi başına "güvensiz" görünmez. Çalışıyor, ışığı yeşil. Değiştirmek için hat durmalı, yeni modül sipariş edilmeli, proje dosyasında modül tanımı güncellenmeli.
Yama yokken ne yaparız?
Eski cihazla yaşamak zorunda olduğumuz dönem için elimizde üç araç var: ağ sınırı, görünürlük ve plan.
| Durum | Yapılacak iş | Neden işe yarar? |
|---|---|---|
| EOL firmware'de hata ayıklama portu açık olabilir | 17185/udp dahil gereksiz portları RTU'nun önündeki güvenlik duvarında kapat; SCADA protokolüne ve kayıt altına alınmış mühendislik erişimine izin ver. Eski merkezde güvenlik duvarı yoksa önce onu kurmak gerekir. | 2010'daki tavsiye hâlâ geçerli; port erişilemezse açık kullanılamaz. |
| Hangi sürümün sahada olduğu bilinmiyor | Her RTU'nun model ve firmware sürümünü envantere yaz; "birkaç eski sürüm" ifadesini kendi cihazlarında doğrula. | Uyarı sürüm bazlı; envanter olmadan risk değerlendirilemez. |
| Yaması olmayan haberleşme modülü | Modülün ulaşılabildiği ağı daraltıp değişim planına al; çökme durumunda operatörün ne yapacağını yaz. | Görünürlük kaybı süresi kısalır; değişim bütçeye girer. |
| Büyük sürüm atlaması gerekiyor | Kesinti penceresinde önce test ortamında, sonra bir merkezde pilot uygulayıp doğrula. | Protokol ve röle uyumu kanıtlanmadan saha değişikliği yapılmaz. |
Bu önlemler cihazdaki açığı gidermeden erişimi daraltır ve kör noktaları azaltır. Güncelleme veya değişim planı tamamlanana kadar cihazın çevresindeki kontrolleri güçlendirmek gerekir.
Bileşen envanteri de gerekli. Aynı hafta yayımlanan başka bir uyarı, gömülü cihazlarda yaygın kullanılan açık kaynaklı lwIP ağ yığınındaki bir taşma hatasını anlatıyor. Hangi ürünlerin etkilendiğini uyarının kendisinden çıkaramıyoruz; çünkü hangi cihazın içinde lwIP olduğunu çoğu zaman üretici bile listelemiyor. CISA, ICSA-26-279-02 RTU'daki VxWorks de böyle bir bileşen. Cihazın içindeki yazılım listesini (SBOM) tedarik sırasında istemek, on beş yıl sonra "içinde ne vardı?" sorusuna cevap bulmanın en kestirme yolu.
Sahadaki soru
Bir trafo merkezini gezerken RTU'nun üstündeki etikete bakmak yetmez. Sorulacak soru şu:
Bu cihazın firmware sürümünü en son kim, ne zaman kontrol etti; ve bu cihaza ağdan kimler ulaşabiliyor?