Coordinated vulnerability disclosure

Koordineli güvenlik açığı bildirimi (CVD)

Güvenlik açıkları nasıl bildirilir, alınır ve koordine edilir; örnek politikalarla.

Koordineli güvenlik açığı bildirimi (Coordinated vulnerability disclosure, CVD) bir bilgisayar güvenliği terimidir. İnsanların güvenlik sorunları hakkındaki raporları nasıl paylaşabileceğini açıklar. Örnekler arasında hata raporları, izinsiz giriş riskleri, bilgisayar korsanlığı uyarıları, veri sızıntıları, web sitesi ihlalleri vb. yer alır.

Çeviriler: العربية, Български, বাংলা, Čeština, Cymraeg, Dansk, Deutsch, Ελληνικά, English, Español, Eesti, Euskara, فارسی, Suomi, Français, Gaeilge, Gàidhlig, ગુજરાતી, Hausa, עברית, हिन्दी, Hrvatski, Magyar, Bahasa Indonesia, Íslenska, Italiano, 日本語, 한국어, Lietuvių, Latviešu, Nederlands, Polski, Português, Română, Русский, Slovenčina, Slovenščina, Svenska, Kiswahili, ไทย, Türkçe, Українська, اردو, Tiếng Việt, 中文

İçindekiler:

Politikalar:

Giriş

Bu belge, koordineli güvenlik açığı bildirimini insanların birlikte çalışmasına yardımcı olabilecek şekillerde açıklar.

Belgenin amaçları:

  1. Güvenlik sorunlarını keşfeden ve bildirmek isteyen kişilere yardımcı olmak.

  2. Şirket temsilcilerinin sorumlu bildirimin ihtiyaçlarını, hedeflerini, uygulamalarını ve özel durumlarını anlamasına yardımcı olmak.

  3. Depo klasörüne örnek koordineli güvenlik açığı bildirimi politikaları eklemek.

Çekme isteklerini (pull request), GitHub sorunlarını (issue) veya security@joelparkerhenderson.com adresine e-postayı memnuniyetle karşılarız.

Koordineli güvenlik açığı bildirimi nedir?

Koordineli güvenlik açığı bildirimi, birisi bir güvenlik sorunu (örneğin bir yazılım hatası) keşfettiğinde ve bunu üreticiye (örneğin yazılımı yapan şirkete) bildirmek istediğinde üç adımı tanımlar.

Adımlar:

  1. Keşfeden kişi sorunu üreticiye iyi niyetle ve gizli olarak bildirir.

  2. Üretici iyi niyetle kullanıcıları korumaya ve sorunu ele almaya çalışır.

  3. Belirli bir süre sonra güvenlik sorunu kamuya açıklanır.

Adım 1: Sorunu bildirin

Adım 1 keşfeden kişi içindir: sorunu iyi niyetle ve gizli olarak bildirin.

  • İyi: Keşfeden kişi ilgili bilgileri üreticiye gönderir; örneğin üreticinin güvenlik e-posta adresine (genellikle "security@example.com") e-posta ile veya üreticinin web sitesindeki bir web sayfası formu aracılığıyla (genellikle "https://www.example.com/security").

  • Kötü: Raporu herkese açık bir blogda yayınlamak, medyayı uyarmak, tehdit etmek veya güvenlik sorununu bilgisayar korsanlarına satmaya çalışmak vb.

  • İpucu: Keşfeden kişi anonim kalmayı seçebilir; üretici de anonim kalmayı seçebilir.

İsterseniz sorundan haberdar olmaya devam edin.

  • İyi: İletişim hatlarını açmak, takip bilgileri sağlamak veya durumu izlemek.

  • Kötü: Sorunu unutmak.

  • İpucu: Keşfeden kişi yardım edip etmemeyi, iletişimde kalıp kalmamayı seçebilir ve koşullar değişirse düzenlemeyi de değiştirebilir.

İsterseniz sorunu başkalarına açıklayın.

  • İyi: Belirtilen süreyi bekledikten sonra kamuya açıklamak; örneğin ilgili bilgileri bir güvenlik haber sitesinde yayınlamak, ilgili üçüncü taraf güvenlik araştırmacılarıyla iletişime geçmek veya sorunu herhangi bir herkese açık sosyal sitede duyurmak vb.

  • Kötü: Kendinize veya başkalarına karşılaştırılabilir miktardan fazla risk oluşturacağını düşünmediğiniz sürece sorunu başkalarına açıklamamak.

  • İpucu: Koşullar değişirse, örneğin daha yüksek bir risk veya yabanda (in the wild) aktif bir istismar keşfedilirse, keşfeden kişi sorunu başkalarına daha erken açıklayabilir.

