Yazılım Güvenliği

Bilgisayar Mühendisliği Bölümü
GYTE - Bilgisayar Mühendisliği Bölümü
Yazılım Güvenliği
BIL 673
Veri ve Ağ Güvenliği
Uğur Tılıkoğlu
131041018

GYTE - Bilgisayar Mühendisliği Bölümü BIL 673 Veri ve Ağ Güvenliği
2
• Yazılım Güvenliği
– Kavramlar, örnekler
• Yazılımda Güvenlik
• Yazılım Güvenliği Mimarisi
– Prensipler
– Yaklaşım Metodları
• Tehdit Modelleme
• Güvenli Kodlama
• Kaynaklar
İçerik

3
• Sistem Bileşenleri
– Sistem yöneticileri
– Sunucular
– Sunucu yazılımları (*)
– Ağ yöneticileri
– Ağ bileşenleri
– İstemciler
– İstemci yazılımları (*)
– Son kullanıcılar

4
• Varlıklar
– Fiziki varlıklar (harddiskler, altın, para, cep
telefonu)
– Dijital varlıklar (kredi kartı numarası, TC kimlik
numarası, mail adresi şifresi)
• Açık
– Bir sistem üzerindeki saldırıya yol açabilecek tüm
zayıflıklar
– Araba anahtarının kolayca kopyalanabilmesi, para
kasası şifresinin başka tuş kombinasyonları ile
kırılabilmesi, SQL injection açıkları

5
• Saldırı
– Varlıklarımıza, açıklardan faydalanarak isteğimiz
dışında yapılmak istenen erişim
– Pasif saldırılar
– Aktif saldırılar
– Korsanlık
– Sosyal mühendislik
– Kimlik bilgilerinin çalınması

6
• Örnek açıklar, saldırılar ve sonuçları
– Free MP3 CD Ripper Buffer Overflow Açığı

7

8

9

10

11

12
– Geciken Yama Saldırıları

13
• Gizlilik (Confidentiality)
• Bütünlük (Integrity)
• Erişilebilirlik (Availability)
• Kimlik Doğrulama (Authentication)
• Yetki Doğrulama (Authorization)
• Faturalandırma (Accounting)
• Anonimlik (Anonimity)
Yazılımda Güvenlik

14
• Saltzer ve Schroeder Prensipleri (1)
– En Düşük Yetki (Least Privilege)
• Tüm programlar ve tüm kullanıcılar, bir işlemi
yapabilmek için gerekli en düşük yetki seviyesine sahip
olmalıdır.
– Varsayılan Yetki Seviyesi (Fail Safe Defaults)
• Tüm yetkilerin verilip daha sonra gereksiz yetkilerin
kısıtlanmasından ziyade, bir yetkinin neden verilmesi
gerektiğinin sorgulanması gerekmektedir.
– Sistem Ekonomisi (Economy of Mechanism)
• Tasarımı mümkün olduğunca basit ve küçük tutmak
gerekmektedir.
Yazılım Güvenliği Mimarisi

15
– Tam Arabuluculuk (Complete Mediation)
• Her bir nesneye her bir erişim mutlaka kontrol
edilmelidir.
– Açık Tasarım (Open Design)
• Bir sistemin tasarımı gizli olmamalıdır. Sistem dizaynı,
birden fazla göz ile şüphe bırakmayacak şekilde kontrol
edilmiş olmalıdır.
– Yetkilerin Paylaştırılması (Separation of Privilege)
• Gerektiği durumlarda bir sisteme erişimin birden fazla
kişiye paylaştırılması daha sağlıklı olacaktır.

16
– En Az Ortak Sistem (Least Common Mechanism)
• Birden fazla kullanıcının kullandığı yapıların sayısının
mümkün olduğunca azaltılması gerekmektedir.
– Psikolojik Kabul Edilebilirlik (Psychological
Acceptability)
• Sistemler üzerindeki kullanıcı arayüzlerinin kolay
kullanılabilir şekilde tasarlanmış olması gerekmektedir.
Eğer kullanıcı bu sistemi benimser ise, sistem üzerine
yapabileceği hata sayısı da azalmış olacaktır.

17
• Yoder ve Barkalow Prensipleri (1)
– Tek Erişim Noktası (Single Access Point)
• Bir sisteme erişim tek noktadan olmalıdır. Örnek:
kullanıcı giriş ekranı, nizamiye kapısı
– Kontrol Noktası (Check Point)
• Sisteme erişimler kontrol edilmelidir. Örnek: kullanıcı
adı – şifre doğrulama, nizamiye kapısında kimlik
kontrolü
– Roller (Roles)
• Sistem kullanıcıları rollere, dolayısı ile farklı yetkilere
göre ayrılmalıdır. Örnek: admin kullanıcısı, normal
kullanıcı, nöbetçi asker, nöbetçi subay

