Coordinated vulnerability disclosure

Koordinált sebezhetőség-közzététel (CVD)

Hogyan jelentsünk, fogadjunk és koordináljunk biztonsági sebezhetőségeket, példa szabályzatokkal.

A koordinált sebezhetőség-közzététel (Coordinated vulnerability disclosure, CVD) a számítógép-biztonság egyik fogalma. Azt írja le, hogyan oszthatnak meg az emberek jelentéseket biztonsági problémákról. Példák: hibajelentések, behatolási kockázatok, hackerfigyelmeztetések, adatszivárgások, weboldalak feltörései stb.

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

Tartalom:

Szabályzatok:

Bevezetés

Ez a dokumentum a koordinált sebezhetőség-közzétételt olyan módon magyarázza el, amely segítheti az embereket az együttműködésben.

A dokumentum céljai:

  1. Segíteni azokat, akik biztonsági problémákat fedeznek fel, és jelenteni szeretnék azokat.

  2. Segíteni a vállalatok képviselőit megérteni a felelős közzététel igényeit, céljait, gyakorlatait és különleges eseteit.

  3. A tárház mappájába példa koordinált sebezhetőség-közzétételi szabályzatokat felvenni.

Szívesen fogadunk pull requesteket, GitHub issue-kat vagy e-mailt a security@joelparkerhenderson.com címre.

Mi az a koordinált sebezhetőség-közzététel?

A koordinált sebezhetőség-közzététel három lépést ír le, amikor valaki biztonsági problémát (például szoftverhibát) fedez fel, és jelenteni szeretné a gyártónak (például a szoftvert készítő vállalatnak).

Lépések:

  1. A felfedező privátan és jóhiszeműen jelenti a problémát a gyártónak.

  2. A gyártó jóhiszeműen igyekszik megvédeni a felhasználókat, és foglalkozik a problémával.

  3. Meghatározott idő elteltével a biztonsági problémát nyilvánosságra hozzák.

1. lépés: Jelentse a problémát

Az 1. lépés a felfedezőé: jelentse a problémát privátan és jóhiszeműen.

  • Jó: a felfedező elküldi a vonatkozó információkat a gyártónak, például e-mailben a gyártó biztonsági e-mail-címére (jellemzően „security@example.com"), vagy a gyártó webhelyén lévő webes űrlapon keresztül (jellemzően „https://www.example.com/security").

  • Rossz: a jelentés közzététele nyilvános blogon, a média riasztása, fenyegetés, vagy a biztonsági probléma eladására tett kísérlet hackereknek stb.

  • Tipp: a felfedező dönthet úgy, hogy névtelen marad; a gyártó is dönthet úgy, hogy névtelen marad.

Ha akarja, továbbra is maradjon tisztában a problémával.

  • Jó: kommunikációs csatornák megnyitása, nyomonkövetési információk nyújtása vagy a helyzet figyelése.

  • Rossz: megfeledkezni a problémáról.

  • Tipp: a felfedező dönthet úgy, hogy segít vagy nem, és úgy is, hogy kapcsolatban marad vagy nem, valamint megváltoztathatja a megállapodást, ha a körülmények változnak.

Ha akarja, hozza nyilvánosságra a problémát mások előtt.

  • Jó: a megadott idő kivárása, majd nyilvánosságra hozás, például a vonatkozó információk közzététele biztonsági hírportálon, vagy a releváns külső biztonsági kutatók felkeresése, vagy a probléma bejelentése bármely nyilvános közösségi oldalon stb.

  • Rossz: a probléma mások előtti nyilvánosságra nem hozatala, kivéve ha úgy érzi, hogy ez az összehasonlíthatónál nagyobb kockázatot jelentene Önre vagy másokra nézve.

  • Tipp: ha a körülmények változnak, például magasabb kockázatot vagy aktív kihasználást fedeznek fel a vadonban (in the wild), a felfedező korábban nyilvánosságra hozhatja a problémát mások előtt.

2. lépés: Biztosítsa az elérhetőségeket

