Teljes közzététel

Az informatikai biztonság területén a teljes közzététel (angolul full disclosure) a biztonsági résekről szóló információk azonnali és teljes körű közzétételének gyakorlata. A biztonsági adminisztráció területén elterjedt másik, a teljes közzététellel teljesen ellentétes filozófiájú elgondolás neve bizonytalanságon alapuló biztonság (security through obscurity). A teljes közzététel gyakorlata vitatott, de nem új keletű; már a 19. század óta probléma a (zár)lakatosok számára.

Definíció

A teljes közzététel megköveteli, hogy a biztonsági réssel (sebezhetőséggel) kapcsolatos információk minden részletét nyilvánosságra hozzák, beleértve azt is, hogyan lehet felderíteni vagy kiaknázni azt. A full disclosure filozófiája szerint ezen információk közkinccsé tétele gyorsabb javításokat, végső soron jobb biztonságot eredményez. A gyorsabb javítások oka, hogy a gyártók/a program írója rákényszerül a hiba kijavítására, hogy megvédje a rendszereit a támadásoktól, és hogy a hírnevén esett csorbát kiköszörülje. A biztonsági helyzet javul, mivel a sebezhetőségi ablak lerövidül.

A számítógépes biztonsági rések világában a közzététel gyakran levelezési listákon (pl. Full Disclosure) történik.

Különböző interpretációk

Még a közzététel szükségességével különben egyetértők között is vita van arról, hogy mikor, kinek és mennyi információt kell közzétenni.

Vannak, akik úgy gondolják, hogy ha egy problémához még nem létezik nyilvános exploit, a „teljes és nyilvános közzétételt” meg kellene előznie a gyártó/a program írója értesítésének. Ez a privát értesítés ad némi időt a gyártó számára, hogy elkészítse a hibajavítást vagy megkerülő megoldást (workaround), tesztelje azt stb. Ezt a filozófiát szokás felelős közzétételnek (responsible disclosure) hívni.

Ha a gyártó figyelmét felhívták a problémára, és megfelelő időn belül nem készített hozzá javítást, általában a nyilvános közzététel következik. A „megfelelő idő” hosszúságával kapcsolatosan megoszlanak a nézetek. 14-30 nap tipikusnak mondható, bár egyes esetekben ez csak órákat jelent. Az Internet Security Systemst széles körben kritizálták azért, mert az Apache HTTP Server egy biztonsági résének javítására kevesebb mint 8 órát hagyott a részletek közzététele előtt.

A korlátozott közzététel (limited disclosure) megközelítés szerint a fejlesztők és gyártók egy szűk közössége számára kell elküldeni a részleteket, a nyilvánossággal elég a probléma puszta létezését tudatni. Ennek a megközelítésnek a hívei is igényt tartanak a „felelős közzététel” elnevezésre.

Természetesen vannak jogos aggályok a potenciálisan veszélyes információk megosztásával kapcsolatban, főleg az internet széles közössége számára (benne a black-hat hackerekkel). Az ismert biztonsági szakértő, Rain Forest Puppy ezért megalkotta az RFPolicy irányelvet, ami megpróbálja meghatározni a megfelelő módot a gyártók értesítésére, és arra is tartalmaz javaslatokat, hogy mit kell tenni, ha a gyártó nem reagál.

A felelős közzététel egyik kihívása, hogy egyes gyártók nem válaszolnak a megkeresésre, vagy szükségtelenül késleltetik a válaszadást, ha a sebezhetőség részletei nem nyilvánosak. Ha a biztonsági rés nem nyilvános (annyira részletekbe menően, hogy abból exploitot lehessen készíteni), a gyártók megtagadhatják a javítás elkészítését, vagy csak alacsony prioritást adnak a feladatnak. Sajnos előfordulhat, hogy mire a gyártó felé jelentik a biztonsági rést, addigra a hackerek már aktívan kiaknázzák, vagy hamarosan valaki felfedezi és exploitot készít hozzá. Ezért a legtöbb biztonsági szakértő meghatároz egy időtartamot (pl. 14 nap vagy 30 nap), aminek eltelte után nyilvánosságra hozza a sebezhetőség minden részletét, különben sok gyártó még a termékében lévő kritikus biztonsági réseket se foltozná be. Sok biztonsági szakértő éppen a gyártók múltbeli nemtörődömségére hivatkozva döntött a teljes közzététel gyakorlata mellett.

A Full Disclosure levelezőlista

A Secunia által üzemeltetett Full Disclosure levelezőlistát sokan radikális megoldásnak tartják, főleg azok, akik nem ismerik az informatikai biztonsági szakértők közösségének működését; valójában ez kulcsfontosságú része a közösség infrastruktúrájának, mint az egyetlen jelentős biztonsági kérdésekkel foglalkozó lista, amit nem moderál valamilyen (hátsó szándékokkal bíró) iparági szereplő.

Bár a Secunia sokszor nem ért egyet a Full Disclosure listán elhangzottakkal, vagy az ott zajló, néha felelőtlen közzététellel, sohasem próbál közbeavatkozni. Valójában erre nincs is módja, mivel a listát egy személyben John Cartwright üzemelteti, aki azóta aktív listagazda, hogy 2002-ben Len Rose-zal együtt megalapították a listát az akkor elterjedt moderált és részrehajló levelezőlisták alternatívájaként.

Érvek pro és kontra

A teljes közzététel gyakorlatát sokan vitatják, mivel a biztonsági résről közzétett információk gyakran kódot, vagy a hiba kiaknázására alkalmas futtatható eszközöket is tartalmaznak. A közzététel ellen érvelők szerint azzal, hogy a hiba teljes leírását és eszközöket adnak ártó szándékú támadók, pl. black-hat hackerek és script kiddie-k kezébe, felgyorsítják, szélesebb körűvé teszik a biztonsági rés kiaknázását. Ez az érvelés azonban feltételezi, hogy a közzététel nélkül a támadások nem történnének meg, az eszközöket nem hoznák létre. A közzététel előnye az, hogy a white-hat hackerekhez eljut az információ, így a sebezhetőséget gyorsabban fel tudják deríteni, be tudják foltozni.

Fordítás

Ez a szócikk részben vagy egészben a Full disclosure című angol Wikipédia-szócikk ezen változatának fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel. Ez a jelzés csupán a megfogalmazás eredetét és a szerzői jogokat jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.

Külső hivatkozások

• Full Disclosure Text Files from r00tsecurity.org Archiválva 2010. március 9-i dátummal a Wayback Machine-ben (complete list updated daily)
• Full Disclosure Debate Bibliography, by date
• Full Disclosure and the Window of Exposure, Bruce Schneier Crypto-Gram hírleveléből, 2000. szeptember
• Full Disclosure from Bruce Schneier's Crypto-Gram, November 2001
• Publicizing Vulnerabilities, Bruce Schneier Crypto-Gram hírleveléből, 2000. február 15.
• Full-Disclosure levelezőlista
• Full-Disclosure levelezőlista szabályai
• Matt Blaze, Is it harmful to discuss security vulnerabilities?, downloaded October 2005.
• Matt Mecham: Why full disclosure is bad
• A history of the CERT Advisory CA-93:15 case, which spawned the movement in the first place