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
Külső hivatkozások Full Disclosure Text Files from r00tsecurity.org (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
Kategória:Informatikai biztonság