Adım 2: İletişim kanallarını güvence altına alın

Adım 2 üretici içindir: iletişim kanallarının kullanılabilir olduğundan emin olun.

  • İyi: Üretici bir güvenlik iletişim e-posta adresi (geleneksel olarak "security@example.com") ve ideal olarak güvenli bir e-posta şifreleme anahtarı yayınlar.

  • İyi: Üretici bir güvenlik iletişim web sayfası (geleneksel olarak "https://www.example.com/security") yayınlar ve ideal olarak sayfayı web sitesinin alt bilgisi, site haritası ve arama aracılığıyla kolay keşfedilebilir kılar.

  • Kötü: Üretici bir e-posta adresi veya web sayfası sağlamaz ya da bunları kolay keşfedilebilir kılmaz.

Personel yetkinliklerini güvence altına alın.

  • İyi: Üretici destek personelini bir güvenlik sorgusu aldıklarında ne yapacakları konusunda eğitir; örneğin iletişim bilgileriyle nasıl yanıt verecekleri veya sorguyu doğru iç ekibe nasıl ileteceklerini.

  • İyi: Üretici personel yetkinliklerinin çalıştığını periyodik olarak doğrular.

  • Kötü: Üretici eğitmez veya doğrulamaz.

Keşfeden kişiye zaman çizelgesi içinde yanıt verin.

  • Keşfeden kişi bir zaman çizelgesi belirtmezse, bir iş günü kullanın; çünkü bu sektör standardıdır ve güncel sektör en iyi uygulamasıdır.

  • Keşfeden kişi soru sorarsa yanıtlayın. Bu, keşfeden kişi test etmek için izin isterse özellikle önemlidir. Tüm yanıtların net ve doğrudan olduğundan emin olun.

Keşfeden kişiye yetkili bir güvenlik iletişim noktası ve/veya yetkili bir güvenlik süreci aracılığıyla yanıt verin.

  • İyi: "security@example.com" gibi güvenliğe özgü bir e-posta adresinden gelen yanıt.

  • Örneğin bunlar kötüdür: "help@example.com" gibi genel amaçlı bir e-posta adresinden veya yetkili bir güvenlik uzmanı olmayan herhangi birinden gelen yanıt.

Keşfeden kişiye sorunun bir güvenlik raporu olarak tanındığını bildirin.

  • İyi: Güvenliğe özgü ifadeler, örneğin "Güvenlik ekibimiz sorumlu bildirim raporunuzu aldı", "Güvenlik sürecimizin sonraki adımları şunlardır" veya "Bilginiz artık güvenlik takipçimizde XYZ kimlik numarasıyla kayıtlı" vb.

  • Kötü: "İşinizi takdir ediyoruz" veya "Güvenliği ciddiye alıyoruz" gibi genel ifadeler, "E-postanızı başka bir departmana ilettik" gibi sorumluluğu devretme ifadeleri vb.

Adım 3: İyi niyetle çalışın

Adım 3 keşfeden kişi ve üretici birlikte içindir: iyi niyetle çalışın.

Koordineli güvenlik açığı bildiriminin iyi niyete dayalı bir süreci tanımladığını anlayın.

  • 1 numaralı hedef, kullanıcıların kendilerini güvenlik risklerinden korumasına yardımcı olma konusunda iyi niyettir.

  • 2 numaralı hedef, güvenlik sorununu ele alma konusunda iyi niyettir.

  • Keşfeden kişi ve/veya üretici iyi niyetle diğer güvenlik kişilerini dahil etmeyi seçebilir; örneğin sorunla ilgili yardım için diğer ilgili güvenlik araştırmacılarıyla iletişime geçmek.

Koordineli güvenlik açığı bildiriminin herhangi bir yükümlülük oluşturmadığını anlayın.

  • Keşfeden kişi ve/veya üretici istediği zaman, herhangi bir nedenle, uyarılı veya uyarısız vazgeçebilir. İlgili tüm kişileri bilgilendirmek ve güncel tutmak nezakettir, ancak bu her zaman mümkün, pratik veya istenir olmayabilir.

  • Koordineli güvenlik açığı bildirimi hiçbir hukuki anlaşma oluşturmaz. Keşfeden kişi ve üreticinin zaten bir hukuki anlaşması varsa, ilgili herkesin uygun avukatlara danışmasını öneririz; bu belgeyi hukuki tavsiye olarak kullanmayın.

