Mikor javítsuk ki a szoftverek biztonsági hibáit?

Két neves biztonsági szakértő között parázs vita alakult ki a szoftverek biztonsági réseinek betöméséről. A beszélgetésük igen elgondolkodtató.
 

Az RSA konferencia számos biztonsági témát érintett, amelyek között természetesen a szoftveres sebezhetőségek kezelése is szerepet kapott. Ez persze nem meglepő, hiszen rengeteg incidens bekövetkezéséhez járulnak hozzá biztonsági rések. Ebben a témában az egyik érdekes vitát Brad Arkin, az Adobe biztonsági igazgatója valamint John Viega, a SilverSky elnöke, a McAfee korábbi fejlesztője és kutatója folytatta. A két szakember beszélgetése elsősorban arról szólt, hogy a fejlesztőcégeknek a sérülékenységek megelőzésére vagy azok utólagos megszüntetésére kell-e koncentrálniuk.

Brad Arkin elmondta, hogy az Adobe - hasonlóan, ahogy például a Microsoft is - elkötelezett a teljes szoftverfejlesztési életciklust lefedő biztonság mellett. Annak érdekében, hogy ez a mindennapokban is megnyilvánulhasson sok időt és pénzt áldoznak a biztonságos fejlesztésre. Az Adobe számára az költségesebb volna, hogy csak arra várna, hogy valaki jelez egy hibát, és azt utólag javítaná. Ezért az alkalmazásbiztonsági megfontolások a koncepciókialakítás, a tervezés, a kódolás, a tesztelés és a bevezetési fázisokban is fontos szerephez jutnak.

"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" - nyilatkozta Arkin.

De mi a helyzet a kicsikkel?

John Viega szerint az Arkin által említett életciklus alapú biztonsági megközelítés korántsem minden esetben kifizetődő, legalábbis a fejlesztőcégek szempontjából. "Vannak olyan vállalatok, amelyek soha nem fogják viszontlátni azokat a befektetéseiket, amelyeket a biztonságos szoftverfejlesztésre áldoznak. A legtöbb cég számára jóval olcsóbb, ha nem tesznek addig semmit, amíg valami nem történik, és megvárják, hogy a piaci nyomás kényszerítse ki a biztonsági intézkedéseket" - vélte Viega.

A szakember egy példával próbálta alátámasztani az érvelését. Tételezzük fel, hogy évente három hiba javítása összességében 50 ezer dollárba kerül, ami már magában foglalja a fejlesztési, tesztelési és kommunikációs költségeket is. Ezzel szemben egy átfogó szoftverbiztonsági program kidolgozása, akár több millió dollárt is felemészthet, amihez még olyan járulékos, közvetett költségek is társulhatnak, mint amit például a termelékenység csökkenése okoz.

Viega szerint, amíg a nagy szoftverfejlesztő vállalatok hasznot tudnak húzni a biztonság fejlesztési folyamatokba történő nagyfokú integrálásából, addig a kisebb szervezetek esetében ez már nincs így. A szakember úgy látja, hogy „a Microsoft és az Adobe számára komoly előnyökkel jár az SDL (Software Development Lifecycle) alapú megközelítés, de tucatnyi olyan céget ismerek, amelyek megvizsgálták az SDL-t, és azt mondták: Viccel? Ez kiütne minket a piacról”.

Mi sem keresünk minden hibát...

Arkin a beszélgetés során finoman célzott arra, hogy miközben az Adobe-nál jelentős erőforrásokat szentelnek a sebezhetőségek korai feltárására és megszüntetésére, aközben a cél nem az, hogy minden egyes biztonsági rést befoltozzanak. A szakember szerint ennél jobb megoldás, ha egy csapat arra fordítja az energiáját, hogy kategorizálja a sérülékenységeket. Persze mint azt az elmúlt hetek történései is igazolták, azért a megjelenő kódokban is maradhatnak kritikus veszélyességű hibák, de ennek lehetőségét semmilyen módszerrel nem lehet 100 százalékosan kizárni. Arkin ugyanakkor azt is hangsúlyozta, hogy a fejlesztők biztonsági oktatását sem lehet félvállról venni.

Nem kellenek törvények

Viega és Arkin egy dologban egyetértett. Mégpedig abban, hogy a szoftverbiztonsági kérdéseket rossz ötlet lenne törvényi szinten szabályozni és megregulázni azokat. Arkin szerint mire egy jogszabály megszületne, addigra az elavulttá is válna, és különben sem szeretné senki, ha a kormányok fogalmaznák meg, hogy miként kell fellépni például a puffertúlcsordulási hibák ellen.