Giden CISA Şefi Jen Easterly Son zamanlarda Ralph Nader kitabı yayınladığında 1965’e benzer bir bükülme noktasında olduğumuzu savunarak güvenli yazılım geliştirmeyi otomotiv güvenliğiyle karşılaştırdı. Herhangi bir hızda güvensiz. Kitap, yenilikçi araç güvenliği önlemlerinin yaygın olarak benimsenmesini sağlayan yol güvenliği konusunda halkın öfkesini teşvik etti.
Jen’in konuyla ilgili yayınlarını okuduktan sonra, açık soru devam ediyor: Gerçekten anlamlı bir değişim sağlamak için güvensiz yazılım riskine karşı öfke kullanabileceğimiz bir noktada mıyız? Bakalım bu soruyu objektif olarak görüp göremeyeceğimizi ve 2025’te kamu baskısının devam etmesi ile ne olması gerektiğini belirleyip belirleyemeyeceğimizi. CISO ve BT yazılım alıcıları için, günlük iyileştirmenin yanı sıra, satın aldığınız yazılımın güvenli olmasını talep etmek ve satıcılarınız tasarım prensiplerine göre güvence altına almayı taahhüt ediyor, 2025’te iğneyi hareket ettirmeye yardımcı olmak için neye odaklanmalısınız?
Bana teşvik göster ve sana sonucu göstereceğim
1960’larda otomobil riski ile modern çağda yazılım riski arasındaki karşılaştırma açıktır. Hızlı teknoloji inovasyonu günlük olarak güvenli olmayan ürünlerin kullanılmasına neden oldu. Yazılım dünyası, 60’lı yıllarda otomotiv endüstrisi gibi, serbest bırakma hızı, özellikler ve işlevsellik ve güvenli kullanım sınırlarını ve sınırlarını zorlamaktadır, hepsi daha fazla ürün satmak ve rakiplerinizden daha hızlı yeni teklifler yenilik yapmak adına. Yazılım geliştiricileri, genellikle kodun güvenliği pahasına ürünleri olabildiğince çabuk serbest bırakma baskısı ile karşı karşıyadır. Güvenlik, geliştirme döngüsünü yavaşlatıyor olarak algılanır ve bu gerçeği sonra genellikle bir cıvatadır.
Büyük Charlie Munger’dan alıntı yapmak için, “Bana teşviki gösterin ve size sonucu göstereceğim.” Yazılım geliştiricileri güvenli kod yazmıyor çünkü bunu teşvik etmiyorlar. Daha da kötüsü, çalıştıkları şirketlerin ürünlerinin güvenliğine odaklanmak için çok az teşviki var. BT ve CISO alıcıları, kod var olduğu sürece güvensiz kod satın alıyorlar.
Otomobil endüstrisinin benzer bir sorunu vardı – bu noktaya kadar satın alınan arabalar güvenli oldukları için satın alınmadı. İnsanlar otomobil bayilerine gitmiyorlardı (60’larda bayilikler var mıydı?) Ve aracın güvenlik derecesi veya çökebilir bir direksiyon sütunu ve yastıklı gösterge paneli hakkında sorular soruyorlardı. Görünüm, stil, en yüksek hız ve ivme ve en önemlisi yeni ulaşım modunu çalıştırırken aldıkları neşeye göre araçlar satın aldılar. Güvenlik gerekli bir özellik değildi ve bu nedenle sonradan düşünülmüştü. Bu, bugün boyunca yazılımı nasıl oluşturduğumuz ve satın aldığımızla neredeyse aynı. Yazılımdan aldığımız değere göre öncelik veriyoruz ve satın alıyoruz, ne kadar güvenli olduğuna çok az ilgi duymadık.
Alıcıların talep ettiği durumda güvenliğe öncelik vermek için bir teşvik yoktur. Otomobil endüstrisi, otomobil üreticilerinin ürün güvenliği özelliklerine “zamanlarını boşa harcamadan” önce daha iyi güvenlik standartları için tüketicinin tanınmasını gerektiriyordu.
2025’te ‘yazılım hızında güvensiz’ anı görmeyeceğiz
Yazılım endüstrisi, birkaç temel nedenden dolayı otomobil endüstrisinin geçmişinden öğrenmedi. Her şeyden önce, bir trafik kazasına girdiğinizde, yaşam kaybı için önemsiz bir şans var. İnsanlar arabalarında güvenlik özelliği olmadığında ölür ve az sayıda ölüm bile halk için kabul edilemez. Bir motorlu taşıt kazasının sonuçları hemen ve viseraldi ve birinde bulunan veya bir tane görenlerin zihninde kalıcı bir izlenim bıraktı. Yazılım farklıdır. Örneğin TV’nizdeki yazılım kırıldığında, sadece yeniden başlatırsınız.
Yakın zamana kadar, en kötü durumda, yazılım kusurlarının büyük çoğunluğu, nüfus üzerinde çok az veya hiç etkisi olmayan bazı anonim kurumsal varlığın uzlaşmasıyla sonuçlandı. Elbette, hesaplarının tehlikeye atılması, doğrudan onlardan çalınması veya onlara karşı işlenen sahtekarlık yapma şansı çok küçük bir şans olabilir, ancak tüketici dünyasının çoğu “bunun başıma gelmeyecek” ve yasa ile Çok sayıda, muhtemelen haklılar. Ve eğer öyleyse, sigortalılar, kayıp için kaplıdırlar ve çoğu zaman, kaybettiklerini geri kazanmak için çok sayıda çemberden atlamak zorunda kalırlar.
Risklere karşı bu laissez-faire tutumu nedeniyle, yazılım endüstrisinin sorunu görmezden gelmesi ve iş yapma maliyeti olarak yazması çok daha kolaydır. Başka bir deyişle, değişim talebi yoktur.
Otomobiller ve yazılım güvenlik açıkları arasındaki risk farkına ek olarak, yazılım manzarasının karmaşıklığı 1960’ların otomobilinin karmaşıklığı. Dört ila altı yazılım işlemini hızlı bir şekilde uygulayabilir ve tüm küresel yazılım risk kaydını düzeltebilirsek, söz vereceğimize söz veriyorum. Sorun, 1960’ların 10’dan az otomatik üreticisinin anlaması gerekenden çok daha karmaşık ve zorlayıcı. Bugün sadece 10 yazılım geliştirme firması varsa, değişimi zorunlu kılmak daha kolay olurdu.
Ancak, yazılım tam anlamıyla dokunduğumuz her şeydedir. IoT cihazlarından ev aletlerine, çocuk oyuncaklarına – yazılım dünyayı yedi ve bu yazılımı tamamlamak çok daha zor bir görev haline getirdi. Otomobil üreticileri ürünlerinde birkaç değişiklik yapmak zorunda kaldı ve satmaya hazırdı. Güvenliğe doğru ilerlemek için halkın mevcut her ürün için tüm üretim dünyasını değiştirmek zorunda kalmadılar. Karşılaştırmanın kısaldığı yer burası.
SBD ve yazılımımızı güvence altına almak için
Bu inanılmaz karmaşıklık seviyesi, sorunun çözülmesinden kimin sorumlu olduğu sorusunu yalvarır. Mayıs 2024’te, yazılım satıcılarının “Güvenli Tasarım (SBD) rehin” i imzalaması için büyük bir baskı vardı. Şu anda, 250’den fazla şirket, tasarım ilkelerine göre güvenli bir şekilde takip etmeyi ve yazılımlarının geliştirme sürecinin her adımında yüksek güvenlikli standartlarla oluşturulmasını sağlamayı taahhüt etmiştir.
Güvenli tasarım rehinini seviyorum, ancak 250 şirket kovada bir düşüş; CyberDB’ye göre sadece 3.500’den fazla siber güvenlik şirketi var. Bunlar sadece günlük hayatımızı güvence altına almak için çalışan şirketler. 250 imza, Amerika Birleşik Devletleri’ndeki şirket sayısına kıyasla sadece bir BLIP’dir. Bazı araştırmalar, 2024 yılında sadece ABD’de 33 milyondan fazla işletmenin olduğunu iddia ediyor, bunların büyük kısmı küçük işletmeler. Zor sorun, riskin çok yüksek olduğunu ve yazılım satıcılarından talep değişikliği olduğunu fark etmek için ABD’deki ve dünya için gereken işletmeler için gereken devrilme noktasına ulaşmaktır.
Pennsylvania Üniversitesi Annenberg İletişim Okulu ve Mühendislik ve Uygulamalı Bilimler Okulu’ndan yapılan araştırmalar, bir nüfusun yaklaşık% 25’inin büyük ölçekli sosyal değişim için devrilme noktasına çarpması gerektiğini göstermektedir. Yakın değiliz.
Düşünmemiz gerektiğini düşündüğüm şey, kod güvenlik sorunlarını daha iyi veya daha hızlı nasıl düzelttiğimiz değil, bunun yerine teşvik yapısının değiştiği ve dünyanın yazılımının kendini düzeltmeye başladığı devrilme noktasına nasıl geldiğimiz değil. Bunu bu şekilde düşünürsek, değişikliğin ancak alıcı talebi ve hükümet tarafından zorunlu kılınan düzenlemelerin bir zemin kargaşası uygulandığında geleceğini hızlı bir şekilde görüyoruz.
2025’te Güvenli Kodu Bir Hareket Olarak Düzeltme
Sunduğum olumsuz görünüm ve temperli beklentiler göz önüne alındığında, muhtemelen bu makaleyi okuduğunuz için pişmansınız. Beyninizde tam tersi bir fikirle ayrılmanızı ve belki de yazılım endüstrisinin daha güvenli bir şekilde yazılım oluşturmak için devrilme noktasına yaklaşabileceği yıl olarak 2025’e yaklaşmanızı çok isterim.
Tartışılan konulara benzer şekilde Herhangi bir hızda güvensizHer türlü yazılım yazan şirketler, sorunun sahipliğini geri almaya devam edecek ve ortaya çıkan herhangi bir sağlık, güvenlik ve güvenlik sorununun sorumluluğunu saptırmaya veya görmezden gelmeye çalışacaktır. Yazılım, sağlık hizmetleri, otomotiv, acil durum iletişimleri, vb. Gibi yaşam ve ölüm durumlarında giderek daha fazla kullanıldığından, iş ve alıcı daha az risk talebi artacaktır.
Yeterince yüksek olursak, bir noktada, yazılım yükümlülüğü ürünü inşa edenlere geçecek ve ne zaman olursa olsun, teşvik yapıları değişecek ve şirketler kendi işlerine risklere daha fazla dikkat edecektir. Ne yazık ki, işletmelerin, sadece müşterileri için yapılacak doğru şey olduğu için, kod güvenliği konusunda yeterince önem verdikleri noktaya geleceğimizi sanmıyorum. Bunun yerine, hedeflerimize ulaşmak için, daha güvenli kod yazmayı işlerinin sağlığı ve başarısı için zorunlu hale getirmeliyiz ve bunu yapmanın tek yolu çok yüksek olmak ve değişiklik talep etmektir.
Peki, 2025’te iğneyi hareket ettirmeye ve güvenli kod devrilme noktasına doğru büyümeye yardımcı olmak için CISO ve BT yazılım alıcısı olarak ne yapabilirsiniz? Her şeyden önce, her birinize yazılım kusurlarının riskleri konusunda eğitilmeniz ve bu sorunları satın aldığınız veya lisansladığınız yazılım geliştiricilerine ifade etmeye yardımcı olmanız gerekir. Kullanıcılar ve geliştiriciler, hem yazılımı satan şirket hem de onu kullanan kişilere güvenliğin öneminin ve yazılım güvenlik açıklarının potansiyel sonuçlarının daha fazla farkında olmalıdır.
İkincisi ve muhtemelen daha kritik olarak, hükümet temsilcilerinizi ve ajanslarınızı konuyla ilgili daha eğitimli olmaya ve güvenli yazılım oluşturma için daha güçlü düzenlemeler ve standartlar oluşturmaya zorlamalısınız. Eğer devlet kurumları adım atmamış ve motorlu taşıtların en azından minimum bir güvenlik seviyesine sahip olmasını talep eden düzenlemeler ve standartlar yerleştirmediyse otomobil asla daha güvenli olmazdı. Yazılım dünyasında devrilme noktasını erişebilecek düzenlemeler yapmalıyız ve hükümeti bu cepheye itmek için alıcılara ve kullanıcılara bağlı. Sorumluluk, yalnızca hükümet dahil olduğunda gerçekleşen inşaatçıya geri dönmelidir. Bu bir ordu alacak, ancak zamanla çığlık atar ve bağırırsak, sadece güvenli bir şekilde yazılmış yazılım satın alır ve yeterince önemli bir gürültü yaparsak, yavaşça iyileştirmeye devam edebiliriz.
‘Tüm Hızlarda Güvenli’ Yavaş Yürüyüş
Tam olarak Herhangi bir hızda güvensiz otomotiv endüstrisi için bir uyandırma çağrısı, yazılım güvenliği sorunları konusunda artan bir farkındalık ve güvenlik açıklarının insan güvenliği ve güvenliğine etkisi, yazılım dünyasında benzer bir hesaplama için baskı oluşturmaktır. Bir Güvence altına almak Tüm Hız Yazılım Geliştirme Dünyası.
2025’te devrilme noktasının vurulduğunu göreceğimizi sanmıyorum, ancak her birimiz en üst düzeyde duyulması gereken hacmi oluşturmak için bu değişikliğe tek tip bir toplanma çığlığı ile yaklaşmalıyız. Teşekkürler, Jen Easterly ve CISA ekibi, bu harekete doğru yaptığınız yer çalışması için ve umarım 2025, başarıya doğru günlük adımlar atmak için birlikte çalışacağımız yıldır.