Koordineli güvenlik açığı bildiriminin iyi iletişim kullanmayı ve tehditleri reddetmeyi amaçladığını anlayın.

  • Koordineli güvenlik açığı bildirimi, ilgili herkesin 1 numaralı hedefin kullanıcıların kendilerini güvenlik risklerinden korumasına yardımcı olmak, 2 numaralı hedefin ise güvenlik sorununu ele almak olduğunu anladığında en iyi sonucu verir.

  • Koordineli güvenlik açığı bildirimi; misilleme, gözdağı, askıya alma, iptal, şantaj, takip yükü veya mağduru suçlama gibi her türlü tehdidi reddeder.

Koordineli güvenlik açığı bildiriminin farklı insanlar için farklı anlamlara gelebileceğini anlayın.

  • Keşfeden kişi ve üretici koordineli güvenlik açığı bildirimi hakkında farklı anlayışlara sahip olabilir. Bu anlayışlar birbiriyle örtüşmeyebilir. İyi niyet, ilgili herkesin bunu anlamasını içerir.

  • Bazı üreticiler koordineli güvenlik açığı bildirimi politikaları yayınlar. Bunlar yararlı rehberlik olabilir. Keşfeden kişi farklı bir koordineli güvenlik açığı bildirimi türü kullanmayı seçerse veya sorumlu bildirim hakkında farklı bir anlayışa sahipse, bu kesinlikle sorun değildir.

Genellikle keşfeden kişinin yayıncıya bir iyilik yaptığını anlayın.

  • Genellikle keşfeden kişinin güvenlik açıklarını yayınlamak için kimsenin iznine ihtiyacı yoktur.

  • Genellikle keşfeden kişinin bilgisi yayıncıya yardımcı olur.

Başarıyı doğrulayın

Sorun çözüldükten sonra üretici başarıyı doğrulamalıdır.

  • Tüm insanlar ve süreçler bildirimi başarıyla ele aldı mı? Evetse iyi. Hayırsa, kök neden analizi (RCA), olay sonrası raporlar (post-mortem), Ishikawa diyagramları veya sistem teorisine dayalı nedensel analiz (CAST) gibi olay sonrası araştırmalar yapmayı düşünün.

  • Çözülmemiş sorunlar önceliklendirildi (triage) ve izleniyor mu?

  • Üretici ve keşfeden kişi sonraki adımlar için ne yapılması gerektiğini anlıyor mu? Bu, olası takip eden koordineli güvenlik açığı bildirimleri olması ihtimaline karşı özellikle doğru yapılması gereken bir konudur.

Rehberlik

Koordineli güvenlik açığı bildirimi için rehberlik; etik uzmanları, hukuk savunucuları, genel halkın makul beklentileri vb. birçok alandan gelebilir.

Rehberlik arıyorsanız, aşağıda açıklanan bu üç alan ilginizi çekebilir.

  • İyi Samiriyeli

  • Kurtarma yükümlülüğü

  • Özen yükümlülüğü

İyi Samiriyeli

Wikipedia: Good Samaritan law

İyi Samiriyeli yasaları, yaralı, hasta, tehlikede veya başka şekilde aciz olan ya da öyle olduğuna inandıkları kişilere makul yardım sağlayan insanlara hukuki koruma sunar. Koruma, yoldan geçenlerin dava edilme veya kovuşturulma korkusuyla yardım etme konusundaki tereddüdünü azaltmayı amaçlar.

Kurtarma yükümlülüğü

Wikipedia: Duty to rescue

Kurtarma yükümlülüğü, bir tarafın tehlikedeki başka bir tarafı kurtarmaya gelmediği için sorumlu tutulabileceği bir durumu tanımlayan bir kavramdır. Kurtarma yükümlülüğünün ahlaki ve/veya hukuki yönleri olabilir.

Özen yükümlülüğü

Wikipedia: Duty of care

Özen yükümlülüğü, başkalarına öngörülebilir şekilde zarar verebilecek herhangi bir eylemi gerçekleştirirken makul özen standardına uyma yükümlülüğüdür. Özen yükümlülüğünün ahlaki ve/veya hukuki yönleri olabilir. Göz önünde bulundurulacak bazı hususlar şunlardır: zarar veya yaralanmanın öngörülebilirliği, olası zarar veya yaralanmanın olası büyüklüğü, davalının giriştiği faaliyetin önemi veya toplumsal değeri, davranışın davalı için faydası, alternatif davranışın uygulanabilirliği, alternatif davranışla ilişkili maliyet ve yükler, alternatif davranışın göreli faydası ve alternatif davranışın göreli güvenliği.

Özel durumlar

Güvenlik ekiplerimiz çok çeşitli özel durumlar gördü.

