Rövid átfutással, nagy hatékonysággal és olcsón állítják elő az agilis fejlesztőcsapatok az üzlet által igényelt, innovatív szoftvermegoldásokat, méghozzá az esetek többségében jó minőségű kód formájában. A gyors piacra lépéshez szükséges prototípusok így sokkal rövidebb idő alatt készíthetők el és tökéletesíthetők, ezért az ilyen fejlesztési módszertanok teszik lehetővé a technológiai startupok hihetetlen fejlődését, és a nagyvállalati szoftverfejlesztési projektek sikeres megvalósítását egyaránt.
A vállalati felhasználók – a fejlesztőcsapatok ügyfelei – által preferált, ún. rapid (gyors) fejlesztési ciklusok, a rövid határidők és a funkcionalitással összefüggő elvárások azonban sok esetben háttérbe szorítják a biztonsági megfontolásokat. Úgy is mondhatnánk, hogy az agilis szoftverfejlesztési módszertan alkalmazása az információbiztonsági szempontok, a biztonságos kódolás elhanyagolását eredményezi. Önmagában természetesen nem feltétlenül a módszertan, sokkal inkább annak felületes használata hibáztatható ezért.
Fejlesztők stresszhelyzetben
Egy átlagos nagyvállalati fejlesztési projekt esetében a fejlesztői csapatok állandó nyomás alatt dolgoznak. Függetlenül attól, hogy agilis módszertant követnek vagy sem, ott próbálnak időt nyerni, ahol tudnak – vagyis a kód ellenőrzésén, a tesztelésen és a biztonsági funkciókon.
Rátesz erre még egy lapáttal, hogy az agilis csapatok még az átlagnál is gyorsabban haladnak, gyorsabban hoznak döntéseket, amelyek többnyire nem lassíthatják le a projekteket biztonsági megfontolások miatt. Nem javítja a helyzetet az sem, hogy jelenleg az iparágban egy szakadék mélyül az információbiztonsági szakértők és az agilis fejlesztők között. A biztonsági szakértők többnyire nem értik az agilis fejlesztések életciklusait, nehezen tudják beilleszteni a biztonsági szempontokat az agilis tervezési és fejlesztési ciklusokba.
Információbiztonsági és projektvezetési szempontból fogas kérdés, hogy a rapid fejlesztési módszertanok rövid, 1-2 hetes időkorlátai közé miként lehet a biztonsági megfontolások, szempontok, kockázatok kezelését (Scrum, Kanban, XP, CI stb.) is beszorítani. Napjaink szoftverfejlesztési kultúrájában, amely a kísérletezést, az ismeretlen kipróbálását és a gyors előrehaladást részesíti előnyben még a gyakori kudarcok árán is, a kód biztonságosságát szem előtt tartó, megfontoltabb megközelítés konzervatívnak számít, és kevéssé tud gyökeret verni. Jelenleg legalábbis ez a helyzet.
Strukturális megfontolások is nehezítik a helyzetet egy agilis projekt esetében. Az állandóan változó követelmények, a megrendelő visszajelzései által kikényszerített változtatások architektúra szintjén is lehetetlenné teszik, hogy a biztonságot már a tervezés szakaszában figyelembe vegyék, mert valójában nincs is tervezés, csak újratervezés, az egyes iterációk végén kapott, új ügyfél-visszajelzések alapján.
Egy 2012-es Microsoft-kutatás szerint csak a szoftverfejlesztők 37 százaléka követi a biztonságos kódolás szabályait, pedig az nem egy különösebben titokzatos tudomány. A Microsoft SDL (Security Development Lifecycle) for Agile vagy az OWASP (Open Web Application Security Project) és a Kaliforniai Egyetem (UC Berkley) által publikált, biztonságos kódolást elősegítő módszertanok, szabályzatok például minden fejlesztőcsapat rendelkezésére állnak.
Mit tehet a CIO?
Cikksorozatunkban eddig mindig a jövő CIO-ja szempontjából tárgyaltuk az informatika biztonsági kérdéseit, és ezúttal sem teszünk kivételt. Az információbiztonsági kockázatok rangsorában ugyanis egyre feljebb kúsznak az internetre csatlakozó, egyedi fejlesztésű rendszerek biztonsági problémái. Az OWASP tavalyi TOP 10-es listáján több olyan biztonsági kockázat is szerepel, amelyek fejlesztői odafigyeléssel alapvetően kiküszöbölhetőek lehettek volna.
Az InformationWeek 2013-as Strategic Security Survey felmérése szerint a támadók az esetek 46 százalékában a szoftversérülékenységek kihasználásával hatolnak be az IT-rendszerekbe. A WhiteHat Security szerint egy átlagos webes alkalmazás nem kevesebb, mint 56 sérülékenységet tartalmaz, A Veracod 2013. áprilisi felmérése szerint pedig csupán a webalkalmazások 13 százaléka mentes teljesen az OWASP TOP 10-ról ismert sérülékenységektől.
Sokáig lehetne ezt a listát folytatni, információbiztonsággal foglalkozó cégek régóta figyelmeztetnek a vállalati, egyedi szoftverfejlesztések során keletkező sérülékenységekre. A gyengébb információbiztonság adta lehetőséggel visszaélők – nevezzük őket hackereknek – szintén jó ideje és egyre inkább magukat az alkalmazásokat, és nem azok környezetét (szerverek, operációs rendszerek, tűzfalak, stb.) támadják. Tisztában vannak vele ők is, hogy az IT-biztonsági szakértők nehezen tudnak lépést tartani az agilis szoftverfejlesztés rohanásával, a szoftverfejlesztőknek pedig nincs kellő IT-biztonsági szakértelmük, tudásuk.
Miként kényszerítheti ki az agilis fejlesztésű szoftver bevezetésére készülő CIO a biztonsági szempontok figyelembe vételét? Nos, amennyiben részt vesz a projektben megrendelői oldalon, mint a készülő termék gazdája, akkor kihasználhatja, hogy az agilis módszertan kiemelt fontosságot tulajdonít a megrendelői oldalról érkező, folyamatos visszaigazolásnak. Iterációról iterációra lehetősége lesz számon kérni, ellenőrizni a létrejött kód, termék IT-biztonsági szintjét, akár egyedi speciális tesztek bevezetésével is.
Alapvetően fontos, hogy a fejlesztés során használt tesztelési technikák között megtalálhatók legyenek a biztonsági tesztelések is. Ezzel együtt érthető persze a dilemma, hogy két rövid, 1-2 hetes iteráció közé miként lehet egy komplex behatolástesztelést elhelyezni anélkül, hogy a projektterv borulna. Arról nem is beszélve, hogy a tesztelt kód már a következő iterációban kikerülhet a termékből.
Fejlesztői oldalon egyfajta biztonságtudatos szemlélet kialakítása lehet a megoldás. Saját fejlesztői környezetében minden fejlesztő valamilyen szinten el kell, hogy sajátítsa az adott környezetre jellemző, biztonságos kódolási szabályokat. Akár az is elvárható tőlük, hogy a rövid, 1-2 hetes sprintek végén biztonsági szempontból is ellenőrizzék a kódot.
Iparági szakértők javasolják, hogy a fejlesztés folyamatába olyan iteráció, security sprint is kerüljön, amelyben nem új funkcionalitás fejlesztése, hanem az addig elkészült kód biztonsági hibáinak, sérülékenységeinek megtalálása a cél. Nem szabad elfelejteni, hogy az IT-biztonság aszimmetrikus játszma – a támadónak egyetlen szoftverhiba is elegendő a károkozáshoz. Ha kétségeink vannak az elkészült kód biztonságosságát illetően, akkor harmadik féltől is megrendelhetjük az alkalmazásbiztonsági vizsgálatot. Emellett nagyon sok egyéb szoftverfejlesztési technika is létezik a biztonságos kódolás elősegítésére, itt nem tudjuk ezek mindegyikét bemutatni.
A lényeg a CIO-k számára, hogy az agilis megközelítés, amellyel a modern rendszerek, az infómunkások kedvencei, a mobilitást és hálózati kommunikációt elősegítő alkalmazások készülnek, nem jelenti alapból azt, hogy kompromisszumot kell kötni a biztonsági elvárások terén. Megfelelő eltökéltséggel és alapvető IT-biztonsági elvek, szabályok követésével sikeres agilis projekteket lehet nagyvállalati környezetben is megvalósítani.
