it-swarm-tr.com

Güvenlik açığı etik bir şekilde nasıl açıklanır?

Güvenlik açığı nasıl etik bir şekilde açıklanır? Bu konuda çeşitli düşünce okulları olduğunu duydum. Her birinin artılarını/eksilerini bilmek istiyorum.

75
Olivier Lalonde

Düzeltme şansı elde etmek için geliştiricilere özel olarak bildirmelisiniz. Bundan sonra, güvenlik açığıyla herkese açık olup olmadığınızda, geliştiriciye sorunu düzeltmek için yeterli zaman ve kime maruz kaldıklarını sistemlerini yükseltmek için yeterli zaman ayırmalısınız. Şahsen, geliştiricinin duyuruyu kendim duyurmak yerine bir güvenlik bülteninde yapmasına izin verirdim. En azından, güvenlik açığının giderildiğini doğrulamak için beklerdim. Zamanınız varsa ve kaynak koduna erişiminiz varsa, bir yama da sağlayabilirsiniz.

43
VirtuosiMedia

Şahsen sanırım Sorumlu açıklama etik bir noktadan gitmenin en iyi yolu gibi görünüyor ve Dan Kaminsky için DNS önbellek zehirlenmesi güvenlik açığının ayrıntılarını açığa çıkardı. Ancak her şey büyük ölçüde uğraştığınız şirket veya gruba ve ayrıca etkileyeceği kullanıcı tabanına bağlıdır.

27
Mark Davidson

@VirtuosiMedia, "Sorumlu İfşa Etme" yi özetlemek için harika bir iş çıkarır.

İki nokta eklerdim:

  • Tam olarak anladıklarından ve yarı pişmiş bir yama yayınlamadığından emin olmak için satıcıyla (mümkünse) çalışın.
  • Tedarikçi sizi dikkate almazsa veya yoksayarsa, denemeye devam edin. Ancak, bunun bir güvenlik açığı olmadığını iddia ederse, devam edin ve yayınlayın. Mümkün olduğunca yüksek. Düzeltmeye söz verdiler, ama yapmadılarsa, taahhüt ettikleri kesin bir zaman çizelgesi ile birlikte onlardan bir cevap almaya çalışın. Bir noktada, ertelemeye devam ederlerse, sonunda onlara yine de yayınlayacağınızı söylemek isteyebilirsiniz ve daha sonra bunları düzeltmek için biraz zaman verin (ancak kısa ve sınırlı).
18
AviD

Bu karmaşık bir konunun halkı. Birkaç yıl önce TLS yeniden müzakere hatasının açıklanmasına katıldım ve inan bana, "sorumlu" olmak için çok uğraştık, ama sonunda, esas olarak etrafımızdaki herkesi kızdırmayı ve (belki de) ertelemeyi başardık düzeltmenin gerçek sürümü. Satıcı bildiriminin mutlaka kötü olduğunu söylememek, sadece çırpılmış testere almanın ve sarılmanın iyi veya daha kötü olduğu kadar zarar vermesini gerçekten çok kolay.

Bizim durumumuzda, sorunu çözmek için IETF'in ( RFC 5746 ) bir eylemi vardı ve sızdığı gün hazır bir internet taslağımız olmasına rağmen, fiili tartışma ve karar verme işi çözüm yaklaşık üç ay daha sürdü ve açıklama yapılana kadar ciddi bir şekilde başlamadı.

Her neyse, bu sorunuza bir cevap değil, ama farkında olduğum en ilginç açıklama hikayelerinden biri. 2010 ShmooCon keynote Hikayede daha fazla bilgi Sorunu keşfeden Marsh Ray ile yaptım.

11
Steve Dispensa

