A San Franciscóban február 25. és március 1. között rendezett RSA konferencián zajlott le az a pódiumbeszélgetés, amelye a szoftverek biztonsági réseiről és a cégek hibajavítási stratégiájáról folyatott Brad Arkin, az Adobe biztonsági igazgatója, valamint John Viega, a SilverSky elnöke, aki korábban a McAfee-nél dolgozott fejlesztőként és kutatóként. A beszélgetés – amelyhez a prezentációt az alábbi linkről lehet letölteni pdf formátumban – a megelőzés vagy utólagos foltozás kérdéskörét járta körül. A beszélgetésről a Biztonságportál készített összefoglalót.

A teljes életciklust nyomon kell követni ■ Brad Arkin kifejtette, hogy az Adobe – hasonlóan, ahogy például a Microsoft is – a teljes szoftverfejlesztési életciklust lefedő biztonság mellett tette le a voksát. Ennek megfelelően sok időt és pénzt is áldoznak a biztonságos fejlesztésre. Arkin egyébként úgy véli, költségesebb is volna, ha csak utólagosan, a felhasználók által jelzett hibákat javítanák (hogy miért költségesebb, az persze homályban marad). Ezért az alkalmazásbiztonsági szempontokat a koncepció kialakításakor, a tervezés során, a kódolásban, a tesztelésben és a bevezetéskor is hangsúlyozottan veszik figyelembe.




"Egy Readerhez vagy Flash Playerhez megjelenő exploit kód több mint egymilliárd számítógépet veszélyeztethet. Ezek frissítési költsége összességében óriási. Ezért nekünk mindent meg kell tennünk annak érdekében, hogy a problémákat még a szoftverek kiadása előtt orvosoljuk" – mondta Arkin.

A szép elvek és a piac ■ John Viega szerint az Arkin által felvázolt megközelítés nem minden esetben kifizetődő a fejlesztőcégeknek. A legtöbb cég számára jóval olcsóbb, ha csak akkor reagálnak, ha már történt valami, magyarán a piac utólag kényszeríti ki a biztonsági intézkedéseket.

Tételezzük fel – érvel Viega –, hogy évente három hiba javítása összességében (a fejlesztési, a tesztelési és kommunikációs költségekkel együtt) 50 ezer dollárba kerül. Nem kis pénz. Ám egy átfogó szoftverbiztonsági program kidolgozása akár több millió dollárt is felemészthet. És akkor még nem is számoltunk a program járulékos költségeivel, például azzal, hogy az intézkedések következtében csökken a termelékenység.

Viega végül is úgy látja – hogy ne legyen ennyire sötét a kép –, hogy a nagy szoftverfejlesztő vállalatok akár hasznot is húzhatnak abból, ha a biztonság szempontjait a fejlesztési folyamatokba integrálják. A kisebb fejlesztő cégekbek azonban nem éri meg ezt az utat követni. Míg „a Microsoft és az Adobe számára komoly előnyökkel jár az SDL-alapú (Software Development Lifecycle) megközelítés, tucatnyi olyan céget ismerek, amelyek megvizsgálták az SDL-t, és azt mondták: viccel? Ez kiütne minket a piacról” – summázta véleményét a SilverSky elnöke.

Az Adobe sem javít mindent ■ Ha a beszélgetésben nem is hangzott el egyértelműen, Arkin szavaiból kiolvasható volt, hogy bár az Adobe-nál tényleg sokat költenek a sebezhetőségek korai feltárására és megszüntetésére, a cél egyáltalán nem az, hogy minden egyes biztonsági rést befoltozzanak. Az ezzel foglalkozó csapat egyik fontos feladata, hogy felderítse a rés veszélyességi fokát, és eszerint döntenek arról, javítják, vagy elfelejtik.


A leggondosabb felderítés sem képes minden veszélyes hibát feltárni. Amint azt az elmúlt hetek történései is igazolták, a megjelenő kódokban is maradnak kritikus veszélyességű hibák. Ezek lehetőségét azonban semmilyen módszerrel nem lehet 100 százalékosan kizárni. Arkin szerint azonban sokat számít, ha egy cég hangsúlyt fektet a fejlesztők biztonsági oktatására.

Nem kellenek törvények ■ Viega és Arkin egy dologban egyetértett: a szoftverbiztonsági kérdéseket nem szabad törvényi szinten szabályozni. Az ok egyszerű: mire egy jogszabály megszületne, addigra elavulttá is válna. És különben is: ne a kormányok fogalmazzák meg, hogy miként kell fellépni például a puffertúlcsordulási hibák ellen.