Sorumlu açıklama

Açılış

Ece üniversitenin ders kayıt sistemine girdiğinde, sayfanın adres çubuğunda bir sayı fark etti: kendi öğrenci numarasıydı. Ekranda yalnız kendi ders programı vardı. Ama o sayı, aklına Modül 4'te öğrendiği bir şeyi getirdi: adres çubuğundaki değerler, kullanıcının değiştirebileceği değerlerdir.

Bir an durdu. Merak ediyordu: sayıyı bir artırsa, başka bir öğrencinin programını mı görecekti?

Sonra elini klavyeden çekti. Sayıyı değiştirmek, başka bir öğrencinin kişisel bilgisine yetkisiz bakmak demek olabilirdi. Sistem onun değildi ve kimse ona böyle bir şeyi denemek için izin vermemişti. Ama gördüğünü de görmezden gelmek istemiyordu. Belki bir zafiyet vardı, belki yoktu; ama bunu sınamak onun işi değildi. Bildirmek ise olabilirdi.

Akşam ev arkadaşlarına sordu: "Bunu kime söylemem gerekir? Ve nasıl söylemeliyim ki başım belaya girmesin?"

Tek fikir

Sorumlu açıklama, bir zafiyeti bulan kişi ile onu düzeltecek sistem sahibinin, kullanıcıları koruyacak biçimde birlikte çalışmasıdır. Bulan, kullanmadan ve yaymadan bildirir; sahip, kolay bir bildirim yolu açar, makul sürede düzeltir ve bulanı korur. İki taraf da kuralları önceden yazarsa süreç işler.

Nasıl çalışır

Modül 1'de sorumlu açıklamayı tanımlamıştık: bir güvenlik açığını fark eden kişinin onu kullanmadan, kamuya duyurmadan önce sistemin sahibine bildirmesi ve düzeltme için makul süre tanıması. O derste Selin'in şirketinin bir bildirim adresi yayımladığını da görmüştük. Bu ders sürecin içine bakıyor: bildirim nereye gider, sonra ne olur, ve iki taraf neyi önceden bilmelidir?

Sürecin tipik aşamaları şunlardır. Bulan kişi zafiyeti fark eder ve doğrulamak için gereğinden fazla ileri gitmez. Sahibin bildirim kanalını bulur ve zafiyeti açık, tekrar edilebilir ama zarar vermeyen bir biçimde anlatır. Sahip bildirimi aldığını doğrular, zafiyeti inceler ve düzeltir. İki taraf bir açıklama tarihi üzerinde anlaşır; düzeltme yayımlandıktan sonra zafiyet kamuya açıklanır, çoğu zaman bir CVE numarasıyla ve bulana teşekkür edilerek. Birden fazla üreticiyi etkileyen zafiyetlerde bu süreci koordine eden kuruluşlar devreye girebilir.

Sürecin en kırılgan noktası ilk adımdır: bulan kişi, kime bildireceğini bulamazsa ya bildirmekten vazgeçer ya da yanlış kişiye, yanlış biçimde bildirir. İnternet mühendisliği topluluğu bunu çözmek için basit bir dosya biçimi tanımladı.

Belgenin son uyarısı bu dersin özüdür: bir bildirim kanalının olması, sistemi sınama izni değildir. Kanal, bulduğunu bildirmek içindir; aramak için değil.

İyi bir politika iki tarafı da korur. Kurum, bildirimlerin doğru kanala, doğru biçimde gelmesini sağlar. Araştırmacı, neyin kapsamda olduğunu ve kurallara uyduğunda neyle karşılaşacağını önceden bilir.

Bazı kurumlar bir adım daha ileri gider.

Sahada

Savunma

Sorumlu açıklama iki tarafın süreci; savunma da iki taraflıdır.

Sistem sahibi olarak bildirimi kolaylaştır. Bir bildirim adresi ya da formu yayımla ve onu kolay bulunur yerde tut. Web sitelerinde security.txt bunun yerleşik bir yoludur. Adresin gerçekten izlendiğinden emin ol; okunmayan bir adres, hiç olmayan adresten daha kötüdür, çünkü bulan kişi bildirdiğini sanır.

Bir zafiyet açıklama politikası yaz. Kapsamı, beklentileri, yasakları, yanıt süreni ve kurallara uyan araştırmacıya karşı tutumunu açıkça yaz. Belirsizlik, iyi bir bildirimi korkutup kaçırır.

Bildirimi ciddiyetle işle. Bildirimi aldığını hemen doğrula, incele, düzelt ve bulanı süreç boyunca bilgilendir. Bildirilen zafiyetin zaten kullanılıp kullanılmadığına da bak; bir önceki derslerde gördüğümüz gibi kayıtlara geriye dönük bakmak burada da geçerlidir.

Bulan kişiyi koru ve teşekkür et. İzni varsa adıyla teşekkür etmek, bir sonraki araştırmacıyı da sana yönlendirir.

Bulan kişi olarak gerektiğinden ileri gitme. Bir zafiyetin varlığından şüphelendiğin anda dur. Doğrulamak için başkasının verisine bakmak, bir saldırının ilk adımıyla aynıdır. Ece'nin yaptığı gibi, şüpheni ve neden şüphelendiğini anlat, sınamayı sahibine bırak.

