Güvenlik mühendisliğinde 15 yılı aşkın deneyimi ve 120 siber güvenlik patentiyle ürün güvenliğinin önde gelen uzmanlarından biri olan Adam Boulton, sektördeki en deneyimli yazılım güvenliği profesyonellerinden biridir.
Şu anda Cybellum’da Güvenlik Teknolojisi ve İnovasyon Kıdemli Başkan Yardımcısı olan Left to Our Own Devices podcast’i, Adam Boulton’u bir ürün güvenliği stratejisi oluşturmaya ilişkin deneyimlerini ve ipuçlarını paylaşmaya davet etti.
Adam, kariyerinin gömülü sistemlere öncülük etmesini beklemiyordu. Yıllarca tipik güvenlik açısından kritik sistemlerde yer aldı: gömülü cihazlara gerçek anlamda maruz kalmadan web uygulamaları, mobil uygulamalar, kaynak kodu incelemeleri.
Gömülü sistemlerle daha fazla ilgilenmeye başladıkça, endüstri olgunlaştıkça insanların kaynak kodu analizi konusunda çok rahat hale geldiğini keşfetti. “Yazılımı derlediğiniz yerde cadılık olarak kabul edilir ve bu kara kutuya giren bu kaynak kodudur ve çalıştırılabilir kodu tükürür.”
Derlenmiş yazılımların avantajlı olmasının pek çok nedeni olsa da Adam bunu sorunlu buluyor “Kaynak kodu ve bunun gözden geçirilmesi için ne kadar zaman harcanıyor? Çünkü, aslında yürüttüğünüz veya dağıttığınız şey bu değil.”
Derlenmiş yazılım ve analizin 3 sınırlaması
Adam, derlenmiş yazılım ve analize güvenmenin üç ana sınırlamasında gördüklerini podcast ile paylaştı:
1. Kaynak kodunu test etmek, tüm sistemi dikkate almaz
Şirketler kendi süreçlerinde kaynak kodlarını test etmeyi seçebilse de, son kullanıcıya neyin teslim edileceğinin gerçek bir temsili olmadığı için bu son test olamaz. “Olanların temsiline sahipsiniz. Birden fazla çeviri aşaması çiziyorsunuz ve sonra bunu gerçekten piyasaya dağıtıyorsunuz.”
“Öyleyse neden dağıttığınız, son kullanıcılara, tehdit aktörlerinin erişebileceği şeylere daha fazla zaman ayırmıyorsunuz? Platformda ne yürütülecek? İnşa ortamlarını ve tüm betikleri ve aslında neyin inşa edileceğini kimse kontrol etti mi? Genellikle bunu gözden kaçırırsınız ve bu büyük bir kör noktadır.”
2. Birçok kontrol kaynak düzeyinde gerçekleştirilemez
Kaynak kodu, karmaşık bir gökdelenin yalnızca bir katıdır. Temeli test etmek çok önemlidir, ancak mühendisler aynı zamanda üzerine inşa edilecek her şeyi destekleyebilmek için işlevini yerine getirmek için gereken güç ve bütünlüğü sağlamak için geliştirilen her katı kontrol etmelidir.
Ayrıca Adam, “Kaynak kodu düzeyinde bulunmadığı için kontrol edemediğiniz sağlamlaştırma gereksinimleri gibi tonlarca işlevsel olmayan gereksinim var” uyarısında bulunuyor. Derleyicinin yapacağı şeyler ve yazılımı derleme ve bu talimatları derleyiciye verme şekliniz, yazılımı sağlamlaştırmaya ve daha güvenli hale getirmeye yardımcı olur. Bunu bir kaynak kod analizinde yapmak imkansız.”
3. İnsanlar derleyicilerine çok fazla güveniyor
Adam, birçok güvenlik açığının derleyicinin yapılandırılma biçiminden veya derleme ortamlarının her türlü gizli sırrı veya belgeyi içerme biçiminden kaynaklandığını ortaya koyuyor. Düzgün bir şekilde gözden geçirilmediğinde, bu güvenlik açıkları cihazda kalır, cihazlara gömülü hale gelir ve dünya çapındaki ağlarda aktif hale gelmek üzere gönderilir. Güvende kalmak ve müşteriler tarafından güvenli olarak görülmek, gelecekte bir güvenlik açığının keşfedilmesi durumunda cihazları bileşen düzeyine kadar korumak için SBOM yönetimiyle birlikte geliştirme süreci boyunca kontroller gerektirir.
Gıda veya inşaat endüstrisine benzer bir kalite güvencesi düzeyi sağlamak
Adam, gömülü sistemlerin birçok ürünün kalite güvencesi açısından diğer sektörlerden ders alması gerektiğini ifade etti.
Örneğin gıda endüstrisini ele alalım: “Şefler ya da servis personeli kontrol etsin, kapıdan ne çıktığını kontrol etmek istersiniz. Biliyorsunuz, şef sadece malzemeler hakkında okumayacak” diye ekliyor. “Aynı durum inşaat sektörü için de geçerli. Bir yapı müfettişi sadece planları incelemez. Gerçekte neyin inşa edildiğini kontrol etmeleri gerekiyor. Spesifikasyona göre mi inşa edildi? O mülkün büyüklüğü?”
“Diğer sektörlerden alabileceğimiz ders, gerçekte neyin gittiğini kontrol etmektir,” diye bitiriyor sözlerini.
Metrikler ve KPI’lar ile kaliteli bir yazılım güvenlik stratejisi geliştirme
Adam, deneyimlerinden yararlanarak C düzeyindeki yöneticiler tarafından ürün güvenliğinin yatırım getirisini izlemek ve ölçmek için kullanılabilecek stratejileri ve KPI’ları paylaştı.
“Yıllar boyunca önceki yazılım güvenliği stratejilerine ve bir güvenlik araştırmacısı olarak bireysel olarak katkıda bulunmam gerekenlere baktım. Ve sadece ölçülmediler. Net bir KPI türü yoktu.”
“Bunu diğer takımların çoğunda yapmıyorsunuz ama yine de yazılım güvenliği için, birçok ürün yazılım güvenliği stratejisinde şu soruyu sormak için şu olgunluk eksikliği var gibi görünüyor: Metrikleriniz nerede? YG’mizi nasıl bilebiliriz? Nasıl geliştireceğiz?”
Adam, yazılım tedarik zincirlerinin karmaşıklığında bile her şeyin görünürlük ve hedeflerle ilgili olduğunu açıklıyor. Ürün ekipleri bu görünürlüğü geliştirmeli ve kaliteyi yönlendirmesine izin vermelidir. Yazılım varlıklarını ve envanterini düzenlemek ve bundan sonuçlar çıkarmak için teknolojiyi kullanma ihtiyacını vurguluyor.
“Örneğin bilgi-eğlence sistemi gibi büyük ürünler için, modern bir sistemde 140.000’den fazla dosya vardır, değil mi? Bunlar büyük, karmaşık sistemlerdir. Nereden başlayalım? Aşağıdaki soruları sorup yanıtladığınız ve bu yanıtları zaman içinde takip ettiğiniz niceliksel veya ölçülebilir bir yazılım güvenlik stratejisiyle başlayacağımızı söylüyorum.”
Bu sorulardan bazıları şunlardır:
- Bugün neredeyiz?
- Ne olmak istiyoruz?
- Birkaç yıl içinde nerede olmak istiyoruz?
- Ne başarmak için çalışıyoruz?”
Ürün ekipleri 2023’te bütçeyi nasıl güvence altına alabilir?
Adam, zorlu bir ekonomide ürün ekiplerinin bütçeyi nasıl güvence altına alabileceğine dair birkaç pratik ipucu paylaştı:
- İşi anlayın – CEO’lar, ne kadar tutkulu olursanız olun, CVE’ler ve CVSS puanlarıyla ilgilenmez. Kendinize sorun, ne inşa etmek istiyorlar? İnşa etmek istediğin şey değil.
- Düzenleyici uygulamalarınızı bilin – İş ve risk söz konusu olduğunda sayısallaştırılırlar. C düzeyindeki her yönetici sorumlu tutulacak ve cezayı alacaktır.
- Standartlarınızı bilin – Düzenleyici uygulamaları takip etmeseniz bile, kaliteyi iyileştirmek için standartlara uyum sağlamaya yardımcı olmak harikadır. Çok iyi bir referans malzemesidir.
- güçlü>Stratejiye yakından bakın – Gerçek bir ürün güvenlik ekibi oluşturmadan önce, stratejiye yakından bakın. Büyük ve karmaşık sorunlarla karşı karşıya kalırsanız, yazılımınızın envanterine bakın. “Büyük kuruluşlarla birçok değerlendirme yaptım ve ürün güvenlik ekibiyle birlikte beceri setlerine bakarsanız, geliştirilmekte olan teknoloji yığınıyla uyumlu değiller. İşte envanterin yeniden devreye girdiği yer burasıdır.”
- Ölçülebilir veri noktalarına sahip olun – Veri noktaları, özellikle bir CEO ile çalışırken güvenilirlik oluşturur. “İşte bu yüzden her zaman yazılımın envanterine ve varlıklarına bu kadar odaklandım. Bunu yiyeceklerin malzemeleriyle yapıyoruz. İnşa edeceğimiz ve geliştireceğimiz her şeyi yönetmek için bunu yapı malzemeleriyle yapıyoruz.”
Verilen kaynakları nasıl kullanmayı planladığınıza ilişkin bir temel olarak veri noktalarını yöneticilerle paylaşmak. Bu, yalnızca içgüdüsel bir duyguya dayalı olarak değil, sayıları ve zaman içindeki içsel eğilimlerin tanımlanmasını gerektirir. “Çünkü bunu her yerde yapıyoruz. Bunu yiyeceklerin malzemeleriyle yapıyoruz. Bunu yapı malzemeleri ile yapıyoruz. İnşa edeceğimiz ve geliştireceğimiz her şeyi yönetmek için. Yazılımdan farklı olması gerekmiyor” diyor.
Ancak tıpkı gıda ve inşaat sektörlerinde olduğu gibi, yönetmelikler de girdiğimiz her binaya güvenebilmemiz için güvenlik standartlarının yerleştirilmesine yardımcı oldu. Şirketler, sektörlerinin yüksek güvenlik standartlarını kendi başlarına koruyup koruyamayacağını veya düzenleyici kurumların gelecekte ağır işleri yapması gerekip gerekmediğini kendilerine sormalıdır.