HAVELSAN A.Ş. Kıbrıs Barış Harekatı’ndan sonra ülkemize uygulanan ambargonun sebep olduğu farkındalık neticesinde milli teknolojileri geliştirmek amacıyla kurulan Türk Silahlı Kuvvetlerini Güçlendirme Vakfı’nın bir şirketidir.

HAVELSAN, dünya çapında bilişim ve savunma piyasasında hizmet veren bir global sistemler ve yazılım şirketi olup, Komuta Kontrol, Simülasyon ve Eğitim Sistemleri ve Yönetim Bilgi Sistemleri alanlarında temel yetkinlikler geliştirmektedir.

Savunma, güvenlik ve bilişim sektörlerindeki gelişmeler teknolojik gelişmelerle giderek daha yakın seyretmektedir. Her ne kadar işlevsel ihtiyaçlar farklı olsa da, teknolojiler ve metodolojiler ortak yönler göstermektedir. Karşılıklı çalışabilirlik, tüm sektörlerin ayrılmaz bir parçası ve belkemiği haline gelmiştir.

Bu kapsamda, dijital dünyanın yazılım yoğunluklu sistemleri tüm sektörlere giriş yapan teknolojiler haline gelmişlerdir. HAVELSAN şimdiden, mevcut bilgi birikimi ile savunma, güvenlik ve bilişim sektörlerinde Komuta Kontrol, Simülasyon, Test ve Değerlendirme ve Eğitim Sistemleri ve Yönetim Bilgi Sistemleri alanlarıyla ilgili sahip olduğu uzmanlığı arasında bir sentez oluşturmuş ve böylece yazılım yoğunluklu sistemler üreten öncü şirketlerden biri haline gelmiştir.

Hayatımıza teknolojiyi göbeğinden aldığımız ve mobil dünyanın getirdiklerine baktığımızda sanki yaptığımız her şeyi dünyaya duyurmak istermiş gibi teknolojiyi sömürmeye çalışıyoruz. Ne yaptığımız, ne yediğimiz, ne içtiğimiz, ruh halimiz vb. Bütün bunları yapmamızı sağlayan dünyada tabii ki bu veya kullanılan sistemler üzerindeki açıklardan başka bilgileri ele geçirip kötü amaçlar için kullanmak isteyen insanlar da bir gerçek olarak karşımıza çıkmaktadır. Bugün kullanıcı hesabımız çalınır yarın paralarımız! Ya sonrası?

İşte bu ve benzeri soruları cevaplayabilmek ve önlem alabilmek için öncelikle bu teknolojilerin kullandığı altlıkları incelememiz ve oralarda önlemlerimizi sıkılaştırmamız gerekmektedir. Bu teknoloji dünyasının en önemli bacaklarından biri de yazılım dünyasıdır. Bilgisayarların ilk ortaya çıkmasıyla birlikte yazılım geliştirme süreci de başlamıştır. Bu süreç 1940’lı yıllara kadar gitmektedir. İlk yıllarda geliştirilen yazılımlarda görülen en büyük eksiklik yazılım projelerinin zamanında tamamlanamaması ve istenilen kalitede (dokümantasyon, fonksiyonellik, harcanan fazla iş gücü) olmamasıdır. Bunlara ek olarak teknolojinin hızla değişmesi, birçok yazılımın hız ve fonksiyonellik eksikliklerinden dolayı devre dışı kalmasına ve işin yeniden projelendirilmesine neden olmuştur. Günümüz dünyasında teknoloji kullanarak yaptığımız birçok şeyi aslında bir yazılım aracılığı ile gerçekleştirdiğimizi de düşünürsek, bu dünyada nasıl önlemler alabileceğimiz hususunda da faaliyetleri incelemek gerekecektir.

