Coordinated vulnerability disclosure

Koordinované zveřejňování zranitelností (CVD)

Jak hlásit, přijímat a koordinovat bezpečnostní zranitelnosti, s ukázkovými zásadami.

Koordinované zveřejňování zranitelností (Coordinated vulnerability disclosure, CVD) je pojem z počítačové bezpečnosti. Popisuje, jak mohou lidé sdílet hlášení o bezpečnostních problémech. Příkladem jsou hlášení chyb, rizika průniku, varování před hackerskými útoky, úniky dat, průniky na webové stránky atd.

Překlady: العربية, Български, বাংলা, Č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, 中文

Obsah:

Zásady:

Úvod

Tento dokument vysvětluje koordinované zveřejňování zranitelností způsoby, které mohou lidem pomoci spolupracovat.

Cíle dokumentu:

  1. Pomoci lidem, kteří objeví bezpečnostní problémy a chtějí je nahlásit.

  2. Pomoci zástupcům společností pochopit potřeby, cíle, postupy a zvláštní případy odpovědného zveřejňování.

  3. Zahrnout do složky repozitáře příklady zásad koordinovaného zveřejňování zranitelností.

Vítáme pull requesty, issues na GitHubu nebo e-maily na adresu security@joelparkerhenderson.com.

Co je koordinované zveřejňování zranitelností?

Koordinované zveřejňování zranitelností popisuje tři kroky, když někdo objeví bezpečnostní problém (například chybu v softwaru) a chce ho nahlásit výrobci (například společnosti, která software vyrábí).

Kroky:

  1. Objevitel nahlásí problém výrobci soukromě a v dobré víře.

  2. Výrobce se v dobré víře snaží chránit uživatele a problém řešit.

  3. Po stanovené době je bezpečnostní problém zveřejněn.

Krok 1: Nahlaste problém

Krok 1 patří objeviteli: nahlaste problém soukromě a v dobré víře.

  • Dobře: objevitel pošle příslušné informace výrobci, například e-mailem na bezpečnostní e-mailovou adresu výrobce (obvykle „security@example.com") nebo přes formulář na webové stránce výrobce (obvykle „https://www.example.com/security").

  • Špatně: zveřejnění hlášení na veřejném blogu, upozornění médií, vyhrožování nebo pokusy prodat bezpečnostní problém hackerům atd.

  • Tip: objevitel se může rozhodnout zůstat anonymní; výrobce se také může rozhodnout zůstat anonymní.

Pokud chcete, nadále o problému buďte informováni.

  • Dobře: otevření komunikačních kanálů, poskytování následných informací nebo sledování situace.

  • Špatně: zapomenutí na problém.

  • Tip: objevitel se může rozhodnout, zda pomůže, či ne, zda bude komunikovat, či ne, a také může změnit dohodu, pokud se změní okolnosti.

Pokud chcete, zveřejněte problém ostatním.

  • Dobře: počkat stanovenou dobu a pak jít na veřejnost, například zveřejněním příslušných informací na zpravodajském webu o bezpečnosti, kontaktováním příslušných bezpečnostních výzkumníků třetích stran nebo oznámením problému na jakékoli veřejné sociální síti atd.

  • Špatně: nezveřejnit problém ostatním, pokud nepovažujete za pravděpodobné, že by to způsobilo větší než srovnatelné riziko pro vás nebo ostatní.

  • Tip: pokud se okolnosti změní, například bude objeveno vyšší riziko nebo aktivní zneužívání v reálném provozu (in the wild), může objevitel problém zveřejnit ostatním dříve.

Krok 2: Zajistěte kontakty

