- Konu Yazar
- #1
Modern yazılımlar, on, yirmi hatta otuz yıl önce piyasaya sürülen ürün ve sistemlerde çalışıyor. Bu durumu daha da karmaşık hale getiren şey ise birçok endüstriyel kuruluşun sistemlerinin içinde ne olduğuna dair yeterli görünürlüğe sahip olmaması. Bu hiç iyi değil! Finite State CEO'su Matt Wyckhouse ile bu zorlukları ve eski varlıklarda yeni yazılım çalıştırmanın çözümlerini keşfediyoruz.
🔍 Endüstriyel Kuruluşlar Hala Kör Noktada mı?
Evet! Birçok endüstriyel kuruluş, operasyonel teknoloji (OT) ağına bağlı fiziksel varlıkları tanımlayabilir, ancak görünürlük genellikle cihaz sınırında durur. Bir varlık envanteri, bir operatöre cihazın ne olduğunu ve ağda nerede bulunduğunu söyleyebilir. Ancak aynı kayıt, genellikle tam donanım yazılımı yapısını, bu yapının hangi yazılımları içerdiğini veya yeni açıklanan bir güvenlik açığının bu yapılandırma için geçerli olup olmadığını gösteremez.
Bu kör nokta önemlidir, çünkü riskin çoğu ağ katmanının altında yaşar. Endüstriyel kuruluşlar, fiziksel varlıkları keşfetme ve ağ trafiğini izleme konusunda gerçek ilerleme kaydettiler, ancak çoğu hala bu varlıkların içinde çalışan yazılımın doğrulanmış bir görünümüne sahip değil. Bu görünüm olmadan, her yeni güvenlik açığı açıklaması, ürünler, sürümler ve siteler arasında uzun bir araştırma haline gelir.
🤔 Neden Böyle Bir Durum Var?
Endüstriyel ürünlerin incelenmesi zordur, çünkü derlenmiş donanım yazılımı tipik bir kurumsal uygulamadan çok farklı görünür. Tek bir donanım yazılımı görüntüsü, bir işletim sistemini ve sürücülerini tedarikçi yazılım geliştirme kitleri ve diğer önceden derlenmiş kodlarla birleştirebilir. Üreticiler genellikle bu öğelerin bazılarını temel kaynak kodu olmadan ikili olarak alırlar.
Geleneksel uygulama güvenliği araçları, kaynak depoları ve paket manifestoları yazılım bağımlılıklarını doğru bir şekilde beyan ettiğinde en iyi şekilde çalışır. Donanım yazılımı genellikle bu varsayımı bozar, bu nedenle faydalı kaynak tabanlı sonuçlar, bitmiş ikiliye giren bileşenleri yine de kaçırabilir.
Uzun bir dağıtım süresince, orijinal yazılım kaydı doğruluğunu kaybedebilir. Bir tedarikçi, sürüm numarasını değiştirmeden bir güvenlik düzeltmesini geri taşıyabilirken, daha sonraki ürün varyantları ilk yapıyı anlayan mühendislerden daha uzun süre dayanabilir.
💡 Dijitalleşme Bu Sorunu Çözüyor mu?
Dijitalleşme, bazı riskleri yarattı, ancak aynı zamanda kuruluşlara riski yönetmek için daha iyi yollar sunuyor. Fabrika katı sistemleri, fabrika dışındaki kurumsal ve bulut ortamlarına bağlandıkça, uzaktan erişim operasyonlara ek yollar yaratır. Yazılım tanımlı işlevsellik de daha sık güncellemeler getirerek ürün yapılandırmalarına daha fazla sapma fırsatı verir.
Aynı zamanda, modern mühendislik iş akışları çok daha güçlü bir güvenlik kaydını koruyabilir. Her ürün sürümü, donanım yazılımını ve Yazılım Malzeme Listesi'ni (SBOM) güvenlik açığı bulgularına ve dağıtım durumuna bağlayabilir. Operatörler daha sonra farklı sitelerde hangi sürümlerin etkin kaldığını görebilirler.
Gerçek değer, bu dijital kaydı bitmiş ürünle karşılaştırmaktan gelir. Dokümantasyon, bir cihazın ne içermesi gerektiğini açıklar. Doğrudan donanım yazılımı analizi, gönderilen cihazın aslında ne içerdiğini gösterir. Bu iki görünümü ürün yaşam döngüsü boyunca hizalı tutmak, dijitalleşmeyi başka bir belirsizlik kaynağı yerine güvenlik çözümünün bir parçası haline getirir.
⏳ 30 Yıllık Varlıklar: Yazılım Yaşam Döngüsü ve Güvenlik
Endüstriyel ekipman ve gömülü yazılım çok farklı oranlarda yaşlanacaktır. Bir kontrolör veya pompa on yıllarca güvenilir bir şekilde çalışabilirken, içindeki yazılım yığını çok daha erken destek sonuna ulaşır. Araştırmacılar, ekipman hizmete girdikten çok sonra bile işletim sisteminde, kriptografik kütüphanelerde veya tedarikçi kodunda güvenlik açıkları keşfetmeye devam edebilirler.
Operasyonel güvenilirlik, büyüyen bir güvenlik sorununu maskeleyebilir: varlık üretimde stabil kalırken, yeni araştırmalar içindeki yazılımın risk profilini değiştirir.
Endüstriyel ekipmanı güncellemek de gerçek operasyonel sonuçlar doğurur. Bir donanım yazılımı değişikliği, planlı bir kesinti veya fiziksel erişim gerektirebilir. Dağıtımdan önce, ekiplerin bir tedarikçiyle koordinasyon sağlaması, güvenliği doğrulaması ve değişikliği belirli bir üretim yapılandırmasına karşı test etmesi gerekebilir. Bazı ortamlarda, bir güncellemeyi hemen uygulamak, iyi anlaşılan bir güvenlik açığını segmentasyon, erişim kontrolleri veya başka bir dengeleyici önlemle yönetmekten daha fazla operasyonel risk yaratabilir.
Güvenlik ekiplerinin, varlık hizmette kaldığı sürece yazılım kaydını sürdürmesi gerekir. Dağıtılan her sürüm için, yeni güvenlik açıkları ortaya çıktıkça yazılım kaydının güncel kalması gerekir. Erişilebilirlik analizi, etkilenen bir işlevin o belirli yapıda gerçekten yürütülüp yürütülemeyeceğini belirlemeye yardımcı olabilir.
Avrupa Birliği Siber Dayanıklılık Yasası (CRA) gibi düzenlemeler aciliyeti artırıyor. Üreticiler bir denetimi bekleyip ardından yıllarca süren yazılım kanıtlarını yeniden oluşturamazlar. Yazılım kaydı, her risk kararının arkasındaki gerekçeyle birlikte, ürünler ve tehditler geliştikçe güncel kalmalıdır.
📊 Örnek Olay: Üreticinin Güvenlik Açığı Gürültüsünü Azaltması
Yakın zamanda yapılan bir Finite State vaka çalışmasında, beş farklı SBOM jeneratörü kullanan küresel bir üretici, her uyumluluk denetimi için verileri manuel olarak uzlaştırmakla haftalar harcadı. Bağlantısız raporlar kritik ürün bağlamından yoksundu, kanıtları farklı ekiplere dağılmış halde bırakıyordu.
Yazılım kayıtlarını merkezileştirerek, SBOM verilerini normalleştirerek ve erişilebilirlik ve sömürülebilirlik bağlamı ekleyerek, üretici güvenlik açığı gürültüsünü %95 oranında azalttı ve uyumluluk hazırlık süresini %90 oranında kısalttı. Daha önce haftalar süren iş, günler içinde tamamlandı.
Buradaki ders, üreticilerin ürünlerinin içindeki yazılımın güvenilir, sürekli güncellenen bir görünümüne ihtiyaç duymasıdır. Ekipler, hangi bileşenlerin mevcut olduğunu, hangi güvenlik açıklarının gerçekten önemli olduğunu, düzeltmenin kime ait olduğunu ve her kararın arkasındaki kanıtı hızlı bir şekilde anlayabildiğinde, güvenlik tekrarlanabilir bir süreç haline gelir, tekrarlayan bir yangın tatbikatı değil.
🔗 Uzun Ömürlü Bağlı Sistemlerin Güvenliğini Sağlamanın Zorlukları
Uzun ömürlü bağlı sistemlerin güvenliğini sağlamak zordur, çünkü yazılım yaşlanmaya devam ederken operasyonel kısıtlamalar ve sahiplik sınırları yerinde kalır.
Bir tarayıcı savunmasız bir bileşeni işaretleyebilir, ancak bulgu tek başına en önemli soruları yanıtlamaz: Bu bileşen bu belirli donanım yazılımı yapısında mevcut mu? Savunmasız işlevsellik erişilebilir mi? Düzeltme, kritik bir üretim sistemine yıkıcı bir güncelleme gerektiriyor mu?
Bu soruları yanıtlamak için gereken bağlam genellikle tedarik zincirine yayılmıştır. Bir bileşen tedarikçisi sağladığı kütüphaneyi görür. Üretici bitmiş donanım yazılımını anlar. Entegratör saha yapılandırmalarını kontrol eder. Operatör, varlığı çevrimdışı almanın üretim için ne anlama geleceğini anlar. Hiçbir kuruluşun tüm teknik ve operasyonel resmi yoktur.
Ürün varyasyonu başka bir karmaşıklık katmanı ekler. Bir donanım yazılımı sürümü için verilen bir risk kararı, daha sonraki bir yapıya veya müşteriye özel bir yapılandırmaya uygulanamayabilir. Sürekli, yapıya özel görünürlük olmadan, ekipler aynı analizi tekrarlamak zorunda kalır.
