Hazırlık

Bu bölümde, belirlediğiniz boşlukları nasıl dolduracağınıza dair pratik tavsiyeler de dahil olmak üzere kuruluşunuzu başarılı bir güvenlik açığı ortaya çıkarma programı başlatmaya ve yürütmeye nasıl hazırlayacağınızı ayrıntılı olarak ele alacağız.

Hataları bulma

Mevcut güvenlik programınızı dışarıdan güvenlik araştırmacılarıyla güçlendirmek, karmaşık sorunları bulmanın ve güvenlik açıklarını gizlemenin harika bir yoludur. Ancak, dahili olarak keşfedilebilecek temel güvenlik sorunlarını bulmak için bir VDP kullanmak, kaynak israfına neden olur.

Öğe yönetimi

Hataları bulmak söz konusu olduğunda nereden başlayacağınızı bilmenin tek yolu, neler olduğuna dair iyi bir fikriniz olmaktır. Yüzlerce güvenlik aracı satın alabilirsiniz ancak ekipler uygulama, sistem ve hizmetleri sizin bilginiz olmadan anlık olarak hayata geçirirse (özellikle de bu öğeleri keşfedip güvenlik değerlendirmesi yapamıyorsanız) hiçbir fark yaratmaz. Yeni uygulamaların, sistemlerin ve hizmetlerin ortaya çıkarılmasına yardımcı olmaktan sorumlu olan kişilere ve ekiplere danışarak nelerin ortaya çıktığını ve bunların kime ait olduğunu gösteren bir envanter oluşturmak ve sürdürmek için bir sürecin olup olmadığını öğrenin. Mevcut bir süreç yoksa bu, bir süreç oluşturmak amacıyla bu ekiplerle iş birliği yapmak için harika bir fırsattır. Kuruluşunuzun varlıkları hakkında bilgi sahibi olmak, saldırı yüzeyinizi belirlemeye başlamak için en iyi adımdır. Bu süreç kapsamında güvenlik ekibi, güvenlik incelemeleri sağlamak için yeni altyapı uygulamasının geliştirilmesine dahil olmalıdır. Kapsamlı bir öğe ve sahip envanterine sahip olmak iyi bir uygulamadır. Bu tür envanter, belirli sistemlerin geçici olarak kapatılmasını gerektiren yeni yamalar uygularken kullanışlıdır. Bilgilendirilmesi gereken ve hangi sistemlerin etkilendiğini gösteren yol haritası sağlar. Güçlü bir öğe yönetimi sürecinin uygulanması, sahiplerin sürecin daha başlarında tanımlanmasını, düzenli olarak güncellenmesini ve kuruluştaki tüm sistemlerin istenen şekilde çalışmasını sağlar.

Proaktif varlık yönetimine ek olarak, kuruluşunuza ait olan ancak standartlaştırılmış varlık yönetimi süreçlerinizdeki boşluklardan aşılmış varlıkları belirlemek için hangi reaktif önlemleri de uygulayabileceğinizi düşünün. Bu, VDP'lere ve hata ödül programlarına katılan güvenlik araştırmacılarının kullandığı aynı "keşif" süreçlerinin kullanılmasını içerebilir. Örneğin, kuruluşunuza ait olabilecek internete yönelik IP aralıklarını veya alanları tarayıp numaralayan ücretsiz ve açık kaynaklı araçlardan yararlanabilirsiniz. Google'da yapılan hata ödülü keşfi araması, kuruluşunuzdan farkında olmadığınız öğeleri belirlemenize yardımcı olacak çeşitli ipuçları ve püf noktaları üretir.

Temel güvenlik açığı taraması

Artık güvenlik sorunlarını nerede bulmanız gerektiği konusunda sağlam bir temeliniz olduğuna göre bunları nasıl bulduğunuza geçebiliriz. Kuruluşunuzun kaynaklarına bağlı olarak girebileceğiniz çeşitli derinlik düzeyleri vardır, ancak güvenlik açığını ortaya çıkarma programınız aracılığıyla dahili güvenlik çabalarınız ile harici bilgisayar korsanlığı topluluğu arasında bir denge kurmanız gerekir. Bu denge mevcut kaynaklara bağlı olarak her kuruluş için farklıdır.

Araçlarınızı seçin

Güvenlik açıklarını belirlemeye yardımcı olacak birçok farklı araç vardır. Bazı güvenlik açığı taraması araçları ücretsiz olarak sunulurken bazıları ücretlidir. Hangi araçları seçeceğinize karar vermek, bireysel ihtiyaçlarınıza bağlıdır.

• Kuruluşunuzun gereksinimleri
• Her bir aracın bu gereksinimleri ne ölçüde karşıladığı
• Aracın sunduğu faydalar maliyetlerden (finansal işlemler ve uygulama) fazlaysa.

