ABB'nin KNX Aracındaki Açık, 20 Yıllık Bir Tasarım Sorununun Belirtisi

ABB, KNX Update Tool’u için sorumlu bir güvenlik açığı bildirimi aldı ve yayınladığı düzeltme özeti alışılmadık derecede dürüst. Başarılı bir saldırı, ürünü kullanılamaz hale getirebiliyor — yani bir denial-of-service (hizmet dışı bırakma) durumu söz konusu — ancak ABB, bu açığın yalnızca “klasik” KNX cihazlarını, yani hiçbir zaman KNX Secure desteği almamış cihazları etkilediğini vurgulamakta acele ediyor. Satır aralarını okuduğunuzda ABB’nin gerçekte söylediği şey şu: bu, bizim aracımızdaki bir kusur değil; modern güvenlik anlayışından on yıllarca önce tasarlanmış bir protokol jenerasyonuna işlenmiş bir kusur.

KNX, 1990’lardan beri Avrupa’daki bina otomasyonunun belkemiği durumunda. Aydınlatma, HVAC, panjurlar, erişim kontrolü — hepsi güvenilirlik ve birlikte çalışabilirlik için tasarlanmış, gizlilik ya da bütünlük için değil, bir bus protokolü üzerinden yürüyor. KNX Secure ise yıllar sonra sonradan eklenen bir katman olarak geldi ve benimsenme oranı, kurulumcuların ve nokta başına maliyetin belirleyici olduğu bir pazarda sonradan eklenmiş bir güvenlik katmanından beklenebileceği gibi oldu: düzensiz, yavaş ve büyük ölçüde on yıl önce kurulmuş devasa bina filosundan ziyade yeni yapılarda yoğunlaşmış durumda.

Bina otomasyonu bu mücadeleyi neden hep kaybediyor

Bina otomasyon sistemleri, elektrik şebekelerinin veya su tesislerinin aldığı ilgiyi görmüyor ve bu bir hata. Bir hastanenin BMS’i (bina yönetim sistemi) ameliyathanelerdeki hava akışını kontrol ediyor. Bir veri merkezinin BMS’i, binanın kendisinden daha değerli sunucu rafları için soğutmayı kontrol ediyor. Bir güvenlik açığı raporu “saldırgan ürünü kullanılamaz hale getirebilir” dediğinde, bu soyut bir rahatsızlık değildir — o bus üzerinde ne çalıştığına bağlı olarak fiziksel sonuçlara kadar tırmanabilecek bir kesinti anlamına gelir.

Rahatsız edici gerçek şu ki, KNX Secure’un benimsenmesi bir retrofit (geriye dönük uyumlulaştırma) sorunu ve OT dünyasında retrofit sorunları nadiren bir yamayla çözülür. 2011’de kurulmuş ve hiçbir zaman güncelleme almak üzere tasarlanmamış bir bus coupler’a firmware güncellemesi gönderemezsiniz. Bunu düzgün bir şekilde çözmek donanım değişimi gerektirir, bu da bütçe döngüleri anlamına gelir, bu da genellikle bir şey mesele haline gelene kadar — çoğunlukla bir olay, bazen bir uyumluluk zorunluluğu, ara sıra da soru soran bir sigorta şirketi — bunun yapılmayacağı anlamına gelir.

Bu danışma belgesi asıl neyi tetiklemeli

İçinde KNX bulunan bir tesis işletiyorsanız, danışma belgesinin kendisi ortaya çıkardığı envanter sorusunun yanında neredeyse ikinci planda kalıyor: KNX cihazlarınızdan hangilerinin Secure desteği olduğunu, hangilerinin olmadığını gerçekten biliyor musunuz? Çoğu tesis ekibinin bu soruya net bir cevabı yok, çünkü KNX projeleri yıllar boyunca sistem entegratörleri tarafından inşa ediliyor ve cihaz listeleri, teslimden sonra kimsenin açmadığı devreye alma dokümantasyonunun içinde gömülü kalıyor.

Buradaki çözüm bir yama değil. Elinizde ne olduğunu bilmek.

Böyle bir danışma belgesinin gerçek değeri de tam olarak bu — spesifik güvenlik açığı değil, bina otomasyon varlığınızın ne kadarının düşman bir ağla temas etmesi hiç düşünülmemiş protokol jenerasyonları üzerinde çalıştığını araştırma dürtüsü. ABB bunu açıkça ifşa ederek doğru olanı yaptı. Daha zor olan iş operatör tarafında: eski KNX’i yamalarla idare etmeye devam mı edecekler, yoksa açığı gerçekten kapatan donanım yenilemesi için nihayet bütçe mi ayıracaklar, buna karar vermek.

Kaynak: https://www.cisa.gov/news-events/ics-advisories/icsa-26-209-07