18
– Oturum (Session)
• Her bir kullanıcıya ait bilgiler, çoklu ortamlarda
diğerlerinden ayrılmalıdır. Örnek: alışveriş sepeti, asker
ziyaretinde her ailenin ayrı masada oturması
– Detaylı Hata Bilgilendirme (Full View with Errors)
• Her bir kullanıcı, sistemde neleri yapıp neleri
yapamayacağı konusunda net hata mesajları ile
bilgilendirilmelidir. Örnek: Bu fonksiyonu kullanma
yetkiniz yoktur, nizamiye kapısından daha içeriye
giremezsiniz

19
– Kısıtlı Görüntüleme (Limited View)
• Kullanıcı yetkisi olmayan işlemleri yapamamalıdır.
Bunun için kullanıcıya, yetkisi kısıtlanmış fonksiyonlar
sunulmalıdır. Örnek: Kredi kartı girmediği takdirde satın
al butonunun aktif olmaması, yetkisi olmayan düğmeleri
görememesi
– Güvenli Erişim Katmanı (Secure Access Layer)
• Güvenli sistemlerin diğer sistemlerle konuşabilmesi
gerekiyorsa, güvenli erişim katmanı tasarlanmalıdır.
Örnek: web servisler için authentication mekanizmaları

20
• Yazılım Güvenliği Yaklaşım Metodları
– Prensiplere dayanarak farklı modeller üretilmiştir.
En çok bilinenler
• SDL (Security Development Lifecycle) - Microsoft
• CLASP (Comprehensive, Lightweight Application
Security Process) - OWASP
• BSIMM (Building Security in Maturity Model) – 70’den
fazla büyük teknoloji şirketinin oluşturduğu bir topluluk

21
• SDL (Security Development Lifecycle) (1)

22
– Tüm yazılım geliştirme ekibi aşağıdaki konularda
eğitim görür

23
– Gereksinimler
• Güvenlik gereksinimleri: Proje başlamadan önce bu
gereksinimler belirlenir
• Kalite kapıları / bug çubukları: Minimum kabul edilebilir
güvenlik seviyeleri belirlenir. Bug kritikliği seviyesine
göre de bug çubuk grafikleri oluşturulur
• Risk analizi: Proje başlamadan önce her bir özellik,
modül vb alt yapılar, P1 (Yüksek), P2 (Orta), P3
(Düşük) güvenlik riski taşıdığına dair belirlenir ve
işaretlenir.

24
– Dizayn
• Dizayn gereksinimleri: Güvenlik gereksinimlerine göre
kullanılacak sistemler, yöntemler ve yaklaşımlar
belirlenir.
• Atak yüzeyi azaltma: Saldırganın saldırı yapabileceği
ve tehdit barındırabilecek kısımları minimum seviyede
tutmak gerekmektedir.
• Tehdit modelleme: Uygulamanın hangi parçalarında ne
tür tehditlerin oluşabileceğinin belirlenmesi
gerekmektedir. Yine MS tarafından geliştirilen STRIDE
metodolojisi kullanılır.

25
– İmplementasyon
• Güvenilir araçların kullanımı: Geliştirme esnasında
mutlaka onaylanmış güvenilir yazılım geliştirme araçları
ve kütüphaneleri kullanılmalıdır.
• Güvenilmeyen methodları devre dışı bırak: Kullanılacak
kütüphane ya da API’ler içerisinde güvenlik tehditi
barındırabilecek methodlar bulunabilir. Bunlar devre
dışı bırakılır ve güvenli olanları geliştirilebilir.
• Statik analiz: Manuel kod inceleme öncesinde, belli kod
şablonlarını yakalayabilecek şekilde otomatik kod
analizi yapan araçlar ile güvenlik konuları tespit etmeye
çalışılır.

26
– Doğrulama
• Dinamik program analizi: Statik analizde ortaya
çıkmayan noktalar, uygulama çalıştığında run-time’da
ortaya çıkabilir. Yardımcı araçlar ile memory hataları,
yetki kullanımı ve diğer kritik güvenlik konuları
uygulama çalışırken incelenmelidir.
• Bulanık test: Farklı ve random girdiler ve şablonlar ile
uygulamanın güvenlik açısından davranışları incelenir.
• Tehdit modeli ve saldırı arayüzü incelenmesi: Dizayn
aşamasında belirlenen tehditler ve saldırı arayüzü
azaltma çözümlerinin doğru uygulanıp uygulanmadığı
kontrol edilir.

