Régóta mondják a szakértők, hogy a biztonsági szempontok teljesítését a szoftverfejlesztés integráns részévé kell tenni. Mondani azonban egyszerűbb, mint meg is tenni – de a dolog nem lehetetlen. Közben persze a mesterséges intelligencia új kihívásokat támaszt.
◼︎ Biztonság
Miközben a világban szaporodó kockázatok miatt mind fontosabb lenne, hogy a szoftverek ne utólagos funkcióként tartalmazzák a biztonsági elemeket, a fejlesztőknek egyre nehezebb dolguk van, ha eleget akarnak tenni az IT-biztonsági elvárásoknak, derült ki az ITBUSINESS & TECHNOLOGY 2023 konferencia ezzel foglalkozó szekciójának előadásaiból.
Mindenki mást akar
A helyzet már korábban sem volt rózsás, a biztonságra általában nem maradt idő és erőforrás. A helyzet azóta csak romlott, hiszen az új verziók már elképesztő tempóban követik egymást – az Amazon például naponta (!) 2300 alkalommal frissíti saját rendszereit, érzékeltette a helyzetet Ádám Zoltán, a Palo Alto szakértője. Az ügyfelek sem könnyítik meg a fejlesztők életét, pedig a biztonsági funkciók az ő érdekeik védelmére szolgálnak. A technológiai fejlesztések – például a mikroszerviz alapú konténerizációs megoldások – szintén új veszélyeket hoznak magukkal.
Nehéz is megoldást találni, mert a három érintett informatikai terület szereplői mind másban érdekeltek, máshol vannak a prioritásaik, folytatta Ádám Zoltán. A fejlesztők rohannának előre az agilis módszerek szerint, hogy kielégíthessék az üzlet igényeit. Nem értik, miért zaklatja őket a biztonsági csapat a követelményeikkel, az üzemeltetés pedig miért frissítgeti az infrastruktúrát, ami megakasztja a programokat. Az üzemeltetők és a biztonságiak veszélyesnek tartják, ahogy a fejlesztők ellenőrzés nélkül használnak fel innen-onnan letöltött, kétes minőségű eszközöket és kódrészleteket; a security pedig nem érti, hogy a másik kettő miért nem képes betartani a legelemibb biztonsági szabályokat sem.
Alapelvek nélkül nem megy
A gondok azonban sok esetben még ennél is mélyebben rejtőznek – fűzte tovább a gondolatot Horváth Tamás, a Brightdea alapítója és ügyvezetője. Vannak ugyanis olyan információbiztonsági alapelvek, amelyeket mindenképpen be kell tartani, ha rendszereinket biztonságban akarjuk látni.
A három legfontosabb alapelv a rendszerelemek láthatósága; azok biztonságos konfigurációja; és végül a rendszerek és rendszerelemek rendszeres frissítése. Hiszen hogyan akarjuk megvédeni az infrastruktúrát, ha azt sem tudjuk, mivel rendelkezünk? Hogyan akarunk biztonságos működést megvalósítani, ha nem változtatunk a gyári beállításokon, ha nem követjük az előírásokat és a legjobb gyakorlatokat? És miért gondoljuk, hogy biztonsági szempontból nem avul el a rendszerünk? Márpedig, ha megnézzük az elmúlt tíz év legnagyobb port felvert nemzetközi biztonsági incidenseit (az RSA, a SolarWinds és a LastPass meghekkelését), azt láthatjuk, hogy a fenti alapelvekből legalább kettő minden esetben sérült.
Horváth Tamás még hozzátette: a siker szempontjából rendkívül fontos, hogy az IT-biztonsági eszközök, technológiák kiválasztását előzze meg az üzleti és az informatikai folyamatok feltérképezése, és a kockázatok elemzése. Ezek ismeretében lehet a biztonsági szabályzatokat kialakítani, majd a hiányosságokhoz és biztonsági célokhoz érdemes eszközöket keresni.
Ellenfél is lehet az MI
Az előadásokat követő panelbeszélgetésen szóba került, hogy 2023 milyen kihívásokkal teszi próbára az információbiztonsági szakembereket. Ádám Zoltán a régóta velünk lévő fenyegetések (phishing, zsarolóvírusok stb.) mellett a mikroszerviz architektúrákat jellemző API-kommunikációk sérülékenységét emelte ki. A phishing Báthori Krisztián, a Magyar Bankholding CISO-jának hozzászólásában is előkerült: ő azt emelte ki, hogy az ilyen támadások mennyire professzionálisak lett az elmúlt időben. A külalak, a szövegezés sokszor annyira követi a vállalati sztenderdeket, hogy még a szakembernek sem egyértelmű: csalással áll szemben.
A szakemberek szerint a mesterséges intelligencia is kétélű fegyver. Dr. Havas-Sághy Gábor ügyvéd nagy veszélyt lát abban, hogy az MI alapú chatbotok segítségével sokkal hatékonyabb támadásokat lehet indítani, Gélák Róbert, a Hungarocontrol IT-biztonsági vezetője ezt saját tapasztalatával is alátámasztotta. A ChatGPT-be bemásolt egy nem triviális sérülékenységet, a chatbot pedig kérésre írt hozzá egy működő exploitot, a hibát kihasználó támadó kódot.
Kié a felelősség?
Fontos kérdésként értékelték a résztvevők a szoftverszállítói felelősséget. Az újonnan bevezetett szabályozások a korábbinál nagyobb felelősséget hárítanak a szoftverszállítókra, és ez jól is van így, vélte Lendvai Richárd, aki maga is egy szoftverfejlesztő céget, az Intuitechet képviselte. Mint mondta, ez megtépázza majd egy kicsit a piacot, és azok a cégek maradnak talpon, amelyek korábban is komolyan foglalkoztak ezzel.
 MI és hitelesség A mesterséges intelligencia veszélyeire hívta fel a figyelmet a konferenciát lezáró előadásában Keleti Arthur kibertitok-jövőkutató. Az MI újonnan megmutatkozó képességei a technológiába vetett hitet, az autentikusságot kezdik ki. A többség mindeddig megbízott azokban az adatokban, amelyeket mondjuk a kedvenc keresőjük tálalt eléjük, mint ahogy megbízott az érzékszerveiben is. Ezt a kognitív és érzékszervi bizalmat viszont most már nagyon könnyen alá lehet ásni. Keleti Arthur ezt demonstrálta is: leklónozta a saját hangját egy szabadon elérhető szoftverrel, amely utána az ő hangján, de még jobb angolsággal olvasott fel bármilyen szöveget – ezzel már átverhetők lennének a hangfelismerésen alapuló biztonsági megoldások. De a fejlettebb technológiákkal a metaverzumos avatarokat is lehet klónozni, hamisítani; egyetlen portréképből generálható a száját életszerűen mozgató, bármilyen szöveget elmondó videó – vagyis mind nehezebb lesz bármiről bebizonyítani, hogy az eredeti, hiteles. |
Élénk vita alakult ki azzal kapcsolatban is, hogy mit tehet a megrendelő, ha biztonsági hibát talál a külső fejlesztőtől származó egyedi szoftverben. Az egyik lehetőség, hogy már a szerződésben rögzíteni kell, hogy a bizonyítható sérülékenységet garanciálisan kell helyrehozni, illetve a teljes ár 10 százalékát csak akkor kifizetni, ha mondjuk fél évig semmilyen sérülékenység nem bukkant fel a szoftverben. De lehet biztonsági specifikációt is mellékelni a funkcionális specifikáció mellé – az már más kérdés, hogy a szoftverszállítók mennyire lesznek együttműködőek, mert sokan inkább bíróságra járnak, minthogy kijavítsák a hibát. „A megrendelőt védő jó szerződés ügyvédi költsége elenyésző a szoftverfejlesztés teljes költségéhez képest”, mondta erről Dr. Havas-Sághy Gábor.
