İşletmenin Harekete Geçireceği Bir Risk Bulgusu Nasıl Yazarım?

Çoğu güvenlik bulgusu bir elektronik tabloda ölür çünkü diğer güvenlik insanları için yazılırlar, bütçeyi onayan kişi için değil. Raporunuz "CVE-2023-XXXX, CVSS 9.8, derhal yama yapın" diyorsa, bir riski değil, bir güvenlik açığını tanımlamışsınız. İşletme güvenlik açıklarına göre hareket etmez. Hayal edebileceği sonuçlara göre hareket eder.

Neden sadece önem puanları kimseyi harekete geçirmez

CVSS size bir hatanın izolasyonda ne kadar kötü olduğunu söyler. Bu hataya ulaşılabilir olup olmadığı, arkasındaki varlığın gelire önemli olup olmadığı veya telafi edici kontrollerin zaten onu azaltıp azaltmadığı hakkında hiçbir şey söylemez. İnternet yolu olmayan ve duyarlı verisi olmayan bir iç geliştirme kutusundaki 9.8, ödeme ağ geçidindeki 7.5 ile aynı konuşma değildir. Bulguları tamamen CVSS'ye göre sıralarsanız, hiç birinin sömürülmek üzere olmadığı şeyleri yamaklamak için itibarınızı harcarsınız ve gerçekten önemli olan bulgu gürültüde kaybolur.

Harekete geçirilen risk üç bileşene sahiptir: etki için makul bir yol, bu etkiye bağlı bir dolar veya operasyonel maliyet ve onu gerçekten düzeltebilecek bir mal sahibi. Bu üçlerden herhangi birini kaçırırsanız, bulgu beklemede kalır.

Bulguyu tarayıcı çıktısı etrafında değil, bir senaryo etrafında oluşturun

"SQL enjeksiyonu /login uç noktasında bulundu" yerine, senaryoyu yazın: "Kimliği doğrulanmamış bir saldırgan, giriş formu aracılığıyla tam müşteri tablosunu (karma şifreler ve faturalama adreslerini içeren) çıkarabilir. Bu tablo 40.000 etkin hesağı destekler ve aynı veritabanı PCI kapsamına bağlı sipariş geçmişini içerir." Şimdi okuyucu bir güvenlik açığı sınıfını ayrıştırmıyor, bir ihlal bildirimi mektubu ve bir uyum çağrısı hayal ediyor.

Her bulgu için kullanışlı bir yapı:

• Ne olabilir — saldırı yolu düz bir dilde, bir veya iki cümle.
• Neyi etkiler — spesifik sistem, spesifik veriler, spesifik iş süreci.
• Ne kadar tutar — kesinti saatleri, düzenleyici maruz kalma, müşteri güveni, sözleşmesel cezalar. Sahip olduğunuz yerlerde gerçek sayıları kullanın (SLA ceza maddeleri, geçmiş olay maliyetleri, siber sigorta muafiyeti).
• Düzeltmek ne alır — çaba, sadece "yamakla" değil. Bazen çözüm bugün bir WAF kuralı ve gelecek sprintde bir kod değişikliğidir.
• Kimin düzeltmeyi sahibi — bir ad veya bir takım, "BT" değil.

Bulguyu işletmenin zaten izlediği bir şeye bağlayın

Her şirketin liderliğin zaten izlediği ölçütleri vardır: çalışma süresi SLA'ları, churn, son SOC 2 döngüsündeki denetim bulguları, siber sigorta primleri, güvenlik maddesi olan belirli bir müşteri sözleşmesi. Bulgunuzu bu mevcut satırlardan birine bağlayabilirseniz — "bu, sigortacımızın son yenilemenin önem verdiği aynı tür sorun" veya "bu veri akışı Q3'teki SOC 2 denetiminin kapsamı içinde" — yeni bir şeye umursamasını istemiyor sunuz. Zaten hesap verebilir oldukları bir tehdidi gösteryorsunuz.

Bu aynı zamanda raporu sonuçlandırmadan önce iş tarafıyla konuşmanın önemli olduğu yerdir. Belirli bir sistem için dört saatlik bir kesintinin gerçekten ne kadar tuttuğu hakkında finans veya operasyon ile on dakikalık bir konuşma, herhangi bir genel "ün hasarı" satırını yener. Sayıyı alın, alıntı yapın, devam edin.

Sadece CVSS değil, istismar edilebilirlik ve etki alanına göre sıralayın

İşe yarar bir önceliklendirme yaklaşımı:

1. İnternete ulaşılabilir mi yoksa önce dahili erişim gerekli mi?
2. Genel bir açık istismar var mı yoksa teorik mi?
3. Düzenlemelmiş veriye (PCI, PHI, PII) veya taç mücevher sistemlerine dokunuyor mu?
4. Düzeltmenin gerçek zaman ve maliyeti ile bırakmanın maliyeti ne?

Erişilebilirlik ve etki alanında yüksek puan alan ancak CVSS'de sadece orta puan alan bulgular, genellikle MFA ile bir atlama kutusu arkasında derinlemesine üç ağ atlaması olan kritik derecelendirilmiş bir hatanın önüne geçmeyi hak eder.

Sorunu değil, istemi yazın

Her bulguyu belirli bir istekle sonlandırın: bir bütçe satırı, bir değişim penceresi, kapatılacak bir politika istisnası veya belirli bir tarihe kadar gerekli olan adlandırılmış bir karar. "Düzeltmeyi öneririz" göz ardı edilir. "Ödeme ağ geçidine yamaklamak için 15'ten önce dört saatlik bir bakım penceresi gerekiyor, aksi takdirde kalan riski yazılı olarak kabul ediyoruz" bir yönde veya diğerinde bir karar vermeyi zorunlu kılar. Liderliğe yazılı olarak, adlarıyla riski kabul etmeleri için açık bir seçenek vermek, çoğu zaman düzeltmenin onaylanmasını sağlayan şeydir.

Ham tarayıcı çıktısını bu gibi bulgulara dönüştürmeyi uygulamak istiyorsanız, Korra Studio'nun Blue Team ve Offensive segmentlerini birlikte işleyin — istismar bağlamını raporlama alıştırmalarıyla eşleştirmek bu becerinin gerçekten keskinleştiği yerdir.