Krok 2 patří výrobci: zajistěte, aby kontakty byly použitelné.

  • Dobře: výrobce zveřejní bezpečnostní kontaktní e-mailovou adresu (obvykle „security@example.com") a ideálně i bezpečný šifrovací klíč pro e-mail.

  • Dobře: výrobce zveřejní bezpečnostní kontaktní webovou stránku (obvykle „https://www.example.com/security") a ideálně ji učiní snadno dohledatelnou, například přes zápatí webu, mapu stránek a vyhledávání.

  • Špatně: výrobce neposkytne e-mailovou adresu ani webovou stránku, nebo je neučiní snadno dohledatelnými.

Zajistěte schopnosti zaměstnanců.

  • Dobře: výrobce školí pracovníky podpory, co dělat, když obdrží bezpečnostní dotaz, například jak odpovědět s kontaktními informacemi nebo jak dotaz předat správnému internímu týmu.

  • Dobře: výrobce pravidelně ověřuje, zda schopnosti zaměstnanců fungují.

  • Špatně: výrobce neškolí nebo neověřuje.

Odpovídejte objeviteli v časovém rámci.

  • Pokud objevitel žádný časový rámec neurčí, použijte jeden pracovní den, protože to je průmyslový standard a současný osvědčený postup v oboru.

  • Pokud objevitel klade otázky, odpovězte na ně. To je obzvlášť důležité, pokud objevitel žádá o povolení k testování. Zajistěte, aby všechny odpovědi byly jasné a přímé.

Odpovídejte objeviteli prostřednictvím oprávněného bezpečnostního kontaktu a/nebo oprávněného bezpečnostního procesu.

  • Dobře: odpověď z bezpečnostní e-mailové adresy, například „security@example.com".

  • Například tyto jsou špatně: odpověď z univerzální e-mailové adresy, například „help@example.com", nebo od někoho, kdo není oprávněným bezpečnostním odborníkem.

Sdělte objeviteli, že problém je uznán jako bezpečnostní hlášení.

  • Dobře: formulace specifické pro bezpečnost, například „Náš bezpečnostní tým obdržel vaše hlášení odpovědného zveřejnění", nebo „Náš bezpečnostní proces má tyto další kroky", nebo „Vaše informace jsou nyní v našem bezpečnostním trackeru pod číslem XYZ" atd.

  • Špatně: obecné formulace, například „Vážíme si vaší přízně", nebo „Bereme bezpečnost vážně", formulace přehazující odpovědnost, například „Váš e-mail jsme předali jinému oddělení" atd.

Krok 3: Pracujte v dobré víře

Krok 3 patří objeviteli a výrobci společně: pracujte v dobré víře.

Pochopte, že koordinované zveřejňování zranitelností popisuje proces v dobré víře.

  • Cíl č. 1 je dobrá víra při pomoci uživatelům chránit se před bezpečnostními riziky.

  • Cíl č. 2 je dobrá víra při řešení bezpečnostního problému.

  • Objevitel a/nebo výrobce se mohou v dobré víře rozhodnout zapojit další bezpečnostní odborníky, například kontaktovat další příslušné bezpečnostní výzkumníky, aby s problémem pomohli.

Pochopte, že koordinované zveřejňování zranitelností nevytváří žádné závazky.

  • Objevitel a/nebo výrobce mohou kdykoli, z jakéhokoli důvodu, s upozorněním nebo bez něj, ukončit účast. Je zdvořilé informovat všechny relevantní osoby a udržovat je v obraze, ale není to vždy možné, praktické ani žádoucí.

  • Koordinované zveřejňování zranitelností nevytváří žádnou právní dohodu. Pokud již objevitel a výrobce mají právní dohodu, doporučujeme, aby všichni zúčastnění konzultovali příslušné právníky; nepoužívejte tento dokument jako právní poradenství.

Pochopte, že koordinované zveřejňování zranitelností usiluje o dobrou komunikaci a odmítá hrozby.

  • Koordinované zveřejňování zranitelností je nejlepší, když všichni zúčastnění chápou, že cíl č. 1 je pomoci uživatelům chránit se před bezpečnostními riziky a cíl č. 2 je řešit bezpečnostní problém.

  • Koordinované zveřejňování zranitelností odmítá jakýkoli druh hrozeb odvetou, zastrašováním, pozastavením, odebráním, vydíráním, břemenem následného jednání nebo obviňováním oběti.

Pochopte, že koordinované zveřejňování zranitelností může pro různé lidi znamenat různé věci.

  • Objevitel a výrobce mohou mít odlišné chápání koordinovaného zveřejňování zranitelností. Tato chápání se nemusejí shodovat. Dobrá víra zahrnuje, že to všichni zúčastnění chápou.

  • Někteří výrobci zveřejňují zásady koordinovaného zveřejňování zranitelností. Ty mohou být užitečným vodítkem. Pokud se objevitel rozhodne použít jiný druh koordinovaného zveřejňování zranitelností nebo má jiné chápání odpovědného zveřejňování, je to naprosto v pořádku.

Pochopte, že obvykle objevitel dělá vydavateli laskavost.

  • Objevitel obvykle nepotřebuje ničí svolení ke zveřejnění zranitelností.

  • Informace objevitele obvykle vydavateli pomáhají.

Ověřte úspěch

Poté, co je problém vyřešen, musí výrobce ověřit úspěch.

  • Zvládli všichni lidé a procesy zveřejnění úspěšně? Pokud ano, dobře. Pokud ne, zvažte provedení analýzy po události, například analýzy kořenové příčiny (RCA), post-mortem zpráv, Ishikawových diagramů nebo kauzální analýzy založené na teorii systémů (CAST).

  • Jsou případné nevyřešené problémy roztříděny (triage) a sledovány?

  • Chápou výrobce i objevitel, co dělat v dalších krocích? To je obzvlášť důležité udělat správně pro případ možných navazujících koordinovaných zveřejnění zranitelností.

Doporučení

Doporučení pro koordinované zveřejňování zranitelností mohou pocházet z mnoha oblastí, například od odborníků na etiku, právních zastánců, z rozumných očekávání široké veřejnosti atd.

Pokud hledáte doporučení, mohou vás zajímat tyto tři oblasti, všechny popsané níže.

  • Milosrdný Samaritán

  • Povinnost zachránit

  • Povinnost péče

Milosrdný Samaritán

Wikipedia: Good Samaritan law

Zákony o milosrdném Samaritánovi nabízejí právní ochranu lidem, kteří poskytnou přiměřenou pomoc těm, kdo jsou, nebo o kom se domnívají, že jsou, zranění, nemocní, v ohrožení nebo jinak nezpůsobilí. Ochrana má snížit váhání přihlížejících pomoci ze strachu před žalobou nebo stíháním.

Povinnost zachránit

Wikipedia: Duty to rescue

Povinnost zachránit je pojem popisující okolnost, kdy lze stranu činit odpovědnou za to, že nepřispěchala na pomoc jiné straně v nebezpečí. Povinnost zachránit může mít morální a/nebo právní stránky.

Povinnost péče

Wikipedia: Duty of care

Povinnost péče je závazek dodržovat standard přiměřené péče při provádění jakýchkoli jednání, která by mohla předvídatelně poškodit ostatní. Povinnost péče může mít morální a/nebo právní stránky. Některé aspekty ke zvážení jsou: předvídatelnost újmy nebo zranění, možný rozsah potenciální újmy nebo zranění, význam nebo společenská hodnota činnosti, které se žalovaný věnuje, užitečnost jednání pro žalovaného, proveditelnost alternativního jednání, náklady a zátěž spojené s alternativním jednáním, relativní užitečnost alternativního jednání a relativní bezpečnost alternativního jednání.

Zvláštní případy

Naše bezpečnostní týmy viděly širokou škálu zvláštních případů.

Popisujeme je zde, abychom lidem pomohli pochopit, kde existuje široká škála názorů na to, co může být v pořádku a co nemusí. Doporučujeme, aby všichni zúčastnění o těchto věcech komunikovali v dobré víře.

Přístup k informacím jiných uživatelů

Příklad: zjistíte, že URL obsahuje vaše uživatelské ID, odhaluje chybu a věříte, že můžete URL upravit a změnit své uživatelské ID na jiné uživatelské ID.

  • Je v pořádku, aby to objevitel udělal, například s jediným cílem zjistit, zda se to týká i jiných uživatelů?

  • Je důležitější rychle pochopit rozsah rizika pro všechny uživatele, než chránit pár uživatelů, jejichž informace již mohou být hackerům viditelné?

  • Je v pořádku, aby to objevitel udělal s tolika uživateli, kolik chcete?

  • Je v pořádku, aby se objevitel pokusil kontaktovat uživatele a dát jim vědět, že jsou postiženi? Je v pořádku nabídnout návrhy na zmírnění?

Odepření služby

Příklad: objevíte chybu, která omylem pozastaví váš účet, například spustí zámek hesla.

  • Je to považováno za útok odepření služby?

Nevyžádaný e-mail

Příklad: pokusíte se nahlásit bezpečnostní problém lidem ve společnosti, o kterých si myslíte, že jsou relevantní a které zjistíte rešerší na LinkedIn, Facebooku atd. nebo pomocí konvencí pojmenování, jako je „webmaster@example.com" nebo „security@example.com".

  • Je to v pořádku?

  • Je to považováno za nevyžádaný e-mail?

  • Je to považováno za neoprávněný e-mail?

Vyloučené skupiny

Příklad: patříte do vyloučené skupiny, například jste nezletilý, nebo jste na sankčním seznamu, nebo jste v zemi na sankčním seznamu.

  • Je v pořádku, abyste podali hlášení?

  • Je v pořádku hlásit anonymně?

  • Je v pořádku záměrně změnit potenciálně identifikující informace, například abyste unikli z vyloučené skupiny, s cílem pomoci zveřejnění dostat se ke správným lidem?

Třetí strana

Příklad: objevíte, že software společnosti má chybu týkající se třetí strany, například integrace s jiným softwarem nebo jiným webem.

  • Je v pořádku, abyste nahlásili všechny nalezené informace oběma stranám?

  • Je nutné provést dvě různá odpovědná zveřejnění, například jedno hlášení jedné společnosti a jiné hlášení společnosti třetí strany, s cílem omezit informace zaslané každé společnosti?

  • Je v pořádku, aby objevitel dal společnosti do vzájemného kontaktu?

Rušivý software

Příklad: jste natolik zruční, že dokážete napsat virus, o kterém se domníváte, že pravděpodobně pomůže uživatelům chránit se před bezpečnostním rizikem, zjistit, zda jsou ohroženi, nebo bezpečnostní riziko opravit.

  • Je to v pořádku?

  • Je v pořádku, aby objevitel nasměroval uživatele na software tohoto druhu a/nebo na návody či tutoriály popisující, jak tento druh softwaru vytvořit?

Koordinované zveřejňování zranitelností vs. odpovědné zveřejňování

Koordinované zveřejňování zranitelností je upřednostňovaný pojem.

  • Nejdůležitějším aspektem je koordinace mezi objevitelem a výrobcem.

Odpovědné zveřejňování (responsible disclosure) je zastaralý pojem.

  • Lidé mají různé názory na to, co znamená být odpovědný. Například někteří lidé zastávají názor, že je odpovědné, aby objevitel okamžitě informoval veřejnost bez ohledu na jakoukoli interakci s výrobcem, a neodpovědné provádět koordinované zveřejňování zranitelností, protože skrývá informace před veřejností.

Sledování