Itt a portálon egészen biztosan sokan olvasták a két egymást követő hírt, miszerint a Microsoft hibája miatt világméretű kiesés történt több különböző organizáció szolgáltatásaiban, majd ugyanez a Crowdstrike miatt.
Megszokhattuk már a Microsofttól az ilyen-olyan bakikat, amelyek - elsősorban a felhős szolgáltatásoknál - részleges kieséseket szoktak okozni. Új elem, hogy ezúttal egy - a kiberbiztonság területén gyakorlatilag piacvezető cég - bakija is komoly kiesést okozott.
Sajnálatos módon sokan nekiálltak vagdalkozni, mi több, ostobaságokat összehordani az események kapcsán. Járjuk körül a témát együtt, ismerjük meg mélyebben - közben pedig helyére teszem a hülyeségeket is.
CROWDSTRIKE
A cég egy amerikai, kiberbiztonsági fejlesztéseket, megoldásokat és szolgáltató vállalkozás. 2011-ben alapították a céget, az egyik társalapító a McAfee korábbi CTO-ja, George Kurtz. 2013-ban elindították a Falcon platformjukat, ami többek között végpontvédelmet és fenyegetés felderítési szolgáltatásokat nyújtott. 2014-ben segítséget nyújtottak öt kínai katonai hacker elleni vádemelésben az amerikai Igazságügyi Minisztériumnak. 2015-ben a Google több alkalommal is befektetett a cégbe, összesen majdnem félmilliárd dollár értékben. 2017-ben a Crowdstrike értéke elérte az 1 milliárd dollárt, 100 milliós éves bevétellel. 2018 közepére a cég saját állítása szerint elérte a 3 milliárdos értéket és olyan befektetőket vonzott magához, mint a Telstra, vagy a Rackspace. 2020-tól a cég célzatosan vásárolt fel más vállalkozásokat, amelyeknek termékeit aztán integrálta a Falcon platformba. Ezekkel együtt ami ma kiberbiztonsági területen bárkinek eszébe juthat megoldás vagy szolgáltatás, nagy eséllyel a Crowdstrike portfóliójában benne van.
Nyilván az események kapcsán nagyon sok cégről hallottunk, mint kliensekről, de a hírekben szereplők mellé tennék még néhányat: Google, Intel, Amazon, Mercedes-AMG PETRONAS és természetesen az amerikai kormányzat. Világszerte összesen körülbelül 29 ezer ügyfele van mindenféle szektorból, legyen az privát, vagy publikus.
Hirdetés
Az 1/10/60 perces szabály
Aki a kiberbiztonsági iparban dolgozik, tisztában van vele, hogy a rendszerekbe való behatolás során az időtényező kritikus: minél előbb felfedni a támadó jelenlétét, elzárni a rendszer többi részétől, majd kirúgni.
A Crowdstrike a saját keretrendszerében ezt úgy fogalmazta meg: átlagosan 1 perc áll rendelkezésre a támadás felfedezésére, 10 perc a megértésére és 60 perc az orvoslásra és a támadás megállítására. Nagyon ambíciózus elképzelés, de nyilván elérhető - megfelelő mennyiségű pénz birtokában.
A Crowdstrike platformja és szolgáltatásai enyhén szólva sem olcsók - cserébe a cég értéke a tegnapi nap folyamán (csütörtökön, tőzsdezáráskor) meghaladta a 83 milliárd dollárt.
Hogyan működik az EDR?
Annak megértéséhez, hogyan működik az EDR, meg kell értenünk a védelmi gyűrűket. Ezek a védelmi gyűrűk biztosítják, hogy az adatok és a funkcionalitás védve legyenek a hibáktól és a rosszindulatú viselkedéstől. Az x86-es CPU-k védett módjában az elmélet 4 különböző védelmi gyűrűt ismer: ring 0-n fut az OS kernele, az 1-es és 2-es gyűrűben az eszközmeghajtók, a 3-asban pedig az alkalmazások. Működésük szerint a 0-s irányból kifelé csökken a szükséges privilégiumszint, ellentétes irányban természetesen értelemszerűen nő. Két egyszerű példa: amikor Windows alatt telepítünk egy bármilyen programot, aminek mondjuk szüksége van a webkamerára, a telepítő elindításakor felugrik egy UAC prompt; jováhagyásunk esetén a programnak biztosítjuk a ring 1-ben futó eszközmeghajtó elérését, ami vissza fog jelezni nekünk a webkamera használatáról. Másik példánk lehet pl. a Firefox: maga a böngésző user oldali része természetesen a ring 3 vendége, de szüksége van a hálózat elérésére, amelynek a meghajtója magasabb privilégiumszinten fut.
A valóságban a szoftveres implementációk nem feltétlenül követik az elméletet, gondoljunk csak a DOS-ra: valós módban nem létezett semmiféle védelem, a memóriamenedzser kivételével minden ring 3-ban futott, míg az OpenVMS mind a 4 gyűrűt használta. Még számos egyéb különböző megoldást lehetne nyomozni, vizsgálni, említeni, de ez az írás nem erről szól, viszont az említése nélkülözhetetlen annak megértéséhez, hogyan tudott ekkora kiesést okozni a Crowdstrike elcseszett frissítése.
Szeretném előre bocsátani: noha az AV és az EDR megoldások nem azonosak - és legfőképpen nem ekvivalensek -, én mégis egyként kezelem őket ebben az írásban, mert a biztonsági gyűrűk szempontjából vizsgálva mindkettő a ring 0-ban fut - megakadályozva bármilyen humán és nonhumán támadót a védelem kikapcsolásában.
Windows alatt a kernel a ring 0-ban fut, ahol a Falcon EDR egy része is. Bármilyen, itt bekövetkező hiba azonnal BSOD-ben végződik.
Lózungok és ostobaságok
Természetesen az eset nem hagyta hidegen a portál olvasóközönségét, de megdöbbentő, hogy egyes vélemények milyen szélsőségekben végződnek.
Előre szeretném leszögezni: a Crowdstrike hibázott, nem is kicsit és meg is fog fizetni érte, mert a piac korrigálni fog, illetve korrigált is, mert a mai napon a cég részvényeinek értéke legalább 10%-ot csökkent, plusz nyilván indulnak kártérítési perek, jókora összegekkel. Valószínűleg elegendő tesztelés nélkül küldték ki a frissítést, noha nehezen elképzelhető, milyen körülmények kellettek ehhez.
A userek egyike sosem hallott még a cégről és valószínűleg a Falconról sem, mivel "sikeresen" scamnek vélte a Crowdstrike-ot. Nyilván az Intel, a Google képtelenek különbséget tenni egy scammer és egy komoly kiberbiztonsági platform között...
Más vélemények azt sugallták, hogy az informatikai rendszerek túlzottan kitettek egy platform felé, ezért ezt a platformot állami irányítás alá kellene vonni. Nem kezdem el ecsetelni, hogy ez mekkora baromság, viszont annyit hozzátennék, hogy a probléma előtt a piac döntött: piacvezető a Falcon (még), igaz, a második helyezett nem sokkal van lemaradva; mire befejeződik az összes per, ez már nem így lesz. Az összekapcsolt rendszerek nagyfokú integrálásáról pedig elsősorban a COVID tehet: amikor mindenki az otthonába kényszerült, meg kellett oldani a munkaerő távoli munkájának mind a sebességét, mind a biztonságát, a felelősséget pedig lehetőség szerint rálőcsölni más(ok)ra.
A harmadik nagy marhaság, amit megemlítenék: valaki szerint az éles rendszerekkel megegyező tesztrendszert kell építeni, akár ÉLES adatokkal feltöltve. Nos, az éles rendszerrel megegyező másolat továbbra is élesnek minősül, továbbá azt sem lehet mondani, hogy modellezi a produktív rendszert, mert a modellezés szabályai szerint a modell csak a főbb tulajdonságaiban egyezik meg az alannyal. Ezen túlmenően éles adatok szerepeltetése nem éles rendszeren GDPR-ba ütközik, akkor is, ha illetéktelenek nem férnek hozzá - hogy ne beszéljünk egy esetleges data breachről...
Biztos vagyok benne, hogy még előkerül 1-2 olyan marhaság, ami ide kívánkozna, de nem célom pellengérre állítani a fentiek elkövetőit, inkább felhívnám a figyelmet arra, hogy az ostoba szélsőség csak ostoba szélsőség, nem pedig konstruktív ötlet vagy javaslat.
