A szoftver akkor lesz igazából biztonságos, ha már a fejlesztés során beépítik a legfontosabb biztonsági funkciókat. Ehhez azonban a szervezeteknek is fel kell nőniük, hiszen komoly érdekellentétek húzódhatnak a felhasználók, a fejlesztők és az üzemeltetők között.
◼︎ ITEXEC 2023 — Kockázatelemzés blokk
Négy előadásban és két kerekasztal-beszélgetésben vesézték ki az ITEXEC 2023 konferencia résztvevői az IT-biztonság örökzöld témáját. A fókuszban leginkább az alkalmazások biztonsága állt: előadóink számokkal is alátámasztották, amit mindenki a saját bőrén érez, nevezetesen, hogy a fenyegetések száma, a kockázatok mértéke folyamatosan nő, miközben a reagálásra rendelkezésre álló idő csökken. A nyilvánosságra került szoftversérülékenységek több mint egyötödét szabadon hozzáférhető szoftverkóddal gyakorlatilag azonnal támadássá lehet fordítani, idézett egy kutatást előadásában Gulyás Krisztián, az ALEF Magyarország F5-szakértője.
Érdekellentétek az IT-n belül
Ilyen körülmények között még nehezebb gondoskodni az alkalmazások biztonságáról. Megjelenik a DevSecOps-paradoxon, mutatott be egy egzotikusan hangzó kifejezést Pintér András, a Palo Alto Networks regionális értékesítési menedzsere. Ez nem másról szól, mint hogy rendkívüli mértékben felgyorsult az alkalmazásfejlesztés és -bevezetés folyamata, így a korábbi beidegződések már nem használhatóak, és kiéleződnek a meglévő ellentétek.
A belső ügyfél, az üzleti felhasználó minél hamarabb szeretné megkapni az új funkciót, ezért hajszolja a fejlesztőt; a fejlesztő nem érti, miért olyan rugalmatlan és lassú az üzemeltető; az üzemeltetésért felelős csapat megbízható, letesztelt, auditálható rendszert akar, amely lehetőleg nem változik túl gyakran; a biztonsági csapat meg haját tépi, mert a nagy rohanásban senki nem figyel a biztonsági szempontokra. Szerencsére erre a helyzetre is kínálnak megoldásokat a szállítók. Az eszközök mellett azonban a szervezeti kultúrába is be kell építeni a biztonságos fejlesztés gondolkodásmódját – tette hozzá Horváth Tamás, a Brigthdea ügyvezetője. Fel kell mérni, hogy milyen elvárásai és félelmei vannak a fejlesztőknek az IT-biztonság irányába, majd biztonsági kontrollpontokat kell illeszteni a fejlesztési folyamatba, lehetőleg már a folyamat elejére, hogy a lehető leghamarabb kiderüljenek a hiányosságok, sérülékenységek. Gondosan kiválasztott metrikák révén mérhetővé kell tenni a biztonsági megfelelőséget, és nem szabad megfeledkezni a fejlesztők képzéséről sem.
A biztonság mérhető
Milyen hibákat követhet el egy szervezet első számú vezetője a kiberbiztonság kapcsán, hogyan lehet mérni a biztonsági szintet, és miként lehet megbizonyosodni a beszállítók biztonságáról – ezeket a kérdéseket járták körül a szekció első panelbeszélgetésének résztvevői.
A résztvevőknek nem kellett sokáig gondolkodniuk, hogy mit ronthatnak el a csúcsmenedzserek. Ilyen lehet, hogy nem érzékenyek a biztonság iránt, nem égették még meg magukat (és a cégüket), ezért hiányzik az elkötelezettség, kezdte a felsorolást Horváth Tamás. A stratégia és a tudatos gondolkodás hiányát emelte ki Laczkó Gábor, az Aspectis ügyvezetője és Szakács Gergely, az ALEF műszaki igazgatója. Több problémát is azonosított Szeiler Andrea, a call centereket üzemeltető Transcom globális CISO-ja: ha a CEO-nak csak a megfelelés lebeg a szeme előtt, vagy ha a hierarchiában túl távol van egymástól a CEO és a CISO (mert a sok szűrőn fennakadnak a fontos információk). De az is gond lehet, ha a CISO nem érti az üzletet, és nem a kockázatokkal arányos megoldásokat javasol.
| A videórendszereket is védeni kell
A modern, IP alapú videokamerás megfigyelőrendszerek a védelem eszközei – ugyanakkor maguk is védelemre szorulnak. A kamerarendszerek manapság ugyanis tisztán informatikai eszközök, amelyek a hálózathoz csatlakoznak; ezáltal viszont sebezhetővé válnak, és rajtuk keresztül a teljes hálózatot meg lehet fertőzni, hívta fel a hallgatóság figyelmét Laczkó Gábor (Aspectis). Fontos ezért, hogy az ügyfelek olyan megoldást válasszanak, amelyek nem csak önmagukban biztonságosak, de az incidensek kezelésének, a sebezhetőségek javításának a folyamata is kidolgozott. |
Mind a saját rendszerek, mind a beszállítók védelmi szintje mérhető, derült ki a következő kérdésekre adott válaszokból. Az előbbi esetében lényeges, hogy minden érintett rendszert monitorozzanak, gyűjtsék az adatok, és persze tisztában legyenek azzal, hogy pontosan milyen rendszereket és adatokat kell védeni, hangsúlyozta Kerper Gábor, az AVL informatikai vezetője. Hozzátartozik a védelmi felkészültséghez a kipróbált vészforgatókönyvek megléte is. A beszállítók értékelésénél pedig az is fontos, tette hozzá Szeiler Andrea, hogy az általa kínált szolgáltatásához kell viszonyítani az elvárt biztonsági szintet, és közösen döntsék el, melyik fél miért felelős.
A felelősség házon belül marad
Gyakori probléma, hogy a cégnél nincs kellő szakértelem minden biztonsági tevékenység ellátásához. Mit szervezhet ki és mit nem a gondos CISO? – hangzott el a kérdés a második biztonsági kerekasztal résztvevőihez. Leginkább azt a speciális tudást érdemes kívülről behozni, amelyet nem tud vagy nem akar megfizetni a vállalat – adott választ az első kérdésre Dellei László, a Kerubiel ügyvezetője. Még a Magyar Honvédség Kiberműveleti Parancsnokságáról érkező Pozderka Gábor ezredes sem gondolta úgy, hogy mindent érdemes házon belül tartani – a képzéseknél például mindenképpen szükségük van a partnerekre.
De van, amit mindenképpen érdemes házon belül tartani. Sándor Barnabás, a MOL kiberbiztonsági architektje szerint ilyen a vállalati felső vezetéssel való kapcsolattartás. A tőlük származó információk nélkül ugyanis lehetetlen lenne az igények felmérése, majd a stratégiaalkotás. Ádám Zoltán, a Palo Alto Networks szakértője ehhez még hozzátette: azt sem engedheti meg a CISO, hogy ne lássa át rendszerei működését, ne tudja, hogy éppen mi történik, mert enélkül elveszti a kontrollt a biztonság felett. Dellei László szavai pedig akár zárszóként is értelmezhetők: az IT-biztonsági vezető a felelősséget sem adhatja át másnak.