Çeşitli araçları gereksinimlerinize göre değerlendirmek için bu gereksinim şablonunu (OpenDocument .ods, Microsoft Excel .xlsx) kullanabilirsiniz. Şablonda bazı örnek gereksinimler yer alır ancak gerekli özellikler konusunda fikir edinmek için güvenlik, BT ve mühendislik ekiplerinizle görüşmeniz gerekir. Bir güvenlik açığını ifşa etme programı başlatmadan önce, en azından, dışarıya dönük varlıklara (web siteleri, API'ler, mobil uygulamalar gibi) karşı güvenlik açığı taraması yapabilmelisiniz. Böylece, dışarıdan güvenlik araştırmacılarını bu varlıklar ve hizmetler üzerinde test etmeye davet etmeden önce kolayca bulunabilecek güvenlik açıklarını bulup düzeltebilirsiniz.

Tarama kurulumu

Otomatik güvenlik açığı taramaları birçok sorunla karşılaşmanın yanı sıra yanlış pozitif sonuçlar da verebilir. Bu nedenle, sonuçları etkilenen ekiplerle paylaşmadan önce doğrulamak için kaynaklara sahip olmak gerekir. Taramaların düzenli olarak yapıldığından ve bu taramaların sonuçlarının gerçekten ele alındığından emin olmak için süreçler uygulamanız gerekir. Bu, her kuruluş için farklı görünür, ancak en azından aşağıdakileri belirlemeniz gerekir:

• Tarama sıklığı
  • Sürekli
  • Haftalık
  • Aylık
• Hangi öğeler taranıyor?
• Kimlik bilgisi
  • Kimlik doğrulaması yapılmış ve doğrulanmamış taramalar
  • (İpucu: Kimlik bilgileriyle taramazsanız bir güvenlik araştırmacısı, VDP'nizi başlattığınızda kimlik bilgileriyle test yaparsa tanımlanan güvenlik açıklarında büyük bir artış görebilirsiniz)
• Roller ve sorumluluklar
  • Taramaları yapmaktan sorumlu ekip üyelerini belirlemek
  • Gerekirse rotasyon ayarlama
• Tarama sonuçları
  • Tarama sonuçlarını doğrulama
  • Doğrulanmış güvenlik açıkları için hataları bildirme
  • Hataları düzeltmek için sahipleri belirleme
  • Çözüm konusunda site sahipleriyle iletişime geçme

Bu kılavuzun ilerleyen kısımlarındaki Hataları Düzeltme bölümünde, tespit edilen güvenlik sorunlarının nasıl düzeltileceğini daha ayrıntılı bir şekilde açıklayacağız.

Güvenlik incelemesi süreci

Güvenlik açığı taraması kuruluşunuzdaki güvenlik sorunlarını proaktif olarak tespit etmenin harika bir yolu olsa da güvenlik incelemesi süreçlerini uygulamak, güvenlik açıklarının daha en başında ortaya çıkmasını önlemeye yardımcı olabilir. Bu kılavuzun amacı doğrultusunda, güvenlik incelemesi terimi güvenlik ekibinizin bir üyesi tarafından manuel incelemeyi tetikleyen her durumu ifade eder. Genellikle bu, çok riskli görülmesi durumunda bir değişikliği engelleme yetkisinin verilmesini de içerir. Güvenlik ekibinizin riskli değişiklikleri engelleme imkanı olmasa bile riski belgeleyecek süreçler yürütmeniz gerekir. Böylece değişim için ısrar eden kişinin dahil edilen riski bilmesini ve bu riski proaktif bir şekilde kabul etmesini sağlayabilirsiniz.

Güvenlik incelemesi ölçütleri

Güvenlik incelemeleri ne zaman yapılmalıdır? Güvenlik incelemesini tetikleyen bir ölçüt grubu oluşturmak, herkesin aynı noktada olmasını sağlar. Aşağıda, güvenlik incelemesini tetikleyebilecek senaryolarla ilgili bazı örnekler verilmiştir.

• Hassas kullanıcı verileriyle ilgili yeni bir işlev önerildi
  • Kullanıcıların harita üzerinde konumlarını paylaşmalarına olanak tanıyan yeni bir özellik
  • Kullanıcılardan ev adresi, doğum tarihi veya telefon numarası gibi hassas olabilecek bilgileri isteme
• Mevcut işlevlerde önemli güncellemeler yapıldı
  • Mevcut kullanıcı verilerini alma ve kullanıcılara devre dışı bırakma fırsatı vermeden, bunları kullanıcıların beklemeyebileceği yeni bir şekilde kullanma
  • Kimlik doğrulama, yetkilendirme ve oturum yönetimi ile ilgili özelliklerde yapılan değişiklikler
• Şirketin üretim ortamındaki değişiklikler
  • Ağ yapılandırması değişiklikleri, özellikle de hizmetlerin dışarıya kapatılmasına neden olabilecek değişiklikler
  • Hassas kullanıcı verilerini işleyen yeni yazılımların yüklenmesi. Bu yazılımın güvenliği ihlal edildiğinde, hassas kullanıcı verilerine erişmek için dolaylı olarak kullanılabilir
  • Yeni sistemleri veya hizmetleri tanıtma
• Yeni bir tedarikçiyle etkileşimde bulunma veya mevcut bir tedarikçiyle çalışma şeklinizi değiştirme
  • Hassas kullanıcı verilerini işleyecek yeni bir tedarikçiyle çalışmaya başlama
  • Mevcut bir tedarikçiyle çalışma şeklinizde yapılan ve tedarikçinin hassas kullanıcı verilerini işlemesine yol açan değişiklikler

Bu, kapsamlı bir liste değildir ancak hangi tür değişikliklerin güvenlik incelemesi gerektirmesi gerektiğini düşünmenizi sağlayacaktır. Nelerin güvenlik incelemesi gerektirip gerektirmediğiyle ilgili kriterleri tanımlarken, bunu kuruluşunuzdaki kilit paydaşlara sorarak şunlardan emin olun:

• Paydaşlar projenin kriterlerini inceleme ve geri bildirim verme
• Paydaşlar kriterleri kabul eder
• Paydaşlar proaktif olarak güvenlik incelemeleri talep etmeyi kabul ederler

Kuruluşunuzun bu süreci takip etmesini mümkün olduğunca kolaylaştırmak için bu kriterleri ve güvenlik incelemesi isteğinde nasıl bulunacağınızı (örneğin, güvenlik ekibinin izlediği bir sıraya hata bildiriminde bulunmak) belgeleyin.

Güvenlik incelemesi kaynağı

Otomatik taramaların aksine güvenlik incelemeleri daha fazla kaynak gerektirebilir. Her güvenlik ekibinin gün içinde sayısız görevi yerine getirmek için çok fazla zamanı olur, bu nedenle kriterlerinize göre kaç güvenlik incelemesi oluşturulabileceğini tahmin etmeniz gerekir. Ekibinizin bunaldığını ve geride kaldığını fark ederseniz özelliklerin kullanıma sunulmasını bekleyenler güvenlik ekibini rahatsız eder. Bu durum, kurumdaki kültürel bir değişime yol açarak güvenlik ekibinin bir iş ortağından çok bir engel olarak görülmesine yol açabilir. Güvenlik inceleme süreci verimli değilse birçok kişi ve ekip bunu tamamen atlamaya çalışır. Kaynaklar kısıtlıysa güvenlik incelemesi isteme kriterlerinizi hafifletmeyi düşünün ve daha fazla kalan riski kabul etmeye istekli olun. Güvenlik incelemelerini gerçekleştirmek için gereken kaynakların yetersiz olması nedeniyle olaylar meydana gelirse bu, daha fazla güvenlik kaynağına olan ihtiyacın bir gerekçesi olur.

Güvenlik incelemeleri gerçekleştirme

Hangi güvenlik incelemelerinin gerçekleştirileceğine ve bunların nasıl gerçekleştirileceğine karar verirken, verileri çekmek için öncelikli bir sıraya ihtiyacınız vardır. Kuruluşunuzdaki diğer kişilerin güvenlik incelemesi istemesi için standart bir yöntem oluşturun. Bu yöntem sayesinde, güvenlik değerlendirmesine uygun şekilde önceliklendirmek için ihtiyacınız olan bilgileri sağlayın. Örneğin, değişikliğin kısa bir özetini ve etkilenebilecek kullanıcı verisi türlerini içeren, değişikliğin yapısı gibi öğeler içeren bir anket düşünün. Potansiyel güvenlik incelemelerini, bu soruların yanıtlarına göre otomatik olarak yüksek, orta veya düşük riskli değişiklikler şeklinde kategorilere ayırabilirsiniz. Bir değişiklik yüksek riskliyse daha kapsamlı bir güvenlik incelemesi sürecine ihtiyaç duyabilirsiniz. Bir değişikliğin riski daha düşükse gereken kaynakları azaltıp süreci hızlandırarak işletmeyi daha iyi etkinleştirmek için daha basit bir güvenlik incelemesi süreci uygulayabilirsiniz. Güvenlik incelemesi sırasını yönetmek, yeni güvenlik incelemelerinin ekip üyeleri tarafından alınmasını sağlamak ve mevcut güvenlik incelemelerinin ilerleme durumunu takip etmekten sorumlu olacak ekip için bir rotasyon oluşturabilirsiniz. Güvenlik incelemesinin gerçek süreci, incelenen öğeye bağlı olarak değişiklik gösterir. Örneğin, mobil uygulamanızdaki yeni bir özellik, bir güvenlik mühendisinin kodu inceleyip potansiyel güvenlik açıklarını aramasını gerektirebilir. Erişim denetiminin uygun şekilde ayarlandığından emin olmak için yüklenen yeni yazılımların incelenmesi gerekebilir. Dış tedarikçilerle çalışmak tamamen farklı bir süreç olabilir. Referans için Google'ın Tedarikçi Firma Güvenlik Değerlendirmesi Anketi'ni okuyun.

Hataları düzeltme

Hataları bulmak önemlidir, ancak güvenlik yalnızca bu hatalar düzeltildikten sonra iyileşir. Kuruluşunuzda hangi risklerin var olduğunu bilmek iyidir ancak bu riskleri verimli bir şekilde ele alabilmek daha iyidir.

Güvenlik açığı yönetimi

Güvenlik açıkları; dahili çalışmalar (örneğin, güvenlik açığı taramaları ve güvenlik incelemeleri), üçüncü taraf sızma testleri ve denetimleri, hatta VDP'niz resmi olarak kullanıma sunulmadan önce destek kanalları üzerinden sizi bilgilendiren harici güvenlik araştırmacıları gibi çeşitli kaynaklardan gelir. Kuruluşunuzun yeni ve mevcut güvenlik açıklarının doğru paydaşlara iletildiğinden, doğru şekilde önceliklendirildiğinden ve zamanında düzeltildiğinden emin olmak için bunları kategorilere ayırması gerekir. VDP'nizi başlattığınızda, güvenlik açığı yönetimi süreçlerinize yeni bir güvenlik açığı akışı görürsünüz. Bu güvenlik açıklarını ele almak için sağlam süreçler uyguluyor olmak, düzeltmedeki ilerlemenizi izlemenize ve harici güvenlik araştırmacılarından gelen güncellemelerle ilgili isteklerine yanıt vermenize yardımcı olur. Bir güvenlik açığının önceliğini hızlıca belirleyebilmek ve onarım zaman çizelgesi hakkında VDP katılımcılarıyla iletişim kurabilmek, güvenlik araştırmacıları topluluğuyla etkileşimi artıracak ve kuruluşunuzun güvenliğinin itibarını artıracaktır. Aşağıdaki bölümlerde, VDP'nizi başlatmadan önce güvenlik açığı yönetim programınızın uygulamak isteyebileceğiniz çeşitli yönleri özetlenmektedir.

Önem derecesi standartları ve çözüm zaman çizelgeleri oluşturma

Güvenlik açıklarının önem derecesi ve her önem derecesiyle ilişkili ideal çözüm zaman çizelgeleriyle ilgili ortak bir dil oluşturmak, kuruluşunuzda standart beklentiler oluşturmayı kolaylaştırır. Her güvenlik açığına acil bir durum gibi davranılırsa kuruluşunuz kaynaklarını tüketir ve güvenlik ekibine karşı kırgınca olur. Her güvenlik açığının düşük öncelikli olduğu kabul edilirse güvenlik açıkları hiçbir zaman düzeltilmez ve güvenlik ihlali riski artar. Her kuruluşun kaynakları sınırlı olduğundan bir önem derecesi sıralaması belirlemeniz gerekir. Bu sıralama, kuruluşunuzun bir güvenlik açığının hangi önem derecesinde olduğunu anlamasına yardımcı olacak ölçütler ve her bir önem derecesiyle ilişkili beklenen çözüm zaman çizelgeleri sağlar. Bir dizi önem derecesi yönergesi hazırlayın ve geri bildirim almak için bunu kuruluşunuzdaki kilit paydaşlarla paylaşın. Örneğin, önem derecesi standartlarınızı belirleme işine mühendislik dahil oluyorsa belirli bir zaman dilimi içinde bir güvenlik açığını düzeltme zamanı geldiğinde bu standartları kabul etme ve bunlara uymaları daha olasıdır. Bu önem derecesi kuralları, işletmenize özel risklere bağlı olarak değişiklik gösterebilir. Hangi tehditlerin kuruluşunuz açısından en olası ve etkili olduğunu düşünmek için bir tehdit modelleme alıştırması yapabilir ve her bir önem derecesi kategorisine girebilecek sorunlardan örnekler ekleyebilirsiniz. Aşağıda, finansal kuruluşlar için önem düzeyi standartları ve çözüm zaman çizelgelerine dair bir örnek verilmiştir.

Önem derecesi	Açıklama	Düzeltme Zaman Çizelgesi	Örnekler
Kritik	Kullanıcılarımız veya işletmemiz için her an ortaya çıkabilecek bir tehdit oluşturan sorunlar.	Sahip: Güvenlik açığının düzeltilmesini sağlamak için 8 saat içinde bir birincil sahip tanımlanmalıdır. Gerektiğinde, normal çalışma saatleri dışında bile kaynakları aranıp çağırın. Çözüm: Mümkün olan en kısa sürede veya en fazla üç iş günü içinde sorunun kendisi düzeltilmeli ya da en azından risk azaltılmalıdır.	Tüm kullanıcıların finansal kayıtlarını da içeren bir üretim veritabanında güvenlik ihlali. Google'a ait yatırım algoritmalarımız gibi ticari sırlara erişen bir saldırgan. Dahili ağımıza veya hassas üretim sistemlerimize erişim sağlayan bir saldırganı içeren aktif bir olay.
Yüksek	Kötüye kullanılması halinde ciddi zarara neden olabilecek sorunlar.	Sahip: Bir iş günü içinde bir birincil sahip tanımlanmalıdır. Düzeltme: 10 iş günü (yaklaşık 2 hafta) içinde.	Hassas kullanıcı verilerine veya işlevlere erişim sağlanmasına yol açabilecek güvenlik açıkları (ör. herhangi bir kullanıcının başka bir kullanıcının parasını çalabilmesi).
Aracı	Kötüye kullanılması daha zor olan veya doğrudan zarara yol açmayan sorunlar.	Sahip: Beş iş günü içinde bir birincil sahip tanımlanmalıdır. Düzeltme: 20-40 iş günü (yaklaşık 1-2 ay) içinde.	Bilinen istismarlar olmadan, güvenlik güncellemeleri için yapılan yamalar gibi otomatik tarayıcılar tarafından tanımlanan doğrulanmış sorunlar. Daha fazla saldırı gerçekleştirilmesine yardımcı olabilecek bilgilerin ifşa edilmesiyle ilgili sorunlar. İstismar edilebilecek hızı sınırlayan sorunlar (ör. bir kullanıcının şifrelerini sürekli tahmin edebilme).
Düşük	Minimum etkiye sahip sorunlar; öncelikli olarak bilinen sorunları günlüğe kaydetmek için kullanılır.	Bir sahip bulma veya belirli bir zaman çizelgesinde düzeltme gerekliliği yoktur.	Olası bir riske yol açmayan ancak bilgilerin dışarıdan erişilebilir olmasının gerekli olmadığı durumlarda bilgi paylaşımı.

Hatalarla ilgilenme

Burada saç kesimlerinden bahsetmiyoruz, hataların kolayca düzeltilebilmesi için doğru biçimlendirildiğinden bahsediyoruz. Önceki tabloyu kılavuz olarak kullanarak kendi önem düzeyi tanımlarınızı belirleyin. Bu tanımlar, hataları çeşitli önem derecelerine göre sınıflandırmak ve sahiplerine bildirmek için kullanılır.

Her güvenlik açığına önem derecesi atamanın yanı sıra hatalarınızın, alıcı ekiplerin işlenmesini kolaylaştıran standart bir biçimde olduklarından emin olmanız gerekir. Güvenlik açıkları, güvenlik açığı yönetimi süreçlerinize çeşitli biçimlerde (otomatik tarayıcı sonuçları veya güvenlik incelemelerinden manuel yazmalar gibi) girer. Her bir güvenlik açığını standart bir biçime dönüştürmek için zaman ayırmak, sorunu alan ekibin sorunu hızla anlayabilmesi ve ele alabilme şansını artırır.

Bu biçim veya şablon, kuruluşunuza ve sahiplerin kendilerine atanan hataları düzeltmeye yardımcı olması için en uygun bilgilerin hangileri olduğuna bağlı olarak değişiklik gösterebilir. Kullanabileceğiniz örnek bir şablonu aşağıda bulabilirsiniz. Daha sonra araştırmacılar için güvenlik açığı açıklama programı gönderim formunuzu oluştururken bu şablonu yeniden kullanabilirsiniz.

Başlık: <Sorunun bir satırı ile açıklaması, genellikle güvenlik açığının türü ve hangi varlığın/hizmetin/vb. durumdan etkilendiğini belirtir; isteğe bağlı olarak sorunun önem derecesini ekleyin veya sorun

Aşağıda, olası bir yüksek önem düzeyli güvenlik açığı örneği verilmiştir:

Başlık: [YÜKSEK] Profil sayfalarında Güvenli Olmayan Doğrudan Nesne Referansı (IDOR) Özet: Uygulamamızın profil sayfaları işlevinde, herhangi bir kullanıcının diğer kullanıcının tam adı, ev adresi, telefon numarası ve doğum tarihi dahil olmak üzere başka bir kullanıcının profilini yetkisiz olarak görüntülemesine ve düzenlemesine olanak tanıyan bir IDOR keşfedildi. Günlükleri inceledik ve bu sorunun henüz kötüye kullanılmadığı anlaşılıyor. Bu sorun dahili olarak tespit edildi. Yeniden oluşturma adımları:

1. Bir proxy (örneğin, Burp Suite) oluşturarak mobil uygulamanın yüklü olduğu bir mobil cihazda trafiğe müdahale edebilirsiniz.
2. Profil sayfanızı ziyaret edin ve ilişkili HTTP isteğine müdahale edin.
3. profileID=###### değerini profileID=000000 (bu bir test kullanıcısıdır) olacak şekilde değiştirin ve HTTP isteğini gönderin.
4. Uygulama, 000.000 numaralı kullanıcının profilini gösterir ve bu bilgileri görüntüleyebilir ve düzenleyebilirsiniz.

Saldırı senaryosu / etki: Herhangi bir kullanıcı bu güvenlik açığını başka bir kullanıcının profilini görüntülemek ve düzenlemek için kullanabilir. En kötü senaryoda, saldırganlar tüm sistemimizde her kullanıcının profil bilgilerini alma işlemini otomatik hale getirebilir. Bu durumun henüz kötüye kullanıldığına inanmasak da, bunu standart YÜKSEK önemde bir sorun olarak ele almamız önemlidir. Kötüye kullanıma dair kanıt gözlemlersek bu durum KRİTİK önem derecesine çıkabilir. Düzeltme adımları: İstekte bulunan kullanıcının, profileID değeri aracılığıyla istenen profili görüntülemek/düzenlemek için erişim iznine sahip olduğundan emin olmak için sunucu tarafı kontrolleri uygulayın. Örneğin, Ayşe giriş yapmış ve 123456 profil kimliğine sahipse ancak Ayşe'nin 333444 profil kimliğini istediği görülürse kullanıcı bir hata görür ve başka bir kullanıcının profiline erişme denemesi günlüğe kaydedilmelidir. IDOR ve nasıl düzeltileceği hakkında daha fazla bilgi için lütfen OWASP'ın bu hatayla ilgili materyallerini inceleyin.

Çeşitli kaynaklardaki güvenlik açıklarını standart biçiminize otomatik olarak dönüştürmenin yollarını bularak zamandan tasarruf edebilir ve manuel olarak daha az çaba sarf edebilirsiniz. Daha fazla güvenlik açığı oluşturdukça düzeltme adımlarında ortak temalar bulabilirsiniz. Genel hata biçimi şablonunuzun ötesinde, yaygın güvenlik açığı türleri için ek şablonlar oluşturmak isteyebilirsiniz.

Sahipleri bulma

Güvenlik açığı yönetiminin en zor yanlarından biri, hataları düzeltmeye yardımcı olacak sahipleri belirlemek ve hataları zaman çizelgesinde gerçekten düzeltmeye yönelik kaynakları tahsis etmek için onları ikna etmektir. Öğe yönetimi süreçleri oluşturduysanız bu işlem biraz daha kolay olur. Öyle değilse bu durum bir motivasyon kaynağı olabilir. Kuruluşunuzun büyüklüğüne bağlı olarak bir sahibi bulmak oldukça basit veya çok karmaşık olabilir. Kuruluşunuz büyüdükçe, yeni keşfedilen güvenlik sorunlarının düzeltilmesinden kimin sorumlu olduğunu belirleme çabası da artar. Operasyonel bir görev rotasyonu uygulamayı düşünün. Görevde olan kişi; atanmamış güvenlik açıklarını incelemek, sahipleri izlemek ve önem derecesine göre önceliklendirmekten sorumludur. Bir güvenlik açığını düzeltmekten kimin sorumlu olduğunu belirleyebiliyor ve hataya atayabiliyor olsanız bile, onları hatayı düzeltmek için zaman ayırmaları için ikna etmeniz gerekir. Bu yaklaşım ekibe ya da bireye ve üzerinde çalıştıkları diğer unsurlara göre değişiklik gösterebilir. Önem standartlarınız ve çözüm zaman çizelgeleriniz konusunda kuruluşunuzu kabul ettiyseniz, bunlardan bahsedebilirsiniz, ancak bazen bir hatayı düzeltmesi için ekstra ikna etmek gerekebilir. Aşağıda, güvenlik açıklarının düzeltilmesine yönelik bazı genel ipuçları verilmiştir:

• Nedenini açıklayın: Birisine düzeltmesi için bir güvenlik açığı atandığında bu, genellikle beklenmedik bir iş olur. Bu sorunu zamanında düzeltmenin neden önemli olduğunu (ör. Etki / Saldırı Senaryosu) açıklayın ve sahibin bunları anlamasını sağlayın.
• Bağlam alma: Bazı durumlarda yalnızca bir kişi bir hatayı düzeltmek için gerekli bilgiye sahip olur ve üzerinde çalıştığı başka görevler olabilir. Zaman ayırıp bunların neler olduğunu öğrenin. Diğer görevler, bu güvenlik açığını kısa vadede düzeltmekten daha önemli olabilir. Çözüm zaman çizelgelerinde empati ve esneklik göstermeniz iyi niyet kazanmanızı ve güvenlik açıklarını düzeltmek için ihtiyaç duyduğunuz kişilerle ilişkinizi güçlendirmenizi sağlar. Ancak fazla zaman bırakmamaya dikkat edin. Aksi takdirde, kuruluşunuz çözüm zaman çizelgelerinizi ciddiye almayacaktır.
• Nasıl olduğunu açıklayın: Hataya düzeltme tavsiyesi ekleseniz bile, sorunu düzeltmenin sahibi kafası karışabilir veya hatayı nasıl düzelteceğinizi öğrenmek için yardıma ihtiyaç duyabilir. Sorunun nasıl düzeltileceğini anlamak için yardıma ihtiyaç duyarsa bunu öğretmeye yardımcı olun. Hataları sahiplere yardım etmeden patlatmak, kurumun güvenlik ekibiyle ilişkisine zarar verir. Başkalarına mümkün olduğunca yardım etmek, onların mevcut ve gelecekteki güvenlik açıklarını düzeltmelerini ve başkalarına eğitim vermelerini sağlar.
• İsteğinizi uyarlama: Çeşitli ekiplerin ve kişilerin, gelen iş isteklerini kabul etmek ve önceliklendirmek için mevcut süreçleri olabilir. Bazı ekipler, gelen tüm isteklerin yöneticileri üzerinden yapılmasını isteyebilir. Bazıları ise yardım isteklerinin standart biçimde gönderilmesini ister. Bazıları sadece bir sprintte önceden belirlenenler üzerinde çalışır. Her durumda, isteğinizi ekibin veya bireyin yardım taleplerini almak için genellikle kullandığı biçime uyacak şekilde uyarlamak için biraz daha zaman ayırmak, isteğinize öncelik verilmesi ve işlem yapılması olasılığını artırır.
• Son çare olarak durumu üst merciye iletme: Yukarıdakilerin hepsini denediyseniz ve bir güvenlik açığını gidermekten sorumlu kişi veya ekip ciddi bir güvenlik sorununu düzeltmek için vakit ayırmayacaksa konuyu gerektiği şekilde üst yönetime iletmeyi düşünün. Bu, söz konusu kişi veya ekiple olan ilişkinize zarar verebileceğinden, her zaman son çare olarak uygulanmalıdır.

Kök neden analizi

Güvenlik açıklarını tek tek bulup düzeltmenin yanı sıra temel neden analizi (RCA) gerçekleştirmek, sistemsel güvenlik sorunlarını tespit edip gidermenize yardımcı olabilir. Herkesin kaynakları kısıtlı olduğundan bu adımı atlamak cazip gelebilir. Bununla birlikte, güvenlik açığı verilerinizdeki trendleri analiz etmek ve kritik ve yüksek önem düzeyine sahip hataları daha derinlemesine incelemek için zaman ayırmak, size zaman kazandırabilir ve uzun vadede riski azaltabilir. Örneğin, aynı güvenlik açığı türünün (ör. amaç yönlendirme) uygulamanızın genelinde tekrar tekrar göründüğünü fark ettiğinizi varsayalım. Bu güvenlik açığını uygulamanıza getiren ekiplerle konuşmaya karar verdiniz ve çoğunun amaç yönlendirmenin ne olduğunu, neden önemli olduğunu veya nasıl önleneceğini anlamadığını fark ediyorsunuz. Kuruluşunuzdaki geliştiricileri bu güvenlik açığı hakkında eğitmeye yardımcı olacak bir konuşma ve kılavuz hazırlarsınız. Bu güvenlik açığı büyük olasılıkla tamamen ortadan kalkmayacaktır, ancak muhtemelen daha az artacaktır. VDP'nizi başlattığınızda, üçüncü bir tarafın size bildirdiği her güvenlik açığı, mevcut dahili güvenlik süreçlerinize atılmış bir unsurdur. VDP'nizdeki hatalar üzerinde RCA oluşturmak, güvenlik programınızı sistematik olarak nasıl iyileştireceğiniz konusunda daha da fazla bilgi sağlayacaktır.

Algılama ve müdahale

Tespit ve müdahale, kuruluşunuza yönelik olası saldırıları tespit edip bunlara müdahale etmek için kullandığınız araçları ve süreçleri ifade eder. Bu, şüpheli davranışları tespit etmek için verileri analiz eden, satın alınmış veya kendi geliştirdiği çözümler biçiminde gerçekleşebilir. Örneğin, Eğitim Hataları bölümünde bir kullanıcı başka bir kullanıcının profiline yetkisiz erişim sağlamaya her çalıştığında günlüğe kaydetme hakkında konuştuk. Bir kullanıcının kısa bir süre içinde diğer kullanıcıların profillerine erişmek için çok sayıda başarısız deneme yaptığını fark ederseniz bir sinyal veya uyarı görebilirsiniz. Hatta, bir kullanıcının hizmetlerinize erişimini belirli bir süre için veya durum incelenip tekrar erişim manuel olarak geri yüklenene kadar süresiz bir şekilde otomatik hale getirebilirsiniz. Kullandığınız tespit ve müdahale mekanizmaları yoksa kuruluşunuz için dijital adli tıp ve olay yanıtı (DFIR) programı oluşturma konusunda size rehberlik etmesi için bir uzman danışmanla çalışma seçeneğini değerlendirin. Halihazırda kullanımda olan tespit ve müdahale mekanizmalarınız varsa internete bakan saldırı yüzeylerinize karşı test yapan beş, on, hatta yüz güvenlik araştırmacısının sonuçlarını göz önünde bulundurmak istersiniz. Bu durum, mevcut IDS/IPS (saldırı tespit ve önleme sistemleri) üzerinde büyük bir etki yaratabilir.

Potansiyel riskler şunları içerir:

• Aşırı uyarı yüklemesi: Kötü amaçlı saldırılara benzeyen ancak aslında VDP'nize katılan güvenlik araştırmacılarının normal, onaylanmış testlerinden oluşan uyarı veya sinyal seli. Gerçek saldırıları meşru güvenlik testlerinden ayırt etmenin zorlaşmasına neden olacak kadar karışıklık yaratabilir.
• Olaylara müdahaleyle ilgili yanlış alarm: Kişileri Cumartesi günü saat 02:00'de sayfaya yerleştiren süreçleriniz varsa bu kişiler uyanıp aslında sadece meşru bir test yapan bir güvenlik araştırmacısı olan olası bir ihlali araştırmaktan memnun olmazlar.
• Güvenlik araştırmacılarını engelleme: Agresif IPS (saldırı önleme sistemleri) kullanıyorsanız, güvenlik açıklarını tanımlamak ve bunları size bildirmek için taramalar, manuel testler vb. çalıştırmaya çalışan bir güvenlik araştırmacısının IP adresini engellemek zorunda kalabilirsiniz. Özellikle bir VDP söz konusu olduğunda, bir güvenlik araştırmacısı beş dakika test yaptıktan sonra engellenirse ilgisini kaybedip bunun yerine başka bir kuruluşun programına odaklanabilir. Bu durum, programınızda güvenlik araştırmacılarının genel olarak etkileşim sağlamamasına yol açabilir. Bu da keşfedilmeyen (ve dolayısıyla kuruluşunuz tarafından bilinmeyen) güvenlik açıkları riskini artırır. IPS'nizin etkisini azaltmak istemeseniz de araştırmacıların dikkatini uzaklaştırma riskini azaltmak için alabileceğiniz başka önlemler de vardır.

Bu riskleri ele alma yöntemi büyük ölçüde dışarıdan güvenlik araştırmacılarıyla çalışırken benimsediğiniz yaklaşıma bağlıdır. Gerçek saldırıları simüle eden daha siyah kutu tarzı bir test istiyorsanız hiçbir şey yapamazsınız. Bu durumda, araştırmacının trafiği uyarılar oluşturur ve ekibiniz, araştırmak ve buna göre yanıt vermek için harekete geçebilir. Bu, ekibinizin gerçek saldırılar gibi görünen olaylara müdahale etme pratiği yapmasına yardımcı olur, ancak özellikle test yapmaları engellenmişse güvenlik araştırmacılarının katılımını azaltabilir. Ayrıca meşru testleri incelemeye zaman ayırırken gerçek bir saldırının kaçırılmasına neden olabilir. Daha fazla gri kutu yaklaşımı istiyorsanız test trafiklerini bir şekilde kendi kendilerine tanımlamak için güvenlik araştırmacılarıyla çalışmayı düşünebilirsiniz. Bu sayede, testlerden ve bunlardan kaynaklanan uyarılardan gelen trafiği beyaz listeye ekleyebilir veya başka şekilde filtreleyebilirsiniz. Ekibiniz gerçek saldırıları onaylanmış testlerden daha iyi ayırabilecek ve araştırmacılar, izinsiz giriş önleme sistemleriniz tarafından engellenmeden güvenlik açıklarını bulup size bildirebilecektir. Bazı kuruluşlar, güvenlik araştırmacılarından, araştırmacı tarafından oluşturulan isteklerdeki başlıklara eklenebilecek benzersiz bir tanımlayıcı için başvuruda bulunmak üzere bir form göndermelerini ister. Bu sayede kuruluş, araştırmacı için trafiği beyaz listeye ekleyebilir ve ayrıca araştırmacının üzerinde anlaşmaya varılan test kapsamının ötesine geçip geçmediğini belirleyebilir. Böyle bir durumda araştırmacıya ulaşabilir ve bir test planı üzerinde birlikte çalışmaya hazır oluncaya kadar beklemesini isteyebilirsiniz.