27
– Yayınlama
• Olay tepki planı: Uygulama yayınlandıktan sonra ortaya
çıkabilecek güvenlik durumlarında ne tür adımlar
uygulanacağı planlanır.
• Son güvenlik incelemesi: Güvenlik mentörü, takım
liderleri ve geliştiriciler bir araya gelerek son inceleme
yapılır.
• Arşivleme: Yayınlanan uygulamanın her bir versiyonu
tekrar incelenebilmesi açısından arşivlenir.

28
– Opsiyonel Adımlar
• Manuel kod incelemesi
• Penetrasyon testleri
• Benzer uygulamaların açık – tehdit modellerinin
karşılaştırılarak incelenmesi

29

30
• CLASP (Comprehensive, Lightweight
Application Security Process) (1)
– Rol tabanlı olarak güvenlik alanındaki best
practiceleri referans alarak, yapısal, tekrarlanabilir
ve ölçülebilir bir yöntem ortaya koyar.

31

32
– Kavram Bakışı (Concepts View)
• Kavramları ve temel bilgilerin tanımlanmasını, güvenlik
konusunda ekibin temel olarak bilgilendirilmesini önerir.
• Platformların, kaynakların, risk değerlendirmelerinin,
örneklerin ve diğer bilgi kaynaklarının tanımlanmasını
ve referans verilmesini belirtir.

33
– Rol Tabanlı Bakış (Role-Based View) (1)
• Süreçleri parçalara değil, rollere ve rollerin
sorumluluklarına göre ayırır.
• Proje yöneticisi: Tüm CLASP sürecini yönetir. Ekip içi
ve dışındaki güvenlik algısını yönetir. Metrikleri takip
eder.
• Gereksinim tanımlayıcı: Talep sahipleri genellikle
güvenlik maddesini bir gereksinim olarak görmezler.
Taleplerin güvenlik kavramları ile ilişkilerini de göz
önünde bulundurarak gereksinimleri yeniden

34
• Mimar: Ağ ve uygulama mimarisini oluşturur, network
aygıtları, VPN gibi diğer kaynakları belirler. Hangi
rollerin hangi kaynaklara erişeceğini tanımlar.
• Tasarım sorumlusu: Uygulama içerisindeki güvenlik
yöntemlerinin araştırmasını ve teknoloji seçimini yapar,
güvenlik ölçüm metriklerini belirler, atak yüzeyini
raporlar. En önemli rol diyebiliriz.
• Uygulayıcı: Teknik geliştirmeyi yapar, karşılaştığı diğer
güvenlik risklerini tasarım sorumlusu ile paylaşır.

35
• Test analisti: Uygulamanın kalite kontrolünden
sorumludur. Bilgi sahibi olmadığı konularda otomatik
araçlardan da faydalanır.
• Güvenlik denetmeni: Güvenlik gereksinimlerinin
belirtildiği şekilde doğru olarak implemente edilip
edilmediğini kontrol eder. Dizaynı inceler.
Gereksinimlerden dolayı ortaya çıkan açıkları araştırır.

36
– Aktivite Değerlendirme Bakışı (Activity-Assesment
View)
• 24 Madde

37
– Aktivite İmplementasyon Bakışı (Activity-
Implementation View)
• Her bir aktivitenin hedef ve amaçları belirlenir
• Her bir hedefe alt hedefler tanımlanabilir
• Her bir hedefi gerçekleştirmek için izlenecek yollar
tanımlanabilir

38
• BSIMM (Building Security in Maturity Model)
(1)
– Dünya üzerindeki önemli teknoloji firmalarının
best practiceleri ile oluşturulmuştur.
– Güvenlik adımlarının nasıl implemente
edileceğinden ziyade, mevcut olgunluğunu ölçme
amacıyla kullanılır.
– Buradaki ölçüm methodları, mevcut yapıların
geliştirilmesi amacıyla da kullanılmaktadır.
– 2008 yılında ilk versiyonu yayınlanmıştır, şu anda
5. versiyonu bulunmaktadır.

39
(2)
– 12 ana başlık altında 112 aktivite
bulundurmaktadır.

40
(3)
– Bu maddeleri oluşturan firmalar, kendilerini de bu
olgunluk seviyesine göre değerlendirmişler ve
skor kartı oluşturmuşlardır.
– Bu firmaların %64’ünün tamamının uyguladığı
temel 12 aktivite, güvenlik konusunda iyileşme
kaydetmek isteyen organizasyonlar için iyi bir
referans noktasıdır.

41
(4)

