RPMNet Kft.

	1. Kell egy jó ~~csapat~~... módszertan!
	Bármilyen informatikai felmérés, vizsgálat alapja a helyesen kiválasztott módszertan. Mit mérjünk, mit vizsgáljunk, mihez képest kell jónak, jobbnak lenni? Melyik követelményrendszer teljesítését tűzzük ki magunk elé? Legyen ISO 27001? Kövessük az ITIL módszertanát? Valósítsunk meg CobIT alapú biztonságmenedzsmentet? Alakítsunk ki saját testreszabott eljárásokat valamelyik nemzetközi sztenderd alapján? Szerencsére valamennyi követelményrendszer elég jó, hiszen mind a JPÉ (Józan Paraszti Ész) mentén készült, az ördög azonban a részletekben rejlik. Rengeteg energiát spórolhatunk meg a helyesen kiválasztott módszertannal.
	2. Kockázatelemzés
	A kockázatok azonosítása, hatásuk vizsgálata (bekövetkezési valószínűség + hatás) elengedhetetlen a helyes méretezés és a testreszabott védelmi megoldások kialakításához. A jogosultsági rendszer, a hozzáférések kezelése, a távoli elérés, a hálózatok kialakítása és átjárhatósága, az operációs rendszerek és az alkalmazások, a mentés-visszaállítás, a rosszul tervezett vagy konfigurált infrastruktúra kockázatokat hordoz.
	3. Adatvédelem
	Jogszabályi előírás a magyarországi és uniós előírások szerinti adatvédelmi megoldások kialakítása és alkalmazása. Helyes adatvédelmi politikával megelőzhetők a vitás helyzetek, a szervezet biztonsággal teljesíti az audit előírásokat. A szolgáltatás magában foglalja a meglévő szabályzatok felülvizsgálatát, a hiányzó elemek pótlását, terület érintett résztvevőivel folyatatott interjúkat, illetve a részletes megoldási javaslatokat. A tanácsadás az elvi követelményrendszer felépítése mellett gyakorlati megvalósítási módszertant is kínál, mely illeszkedik a meglévő informatikai megoldásokhoz, alkalmazásokhoz.
	4. Információs vagyon felmérés
	Bármilyen informatikai biztonsági megoldás kialakítását megelőzően javasolt az informatikai vagyon felmérése. A tapasztalatok szerint sok esetben a vállalat vezetése sincs tisztában, milyen informatikai vagyon felett rendelkezik, annak mekkora az értéke (vagy hiányában mekkora veszteséget jelent), valamint melyek a védendő elemei. Az informatikai vagyon felmérése során az egyes elemek besorolása megalapozza a későbbi kockázatelemzést és segít a döntések meghozatalában. Az informatikai vagyon részletes felmérésének eredményeképp kialakíthatók a költséghatékony védelmi zónák és részletes védelmi intézkedések.
	5. Folyamatok átvilágítása
	Sokszor a folyamatok rejtik magukban a kockázatokat. A megszokott, bebetonozott eljárások hibái a használóik számára nem is tűnnek fel. Az egyik leghatékonyabb, azonnali eredményt mutató és számos esetben a legalacsonyabb ráfordítást igénylő megoldás a folyamatok áttekintése, kockázat alapú átvilágítása.
	6. Sérülékenység vizsgálat
	Biztonságos rendszer márpedig NINCS! - találkozunk nap, mint nap, számtalan helyen ezzel a mondással. Részben igaz, manapság felelősen nyilatkozó informatikus ennek ellenkezőjét nem állítja. Egy kikapcsolt rendszer lehet elég biztonságos, hisz nem nyújt támadási felületet. A még meg sem álmodott rendszer még jobb, abban biztosan nincsenek rejtett hibák. Persze ez nem csak az informatikára igaz, hiszen nincsenek soha el nem romló autók, soha le nem zuhanó repülők, örökéletű háztartási cikkek és mindig helyes döntést hozó emberek sem. Félretéve a humort, lehet elegendően biztonságos rendszert kialakítani, amely kockázatarányos és mind árában mind szolgáltatásaiban az elvárt biztonságot képes szavatolni. A sérülékenység vizsgálat a kérdéses rendszer(ek) egy vagy több pontján, akár kívülről, akár belülről történő, a legfrissebb ismert sérülékenységeket vizsgálva deríti fel az esetlegesen gyenge pontokat, azonnali megoldási javaslatokat is kínálva.
	7. Szabályozórendszer kialakítása
	Az utasítások, szabályozók akkor jók, ha a szervezetben egységesen, mindenkire nézve kötelezően, közérthetően és elérhető módon valósítják meg. A jó szabályozó nem az íróasztal fióknak készül - olyan, mint egy jó kézikönyv, azonos típusú kérdéseket feltéve azonos válaszokat ad. A szabályzatok célja kettős, egyrészt dokumentálja és lefedi a folyamatokat, másrészt irányelveket ad a nem tárgyalt, vagy később felmerülő kérdések tisztázására.
	8. Képzés
	Az átlagos felhasználó sok esetben nincs tisztában azzal, melyik tevékenysége milyen kockázatot rejt magában. Autó vezetéshez egy 150-200e Ft értékű jogosítvány megszerzése a feltétel. A számítógépek használatához nincs ilyen előírás, holott a károkozás anyagi mértéke sokszor nagyobb egy gépkocsi értékénél. Az információs vagyon felmérése során azonosított értékek védelme a műszaki-technikai és szabályozási megoldásokon túl nagy mértékben függ a felhasználók magatartásától is. A biztonságtudatosság kialakítása és rendszeres frissítése segít a rendelkezésre álló megoldások helyes használatában és a veszélyt rejtő magatartások kerülésében. A képzés lehet egyéni, csoportos, vagy akár távoktatás, e-learning kurzus, a tanúsításnak megfelelő dokumentációval.
	9. Üzletmenet-folytonosság
	Ááá, ez velünk nem fordulhat elő – gondolják sokan. Miért köt mégis biztosítást a felelősen gondolkodó ember? Nincs baj, amíg nincs baj! – szoktuk mondani. Mi történik, ha mégis bekövetkezik az összeomlás? Semmi, vagy majdnem semmi, ha erre jó előre felkészülünk. Az üzleti folyamatok és az őket kiszolgáló informatikai megoldások, háttérrendszerek összehangolása elengedhetetlen. Az egyes szolgáltatások SLA-ja (szolgáltatási szint megállapodás) meghatározza az informatikai rendszer elvárt rendelkezésre állását és visszaállítási idejét, a maximális kiesési időt, a 100%-osan, vagy csak korlátozottan elérendő szolgáltatásokat és még rengeteg egyéb paramétert. Természetesen ismerni, vagy legalább becsülni kell a kiesés okozta veszteséget versus a megvalósítás és fenntartás költségeit. Az üzletmenet-folytonossági terv kezdődhet egy szolgáltatási szint leírással és egészen a katasztrófa tervig terjedhet.
	10. Követelményspecifikáció
	Mit kell tudnia egy programnak? Bármilyen alkalmazással szemben támasztott követelményt le kell tudni fordítani a gép, a programozó nyelvére. A követelményjegyzék a szoftverrel szemben támasztott funkcionális és egyéb elvárásokat rögzíti. Egy jól megírt és kellően részletes követelményspecifikáció birtokában kellő programozói tapasztalattal szinte bárki képes elvégezni kódolást. A fejlesztés ideje lerövidül, a programozóknak szinte nincsenek kérdései, nem kell önállóan semmit kitalálniuk, nem értenek félre semmit.
	11. Informatikai biztonsági incidenskezelés
	Mi a teendő, ha valamilyen információbiztonsági incidens következik be? Mit kell tenni, kinek kell szólni, ki fog döntést hozni, ki fogja elhárítani? Mintha nem lenne elérhető a weboldalunk, nem elérhető a kereskedelmi igazgató, mit tegyek? Leállíthatom a szolgáltatást, vagy várjak? Informatikai biztonsági incidensek alatt olyan - az információbiztonsággal összefüggő - nem várt eseményeket értünk, melyekre nem alakíthatók ki rutineljárások, ám a szervezeteknek mégis fel kell készülniük ezek kezelésére. Az incidenskezeléssel szembeni legfontosabb elvárások a gyorsaság, a hatékonyság és a teljes körűség.
	12. Tűzfalrendszerek biztonsági vizsgálata
	Tűzfalak alkalmazása napjainkra általánossá vált a vállalati informatikai rendszerekben. Az ám, de a rendszer már több éve üzemel. Azóta többször átszerveztünk, egészen új informatikai megoldásokat használunk, semmi nem úgy működik mint a telepítésekor. Vajon a beállításai követték a változásokat? Az architektúra és azok egyes komponenseinek részletes konfiguráció- és szabályelemzésével biztosítható a biztonságos megoldások kialakítása. Auditori szemmel a megszokott, a szervezeten belül általánosan elfogadott és alkalmazott beállítások felülvizsgálata során kialakítható az iparági elvárásoknak megfelelő határvédelem.
	13. Naplóelemzés
	Az eseményeket naplózni kell, ebben mindenki egyetért. A naplózás kérdése a dolgok könnyebbik fele. A naplóállománynak azonban olyannak kell lennie, hogy a szükséges információ visszakereshető legyen belőle. Megoldást kínálunk a szervezet informatikai rendszerben zajló folyamatainak azonosíthatóságát biztosító naplózó rend kialakítására. Szintén fontos probléma a keletkezett naplóállományok feldolgozása. A naplózó és naplóelemző rendszereket használhatjuk utólagos azonosításra, hibás működés kiszűrésére, vagy akár riasztások generálására is. Az események összefüggéseiben történő elemzése, egymásra hatásának vizsgálata, majd az eredményekről jelentések készítése biztosítja az informatika rendszerek rendeltetésszerű, rendellenes, szokatlan vagy hibás működésének átfogó monitorozását.