Dr.Allan Friedman Siber Güvenlik ve Altyapı Güvenliği Ajansı’nda Kıdemli Danışman ve Stratejisttir. Yazılım malzeme listesi (SBOM) etrafında küresel sektörler arası topluluk çabalarını koordine etmektedir. Daha önce NTIA’da Siber Güvenlik Girişimleri Direktörü olarak görev yapmış ve güvenlik açığının ifşa edilmesi, SBOM ve diğer güvenlik konularında öncü çalışmalara öncülük etmiştir. Friedman, Federal hükümete katılmadan önce, Harvard’ın Bilgisayar Bilimleri bölümünde, Brookings Enstitüsü’nde ve George Washington Üniversitesi Mühendislik Okulu’nda on yılı aşkın süre tanınmış bir bilgi güvenliği ve teknoloji politikası uzmanı olarak çalıştı. Popüler “Siber Güvenlik ve Siber Savaş: Herkesin Bilmesi Gerekenler” kitabının ortak yazarıdır ve Swarthmore College’dan Bilgisayar Bilimi diplomasına ve doktora derecesine sahiptir. Harvard Üniversitesi’nden.
Terime yabancı olanlar için Yazılım Malzeme Listesinin (SBOM) ne olduğunu ve yazılım geliştirme sürecinde nasıl çalıştığını basit bir şekilde açıklayabilir misiniz?
Yazılım Malzeme Listesi, yazılımın içindekiler listesi gibidir. Yazılım baştan aşağı yeni yazılmıyor. Yapı taşlarından yapılmıştır, bu yapı taşları daha çok yazılımdır. SBOM’lar, hayatımızı yöneten sistemlerin altında ne olduğunu daha iyi anlayabilmemiz için bunu belgelemeyi amaçlamaktadır.
Bugün bir SBOM’a sahip olmak neden önemli?Özellikle Log4j güvenlik açığı gibi olaylardan sonra yazılım ortamı nasıl etkilenir?
Yazılım her zaman hatalı olacaktır. Her zaman kusurlar, riskler ve güvenlik açıkları olacaktır. Önemli olan, daha iyi ve daha güvenli yazılımlar yazmaya çalışırken, bir kusur bulduğumuzda hızlı ve verimli bir şekilde yanıt verebilmektir. Dolayısıyla Log4j güvenlik açığı için bir SBOM bunu engellemez. Ancak bu keşfedildiğinde, yazılım tedarik zincirlerini görebilen herkes, endişelenmeleri gereken ve endişe duymadıkları şeylerin önceliklerini hızlı ve kolay bir şekilde belirleyebildi. Tepkiyi verimli hale getirdi.
Tedarik zinciri saldırılarıyla baş etmede SBOM’un rolü nedir? Saldırı yüzeyini kaplamak yeterli mi, değilse sonraki adımlar nelerdir?
Risk sadece güvenlik açığı değildir; bulup düzeltmemiz gereken, yazılımın doğal bir parçası olan şeylerdir. Ancak aynı zamanda, rakiplerin yazılımı baltalamanın bir yolu olarak tedarik zinciri sonrasındaki kararlı saldırılarından da endişe duyuyoruz. Ve bu sadece bir saldırının meydana geldiğinin belirlenmesi açısından değil, aynı zamanda olasılıkları nerede? Belirli ulusal düşmanlardan kaynaklanan risklere daha fazla maruz kalabilecek belirli yazılım bileşenleri var mı? Yoksa çok fazla bakıcısı olmayan, böylece bir düşmanın isterse devralabileceği açık kaynaklı projelerle mi uğraşıyoruz. Riskin önüne geçmekle ilgili. SBOM yalnızca bir veri katmanıdır. Ve tıpkı bir içerik listesi gibi, ailenizdeki bir kişiyi alerjisi olan bir şeyi yemekten tek başına alıkoyamayacağı gibi, bir SBOM da saldırıları önlemez. Ancak parlak bir ışık yakıp parlatarak bu saldırıların başarılı olmasını çok daha zorlaştırır. Risk faktörlerini önceden tespit ederek başarılı bir saldırı keşfettiğimizde daha ucuza ve daha hızlı yanıt verebiliriz.
SBOM tedarikçi, bileşen, sürüm ve tanımlayıcıları içerir. Bu ayrıntıları takip etmek neden bu kadar önemli ve kuruluşlar bu ayrıntı düzeyini korumayı başaramazlarsa hangi risklerle karşı karşıya kalırlar? Peki, oynatıcı bileşeni sürümünü ve tanımlayıcıları içerdiğinden, bu ayrıntıları izlemek neden bu kadar önemli?
SBOM’un temel amacı riski anlamaktır ancak herkes riski biraz farklı tanımlar. Ve bu doğaldır. Ordunun sağlık sistemi veya okulla aynı riskleri düşünmesini beklemiyoruz. Dolayısıyla bu şeffaflığın amacı, yazılımımızda ne olduğunu anlayabilmek ve böylece onu önemsediğimiz şeylerle eşleştirebilmektir. Bazı kuruluşlar, özellikle ilk başta, gerçekten güvenlik açığı yönetimi tarafına odaklanacak. Diğerleri ise şu anda dönmelerine olanak tanıyan belirli türdeki düşmanların saldırısı altında olduklarını biliyor.
SBOM’ları benimseme konusunda geliştiricilerin ve şirketlerin bazı dirençleriyle veya geri itmeleriyle karşılaştınız mı? Ortaya koydukları tipik endişeler nelerdir?
Ne zaman ekstra bir şey yapmaktan bahsediyorsanız, bunun elbette bir bedeli olacaktır, bunu çok iyi biliyoruz. Bu endişelerin bir kısmı iyi niyetle yapılıyor. Bu, maliyeti önemli ölçüde artıracak mı? Çok ciddi bir artış olmayacağını düşünüyoruz. Örneğin, Birleşik Krallık Ulusal Siber Güvenlik Merkezi, SBOM’un iyi bir yazılım sürecinin doğal bir yan ürünü olması gerektiğini açıklayan bir blog yazısı yayınladı. Fikri mülkiyetle ilgili konularda endişe duyan insanlar var, ancak yine açık kaynak lisansları gibi şeyler için zaten belirli bir miktarda şeffaflık gerekiyor; ve biz de bu SBOM fikrini, kiminle paylaşımda bulunduğunuza bağlı olarak bilinmeyenleri bilebileceğiniz gerçeğini oluşturduk. Ve dürüst olacağım, bazen bazı endişeler değişim riskiyle ilgili geleneksel endişelerdir. Bu çok yaygın, doğal bir insan tepkisidir. Ancak son birkaç yılda bile, – Evet, bu imkansız – – Tamam, bunu nasıl uygularız ve nereden başlarız?
‘Düzenleme ve uyumluluk geliyor…’ dediniz. Şu anda SBOM’ların kamuya açıklanması yönünde herhangi bir düzenleme baskısı yok. Gelecekte bunun değişeceğini öngörüyor musunuz?
Giderek daha fazla itme var. Öncelikle yazılım üreten şirket ve kuruluşların ne yaptıklarını bilmeleri gerekiyor. Ve çabanın büyük bir kısmı sadece onlar için farkındalık olmasını sağlamak içindir. İkinci parça ise, Tamam, SBOM’un bir kopyasını müşteriye veya düzenleyiciye vereceğiz demek. Örneğin Amerika Birleşik Devletleri’nde tıbbi cihaz düzenleyici kurumu FDA, SBOM’un bir kopyasını düzenleyiciye vermeniz gerektiğini söylüyor. Benzer şekilde, eğer Avrupa’daysanız Siber Dayanıklılık Yasası, bir SBOM’un ulusal ajansın kullanımına sunulmasını gerektirir. Bunların hiçbiri “Yazılımımın içinde ne olduğunu herkese söylemem lazım” demek içermiyor. Temel amaç, yazılımı kullanacak konumda olanların, yani müşterilerin ve kamu-ulusal düzenleyicilerin koruyucusu konumunda olanların verilere erişiminin sağlanmasıdır.
Yazılımın ötesinde, Donanım Malzeme Listesinden ve hatta Şifreleme ve Yapay Zeka Malzeme Listelerinden bahsettiniz. Bunların nasıl gelişeceğini öngörüyorsunuz?
SBOM’un gücü, şeffaflık beklentisi yaratarak, yazılım yapanlara hesap verebilirliği dayatmamız ve yazılımı kullananlara, yazılımı kullanma becerisine sahip oldukları için riskleri daha iyi anlamalarını sağlamamızda yatmaktadır. Şeffaflık tüm sorunlarımızı çözmez ama bize güç verir. Benzer şekilde, diğer alanları sabırsızlıkla beklediğimizde, giderek daha fazla insan, sistemlerimizdeki donanım bileşenlerinin nereden geldiği konusunda daha fazla şeffaflığa duyulan kritik ihtiyacı görüyor. Özellikle de ulusal güvenlik risklerinden endişe duyduğumuz bir dönemde. Özellikle kuantum hesaplamayı ileriye baktığımızda, sistemlerimde hangi kriptografik materyalleri ve algoritmaları kullanıyorum? Ve elbette, yapay zeka sistemlerini düşündüğümüzde – bunların çoğu şeffaf kutular anlamına geliyor ve şunu söyleyerek başlamamız gerekiyor – en azından bunları oluşturmak için hangi modellerin, hangi verilerin, hangi altyapının kullanıldığını anlayalım.
Paket servis mesajı olarak SBOM’daki SB, sihirli değnek anlamına gelmez. Peki bunu güvenlik dünyasının dışından insanlara anlattığımda? Zaten şeffaflık alışkanlığımızın olmaması açıkçası onları şaşırttı. Şekerimizi yapan kişilerin bize şekerimizin içinde ne olduğunu söyleyebilmelerini bekliyoruz ve kritik altyapımızı çalıştıran yazılımlar için de aynı seviyede şeffaflığa sahip olmalıyız.