İnternetin yaygın olarak kullanılmaya başlanması ile yazılımlar içerdikleri güvenlik zayıflıkları/açıklıkları nedeniyle kötü niyetli veya bilinçsiz kullanıcılar tarafından kötüye kullanılmaya başlanmış ve e-ticaret, e-devlet, e-sağlık gibi günlük hayatımızdaki işlerin yazılımlar aracılığı ile güvenli olarak sağlanması riskli olmaya başlamıştır.

Şekil 1 de Microsoft tarafından 2012 yılında belirlenmiş önceliğine göre güvenlik açıklıkları bulunmaktadır. Şekil 2 de ise Ortak Güvenlik Açıkları ve Etkilenmeler tarafından (CVE) 2012 yılında belirlenmiş önceliğine göre güvenlik açıklıkları bulunmaktadır.

Bu sonuçlara da baktığımızda çok önemli açıkların oranının ne kadar fazla olduğunu görebilmekteyiz. Bu açıklıkların artma nedenlerinin başında internetin yaygın olarak kullanılması ve bilgisayarın iş uygulamaları da dahil olmak üzere kullanım oranının çok artması gelmektedir. Diğer önemli sebep yazılımların güvenliği dikkate alınmadan sadece fonksiyonellik göz önüne alınarak geliştirilmesidir. Bu durumda yazılımlar birçok açıklık içermektedir. Ayrıca yazılımın ortaya çıkmasından sonra tespit edilen açıklıkların kapatılması için çok fazla iş gücü ve zaman harcanmaktadır. Çünkü bir güvenlik açıklığı yazılım geliştirme evresinde ne kadar erken tespit edilebilirse, o açıklığın kapatılması maliyeti o kadar az olacaktır.

Yazılım geliştirme sürecinin yaygın olarak kullanılmaya başlandığı ilk yıllarda kaliteli ve olgun yazılım üretmek için, son yıllarda ise özellikle güvenli yazılım geliştirmek için çok sayıda model ve anaçatı üzerinde çalışılmıştır. Bu süreç CMM (Capability Maturity Model) ile başlamış daha sonrasında CMMI (Capability Maturity Model Integration), FAA–iCMM (Federal Aviation Administration integrated Capability Maturity Model), Trusted CMM, SSE-CMM (Security System Engineering CMM), Microsoft Security Development Lifecycle, OpenSAMM (Software Assurance Maturity Model) modelleri gibi modeller geliştirilmiştir.

Farklı ülkelerde üretilen yazılım/donanım ve sistemlerin farklı standartlara göre güvenlik değerlendirmelerinin gerçekleştirilmesi, uluslararası satılan ürünlere uygulanmış testlerin diğer ülkelerde anlaşılamamasına, yazılım/donanım ve sistem güvenliği konusundaki çalışmaların farklı ülkelerde farklı şekilde geliştirilmeye çalışılması sorunlara sebep olmuştur. Bu ve buna benzer ortak dil problemlerini giderebilmek amacı ile Kanada, Fransa, Almanya, İngiltere, Avustralya, Yeni Zelanda ve Amerika Birleşik Devletleri 1996 yılında bir araya gelerek Ortak Kriterler (Common Criteria) standardı sürüm 1.0’ı yayınlamışlardır. Bu standart çerçevesinde ürün değerlendirme seviyeleri EAL1 (Evaluation Assurance Level) ‘ den EAL7’ ye kadar değişmektedir. Hali hazırda standardın 3.1 sürümü kullanılmaktadır. Ortak Kriterler standardı 25 ülke tarafından kabul edilmiştir. Ortak Kriterler aynı zamanda ISO tarafından EN ISO/IEC 15408 standardı olarak yayınlanmıştır.

Yazılım Geliştirme Modelleri

