50
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

Yazılım Güvenliği

Embed Size (px)

DESCRIPTION

 

Citation preview

Page 1: 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 673Veri ve Ağ Güvenliği

Uğur Tılıkoğlu

131041018

Page 2: Yazılım Güvenliği

GYTE - Bilgisayar Mühendisliği Bölümü BIL 673 Veri ve Ağ Güvenliği2

• 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

Page 3: Yazılım Güvenliği

GYTE - Bilgisayar Mühendisliği Bölümü BIL 673 Veri ve Ağ Güvenliği3

• 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

Yazılım Güvenliği

Page 4: Yazılım Güvenliği

GYTE - Bilgisayar Mühendisliği Bölümü BIL 673 Veri ve Ağ Güvenliği4

• 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ı

Yazılım Güvenliği

Page 5: Yazılım Güvenliği

GYTE - Bilgisayar Mühendisliği Bölümü BIL 673 Veri ve Ağ Güvenliği5

• 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ı

Yazılım Güvenliği

Page 6: Yazılım Güvenliği

GYTE - Bilgisayar Mühendisliği Bölümü BIL 673 Veri ve Ağ Güvenliği6

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

Yazılım Güvenliği

Page 7: Yazılım Güvenliği

GYTE - Bilgisayar Mühendisliği Bölümü BIL 673 Veri ve Ağ Güvenliği7

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

Yazılım Güvenliği

Page 8: Yazılım Güvenliği

GYTE - Bilgisayar Mühendisliği Bölümü BIL 673 Veri ve Ağ Güvenliği8

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

Yazılım Güvenliği

Page 9: Yazılım Güvenliği

GYTE - Bilgisayar Mühendisliği Bölümü BIL 673 Veri ve Ağ Güvenliği9

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

Yazılım Güvenliği

Page 10: Yazılım Güvenliği

GYTE - Bilgisayar Mühendisliği Bölümü BIL 673 Veri ve Ağ Güvenliği10

• Örnek açıklar, saldırılar ve sonuçları

Yazılım Güvenliği

Page 11: Yazılım Güvenliği

GYTE - Bilgisayar Mühendisliği Bölümü BIL 673 Veri ve Ağ Güvenliği11

• Örnek açıklar, saldırılar ve sonuçları

Yazılım Güvenliği

Page 12: Yazılım Güvenliği

GYTE - Bilgisayar Mühendisliği Bölümü BIL 673 Veri ve Ağ Güvenliği12

• Örnek açıklar, saldırılar ve sonuçları– Geciken Yama Saldırıları

Yazılım Güvenliği

Page 13: Yazılım Güvenliği

GYTE - Bilgisayar Mühendisliği Bölümü BIL 673 Veri ve Ağ Güvenliği13

• 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

Page 14: Yazılım Güvenliği

GYTE - Bilgisayar Mühendisliği Bölümü BIL 673 Veri ve Ağ Güvenliği14

• 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

Page 15: Yazılım Güvenliği

GYTE - Bilgisayar Mühendisliği Bölümü BIL 673 Veri ve Ağ Güvenliği15

• Saltzer ve Schroeder Prensipleri (2)– 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.

Yazılım Güvenliği Mimarisi

Page 16: Yazılım Güvenliği

GYTE - Bilgisayar Mühendisliği Bölümü BIL 673 Veri ve Ağ Güvenliği16

• Saltzer ve Schroeder Prensipleri (3)– 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.

Yazılım Güvenliği Mimarisi

Page 17: Yazılım Güvenliği

GYTE - Bilgisayar Mühendisliği Bölümü BIL 673 Veri ve Ağ Güvenliği17

• 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

Yazılım Güvenliği Mimarisi

Page 18: Yazılım Güvenliği

GYTE - Bilgisayar Mühendisliği Bölümü BIL 673 Veri ve Ağ Güvenliği18

• Yoder ve Barkalow Prensipleri (2)– 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

Yazılım Güvenliği Mimarisi

Page 19: Yazılım Güvenliği

GYTE - Bilgisayar Mühendisliği Bölümü BIL 673 Veri ve Ağ Güvenliği19