Genellikle, satıcının yanıtına bağlıdır. İyi bir uygulama, güvenlik araştırmacısı satıcıyı güvenlik açığı hakkında bilgilendirdiğinde, konuşma sırasında bu güvenlik açığından poc/exploit yayınlama şartları hakkında konuşursunuz. Aslında, araştırmacı bu güvenlik açığıyla ne yapacağını seçiyor - daha sonra yayınlayın veya yayınlamayın. Ardından satıcı yamayı veya yeni ürün sürümünü yayınlar. Olabilir. Ancak, deneyim nasıl görünüyor - tüm satıcılar çok güzel değil. Bazıları son kullanıcıları ve araştırmacıları bilgilendirmeden hataları sessizce düzeltir, bazıları araştırmacıyı görmezden gelmeyi tercih eder. Hatta diğerleri dava açmaya çalışıyor. Bu yüzden bazen anonimlik bilinmeyen bir satıcıyla ilk iletişimin tercih edilen yoludur.

Ayrıca, hata ödüllendirme programları olduğunu da itiraf etmek isterim - bunlar Google, Mozilla tarafından sunulmaktadır. Ayrıca, diğerleri güvenlik açıkları satın alır - ZDI , iDefense , SNOsoft , gelen "istismar hub'ı" ve Bu nedenle, güvenlik açığı bilgilerini bazı listelerde veya üçüncü taraf şirketler aracılığıyla yayınlayarak satıcıyı doğrudan bilgilendirmenin en az üç yolu vardır.

8
anonymous

Genel bir sorun izleyicileri varsa, "özel" veya "güvenlik" etiketine sahip bir hata yapıp yapamayacağınıza bakın.

Sorun izleyicileri olup olmadıklarına bakılmaksızın, [email protected] şirket adı ve onlara bildirin.

Eğer hemen yanıt vermezlerse (aşağıdaki Schneier makalesinde "Açıklama Penceresi" konusuna bakın), daha geniş bir şekilde ifşa etmeyi düşünmeniz gerekir. Güvenlik akademisyenlerinin/profesyonellerinin güvendiği posta listelerini arayın ve sorunları söz konusu satıcıya nasıl bildirdiklerini sorun. Kuruluşta doğru yere giriş yapabilirler.

Tüm bunlar başarısız olursa, Schneier bitini okuyun ve tam açıklamanın sorunun bir parçası mı yoksa çözümün bir parçası mı olacağını düşünün.

Bruce Schneier tam açıklama için belirli durumlarda “sorunun bir parçası olun, sorunun bir parçası değil” standardını temel alır. Kesinlikle okumaya değer.

Bu klasik "hata gizliliği ve tam ifşa" tartışmasıdır. Daha önce Crypto-Gram'da yazmıştım; diğerleri de bu konuda yazmışlardır. Bu, tüm bilgisayar güvenliği üzerindeki ince etkileriyle karmaşık bir konudur ve tekrar tartışmaya değer.

...

Hem açıklama hem de kavram kanıtı kodunun bu ücretsiz bilgi akışı, güvenlik araştırmaları için de hayati önem taşımaktadır. Bilgisayar güvenliğinde araştırma ve geliştirme son on yılda gelişmiştir ve bunların çoğu tam ifşa hareketine atfedilebilir. Hem iyi hem de kötü araştırma bulgularını yayınlama yeteneği herkes için daha iyi güvenlik sağlar. Güvenlik topluluğu yayın yapılmadan birbirlerinin hatalarından ders alamaz. Herkes aynı hataları tekrar tekrar yaparak kör bahislerle çalışmalıdır. Bilgisayarlarımızın ve ağlarımızın güvenliğini artırmaya devam edersek tam açıklama şarttır.

...

İkincisi, satıcıya önceden bildirimde bulunmaya inanıyorum. CERT bunu aşırı derecede aldı ve bazen satıcıya sorunu düzeltmesi için yıllar verdi.

...

"Sorunun bir parçası değil, sorunun bir parçası olmak" metriğini seviyorum. Güvenliği araştırmak çözümün bir parçasıdır. Tedarikçileri sorunları düzeltmeye ikna etmek çözümün bir parçasıdır. Korku ekimi sorunun bir parçasıdır. Saldırı araçlarını clueless gençlere teslim etmek sorunun bir parçasıdır.

6
Mike Samuel