Yazılım geliştirme süreçleri (Waterfall, Spiral, Agile gibi) temelde planlama, tasarım, kodlama, test, kurulum, bakım gibi benzer basamaklardan oluşurlar. Sonuçta ortaya çıkan sistemin/ürünün güvenli olması isteniyorsa bilgi güvenliği konusu bir süreç gibi algılanmalı ve gerekli aktiviteler yazılım süreçlerinin her basamağına bütünleştirilmelidir. Bu sayede örneğin planlama aşamasında yazılım geliştiricilere güvenli kod geliştirme üzerine eğitim verilmeli ya da test aşamasında uygulama seviyesinde otomatik araçlarla güvenlik testleri gerçekleştirilmesi gibi projelerde görmezden gelinen önemli aktivitelerin yazılım sürecine dahil edilmesi sağlanmalıdır. Bu süreçleri ihtiva eden değişik yazılım geliştirme modelleri söz konusudur. Bu modeller;

• Yetenek Olgunluk Modeli (CMM - Capability Maturity Model)
CMM özel süreçler (yazılım mühendisliği, sistem mühendisliği, güvenlik mühendisliği) için hedef aşamalar tanımlar. Fakat bu işlemler için rehber dokümanlar sağlamaz. Bu süreçler ne istendiğini tanımlar fakat nasıl olacağını tanımlamaz.

• Tümleşik Yetenek Olgunluk Modeli (CMMI, Capability Maturity Model Integration)
CMMI (Capability Maturity Model Integration) uzun vadede organizasyonun iş performansının olgunluğunun artırmasına yardım etmektedir. CMMI, organizasyonların işlemlerinin yeteneğini ve olgunluğunu değerlendirmek için servis geliştirme, bakım, satın alma mekanizmaları için en iyi pratikleri sunmaktadır.

Bu model tarafında içerilen geliştirme alanları, sistem mühendisliği, yazılım mühendisliği, tümleşik ürün ve süreç geliştirme, tedarikçi kaynakları ve satın alma alanlarıdır. CMMI, CMM’in üzerine geliştirilmiş olup sekiz yıldan beri kullanılmaktadır.

• Federal Havacılık Yönetim Tümleşik Yetenek Olgunluk Modeli (FAA-iCMM Federal Aviation integrated Maturity Model)
FAA-iCMM federal havacılık yönetiminde yaygın olarak kullanılır. FAA-iCMM modeli, dış kaynak kullanımı ve kaynak yönetimini de içeren büyük yazılım sistemlerinde
(enterprise) ilerlemeler yapmayı hedefleyen en iyi pratiklerden oluşan bir model sunar. Son sürümü tümleşik büyük yazılım yönetimi, bilgi yönetimi kullanım/geçiş/devre dışı bırakma ve işlem/destek süreçlerini içerir.

• Güvenli CMM/Güvenli Yazılım Metodolojisi (Trusted CMM/Trusted Software Methodology (T-CMM, TSM))
Bu model düşük seviyelerde bilmeden yapılan geliştirici hatalarına karşı yüksek seviyelerde ise bilerek yapılan zararlı yazılım ataklarına karşı direnç sağlayan seviyelerden oluşmaktadır. TSM daha sonra CMM ile birleştirilmiş (Harmonize) ve Trusted CMM ortaya çıkmıştır. Günümüzde çok fazla kullanılmamaktadır.

• Sistem Güvenlik Mühendisliği Yetenek Olgunluk Modeli (SSE-CMM -- Systems Security Engineering Capability Maturity Model)
SSE-CMM bir organizasyonun güvenlik mühendisliği yeteneğinin değerlendirilmesi ve geliştirilmesi için kullanılabilecek bir süreç modelidir. SSE-CMM, güvenlik mühendislik pratiklerini genel olarak kabul edilmiş mühendislik prensiplerine göre değerlendirip kabul edilebilir bir çerçeve ortaya koyar. Böyle bir çerçeve güvenlik mühendislik prensiplerinin uygulamalarında performansı ölçme ve iyileştirmeyi sağlar. SSE-CMM ISO/IEC 21827
standardı olarak yayınlanmış ve hali hazırda sürüm 3 yayınlanmıştır.

