# Egy SOC. Két világ. | IT- és OT-biztonság üzemeltetése > Terjessze ki a biztonsági üzemeltetést az IT-ról az OT-ra a Yellow Cube-bal: közös láthatóság, egyirányú leválasztás, célzott beruházás és egyértelmű reagálási felelősségek. - Kanonikus URL: https://yellowcube.eu/hu/how-a-soc-works/ - Kiadó: Yellow Cube - Nyelv: hu - Kapcsolat: hello@yellowcube.eu Észleljen és reagáljon ott, ahol a gyorsaság számít. Előzzön meg és válasszon le ott, ahol a fizikai biztonság számít. Építsen egy központot, amely érti a különbséget. 01 / A működési modell ## [**Egy SOC.** Két eltérő felelősség.]() A biztonsági műveleti központ (SOC) az a csapat, technológia és működési folyamat, amely a biztonsági jelzéseket döntésekké alakítja. Bizonyítékot gyűjt, kivizsgálja a lényeges eseményeket, megfékezi a támadásokat és fejleszti a védelmet. Egy konzol megvásárlása csupán a kezdet: minden súlyos incidensnek kell felelőse lennie, hajnali háromkor is. Az informatikában (IT) az identitások, alkalmazások és adatok védelme az elsődleges, miközben az üzlet folyamatosan változik. Az üzemtechnológiában (OT) a biztonságos fizikai folyamat megőrzése a cél: az energiatermelés, vízkezelés, vasúti közlekedés vagy egy gyártósor működése. **Közös kép a támadásról. A környezethez illő reagálás.** Egy kompromittált irodai laptop leválasztása észszerű lehet. Egy ipari vezérlő leválasztása a folyamatfüggőségek ismerete nélkül önmagában is incidenst okozhat. A Yellow Cube megközelítése ### Egy közös irányítóközpont. **Világos reagálási határok.** **IT** **Gyors észlelés. Magabiztos elhárítás.** Fektessen gyors észlelésbe és reagálásba; az automatizálást korlátozza a végpontokon, identitásokon és üzleti rendszereken jóváhagyott műveletekre. **OT** **Tartsa kívül a fenyegetést.** Helyezze előtérbe a leválasztást és a megelőzést. Figyeljen passzívan, és az ipari beavatkozásokról az üzemért felelős emberek döntsenek. **SOC** **Egyesítse a bizonyítékokat.** Kapcsolja össze az IT és OT jelzéseit egy közös vizsgálatban, megnevezett incidensfelelősökkel és tesztelt eszkalációs tervvel. ### IT-támadási lánc 1. Felderítés 2. Bejutás 3. Tartós jelenlét 4. **Oldalirányú mozgás** Lehetséges átjutás az OT-ba → 5. Incidens 6. Helyreállítás ### OT-támadási lánc 1. Felderítés 2. Oldalirányú mozgás 3. Incidens 4. **Kár** A körforgás itt véget érhet. Az IT helyreállhat, majd újrakezdheti a ciklust. Az OT-ban a fizikai kár visszafordíthatatlan lehet. Az átjutáshoz elérhető OT-belépési pont szükséges. Kialakítás. Üzemeltetés. Folyamatos fejlesztés. ### [A SOC olyan szolgáltatás, amelyet **folyamatosan építünk.**]() Először állapodjunk meg a felelősségekről és a reagálás határairól. Ezután ismételjük a ciklust az üzlet, az üzem és a fenyegetések változásával. **Egy közös kép.** IT-reagálás. OT-biztonság. 1. #### Új jelzések bekötése Térképezze fel az eszközöket, felelősöket és kritikus folyamatokat. Kösse be a jóváhagyott EDR-, NDR-, identitás- és alkalmazásadatokat az Open XDR-be; az új OT-adatfolyamokat csak a leválasztás ellenőrzése után engedje élesbe. 2. #### A leválasztás biztosítása és ellenőrzése Építse ki és tesztelje az OT-ból IT felé vezető egyirányú megfigyelési útvonalat. Keresse a megkerülési lehetőségeket, használat előtt hagyjon jóvá minden exportált adatfolyamot és offline importeljárást; változás után ellenőrizze újra. 3. #### Bizonyítékgyűjtés és kivizsgálás Figyelje az adatfolyamok állapotát és a hiányzó naplókat. Az eszközök kritikusságát figyelembe véve kapcsolja össze a végponti, hálózati és identitásbizonyítékokat, hogy feltárja az eseményeket és rangsorolja az incidenseket. 4. #### Döntés, reagálás és helyreállítás Jóváhagyott forgatókönyvekkel fékezze meg az IT-fenyegetéseket, és ellenőrizze a helyreállítást. Az OT-beavatkozásokat tesztelt helyi eljárások szerint eszkalálja az üzemi és biztonsági felelősökhöz. 5. #### Tanulás, karbantartás és fejlesztés Értékelje az incidenseket és gyakorlatokat, hangolja az észlelést, tartsa karban a szenzorokat és csatlakozókat, majd tesztelje újra a reagálást és helyreállítást. A lefedettségi hiányokat és konfigurációváltozásokat építse be a következő ciklusba. **Minden változás újabb ellenőrzést indít.** Új integrációk, infrastruktúraváltozások és incidensek után, valamint tervezett gyakorlatokon tartson felülvizsgálatot. A tanulságok alapján javítsa a lefedettséget, és ellenőrizze újra a leválasztást. [OT-biztonság: útmutató \[6\]]() 02 / A következményekből induljunk ki ## [Azonos költségkeret. **Más súlypont.**]() Kiindulópontunk a biztonsági erőfeszítések elosztásához egy érett környezetben. Ezek a Yellow Cube tervezési ajánlásai, nem iparági átlagok vagy beszerzési képletek. IT ### Találja meg. Fékezze meg. Állítsa helyre. **30%** megelőzés **70%** észlelés és reagálás Költsön az első védelmi vonalon túl is: viselkedésre, identitásra, hálózati láthatóságra, kivizsgálásra és hatékony reagáló csapatra. OT ### Tartsa kívül a támadást. **70%** megelőzés **30%** észlelés és reagálás A súlypont a leválasztás, az ellenőrzött átvitel és a biztonságos mérnöki munka legyen. Tartsa meg a passzív megfigyelést és a begyakorolt reagálási tervet. Ezt az arányt a hatókör meghatározása után alkalmazza. Nem jelenti az identitásvédelem, mentések, képzések vagy biztonságtechnikai tervezés elhagyását. A tényleges beruházást az érettség, a kitettség és a meghibásodás következményei határozzák meg. Miért változik az egyensúly az IT és OT között? | Döntési szempont | Üzleti IT | Ipari OT | | --- | --- | --- | | Mit kell megvédeni? | Információkat, identitásokat és a szolgáltatások folytonosságát. | Embereket, berendezéseket és a fizikai folyamatot. | | Módosítható a rendszer? | Gyakran megvalósítható a rendszeres frissítés és a végpontok központi kezelése. | A változtatások a gyártói támogatástól, teszteléstől és karbantartási időablakoktól függnek. | | Visszafordítható a beavatkozás? | Sok művelet visszaállítható, bár az üzleti fennakadás ekkor is számít. | Egy leállítás vagy elveszett vezérlőjel azonnali fizikai következményekkel járhat. | | Mit állít vissza a helyreállítás? | A tesztelt mentések visszaállíthatják a rendszereket; az ellopott információt nem tehetik meg nem történtté. | A mentések visszaállíthatják a logikát és konfigurációkat; a sérült gépeket nem javítják meg. | 03 / IT: számítsunk arra, hogy valami átjut ## [A tiszta fájlvizsgálat **nem jelent tiszta környezetet.**]() **82%** a CrowdStrike 2025-ös észlelései közül **kártevő használata nélkül történt**. 82% kártevő nélküli · 18% egyéb észlelés. CrowdStrike 2026 Global Threat Report. Ez a vállalat által megfigyelt észleléseket írja le, nem a világ összes támadásának megoszlását. [\[1\]]() Ez nyomós érv a szignatúrákon túli vizsgálat mellett. A támadó lopott hitelesítő adatokkal jelentkezhet be, távoli adminisztrációs eszközzel élhet vissza, vagy legitim parancsértelmezővel mozoghat a környezetben. A „kártevő nélküli” tágabb fogalom a „fájl nélkülinél”: olyan tevékenységet is magában foglal, amelyhez egyáltalán nem kell rosszindulatú program. A living-off-the-land támadások a rendszergazdák által megbízhatónak tartott eszközöket fordítják támadásra. A kérdés az, ki használta ezeket, melyik gépen, milyen jogosultsággal, és mi történt utána. A végponti észlelés és reagálás (EDR), a hálózati észlelés és reagálás (NDR), az identitásesemények és a felhőnaplók mind a történet egy részét tárják fel. A kiterjesztett észlelés és reagálás (XDR) összekapcsolja ezeket. ### Építsen megbízható 30%-os alapot ****10%** Végponti megelőzés** A szignatúraalapú vírusvédelem az alap, amelyet viselkedésalapú megelőzés, alkalmazásvezérlés és exploitvédelem erősít. A megelőző réteg akkor is fontos, ha nem lát minden támadást. ****10%** Biztonsági állapot** Szüntesse meg a felesleges kitettséget, túlzott jogosultságokat, gyenge identitásbeállításokat és kockázatos felhőkonfigurációkat. A leltár és a kijelölt felelősség a megállapításokat számonkérhető feladatokká alakítja. ****10%** Sérülékenység- és javításkezelés** Rangsoroljon a kihasználhatóság, a kitettség és az üzleti hatás alapján. Ellenőrizze a javítás tényleges telepítését: az ütemezett javítás még nem megszüntetett sérülékenység. Az AI-val támogatott kutatás tovább növeli a nyomást ezen a területen. Az Anthropic 2026 márciusában arról számolt be, hogy a Mozillával két hét alatt 22 Firefox-sérülékenységet találtak. Ez a gyorsuló feltárás konkrét példája, nem bizonyíték arra, hogy a CVE-k számának minden növekedését az AI okozza. A gyakorlati tanulság: rövidítsük le az utat a releváns sérülékenységtől az ellenőrzött javításig. [\[2\]]() ### Tegye működőképessé a másik 70%-ot Több egymással versengő, valós idejű víruskereső futtatása minden laptopon általában nem észszerű biztonsági beruházás: a kompatibilitás, a teljesítmény és az üzemeltetés válik problémává. A dedikált fájlátviteli ellenőrző más feladatot lát el, ezért egy szabályozott ellenőrzési ponton több motort is egyesíthet. Az IT-ban a fennmaradó erőfeszítést a viselkedés megfigyelésére, az incidensek kivizsgálására és gyors beavatkozásra fordítsa. Előre hagyjon jóvá visszafordítható lépéseket, például nem kritikus munkaállomás leválasztását vagy kockázatos munkamenet visszavonását. A kiemelt jogosultságú és szolgáltatásfiókokat szigorúbb szabályok védjék. Tesztelje a mentésből történő visszaállítást és a katasztrófa utáni helyreállítást; a mentési feladat „sikeres” állapota egyikre sem garancia. 04 / A támadás egy folyamat ## [A támadók **nem születnek** az OT-hálózatban.]() Bejutási lehetőségre, használható jogosultságokra és a folyamat befolyásolásának módjára van szükségük. Minden függőség egy lehetőség a támadás megszakítására. 1. 01 ### Hídfőállás megszerzése Adathalászattal ellopott identitás, nyitott szolgáltatás vagy kompromittált beszállítói eszköz adhat kezdeti hozzáférést. **Figyelje: identitás, e-mail, végpont** 2. 02 ### Az útvonal előkészítése A támadó feltérképezi a rendszereket, hitelesítő adatokat gyűjt és átjárót keres az üzem felé. **Figyelje: EDR, NDR, kiemelt hozzáférések** 3. 03 ### A határ átlépése Távoli munkamenet, megbízhatónak tekintett átvitel vagy karbantartó eszköz válhat a bejutási kísérlet útvonalává. **Előzze meg: leválasztás, átviteli szabályzat** 4. 04 ### A folyamat befolyásolása A logika, beállítások vagy kezelői láthatóság módosítása a kiberincidenst fizikai kárrá alakíthatja. **Védje: helyi biztonság és mérnöki kontroll** Ez szemléltető útvonal, nem ígéret arra, hogy órák vagy napok állnak rendelkezésre a reagáláshoz. Egyes támadók gyorsak, mások hetekig készülnek. Az IT-hídfőállás korai észlelése megszüntetheti a tervezett hozzáférést, még mielőtt elérnék az ipari rendszereket. Az interaktív távvezérléshez kommunikációs útvonal kell. A megfelelően kialakított, csak kifelé vezető dióda megszünteti a visszautat. Az előre telepített kártevők, belső szereplők és kompromittált adathordozók azonban élő, parancsokat gépelő operátor nélkül is cselekedhetnek. A leválasztásnak és a fájlalapú megelőzésnek együtt kell működnie. Az IT-hídfőállás leválasztása elvághatja az attól függő támadót. Ez nem bizonyítja, hogy egy már kompromittált OT-környezet tiszta. 05 / A referencia-architektúra ## [Egyesítse a bizonyítékokat. **Tartsa meg a határvédelmet.**]() Helyezze el a védelmi elemeket egy ismert Purdue-térképen: EDR az IT-végpontokon, passzív NDR mindkét hálózatban, egy közös irányítóközpont a leválasztási határ fölött. Purdue-nézet · alulról, a fizikai folyamattól felfelé olvassa[A teljes architektúra felfedezése]() L5–L4 ### Vállalati IT **Munkaállomás**EDR-ügynök **Laptop / felhasználói végpont**EDR-ügynök **Üzleti kiszolgáló**EDR-ügynök IT-hálózati kapcsoló · TAP / SPAN másolat **IT NDR-szenzor** Az IT-forgalom tükrözött másolatát figyeli. EDR-végpontesemények + NDR-hálózati bizonyítékok Egy irányítóközpont · IT-oldal ### Stellar Cyber Open XDR Végponti és hálózati bizonyítékok összekapcsolása egy közös vizsgálatban. - EDR az IT-munkaállomásokon és kiszolgálókon - IT NDR-megfigyelések - OT NDR-bizonyítékok a diódán keresztül **AI-val támogatott elemzés és reagálás** Automatizálja a jóváhagyott IT-műveleteket. Az üzemi döntéseket eszkalálja az OT-mérnökökhöz. L3.5 ### Hardveresen kikényszerített leválasztás A megfigyelési adatok elhagyhatják az OT-t. Nincs visszirányú munkamenet vagy SOC-vezérlési út az üzembe. **Egyirányú adatdióda**Csak OT-ból IT felé OPSWAT vagy Waterfall Validált export / replikáció A védett OT-zónán belül ### OT NDR-szenzor **Kizárólag tükrözött forgalom.** A forgalomrögzítő interfész az OT-kapcsoló vagy TAP másolatát figyeli. Passzív rögzítés. Nincs adatútba épített blokkolás. Ebben a tervben nincs aktív szondázás. Csak jóváhagyott megfigyelési bizonyítékok kerülnek ki a fenti diódán keresztül. L3–L2 ### OT-üzemeltetés és vezérlés **Mérnöki munkaállomás** **HMI / SCADA** **Historian adattörténeti rendszer** OT-kapcsoló / TAP · tükrözött másolat az OT NDR-szenzorhoz A termelési forgalom az OT-hálózaton marad. A szenzor külön megfigyelési másolatot kap. L1–L0 ### Vezérlők és fizikai folyamat **PLC-k / RTU-k** **Hajtások / terepi érzékelők** **Gépek / folyamat** A helyi vezérlési és biztonsági rendszerek az üzem hatáskörében maradnak. ### A másolat láthatóságot ad. A dióda megőrzi a leválasztást. A SPAN- vagy TAP-tükrözés önmagában nem elegendő az OT-biztonság megteremtéséhez és az IT/OT-határ védelméhez. A hardveresen kikényszerített egyirányú út megakadályozza, hogy a SOC ezen a megfigyelési kapcsolaton forgalmat küldjön vissza. Egyszerűsített Purdue-elhelyezés; a tényleges zónákat a telephely kialakítása határozza meg. A panelek közötti folytonos vonalak biztonsági bizonyítékokat továbbítanak; a szaggatott vonalak tükrözött forgalmat jelölnek. Az OT-megfigyelés passzív, és csak jóváhagyott megfigyelési adatok haladnak át a diódán. Validálja a szenzor–átjáró párosítást, és biztosítsa a szenzorok helyi frissítését. Lásd: [Stellar Cyber telepítési útmutató \[8\]](). ### Mit jelent itt az „airgap”? A szó szerinti légrésnél nincs hálózati kapcsolat. Ez a kialakítás hardveresen kikényszerített egyirányú határral őrzi meg a leválasztást az adatexport mellett. Nem tévesztendő össze egy szokásos tűzfalszabállyal, amely módosítható, hogy visszirányú OT-munkameneteket engedjen. A syslog az OT-n belül összegyűjthető, majd azon kívül újra kibocsátható. Az FTP és más kétirányú protokollok kompatibilis replikációs vagy proxyvégpontokat igényelnek; egy normál FTP-munkamenet nem halad át egyszerűen egy egyirányú vezetéken. A Waterfall dokumentálja ezt a biztonsági megfigyelési megközelítést, az OPSWAT pedig optikai diódákat és átjárókat kínál. [\[3\]]() [\[4\]]() ### Tervezze meg a teljes határt Minden jóváhagyott adatfolyamhoz határozza meg az irányt, protokollokat, adatmennyiséget és veszteségtűrést. Az adatgyűjtő olyan helyre kerüljön, ahol bejövő felhőmenedzsment nélkül működhet; ezután ellenőrizze a pufferelést, az időszinkronizációt és a szenzorfrissítéseket. A termékkombináció működését koncepcióigazolással bizonyítsa. Vegyen leltárba minden alternatív útvonalat: gyártói VPN-eket, két hálózathoz csatlakozó laptopokat, vezeték nélküli kapcsolatokat, mobilmodemeket és közös adminisztratív bizalmi kapcsolatokat. A dióda a saját útvonalát védi; egy figyelmen kívül hagyott kapcsolat alááshatja az architektúrát. A szenzorok elhelyezését külön kezelje attól a feltételezéstől, hogy minden szenzor bármely diódán keresztül működik. 06 / OT: előzze meg a veszélyes állapotot ## [Ellenőrizze az átvitelt. **Védje a folyamatot.**]() Az OT olyan lehetőséget ad, amelyet egy úton lévő laptop ritkán: a bejövő fájlok néhány ellenőrzött átviteli pontra koncentrálhatók. A karbantartási csomagok, konfigurációs fájlok és beszállítói adathordozók ellenőrizhetők, mielőtt elérnék a védett mérnöki munkaállomást. Az OPSWAT MetaDefender Kiosk és Core többmotoros ellenőrzéssel és megfelelő formátumoknál tartalomhatástalanítással és -rekonstrukcióval támogatja ezt a megelőzésközpontú megközelítést. A cél a mélyebb határellenőrzés, naplózható kiadási döntéssel. A vizsgálat nem garancia; az aláírt firmware-ek és vezérlőprogramok továbbra is eredetiségellenőrzést és mérnöki validálást igényelnek. [\[5\]]() 1. **Azonosítás.** Rögzítse a beszállítót, a célberendezést, a fájltípust és az üzleti célt. 2. **Ellenőrzés.** Alkalmazza a jóváhagyott motorkészletet, fájlszabályzatot és tisztítási folyamatot. A hibás vagy nem egyértelmű eredményeket helyezze karanténba. 3. **Jóváhagyás.** Felhatalmazott felelős igazolja, hogy a tartalom megfelelő, kompatibilis és elvárt. 4. **Átvitel és ellenőrzés.** Csak a jóváhagyott fájlt adja ki, őrizze meg az auditnyomot, és ellenőrizze a használatát a tervezett karbantartási időablakban. ### Ha a javítás nehéz, tudatosan alkalmazzon kompenzáló védelmet Az OT-javításkezelés korlátozott, de nem hiányzik. Egyes eszközök támogatási ciklusa hosszú, vagy szűk leállási időablakokkal rendelkeznek; mások nem fogadnak ügynököt vagy szokásos vizsgálatot. Vezessen eszköz- és sérülékenységleltárt, lehetőség szerint alkalmazzon gyártó által jóváhagyott frissítéseket, és dokumentálja a kompenzáló intézkedéseket, ha a javításnak várnia kell. A passzív megfigyelés továbbra is értékes. Váratlan mérnöki tevékenység, új eszköz vagy megváltozott kommunikációs minta még a károkozás előtt jelezhet problémát. Egy veszélyes vezérlőparancs utáni észlelés azonban túl kevés időt hagyhat a beavatkozásra. Az architektúra előbb akadályozza meg a hozzáférést ehhez a parancsútvonalhoz, és csak utána támaszkodjon a visszaélés észlelési versenyére. **Egy vezérlő konfigurációját visszaállíthatja. Egy törött turbinát nem állíthat helyre mentésből.** Az OT-nak is szüksége van tesztelt mentésekre, helyreállítási eljárásokra, tartalék alkatrészekre és biztonságos újraindítási tervekre. Ezek a helyreállítást segítik; a fizikai következményeket nem törlik el. A NIST kifejezetten az OT-biztonság részének tekinti a megbízhatóságot, a fizikai biztonságot és a helyreállítást. [\[6\]]() Ellenőrzött import / OPSWAT MetaDefender ### [Egy átviteli pont. **Nyolc ellenőrzési réteg.**]() Építsen bizonyosságot, mielőtt a fájl eléri az OT-t. Minden réteg más kérdésre ad választ a forrásról, tartalomról vagy viselkedésről. **Kiindulás: nem megbízható beszállítói fájl vagy adathordozó** Azonosítsa a valódi fájltípust, vizsgálja meg a támogatott archívumokat, és tartsa karanténban az eredetit a szükséges ellenőrzések idején. Visszatartva az átviteli állomáson 1. Forrásszabályzat #### [Származási ország]() Ujjlenyomatok és metaadatok alapján azonosítsa a támogatott szoftverek földrajzi eredetét. Az ismeretlen vagy korlátozott eredetű elemeket a szervezet szabályzata szerint küldje felülvizsgálatra. 2. Reputáció és összefüggések #### [Fenyegetésfelderítés]() Kapcsolja össze a fájl reputációját, az ismert fenyegetésjelzőket és a viselkedési információkat. Jelezze a rosszindulatú infrastruktúrához, kapcsolódó kártevőkhöz vagy ismert kampányokhoz fűződő kapcsolatokat. 3. Ismert szoftvergyengeségek #### [Fájlalapú sérülékenységértékelés]() Telepítés előtt ellenőrizze a támogatott futtatható állományokat, telepítőket és könyvtárakat ismert sérülékeny összetevők és verziók után kutatva. Tartsa kívül az elkerülhető CVE-ket az üzemen. 4. Metascan többmotoros vizsgálat #### [Több mint 30 víruskereső motor]() Egyesítse a világ vezető gyártóinak kártevőellenes motorjait. A széles szignatúralefedettség egymást kiegészítő heurisztikákkal és más észlelési módszerekkel erősíti az ismert fenyegetések elleni megelőzést. 5. Prediktív Alin AI #### [Prediktív AI]() Futtatás előtt vizsgálja a fájl strukturális és szemantikai jeleit a potenciálisan rosszindulatú, korábban ismeretlen fájlok azonosításához. Adjon korai védelmi réteget a nulladik napi fenyegetésekkel szemben. 6. Viselkedéselemzés #### [Adaptive Sandbox]() Emulálja a fájlokat elkülönített elemzőkörnyezetben, hogy feltárja a rejtett kártékony tartalmakat, kitérő viselkedést és hálózati visszahívásokat, mielőtt a termelésbe jutnának. 7. Érzékenyadat-szabályzat #### [Proactive DLP]() Észlelje az érzékeny információkat, hitelesítő adatokat és szabályozott tartalmakat. Tiltsa vagy takarja ki őket az átviteli szabályzat szerint; ez különösen értékes a védett környezetből kilépő fájloknál. 8. Hatástalanítás és rekonstrukció #### [Deep CDR]() Építse újra a támogatott dokumentumokat jóváhagyott tartalomból, eltávolítva a kockázatos aktív elemeket. Gondoljon egy PDF tiszta oldalakból való újraalkotására: friss, használható fájl jön létre az eredeti szkriptekbe és beágyazott objektumokba vetett bizalom helyett. VISSZATARTÁS / ELUTASÍTÁS #### A sikertelen vagy befejezetlen ellenőrzés megállítja a kiadást. Helyezze karanténba a fájlt kivizsgálásra. Az ismeretlen eredményekről és szabályzati kivételekről az illetékes felelősnek kell döntenie. JÓVÁHAGYÁS / ÁTVITEL #### Adja ki a jóváhagyott fájlt az offline folyamaton keresztül. Támogatott dokumentumoknál használja az újraépített másolatot. Javítások és firmware esetén őrizze meg az eredeti gyártói csomagot; ellenőrizze az aláírást, a tervezett verziót és célrendszert, majd bevezetés előtt tesztelje az elvárt javítást. **Javasolt ellenőrzési folyamat, nem rögzített termék-végrehajtási sorrend.** Az ellenőrzések párhuzamosan is futhatnak; a folyamatot a fájltípus, a szabályzat és a licencelt modulok határozzák meg. A CDR támogatott dokumentumformátumokra való, nem aláírt firmware újraépítésére. A fenyegetésfelderítés segíti a javítás értékelését; a mérnöki validálás igazolja, hogy az valóban az elvárt hibát javítja-e. Nem jön létre élő IT–OT kapcsolat. [Az OPSWAT MetaDefender technológiáinak megismerése]() 07 / A Yellow Cube univerzális platformja ## [**Egy közös vizsgálat.** A megfelelő specialistákkal a háttérben.]() Az ügyfél eszközei és üzemeltetési képességei köré építkezzen. Tartsa meg a hasznos védelmi elemeket, pótolja a hiányokat, és kapcsolja össze a bizonyítékokat. 01 / Irányítóközpont ### Stellar Cyber Open XDR Egyesítse a végponti, identitás-, hálózati, felhő- és biztonsági termékekből származó bizonyítékokat egy közös vizsgálatban. Az AI-val támogatott gazdagítás, korreláció és osztályozás csökkenti a zajt, és a lényeges incidensekre irányítja az elemzők figyelmét. A reagálás automatizálása a jóváhagyott forgatókönyveket és a ténylegesen megadott jogosultságokat követi. [\[7\]]() 02 / Láthatóság ### NDR az IT- és OT-környezetben Figyelje a forgalmat ott is, ahová végponti ügynök nem telepíthető. A Stellar Cyber OT-útmutatója közös elemzőplatformon támogatja a hálózati szenzorokat és ipari naplóforrásokat. Ellenőrizze a protokoll-lefedettséget és az üzemi telepítési korlátokat; az „univerzális” közös vizsgálati modellt jelent, nem minden eszközön azonos láthatóságot. [\[8\]]() 03 / Szakemberek éjjel-nappal ### Cynet + CyOps A Cynet végpontvédelmet és észlelést egyesít 24×7 szakértői szolgáltatással. Válassza az ügyfélhez illő szolgáltatási szintet és előre jóváhagyott elhárítási jogkört. A lefedettség a megállapodás szerinti Cynet-környezetre vonatkozik; nem jelenti a Stellar Cyberhez kapcsolt összes külső eszköz automatikus üzemeltetését. [\[9\]]() 04 / Az ipari határ ### OPSWAT + Waterfall Használja a MetaDefendert ellenőrzött fájlvizsgálati és átviteli folyamatokhoz. A jóváhagyott adatútvonalakhoz válasszon OPSWAT- vagy Waterfall-egyirányú megoldást. Ezek egymást kiegészítő architekturális szerepek; a pontos kombinációt, protokolltámogatást és karbantartási folyamatot a partnerrel validáljuk. ### Vonja be a portfólió többi elemét is Egy gyanús parancsértelmező többet mond, ha összekapcsoljuk az azt megelőző e-maillel, a használt identitással és az elért adatokkal. A projekttől függően a Yellow Cube az alábbi speciális képességekkel egészítheti ki a védelmet. A csatlakozók elérhetőségét és reagálási jogosultságait egyenként ellenőrizzük. **Állítsa meg és tárja fel a bejutási útvonalat** IronScales az e-mail-védelemhez; Whalebone a DNS-biztonsághoz; WithSecure vagy Cynet a végpontvédelemhez; iVerify a mobileszközök kockázataihoz. **Szabályozza a hozzáférést és a mozgást** Stormshield: hálózati szegmentáció; Imprivata a kiemelt hozzáférésekhez; A10 Networks a DDoS- és alkalmazás-/API-védelemhez. **Értse meg a szándékot és a hatást** Group-IB: fenyegetésfelderítés és külső kitettség; Varonis az adatbiztonsághoz; Teramind a belső kockázatok összefüggéseihez. A MailStore az e-mailek archiválását támogatja, amely a rendszermentéstől különálló igény. **Igazolja az üzemeltetési képességet** Cymulate a védelmi intézkedések validálásához; CYBER RANGES és Yellow Cube HackLab a gyakorlati feladatokhoz, vizsgálati készségekhez és begyakorolt eszkalációhoz. [A teljes termékmátrix megtekintése →]() [A védelmi elemek elhelyezése az architektúrában →]() 08 / AI egyértelmű működési határokkal ## [Automatizálja a munkát. **Határozza meg a jogköröket.**]() Az AI gazdagíthatja a riasztást, összekapcsolhatja a kapcsolódó eseményeket, összefoglalhatja a vizsgálatot, és javasolhat vagy végrehajthat engedélyezett beavatkozást. Tévedhet is. A téves pozitív riasztások kiszűrését hangolt, auditálható és felülvizsgált folyamatként kezelje, ne ígéretként arra, hogy minden lezárt riasztás ártalmatlan volt. Az első incidens előtt állapodjanak meg egy beavatkozási mátrixban. Az automatizálást a bizonyosság, az eszköz kritikussága és az üzleti környezet határozza meg. A bizonyíték, döntés és művelet maradjon együtt, hogy az elemző rekonstruálhassa a történteket. Automatizálás szabályzat alapján ### Rutinszerű IT-elhárítás Gyűjtsön bizonyítékot, nyisson ügyet, értesítse a felelőst, és válasszon le egy kifejezetten jóváhagyott, nem kritikus végpontkategóriát. Rögzítse a műveletet, és biztosítson helyreállítási útvonalat. Jóváhagyás szükséges ### Szélesebb hatású beavatkozások Kiemelt fiók letiltása, közös kiszolgáló leválasztása vagy hálózati hozzáférés módosítása csak a megállapodott eszkalációs szabályok szerint történjen. Egy szolgáltatásfiók több üzleti folyamatot is kiszolgálhat. Az OT-jogkör helyben marad ### Üzemi változtatások Eszkaláljon az üzemeltetési és biztonsági személyzethez. Vezérlőmódosításhoz, folyamatleállításhoz és újraindításhoz validált helyi eljárásokat használjon. A vállalati SOC-forgatókönyv ezeket nem indíthatja el vakon. A támadó célja lehet a védők túlreagálása is. A szükségtelen termelésleállást okozó téves riasztás is elérheti a zavarkeltés célját. A válasz nem az OT-riasztások figyelmen kívül hagyása: a SOC bizonyítékait mérnöki jogkörrel és biztonságos döntési folyamattal kell összekapcsolni. 09 / A koncepciótól a működő szolgáltatásig ## [Kezdjünk egy valódi telephellyel. **Igazoljuk a teljes folyamatot.**]() A partnerek üzleti lehetősége az üzemeltetési képesség: tervezés, integráció, validálás és folyamatos szolgáltatás az ügyfél meglévő beruházására építve. 1. 01 ### Térképezze fel a környezetet és következményeket Azonosítsa a kritikus folyamatokat, IT-függőségeket, meglévő eszközöket és minden IT/OT-kapcsolatot. Állapodjanak meg, mely rendszerek választhatók le, és ki felel az egyes döntésekért. Az eredmény körülhatárolt architektúra, nem általános bevásárlólista. 2. 02 ### Igazolja az adatútvonalakat Kössön be reprezentatív IT-adatforrásokat és passzív OT-telemetriát. Tesztelje a feldolgozást, időbélyegeket, diódareplikációt, pufferelést és az adatgyűjtők állapotát. Mutassa be, hogy a megfigyelési útvonal nem válhat vezérlési útvonallá. 3. 03 ### Gyakorolja a reagálást Gyakoroljanak IT-kompromittálódást, elutasított karbantartási fájlt és OT-rendellenességet. Tisztázzák, ki kapja az ügyet munkaidőn kívül, mire jogosult, és hogyan érik el az üzemi személyzetet. Az elhárítás mellett a helyreállítást is validálják. 4. 04 ### Üzemeltetés, mérés és fejlesztés Kövesse a telemetria lefedettségét, a kivizsgálási időt, a jóváhagyott elhárítás idejét, az átviteli kivételeket és a helyreállítási gyakorlatok eredményeit. Az ügyféllel tekintsék át a változott eszközöket, új kapcsolatokat és lejáró karbantartási kivételeket. ### Hozza el hálózati vázlatát és jelenlegi biztonsági eszközkészletét. Együtt dolgozhatunk a határvédelem kialakításán, a hiányzó láthatóságon, a megfelelő termékeken és a 24×7 működési modellen. Közösen meghatározhatunk egy gyakorlati koncepcióigazolást és olyan szolgáltatást, amelyet csapata magabiztosan nyújthat. [Beszéljünk a SOC-architektúráról ]()[A 24×7 menedzselt biztonság megismerése →]() ## [Források és további olvasnivalók]() A termékképességeket és kutatásokat 2026 szeptemberében ellenőriztük. A költségfelosztás és a referenciaterv a Yellow Cube ajánlásai. 1. [CrowdStrike · A 2026-os Global Threat Report bemutatása]() — 82% kártevő nélküli észlelés 2025-ben. 2. [Anthropic és Mozilla · Firefox-biztonsági kutatás, 2026. március](). 3. [Waterfall · Biztonsági megfigyelés egyirányú átjárókon keresztül](). 4. [OPSWAT · MetaDefender Optical Diode](). 5. [OPSWAT · MetaDefender Kiosk]() és [MetaDefender Core](); [A MetaDefender technológiai eszközkészlete]() (az egyes technológiák forrásai az ellenőrzési diagramon találhatók). 6. [NIST SP 800-82 Rev. 3 · Útmutató: OT-biztonság]() és [2026-os OT-mentési útmutató](). 7. [Stellar Cyber · Emberi szakértelemmel támogatott autonóm SOC](). 8. [Stellar Cyber · OT-telepítési útmutató](). 9. [Cynet · A CyOps szolgáltatás hatóköre és reagálási modelljei](). ## Mielőtt megtervezzük SOC-ját ### Le kell cserélnünk meglévő EDR- vagy SIEM-rendszerünket? Induljunk ki abból, ami működik. Az Open XDR a támogatott adatforrásokat közös vizsgálatba kapcsolhatja. Mielőtt összevonást vagy cserét javasolnánk, ellenőrizzük a csatlakozók lefedettségét, az adatmegőrzést, a duplikációt és a reagálási jogosultságokat. ### Az erős leválasztás mellett elhagyható az OT megfigyelése? Nem. A passzív megfigyelés és a helyi incidenskezelési felkészültség továbbra is nélkülözhetetlen a belső tevékenységek, karbantartási hibák, rosszindulatú importok és váratlan kapcsolatok miatt. A megelőzés csökkenti a kitettséget; a megfigyelés ellenőrzi, hogy a feltételezések továbbra is érvényesek-e. ### Ki felel az incidensért munkaidőn kívül? Ezt kifejezetten rögzítsük a szolgáltatás tervezésekor. A Cynet CyOps a szerződésben meghatározott Cynet-környezetet fedi le. A partnernek, az ügyfélnek és minden további SOC-szolgáltatónak tisztáznia kell a többi adatforráshoz tartozó felelősséget, az üzemi személyzet felé történő eszkalációt és a beavatkozási jogköröket. A közös konzol nem helyettesíti a szolgáltatási megállapodást. ### Kezdhetünk az IT-val, és később hozzáadhatjuk az OT-t? Igen. Először építsük ki az IT-észlelés és -reagálás alapjait, majd jóváhagyott útvonalakon adjuk hozzá az OT láthatóságát. Az ipari függőségeket már az elején térképezzük fel, hogy a korai IT-automatizálás véletlenül se zavarhassa meg az üzemet; a határvédelmet pedig a telephely csatlakoztatása előtt alakítsuk ki. ### Mit igazoljunk a szélesebb körű bevezetés előtt? Kezdjünk egy reprezentatív telephellyel, és a végleges eszközkészlet kiválasztása előtt állapodjunk meg a sikerfeltételekben. Mutassunk be hasznos IT- és OT-bizonyítékokat egy közös vizsgálatban, megbízható egyirányú telemetriát, ellenőrzött fájlimportot és begyakorolt reagálást megnevezett felelősökkel. Mérjük a lefedettséget, a kivizsgálási időt és az átviteli kivételeket. Az eredményből derüljön ki, mi működik, mi igényel mérnöki munkát, és mi szükséges a nagyobb léptékű üzemeltetéshez. ### Mi határozza meg a költségeket, és szükségünk van-e a teljes eszközkészletre? A szolgáltatás hatókörét a lefedendő eszközökhöz és kockázatokhoz igazítsuk. A végpontok és telephelyek száma, a telemetria mennyisége és megőrzése, az OT-szenzorok, átjárók, fájlellenőrző modulok, integrációk és a szolgáltatás lefedettsége egyaránt befolyásolja az ajánlatot. Tartsa meg a hatékony meglévő védelmet, és ott bővítsen, ahol hiányosság van. A bevezetési munkát, az ismétlődő licencdíjakat, a támogatást és az üzemeltetési felelősségeket az üzleti megállapodás külön részeiként rögzítsük. ### Kínálhatjuk ezt menedzselt szolgáltatásként ügyfeleinknek? Igen. A partnerek a felmérés, integráció, megfigyelés, ellenőrzött átvitel és folyamatos fejlesztés köré építhetnek szolgáltatást. A Yellow Cube támogatást nyújthat az architektúra és a termékek kiválasztásában, a műszaki validálásban és az értékesítési felkészítésben. Határozzuk meg, ki üzemelteti az egyes platformokat, ki kezeli a munkaidőn kívüli incidenseket, és mely lépésekhez kell ügyféljóváhagyás. Ügyfélvállalások előtt erősítsük meg a kiválasztott kombináció gyártói szolgáltatásainak hatókörét és üzleti feltételeit. ### Bővíthető az OT láthatósága a termelés megzavarása nélkül? Passzív megfigyeléssel és fokozatos bevezetéssel tervezzünk; a szenzorok elhelyezését, az adatexportot és a karbantartási időablakokat az üzemi csapat hagyja jóvá. Új adatfolyam engedélyezése előtt ellenőrizzük a megfigyelési útvonalat és függőségeit, valamint rögzítsük az átvételi és visszaállítási feltételeket. A megfigyelés nem válhat az üzemi adatútba épített vezérlési függőséggé. Az üzemi berendezések vagy hálózati kapcsolatok módosításához továbbra is telephelyspecifikus mérnöki jóváhagyás szükséges. ### Mit kell karbantartani a SOC éles indulása után? Jelöljön ki felelősöket a csatlakozókhoz, szenzorokhoz, átjáróreplikációhoz, fájlellenőrzési szabályzatokhoz és észlelési tartalmakhoz. Figyelje a hiányzó naplókat és az adatgyűjtők állapotát, ütemezze a jóváhagyott frissítéseket, vizsgálja felül a reagálási jogosultságokat, és gyakorolja az eszkalációt és helyreállítást. Eszköz- vagy kapcsolatváltozáskor ismét ellenőrizze a leválasztást. A rendszeres szolgáltatásértékelések kövessék a lefedettséget, a kivizsgálási időket, az átviteli kivételeket és az elvégzett feladatokat, hogy a SOC lépést tartson a védett környezettel. ### Mivel készüljünk az első beszélgetésre? Hozzon egy egyszerű hálózati vázlatot, a jelenlegi biztonsági eszközök listáját, az érintett telephelyeket és eszközöket, valamint az IT és OT közötti ismert kapcsolatokat. Mondja el, ki kezeli az incidenseket, milyen termelési korlátok számítanak, és hol hiányzik a lefedettség. Partnerként ismertesse a kínálni kívánt szolgáltatást is. Ebből kiindulva meghatározhatunk egy gyakorlati koncepcióigazolást és a következő műszaki, illetve üzleti lépéseket. ## Építsünk intelligensebb kibervédelmet együtt Hosszú távú partnerségeinket bizalomra, szakértelemre és közös sikerekre építjük. Akár vállalkozását fejlesztené, akár kiberbiztonsági kínálatát bővítené, akár innovatív megoldásokat vinne új piacokra, a Yellow Cube-ra számíthat. [Vegye fel a kapcsolatot a Yellow Cube disztribúcióval]() ## Forrásmegjelölés és hatókör Ez a Markdown-változat ugyanazokból a jóváhagyott tartalmi rekordokból készül, mint a kanonikus HTML-oldal. Hivatkozáskor a kanonikus URL-t használja.