A 2. lépés a gyártóé: gondoskodjon arról, hogy az elérhetőségek használhatók legyenek.

  • Jó: a gyártó közzétesz egy biztonsági kapcsolattartási e-mail-címet (hagyományosan „security@example.com"), és ideális esetben egy biztonságos e-mail-titkosítási kulcsot.

  • Jó: a gyártó közzétesz egy biztonsági kapcsolattartási weboldalt (hagyományosan „https://www.example.com/security"), és ideális esetben könnyen megtalálhatóvá teszi, például a weboldal láblécén, webhelytérképén és keresőjén keresztül.

  • Rossz: a gyártó nem biztosít e-mail-címet vagy weboldalt, vagy nem teszi azokat könnyen megtalálhatóvá.

Biztosítsa a személyzet képességeit.

  • Jó: a gyártó betanítja a támogatási személyzetet, mit tegyen, ha biztonsági megkeresést kap, például hogyan válaszoljon elérhetőségi adatokkal, vagy hogyan továbbítsa a megkeresést a megfelelő belső csapatnak.

  • Jó: a gyártó rendszeresen ellenőrzi, hogy a személyzet képességei működnek-e.

  • Rossz: a gyártó nem képez vagy nem ellenőriz.

Válaszoljon a felfedezőnek az ütemezésen belül.

  • Ha a felfedező nem ad meg ütemezést, használjon egy munkanapot, mert ez az iparági szabvány és a jelenlegi iparági legjobb gyakorlat.

  • Ha a felfedező kérdéseket tesz fel, válaszoljon rájuk. Ez különösen fontos, ha a felfedező engedélyt kér a teszteléshez. Gondoskodjon arról, hogy minden válasz világos és közvetlen legyen.

Válaszoljon a felfedezőnek egy jogosult biztonsági kapcsolattartón és/vagy jogosult biztonsági folyamaton keresztül.

  • Jó: válasz egy kifejezetten biztonsági e-mail-címről, például „security@example.com".

  • Például ezek rosszak: válasz egy általános célú e-mail-címről, például „help@example.com", vagy bárkitől, aki nem jogosult biztonsági szakember.

Jelezze a felfedezőnek, hogy a problémát biztonsági jelentésként ismerték el.

  • Jó: biztonság-specifikus megfogalmazás, például „Biztonsági csapatunk megkapta az Ön felelős közzétételi jelentését", vagy „Biztonsági folyamatunk következő lépései a következők", vagy „Az Ön információi most XYZ azonosítószámmal szerepelnek biztonsági követőnkben" stb.

  • Rossz: általános megfogalmazás, például „Nagyra értékeljük az Ön üzletét", vagy „Komolyan vesszük a biztonságot", felelősséget áthárító megfogalmazás, például „Továbbítottuk az Ön e-mailjét egy másik osztálynak" stb.

3. lépés: Dolgozzon jóhiszeműen

A 3. lépés a felfedezőé és a gyártóé együtt: dolgozzanak jóhiszeműen.

Értse meg, hogy a koordinált sebezhetőség-közzététel jóhiszemű folyamatot ír le.

  • Az 1. számú cél a jóhiszeműség abban, hogy segítsen a felhasználóknak megvédeni magukat a biztonsági kockázatoktól.

  • A 2. számú cél a jóhiszeműség a biztonsági probléma kezelésében.

  • A felfedező és/vagy a gyártó jóhiszeműen dönthet úgy, hogy más biztonsági szakembereket von be, például más releváns biztonsági kutatókhoz fordul segítségért a problémával kapcsolatban.

Értse meg, hogy a koordinált sebezhetőség-közzététel nem hoz létre semmilyen kötelezettséget.

  • A felfedező és/vagy a gyártó bármikor, bármilyen okból, figyelmeztetéssel vagy anélkül kiléphet. Udvarias dolog az összes érintettet tájékoztatni és naprakészen tartani, de ez nem mindig lehetséges, praktikus vagy kívánatos.

  • A koordinált sebezhetőség-közzététel nem hoz létre jogi megállapodást. Ha a felfedezőnek és a gyártónak már van jogi megállapodása, javasoljuk, hogy minden érintett forduljon megfelelő ügyvédekhez; ne használja ezt a dokumentumot jogi tanácsként.

Értse meg, hogy a koordinált sebezhetőség-közzététel a jó kommunikáció használatára törekszik, és elutasítja a fenyegetéseket.

  • A koordinált sebezhetőség-közzététel akkor a legjobb, ha minden érintett megérti, hogy az 1. számú cél a felhasználók segítése abban, hogy megvédjék magukat a biztonsági kockázatoktól, a 2. számú cél pedig a biztonsági probléma kezelése.

  • A koordinált sebezhetőség-közzététel elutasít mindenféle megtorlással, megfélemlítéssel, felfüggesztéssel, visszavonással, zsarolással, utánkövetési teherrel vagy az áldozat hibáztatásával való fenyegetést.

Értse meg, hogy a koordinált sebezhetőség-közzététel különböző embereknek különböző dolgokat jelenthet.

  • A felfedező és a gyártó eltérően érthetik a koordinált sebezhetőség-közzétételt. Ezek az értelmezések nem feltétlenül egyeznek meg egymással. A jóhiszeműséghez hozzátartozik, hogy minden érintett ezt megérti.

  • Néhány gyártó koordinált sebezhetőség-közzétételi szabályzatokat tesz közzé. Ezek hasznos útmutatást jelenthetnek. Ha a felfedező a koordinált sebezhetőség-közzététel egy másik fajtáját választja, vagy másképp érti a felelős közzétételt, az teljesen rendben van.

Értse meg, hogy jellemzően a felfedező szívességet tesz a kiadónak.

  • Jellemzően a felfedezőnek senki engedélyére nincs szüksége a sebezhetőségek közzétételéhez.

  • Jellemzően a felfedező információi segítik a kiadót.

Ellenőrizze a sikert

A probléma megoldása után a gyártónak ellenőriznie kell a sikert.

  • Sikeresen kezelte-e a közzétételt minden ember és folyamat? Ha igen, jó. Ha nem, fontolja meg utólagos kutatás végzését, például gyökérok-elemzést (RCA), utólagos jelentéseket (post-mortem), Ishikawa-diagramokat vagy rendszerelméleten alapuló okozati elemzést (CAST).

  • Besorolták-e (triage) és nyomon követik-e a fennmaradó problémákat?

  • Érti-e a gyártó és a felfedező is, mit kell tenni az esetleges következő lépésekhez? Ezt különösen fontos jól megoldani arra az esetre, ha további koordinált sebezhetőség-közzétételek következnének.

Útmutatás

A koordinált sebezhetőség-közzétételhez kapcsolódó útmutatás számos területről érkezhet, például etikai szakértőktől, jogi érdekvédőktől, a nagyközönség ésszerű elvárásaiból stb.

Ha útmutatást keres, érdekelheti Önt ez a három terület, amelyeket alább ismertetünk.

  • Irgalmas szamaritánus

  • Mentési kötelezettség

  • Gondossági kötelezettség

Irgalmas szamaritánus

Wikipedia: Good Samaritan law

Az irgalmas szamaritánus törvények jogi védelmet nyújtanak azoknak, akik ésszerű segítséget nyújtanak olyanoknak, akik megsérültek, megbetegedtek, veszélyben vannak vagy más módon cselekvőképtelenek, vagy akikről azt hiszik, hogy ilyenek. A védelem célja, hogy csökkentse a szemlélők tétovázását a segítségnyújtásban, a perelve vagy üldözve levéstől való félelem miatt.

Mentési kötelezettség

Wikipedia: Duty to rescue

A mentési kötelezettség olyan fogalom, amely olyan körülményt ír le, amelyben egy fél felelőssé tehető azért, mert nem sietett egy veszélyben lévő másik fél segítségére. A mentési kötelezettségnek erkölcsi és/vagy jogi vonatkozásai lehetnek.

Gondossági kötelezettség

Wikipedia: Duty of care

A gondossági kötelezettség az ésszerű gondosság színvonalának betartására vonatkozó kötelezettség minden olyan cselekmény végzésekor, amely előreláthatóan kárt okozhat másoknak. A gondossági kötelezettségnek erkölcsi és/vagy jogi vonatkozásai lehetnek. Néhány megfontolandó szempont: a kár vagy sérülés előreláthatósága, a lehetséges kár vagy sérülés valószínű mértéke, az alperes által folytatott tevékenység fontossága vagy társadalmi értéke, a magatartás hasznossága az alperes számára, az alternatív magatartás megvalósíthatósága, az alternatív magatartással járó költségek és terhek, az alternatív magatartás relatív hasznossága és az alternatív magatartás relatív biztonsága.

Különleges esetek

Biztonsági csapataink a különleges esetek széles körét látták.

Itt azért írjuk le őket, hogy segítsünk az embereknek megérteni, hol vannak széles körben eltérő vélemények arról, hogy mi lehet rendben és mi nem. Javasoljuk, hogy minden érintett jóhiszeműen kommunikáljon ezekről.

Más felhasználók adataihoz való hozzáférés

Példa: felfedezi, hogy egy URL tartalmazza az Ön felhasználói azonosítóját, és hibát tár fel, és úgy hiszi, hogy az URL szerkesztésével megváltoztathatja a felhasználói azonosítóját egy másik felhasználói azonosítóra.

  • Rendben van-e, hogy a felfedező ezt megtegye, például azzal az egyetlen céllal, hogy kiderítse, érint-e más felhasználókat is?

  • Fontosabb-e gyorsan megérteni a kockázat kiterjedését az összes felhasználóra nézve, mint megvédeni néhány felhasználót, akiknek az információi esetleg már láthatók a hackerek számára?

  • Rendben van-e, hogy a felfedező ezt annyi felhasználóval megtegye, amennyit csak akar?

  • Rendben van-e, hogy a felfedező megpróbálja felvenni a kapcsolatot a felhasználókkal, hogy tudassa velük, hogy érintettek? Rendben van-e mérséklési javaslatokat ajánlani?

Szolgáltatásmegtagadás

Példa: felfedez egy hibát, amely véletlenül felfüggeszti a fiókját, például jelszózárat vált ki.

  • Szolgáltatásmegtagadásos támadásnak minősül ez?

Kéretlen e-mail

Példa: megpróbál biztonsági problémát jelenteni a vállalat azon embereinek, akiket relevánsnak tart, és akiket a LinkedIn, a Facebook stb. kutatásával, vagy „webmaster@example.com" vagy „security@example.com" típusú elnevezési konvenciók használatával talál meg.

  • Rendben van ez?

  • Kéretlen e-mailnek minősül ez?

  • Jogosulatlan e-mailnek minősül ez?

Kizárt csoportok

Példa: kizárt csoportba tartozik, például kiskorú, vagy szankciós listán van, vagy olyan országban van, amely szankciós listán szerepel.

  • Rendben van-e, hogy jelentést tegyen?

  • Rendben van-e névtelenül jelenteni?

  • Rendben van-e szándékosan megváltoztatni az esetleg azonosító információkat, például hogy megszökjön a kizárt csoportból, azzal a céllal, hogy segítsen a közzétételnek eljutni a megfelelő emberekhez?

Harmadik fél

Példa: felfedezi, hogy egy vállalat szoftverében van egy hiba, amely harmadik felet érint, például egy másik szoftverrel vagy egy másik weboldallal való integrációt.

  • Rendben van-e, hogy az összes talált információt mindkét félnek jelentse?

  • Szükséges-e két különböző felelős közzétételt végezni, például egy jelentést az egyik vállalatnak és egy másik jelentést a harmadik fél vállalatának, azzal a céllal, hogy korlátozza az egyes vállalatoknak küldött információkat?

  • Rendben van-e, hogy a felfedező összehozza a vállalatokat egymással?

Zavaró szoftver

Példa: elég ügyes ahhoz, hogy írjon egy vírust, amelyről úgy hiszi, hogy valószínűleg segít a felhasználóknak megvédeni magukat a biztonsági kockázattól, vagy megállapítani, hogy veszélyben vannak-e, vagy kijavítani a biztonsági kockázatot.

  • Rendben van ez?

  • Rendben van-e, hogy a felfedező ilyen szoftverre és/vagy az ilyen típusú szoftver létrehozását leíró útmutatókra vagy oktatóanyagokra irányítja a felhasználókat?

Koordinált sebezhetőség-közzététel és felelős közzététel

A koordinált sebezhetőség-közzététel az előnyben részesített kifejezés.

  • A legfontosabb szempont a felfedező és a gyártó közötti koordináció.

A felelős közzététel (responsible disclosure) elavult kifejezés.

  • Az embereknek különböző nézeteik vannak arról, mit jelent felelősnek lenni. Például egyesek azt vallják, hogy felelős dolog, ha a felfedező azonnal értesíti a nyilvánosságot a gyártóval való bármilyen interakciótól függetlenül, és felelőtlen dolog koordinált sebezhetőség-közzétételt végezni, mert az elrejti az információt a nyilvánosság elől.

Nyomon követés