Múlt év végén egy felmérésben arról kérdezte nagyvállalati informatikai vezetőkkel a Forrester, hogy mi jelenti számukra biztonsági szempontból a legnagyobb kihívást. A válaszadók 67 százaléka azt válaszolta, hogy az informatikai és biztonsági operáció összehangolása. A Forrester szerint most kezd visszaütni az az évtizedes gyakorlat, hogy a két terület még mindig silókban működik (pedig már túl vagyunk egy SOA – azaz service oriented architecture – hullámon, és nyakik benne vagyunk a felhőkorszakban). Ez ha nyikorogva is, de működik. Így aztán erre a helyzetre is érvényes lesz a mondás: ami nem romlik el, ne akard megjavítani.

Kell egy mindenki által elfogadott igazság

A helyzet azonban az, hogy ez a rossz működési szisztéma lassítja a szervezet reagálási sebességét: közel két héttel hosszabb ideig tart az IT-sebezhetőségek kijavítása, mint ott, ahol az IT és a biztonsági csapat zökkenőmentesen tud együttműködni. Ez már olyan nagy időtáv, amit forintosítani is lehet a kockázatok értékelésénél.

A Forrester által megkérdezett informatikai vezetőknek egyébként a fele állította határozottan a kérdőíven, hogy pontosan ismeri vállalata IT-környezetének sebezhető pontjait, és az azokból eredő kockázatokat, és nagyságrendben ugyanennyi CIO állította, hogy teljes képpel rendelkezik az informatikai környezetben lévő összes szoftverről és hardverről. Aztán a személyes interjúk során kiderült: ez az 50 százalék mindkét kérdésnél jó esetben 20 vagy még annál is kevesebb. A hiányos információk alapján döntés hozni pedig köztudottan kockázatos.

A Forrester kutatásából is látszik, hogy kell egy olyan közös pont a teljes szervezetnek, amely a biztonsági problémákra összpontosít, azonosítja az eszközöket, folyamatokat és az azokban rejlő kockázatokat. Az IT-vezető vagy a vállalat menedszmentje pedig ez alapján meghozza a szükséges döntéseket. Ez lehet a Security Operations Center (SOC): egy szervezet saját biztonságról való közös tudásának forrása, amely – mint azt sorozatunk előző részében bemutattuk – mindig a teljes rendszert egyben látja a végpontoktól, adott esetben szenzoroktól (IoT-biztonság) a felhőig.

A SOC építésében sincs királyi út

Egy (hatékony) SOC felépítése azonban komoly kihívás. Ráadásul nincs mindenhol alkalmazható, bevált recept (legfeljebb olyan jó gyakorlatok, melyeket más környezetben már sikerrel alkalmaztak), hiszen minden szervezet egy kicsit más.

A szakemberek két dologban értenek egyet. Az első az, hogy a SOC-ot a kompetenciák (szakembergárda), a folyamatok, valamint az alkalmazandó technológiák összehangolt működésére kell építeni. Azaz nem elegendő, hogy veszünk egy sor technológiát, és eléje ültetünk szakembereket.

A másik alapvetés pedig az, hogy a SOC felépítését mindig a szervezetet fenyegető veszélyek modellezésével kell kezdenie. Milyen veszélyforrásokkal, kockázati tényezőkkel kell számolni? Hogyan néz ki egy fenyegetés? És hogyan kell azt kezelnie a SOC-nak? Ezekből az információkból lehet elkészíteni azt a mátrixot, amiből mindent le lehet vezetni: milyen tudású emberekre és technológiákra lesz szükség, és azok milyen folyamatok mentén működnek és kapcsolódnak a szervezet egyéb részeihez?

Vannak azonban mindhárom területre általában igaz megállapítások, melyeket érdemes megfogadni.

Szakemberek, azaz a kompetencia: érdemes első körben néhány magasan képzett és tanúsításokkal rendelkező szakemberben gondolkodni. Olyanokban, akik ismerik a jelenlegi biztonsági riasztásokat és forgatókönyveket, emellett kellően nyitottak, hogy tudásukat ismeretlen szituációban alkalmazzák. Ők azok, akiknek a feladatát még magas fokú automatizáció esetén sem nagyon lehet és érdemes megspórolni.

Folyamatok, eljárások: ebből a szempontból az IT-biztonság viszonylag szerencsés helyzetben van, mert az biztonsági iparban ezekről többé-kevésbé létezik egy közmegegyezés, valamint rengeteg szabvány (például NIST, PCI, HIPAA stb.), melyek eleve megkövetelnek bizonyos folyamatokat.

Ami pedig a SOC-ban, illetve az egész szervezetben kialakítandó folyamatokat illeti, abban – ahogy azt az előző részben már említettük – érdemes követni a szerepalapú felépítést (monitoring – content team – fenyegetésfelderítők – vadászok – reagálók stb.), mert így könnyebben tervezhető az eszkalációs folyamat is.

Technológia: bár a SOC felépítésben ez az utolsó lépés, általában erről esik a legtöbb szó. A látszólag legegyszerűbb megközelítés, hogy a vállalatok tegyenek bele a SOC-ba minél több technológiát, és akkor biztosan biztonságban lesznek. Ennek azonban szerencsére a büdzsé mindig határt szab – lényegében menedzselhetetlen káoszt eredményezne, ha válogatás nélkül mindent használni akarnának. A biztonsági cégek is egyre nagyobb figyelmet szentelnek a SOC-okvanhasznált eszközök egymáshoz hangolására, hangszerelésére. Szinte minden széles biztonsági portfólióval rendelkező IT-biztonsági gyártónak vannak ilyen speciális, ún. orchestration eszközözei (. Az RSA például a NetWitness SecOps Managerébe, de egy kifejezetten a SOC-okra szabott orchestrator eszköze is van, a NetWitness Orchestrator.

Jövőálló technológiára van szükség

És itt el is érkeztünk a technológia egyik sarokkövéhez: a menedzselhetőséghez. Olyan technológiára van tehát szükség, ami hatékonyan kezelhető, integrálható és kellően elasztikus is, hogy a vállalat változó igényeihez lehessen igazítani.

Manapság a munkaerőhiány még egy szempontot érdemes figyelembe venni: az automatizálhatóságot. A legtöbb biztonsági megoldást szállító cég igyekszik erre is, amit jelez a fejlett SIEM (Security Information and Event Management) eszközök terjedése. Emellett a biztonság területén – például a viselkedéselemzésben – egyre általánosabb a mesterséges intelligencia és a gépi tanulás alkalmazása, de az öntanuló elemző eszközök sem tekinthetők ma már különlegesnek.

A SOC azonban, bár a tapasztalatok azt mutatják, hogy hatékony, meglehetősen drága mulatság: sem a szakemberek, sem a technológia nem olcsó. A következő alkalommal megnézzük a költségeket, és hogy milyen alternatív utak vannak arra, hogy egy vállalat biztosítsa IT-infrastruktúrájának a SOC-szintű biztonságot.