A biztonságos szoftverfejlesztés 7 lépése

Szerencsére mások is így vélik, és a biztonságot egyre több szervezet kezeli prioritásként. Rájöttek, hogy a szoftver működésének néhány kifejezetten gyakorlatias kérdésével, például egyszerű feladatok ciklusonkénti kivitelezésével kellene kezdeni, és azok alapján javítani a minőséget. Persze ezt a megközelítést is könnyebb megfogalmazni, mint a valóságban kivitelezni. Sajnos olyan nagy a nem várt változásokkal szembeni tehetetlenség, hogy a rendszerek gyakran lebénulnak. Okok? A biztonságra a tervezés, a fejlesztés, a tesztelés és a gyártás során sem fordítottak kellő figyelmet.

E hibákat elkerülendő, a HP hét praktikus lépést javasol, amelyeket betartva a fejlesztőcégek biztonságosabb szoftverekkel rukkolhatnak elő. Az elmélettel szemben a praktikus oldalra, manapság bárki által kivitelezhető tevékenységekre fekteti a hangsúlyt. A javasolt lépések ugyan nem oldják meg teljesen a biztonságot, viszont (elvileg) mérhető eredményeket generálnak rövid időn belül.

1. Biztonsági értékelés – tervkészítés

A szoftverbiztonság jelen állapotának értékelése, valamint a biztonság teljes fejlesztési életcikluson át történő kezelését, illetve további kiegészítő tevékenységeket leíró terv készítése az első lépés. A legcélszerűbb egyszerű listákkal és elemzésükkel kezdeni: van-e belső biztonsági szakértő a cégnél, minden projekthez készítünk-e veszélyelemzést, továbbá speciális segédprogramok, erőforrások azonosítása és beszerzése stb. Az első tervnek egyfajta POC-ként (proof-of-concept) kell funkcionálnia – a későbbiekben a POC pozitív eredményei alapján lehet majd sokkal alaposabb terveket kidolgozni. Három területet kell vizsgálnia: a szervezet összes szoftverfejlesztési projektjét körülvevő szoftverbiztonsági infrastruktúrát, a fejlesztőcsoportok által kiválasztott speciális biztonsági aktivitásokat és megoldásokat a biztonsági rések kezelésére.

2. A kockázatok és veszélyek specifikálása

E második lépéssel már akár meg is előzhetők a kockázatok és veszélyek. A biztonság – kockázatcsökkentés, és nem mindegy, milyen kockázatot csökkentünk: a felhasználó személyes adatait tartalmazó alkalmazások sokkal érzékenyebb információt tartalmaznak, mint például egy vállalat konferenciatermében folyó programok ütemezése. Meg kell határozni, hogy a szoftver melyik részéhez milyen kockázatok társíthatók. A veszélyelemzés egyszerűbb megoldás a teljes skálájú kockázatfelmérésnél – lényege a tervezés biztonsági hibáinak kiszűrése. Először meg kell állapítani a védendő eszközöket és alkalmazásokat, illetve, hogy melyiket akarjuk leginkább megóvni, és csak utána azonosítjuk a veszélyt.

3. A kód felülvizsgálata

Ebben a fejlesztési során (önkéntelenül) létrehozott biztonsági veszélyeket kell feltérképezni. A legtöbb esetben számos hiba kimutatható, és ha újra elvégzünk egy veszélyelemzést, az általunk legfontosabbnak tartott biztonsági problémák kiküszöbölhetők ezen a szinten, de legalább nyílt rések nem maradnak. A HP a szokásos manuális helyett gépi felülvizsgálatot javasol.

4. A kód tesztelése és verifikálása

A tesztelés szintén automatizálható. Bevett módszer a támadások, behatolások szimulálása, amellyel a rendszer megnyilvánulásainak anomáliáit próbálják azonosítani. Az automatizálás előnye, hogy az ismert támadásokról könnyen készíthető tudásbázis, ugyanakkor a kifinomultabb betörésekkel gyakran nem tud mit kezdeni. A behatolás tesztelése során az összes bemenő forrást figyelembe veszik, sebezhetőségi szempontból érdektelen területeket viszont nem. A tesztelés egyrészt nem könnyű feladat, másrészt nem csak erre a lépésre kell támaszkodni hibakereséskor. Elsődleges célja a kód felülvizsgálatakor talált rések megszüntetése.

5. Magának a kódnak a tesztelése

Meg kell állapítani, hol és miért támadható, és megelőzendő az alkalmazások sebezhetőségét, be kell építeni egy biztonsági kaput. A kapu megakadályozza, hogy ezek a gyenge pontok bajt okozzanak a gyártási fázisban és utána. De milyen kritériumok alapján döntsük el, hogy a szoftver alkalmas erre az utolsó ellenőrzésre, vagy sem? Például (többek között) az előző lépések kivitelezése, a kód auditja ilyen kritériumoknak tűnnek.

6. A biztonsági terv sikerének mérése

E hatodik lépéssel az előállítási folyamat hibái fokozatosan és folyamatosan kiküszöbölhetők. A fejlesztőcégeknek minden esetben ellenőrizni kell biztonsági lépéseik sikerét, hogy megfelelnek-e a változó igényeknek és környezetnek. Sajnos nem könnyű a mérés, sokszor azt se lehet tudni, hogy tulajdonképpen mit is kellene mérni. Olyan tényezőket szoktak számszerűsíteni, mint például a tervekhez való hűség, a biztonsági folyamat implementáció utáni sikere, projektenkénti rések száma és általánosításuk, kategóriánkénti fokozat és idő szerinti megoszlásuk. A HP ezen a területen az adatgyűjtés időben való megkezdését tartja kulcsfontosságúnak.

7. Felvilágosítása/oktatása a biztonság fontosságáról

A hetedik és egyben utolsó lépés a fejlesztők, majd a felhasználók felvilágosítása/oktatása a biztonság fontosságáról, a biztonsági terv hatékony implementálásáról. Persze a fejlesztők többsége még speciális tréning után sem lesz feltétlenül szoftverbiztonsági szakember, de nem is ez a cél, hanem inkább a felelősség kijelölése, annak eldöntése, hogy a csoporton belül ki a legalkalmasabb az ilyen jellegű tevékenységek levezénylésére. Ugyanakkor a felelősség megosztására is ügyelni kell. A csoport valamennyi tagjának tudatosítania kell a kódírás, tervezés, fejlesztés adott lépésével járó kockázatokat. Kevesebb hacker ér célba, ha folyamatosan átgondolják, hogy „miként húzhat hasznot egy behatoló abból, amit pont teszek?”