42
• Modelleme yöntemleri
– STRIDE
– Saldırı Ağacı (Attack Tree)
– DREAD
– Saldırı Yüzeyi (Attack Surface)
Tehdit Modelleme

43
• STRIDE
– Microsoft tarafından önerilmiştir.
– Spoofing identity: sahte kimlik
– Tampering with data: sahte bilgi
– Repudiation: inkar
– Information disclosure: açığa çıkarma
– DoS: servis durdurma
– Elevation of privilage: yetkileri ele geçirme
Tehdit Modelleme

44
• Saldırı Ağacı (Attack Tree)
Tehdit Modelleme

45
• DREAD
– Tehditlerin sisteme toplam etkisini ölçer
– Her bir başlık için aşağıdaki ölçekte not verilir
• 0: gerçekleşmesi ileri düzeyde bilgi gerektiren /
herhangi bir etkisi olmayan
• 5: gerçekleşmesi için birden fazla adımın
gerçekleşmesi gereken / bölgesel etkileri olan
• 10: çok kolay şekilde gerçekleşebilen / etkileri tüm
sistemi kaplayacak
Tehdit Modelleme

46
• Saldırı Yüzeyi (Attack Surface)
– Aşağıdaki 5 sorunun sorulması gerekir
• Bu özellik gerçekten gerekli mi?
• Bu özelliğe erişim için uzak bağlantı gerçekten gerekli
mi?
• Bu özelliğe erişmesi gereken kullanıcılar / roller
kimlerdir?
• Bu hizmeti sağlamak için ne tür izinler verilmesi
gerekmektedir?
• Bu özelliğin diğer servislerle, sistemlerle, arayüzlerle
bağlantı noktaları nelerdir?
Tehdit Modelleme

47
• Temel Prensipler
– Saltzer ve Schroeder Prensipleri
– Yoder ve Barkalow Prensipleri
• Kaynaklar
– The CERT C Secure Coding Standard
– The CERT C++ Secure Coding Standard
– The CERT Oracle Secure Coding Standard for Java
– Java Coding Guidelines, 75 Reccommendations for
Reliable and Secure Programs
– The CERT Perl Secure Coding Standard
Güvenli Kodlama

48
• Araçlar
– Lint
– PREfast
– FxCop
– AppVerif
– Code Coverage Tools
• Test
– Netsparker (Türk girişimi)
Güvenli Kodlama

49
• Talukder, Chaitania, «Architecting Secure Software Systems», CRC Press, 2009
• Saltzer, Schroeder, «The Protection of Information in Computer Systems», Fourth ACM
Symposium on Operating System Principles, 1973
• Yoder, Barcalow, «Architectural Patterns for Enabling Application Security», PLoP, 1997
• MrTuxracer, «Buffer Overflow Exploitation: A Real World Example»,
http://www.rcesecurity.com/2011/11/buffer-overflow-a-real-world-example/, 2011
• Aleph One, «Smashing The Stack For Fun And Profit»,
http://insecure.org/stf/smashstack.html
• Blexim, «Basic Integer Overflows», http://phrack.org/issues/60/10.html
• CERT, «CERT Coding Standarts»,
https://www.securecoding.cert.org/confluence/display/seccode/CERT+Coding+Standards
• Marco Morana, «Managing Software Security Risks Using Application Threat Modeling», IMI
Security Symposium and Expo, 2008
• OWASP, «Secure Coding Practices Quick Reference Guide», 2010
• Ozan Çağlayan, Galatasaray Üniversitesi, «Yazılım Güvenliği ve Açıkları»,
http://ozancaglayan.com/files/Presentations/Yazilim-Guvenligi-Guvenlik-Aciklari.pdf
• Peterson, «Security Design Patterns», Black Hat Breifings
• Elisa Bertino, Purdue University, «Design Principles for Security Lecture Notes»,
• ARCTEC Group, «Secure By Design: Security in the Software Development Lifecycle»,
http://www.arctecgroup.net/pres/tcrugpres.pdf
Kaynaklar

50
• Hernan, Lambert, Ostwald, Shostack, «Uncover Security Design Flaws Using The STRIDE
Approach», MSDN Magazine, 2006
• McGraw, Migues, West, «Building Security in Maturity Model», 2013
• David Brumley, Carnegie Mellon University, «Software Security Lecture Notes», 2009
• Microsoft, «Simplified Implementation of the Microsoft SDL», 2010
• Nick Coblentz, «CLASP Overview Presentation», 2008
Kaynaklar

Yazılım Güvenliği

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Yazılım Güvenliği

Similar to Yazılım Güvenliği (20)

Yazılım Güvenliği