A biztonsági réseket a programozók hozzák létre

Az alkalmazások biztonsága az utóbbi években került a figyelem középpontjába. Ez köszönhető részben a webes alkalmazások széles körű elterjedésének, részben annak, hogy ma már főleg a szoftverekben hagyott hibákból származik az a rés, amelyen a hackerek támadhatnak.

A 2010-es évek elejéig a biztonsági szakemberek a határvédelemre koncentráltak, a cégek rengeteget költöttek erre a fajta védelemre. A hackerek ezt felmérve az alkalmazások hibái felé fordultak, amelyek, a vállalati környezetekben is, főleg a programozók által hagyott hibákból adódnak, hiszen egyfelől a mai programok jóval komplexebbek, mint 10-20 évvel ezelőtt, másfelől a megrendelői oldal még nem ismerte fel, hogy számára – és ügyfelei számára – csak a fejlesztési folyamatba illesztett biztonsági ellenőrzés adhat valódi biztonságot.

A "határvédelmi" modellben a védett hálózat külső forgalmából szűrték ki a potenciális támadásokat. A belső hálózatban zónákat hoztak létre, a külső zónában elhelyezve például a webszervereket, a belsőkben pedig az érzékeny adatokat és a szolgáltatásokat.

A szakemberek ilyenkor abban bíztak, hogy a támadók fennakadnak a kerítéseken és az ellenőrzött kapukon. Ezzel párhuzamosan a 2000-es években végbement egy korszakváltás, amelynek köszönhetően a szoftveriparban megjelent és a semmiből a biztonsági büdzsék 20-30%-át hasította ki az azelőtt szinte teljesen hiányzó funkcionális tesztelés, ami már komoly lépés volt a biztonság felé.

Hamis biztonságérzet helyett

Napjainkban egy újabb korszakváltásnak vagyunk tanúi: a határvédelemről és az utólagos tesztelésről – amilyen például az etikus hacking, és főleg a penetrációs tesztek – Nyugat-Európában és az Egyesült Államokban a figyelem egyre inkább a preventív alkalmazásbiztonságra terelődik. Nem csoda, hiszen a fejlesztés folyamatába illesztett biztonsági ellenőrzés és szakértelem sokkal jobb hatékonyságot és valóságosabb biztonságot – nem csupán a hamis biztonságérzetet – ad. Emellett a számos országban már létező adatvédelmi törvényi kötelezettségek miatt a preventív alkalmazásbiztonság az egyetlen út, ami valóban megvédheti a piaci szereplőket és ügyfélköreiket a betolakodóktól.

A fejlett országokban mára a biztonsági büdzsék 20%-át fordítják alkalmazásbiztonságra, legnagyobb részben etikus hackingre, de folyamatosan nő a preventív megelőzés részaránya is. Magyarországon ez az arány ma még nem éri el az 5%-ot, ami a hazai mintegy 25 milliárd forintos biztonsági piacot alapul véve körülbelül 1 milliárd forintos ráfordítás.

Az alkalmazásbiztonsági piac minden jel szerint dinamikus növekedés előtt áll, hiszen ma már a támadások 80%-a az alkalmazásokat, a szoftverekben hagyott réseket és nem a határvédelmet veszi célba. Ezeket a javításokat pedig a szokványos garanciális keretek között a fejlesztők általában nem végzik el, már csak azért sem, mert az utólagos tesztelésekre sokszor az általánosan szabott 3 hónapos garanciális határidőn túl kerül sor.

Tesztelés már a fejlesztés során 

Az adatbiztonság növelését az OWASP hazai tagozatának alapítói, a Cloudbreaker szakértői szerint részben az eddig halogatott törvényi szabályozással, részben a megrendelői oldal szemléletváltásával lehetne elősegíteni. Míg a törvényi szabályozás egyelőre várat magára, a megrendelői oldalon kívánatos szemléletváltást részben az OWASP tevékenysége hivatott előmozdítani.

Ezt szem előtt tartva hozta létre a Cloudbreaker SEQA (Security QA, Security Quality Assurance) nevű termékét, amely a megrendelői oldalnak létrehozott minőségbiztosítási eljárásrend. Ha a megrendelők eszerint írják ki a beszerzéseket és kötnek szerződést a fejlesztőkkel, akkor biztosítják azt, hogy a biztonsági hibákat a beszállítók már a fejlesztés során – preventíven – folyamatosan kiküszöböljék, így elkerülve, hogy hiányosságokra csak az utólagos tesztelések során derüljön fény, ami a hibák egy jelentős részénél már túl késő, a javítás nem vagy csak nagyon körülményesen és extraráfordításokkal lesz lehetséges.