Teknoloji, OEM’lerin otomobil üretme biçiminde devrim yaratırken, yazılım destekli bu değişim aynı zamanda yeni riskleri ve zorlukları da beraberinde getirdi. Arabalar daha fazla bağlantılı hale geldikçe daha fazla siber güvenlik tehdidine maruz kalıyorlar. Yazılım açıkları ve açık kaynak kodu, bilgisayar korsanları tarafından güvenlik açısından kritik sistemleri tehlikeye atmak, kişisel verilere erişmek ve hatta uzak bir yerden bir arabayı çalıştırmak için kullanılabilir. Ayrıca araç yazılım ekosisteminin artan karmaşıklığı nedeniyle entegrasyon ve kod kalitesinin korunması da zorlaştı.
OEM’lerin ve 1. Kademe tedarikçilerin güvenlik risklerini azaltmak, mevzuat uyumluluğunu sağlamak ve otomotiv yazılım geliştirme döngüsünü kolaylaştırmak için atabileceği bazı pratik adımları inceleyelim.
Düzenleyici beklentilerin karşılanması
Son birkaç yılda otomotivde siber güvenlik uygulamalarının standardizasyonu ve düzenlenmesinde çarpıcı değişiklikler gördük. Bunlardan bazıları, siber güvenlik odaklı bir geliştirme süreci ve ürünü sağlamanın fiili bir yolu haline gelen ISO 21434, ASPICE siber güvenlik uzantısı ve UNR155’tir. UNR155 çoğunlukla AB’de geçerli olsa da, diğer birçok ülke bunu takip ediyor veya benzer yönergelere veya düzenlemelere sahip. Üstelik otomotiv pazarının küresel yapısı nedeniyle AB düzenlemelerinin AB dışındaki üreticiler üzerinde de büyük etkisi var.
Bu tür beklentilerin ortaya çıkmasıyla birlikte sektör yavaş yavaş kendisini bu yeni gereksinimlere uyum sağlayacak ve karşılayacak şekilde şekillendiriyor. Bu, tüm otomotiv üreticilerinin ve tedarikçilerinin birçok farklı departmanını etkileyen, yavaş bir süreçtir. Bunun aynı zamanda yeni düzenleyici beklentilerin karşılanıp karşılanmadığını nasıl denetleyeceklerini öğrenmesi gereken denetçiler ve değerlendiriciler üzerinde de etkisi vardır.
Bu değişiklikler, geliştirme döngüsüne ve aracın yaşam döngüsünün geri kalanına (üretim, üretim sonrası vb.) yeni adımlar katıyor. Yeni çalışmalar üreticiler için ek iş ve artan maliyet anlamına geliyor.
Peki, OEM’ler ve Seviye 1’ler, zaten son derece sıkı olan proje çerçevesine daha fazla zaman ve malzeme yatırımı gerektiren bu yeni çabalarla nasıl başa çıkıyor?
Sola kaydırma ve otomasyon
Cevap, tüm endüstrilerin her zaman yaptığını yapmaktır. Otomotiv üreticilerinin ve tedarikçilerinin kalite hususlarını nasıl ele aldıklarını göz önünde bulundurursanız, her aşama için doğrulama ve doğrulamayı sürecin mümkün olduğu kadar erken bir zamanda (“sola kaydırma”) gerçekleştirmeye yönelik sürekli bir çaba olduğunu göreceksiniz. Üreticiler bunu yaparak olası bir hatanın etkisini ve bunu düzeltmek için gereken süreyi azaltır.
Diğer önemli unsur otomasyondur. Bu özellikle büyük ölçek gerektiren durumlar için geçerlidir. Gereksinim izleme, dağıtım, performans analizi, işlevsel test ve diğer süreçlerin otomatikleştirilmesiyle her küçük değişiklik test edilebilir ve proje ve ürün üzerindeki istenmeyen etkiler anında raporlanıp giderilebilir.
Sektör, yeni siber güvenlik düzenleme gerekliliklerini karşılamak için araç ve süreçleri uygulamaya koyarken, aynı ilkelerin hâlâ geçerli olduğu açıkça görülüyor. Yavaş yavaş, uyumluluğu karşılamak için gereken çabayı ve zamanı azaltmaya yardımcı olan gerekli siber güvenlik aşamalarını otomatikleştirmek ve “sola kaydırmak” için araç ve yöntemlerin ortaya çıktığını görüyoruz.
Daha çok değil, daha akıllıca çalışmak (pratikte!)
Argus olarak yaptığımız işlerin bir kısmı otomotiv şirketlerine siber güvenlik ve mevzuat uyumluluğu ile ilgili süreçlerinde destek olmaktır. Bu etkileşimler aracılığıyla, bir OEM’in/tedarikçinin siber güvenliği uygulamada daha verimli hale gelmek için gerçekleştirebileceği bazı faydalı eylemleri belirledik. Örneğin, şirket içi uzmanlığı daha etkin kullanmak ve belirli faaliyetlerde dış kaynak kullanımına daha az güvenmek.
Bu bağlamda, OEM’lerin ve Tier 1 tedarikçilerinin güvenlik sorunlarını geliştirme sürecinin erken safhalarında tespit edip çözmelerine yardımcı olabilecek, bu yeni düzenlemelerin zorunlu kıldığı iki önemli faaliyet, sızma testi (fuzz testi) ve güvenlik açığı yönetimidir.
Otomatik tüylenme test
Fuzz testi, güvenlik açıklarını, hataları veya beklenmedik davranışları ortaya çıkarmak için bir programa geçersiz, beklenmedik veya rastgele veri girişleri beslemeyi içeren bir yazılım test tekniğidir. Otomotiv endüstrisi bağlamında, otomotiv yazılım sistemlerinin güvenliğini ve sağlamlığını değerlendirmek için bulanıklaştırma kullanılır. Fuzzing’in etkili olabilmesi için otomotiv protokollerini, kullanım senaryolarını ve otomatik test prosedürlerini dikkate alması gerekir. Doğru şekilde uygulandığında bu tür testler, projenin ilk aşamalarında ve sonrasında minimum çabayla kusurları ve güvenlik açıklarını ortaya çıkaracaktır.
Günümüzde çoğu üretici, son ürünü işlevsellik ve güvenlik açısından kontrol etmek için simülasyon sistemlerine büyük ölçüde güveniyor. Bu tür simülasyon ve test ürünlerinin birçok farklı uygulaması ve satıcısı olsa da, bazıları çözümlerinin bir parçası olarak “siber güvenlik” paketleri veya araçları sunmaya başlıyor. HIL/SIL kurulumunuza otomatik bir Fuzzing testi uygulayarak sistemdeki güvenlik düzeyini otomatik olarak artırabilirsiniz. Bazı ürünler, belirli testlerle test edilen düzenleyici gerekliliklere atıfta bulunan otomatik raporlar bile sağlar; böylece bunlar, uyumluluğu sağlamak için kolayca kanıt olarak kullanılabilir.
Sadece tüy değiling
Ağır hizmet Döngüdeki Donanımın/Döngüdeki Yazılımın parçası olması gerekmeyen güvenlik sorunlarını daha kolay tespit etmek için geliştirme veya test ekibi tarafından kullanılabilecek birçok başka araç vardır (HIL/ SIL) sistemi. Bazı araçlar açık kaynaklıdır ve tamamen ücretsizdir. Böyle bir örnek “python-udsoncan”dır. Bu yardımcı program, bir mühendis tarafından bir UDS sunucusuyla farklı şekillerde etkileşimde bulunmak ve güvenlik kusurlarını tespit etmek için kullanılabilir. Bunu bir adım daha ileri götürerek, yeterli güvenlik uzmanlığına sahip bir mühendis, UDS işlevselliğinin güvenlik açısından doğruluğunu sağlamak için otomatik testler oluşturabilir ve bu testlerin her yeni yazılım sürümünde yürütülmesini sağlayabilir.
Güvenlik Açığı Ma yüzme
Araçlar giderek daha fazla yazılım tabanlı hale geldikçe ve farklı kaynaklardan gelen daha fazla yazılım kütüphanesi birbirine entegre edildikçe, bu kod parçalarından birinin güvenlik açığı içerme riski de artıyor. Bir araç yola çıktıktan iki yıl sonra, araçta kullanılan yazılım kitaplıklarından birini etkileyen bir güvenlik açığı yayınlanırsa ne olur? Hangi araçların etkilendiğini nasıl anlarsınız? Potansiyel etkiyi nasıl değerlendiriyorsunuz ve nasıl yanıt veriyorsunuz?
Bu sorun, doğrudan bir Yazılım Malzeme Listesinin (SBOM) aracın ömrü boyunca saklanmasını ve takip edilmesini gerektiren UNR 155 ve ISO 21434 gibi düzenleme ve standartlarla ele alınmıştır. Yeni yayınlanan güvenlik açıklarının hızlı bir şekilde belirlenip giderilmesi için SBOM’un sürekli olarak izlenmesi gerekir. Bu aktivite projenin erken bir aşamasında yapılmalıdır. Yazılımınızı erken, otomatik olarak ve her yeni sürümde tarayarak, üründe bulunan bilinen tüm güvenlik açıkları anında tespit edilir ve sorumlu mühendis veya tedarikçi tarafından giderilebilir.
Bu tür bir taramanın yalnızca geç sürüm aşamasında gerçekleştirilmesi, gecikmelere ve/veya riskli tavizlerin alınmasını gerektiren bir duruma neden olabilir. Her yeni yazılım sürümünden otomatik olarak SBOM oluşturan ve onu etkileyen bilinen güvenlik açıklarına ilişkin bir rapor sağlayan uygun bir Güvenlik Açığı Yönetimi çözümü, bu sorunların tanımlanması ve giderilmesi için gereken manuel çabaları önemli ölçüde azaltır.
Alt Liöyle
Günümüzün karmaşık yazılım odaklı ekosisteminde araç üreticileri, güvenlik önlemlerini geliştirme sürecine erken entegre etmenin önemini fark etmeye başladı. Bu “sola kaydırma” güvenlik yaklaşımı, otomotiv yazılım geliştiricilerinin ürünlerinin genel kalitesini ve güvenliğini iyileştirmesine olanak tanırken aynı zamanda pazara çıkış süresini hızlandırıp geliştirme maliyetlerini azaltır.
Yazılım geliştirme sürecinin ayrılmaz bir parçası olarak bulanıklık testi ve güvenlik açığı yönetimi gibi gelişmiş siber güvenlik araçlarını ve süreçlerini birleştirmek, OEM’lerin ve Kademe 1’lerin ürün geliştirmeyi kolaylaştırmasına ve uyumluluk hedeflerine ulaşmasına yardımcı olabilir.
Yazar Hakkında
Oron Lavi, 2014 yılında kurulan öncü bir şirket olan Argus Cyber Security’nin Baş Teknoloji Sorumlusu ve Kurucu Ortağıdır. Teknoloji endüstrisinde zengin bir deneyime sahip olan Oron, daha önce Salesforce.com’da kıdemli yazılım mühendisi ve CTO olarak görev yaptı. CBVW. Tel Aviv Üniversitesi’nden magna cum laude ile mezun olan Bilgisayar Mühendisliği alanında Lisans derecesine sahiptir.
Oron’a şu adresten çevrimiçi olarak ulaşılabilir: https://www.linkedin.com/in/oron-lavi-10777b3/ ve şirket web sitemizde https://argus-sec.com/