NTT Australia’nın siber güvenlik direktörü Dirk Hodgson bir hikaye anlatıyor. Bir zamanlar bilimsel ölçümler yapan bir şirkette çalışıyordu. Son derece uzmanlaşmış firma, son derece özel ekipman kullandı ve büyük bir ekipman parçası, yıllar önce satın alındığında onlara 2 milyon dolara mal oldu.
Donanım herhangi bir soruna neden olmadı ve üretici, sözleşmelerine göre rutin olarak parçaları değiştirdi ve bakım yaptı. Güvenlik sorunu, Windows XP olan işletim sistemiydi. Şirket üreticiye gitti ve işletim sistemini mevcut ve desteklenen bir işletim sistemine yükseltip yükseltemeyeceğini sordu.
Sorun değil, diye yanıtladı üretici. Şirketin tek yapması gereken yeni bir multimilyon dolarlık sistem satın almak ve mevcut işletim sistemi ile birlikte gelecek. Mevcut makinedeki işletim sistemini güncellemeye gelince? Üretici reddetti.
Hodgson, “Bu bin dolarlık yükseltme, multimilyon dolarlık bir yatırım gerektirecektir” diyor. “Eski yazılım kesinlikle büyük bir sorun.”
Onlarca yıldır güvenlik yöneticileri eski sistemlerle mücadele etti. Tehdit ortamı daha karmaşık hale geldikçe, uzak çalışanlar, iş ortakları, IoT ve bulut entegrasyonlarında birbirine karıştıkça mücadele daha da yoğunlaştı. Eski tehdidi hafifletmeye çalışmanın birçok teknolojik yolu vardır (izolasyon, sanallaştırma, bir sanal alanda çoğaltma vb.), ancak bunların hiçbiri kurumsal politikayla ve güvenlik ekiplerinin eski sistemlere dokunmasına izin verme korkusuyla ilgili değildir.
Çalışma Süresi Sorunları İş Kolu için Öncelik Alır
Eski sistemlerle ilgili sorunlar iki ayrı gruba ayrılır: siber güvenlik sorunları ve çalışma süresi sorunları. İş kolu (LOB) yöneticisi için çalışma süresi sorunu (eski ortamdaki herhangi bir şeye dokunmanın sistemin çökmesine neden olabileceği korkusu) çok daha korkutucu. Ve bu eski sistemler genellikle günden güne oldukça iyi çalıştığından, işletme yöneticisi bunlarla oynamak için hiçbir neden görmez.
LOB ayrıca, kodu yazan kişiler çoktan gitmiş olduğundan, donanımı üreten satıcı artık faaliyet göstermiyor olabileceğinden ve sistem çökerse sistemi geri yükleme yeteneklerine sahip olamayacaklarından haklı olarak endişelenir. yazılım ya yok ya da ne yazık ki yetersiz.
Hepsinden kötüsü, eski sistemler, örneğin montaj hatlarını çalıştıranlar gibi genellikle gerçekten görev açısından kritiktir. Bu sistemlerin çökmesi, üretimi belirsiz bir süre için kolayca durdurabilir ve daha da kötüsü, bağlı sistemlerde art arda gelen arızaları tetikleyebilir.
Vercara’nın saha CTO’su Michael Smith, “Eski sistemler hakkındaki en büyük sürpriz, bu kadar uzun süredir var olduklarından, geri kalan hemen hemen her şeyin onlara bağlı olması,” diyor. “Öyleyse, bu eski sistemi yükseltmeyi veya devre dışı bırakmayı neredeyse imkansız kılan bu devasa Gordian bağımlılık düğümüne sahipsiniz ve diğer sistemlerin onlara ne zaman bağlandığını anlamak için çok sayıda ağ ve günlük analizi yapmanız gerekiyor.”
Baloncuklu Ambalaj Her Şeyde İşe Yaramaz
Tines’in kurucusu ve CEO’su Eoin Hinchy, “İşletme yöneticileri, güvenlik ekiplerinin görev açısından kritik eski sistemlere dokunmasına izin verirken dikkatli olmakta haklıdır” diyor. “Güvenlik ekipleri bunun yerine eski sistemlerin saldırı yüzey alanını azaltmaya odaklanmalı. Başka bir deyişle, onları balonlu naylona sarın.”
Balonlu ambalaj konsepti, mirasla başa çıkmanın popüler bir yolu olmasına rağmen, her zaman işe yaramaz. Ve asıl muamma da burada yatıyor. Bu çaba bazen başarısız olmakla kalmıyor, aynı zamanda böyle bir başarısızlığı tahmin etmenin güvenilir bir yolu da yok.
Ernst & Young Americas’ın siber güvenlik lideri David Burg, “Mirasla ilgili zorluklardan biri, zaman içinde biriken teknik bir borcun birikmesidir” diyor. “Yapıldıklarında (geliştiriciler) o dönemde var olan kurumsal bilgiyle çalışıyorlardı. Mimarinin, birlikte çalışabilirliğin ve bağımlılıkların ve benzerlerinin belgelenmesi büyük olasılıkla hiçbir zaman belgelenmedi. İnsanlar gelip gidiyor.”
NTT Australia’dan Hodgson, geleneksel güvenlik risklerinin ötesinde, sistem sertifikasyonunun diğer bir karmaşıklaştırıcı faktör olduğuna dikkat çekiyor. “Bir sistem belirli bir düzeyde onaylanmıştır. Yama uygulanırsa, düzgün çalışması için makul bir şans vardır, ancak satın aldığınız akreditasyonu kaybedebilirsiniz” diyor.
Ve LOB bunu yapmayı seçse bile, bu özel sistemlerin çoğunun değiştirilmesi fiziksel olarak zordur. Hodgson, “MRI makineleri kuran tıbbi tesisleri düşünün. Vinçle yerleştirilmeleri gerekiyor, duvarlara kurşun yerleştirmeniz gerekiyor” diyor. “Bunu çok uzun süre saklayacaksın.”
CISO’lar Ne İstiyor?
Bu, tartışmayı ideal ve pratik arasındaki bir çatışmaya getiriyor. Yönetim kurulu/CEO/CISO açısından ideal olan, tüm eski sistemleri günümüzün siber güvenlik ve uyumluluk gereksinimlerini zahmetsizce destekleyebilecek modernize edilmiş sistemlerle değiştirmek olacaktır. Ancak işletme bu geçişi yapmak için parayı harcamaya istekli olsa bile, bu pratik olmayabilir.
Infoblox’ta güvenlikten sorumlu kıdemli ürün pazarlama müdürü Bob Hansmann, “Pek çok eski sistem uygulaması için, veri erişimi, hesaplama ve hatta iletişim performansı bir bilgisayar ortamında kolayca eşleştirilemez” diyor. “Cobol, Fortran, RPG II ve diğer uygulamaları PC platformlarına taşıma/yeniden yazma işi dağlıktır ve maliyeti haklı çıkarmak zordur. Kod taşınsa bile, performans için yoğun bir şekilde test edilmesi ve değiştirilmesi gerekir – tıpkı burada olduğu gibi hız ve doğruluk – genellikle PC donanımının ana bilgisayar ve mini donanımdan ne kadar farklı olduğu nedeniyle.”
Eyleme geçirilebilir belgelerin olmaması, eski sistemlerin güncellenmesinde kritik bir faktördür, ancak sorun eski sistemlerle sınırlı değildir. İster geniş dağıtım için uygulamalar oluşturan bir yazılım satıcısı, isterse kendi geliştirdiği yazılımları oluşturan bir kurumsal geliştirici olsun, günümüzün geliştiricileri kodu hala kullanılabilir bir şekilde belgelemiyor. Bu nedenle, yeni nesil eski sistemler aynı sorunlardan muzdarip olabilir.
Dokümantasyonu Geleceğin Mirasına Dönüştürün
McKinsey’de endüstriyel siber güvenlik lideri Ayman Al Issa, bugün eyleme geçirilebilir belgelerin eksikliğini “önemli bir sorun” olarak nitelendiriyor.
“Hiç iyi belgeler görmüyoruz” diyor. “Bu kültürel bir mesele. Belgelemenin değerini görmüyorlar. Buna bakım sorunları ve sistemdeki herhangi bir değişiklik de dahil. Belgelenmiyorlar. İnsanlar her şeyi belgelemek konusunda tembel.”
Al Issa, şirketlerin sistemleri yöneten ekiplere dayalı olarak kendi belgelerini oluşturmaları gerektiğini önermektedir. Ancak tek arıza noktası probleminden kaçınmak için, “sistemleri çalıştırabilecek tek bir kişinin kalmaması için görev rotasyonu yapmaları gerekiyor” diyor.
Teorik olarak, yönetim uygun dokümantasyonun gerçekleşmesi konusunda ısrar etmelidir, ancak bunun yerine yöneticiler teslim etmeleri için baskı altındadır. Geliştirici, Proje A’yı tamamladıktan sonra, geliştiricinin her şeyi belgelemek için bir hafta harcaması konusunda ısrar mı ediyorlar, yoksa geliştiriciye bir sonraki projeye geçmesini mi söylüyorlar ki, geliştirici zaten bunu yapmak istiyor?
Burg, uygulanabilir tek düzeltmenin, güçlü belge gereksinimlerini DevSecOps sürecine dahil etmek olduğunu söylüyor: “Bu eş zamanlı belgeleri yapmalıyız, yoksa bu olmayacak.”