Bildirimi açık ve sakin yaz. Ne gördüğünü, nerede gördüğünü, neden önemli olabileceğini ve neyi yapmadığını yaz. Tehdit eden, süre dayatan ya da karşılık bekleyen bir dil, iyi bir bildirimi şantaja benzetir.

Bir yanıt gelmezse kanalı değiştir, ama yaymaya başlama. Başka bir yetkiliye yaz, ya da gerekiyorsa ülkenin ulusal siber olaylara müdahale ekibi gibi koordinasyon yapabilen bir kuruma danış.

Uygulama

Kendi kullandığın birkaç hizmetin sorumlu açıklama kanallarını bulacak ve bir bildirim taslağı hazırlayacaksın.

Bittiğinde, üç hizmetin hangilerinde bir bildirim kanalı bulduğunu not et.

Defter: Üç hizmetin security.txt durumu ve bildirim yolları, son geçerlilik tarihleri, bildirim taslağı.

Hata köşesi

Etik ve sınırlar

Sorumlu açıklamanın en zor kısmı, bulan kişinin nerede durması gerektiğidir. Bir zafiyetten şüphelendiğin anda dur: sistemin sahibinin yazılı izni ya da açık bir politikanın verdiği kapsam olmadan onu sınamak, başkasının verisine bakmak ya da sistemi zorlamak, iyi bir amaçla da yapılsa Türkiye'de bilişim sistemlerine yönelik suçlar kapsamına girebilir; açıklama politikası bile ancak yazdığı kapsam ve kurallar içinde koruma sağlar. Bulduğun zafiyeti kimseye satmazsın, karşılığında bir şey istemezsin ve düzeltme gelmeden kamuya duyurmazsın; bir ödül programı yoksa ödül talep etmek, iyi bir bildirimi şantaja dönüştürebilir. Bir sahip olarak da sorumluluğun vardır: sana zafiyet bildiren birini, politikana uyduğu sürece tehdit etmemek, onu bir saldırgan gibi görmemek ve düzeltmeyi makul sürede yapmak.

Kapanış

1. Sorumlu açıklama, bir zafiyeti bulan ile onu düzeltecek sahibin kullanıcıları koruyacak biçimde birlikte çalışmasıdır: bulan kullanmadan bildirir, sahip makul sürede düzeltir, açıklama düzeltmeden sonra yapılır.
2. Sahibin işi bildirimi kolaylaştırmaktır: izlenen bir bildirim adresi, web sitelerinde security.txt, kapsamı ve kuralları açık bir zafiyet açıklama politikası ve isteğe bağlı olarak bir hata ödül programı.
3. Bulan kişinin işi durmaktır: şüphelendiği anda sınamayı bırakmak, açık ve sakin bir bildirim yazmak, yanıt gelmezse kanalı değiştirmek ama zafiyeti yaymamak; bildirim kanalının varlığı bir test izni değildir.

Üç soru

1. Ece adres çubuğundaki sayıyı neden değiştirmedi ve bildiriminde bunu neden özellikle yazdı?
2. Selin'in ekibi neden bir security.txt dosyası yayımladı ve dosyaya son geçerlilik tarihini neden takvimlerine eklediler?
3. RFC 9116'ya göre bir sitede security.txt dosyasının bulunması neden o siteyi test etme izni anlamına gelmez?

Yanıtlar

1. Sayıyı değiştirmek, başka bir öğrencinin kişisel bilgisine yetkisiz bakmak demek olabilirdi; sistem onun değildi ve böyle bir deneme için izni yoktu. Bildiriminde bunu yazması, ne gördüğünü ve neyi yapmadığını açıkça göstererek hem bildirimi ciddiye alınır kıldı hem de onu bir saldırgan gibi görünmekten korudu.
2. Araştırmacı onları bulmak için kişisel e-posta adreslerine ulaşmak zorunda kalmıştı, çünkü eski bildirim adresi bir site yenilemesinde sayfadan düşmüştü. security.txt, bildirim yolunu belirli ve kolay bulunur bir yerde, politikayla birlikte duyurur. Son geçerlilik tarihi zorunludur ve dosya da bayatlayabilir; takvime eklenmesi, tarih geçmeden dosyanın güncellenmesini sağlar.
3. Belge, dosyanın varlığının araştırmacılarca test izni, yokluğunun ise yasak olarak yorumlanabileceğini, ama her iki yorumun da yanlış olduğunu yazar. security.txt yalnız nereye ve nasıl bildirim yapılacağını söyler. Test izni varsa, kurumun açıklama politikasında kapsamı ve kurallarıyla birlikte açıkça yazılır.

Sonraki derse köprü

Bu modülde zafiyetleri tanıdık, adlandırdık, puanladık, taradık ve bildirdik. Modülün son dersi bunları bir atölyede birleştiriyor: Yama önceliklendirme dersinde istismar edilen zafiyet listelerini ve iş etkisini kullanarak gerçek bir bulgu listesini sıraya koyacağız.