• Yoder ve Barkalow Prensipleri (3)– 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ı

Yazılım Güvenliği Mimarisi

Page 20: Yazılım Güvenliği

GYTE - Bilgisayar Mühendisliği Bölümü BIL 673 Veri ve Ağ Güvenliği20

• 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

Yazılım Güvenliği Mimarisi

Page 21: Yazılım Güvenliği

GYTE - Bilgisayar Mühendisliği Bölümü BIL 673 Veri ve Ağ Güvenliği21

• SDL (Security Development Lifecycle) (1)

Yazılım Güvenliği Mimarisi

Page 22: Yazılım Güvenliği

GYTE - Bilgisayar Mühendisliği Bölümü BIL 673 Veri ve Ağ Güvenliği22

• SDL (Security Development Lifecycle) (2)– Tüm yazılım geliştirme ekibi aşağıdaki konularda

eğitim görür

Yazılım Güvenliği Mimarisi

Page 23: Yazılım Güvenliği

GYTE - Bilgisayar Mühendisliği Bölümü BIL 673 Veri ve Ağ Güvenliği23

• SDL (Security Development Lifecycle) (3)– 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.

Yazılım Güvenliği Mimarisi

Page 24: Yazılım Güvenliği

GYTE - Bilgisayar Mühendisliği Bölümü BIL 673 Veri ve Ağ Güvenliği24

• SDL (Security Development Lifecycle) (4)– 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.

Yazılım Güvenliği Mimarisi

Page 25: Yazılım Güvenliği

GYTE - Bilgisayar Mühendisliği Bölümü BIL 673 Veri ve Ağ Güvenliği25

• SDL (Security Development Lifecycle) (5)– İ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.

Yazılım Güvenliği Mimarisi

Page 26: Yazılım Güvenliği

GYTE - Bilgisayar Mühendisliği Bölümü BIL 673 Veri ve Ağ Güvenliği26

• SDL (Security Development Lifecycle) (6)– 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.

Yazılım Güvenliği Mimarisi

Page 27: Yazılım Güvenliği

GYTE - Bilgisayar Mühendisliği Bölümü BIL 673 Veri ve Ağ Güvenliği27

• SDL (Security Development Lifecycle) (7)– 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.

Yazılım Güvenliği Mimarisi

Page 28: Yazılım Güvenliği

GYTE - Bilgisayar Mühendisliği Bölümü BIL 673 Veri ve Ağ Güvenliği28

• SDL (Security Development Lifecycle) (8)– Opsiyonel Adımlar

• Manuel kod incelemesi• Penetrasyon testleri• Benzer uygulamaların açık – tehdit modellerinin

karşılaştırılarak incelenmesi

Yazılım Güvenliği Mimarisi

Page 29: Yazılım Güvenliği

GYTE - Bilgisayar Mühendisliği Bölümü BIL 673 Veri ve Ağ Güvenliği29

• SDL (Security Development Lifecycle) (9)

Yazılım Güvenliği Mimarisi

Page 30: Yazılım Güvenliği

GYTE - Bilgisayar Mühendisliği Bölümü BIL 673 Veri ve Ağ Güvenliği30

• 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.

Yazılım Güvenliği Mimarisi

Page 31: Yazılım Güvenliği

GYTE - Bilgisayar Mühendisliği Bölümü BIL 673 Veri ve Ağ Güvenliği31

• CLASP (Comprehensive, Lightweight Application Security Process) (2)

Yazılım Güvenliği Mimarisi

Page 32: Yazılım Güvenliği

GYTE - Bilgisayar Mühendisliği Bölümü BIL 673 Veri ve Ağ Güvenliği32

• CLASP (Comprehensive, Lightweight Application Security Process) (3)– 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.

Yazılım Güvenliği Mimarisi

Page 33: Yazılım Güvenliği

GYTE - Bilgisayar Mühendisliği Bölümü BIL 673 Veri ve Ağ Güvenliği33

• CLASP (Comprehensive, Lightweight Application Security Process) (4)– 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

Yazılım Güvenliği Mimarisi

Page 34: Yazılım Güvenliği

GYTE - Bilgisayar Mühendisliği Bölümü BIL 673 Veri ve Ağ Güvenliği34

