Güvenli Yazılım Geliştirme

Şirket içi eğitim için hazırlanmıştır

Transcript

1. Güvenli Yazılım Geliştirme Ahmet Pirimoğlu 29 Kasım 2024
2. Ajanda • Kavramlar • Güvenli Yazılım Geliştirme Süreçleri • Sık Karşılaşılan Güvenlik Açıkları • Güvenlik Standartları ve En İyi Uygulamalar • Kod İnceleme ve Güvenlik Testleri • Sonuç ve Öneriler
3. Güvenlik Nedir? Farkındalık + Koruma
4. Güvenli Yazılım Saldırı altında doğru çalışan yazılımdır
5. %100 Güvenlik Yoktur "The only secure computer is one that's unplugged, locked in a safe, and buried 20 feet under the ground in a secret location... and I'm not even too sure about that one" -- Dennis Huges, FBI
6. Ne Kadar Güvenliğe İhtiyacım Var? • Gereksinimleri çıkarma, hedeflerle • İhtiyaç olan kadarını tam olarak yapma • Yeniden gözden geçirme periyotları
7. Güvenli Yazılım Geliştirme Süreçleri
8. Geleneksel Yaklaşım ile Koruma • Firewall’lar ile sistemlerimizi koruruz • “Saldırganları uzak tutalım” • Kriptografi kullanımı yazılımın güvenliğini sağlar • “Tüm verilerimizi şifreli saklıyoruz” • Yazılım ürünlerinin bittiğinde test edilmesi • Saldır ve yamala (penetrate and patch) • Güvenlik özellikleri yazılımlarımızı güvenli kılar • “Biz SSL kullanıyoruz” • Proje hedefleri içerisinde güvenliğin konu edilmemesi • “Güvenlik konusunu bir sonraki sürümde ele alacağız”
9. Modern Yaklaşım • Güvenlik “risk yönetimi”dir • Güvenlik konusunun geliştirme sürecinin entegre bir parçası olması zorunludur
10. SDLC vs Secure-SDLC
11. DevSecOps
12. Tehdit Modelleme •Yazılımınıza yönelik tehditleri bilmeden güvenli bir yazılım üretemezsiniz •Tehdit modellemesi yazılım geliştirmeden önce yapılmalıdır
13. Tehdit Modelleme • Modelleme Süreci • Sistemi Anlamak • Tehditleri Belirlemek • Risk Değerlendirme • Önlemler Geliştirme • Araçlar, • Microsoft Threat Modeling Tool • OWASP Threat Dragon
14. Tehdit Modelleme • Bir e-ticaret sitesinde: • Hassas Veri: Kullanıcıların kredi kartı bilgileri • Tehdit: Veri aktarımı sırasında dinleme (man-in-the-middle saldırısı) • Çözüm: TLS/SSL kullanarak veri aktarımını şifrelemek • Bu yöntem, yazılımın daha güvenli hale gelmesini sağlamak için proaktif bir yaklaşımdır.
15. Sık Karşılaşılan Güvenlik Açıkları
16. SQL Injection
17. SQL Injection
18. Cross-Site Scripting (XSS)
19. Directory Traversal
20. OWASP Top 10 https://owasp.org/www-project-top-ten/
21. Güvenlik Standartları ve En İyi Uygulamalar
22. ISO/IEC 27001 1.Bilgi Güvenliği Politikaları 2.Risk Yönetimi 3.Kontrol Listesi 4.Sürekli İyileştirme
23. Şifreleme (AES-256)
24. Şifreleme (bcrypt)
25. Şifreleme (Karşılaştırma) Özellik AES-256 bcrypt Tür Simetrik Şifreleme Hashing Algoritması Anahtar Şifreleme ve şifre çözme için aynı anahtar gerekir. Tek yönlü (geri dönüş yok) Amaç Veri şifreleme Parola koruma Kullanım Alanı Dosya şifreleme, veri aktarımı Parola hashleme, kimlik doğrulama
26. JSON Web Tokens (JWT)
27. Yazılım Çalışma Ortamı Güvenliği Uygulama Konteyneri (Application Container) Kullanımı
28. Yazılım Çalışma Ortamı Güvenliği Mikroservis Mimarisi ile Yazılımların Geliştirilmesi
29. Kod İnceleme ve Güvenlik Testleri
30. Statik Güvenlik Testleri (SAST)
31. Dinamik Güvenlik Testleri (DAST)
32. SAST vs DAST Özellik SAST (Statik) DAST (Dinamik) Test Edilen Alan Kaynak kod Çalışan uygulama Zamanlama Geliştirme aşamasında Çalışan yazılım üzerinde Yetenek Mantıksal hataları tespit eder Çalışma zamanındaki açıkları tespit eder Avantaj Erken tespit Çalışma ortamına uygun Dezavantaj Çalışma zamanındaki açıkları tespit edemez Geliştirme sırasında tespit yapamaz
33. Araçlar SAST • Sonarqube • Fortify SCA • Checkmarx • Veracode Static Analysis DAST • OWASP ZAP • Burp Suite • Netsparker
34. Penetrasyon Testleri • Metasploit • Nmap • Burp Suite • Wireshark • Aircrack-ng
35. Sonuç ve Öneriler
36. İhtiyaçlar • Güvenlik eğitimi ve farkındalık • Kod tarama ve test araçlarının entegrasyonu • Yazılımın güncel tutulması • Siber tehditlere karşı proaktif yaklaşımlar
37. Beklenmeyenleri beklemek Suçu gerçekleşmeden önlemek Kullanıcı gözüyle bakmak Keskin kenarları düşünmek
38. Kullanıcılara asla güvenme
39. Girdilerin Sınanması: Neden? • Güvenilmez kaynaklardan gelen tüm girdiler işleme tabi tutulmadan önce sınanmalıdır • Uygunsuz girdiler ile bir sürecin işleyişini değiştirmek mümkündür • Neye güvenilebileceği her uygulama ve her kuruluş için farklı olabilir • Kullanıcılardan, ağ üzerinden • Sistem üzerindeki diğer süreçlerden • Library den (.so, .dll vb.) • İşletim sisteminden • Uygulama içerisindeki diğer fonksiyonlardan gelen verilerin sınanması gerekli olabilir
40. Girdilerin Sınanması: Nasıl? • Geçerli olan girdiler tanımlanmalı ve bunun dışındaki veriler kabul edilmemelidir • Tersi yapılmamalıdır: Geçersiz verileri/sembolleri tanımlama ve diğerlerinin tümünü kabul etme • Veriler için maksimum uzunluk/büyüklük tanımlanmalı ve daha büyük girdi kabul edilmemelidir
41. Güvenli Yazılım Tasarımı Önerileri • Güvenlik gereksinimleri uygulama yaşam döngüsündeki her bir aşamada tam olarak tanımlanmalı ve sürekli bir biçimde analiz edilmelidir. • Gözden geçirme sürecinin bu döngüye eklenmesi gerekmektedir.
42. Güvenli Yazılım Tasarımı Önerileri • Uygulama veritabanında kişisel veri içeren birincil anahtar (kimlik no, e-posta adresi vb.) şifrelenerek saklanmalıdır. • Kişisel veriler üzerinde işlem yapılması ana amaç olmayan durumlarda uygulama kişisel verileri maskeleyerek görüntülemeli, aktarmalı veya işlemelidir. • Uygulamanın geliştirme, test ve eğitim ortamlarında kişisel veri olmamalı, anonimleştirilmiş veriler kullanılmalıdır. • Kişisel veri içeren uygulama veritabanı yedekleri şifreli olarak saklanmalıdır. • Uygulama, kişisel veriler için saklama sürelerini takip edebilmeli ve saklama süresi sona eren verilerin silinebilmesini / yok edilebilmesini sağlamalıdır.
43. Güvenli Yazılım Tasarımı Önerileri • Uygulamadaki bileşenler hata durumlarında varsayılan olarak güvenli durumlara geçmelidir • Uygulamaya yapılan tüm erişim istekleri hem istek hem de yanıt zamanında yetkilendirmeye tabi tutulmalıdır. • Geçersiz olmuş, potansiyel olarak tehlikeli işlevlerin bulunduğu kütüphane ve modüller tasarımda ve uygulamada yer almamalıdır.
44. Güvenli Yazılım Tasarımı Önerileri • Kimlik doğrulaması, özellikle herkese açık olan sayfa ve kaynaklar dışındaki tüm sayfa ve kaynaklara erişim için önkoşul olmalıdır. • Tüm parola alanlarında kullanıcı giriş yaparken kullanıcının parolası maskelenmeli ve açık olarak görünmemelidir. • Parola giriş alanları uzun ve karmaşık bir parola girilmesini engellememeli, deyimsel parola kullanımına izin vermeli ya da teşvik etmelidir. Örneğin, parolaların en az 15 karakter uzunluğunda girilebilmesine olanak tanıması, en az bir büyük, bir küçük harf, bir özel karakter ve bir sayı kullanılması, son 5 parolayla aynı parolanın kullanılmaması vb.
45. Güvenli Yazılım Tasarımı Önerileri • Kimlik bilgileri uygun şifreli bir bağlantı kullanılarak iletilmeli ve kimlik bilgilerinin girilmesi için kullanıcıya gereken tüm sayfalar / işlevler şifreli bir bağlantı kullanılarak yapılmalıdır. • Unutulan parola işlevi ve diğer kurtarma yolları geçerli parolayı açığa çıkarmamalı ve yeni parola kullanıcıya düz metin olarak gönderilmemelidir.
46. Güvenli Yazılım Tasarımı Önerileri • Değişen parola işlevselliği eski parolayı, yeni parolayı ve bir parola onayını kapsamalıdır. • Tüm şüpheli kimlik doğrulama kararları için özet veri içerecek şekilde log kaydı oluşturulmalıdır. • Hesaplara ilişkin parolaları korumak için yeterince güçlü kriptografik yöntemler (şifreleme, özet alma) kullanılmalı ve bu kriptografik yöntemlerin kaba kuvvet saldırılarına karşı güçlü olmalıdır.
47. Güvenli Yazılım Tasarımı Önerileri • Kaba kuvvet saldırıları ya da servis dışı bırakma saldırıları gibi otomatik yapılan yaygın kimlik doğrulama saldırılarını önlemek için istekler azaltılmalıdır. (rate limiting, throttling)
48. Güvenli Yazılım Tasarımı Önerileri • Oturum açma, parola sıfırlama ya da hesap unutma gibi işlevler sıralı denemelerle bilgi edinmeye olanak vermemelidir.
49. Güvenli Yazılım Tasarımı Önerileri • Hassas işlevler gerçekleştirilmeden önce, yeniden kimlik doğrulama, daha güçlü bir mekanizmayla kimlik doğrulama, ikinci faktör veya işlem imzalama gibi yöntemler uygulanmalıdır. • Uygulama kullanıcının son başarılı oturum açma tarih ve saatini görüntülemelidir. • Unutulan parola ve diğer kurtarma yolları kısa ileti, e-posta onayı, mobil onay, çevrimdışı onay vb. yöntemleri kullanmalıdır. • Hesaplar geçici veya kalıcı olarak kilitlenebilmelidir. Kalıcı olarak kilitlenen hesaplar eğer üzerindeki geçici kilit kaldırılsa da kilitli kalmalıdır.
50. Güvenli Yazılım Tasarımı Önerileri • Kaynak kodunda veya kaynak kodu depolarında gizli bilgiler, API anahtarları ve parolalar mevcut olmamalıdır. • Yazılım altyapısında ya da herhangi bir bileşen için kullanılan teknolojide üzerinde varsayılan parolalar yer almamalıdır
51. Güvenli Yazılım Tasarımı Önerileri • Parolalar için bir en uzun geçerlilik süresi tanımlanmış olmalıdır. • Örneğin Seviye 3 güvenlik için 30 gün, Seviye 1 ve 2 güvenlik için 60 gün
52. Güvenli Yazılım Tasarımı Önerileri • URL yeniden yönlendirmelerinin sadece bilinen "beyaz liste" adreslerine yapılması, bilinmeyen adreslere yönlendirme gerekiyorsa kullanıcının uyarılarak onayının alınması sağlanmalıdır. • Karşı alanlar arası kaynak paylaşımında (Cross- domain Resource Sharing, CORS) güvenilmeyen veri kullanılmamalıdır
53. Güvenli Yazılım Tasarımı Önerileri • Uygulama tarafından etkin ve aynı zamanlı oturumların sayısı sınırlandırılabilmelidir. • Oturum sonlandığında oturum ile ilgili tüm geçici depolama alanları ve çerezler uygulama tarafından silinmelidir. • Web uygulamalarında oturum çerezlerinde HTTPOnly bayrağı etkin olmalıdır. Ayırca "Secure" olarak yapılandırılmalıdır.
54. Güvenli Yazılım Tasarımı Önerileri • Log kayıtlarında olayların zaman sıralamasına ilişkin araştırma yapılabilecek şekilde zaman bilgisi yer almalıdır. • Log kayıtlarını okuyan araçlarda istenilmeyen bir işlemi yapacak kayıt üretilmemelidir. • Uygulama tarafından üretilen log kayıtları hassas bilgi içermemelidir.
55. Güvenli Yazılım Tasarımı Önerileri • Uygulama hassas bilgileri formlarda bulunan gizli alanlarda saklamamalıdır. • Uygulama Cross-Site Request Forgery (CSRF)'dan kaynaklanan açıklıklardan korunma mekanizmasına sahip olmalıdır.
56. Güvenli Yazılım Tasarımı Önerileri • Bütün veritabanı sorguları, parametre olarak yapılmalı ve veritabanına erişimde kullanılan dile karşı (SQL, NoSQL vb.) enjeksiyon saldırılarını önleyebilecek denetimler yapılmalıdır.
57. Güvenli Yazılım Tasarımı Önerileri • Uygulama, web servisi ile gönderilen veride betik (script) içermeyecek şekilde tasarlanmalıdır. • Uygulama, web servislerinden şifreli olarak paylaşılan verileri yine şifreli olarak saklayacak şekilde tasarlanmalıdır • Uygulama, kişisel verileri şifreli olarak saklamalı ve bu verilerin taşınmasında korumalı iletişim kanallarını kullanmalıdır
58. Teşekkürler pirimoglu@gmail.com https://www.pirimoglu.com https://twitter.com/ahmetpirimoglu https://www.linkedin.com/in/ahmetpirimoglu
59. Kaynaklar • https://siberakademi.bilgem.tubitak.gov.tr/plu ginfile.php/6115/mod_page/content/26/SGE- KLV-GuvenliYazilimGelistirmeKilavuzu_R1.1.pdf • https://www.slideshare.net/slideshow/gvenli- yazlm-gelitirmepptx/257878175 • https://www.youtube.com/watch?v=uJ7Smpki cPk&t=2s • ChatGPT