Örnek sorular
Security Secure SdlcZorluk 1
Yeni bir sistem için tasarım aşamasında threat model (tehdit modeli) oluşturmanın temel amacı nedir?
- aSistemin yük altında nasıl ölçekleneceğini öngören bir performans benchmark'ı üretmek
- bGüvenlik açısından nelerin ters gidebileceğini ve karşılık gelen kontrolleri belirlemek✓
- cQA ekibinin sürüm öncesi çalıştıracağı nihai test senaryosu listesini üretmek
- dFrontend ve backend ekiplerinin belirsizlik olmadan entegre olabilmesi için API sözleşmesini belgelemek
Açıklama:Threat modeling yapılandırılmış bir egzersizdir: varlıkları, bir saldırganın bunları nasıl tehlikeye atabileceğini ve her belirlenmiş tehdidi azaltan kontrolleri sırala. Bu bir güvenlik tasarım faaliyetidir, performans, QA ya da API-sözleşmesi egzersizi değildir; çıktısı genellikle üçüne de girdi olur.
Security Secure SdlcZorluk 2
STRIDE-tarzı bir tehdit sınıflandırmasında, bir saldırganın sistemi, aslında öyle olmayan bir isteğin meşru bir kullanıcıdan geldiğine ikna etmesi hangi kategoriye en iyi girer?
- aDenial of service, çünkü istek sistem kaynaklarını tüketir
- bInformation disclosure, çünkü saldırgan kullanıcı hakkında bir şey öğrenir
- cElevation of privilege, çünkü saldırgan hemen ek izinler kazanır
- dSpoofing — saldırgan kendisine ait olmayan bir kimliği taklit eder✓
Açıklama:Spoofing tam olarak budur: saldırgan kendisine ait olmayan bir kimliği (kullanıcı, servis, cihaz) iddia eder ya da taklit eder, böylece sistem güvenmemesi gereken bir isteğe güvenir. Elevation of privilege ayrı ve sonraki bir sonuçtur; disclosure ve denial of service farklı tehdit biçimlerini tarif eder.
Security Secure SdlcZorluk 2
Bir ekip, ödeme verisini işleyen yeni bir özelliği geliştirmeye başlamak üzere. Bu özellik için threat-modeling oturumunu yapmanın en iyi zamanı nedir?
- aTasarım aşamasında, uygulama başlamadan önce; böylece belirlenen riskler mimariyi şekillendirebilir✓
- bÖzelliği içeren ilk production incident'inden hemen sonra, neyin zaten ters gittiğini anlamak için
- cSürüm etiketlenmeden hemen önce, son QA regresyon turunda
- dYalnızca bir müşteri özellik için açıkça güvenlik denetimi istediğinde
Açıklama:Threat modeling en çok tasarımın ucuz şekilde değiştirilebildiği erken aşamada değer katar. Incident'i, son QA turunu ya da müşteri talebini beklemek mimarinin zaten sabitlendiği anlamına gelir, bu yüzden herhangi bir bulgu tasarım girdisi yerine maliyetli bir sonradan-uyarlama olur.
Security Secure SdlcZorluk 1
Güvenli yazılım geliştirme bağlamında "shift-left" terimi ne anlama gelir?
- aUyum (compliance) nedenleriyle deployment pipeline'ını bir cloud bölgesinden diğerine taşımak
- bGüvenlik uzmanlarının ayrı bir departman yerine mühendislik yöneticisine rapor vermesi için ekibi yeniden organize etmek
- cGüvenlik gereksinimlerini ve kontrollerini yalnızca sonda değil, geliştirme yaşam döngüsünün daha erken aşamalarında ele almak✓
- dYeni özellik eklemeden önce eski (legacy) kodu daha eski bir programlama dilinden daha yeniye yeniden yazmak
Açıklama:Shift-left, geleneksel olarak geç yapılan faaliyetleri (güvenlik incelemesi, test) yaşam döngüsünün erken aşamalarına — gereksinimler, tasarım, kodlama — taşımak demektir; böylece sorunlar ucuzken yakalanır ve düzeltilir. Raporlama hattı, bölge ya da dil geçişiyle ilgisi yoktur.
Security Secure SdlcZorluk 2
Bir yetkilendirme kontrolü eksikliği, özellik henüz merge olmadan, kod incelemesi sırasında bulunup düzeltiliyor. Aynı sorunun release'den üç ay sonra bulunmasıyla karşılaştırıldığında, bu sonuç neden tercih edilir?
- aAslında tercih edilmez, çünkü düzeltme her iki durumda da aynı miktarda kod gerektirir
- bDaha ucuz ve güvenlidir çünkü henüz veri açığa çıkmamıştır ve rollback ya da incident response gerekmez✓
- cYalnızca uyum (compliance) evrakları için önemlidir, sistemin gerçek güvenliği için değil
- dYalnızca inceleyen kişi orijinal yazardan daha kıdemliyse tercih edilir
Açıklama:Hatanın merge'den önce yakalanması, hiçbir zaman production'a ulaşmadığı anlamına gelir: kullanıcı verisi risk altında kalmamıştır, incident response, müşteri bildirimi ya da acil yama gerekmemiştir. Düzeltmenin mühendislik maliyeti benzer olabilir ama canlı bir zafiyetin operasyonel ve güven maliyeti çok daha yüksektir.
Security Secure SdlcZorluk 2
Kodun doğru çalıştığını kontrol etmenin ötesinde, güvenlik odaklı bir kod incelemesinde bir reviewer ek olarak neye bakmalıdır?
- aGirdinin doğrulanıp doğrulanmadığına, erişim kontrollerine ve hassas verinin güvenli işlenip işlenmediğine✓
- bDeğişken adlarının ekibin tercih ettiği isimlendirme kuralına uyup uymadığına
- cPull request açıklamasının tam cümlelerle yazılıp yazılmadığına
- dDeğişen satır sayısının tek ekrana sığacak kadar küçük olup olmadığına
Açıklama:Güvenlik odaklı bir inceleme güvenliğe özgü sorular sorar: güvenilmeyen girdi doğrulanıyor mu, yetkilendirme doğru katmanda uygulanıyor mu, secret'lar ve hassas veri güvenli işlenip loglanıyor mu. İsimlendirme stili, açıklama metni ve diff boyutu faydalı inceleme hijyenidir ama güvenlik endişesi değildir.