Már több, mint egy hónapja, hogy a SolarWinds incidens valódi súlyával tisztában vagyunk. Sajnos ennyi idő a jelek szerint nem volt elég ahhoz, hogy a hazai kritikus infrastruktúra cégei és az illetékes állami szervek koordinált intézkedésekről kezdjenek egyeztetni, amik lehetőséget adnának a jövőbeli, hasonló jellegű és méretű fenyegetést jelentő, részben a beszállítói lánc, részben pedig a hálózatmenedzsment és monitoring megoldások elleni támadások esetére a védekezéshez.
Első lépésként minden szervezetnek, de szerintem különösképpen a kritikus infrastruktúrákhoz tartozó szervezeteknek és (természetesen) az államigazgatásban érintett szervezetek esetén el kéne végezni a beszállítók jelentette kockázatok elemzését. Ehhez meglehetősen jó iránymutatást ad az NIST Cyber Supply Chain Risk Management című publikációja. Emellett egyes vélemények szerint három területen lehet viszonylag gyorsan érezhető hatású intézkedésekkel csökkenteni a hasonló támadások kockázatait:
1. A szoftver-beszállítói lánc irányítása - A legtöbb szervezetnek nincs megfelelő rálátása arra, hogy a neki egyedi szoftvereket fejlesztő vagy dobozos szoftver-termékeket értékesítő/üzembe helyező vállalatok pontosan mit is adnak át nekik, de még ha a képességnek birtokában is vannak (1000 ügyfélből talán egy ilyen, ha lehet), a fejlesztők és integrátorok általában nem érdekeltek abban, hogy az ügyfeleknek minél transzparensebbé tegyék a saját folyamataikat. Pedig szükség lenne ahhoz, hogy a beszállítói lánc elleni támadásokat meg lehessen előzni vagy legalább csökkenteni lehessen a hatásaikat. Erre két esély kínálkozhat, egyrészt az ügyfélnek célszerű minden olyan befolyásolási eszközt megragadni a tárgyalások során, amivel rá tudja venni a szállítót az általa fontosnak tartott átláthatósági követelmények betartására, másrészt pedig az iparági jó gyakorlatok és (szerintem különösképpen a kritikus infrastruktúrák közé sorolt hazai szervezetek esetén) a 41/2015. BM rendeletben is előírt követelmény (a fejlesztési folyamat teljes körű és átlátható dokumentálása) alapján lehet megteremteni ezt a fajta transzparenciát.
2. Viselkedés-elemzésen alapuló fenyegetés-detektálás
Ha jól belegondolunk abban, hogy a támadók általában nem mozognak otthonosan a megtámadott rendszerekben, megérthetjük, miért lehet jó eszköz a viselkedés-elemzés a különböző támadások észlelésében. Egyes hírek szerint a SolarWinds-incidens első felfedezéséhez (a FireEye nyomozását kiváltó eseményhez) egy szokatlan távoli felhasználói bejelentkezés vezetett, ami egy ismeretlen eszközről és gyanús IP címről történt.
3. Adatletöltés megelőzése és észlelése
Ha minden más biztonsági intézkedésünk elbukott, képesnek kell lennünk gyorsan azonosítani, amikor a szervezet értékes adatait éppen jogosulatlanul akarják a cég rendszerein kívülre juttatni. Ebben a témában (szigorúan műszaki szempontból) sok szervezet jól teljesít (a SolarWinds incidens kapcsán számos cégnél találtak olyan logokat, amik az adatok lopására utaló jeleket tartalmaztak), éppen csak a riasztások kezelése volt csapnivaló (gyakorlatilag nem foglalkoztak ezekkel). Ebből is látszik annak a régi, IT biztonsági műveleti körökben ismert megállapításnak az igazsága, ami szerint a különböző gyártók különböző csoda-megoldásai önmagukban nem fogják megvédeni a szervezeteket a biztonsági eseményektől és incidensektől, a jó megoldások mellé nagyon jó és tapasztalt biztonsági elemzőkre és jól megtervezett, jól begyakorolt és rendszeresen tesztelt (valamint szükség esetén finomhangolt) eljárásokra is legalább ugyanekkora (vagy inkább még nagyobb) szükség van.
Azt egyelőre még nem lehet tudni, hogy a SolarWinds incidens lesz-e ugyanolyan mérföldkő a supply-chain támadások terén, mint amilyen a Stuxnet az ICS kiberbiztonság témájában, de én személy szerint arra számítok, hogy a közeli jövőben látni fogunk még nagyszabású, a beszállító láncot is érintő kiberbiztonsági incidenseket.