• CLASP (Comprehensive, Lightweight Application Security Process) (4)– Rol Tabanlı Bakış (Role-Based View) (2)

• 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.

Yazılım Güvenliği Mimarisi

Page 35: Yazılım Güvenliği

GYTE - Bilgisayar Mühendisliği Bölümü BIL 673 Veri ve Ağ Güvenliği35

• CLASP (Comprehensive, Lightweight Application Security Process) (4)– Rol Tabanlı Bakış (Role-Based View) (3)

• 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.

Yazılım Güvenliği Mimarisi

Page 36: Yazılım Güvenliği

GYTE - Bilgisayar Mühendisliği Bölümü BIL 673 Veri ve Ağ Güvenliği36

• CLASP (Comprehensive, Lightweight Application Security Process) (5)– Aktivite Değerlendirme Bakışı (Activity-Assesment

View)• 24 Madde

Yazılım Güvenliği Mimarisi

Page 37: Yazılım Güvenliği

GYTE - Bilgisayar Mühendisliği Bölümü BIL 673 Veri ve Ağ Güvenliği37

• CLASP (Comprehensive, Lightweight Application Security Process) (6)– 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

Yazılım Güvenliği Mimarisi

Page 38: Yazılım Güvenliği

GYTE - Bilgisayar Mühendisliği Bölümü BIL 673 Veri ve Ağ Güvenliği38

• 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.

Yazılım Güvenliği Mimarisi

Page 39: Yazılım Güvenliği

GYTE - Bilgisayar Mühendisliği Bölümü BIL 673 Veri ve Ağ Güvenliği39

• BSIMM (Building Security in Maturity Model) (2)– 12 ana başlık altında 112 aktivite

bulundurmaktadır.

Yazılım Güvenliği Mimarisi

Page 40: Yazılım Güvenliği

GYTE - Bilgisayar Mühendisliği Bölümü BIL 673 Veri ve Ağ Güvenliği40

• BSIMM (Building Security in Maturity Model) (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.

Yazılım Güvenliği Mimarisi

Page 41: Yazılım Güvenliği

GYTE - Bilgisayar Mühendisliği Bölümü BIL 673 Veri ve Ağ Güvenliği41

• BSIMM (Building Security in Maturity Model) (4)

Yazılım Güvenliği Mimarisi

Page 42: Yazılım Güvenliği

GYTE - Bilgisayar Mühendisliği Bölümü BIL 673 Veri ve Ağ Güvenliği42

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

Tehdit Modelleme

Page 43: Yazılım Güvenliği

GYTE - Bilgisayar Mühendisliği Bölümü BIL 673 Veri ve Ağ Güvenliği43

• 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

Page 44: Yazılım Güvenliği

GYTE - Bilgisayar Mühendisliği Bölümü BIL 673 Veri ve Ağ Güvenliği44

• Saldırı Ağacı (Attack Tree)

Tehdit Modelleme

Page 45: Yazılım Güvenliği

GYTE - Bilgisayar Mühendisliği Bölümü BIL 673 Veri ve Ağ Güvenliği45

• 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

Page 46: Yazılım Güvenliği

GYTE - Bilgisayar Mühendisliği Bölümü BIL 673 Veri ve Ağ Güvenliği46

• 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

Page 47: Yazılım Güvenliği

GYTE - Bilgisayar Mühendisliği Bölümü BIL 673 Veri ve Ağ Güvenliği47

• 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

Page 48: Yazılım Güvenliği

GYTE - Bilgisayar Mühendisliği Bölümü BIL 673 Veri ve Ağ Güvenliği48

• Araçlar– Lint– PREfast– FxCop– AppVerif– Code Coverage Tools

• Test– Netsparker (Türk girişimi)

Güvenli Kodlama

Page 49: Yazılım Güvenliği

GYTE - Bilgisayar Mühendisliği Bölümü BIL 673 Veri ve Ağ Güvenliği49

• 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

Page 50: Yazılım Güvenliği

GYTE - Bilgisayar Mühendisliği Bölümü BIL 673 Veri ve Ağ Güvenliği50

• 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