A mai poszt témája a SANS által Active Cyber Defense Cycle-nek nevezett rendszer, ami alapvetően 4 részből áll (ahogy ezt ennek a sorozatnak az előző posztjában), de kezdésnek nézzük még kicsit részletesebben azt, mit is értünk aktív kiberbiztonság alatt. Ahogy oly sok más esetben, az egyes szervezeteknél kisebb-nagyobb különbségek lehetnek abban, mit is értenek bele az aktív kiberbiztonságba, egy dolog azonban biztos: a hack-back vagy visszahackelés, a támadók megtámadása nem azonos az aktív kiberbiztonság fogalmával és tevékenységével.
Visszatérve az aktív kiberbiztonság 4 általános területére:
1. Fenyegetéselemzés és információgyűjtés (threat intelligence)
Ez a tevékenység lényegében azt célozza, hogy a lehető legtöbb információval rendelkezzen a szervezet az őt és az általa használt IT és ICS/OT rendszereket célzó kiberbiztonsági fenyegetésekről és ezek ismeretében a preventív, detektív és incidenskezelési intézkedéseit a lehető leghatékonyabbra tudja alakítani. Az ehhez szükséges információgyűjtés életciklusát a Tripwire oldalán
https://www.tripwire.com/state-of-security/security-data-protection/introduction-cyber-intelligence/
lehet legjobban megismerni. Alapesetben ez a tevékenység csak annyiban tér el az IT biztonsági területen végzett fenyegetéselemzéstől, hogy OT területen az IT fenyegetések mellett a kifejezetten OT fenyegetésekre vonatkozó információkat is érdemes gyűjteni.
2. Eszközleltár és hálózatbiztonsági monitoring
Nehéz (ha nem lehetetlen) megvédeni olyan dolgokat, amikről nem is tudjuk, hogy léteznek és meg kell(ene) védenünk őket, így azt hiszem érthető, hogy miért kritikus fontosságú egy naprakész és pontos, részletes eszközleltárral rendelkeznie minden szervezetnek. Ez ugyanúgy igaz az IT rendszerekre, mint az ICS/OT rendszerekre. Ebben a nyilvántartásban célszerű nem csak a hardver- és szoftverkomponenseket nyilvántartani, hanem az egyes rendszerelemek (kiemelten a vezérlők, PLC-k és RTU-k illetve egyéb L1 és L0 eszközök) konfigurációit is tárolni és az egyes komponensek közötti hálózati kommunikáció adatait is célszerű az eszközleltárban feljegyezni.
A hálózatbiztonsági monitoring a biztonsági tevékenység detekciós részének kulcsa. Ez a tevékenység OT rendszerek esetén szintén nem tér el nagyon az IT rendszereknél megszokottaktól, azonban arra mindenképp érdemes felkészülni, hogy az ICS/OT rendszerek gyártói gyakran kizárólag a saját, bevett módszereik szerint és a saját eszközeiket felhasználva támogatják például a rendszerlogok átadását egy központi loggyűjtő vagy SIEM-megoldásnak.
A rendszerek működésének alapvető karakterisztikáitól való eltéréseket illetve a fenyegetéselemzés során a szervezet birtokába jutott kompromittálást jelző információkat, jeleket keresve lehet biztonsági eseményeket észlelni, amiknek vizsgálata során lehet eldönteni, hogy az adott esemény a szervezet számára nem érdekes vagy a vizsgált esemény valójában egy incidens.
3. Incidenskezelés
Az első két fejezet IT és OT rendszerek esetén nem térnek el jelentősen (ahol mégis, azt ugye már jeleztem), az incidenskezelés viszont már nem ilyen.
Ha egy biztonsági eseményről a vizsgálat/kiértékelés (triage) során kiderül, hogy valójában incidens, akkor indul az incidenskezelés folyamata, ami az ICS/OT környezetekben meglehetősen különböző lehet attól, mint amit a hozzám hasonló, IT irányból érkező szakik korábban megszokhattak. Mert mi is a legfontosabb feladat egy IT rendszert megfertőző malware esetében? Egyértelmű: mielőbb megszűntetni magát a fertőzést, ha kell, ehhez eltávolítjuk a fertőzött rendszereket a hálózatról és csak a sikeres malware-eltávolítás után engedjük őket újra csatlakozni. Ezzel szemben OT hálózatok esetében egy malware-fertőzött rendszer esetén az első kérdés, amit tisztázni kell, az az, hogy a kártékony kód okoz-e bármilyen problémát az adott rendszer alapvető funkcióinak működésében és okoz-e bármilyen performancia-csökkenést? Ha pedig mindkét kérdésre nemleges a válasz, akkor teljes mértékben elfogadható az, hogy a komolyabb problémát nem okozó malware-t a következő karbantartásig ott hagyjuk az OT rendszerünk adott komponensén és majd csak az érintett üzem leállásával járó karbantartás során távolítjuk el.
Ez az egyetlen példa remekül mutatja, hogy mennyire sokrétű tudással kell rendelkeznie az ICS/OT rendszerek incidenskezelését végző csapatnak és miért kulcsfontosságú, hogy ne csak forensics szakértőket, hanem folyamatirányítási mérnököket is bevonjunk ezekbe a tevékenységekbe.
4. Fenyegetés és környezet kezelése
Ha az incidenskezelés során sikerült beazonosítani a támadók által használt eszközöket (malware-eket és egyéb, általában nem feltétlenül kártékony, de a célpont szervezet számára ártó szándékúnak számító szoftvereket), akkor következhet ezek vizsgálata és elemzése. Fontos különbséget tenni a már ismert kártékony kódok és a még nem ismert, de gyanús kódok között a további vizsgálat szempontjából. Különösen fontos, hogy ha találunk egy gyanús kódot, akkor hogyan vizsgáljuk ki és bizonyosodjunk meg arról, hogy az általunk talált szoftver vajon valóban kártékony-e. Egyes nézetek szerint a gyanús kódokat nem célszerű publikusan elérhető sandbox alkalmazásokba (mint például a VirusTotal) feltölteni, mert a legtöbb ilyen szolgáltatásnál az előfizetők értesülhetnek arról, ha új fájlt töltenek fel ellenőrzésre és a komolyabb, állami/titkosszolgálati háttérrel rendelkező APT-csoportok hajlamosak monitorozni az ilyen szolgáltatásokat, hogy értesüljenek arról, ha valamelyik általuk fejlesztett/használt kártékony kódot felfedeznék. Emiatt célszerű lehet saját (vrituális és bare-metal) sandbox környezetekben vizsgálni a gyanússá vált szoftvereket.
Az elemzések során kinyert információk dokumentálása szintén fontos feladat, mert ezek később hasznos bemenetként szolgálhatnak az 1. pontban ismertetett fenyegetéselemzéshez (és nem csak a saját szervezetünkön belül, de ha a szervezetünknek vannak kapcsolatai különböző információmegosztást végző közösségekben, akkor akár a partnerek számára is).
