BS7799 Az informatikai biztonság alapszabványának a BS7799 tekinthető. Hazai megfelelője a MSZ ISO/IEC 17799. A BS7799 magába foglalja a biztonságos szoftverfuttatási környezet minden elemét. A szabványnak való megfelelőség tanusítható. Az auditáló szervezetek a szabvány minden pontjának teljesülését vizsgálják. Minden auditáló szervezet kialakítja a saját módszeertanát, ez azonban nem érinti a lényeges követelményeket. A szabvány fontosabb követelményei: 1. Biztonságpolitikai nyilatkozat. Rendelkezik‐e a cég megfogalmazott biztonságpolitikával, követik‐e a változásokat? Ez a követelmény elsősorban a vállalatvezetés elkötelezettségét jelenti az informatikai biztonság megteremtésére. 2. Szervezeti szintű biztonság. 2.1 Biztonsági infrastruktúra. • • • • • • •
a vezetőség biztosít‐e fórumot a titkossági kérdések megvitatására? összehangolt‐e az informatikai védelem? kezelik‐e az egyedi biztonsági eseményeket? ellenőrzi‐e a vezetőség a biztonság hardver és szoftver komponenseit? van‐e képzett dolgozó az informatikai biztonság kezelésére? van‐e koordináció a szervezeti egységek között a biztonsági incidensek megelőzésére? végez‐e független szervezet biztonsági felülvizsgálatot?
2.2. Harmadik fél részvételének biztonsági kockázatai. • Harmadik fél részére milyen típusú elérések engedélyezettek, van‐e ezeknek besorolása? • Hogyan szabályozták a harmadik fél szerződéseiben a biztonsági kérdéseket? Milyen elvárások vannak. 2.3. Outsourcing Meg kell vizsgálni, hogy a külső feldolgozást végző szervezeteknél biztosított‐e az adatok megfelelő védelme? A szerződés szabályozza‐e a biztonsági kérdéseket? 2.4. Elszámolhatóság Olyan rendet kell kialakítani, ahol az információ kezelése követhető. Mindig kell ismernünk az információ helyét és felelősét. 2.5. Az információk minősítése Rendelkeznünk kell az információk besorolását meghatározó irányelvekkel. A besorolást az információval össze kell kapcsolni, és a besorolásnak megfelelő kezelést kell biztosítani. Pl. Az információ biztonsági szintje megoldható a dokumentumhoz kapcsolt meta‐adat‐ként. Ha egy dokumentumot hely szerint elérhetek, mert a számítógép adott könyvtárában van írási/olvasási jogom, ez nem elegendő, mert a személyes titkossági szintemnek is magasabbnak kell lenni, mint a dokumentum titkossági szintje. Ezzel a módszerrel a dokumentum egyes részei is védhetők. Lehetnek „takart” információk a dokumentumban. 3. Személyi biztonság • Meg kell határozni az egyes munkakörökhöz kapcsolódó biztonsági előírásokat. • Ellenőrizni kell az állandó munkatársakat megbízhatóság szempontjából. A humán erőforrás gazdálkodás feladata, hogy felfigyeljen pl. a magánéleti problémákra, a feltűnően
•
• •
• •
nagyösszegű vásárlásokra. A megfelelő emberek kiválasztása már a munkába állás elött is feladata a részlegnek. A dolgozókkal szerződésben kell közölni a biztonsági előírások megsértésének következményeit (volt rá példa, hogy egy világcég 1 év alatt több mint 8000 munkatárstól vált meg ilyen okokból). Az informatikai biztonság kérdéseit oktatni kell a dolgozóknak. A biztonsági incidenseket ki kell vizsgálni. A biztonsági incidenseknek el kell jutni a vállalat vezetéséhez. Fel kell tárni a hiányosságokat, ami ezt lehetővé tette az esemény bekövetkezését. Valamennyi szoftverhibából eredő hibás működést regisztrálni kell. A szoftveres hibák szinte mindig biztonsági rést is jelentenek, és ezeket folyamatosan javítani kell. A dolgozókkal szembeni eljárások esetén szigorúan ragaszkodni kell az írott szabályokhoz. Tanulni kell a hibákból.
4. Fizikai környezeti biztonság Gondoskodni kell róla, hogy a védett terület „határai” biztonságosak legyenek. Falak, ablakok, recepció, stb. Általában akkor jó a védelem, ha a védett területre közvetlenül nem lehet bejutni. Pl. az ügyfél‐tértől elválasztott alkalmazotti terület, és az alkalmazotti térből újabb recepció után érhető el a védett terület Gyakori megoldás, hogy az irodaházak igazgatósági szintje alatt van a számítógépterem. Az igazgatósági szintre csak speciális kártyával lehet fel‐liftezni. Az igazgatósági szinten kicserélt kártyával érhető el lefelé a védett terület. • Az egyes területekre való belépést célszerű funkció‐kódokhoz kötni. (Könyvelés, fejlesztés, stb.) • A védett területnek műszakilag biztonságosnak kell lenni Minimalizálnunk kell a víz, gáz, gőz és tűzveszélyt. Meg kell védenünk a vibrációtól, kémiai behatásoktól, elektromágneses terektől, elárasztástól. A „kényes” számítóközpontokat elektromágneses árnyékolással, automata tűzoltó rendszerrel, lezárható klíma‐csatornákkal építik. A kémiai hatásoktól való védelem sem egyszerű sok esetben. Vegyiüzemben (kénsav gyár) előfordulhat, hogy a számítástechnikai helyiséget túlnyomás alá kell helyeznünk, és túlnyomást biztosító levegőt több kilométer távolságból kell hoznunk, ahol kellően alacsony a légszennyezés mértéke. • Tápellátás biztonságossá tétele. A tápellátás biztonsága növelhető szünetmentes áramforrásokkal, aggregátorokkal. Gondolnunk kell arra is, hogy az aggregátorok beindítása és feszültségkiesés közti időt az akkumulátoros tápegységeknek kell áthidalni. Újabban a generátorok helyett használnak hidrogén cellákat is. A hidrogén cella sok szempontból kedvezőbb, mint a generátor. Nem zajos, nem vibrál, gyorsan indítható. Jelenleg (2009) 1W‐10 KW tartományban vannak kereskedelmi forgalomban hidrogén cella egységek. Van már rendszerbe állított hidrogén‐cellás meghajtású tengeralattjáró is. A technológia kidolgozott, így várható a kereskedelmi egységek teljesítményének növekedése . Építés alatt vannak 100‐250MW teljesítményű egységek is. • Kábelek védelme A kábeleket védenünk kell a mechanikai és hőhatásoktól. A kábelek égésekor mérgező gázok is felszabadulhatnak, ezért a belső terekben a kábelek szigetelőanyagainak nem szabad jelentős mennyiségű mérgező anyagot termelni égés közben. A korábbi évek tapasztalatai (Pl. Frankfurti repülőtéri tűz) azt bizonyították, hogy kevés halogén is halálos lehet a légtérben.
•
• •
A berendezések rendszeresen karban kell tartani. (Légcsatornák tisztítása!!) A karbantartó személyzetre, és végzett műveletekre is ki kell terjeszteni a biztonsági ellenőrzést. (A karbantartó elhelyezhet kamerát, lehallgató berendezést, stb.. a védett területen). Időnként egy‐egy szakterületre koncentrált ellenőrzést célszerű végezni. (Tűz, villamos betáp, automata oltórendszer,…) Készüléket, adathordozót ne engedjünk előzetes kontroll nélkül a védett területen kívülre szállítani. A diszkeken adatok maradhatnak, a gépekben benn maradhatnak cserélhető adathordozók.
5. Tevékenységek felügyelete • Minden tevékenységet azonosítani, és az eljárást dokumentálni kell. (Mentés, berendezések karbantartása, javítása, ....) • Az üzemszerűen használt programok minden módosítását dokumentálni kell. A változásoknak az „audit log”‐ban is meg kell jelenni. • A biztonsági incidenseket súlyosságuk szerint csoportosítani kell, és a lehető legrövidebb időn belül ki kell vizsgálni. • Az ismertté vált biztonsági incidensek ismételt előfordulása ellen intézkedéseket kell hozni. Lehetőség szerint meg kell akadályozni, hogy egy biztonsági incidens megismétlődjön. • Az üzemszerű működést (production) el kell választani a fejlesztésektől. Célszerű, ha a fejlesztés az üzemelő rendszertől független számítógépen történik. A szeparált működés egyben azt is jelenti, hogy általában a feldolgozott adathalmaz generált, vagy korábbi működésből származik. Komoly nehézségekkel kerülünk szembe, ha az új szoftvert a működő adatbázissal dinamikusan is megegyező adatokkal akarjuk tesztelni a fejlesztő rendszeren, mert az átállás után nincs már idő az éles rendszerrel végzett további tesztekre, sem az adatbázisok másolására. Az átkapcsolás után a produkciós rendszer azonnal az új szoftverrel működik, és rákapcsolódik a technológiára. (Pl. az adatbázis 100 TBnagyságrendű, és az engedélyezett átállási idő 5 perc.Nincs idő az adatbázis kiírására külső hordozóra). Az új szoftvernek gyakorlatilag azonnal át kell venni a rendszer vezérlését. Ilyen esetben meg kell oldani, hogy teszt ideje alatt a régi rendszer bemeneteit megkapja az új rendszer is, és párhuzamosan fusson a két rendszer. Az új rendszer kimeneteinek ellenőrzése sem egyszerű sok esetben. (Pl. egy repülésirányító rendszernek nagyon sok rendszer felé van kimenete: utas‐tájékoztatás, csomagirányítás, konyhai előkészítő, csomagszállító járművek, vám,…). Nehéz eldönteni azt is, hogy a kapott eredmények megfelelőek‐e. A régi rendszerrel való komparálás sem mindig célravezető, mert elképzelhető, hogy az új rendszer új szolgáltatásokat is tartalmaz, a korábbi szolgáltatásokhoz pedig másféle kiértékelő algoritmusokat használ. 6. Rendszertervezés, teljesítmény tervezés • Meg kell tervezni és felügyelni kell a rendszer erőforrásait. Pl. monitorozni kell a diszkek foglaltságát, a CPU terheltségeket, hálózati terhelést. Törekvések vannak arra, hogy a rendelkezésre álló teljesítményt dinamikusan osszuk el az alkalmazások között, a pillanatnyi igénynek megfelelően. Léteznek olyan megoldások is, ahol a számítógép „beépített” teljesítménye többszöröse annak, amit a vevő megvásárolt, és csak akkor aktiválja –bérleti konstrukcióban‐ a nagyobb teljesítményt, amikor arra ténylegesen szüksége van. • Meg kell határozni az új hardver, szoftver eszközök bevezetésének módját Ki kell alakítani”konfiguráció menedzsment”eljárásokat. Az „upgrade” eljárások rendkívüli gondosságot igényelnek, mert az átállást követően nem várt mellékhatások jelentkezhetnek. Sok vállalat a belső terjesztés elött megvizsgálja a szoftvergyártók módosításait, és csak belső
jóváhagyás után engedélyezi a frissítéseket. Számtalan működési, kompatibilitási probléma tud keletkezni egy módosítás után. Pl.: Felhasználhatók a korábbi adatmentések? A korábbi archívumokkal együtt tud működni? Hogyan kezeli az új szoftver a régebbi adatrekordokból még hiányzó új mezőket? Azonos‐e logikailag a régi és az új szoftver azonos nevű adata? 7. Védelem a rosszindulatú szoftverekkel szemben. Ez a terület a vírus, féreg és más rosszindulatú szoftverek elleni védelmet jelenti. Sajnálatosan ez napi küzdelmet jelent minden olyan rendszerben, ahol a külvilággal kapcsolatba kerül a rendszer. Nagyon nehéz ma már olyan rendszert találni, ahol a külvilág teljesen ki van zárva. Törekednünk kell a rendszerek zártságára, ahol lehetséges. Pl. : távadat‐gyűjtő rendszerben a nyílt internethez való csatlakozás helyett használjunk saját, kódolt rádiórendszert. A technológiai rendszert válasszuk le az irodai hálózatról, stb.. Gyakorlatban azonban a megvalósítás nem túlságosan egyszerű, hiszen a gyártásban keletkeznek adatok, melyeket el kell juttatni a vállalati vezetésnek. A gyártó‐sor adatait elemezni szeretné a minőségfelügyelet, az anyagbeszerzés, a beszállítókat koordináló osztályok, akik „hivatalból” a külvilággal vannak kapcsolatban. A szoftveres hibák, vírusok ellen a védelem fontos eszközei a mentések. Ha időben felismerjük, hogy a rendszerünk „fertőzött”, akkor a korábbi mentésekből a rendszer helyreállítható. Nehezebb helyzetben vagyunk, ha a tranzakciók csak elektronikusan léteznek. Ekkor a mentések közötti eseményeket is helyre kell tudni állítani. Ezt a célt szolgálják a „journal”‐nak nevezett megoldások, ahol gyakorlatilag minden műveletet lépésenként tárolunk. Belátható, hogy a journal mérete rendkívül gyorsan nő, és hosszabb időintervallumban áttekinthetetlen. 2‐3 mentésnyi időt szoktak a journal‐ban tárolni. Napi mentés esetén a journal kb. 2 napi tevékenységet tárol. Gyakorlatilag ez az egyetlen módszer, ami a szoftver hibák esetén használható. A redundáns rendszerek nem védenek a szoftveres hibák ellen!! . (Ugyanazzal a hibával terhelt adatot 1 helyett 6 különböző adathordozó felírunk, ettől nem lesz jobb helyzet). 8. „Háztartás”, karbantartás (Housekeeping) 8.1 Meg kell szervezni a mentéseket, (Back‐up). A fontos üzleti adatok másolatait minden esetben el kell készíteni. Menteni kell a konfigurációs beállításokat és üzemszerűen használt szerverek adatállományait, programjait. Nagyon fontos, hogy próbáljuk ki a visszatöltést a mentésekből. Ne akkor szembesüljünk az eljárás hibáival, amikor már valóban szükség van a visszaállításra. 8.2 Alakítsunk ki „operátor‐log” eljárásokat. A kezelők és főként a rendszergazdák tevékenységét célszerű naplózni. A jó operációs rendszerekben bármit definiálhatunk naplózandó eseménynek. Túlságosan sok eseményt nem érdemes naplózni, mert nem fogja senki átnézni. Ha a biztonsági előírások megszegésének gyanuja merül fel valakivel szemben, akkor annak minden műveletét célszerű naplózni. A biztonsági előírások megsértésének következményeit mindenkinek ismerni kell, és az eseményeket mindig ki kell vizsgálni. 8.3. Célszerű naplózni a rendszergazda tevékenységének a biztonságot érintő főbb műveleteit. o a jogosultságok beállításával kapcsolatos minden műveletet, o fájlok törlését, o új programok feltöltését, o védelmi beállítások megváltoztatását. A rendszergazda ellenőrízhetőségének természetesen az az alapja, hogy legyen a rerendszerben „auditor” jogosultság, amit a rendszergazda nem tud változtatni.
8.4. Naplózni kell a rendszer és programhibákat. Ha mód van rá, naplózni kell a javítási akciókat is. 8.5. Hálózat menedzsment • Alakítsuk ki egymástól függetlenül a hálózat és az operációs rendszerek felügyeletét. • Dolgozzunk ki eljárásokat a távoli eszközök elérésére, beleértve a vállalati, de nem védett felhasználói területen lévő eszközöket is. • Dolgozzunk ki speciális eljárásokat a nyilvános hálózaton átmenő adatok védelmére (pl.: virtuális privát hálózat, titkosítás, stb.) 8.6. Adathordozók kezelése • Eljárást kell kidolgozni a kivehető adathordozók kezelésére. ( Floppy, CD, kazetta, memóriakártya ). • A nem használt médiákat raktározni kell. Az „érzékeny” adatokat tartalmazó médiákról nyilvántartást kell vezetni. • Ki kell dolgozni az információtárolás rendszerét. Az eljárásnak meg kell akadályozni a jogosulatlan használatot és az információk módosítását. • A számítástechnikai rendszer dokumentációját biztonságosan kell kezelni. Az elektronikus dokumentáció elérését csak szűk körben célszerű engedélyezni. A felhasználói dokumentációkat, segédleteket azonban minden felhasználó számára elérhetővé kell tenni. 8.7. Információk és szoftverek cseréje • Formális szabályokat kell hozni a szervezeti egységek közötti információ és szoftvercserékre. • Az információ titkosságát a vállalat szemszögéből vizsgált „érzékenység” alapján kell meghatározni. ( Stratégiai tervek, bejelentés előtti állapotú szabadalmak, . .) • Gondoskodni kell az adathordozók biztonságáról szállítás közben is. • Különös gondossággal kell eljárni az elektronikusan bonyolított kereskedelmi tranzakciók esetén. (Ne vegyünk fel nem létező szervezetektől megrendelést, ne jussanak a vásárlás fizikai adatai a pénzügyi teljesítést igazoló szervezetekhez. • Gondoskodni kell az elektronikus levelezés okozta „adatszivárgás” megakadályozásáról, illetve a levelekkel érkező kártékony szoftverek szűréséről. (Vírusok, férgek, trójai programok). 9. Üzleti követelmények a hozzáférés‐védelem területén • A hozzáférési jogokat meg kell határozni, és dokumentálni kell. • A hozzáférési szabályokat a szerepkörökhöz, és ezen belül személyekhez kell kötni. • Az informatikai szolgáltatók számára is egyértelművé kell tenni a hozzáférési szabályokat. 9.1. Felhasználói hozzáférések menedzselése • Meg kell határozni a felhasználók regisztrálásának és törlésének rendjét. • A jogosultságok meghatározásának alapja a munkához szükséges információk elérésének ellenőrzött biztosítása. Jogosultságot csak regisztrált felhasználónak szabad adni. 9.2. A jelszavak kiadását formalizált eljárás keretében kell megoldani. A jogosultságokat normál felhasználóknál 6 havonta, kiemelt jogosultságok esetén 3 havonta célszerű ellenőrizni. 9.3. Felhasználói magatartás szabályozása • Meg kell határozni a felhasználói jelszavak karbantartásának, módosításának rendjét.
•
Műszaki eljárásokat kell kidolgozni a magukra hagyott számítógépek védelmére, a processzek automatikus lezárására.
9.4. Hálózat‐elérés szabályozása • Célszerű a hálózati szolgáltatások elérését címekhez (IP vagy hardver címek) kapcsolni.Ez csökkentia a szolgáltatások jogosulatlan igénybevételének kockázatát. • Ha lehetőség van rá, ki kell jelölni az elérési útvonalakat. A bejelentkezés helye (azonosítója) is rögzíthető szabályokban. (Pl.: A kényes adatokat tartalmazó állományok csak a védett számítóközpontban lévő terminálokról érhetők el.) • A távoli eléréseknél törekedni kell arra, hogy a belépés authentikált hálózatról történjen. (pl.: a cég egy másik, zárt hálózatáról). • A távoli diagnosztikai eljárásokat kiemelt figyelemmel kell kezelni, mivel ezek az eljárások mély betekintést engednek a rendszerekbe. 9.5. Operációs rendszer elérésének szabályozása . • A terminálok csak biztonságos „log‐on” mechanizmussal érhetik el az információs rendszert. • Meg kell tervezni a felhasználókat azonosító eljárásokat. (Tudás, birtoklás, biometria) • A jelszavak kezelésére megfelelő eljárást kell kidolgozni. Ebben meg kell határozni a jelszavak jellemzőit, a kötelező csere időperiódusokat. A jelszavakat titkosított formában kell tárolni a szervereken. • Azokat a szoftver eszközöket, melyek átírják az operációs rendszert, különös gondossággal kell kezelni. (Pl.: a gyári, hiteles másolatokat is ellenőrizni kell, hogy nem okoznak‐e hibát a futó alkalmazásban.) • A nyilvánosan elérhető terminálokat meghatározott idejű inaktivitás után le kell kapcsolni a rendszerről. 9.6 Alkalmazások elérésének szabályozása. • A magas kockázatú alkalmazások futtatási idejét korlátozni kell. • A különlegesen „érzékeny” alkalmazásokat célszerű, különálló, csak a meghatározott célra használt eszközökön futtatni. (Stratégiai tervek, kutatási eredmények, tesztspeciifikációk) • Használjuk a rendszer monitorozására alkalmas eszközöket! • Használjunk eseménykezelő log‐ot. • Figyeljük (monitorozzuk) a felhasználói aktivitást. • Szinkronizáljuk az órákat, hogy az audit‐log kiértékelhető legyen. 9.8. Mobil számítógépek, távmunka A mobil számítógépek kiemelt biztonsági kockázatot jelentenek. Egyrészt a gépeket nem védett helyen is használják, ami a tárolt adatokat veszélyezteti. Másrészt a biztonsági tűzfalak mögé behozhatunk veszélyes programokat, a vállalati védelmi rendszer megkerülésével. 10. Megfelelés az elvárásoknak. 10.1. Információs rendszerek fejlesztése és karbantartása. • A biztonsági kérdéseket az üzleti célú specifikációval együttesen, azonos szinten kell kezelni. • A biztonsági elvárásokat a fejlesztés megkezdése előtt meg kell határzni. 10.2. A felhasználói programok biztonságossága. • A bemeneti adatok ellenőrzését el kell végezni a hihetőség és a káros kódtartalom szempontjából. A bemenetekre küldött speciális vezérlőkarakterek sokféle támadás alapját képezik, ezekre fokozattan kell ügyelni. A speciális karaktereket szűrni kell a bemeneteken.
• • •
Elemezni kell a belső feldolgozás során megsérült adatok okozta kockázatot, a hibás adatok hatását a további feldolgozásra és az üzleti folyamatokra. Meg kell tervezni az elektronikus üzenetek ellenőrzését (levelek, adatállományok). Vizsgálni kell a dokumentumok hitelességét, sértetlenségét és teljességét. A kimenő adatokat ellenőrizni kell, hogy megfelelnek‐e az alkalmazásból adódó természetes követelményeknek, a várható értéktartományban vannak‐e, formátumuk megfelelő‐e.
10.3. Titkosítási folyamatok ellenőrzése. • Meg kell határozni a kriptográfiai védelem szintjét. • Össze kell rendelni a védelmi szinteket és az adtok titkossági szintjeit. • Az elektronikus dokumentumokat a változatlanság és hitelesség ellenőrzésére digitális aláírással kell ellátni. Figyelem! Nem minden fájl „dokumentum”. • Meg kell szervezni a kulcs karbantartási folyamatokat . Ha a kulcs előállítás, továbbítás szabványokon alapul, akkor elegendő a módszerek meghatározása. 10.4. Rendszerfájlok védelme • Ellenőrizni kell a rendszerfájlok sértetlenségét minden betöltés előtt. • A rendszertesztek alatt gondoskodni kell a használt adatbázisok „anonimizálásáról”. A rendszerteszthez használt adatbázisok nem tartalmazhatnak valós személyes adatokat. • A rendszerfájlok védelme érdekében a rendszerprogramok forrásfájljait különös gondossággal kell őrizni. A programkönyvtárakhoz való hozzáférést erősen korlátozni kell. 10.5. Biztonság és titkosság a fejlesztési folyamatban • Eljárást kell kidolgozni a változások követésére és dokumentálására. • A felhasználói programokat minden operációs‐rendszer váltás után tesztelni kell. A szoftvergyártó javító‐csomagjait csak korlátozottan használjuk. Csak azok a „javítások” alkalmazhatók, melyeknek származása biztonságosan azonosítható, és a felhasználói programok kompatibilitását ellenőriztük. • Gondot kell fordítanunk arra, hogy az újonnan szállított szoftvertermékek nem tartalmaznak „bombákat” és Trójai jellegű támadásra utaló kódrészleteket. 11.Üzleti folytonosság biztosítása. Az „üzleti folytonosság” általános fogalom az informatikai szolgáltatás folytonosságának jelölésére. Egy folyamatirányító rendszer esetén is beszélhetünk „üzleti folytonosságról”. Annyival több az „üzleti folytonosság”, mint a szűken vett számítástechnikai rendszer folyamatos működése, hogy nem elegendő egy hiba elhárítása, és a rendszer utolsó állapotának korrekt helyreállítása. Az üzemkiesés idején történt eseményeket is kezelni kell a rendszernek, és csak akkor fejeződik be a helyreállítási procedúra, amikor a műszaki helyreállítást követően a kiesett idő alatti eseményeket is bevittük a rendszerbe. Pl.: a kiesett időben papíron rögzített készletmozgásokat kézzel felvitték. Folyamatirányító rendszerekben a lokális számítógépek pl. kommunikációs hiba miatt kiesett időszakaszok eseményeit betöltötték a központi felügyeleti rendszer adatbázisába. Az üzleti folytonosság biztosítása érdekében • meg kell vizsgálni és nevesíteni kell a várható külső hatások (tűz, árvíz, készülék meghibásodás) következményeit az informatikai rendszerre. Stratégiai tervet kell kidolgozni a folytonosság biztosítására. • Ki kell dolgozni a rendszervisszatöltés módszereit, és tesztelni is kell az eljárásokat.
•
Meg kell határozni a helyreállítás sorrendjét. Meg kell határozni a komponensek aktiválásának sorrendjét.
12. Megfelelés a hivatalos szabályozásoknak. • Vizsgálni kell, hogy az informatikai rendszer megfelel‐e a hatályos jogszabályoknak, illetve szolgáltatási szerződéseknek. • Az informatikai rendszernek meg kell felelni a személyiségi jogokat védő szabályozásoknak.. Ez a kitétel jogilag kötelező, de a megvalósítása sok esetben szinte lehetetlen, vagy éppen a védett személyre nézve súlyosan hátrányos. Pl.: Egy kórházi rendszeren belül sem ad felmentést a törvény az alól, hogy egyes adatok csak a kezelőorvosra tartoznak. Hogyan látja el akkor felelősséggel a beteget az ügyeletes orvos? • Meg kell vizsgálni, hogy az informatikai rendszer nem sért‐e szerzői joogot, védjegyet, formatervi védelmet. A rendszernek meg kell akadályozni a nem vállalati célú alkalmazások futtatását, és jeleznie kell a jogtalan felhasználási kísérleteket. • A titkosításoknak meg kell felelni a nemzeti szabályozásoknak. (Egyes országokban korlátozzák a magán‐célra használt titkosítási algoritmusok típusát és alkalmazható kulcsok méretét). • Rendszeresen ellenőrizni kell a biztonsági rendszereket külső, hozzáértő szakértőkkel. Összefoglalás: Az informatikai rendszer védelméhez • Meg kell határozni a célokat mit kell védeni mitől, kitől kell megvédeni milyen jól kell megvédeni • Meg kell fogalmazni a biztonsági irányelveket • Meg kell határozni az adathordozók és hálózat használati irányelveit, • A rendszer kezelésével, jogosultságok kezelésével kapcsolatos határozatokat, • Az infrastruktúra kritikus elemeit és azok védelmét, • A szoftverek védelmét, • A bizalmas adatok kezelésének irányelveit, • A külső erőforrások igénybevételének külső adatkapcsolatok használatának irányelveit, • Az üzleti folytonosság biztosításának módszereit, • Az alkalmazottak felelősségét, és biztonsági irányelvek megsértésének következményeit, Az informatikai biztonság főbb területén 1. A biztonságpolitika és célok meghatározása 2. Szervezeti színtű biztonsági kockázatok felmérése és kezelése 3. A védendő információk besorolása az adatok fontossága és érzékenysége alapján 4. A személyektől függő biztonsági kockázatok elemzése és irányelvek meghatározása , a bekövetkezett események elemzése. 5. Az eszközök biztonságos működéséhez szükséges környezet létrehozása 6. Kommunikációs rendszer 8.5. Hálózat menedzsment • Alakítsuk ki egymástól függetlenül a hálózat és az operációs rendszerek felügyeletét. • Dolgozzunk ki eljárásokat a távoli eszközök elérésére, beleértve a vállalati, de felhasználói területen lévő eszközöket is.
•
Dolgozzunk ki speciális eljárásokat a nyilvános hálózaton átmenő adatok védelmére pl. privát virtuális hálózat, titkosítás, stb.
8.6. Adathordozók kezelése • Eljárást kell kidolgozni a kivehető adathordozók kezelésére. ( Floppy, CD, kazetta, memóriakártya ). • A nem használt médiákat raktárizni kell. Az „érzékeny” adatokat tartalmazó médiákról nyilvántartást kell vezetni. • Ki kell dolgozni az információtárolás rendszerét. Az eljárásnak meg kell akadályozni a jogosulatlan használatot és az információk módosítását. • A számítástechnikai rendszer dokumentációját biztonságosan kell kezelni. Az elektromos dokumentáció elérését csak az illetékeseknek célszerű engedélyezni. 8.7. Információk és szoftverek cseréje • Formális szabályokat kell hozni a szervezeti egységek közötti információ és szoftvercserékre. • Az információ titkosságát a vállalat szemszögéből vizsgált „érzékenység” alapján kell meghatározni. ( Stratégiai tervek, bejelentés előtti állapotú szabadalmak, . .) • Gondoskodni kell az adathordozók biztonságáról szállítás közben. • Különös gondossággal kell eljárni az elektronikusan bonyolított kereskedelmi tranzakciók esetén. • Gondoskodni kell az elektronikus levelezés okozta „adatszivárgás” megakadályozásáról, illetve a levelekkel érkező kártékony szoftverek szűréséről. (Vírusok, férgek, trójai programok). 9. Üzleti követelmények a hozzáférés védelmében • A hozzáférési jogokat meg kell határozni, és dokumentálni kell. • A hozzáférési szabályokat a szerepkörökhöz, és ezen belül személyekhez kell kötni. • Az informatikai szolgáltatók számára is egyértelművé kell tenni a hozzáférési szabályokat. 9.1. Felhasználói hozzáférések menedzselése • Meg kell határozni a felhasználók regisztrálásának és törlésének rendjét. • A jogosultságok meghatározásának alapja a munkához szükséges információk elérésének ellenőrzött biztosítása. Jogosultságot csak regisztrált felhasználónak szabad adni. 9.2. A jelszavak kiadását formalizált eljárás keretében kell megoldani. • A jogosultságokat normál felhasználóknál 6 havonta, kiemelt jogosultságok esetén 3 havonta célszerű ellenőrizni. 9.6. Felhasználói magatartás szabályozása • Meg kell határozni a felhasználói jelszavak karbantartásának, módosításának rendjét. • Műszaki eljárásokat kell kidolgozni a magukra hagyott számítógépek védelmére, a processzek automatikus lezárására. 9.7. Hálózat‐elérés szabályozása • Célszerű létrehozni címekhez kötött jogosultságokat a szo9lgáltatások elérésére.
• •
Ha lehetőség van rá, ki kell jelölni az elérési útvonalakat. A bejelentkezés helye (azonosítója) is rögzíthető szabályokban. A távoli eléréseknél törekedni kell arra, hogy a belépés authentikált hálózatról történjen. (pl.: a cég egy másik, zárt hálózatáról). A távoli diagnosztikai eljárásokat kiemelt figyelemmel kell kezelni.
• 9.8. Operációs rendszer elérésének szabályozása • A kapcsolatok hitelesítésére használni kell a terminálok azonosítását is. • A terminálok csak biztonságos log‐on mechanizmussal érhetik el az információs rendszert. • Meg kell tervezni a felhasználókat azonosító eljárásokat. (Tudás, birtoklás, biometria) • A jelszavak kezelésére megfelelő eljárást kell kidolgozni. Ebben meg kell határozni a jelszavak jellemzőit, a kötelező csere időperiódusokat. A jelszavakat titkosított formában kell tárolni a szervereken. • Azokat a szoftver eszközöket, melyek átírják az operációs rendszert, különös gondossággal kell kezelni. (Pl.: a gyári, hiteles másolatokat is ellenőrizni kell, hogy nem okoznak‐e hibát a futó alkalmazásban.) • A nyilvánosan elérhető terminálokat meghatározott idejű inaktivitás után le kell kapcsolni a rendszerről. • A magas kockázatú alkalmazások futtatási idejét korlátozni kell. • A különlegesen „érzékeny” rendszereket célszerű, különálló, csak a meghatározott célra használt eszközökön futtatni. (Stratégiai tervek, kutatási eredmények, tesztspeciifikációk) 9.7 Használjuk a rendszer monitorozására alkalmas eszközöket. • Használjunk eseménykezelő log‐ot. • Figyeljük (monitorozzuk) a felhasználói aktivitást. • Szinkronizáljuk az órákat, hogy az audit‐log kiértékelhető legyen. 9.8. Mobil számítógépek, távmunka A mobil számítógépek kiemelt biztonsági kockázatot jelentenek. Egyrészt a gépeket nem védett helyen is használják, ami a tárolt adatokat veszélyezteti. Másrészt a biztonsági tűzfalak mögé behozhatunk veszélyes programokat, a vállalati védelmi rendszer megkerülésével. 10.1. Információs rendszerek fejlesztése és karbantartása. • A biztonsági kérdéseket az üzleti célú specifikációval együttesen, azonos szinten kell kezelni. • A biztonsági elvárásokat a fejlesztés megkezdése előtt meg kell határzni. 10.2. A felhasználói rendszerek biztonságossága. • A bemeneti adatok ellenőrzését el kell végezni a hihetőség és a káros kódtartalom szempontjából. A bemenetekre küldött speciális vezérlőkarakterek sokféle támadás alapját képezik, ezekre fokozatosan kell ügyelni. • Elemezni kell a belső feldolgozás során megsérült adatok kockázatát, hatását a további feldolgozásra és az üzleti folyamatokra. • Meg kell tervezni és ellenőrizni kell az elektronikus üzenetek (levelek, adatállományok) hitelességét, sértetlenségét és teljességét. • A kimenő adatokat ellenőrizni kell, hogy megfelelnek‐e az alkalmazásból adódó természetes követelményeknek, a várható értéktartományban vannak‐e, formátumuk megfelelő‐e.
10.3. Titkosítási folyamatok ellenőrzése. • Meg kell határozni a kriptográfiai védelem szintjét. • Össze kell rendelni a védelmi szinteket és az adtok titkossági szintjeit. • Az elektronikus dokumentumokat a változatlanság és hitelesség ellenőrzésére digitális aláírással kell ellátni. Figyelem! Nem minden fájl „dokumentum”. • Meg kell szervezni a kulcs karbantartási folyamatokat . Ha a kulcs előállítás, továbbítás szabványokon alapul, akkor elegendő a módszerek meghatározása. 10.4. Rendszerfájlok védelme • Ellenőrizni kell a rendszerfájlok sértetlenségét minden betöltés előtt. • A rendszertesztek alatt gondoskodni kell a használt adatbázisok „anonimizálásáról”. A rendszerteszthez használt adatbázisok nem tartalmazhatnak valós személyes adatokat. • A rendszerfájlok védelme érdekében a forrásfájlokat különös gondossággal kell őrizni. A programkönyvtárakhoz való hozzáférést erősen korlátozni kell. 10.5. Biztonság és titkosság a fejlesztési folyamatban • Eljárást kell kidolgozni a változások követésére és dokumentálására. • A felhasználói programokat minden operációs‐rendszer váltás után tesztelni kell. A szoftvergyártó javító‐csomagjait csak korlátozottan használjuk. Csak azok a „javítások” alkalmazhatók, melyeknek származása biztonságosan azonosítható, és a felhasználói programok kompatibilitását ellenőriztük. • Gondot kell fordítanunk arra, hogy az újonnan szállított szoftvertermékek nem tartalmaznak „bombákat” és Trójai jellegű támadásra utaló kódrészleteket. 11.Üzleti folytonosság biztosítása. Az „üzleti folytonosság” általános fogalom az informatikai szolgáltatás folytonosságára. Egy folyamatirányító rendszer esetén is beszélhetünk „üzleti folytonosságról”.Annyival több az „üzleti folytonosság”, mint a szűken vett számítástechnikai rendszer folytonossága, hogy nem elegendő egy hiba elhárítása, és a rendszer utolsó állapotának korrekt helyreállítása. Az üzemkiesés idején történt eseményeket is kezelni kell a rendszernek, és csak akkor fejeződik be a helyreállítási procedúra, amikor a műszaki helyreállítást követően a kiesett idő alatti eseményeket is bevittük a rendszerbe. Pl.: a kiesett időben papíron rögzített készletmozgásokat kézzel felvitték. Folyamatirányító rendszerekben a lokális számítógépek pl. kommunikációs hiba miatt kiesett időszakaszok eseményeit betöltötték a központi felügyeleti rendszer adatbázisába. • Meg kell vizsgálni és nevesíteni kell a várható külső hatások (tűz, árvíz, készülék meghibásodás) következményeit az informatikai rendszerre. Stratégiai tervet kell kidolgozni a folytonosság biztosítására. • Ki kell dolgozni a rendszervisszatöltés módszereit, és tesztelni is kell az eljárásokat. • Meg kell határozni a helyreállítás sorrendjét. Meg kell határozni a komponensek aktiválásának sorrendjét. 12. Megfelelés a hivatalos szabályozásoknak. • Vizsgálni kell, hogy az informatikai rendszer megfelel‐e a hatályos jogszabályoknak, illetve szolgáltatási szerződéseknek. • Az informatikai rendszernek meg kell felelni a személyiségi jogokat védő szabályozásoknak.. Ez a kitétel jogilag kötelező, de a megvalósítása sok esetben szinte lehetetlen, vagy éppen a védett személyre nézve súlyosan hátrányos. Pl.: Egy kórházi rendszeren belül sem ad
felmentést a törvény az alól, hogy egyes adatok csak a kezelőorvosra tartoznak. Hogyan látja el akkor felelősséggel a beteget az ügyeletes orvos? • Meg kell vizsgálni, hogy az informatikai rendszer nem sért‐e szerzői joogot, védjegyet, formatervi védelmet. A rendszernek meg kell akadályozni a nem vállalati célú alkalmazások futtatását, és jeleznie kell a jogtalan felhasználási kísérleteket. • A titkosításoknak meg kell felelni a nemzeti szabályozásoknak. (Egyes országokban korlátozzák a magán‐célra használt titkosítási algoritmusok típusát és alkalmazható kulcsok méretét). • Rendszeresen ellenőrizni kell a biztonsági rendszereket külső, hozzáértő szakértőkkel.