|
Dizayn hataları, üzerinde çok düşünülmemiş güvenlik açıkları, yeni geliştirilen malware uygulamaları ve bunlar gibi bir çok neden geliştirilen uygulamaların debug ve patching süresini maksimuma çıkartır. Bu debug seansları uzun zaman almasının yanında yazılımcıyı moral olarak da kötü etkiler. Dolayısıyla programın yapımına harcanılan bütçeyi bile geçebilecek yatırımlar yapılması zorunlu hale gelir.
Microsoft işte bu problemi halledebilecek sistematik bir yapı geliştirerek uygulamalarını daha program çıkmadan dışarıdan gelebilecek saldırılara karşı korumasını sağlamayı hedefliyor. Bu yapının ismi de SDL (Güvenlik Geliştirme Süreci) dir. SDL, Microsoft bünyesinde yazılım geliştirenler tarafından bilinmesi zorunlu olan bir yapıdır. Her sene bu sürece yeni eklentiler ilave edilir ve yazılımcılara bu yenilikler anlatılarak benimsenmeleri sağlanır.
Bir uygulamanın SDL sürecine dahil olup olamayacağı ise uygulamanın kullanımına göre değişir. Eğer bir uygulama İnternet erişimine ihtiyaç duyuyorsa ve önemli bilgiler içerebilecek türden bir programsa bu sürece dahil edilir. SDL ile üretilmemiş ancak daha sonra SDL’e geçirilme durumu olan uygulamalar ise Service Pack gibi yamalar sayesinde bu sürece dahil edilir.
Neden SDL?
SDL ürünün güvenlik maliyetini büyük oranda düşürüp daha az bütçe ile daha güçlü güvenlik sağlanmasına yardımcı olur. Microsoft’un 2002 Ocak ayından bu yana prensip haline getirdiği “Trustworty Computing” (güvenilir yazılımcılık) standardının bu alandaki güvenliği olumlu yönde etkilediği gibi bütçeyi de 7 ye 1 oranla düşürdüğü görülüyor.
Şekil-1 Güvenlik Maliyeti
Bu adımlar basitçe şu şekilde sıralanır;
Şekil-2 Adımlar
Eğitim
Eğitim daha önce de bahsettiğimiz gibi bütün çalışanların almak zorunda olduğu SDL süreci hakkında bilgilendirmedir. Süreç başlarken ve devam ederken sürekli yapılması gerekenleri yazılımcının bilmesi önemli olduğu için eğitim kısmı her sene SDL implementasyonu değiştiğinde önem kazanır.
Analiz
Dizayn kısmına başlanmadan önce durum analizi bu program kimler için yazılacak, hangi özelliklere dikkat edilecek, nasıl bir yol izlenecek gibi sorulara alt yapı oluşmasını sağlayan “beyin fırtınası” kısmıdır. Bu kısım aynı zamanda uygulamanın ortalama ne kadara mal olacağının da belli olduğu bölüm olur. Özellikle dikkat edilmesi gereken konular saldırı modellerini programın hangi bölümlerinde test edileceğinin karar verilmesidir. Bu modelleri düşünürken çok dikkatli olmak gerekir çünkü bundan sonra gelişen programı değiştirmek gerektiğinde ekstra maliyet çıkar.
Dizayn
Programın nasıl olacağının tam olarak belirlendiği adım olan dizayn adımı, yazılımın SDL çerçevesinde nasıl gelişeceğinin analiz bölümünde edinilen bilgiler ışığında planlanması olarak özetlenebilir. Ancak analiz bölümü yeteri kadar dikkatli yapılmamışsa dizayn hataları oluşabilir. Bir uygulamayı dizayn ederken analiz adımında programın hangi bölümünde kullanılacağı düşünülen saldırı modelleri tasarlanır, bu modellere karşı nasıl bir koruma sağlanacağı teknik bir şekilde ele alınır. Yazılımcılar kriptoloji veya başka yöntemler ile bu modellere karşı önlem alır. Burda saldırı modellerinden kasıt, uygulamanın açıkları veya uygulamanın sağlıklı çalışabilmesini etkileyebilecek olan etkenler olabilir. Bütün bunlar yapıldıktan sonra bir risk analizi yapılır, eğer hala açıklar bulunuyor ise, onlar içinde savunmalar geliştirilir ve bu adım başka açıklar kalmayana kadar tekrar edilir. Aynı zamanda uygulamayı dizayn ederken dikkat edilmesi gereken bir husus da uygulamanın işletim sistemi üzerindeki haklarının gerektiğinden daha fazla tutulmaması ve bu sayede uygulamanın açık verebileceği alanların daraltılmasıdır.
Yapım Aşaması
Kullanıcının isteğine göre değişebilecek güvenlik önlemlerinin düzeyini değiştirebilecek araçlar tasarlanması önemlidir. Bu araçların son kullanıcıya nasıl kullanıldığını anlatmak için bir dökümantasyon yapılması gerekir. Uygulama henüz dizayn aşamasındayken son kullanıcıyı bilgilendirebilecek bir dökümantasyon yazmak genelde pek mümkün olmaz. Program ancak geliştirilmeye başlanıldığında uygulamanın mimarisinde nasıl bir yol izleneceği belli olur. Yapılan güvenlik seçeneklerinin kullanıcıya aktarılması amaçlı bir dökümantasyon hazırlanarak kullanıcılara uygulama ulaştığında, güvenlik seçeneklerinin programın kullanılabilirliğini ne gibi durumlarda etkileyebileceğini anlatıp yapılan her hareketin nelere mal olabileceğini son kullanıcıya belirtir.
Dökümantasyonun yanı sıra uygulama kodunun içerisindeki kod yapısının da önemi yüksektir. Mesela, Kodun içerisinde kullanılan global pointerlar gibi değerleri kullanırken herzaman encoding algoritmaları kullanmak uygulamanın güvenliğini arttıracaktır. Son olarak, yapım aşamasında belirginleşebilecek bazı durumlar dizayn bölümüne ilave edilir ve tekrar analiz yapılarak uygulamaya eklenir.
Doğrulama
Uygalama gelişmeye ve bir şeyler oluşmaya başladığında uygulamanın güvenlik düzeyinin tasarlandığı gibi olup olmadığını kontrol etmek gereklidir. Bu iş için biraz maliyetli olan “fuzz” yada “fuzzing” test etme yöntemi kullanılarak daha kısa sürede yararlı sonuçlar alınması mümkündür. Her ne kadar fuzz yöntemi yararlı olsa da mutlaka kodun üzerinden “White-Box security code review” (kodun her satırına tek tek bakmak) yöntemi ile Kodun üzerinden geçerek olası açıkların bulunması sağlanır. Kodun uygulamada kullanıldıkları yere göre değerleri ölçülür ve ona göre daha değerli bölümlerdeki kodların incelenmesi daha düşük değere sahip olana göre daha dikkatli yapılır.
Belirli zaman aralıklarında projede çalışan bütün yazılımcılar security push denen daha önceden planlanmış bir “uygalamadaki açıkları bulma” eforuna girer. Bu Security Push sayesinde programdaki açıklar daha kolay bulunur ve düzeltilmesi için analiz edilir. Eğer projedeki saldırı modelleri sürekli güncelleniyor ise bu security push’ların aldığı zaman azalır ve daha temiz bir proje olur.
Yayınlama (Release)
Uygulamanın geliştirilmesi bittiğinde ve son kullanıcıya dağıtılmaya başlanmadan hemen önce uygulamanın güvenli olup olmadığının kontrol edilmesi ve herşeyinin güvenli olduğundan emin olunması gerekir. Yeni açıklar bulunursa kodda değişiklikler yapılması gerekebilir. Program kullanılmaya açık hale geldiğinde oluşabilecek güvenlik açıkları için alınması gereken önlemler ve açık oluştuğu zaman yapılacak işlerin ne şekilde yapılacağının planlanması yapılır. Unutulmamalıdır ki ne kadar iyi bir güvenlik planı yapılırsa yapılsın, uygulamada yeni açıklar bulunmasının olasılığı her zaman çok yüksektir.
Bilgi toplama ( Post – Release)
Uygulamanın bitmesi ve son kullanıcının eline geçmesiyle birlikte oluşabilecek olan güvenlik açıklarına her zaman hazırlıklı olunmalıdır. Bu açıklarısürekli yapılacak olan küçük patchler ile ve zamanla oluşacak daha büyük çaplı değişiklikleri ise service pack gibi büyük yenileştirmeler sayesinde giderilebilir.
Microsoft Güvenlik Geliştirme Süreci yazılımcının işini kolaylaştırmanın yanında, hem finansör için hem de son kullanıcı için gelişmeler sağlıyor. Yazılımcı programı debug etmeye daha az zaman harcarken finansör yatırımı projenin daha verimli kısımlarına yapıyor ve son kullanıcı hem güvenli hemde yüksek düzeyde donanıma sahip olan bir uygulama ile işlerini daha rahat halledebilecek hale geliyor.
 Favori olarak ekle (1) | Görüntüleme sayısı: 1069
Sadece kayıtlı kullanıcılar yorum yazabilir.
Lütfen sisteme giriş yapın veya kayıt olun. |