Bunları burada, neyin uygun olup neyin olmayabileceği konusunda geniş bir görüş yelpazesi bulunduğunu insanların anlamasına yardımcı olmak için açıklıyoruz. İlgili herkesin bunlar hakkında iyi niyetle iletişim kurmasını öneririz.

Diğer kullanıcıların bilgilerine erişim

Örnek: Bir URL'nin içinde kullanıcı kimliğinizin bulunduğunu, bir hata ortaya çıkardığını ve URL'yi düzenleyerek kullanıcı kimliğinizi farklı bir kullanıcı kimliğiyle değiştirebileceğinize inandığınızı keşfediyorsunuz.

  • Keşfeden kişinin bunu yapması uygun mu; örneğin yalnızca bunun diğer kullanıcıları da etkileyip etkilemediğini keşfetme amacıyla?

  • Tüm kullanıcılar için risk boyutunu hızlıca anlamak, bilgileri zaten bilgisayar korsanları tarafından görülebilir olabilecek birkaç kullanıcıyı korumaktan daha mı önemli?

  • Keşfeden kişinin bunu istediğiniz kadar çok kullanıcıyla yapması uygun mu?

  • Keşfeden kişinin kullanıcılara etkilendiklerini bildirmek için onlarla iletişime geçmeye çalışması uygun mu? Hafifletme önerileri sunmak uygun mu?

Hizmet reddi

Örnek: Hesabınızı yanlışlıkla askıya alan bir hata keşfediyorsunuz; örneğin bir parola kilidini tetikliyor.

  • Bu bir hizmet reddi saldırısı olarak kabul edilir mi?

İstenmeyen e-posta

Örnek: Bir güvenlik sorununu, ilgili olduğunu düşündüğünüz ve LinkedIn, Facebook vb. üzerinde araştırarak ya da "webmaster@example.com" veya "security@example.com" gibi adlandırma kurallarını kullanarak bulduğunuz şirket çalışanlarına bildirmeye çalışıyorsunuz.

  • Bu uygun mu?

  • Bu istenmeyen e-posta olarak kabul edilir mi?

  • Bu yetkisiz e-posta olarak kabul edilir mi?

Dışlanan gruplar

Örnek: Dışlanan bir gruptasınız; örneğin reşit değilsiniz, bir yaptırım listesindesiniz veya yaptırım listesindeki bir ülkedesiniz.

  • Rapor yapmanız uygun mu?

  • Anonim olarak bildirmek uygun mu?

  • Potansiyel olarak kimlik belirleyici bilgileri, örneğin dışlanan gruptan kurtulmak için ve bildirimin doğru kişilere ulaşmasına yardımcı olma amacıyla kasıtlı olarak değiştirmek uygun mu?

Üçüncü taraf

Örnek: Bir şirketin yazılımında, başka bir yazılımla veya başka bir web sitesiyle entegrasyon gibi bir üçüncü tarafı içeren bir hata olduğunu keşfediyorsunuz.

  • Bulduğunuz tüm bilgileri her iki tarafa da bildirmeniz uygun mu?

  • Her şirkete gönderilen bilgileri sınırlama amacıyla, örneğin bir şirkete bir rapor ve üçüncü taraf şirkete farklı bir rapor olmak üzere iki farklı sorumlu bildirim yapmak gerekli mi?

  • Keşfeden kişinin şirketleri birbiriyle temasa geçirmesi uygun mu?

Yıkıcı yazılım

Örnek: Kullanıcıların kendilerini güvenlik riskinden korumalarına, risk altında olup olmadıklarını belirlemelerine veya güvenlik riskini düzeltmelerine yardımcı olacağına inandığınız bir virüs yazacak kadar yetenekli durumdasınız.

  • Bu uygun mu?

  • Keşfeden kişinin kullanıcıları bu tür yazılımlara ve/veya bu tür yazılımın nasıl oluşturulacağını anlatan rehberlere veya eğitimlere yönlendirmesi uygun mu?

Koordineli güvenlik açığı bildirimi ve sorumlu bildirim karşılaştırması

Koordineli güvenlik açığı bildirimi tercih edilen terimdir.

  • En önemli husus, keşfeden kişi ile üretici arasındaki koordinasyondur.

Sorumlu bildirim (responsible disclosure) kullanımdan kaldırılmış bir terimdir.

  • İnsanların sorumlu olmanın ne anlama geldiğine dair farklı görüşleri vardır. Örneğin bazı insanlar, keşfeden kişinin üreticiyle herhangi bir etkileşime bakılmaksızın halkı derhal bilgilendirmesinin sorumlu olduğunu, koordineli güvenlik açığı bildirimi yapmanın ise bilgiyi halktan sakladığı için sorumsuz olduğunu savunur.

İzleme