• Microsoft Security Development Lifecycle (SDL)
Bu model yazılım geliştirmenin başlangıcından itibaren güvenli yazılım geliştirme ve yaşam döngüsünü hedefler. Bu hedeflere ulaşmak için, eğitim ve farkındalık, proje başlangıcı, en iyi pratikleri tanımla ve uygula, risk analizi yap, risk analizi aracı, risk analizi, yazılım dokümantasyonu araçları ve müşteriler için en iyi patrikler, güvenli kodlama politikası, güvenli test politikası, güvenlik ekleme, son güvenlik kontrolü, güvenlik müdahale planlaması, ürün çıkarma güvenlik cevapları ve işletme olmak üzere on üç adımı kullanır. Bu modelin temel dezavantajı doğrudan proje yöneticisinin liderliğine bağlı olmasıdır.

• OpenSAMM Modeli
OWASP (Open Web Application Security Platform) tarafından desteklenmektedir. Bu çalışmada güvenli yazılım geliştirme amacıyla bir ana çatı oluşturulmaya çalışılmıştır.

Ana çatı, büyüklükten bağımsız bir şekilde her organizasyonun kendine adapte edebileceği, normal yazılım geliştirme döngülerine uyarlayabileceği ve bir organizasyondaki yazılım güvenliği alanında gelişmeyi yönlendirebilecek bir yapıda oluşturulmuştur.Modellerin güvenliğe bakış açısını irdelediğimizde Tablo 1 bize bu konuda bilgi verebilir.

Common Kriterler - SSE-CMMI – MİCROSOFT-SDL - OPENSAMM

Bilgi Güvenliği
Bilinçlendirmesi ve Eğitimi X √ √ √

Fiziksel ve Mantıksal Güvenlik √ √ X X

Güvenli Yapılandırma Yönetimi √ √ X X

Yasa, Politika ve Prosedür
Uyumluluğu X √ X √

Tehdit Modellemesi √ √ √ √

Risk Analizi √ √ √ √

Güvenlik Gereksinimleri Belirleme √ √ √ √

Güvenlik Mimari √ √ √ √

Güvenlik Tasarım √ √ √ √

Kaynak Kod Analizi X X √ √

Açıklık Analizi X √ √ √

Güvenlik Doğrulaması √ √ √ √

Açıklık Yönetimi √ √ √ √

Güvenli Geliştirme Teknikleri
Belirleme ve Uygulama X √ √ √

Operasyonel Ortama Bilgi
Aktarma √ √ √ √

Çevre Bileşenlerle Güvenli
Entegrasyon √ √ √ √

Güvenli Teslim Etme √ √ X √

Tabloyu incelediğimizde tüm modellerde muhakkak bazı eksiklikler olduğunu görebilmekteyiz. Bu da yazılım geliştirme süreçlerimizde muhakkak suretle modelleri birleştirme yoluna gitmemizin uygun bir yöntem olabileceğini bize göstermektedir. Bilgi sistemlerinde kullanılan yazılımların, güvenli olarak geliştirilmemesinden dolayı yazılımlarda sürekli açıklıklar çıkmaktadır. Bu açıklıklar ve zayıflıklar kullanıcılar tarafından bilerek ya da bilmeden kötüye kullanılabilmektedir. Kullanıcılar bilgi sistemlerinde kullanacakları yazılım ya da sistemlerin de bu tür açıklıkların olmamasını istemektedir. Bu açıklıkları ve onların etkilerini azaltmanın en etkin yöntemi ise yazılımın güvenli olarak geliştirilmesidir.

Özellikle günümüzde açık noktalar olarak kastedilenlerin aslında yazılım geliştirme sürecindeki güvenlik unsuruna yeterince önem verilmemesinden kaynaklandığını bilmek, güvenlik gözü ile baktığımızda, tam bir “ayağa kurşun sıkmak” olarak da nitelenebilir. Çünkü ne kadar açık nokta, o kadar kötü imaj demektir!

Haberin Kaynağı : RailwayTurkey Demiryolu Tedarikçileri Dergisi

02.01.2014