Eötvös Loránd Tudományegyetem
Informatika Kar
Eötvös Loránd Tudományegyetem
Informatika Kar
Internetes biztonsági események katalogizálása
Lelekács Zoltán
Témavezető: Kincses Zoltán (MTA-SZTAKI)
Budapest, 2005-06-15
Diplomamunkám témája a CSIRT (Computer Security Incident Response Team) csoportok működése menedzsment szempontból, osztály-hierarchia felépítése és erre építve munkájuk támogatása egy web service alapú kiszolgálónak a specifikálásával Microsoft Windows környezetben, illetve kliens oldal leírása szintén MS környezetben.
A munkám első részében megmutatom a CSIRT igényének hátterét, majd részletezem üzleti megközelítés szempontjából a folyamatokat. Foglalkozom az implementálási nehézségekkel a már meglévő üzleti folyamatok mellé, elhelyezem a CSIRT feladatát a biztonsági menedzsmenthez képest.
Rövid áttekintést adok az XML leírónyelvről, majd az XML önleíró tulajdonságáról. XSD segítségével definiálom a CSIRT osztályokat, rövid megjegyzésekkel a típusoknál.
Következő fejezetben az adatcseréről és ennek a mai szabványos fejlett technikáiról írok, kiemelve a szabványosításból fakadó előnyöket, és átjárhatóságot, mint technikai, mint felhasználói oldalról. Szólok a Microsoft legújabb technikai megoldásairól, majd részletesebben az XML relációs adatbázisba tárolásáról. Specifikálom a szerver és kliens oldalt, részletezve a funkcionalitást.
Utolsó fejezetben távolabbról tekintek a problémára, és felvetek két módosítást az osztály hierarchiára, illetve a rendszer ötvözését egy új technológiával, és az ebből várható előnyöket.
Leírásaim támaszkodnak [1] munkára, és az ott közölt eredményekre, mint fogalmak és követelmények, vagy osztály leírás.
A dolgozat a következő témaköröket tartalmazza:
1.b.
CSIRT felépítése és beépülése az üzleti folyamatokba
1.c.
Incidens menedzsment és a biztonsági menedzsment különbségei
2.
CSIRT osztályok és reprezentálásuk
2.b.
Osztályok reprezentálása XSD-vel
2.d.
.NET által nyújtott keretrendszer (rapid development)
2.e.
SOAP, mint burkoló felület
3.a.
XML beágyazott elemek kontra relációs adatbázis-kezelés
3.b.
CSIRT kiszolgáló specifikáció
4.
Ajánlások a továbbfejlesztéshez és implementálásukhoz
4.a.
ID referenciák kiváltása „GUIDokkal”
4.b.
Menedzsment oldali feldolgozhatóság nővelése
4.c.
Keresés és adat továbbítás P2P hálón
Számítástechnikával egyidős a számítástechnika biztonsági kérdése. Eleinte ez fizikai védelmet jelentett, de a hálózatok terjedésével, és a közszférába való kilépéssel, a programok hangsúlynövekedésével eltolódott a fizikai védelemről a figyelem a szoftver/hardware alapú felé. Mai világunkban, ahol elsődleges kommunikációs csatorna egyre inkább az Internet, mindenki – mindenki szomszédjává válik, és ez által sebezhető felület, és rossz szándékú szomszédaink száma is exponenciálisan növekszik. Mint ahogy az élet más területén, itt is megjelent a minőségbiztosítás igénye. Ennek egyik elengedhetetlen kelléke az információ és ezen információból nyert reagálási, cselekvési terv. Ezt a témát karolja fel a CSIRT.
Computer Security Incident Response Team egy csapat, mely gondoskodik egy szervezet védelméről és támogatásáról biztonságtechnikai kérdésekben, ide értve a megelőzést, az elhárítást, és a támadás utáni válaszlépéseket.
A csapat mérete és tagjai függhetnek a szervezet méretétől. Lehet ez egy ténylegesen elkülönített emberállomány egy nagyobb cégen belül, de lehetőség van a már feladattal rendelkező munkatársak közül kiválasztani a csapat tagjait. A hierarchiában mindenkinek meg van a szerepe egy esetleges biztonsági esemény bekövetkeztekor, és az akcióterv az esemény kezelésére. A mai rendszerbonyolultság és céges hierarchia mellett (globális cégek) szükség van jól dokumentált lépésekre, szervezett információáramlásra. A megfelelő védekezés alapja az információgyűjtés és kategorizálás, könnyű visszakereshetőség.
A feladatok részletesebben:
Mint ebből a felsorolásból is látható a feladatkör jóval bővebb, mint egy információtechnológia szinten kezelt védekezés, esetleges válaszadás a támadásra. A megfelelően működő CSIRT beleintegrálódik a cég mindennapi életébe, az üzleti folyamatokba. A bevezetés fontos része, hogy ezeket a folyamatok következetesen, folyamatosan, megfelelő minőségben, mérhetően (ellenőrizhetően), átláthatóan (a munkatársak pontosan értsék a folyamatot, és a rájuk háruló feladatokat) vezessék be a már meglévő üzleti folyamatok mellé, vagy közé.
Ahhoz, hogy ez sikeres legyen a következő pontok szükségesek:
A minőségbiztosítás egyik fontos jellemzője a jól dokumentáltság, mind az elvégzett folyamatok, mind az elvégezendő folyamatokról. A CSIRT üzleti menedzser feladatai cégenként változhatnak, és minden esetben szükséges az adott cégre/szervezetre a testre szabás, de a feladat absztrahálása következtében kialakult egy jól definiált feladatkör, és lépéssorrend, amit követni érdemes. Egyik ilyen a Carnegie Mellon által dokumentált felosztás, amit a következőkben mutatok be.
A fent felsorolt feladatok folyamatba szervezése, csoportosítása az általánosság megtartása mellett:
Az előbbiekben ismertetett folyamatok ábrája.
Az incidens menedzsment kifejezés pontos definiálása nehéz összetettsége, és különböző jelentése miatt a különböző közösségekben. Egyik értelmezése az információtechnológiában: kezelni a bekövetkezetett zavarokat és váratlan eseményeket. A saját definíciónk ennél tágabb: megelőzni és kezelni a komputeres biztonsági eseményeket. Ez magában foglalja a teljes spektrumát a figyelés, megelőzés, kezelés hármasnak, beleértve az azonosítását és minimalizálását bármilyen behatásnak, mely a szoftver vagy hardver fronton történik, és biztonsági kockázatot okozhat. A fontos különbség a két eset között, az interpretációban van. Az incidens menedzsment részét képezi a biztonsági menedzsmentnek, de nem fedi le annak teljes spektrumát. Nem foglalkozik a hozzáférés problémájával a céges erőforrásokhoz (jogosultságkezelés) vagy biztonsági célkitűzésekkel, de részét képezi a cég technikai berendezéseinek (számítógépek, switchek, routerek) követelményspecifikációjával, konfigurálása, karbantartása biztonsági szempontból, és a folyamatos működésük szempontjából (patchelés).
Az ábra a biztonsági menedzsment és incidens menedzsment kapcsolatát mutatja. A felkészülés és védelmi nyilak közös részt alkotnak a biztonsági résszel, azaz vannak átfedések a felügyeleti funkciókban, de a biztonsági tágabb, míg az észlelés, besorolás, válasz hármasa már az incidens menedzsment része, teljes mértékben lefedi ezt a kérdést.
A CSIRT ajánlás által meghatározott osztályok egy elég szabad struktúrát adnak meg, mely megnehezíti az adat tárolását és áramoltatását az egyes csoportok között. Problémát okozhat a különböző mélység az esetet leíró fában, vagy a különböző attribútumok. Olyan adat reprezentációs technikát kellett választani, ami lefedi ezeket a problémákat, és platform független. A platformfüggetlenség egyik velejárója, hogy gyakran ASCII 7bit alapú az átvitel, így nincs méretre optimalizálva a leírónyelv, ezért ember által is értelmezhető elemeket használnak fel.
Felmerül a felsorolási típusoknál a törzsadat (felvehető listaértékek) átvitele, olyan megoldást kell találni, ami segít az adat-konzisztenciát és szinkronizálást fenntartani, elősegíteni. Egy adatcsere során előfordulhat, hogy az adott CSIRTnél még nincs értékként felvéve a küldő CSIRT által használt listaérték, ekkor az adatok beillesztése után inkonzisztens állapot állna elő. Későbbiekben felmerülhet az igény, hogy meg kellene különböztetni a „saját” és más CSIRTek által használt értékeket, esetleg emberi felügyelet mellett a lista folyamatos revízióját.
Ezen feltételeknek tökéletesen megfelel az XML, mint leírónyelv. Bővíthető szerkezete, a leíráshoz használt tag-jei tetszőlegesen használhatóak (nincs megkötés se az elnevezésre, se sorrendre, kivétel a beágyazást). Magát a nyelvet adathalmazok/objektumok leírására hozták létre, így ideális reprezentációja a CSIRT osztályok által meghatározott objektum hierarchiának. Az XML másik nagy előnye, hogy DTD kiegészítéssel önleíró nyelv. Az XML dokumentum tartalmazhatja saját szerkezetének és tulajdonságainak a leírását, így megkönnyítve az adat feldolgozását, amit hordoz. Leíró segítségével az új törzsadatok könnyen átvihetőek, már a tényleges adat feldolgozása előtt fel lehet készülni az új értékek helyes kezelésére. Az attribútumok használatával az egyes elemek megjelölhetőek, így kialakítva például az értéklistáknál az idegen CSIRT értékeket.
XML leírása
A szintaktikai szabályok nagyon egyszerűek, ugyanakkor nagyon szigorúak is. Könnyű őket megtanulni és használni, épp ezért XML-dokumentumokat kezelő szoftverek készítése sem nehéz feladat.
Az XML forrásban az első sor az un. XML-deklaráció, amely megadja az XML verzióját, valamint a használt karakter-kódolást, ezzel rögtön lehetőséget adva a többnyelvűség könnyű kezelésére.
A következő sorban adjuk meg a gyökérelemet (ezt dokumentumelemnek is nevezik), mint például <IODEF>. Esetünkben ez azt adja meg, hogy a komplett dokumentum egy IODEF leírás lesz. Az elemek egymásba ágyazva, vagy egymást követve helyezkedhetnek el, mindig kötelező lezáró taggal, így esetünkben a záró rész egy </IODEF> sor lesz.
Ezeket az elemeket szokás tag-eknek, elemeknek nevezni. Továbbiakban az elem elnevezést a teljes nyitó- és záró tag-re használom, míg a tag elnevezést magára a literálra, ami leírja az XML-ben az elemet. Ha egy elem nem tartalmaz adatot, akkor rövidített formában így írható:
<gyerek_nelkuli_elem/>
Mindegyik dokumentumnak tartalmaznia kell a gyökérelemet jelölő nyitó- és záró tag-et, ha gyökérelemből egy van, akkor jól formált XMLről beszélünk. Az összes többi elem ezeken belül helyezkedik el. Az elemeknek lehetnek gyermekelemeik, amelyeket a szülőkbe helyesen kell beágyazni, csak a <b><i>…</i></b> sorrend megengedett, a váltakozó <b><i>…</b></i> sorrend nem.
Ez egy lényeges megkötés a feldolgozhatóság szempontjából, és követi az objektumok közötti relációkat. Ebből a logikából objektum szerializálásnál akadhat probléma (például egymásra hivatkozás), de fontos észre venni, hogy ekkor a kapcsolatot már a példányosult objektumok között értelmezzük, és nem az osztályok között (azaz adat és nem metaadat), ezért ezen információt így is kell kezelni. Ezen probléma implementációs kezelésére több megoldás is született, a beágyazott ismétléstől kezdve, az attribútumos megjelölésen át, a jól bevált, de nehezen követhető és feldolgozható azonosító hivatkozásig.
A tagokhoz attribútumok adhatóak meg, minden taghoz minden attribútum egyszer. Ezek név érték párok, melyek az adathoz plusz tulajdonságot rendelhetnek (ilyen lehet pl. egy tag szintű verziókövetés).
Maguk az elemek szülő-gyermek kapcsolatban vannak, melyet tabulálással is szokás jelezni a forrásban. Egy elem gyerekei az elem tag-jei által közrefogott elemek, és fordítva, egy tag gyerek, ha van olyan elem (tag), ami közrefogja.
A fent említett megkötésből következik, hogy egy elemnek egy szülője, de tetszőleges számú gyereke (unokája, stb.) lehet. Egy elem tartalmazhat:
A CDATA az XML értelmező szemszögéből adatnak minősül, amivel nem kell foglalkoznia, míg PCDATA esetén további elemzésre kerül sor (azaz XML tag-eket tartalmazhat).
Az elemeknél ún. névterek is használhatóak, ekkor a tag részt a névtérrel kell kezdeni, és kettősponttal megadni magát a tag-et.
<msschema:table …>…
XML nagy előnye a kiterjeszthetőség. Egy feldolgozó csak azokkal a tagokkal foglalkozik, amiket ismer, és értelmezni tud. A szerkezet utólagos bővítésénél az új tagok megjelenése a régebbi feldolgozókat nem zavarhatja meg, így biztosítva a kompatibilitást, így egy régi IODEF dokumentum is „érvényes” tud maradni, ha időközben kibővítették az adatbázist, vagy, ha egyes CSIRT csoportok több információt kívánnak tárolni a struktúrában.
Érvényes XML dokumentumnak nevezzük azon jólformázott XML dokumentumokat, melyek logikai felépítése és tartalma teljes mértékben megegyezik az XML dokumentumban meghatározott (vagy külső fájlban meghatározott és az XML dokumentumhoz csatolt) szabályoknak. Ezen szabályok megfogalmazhatóak (megírhatóak) Dokumentum Típus Definíció (rövidebb nevén DTD) vagy XML-séma segítségével.
A DTD segítségével biztosítjuk, hogy a megírt vagy feldolgozni kívánt dokumentum megfelel az elvártaknak. Az egyes DTD-k ismerete alapján bárki készíthet érvényes dokumentumot vagy akár feldolgozó alkalmazást, így bármely CSIRT csoportnak elég tudnia a DTD leírását az IODEFnek és rögtön képes olyan program előállítására, ami értelmezni tudja más CSIRTek által küldött XML adatot, vagyis a DTD nem más, mint egy tervrajz az XML dokumentumokhoz. A DTDnek tartalmazni kell az összes elemet és jellemzőt, amelyet a dokumentum tartalmazhat.
XML önleíró része a fejléc után következik (DTD = Document Type Definition). Ennek segítségével megadható az XML adatrész elvárt formája. Ha ennek megfelel az adatrész, akkor érvényes XML dokumentumról beszélünk.
A DTD
deklaráció általános formája:
<!DOCTYPE
dokumentumelem_neve DTD>
ahol dokumentumelem_neve
a DTDt tartalmazó dokumentum dokumentumelem neve, a DTD pedig az
egyes DTD deklarációk összessége. A DTD deklarációk összessége alatt értjük az
egyes elemek, jellemzők, egyedek, jelölések deklarációit, valamint feldolgozási
utasításokat, megjegyzéseket és paraméteregyed-hivatkozásokat.
Az elemtípusok deklarálásának
általános alakja:
<!ELEMENT elemneve tartalomleírás>
ahol elemneve az éppen
deklarálni kívánt elem neve (fontos, hogy a kis én nagybetűket figyelembe veszi
az értelmező), tartalomleírás
pedig meghatározza, hogy az elem milyen tartalommal rendelkezhet. Az elemek
tartalma a következő lehet:
<!ELEMENT URES EMPTY><!ELEMENT BARMI ANY><!ELEMENT ELEMTARTALMU
(EGYIK_GYERMEKELEM, MASIK_GYERMEKELEM)> <!ELEMENT VEGYES (#PCDATA,
GYERMEKELEM)*>Ha az elem gyermekelemeket tartalmaz (elemtartalommal rendelkezik), az összes gyermekelem nevét fel kell tüntetni a szülőelem deklarációjában, majd az egyes gyermekelemeket egyesével deklarálni kell.
A definíciónál meg kell adni az előfordulás számát is, erre a következő jelölések szolgálnak:
? - nulla vagy egy az előtte álló elemből+ - egy vagy több az előtte álló elembőlA gyerek elemek felsorolásánál a vesszővel választjuk el azokat az elemeket, amiknek egy szinten szerepelniük kell, és „|” jellel, amik közül az egyiknek (választólista létrehozása).
Az egyes elemekben használt összes jellemzőt deklarálni kell, amely általános formája a következő:
<!ATTLIST ELEMNEV jellemzo_neve
jellemzo_tipusa alapertelmezes_deklaracio ...>
Az egyes
jellemzők definiálásakor meg kell adni az elem nevét (ELEMNEV), amely
jellemzőit éppen definiáljuk, majd az egyes jellemzők deklarációi következnek.
Az egyes jellemzők nevét (jellemzo_neve) és típusát (jellemzo_tipusa)
a jellemző alapértelmezés deklarációja (alapertelmezes_deklaracio) követi, amely
megadja, hogy a jellemző megadása kötelező-e, vagy ha nem akkor esetlegesen egy
alapértéket rendeljen hozzá az értelmező.
Az egyes jellemzőknek három típusa lehetséges:
· karakterlánc - mely tartalma és létrehozása az előző részben ki lett tárgyalva
· token típus - mely tartalma bizonyos korlátok közé van szorítva
ID - ezen jellemző tartalmának egyedi érvényes névnek kell lenni, vagyis két jellemzőnek nem lehet egyforma tartalmú ID típusú jellemzője
IDREF - referencia (mutató) egy már létező ID típusú jellemzőre, tehát értéke csak egy létező ID típusú jellemző értéke lehet
IDREFS - ugyanaz, mint az IDREF azzal a különbséggel, hogy egyidejűleg több, már létező azonosítóra hivatkozhatunk egy tulajdonságon belül, úgy, hogy az egyes referenciákat szóközzel választjuk el egymástól
NMTOKEN típusú jellemző értéke számok, betűk, pontok, kötőjelek, aláhúzások, vagy kettőspontok (kettőspont nem szerepelhet az első helyen) sorozata.
NMTOKENS típusú jellemző ugyanaz, mint az NMTOKEN, azzal a különbséggel, hogy egyidejűleg több NMTOKEN típusú értéket adhatunk meg, szóközzel elválasztva
ENTITY típusú jellemző értéke egy, a DTDben már deklarált nem értelmezett egyed (egyed fogalmával és deklarálásával a későbbiekben fogunk foglalkozni) lehet
ENTITIES típusú jellemző ugyanolyan, mint az ENTITY típusú, azzal a különbséggel, hogy értekül adhatunk több nem értelmezett egyeded egyszerre, szóközzel elválasztva
Ez volt ez első lehetőség egy XML dokumentum érvényességének ellenőrzésére, és ez a legelterjedtebb mód egy érvényes dokumentum megadásához. Időközben kiderült, hogy ez a leírás nem elég erős (típusmegkötések például), és az egyedi nyelvezete miatt „elüt” az XMLtől. Ezért bevezették az XML sémákat. Ez már XML alapon írja le az XML érvényességéhez szükséges definíciót, jóval bővebb lehetőségekkel, mint amit a DTD ad, de természetesen elfedve azt.
Az XML sémának az alakja a következő:
Egyszerű elemtípusok deklarációja
Az XML-sémában az elemeket az element elemmel tudjuk deklarálni, melyen belül mindenképpen fel kell tüntetnünk az elem nevét.
Amennyiben egyszerű típusú elemet (nem tartalmaz gyermekelemeket) deklarálunk nem származtatott tartalom-típussal, úgy magát az elem (tartalom) típust is az element elemen belül kell megadni:
<xsd:element name="NEV" type="xsd:string"/>
<xsd:element name="DATUMIDO" type="xsd:dateTime"/>
Lehetőség van sokkal összetettebb megkötésekre is. Álljon itt példának egy dátumra vonatkozó:
<xsd:element name="EV">
<xsd:simpleType>
<xsd:restriction base="xsd:gYear">
<xsd:minInclusive value="1950"/>
<xsd:maxInclusive value="2010"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
A példa az írja le, hogy az EV típus 1950 és 2010 közötti értéket vehet fel. Innen is látszik, hogy lényegesen bonyolultabb kifejező eszköz, mint a DTD. Következőkben ismertetem az IODEF sémáját XML séma alapján, hivatkozva az [1] 3.2, ahol megtalálható az egyes osztályok pontos szemantikai jelentése, használata és kapcsolata. Nem a tartalmazási sorrendet követem, mert a rekurzív hivatkozások miatt előre veszem azon típusdefiníciókat, mely osztályokhoz ez szükséges.
A fejléc a következő információkat tartalmazza:
· UTF-8 kódolást használunk a hierarchia leírására.
· XS namespace használata, ami az XSD alapdefinícióit tartalmazza.
<?xml version="1.0" encoding="utf-8" ?>
<xs:schema id="IODEF" attributeFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">
Az első típus a leggyakrabban használt osztály, olyan String osztály, ami tartalmazza a restriction tagot, ami meghatározza a hozzáférést a value taghoz. A restriction a következő értékeket veheti fel:
· public: bárki hozzáférhet az információhoz, amit az objektum tárol
· need-to-know: információ megosztható más érintettekkel pl. több áldozat esetén az egyik értesíti a többit.
· private: az információ nem osztható meg
· default: az információ a többi IKCS-al korlátlanul megosztható
Ehhez definiálni kell a következő típust:
<xs:simpleType name="RestrictionENUM">
<xs:restriction base="xsd:string">
<xsd:enumeration value="public"/>
<xsd:enumeration value="need-to-know"/>
<xsd:enumeration value="private"/>
<xsd:enumeration value="default"/>
</xsd:restriction>
</xs:simpleType>
xs:restricition base sor az egyszerű típus alaptípusát adja meg, ami ez esetben a string típus, ami alaptípus az XSD típusok között. Az xs:enumeration sorok a felvehető lehetséges értékeket adják meg. Ebből a típusból származó osszes xml elem csak az itt felsorolt értékekkel rendelkezhet.
Maga a RestString deklarációja:
<xs:complexType name="RestString">
<xs:sequence>
<xs:element
name="restriction" type="RestrictionENUM"
minOccurs="1" maxoccurs=”
<xs:element
name="value" type="xs:string" minOccurs="0"
maxOccurs=”
</xs:sequence>
</xs:complexType>
A komplex típusok belül tetszőleges számú új elemet adhatunk meg az xs:element taggal, ami lehet ComplexType, SingleType vagy XSD alaptípus. Attribútumok segítségével további megkötéseket tehetünk a deklarációban, egyik ilyen a számosságra vonatkozik, a minOccurs és a maxOccurs előfordulást határoz meg. minOccurs a minimális előfordulást adja meg az adott objektumból. Értéke nem negatív egész szám lehet, nulla a nem szükséges előfordulást jelenti. maxOccurs az elem maximális előfordulási számát határozza meg, értéke pozitív egész szám vagy Unbounded karakterlánc. Ez utóbbi a korlátlan jelzőt jelenti az elemnél, tetszőleges számban előfordulhat, mint gyermekelem.
Az incidens egyedi azonosítóját leíró típus.
<xs:complexType name="IncidentID">
<xs:sequence>
<xs:element name="UID" type="xs:string" minOccurs="1" maxoccurs=”1”/>
<xs:element name="GUID"
type="xs:string" minOccurs="1" maxOccurs=”
</xs:sequence>
</xs:complexType>
A Description (leírás) logikailag ugyan azt a szabályt követi, mint a RestString, ezért ez lesz a típusa, nem külön osztályt definiáltam neki.
Első bonyolultabb típus a Contact. Magában foglal több gyerekosztályt, és rekurzívan saját magát. Sok eleme nem kötelező, így adva szabadabb kezet a valós szervezeti hierarchia ábrázolására. Tárolhat információt a szervezetről, de gyerekelemként akár egy konkrét személy adatait is tartalmazhatja.
<xs:complexType name="Contact">
<xs:sequence>
<xs:element
name="restriction" type="RestrcitionENUM"
minOccurs="1" maxOccurs=”
<xs:element name="role"
type="xs:string" minOccurs="1" maxOccurs=”
<xs:element name="type"
type="xs:string" minOccurs="1" maxOccurs=”
<xs:element name="Name"
type="xs:string" minOccurs=”
<xs:element
name="Description" type="RestString" minOccurs=”
<xs:element name="RegistryHandle"
minOccurs=”
<xs:complexType>
<xs:sequence>
<xs:element
name="Value" type="xs:string" minOccurs="1"
maxOccurs=”
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element
name="PostalAddress" minOccurs=”
<xs:complexType>
<xs:sequence>
<xs:element
name="Value" type="xs:string" minOccurs="1"
maxOccurs=”
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="Email"
minOccurs=”
<xs:complexType>
<xs:sequence>
<xs:element
name="Value" type="xs:string" minOccurs="1"
maxoccurs=”
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element
name="Telephone" minOccurs=”
<xs:complexType>
<xs:sequence>
<xs:element name="Value" type="xs:string" minOccurs="1" maxOccurs=”1”/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="TimeZone"
minOccurs=”
<xs:complexType>
<xs:sequence>
<xs:element
name="Value" type="xs:string" minOccurs="1"
maxOccurs=”
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="Contact" type="Contact" minOccurs="0" maxOccurs=”Unbounded”/>
</xs:sequence>
</xs:complexType>
Method osztály, mely leírja a támadó által használt eljárásokat:
<xs:complexType name="Method">
<xs:sequence>
<xs:element
name="restriction" type="RestrictionENUM"
minOccurs="1" maxOccurs=”
<xs:element
name="method_classification" minOccurs=”
<xs:complexType>
<xs:sequence>
<xs:element
name="restriction" type="RestrictionENUM"
minOccurs="1" maxOccurs=”
<xs:element
name="origin" type="xs:string" minOccurs="1"
maxOccurs=”
<xs:element
name="name" type="xs:string" minOccurs="1"
maxOccurs=”
<xs:element
name="url" type="xs:string" minOccurs="1"
maxOccurs=”
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element
name="method_description" minOccurs=”
<xs:complexType>
<xs:sequence>
<xs:element
name="value" type="RestString" minOccurs="1"
maxOccurs=”
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
Assessment osztály tartalmazza a TimeImpact osztályt, amiben szerepel egy ENUM típus, ami megadja hogy a definiált támadás időhossza milyen egységben értendő ennek felsorolási egyszerű típusa:
<xs:simpleType name="timeUnitsENUM">
<xs:restriction base="xsd:string">
<xsd:enumeration value="seconds"/>
<xsd:enumeration value="minutes"/>
<xsd:enumeration value="hours"/>
<xsd:enumeration value="days"/>
</xsd:restriction>
</xs:simpleType>
A támadás súlyosságát leíró ENUM:
<xs:simpleType name="severityENUM">
<xs:restriction base="xsd:string">
<xsd:enumeration value="low"/>
<xsd:enumeration value="medium"/>
<xsd:enumeration value="high"/>
</xsd:restriction>
</xs:simpleType>
Assessment osztály a kárfelméréssel kapcsolatos információkat tartalmazza:
<xs:complexType name="Assessment">
<xs:sequence>
<xs:element name="restriction" type="RestrictionENUM" minOccurs="1" maxOccurs=”1”/>
<xs:element
name="TimeImpact" minOccurs=”
<xs:complexType>
<xs:sequence>
<xs:element
name="restriction" type="RestrictionENUM"
minOccurs="1" maxOccurs=”
<xs:element
name="time" type="xs:time" minOccurs="1"
maxOccurs=”
<xs:element
name="severity" type="severityENUM" minOccurs="1"
maxOccurs=”
<xs:element
name="metric" type="xs:string" minOccurs="0"
maxOccurs=”
<xs:element
name="units" type="timeUnitsENUM" minOccurs="1"
maxOccurs=”
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element
name="TechnicalImpact" minOccurs=”
<xs:complexType>
<xs:sequence>
<xs:element
name="description" type="RestrictionENUM"
minOccurs="1" maxOccurs=”
<xs:element
name="severity" type="severityENUM" minOccurs="1"
maxOccurs=”
<xs:sequence/>
</xs:complexType>
</xs:element>
<xs:element
name="MonetaryImpact" minOccurs=”
<xs:complexType>
<xs:sequence>
<xs:element name="value" type="xs:float" minOccurs="0" />
<xs:element name="severity" type="severityENUM" minOccurs="0" />
<xs:element name="currency" type="xs:string" minOccurs="0" />
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
A következő osztály (ImprovementList) típusát leíró felsorolási típus.
<xs:simpleType name="ImprovementListENUM">
<xs:restriction base="xsd:string">
<xsd:enumeration value="update"/>
<xsd:enumeration value="configure"/>
<xsd:enumeration value="additional"/>
<xsd:enumeration value="step"/>
</xsd:restriction>
</xs:simpleType>
ImprovementList osztály leírása, ez az osztály saját magunk tettük bele azt osztály hierarchiába a menedzsment támogatása érdekében. Részletesebben a 4.b. részben lesz szó.
<xs:ComplexType name=”ImprovementList”>
<xs:sequence>
<xs:element name=”type”
type=”ImprovementListENUM” minOccurs=”
<xs:element name=”num”
type=”xs:integer” minOccurs=”
<xs:element name=”Description”
type=”RestString” minOccurs=”
<xs:element name=”source”
type=”xs:string” minOccurs=”
<xs:element name=”full”
type=”xs:boolean” minOccurs=”
<xs:element name=”improvementlist”
type=”ImprovementList” minOccurs=”
</xs:sequence>
</xs:ComplexType>
Process osztály, ami tartalmazza a támadás helyén futó processzeket:
<xs:complexType name="Process">
<xs:sequence>
<xs:element name="ident" type="xs:string" minOccurs="0"/>
<xs:element name="name" type="xs:string" minOccurs="0" />
<xs:element name="pid" type="xs:integer" minOccurs="0" />
<xs:element name="path" type="xs:string" minOccurs="0" />
<xs:element name="args" type="xs:string" minOccurs="0" />
<xs:element name="env" type="xs:string" minOccurs="0" />
</xs:sequence>
</xs:complexType>
A hálózati erőforrások funkciójának leírásához használt felsorolási típus:
<xsd:simpleType name="nodeCategoryENUM">
<xs:restriction base="xsd:string">
<xsd:enumeration value="atm"/>
<xsd:enumeration value="mac"/>
<xsd:enumeration value="sna"/>
<xsd:enumeration value="ipv4-addr"/>
<xsd:enumeration value="ipv4-net"/>
<xsd:enumeration value="ipv4-net-mask"/>
<xsd:enumeration value="ipv6-addr"/>
<xsd:enumeration value="ipv6-net"/>
<xsd:enumeration value="ipv6-net-mask"/>
<xsd:enumeration value="vm"/>
<xsd:enumeration value="e-mail"/>
<xsd:enumeration value="lotues-notes"/>
</xsd:restriction>
</xsd:simpleType>
Az erőforrásokat leíró osztály:
<xsd:simpleType name="nodeRoleCategoryENUM">
<xs:restriction base="xsd:string">
<xsd:enumeration value="client"/>
<xsd:enumeration value="server-internal"/>
<xsd:enumeration value="server-public"/>
<xsd:enumeration value="www"/>
<xsd:enumeration value="mail"/>
<xsd:enumeration value="messaging"/>
<xsd:enumeration value="streaming"/>
<xsd:enumeration value="voice"/>
<xsd:enumeration value="file"/>
<xsd:enumeration value="ftp"/>
<xsd:enumeration value="p2p"/>
<xsd:enumeration value="name"/>
<xsd:enumeration value="directory"/>
<xsd:enumeration value="credential"/>
<xsd:enumeration value="print"/>
<xsd:enumeration value="application"/>
<xsd:enumeration value="database"/>
<xsd:enumeration value="infra"/>
<xsd:enumeration value="log"/>
<xsd:enumeration value="other"/>
</xsd:restriction>
</xsd:simpleType>
A Node class egy fizikai hostot, hálózati erőforrást vagy egy konkrét hálózatot reprezentál:
<xs:complexType name="Node">
<xs:sequence>
<xs:element name="category" type="xs:string" minOccurs="0"/>
<xs:element name="Location" type="RestString" />
<xs:element name="Name" type="RestString" minOccurs="0" />
<xs:element name="Address">
<xs:complexType>
<xs:sequence>
<xs:element name="category" type="nodeCategoryENUM" minOccurs="1" maxOccurs="1" />
<xs:element name="vlan-name" type="xs:string" minOccurs="0" maxOccurs="1" />
<xs:element name="vlan-num" type="xs:integer" minOccurs="0" maxOccurs="1" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="Counter" type="Counter"></xs:element>
<xs:element name="dateTime" type="xs:dateTime" minOccurs="0"/>
<xs:element name="NodeRole">
<xs:complexType>
<xs:sequence>
<xs:element name="role" type="xs:string" minOccurs="0" />
<xs:element name="category" type="nodeRoleCategoryENUM" minOccurs="0" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="Process" type="Process" />
</xs:sequence>
</xs:complexType>
Analyzer osztály olyan adatokat tartalmaz melyeket különböző automatikus logolásra használt programok állítanak elő:
<xs:complexType name="Analyzer">
<xs:sequence>
<xs:element name="analyzerid" type="xs:string" minOccurs="0"/>
<xs:element name="name" type="xs:string" minOccurs="0" />
<xs:element name="manufacturer" type="xs:string" minOccurs="0" />
<xs:element name="model" type="xs:string" minOccurs="0" />
<xs:element name="version" type="xs:string" minOccurs="0" />
<xs:element name="class" type="xs:string" minOccurs="0" />
<xs:element name="ostype" type="xs:string" minOccurs="0" />
<xs:element name="osversion" type="xs:string" minOccurs="0"/>
<xs:element name="Node" type="Node"></xs:element>
<xs:element name="Process" type="Process" minOccurs="0" />
<xs:element name="Analyzer" type="Analyzer" minOccurs="0" />
</xs:sequence>
</xs:complexType>
Az AdditionalData osztály típusát leíró felsorolási típus:
<xsd:simpleType name="dataTypeENUM">
<xs:restriction base="xsd:string">
<xsd:enumeration value="allPrimitivType"/>
<xsd:enumeration value="XML"/>
<xsd:enumeration value="meaning"/>
</xsd:restriction>
</xsd:simpleType>
Additional data osztály. Fontos tudni, hogy az adott elem milyen típusú, és mi a szemantikai jelentése, ezért kötelező az összes tagja.
<xs:complexType name="AdditionalData">
<xs:sequence>
<xs:element name="data" type="xs:string" minOccurs="1" maxOccurs=”1”/>
<xs:element name="restriction" type="RestrictionENUM" minOccurs="1" maxOccurs=”1”/>
<xs:element name="type" type="dataTypeENUM" minOccurs="1" maxOccurs=”1”/>
<xs:element name="meaning" type="xs:string" minOccurs="1" maxOccurs=”1”/>
</xs:sequence>
</xs:complexType>
Az egyik legösszetettebb osztály az EventData. Az incidens során feltárt információkat tartalmazó osztály. Ez is rekurzívan hivatkozik magára, illetve több gyermekosztály is még csoportosítási szándékkal szerepel benne:
<xs:complexType name="EventData">
<xs:sequence>
<xs:element
name="restriction" type="RestricitonENUM" minOccurs="1"
maxOccurs=”
<xs:element name="Description" type="RestString" minOccurs="1" maxOccurs=”Unbounded”/>
<xs:element name="DetectTime" type="xs:dateTime" minOccurs="0" maxOccurs=”1”/>
<xs:element name="StartTime" type="xs:dateTime" minOccurs="0" maxOccurs=”1”/>
<xs:element name="EndTime" type="xs:dateTime" minOccurs="0" maxOccurs=”1”/>
<xs:element name="Contact" type="Contact" minOccurs="0" maxOccurs=”Unbounded”/>
<xs:element name="Method" type="Method" minOccurs="0" maxOccurs=”Unbounded”/>
<xs:element name="Assessment" type="Assessment" minOccurs="0" maxOccurs=”1”/>
<xs:element name="Flow" minOccurs="0" maxOccurs=”Unbounded”>
<xs:complexType>
<xs:sequence>
<xs:element
name="restriction" type="RestrictionENUM"
minOccurs="1" maxOccurs=”
<xs:element name="System" minOccurs="1" maxOccurs=”Unbounded”>
<xs:complexType>
<xs:sequence>
<xs:element name="restriction" type="RestrictionENUM" minOccurs="0" />
<xs:element name="category" type="xs:string" minOccurs="0" />
<xs:element name="interaface" type="xs:string" minOccurs="0" />
<xs:element name="spoofed" type="xs:string" minOccurs="0" />
<xs:element
name="Node" type="Node" minOccurs="1" maxOccurs=”
<xs:element name="Service" minOccurs="0" maxOccurs=”Unbounded”>
<xs:complexType>
<xs:sequence>
<xs:element name="ip_version" type="xs:string" minOccurs="1" maxOccurs=”1”/>
<xs:element
name="ip_protocol" type="xs:string" minOccurs="1"
maxOccurs=”
<xs:element
name="port" type="xs:string" minOccurs="0"
maxOccurs=”
<xs:element name="Portlist" minOccurs="0" maxOccurs=”1”>
<xs:complexType>
<xs:sequence>
<xs:element name="port" type="xs:string" minOccurs="1"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="Application" type="xs:string" minOccurs="0" maxOccurs=”1”/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="Counter" type="Counter"></xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="AdditionalData" type="AdditionalData" minOccurs="0" />
<xs:element name="Record">
<xs:complexType>
<xs:sequence>
<xs:element name="restriction" type="xs:string" minOccurs="0" />
<xs:element name="RecordData">
<xs:complexType>
<xs:sequence>
<xs:element name="restriction" type="xs:string" minOccurs="0" />
<xs:element name="DateTime" type="xs:dateTime" minOccurs="0" />
<xs:element name="Description" type="Description" minOccurs="0" />
<xs:element
name="RecordItem" minOccurs=”
<xs:complexType>
<xs:sequence>
<xs:element name="type" type="xs:string" minOccurs="1" maxOccurs=”1”/>
<xs:element
name="data" type="xs:string" minOccurs="1"
maxOccurs=”
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element
name="Analyzer" type="Analyzer" minOccurs=”
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
Counter osztály:
<xs:complexType name="Counter">
<xs:sequence>
<xs:element name="count" type="xs:integer" minOccurs="1" maxOccurs=”1”/>
<xs:element name="type" type="xs:string" minOccurs="1" maxOccurs=”1”/>
<xs:element name="meaning" type="xs:string" minOccurs="1" maxOccurs=”1”/>
</xs:sequence>
</xs:complexType>
Maga az IODEF gyökér sablonja, minden IODEF dokumentum ezt tartalmazza, mint gyökér elemet:
<!-- IODEF ROOT -->
<xs:complexType name="IODEF">
<xs:sequence>
<xs:element
name="version" type="xs:string" minOccurs="1"
maxOccurs=”
<xs:element
name="Incident" minOccurs=”
<xs:complexType>
<xs:sequence>
<xs:element
name="purpose" type="xs:string" minOccurs="1"
maxOccurs=”
<xs:element
name="restriction" type="RestrictionENUM"
minOccurs="1" maxOccurs=”
<xs:element
name="IncidentID" type="IncidentID" minOccurs="1"
maxOccurs=”
<xs:element
name="AlternativeID" minOccurs=”
<xs:complexType>
<xs:sequence>
<xs:element
name="restriction" type="RestrictionENUM"
minOccurs="1" maxOccurs=”
<xs:element name="IncidentID" type="IncidentID" minOccurs="0" maxOccurs=”Unbounded” />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element
name="RelatedActivity" maxOccurs=”
<xs:complexType>
<xs:sequence>
<xs:element
name="restriction" type="RestrictionENUM"
minOccurs="1" maxOccurs=”
<xs:element name="IncidentID" type="IncidentID" minOccurs="0" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element
name="AdditionData" type="AdditionalData" minOccurs=”
<xs:element name="Contact" type="Contact" minOccurs="1" maxOccurs=”Unbounded”/>
<xs:element name="StartTime" type="xs:dateTime" minOccurs="1" maxOccurs="1" />
<xs:element name="EndTime" type="xs:dateTime" minOccurs="1" maxOccurs="1" />
<xs:element name="DetectTime" type="xs:dateTime" minOccurs="1" maxOccurs="1" />
<xs:element name="ReportTime" type="xs:dateTime" minOccurs="1" maxOccurs="1" />
<xs:element
name="Expectation" minOccurs=”
<xs:complexType>
<xs:sequence>
<xs:element name="restriction" type="RestrictionENUM" minOccurs="1" maxOccurs=”1”/>
<xs:element name="priority" type="xs:string" minOccurs="0" maxOccurs="1" />
<xs:element name="category" type="xs:string" minOccurs="0" maxOccurs="1" />
<xs:element name="Description" type="RestString" minOccurs="1" maxOccurs="Unbounded" />
<xs:element name="StartTime" type="xs:dateTime" minOccurs="0" maxOccurs="1" />
<xs:element name="EndTime" type="xs:dateTime" minOccurs="0" maxOccurs="1" />
<xs:element name="Contact" type="Contact" minOccurs="0" maxOccurs="1" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element
name="Method" type="Method" minOccurs=”
<xs:element
name="Assessment" type="Assessment" minOccors=”
<xs:element
name="History" minOccurs=”
<xs:complexType>
<xs:sequence>
<xs:element name="restriction" type="xs:string" minOccurs="0" />
<xs:element name="HistoryItem">
<xs:complexType>
<xs:sequence>
<xs:element name="restriction" type="xs:string" minOccurs="0" />
<xs:element name="type" type="xs:string" minOccurs="0" />
<xs:element name="IncidentID" type="IncidentID"></xs:element>
<xs:element name="DateTime" type="xs:dateTime" minOccurs="0" />
<xs:element name="Description" type="Description" minOccurs="0" />
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="EventData" type="EventData" />
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:schema>
A fent definiált séma segítségével jól formált és érvényes XML dokumentumokat hozhatunk létre, melyek rögtön magukban hordozhatják azokat a plusz információkat, melyek szükségesek egy másik CSIRT csoporttól kapott adathalmaz konzisztens, sikeres beillesztéséhez a saját adatbázisunkba.
Az egyes simpleType típusokat elő-feldolgozhatjuk, így biztosítva, hogy a mi adatbázisunkba is megjelenjenek a más CSIRT által használt ENUM értékek. Megfelelő munkafolyamat támogatás mellett ez segíthet a saját leírónyelvünk bővítéséhez, dokumentált incidensek és körülményeik pontosabb ábrázolásában
Szerverek közti kommunikáció két okból indulhat. A CSIRT csoport szinkronizál a másik csoporttal, vagy keresni szeretne más adatbázisában. A keresés indulhat automatikusan, az adatbázisba érkezett adatok (riasztások, események) alapján, vagy CSIRT tag kezdeményezhet célzott keresést.
Az XML alapú kommunikáció előnye, hogy könnyen lehet a HTTP protokollra ráültetni, azon továbbítani. Esetünkben a publikálásnak több módja is lehet, a statikusan generált XML reportoktól egészen a dinamikusan, CGI vagy egyéb szerver oldali script vagy kiszolgálóprogram által előállított az adott kéréshez igazodó tartalommal. Maga a megoldás függhet a szerver egyéb kiszolgálói feladataitól, vagy a CSIRT naprakészségétől és kapcsolodó CSIRT csoportok számától.
HTTP protokoll eleve ad megoldást az autentikálás problémájára, így a jogosultság-kezelés is a protokoll felett szabványosan kivitelezhető. A hitelesítés történhet HTTP fejlécben hordozott információ alapján, de megvalósítható form alapon, emberi beavatkozást igénylő módon.
Az XML terjedelmes méretű leírónyelv, az optimalizált adatátvitel érdekében hasznos a tömörítése utaztatás alkalmával, erre is ad megoldást a HTTP protokoll, ma már sok (web)szerver támogatja az on-the-fly tömörítést a lekérések és válaszok feldolgozásakor.
Az adat sok szerver érintésével érkezhet meg a cél gépre, ezért a tömörítésen felül az adat titkosítása is fontos szempont lehet. Ehhez egy újabb réteg beszúrása szükséges, de a protokoll szabadsága (fejléc szerkezete) lehetővé teszi a többi réteg számára átlátható módon való implementálását a titkosító algoritmusnak.
A választott operációs rendszer és környezetből következőleg ez a diplomamunka a teljes mértékben dinamikusan generált XML kimenetet írja le, a Microsoft által biztosított széles technikai paletta segítségével.
A szerverek közti kommunikáció alapja a HTTP-POST lesz URL vagy SOAP protokoll által vezérelve. A technológia előnye az interaktív kommunikáció lehetőségeinek kihasználása, a kérő meghatározhatja, hogy pontosan milyen adatra van szüksége szűrési feltételek segítségével.
Univerzális technológiai platform
A .NET technológiai platform legfontosabb összetevője egy minden elemében újratervezett (ASP volt az első webes megjelenése a cégnek, erre a tudásra építve tervezték újra és gondolták újra a webet, mint felhasználói felületet), teljes programozási rendszer, az ún. .NET Framework. Ebben a következők vannak:
A cég kidolgozta a kisméretű, erőforrások tekintetében korlátozott eszközökön használható, .NET Compact Framework változatot is, így lehetőséget teremtve a pocketPCk és egyéb okos-telefonok felületének tovább fejlesztésére. Ezzel a hatékonysággal egy CSIRT esetén a vállalat bármely pontján WiFi segítségével, vagy akár offline azonal felvihető az adat, vagy a körülmény, ami nagyban hozzájárul a pontos adatrögzítéshez, az adatbázis hasznos növekedéséhez.
Így a platform különlegessége az is, hogy a mobil telefonoktól a legnagyobb gépekig terjedően mindent lefed.
A .NET technológiai platform másik összetevője a fejlesztőrendszer. Ebből több is van. A parancssorról és egyszerű szövegszerkesztőből használható .NET Framework SDK. Az ennél minőségileg nagyobb hatékonyságú Visual Studio .NET.
XML és Web szolgáltatások
A Microsoft a .NET – mint stratégiai elgondolás és ezt támogató technológiai platform – segítségével tette, illetve teszi minden termékét XML alapúvá, így könnyítve meg az univerzális felületet és kereszt-fejlesztéseket. A „.NET magában foglalja az XML-t” képlet alapján fejlesztik a Microsoft termékeket már vagy 6 éve. Komplett namepsace és osztálycsokor tartozik, mind az XML-hez, mind a Web Service részhez, komplett SOAP támogatással.
Az XML-re a maga teljes spektrumában kell gondolnunk. Abban az értelemben, hogy például ennek keretében készült el a SOAP specifikáció, majd ehhez a WSDL (Web Services Description Language) és a UDDI (Universal Description, Discovery and Integration), melyek segítségével a webes kommunikáció, az objektumok „web alapú” leírása került szabványos formába.
Ez utóbbira a legjobb példa az XML alapú Web szolgáltatások támogatása a fejlesztők irányában. Bármelyik .NET nyelven készült modul a szó szoros értelmében, egy mozdulattal Web szolgáltatássá alakítható. Egyszerűen a „[WebMethod]” attribútummal kell ellátni a megfelelő interfészt, és a platform maga gondoskodik az annak Web szolgáltatásként való hívásához szükséges átalakításokról. A fejlesztő környezethez járó kiegészítő programok segítségével egyszerűbb felületű szolgáltatások könnyen létrehozhatóak és üzembe állíthatóak.
ASP.NET WebForms, vezérlő elemekkel
A Windows környezetből már jól ismert kontrolok gyüjteményét a Microsoft áthozta a webre, és az ASP.NET segítségével a jól megszokott design-time szerkesztést is megvalósította, így tényleg gyors ás áttekinthető fejlesztést téve lehetővé web alatt is.
Egy CSIRT rendszer implementációja szükség esetén teljes mértékben a webre korlátozódhat, nincs szükség kliens oldali programozásra, vastag kliens kifejlesztésére, és mindkét oldal (kliens-szerver) párhuzamos karbantartására.
További áttörés a fejlesztés sebességében, hogy a böngésző típusától függetlenül fejleszthetjük a webes megjelenítést, mivel az ASP.NET gépezet belsőleg maga gondoskodik az egyes böngészőknek megfelelő leképzésekről. Ez egészen a mobil eszközökön alkalmazott, ún. mikro böngészőkig terjedően igaz.
távoli metódushívás
XML segítségével könnyen tudunk objektumokat platform függetlenül szerializálni. Ez feltételezi, hogy a túloldalon ezt az objektumot fel is tudjuk építeni, azaz minden osztályleíró információ megvan ahhoz, hogy újra építsük az objektumot a hálózaton keresztül. Ha az osztálytípus teljes, akkor az osztályhoz tartozó metódusok is megvannak, ekkor már csak egy apró lépés választ el attól, hogy az újra felépített objektumon, vagy objektummal, mint adat hívható legyen tetszőleges metódus. Erre ad lehetőséget a SOAP protokoll.
Előfeltétele tehát, hogy a hívó által megadott osztály, a szerializált objektum adata a túloldalt hiánytalanul felépíthető legyen, és a megadott paraméterekkel a metódus hívható legyen. A hívás visszatérési értéke szintén szerializálódjon és visszakerüljön a hívóhoz. Ez a kör nagyon hasonlít a HTTP protokoll kérés-válasz felületéhez, ahol POST kérésben érkezik meg a paraméter objektum, amit a web service értelmez, feldogoz, végrehajta a hívást, majd az eredmény objektumot visszajuttatja a lekérés válaszaként.
SOAP felett megvalósított CSIRT kommunikáció előnye ismét a platform függetlenség, és az elosztott rendszerekben rejlő erő. Egy nagyobb szervezetnél a rendelkezésre álló adat nagysága esetleg lehetetlenné teszi a folyamatos szinkronizálást. Ez esetben a teljes rendszer implementálható úgy, hogy az egyes alegységek egy-egy részét képezik elosztott rendszer elemeiként a teljes CSIRT modellben.
A weben megvalósított szinkronizációs, és kereső felületeket megfelelő védelemmel ellátva külső CSIRT csoportok is igénybe vehetik, alkalmas erőforrás menedzsment esetén, figyelmet fordítva arra, hogy priorítása az elosztott rendszer részeként érkezett hívásoknak legyen.
Másik előnye a HTTP-re ültetett SOAP protokollnak, hogy könnyen válnak elérhetővé a tűzfal mögött elhelyezett szolgáltatások, és nincs további hálózati konfiguráció szükség, ha már elérhető a szolgáltatás a webszerveren.
A protokoll kinézete
Maga a hívás egy text/xml alapú HTTP lekérés lesz, ahol a POST rész fogja tartalmazni a SOAP Envelope-ot, a borítékot, ami leírja melyik szolgáltatást kívánja a hívó fél igénybe venni, milyen paraméterekkel. A boríték a http://schemas.xmlsoap.org/soap/envelope/ namespace-t használja, és két részből áll: header (fejléc) és body (test).
Test
A Body elem használható egy eljárás hívás paramétereinek (request irány), vagy egy eljárás visszatérési értékének csomagolásához, illetve hiba visszajelzéséhez is (response irány). Állhat magában is (tehát nem kötelező a fejléc kitöltése), de a test kötelező.
A Body elemben lévő bejegyzéseknek namespace-hez tartozónak kell lenni.
Fejléc
A Header rész egy eljárás hívásának kibővítéséhez használható egyéb, előre nem meghatározott funkciókkal. Ilyen tipikus funkciók például a tranzakciókezelés, felhasználó azonosítás.
A Header elemben lévő bejegyzéseknek szintén namespace-hez tartozónak kell lenni. A Header-ben szereplő elemeknek speciális attribútum is adható.
Az egyik ilyen attribútum a mustUnderstand, melynek szerepeltetése 1 értékkel azt jelenti, hogy ha a szerver oldalon az adott fejlécelem nem ismert, nem értelmezhető, akkor a hívást kötelező visszautasítani. Elhagyása esetén a nem ismert elem egyszerűen figyelmen kívül lesz hagyva.
A másik, szintén fontos attribútum az actor. Egy SOAP hívás feldolgozása alatt keresztülhaladhat több objektumon is, míg eljut a végcélhoz. Az actor adja meg annak az objektumnak az URI-jét, ami az adott fejlécelemet feldolgozza. Ilyen lehet például a tranzakciókezelő, hogyha a header elem egy tranzakció azonosító. Az actor elhagyása esetén a feldolgozás a végcél feladata.
A továbbítható adattípusok a W3C konzorcíum által kiadott séma specifikációban található típusok.
Ha a szervernek nem sikerült valami miatt végrehajtani egy hívást, hibával kell visszatérnie. Ilyenkor a Body egy Fault elemet tartalmaz, aminek a következő részei lehetnek:
Hiba esetén a válasz HTTP fejlécében az “500 Internal Server Error” hibaüzenetnek kell megjelennie.
Az XSD által leírt osztály hierarchia jól tükrözi a valóságot, azt a felfogási struktúrát, amit az emberi agy képvisel. Az összetartozó információkat a szülő közrefogja (XMLben szó szerint) és egy egységként láttatja. A relációs adatbázisban típus szerint vannak tárolva az adatok, és azonos típusú dolgok egy táblába kerülnek, majd idegen kulcsok segítségével kapcsolatot teremtünk a táblák között, így írva le a szülő-gyermek kapcsolatot is. A technológiából fakadóan egy szülőnek több gyereke lehet, de a gyereknek csak egy szülője, pontosabban fogalmazva a táblát annyi mezővel kell kiegészíteni, ahány szülő hivatkozást szerenénk bele tenni, vagy ha változó, hogy egy sornak hány szülője van, akkor újabb kapcsolótáblát kell használni ezen reláció leírására, ahol megadjuk, hogy az adott gyerek sor mely szülőkhöz tartozik (ekkor már nem is szerencsés szülő-gyerek kapcsolatról beszélni).
A probléma azonnal jelentkezik, amint a mai környezet adta lehetőségeket szeretnénk használni. .NET Framework támogatja az XSD leírást, de a széles körben használt és sok-sok osztállyal kiegészített adatkezelés a DataSet osztályra épül, ami egy szűkebb XSD leírást fogad csak el, és ebből az egyik alapfeltétel, hogy azonos nevű gyerekelemek nem lehetnek a leíróban, mert az IDE tervezési időben generál hozzá kódot, hogy a forrásban típusosan lehessen hivatkozni az adatra (táblákra, oszlopokra).
Ha nem lenne ez a feltétel, akkor a beérkező XML adatot képtelen lenne elemezni, mert a fent említett hibába ütközne, amikor relációs alapokra helyezett tárolású DataSetbe töltené be.
A megoldásra 2 különböző mód lehetséges:
Ekkor vagy plusz információként tároljuk a kapcsolódási adatot, vagy csak egy irányú kapcsolat lesz az adatok között, azaz a gyerekelem nem fogja tudni, hogy ki a szülője (csak egy ID tárolódik, amiről nem lehet tudni, hogy melyik táblában van a gyerek oldaláról). A szülőtáblák ID készlete diszjunktnak kell lenni a visszakereshetőséghez.
Másik megoldás, hogy annyi mezőt feszünk fel szülő tárolására, ahány szülő lehetséges. Ekkor megmarad az idegenkulcs kapcsolat, de problémát okozhat, ha bővíteni szeretnénk a szülők számát, vagy a gyermek nem tartozik minden szülőhöz.
Harmadik megoldás, ami talán legjobban lefedi ezt az esetet, amikor van egy szülő ID és egy típus mező, ami meghatározza, melyik szülőről van szó.
Helyzetfüggő, hogy melyiket érdemes választani a megvalósításnál. Az első eset hasonlít a mezőfelvételes esetthez, amikor annyi mező van, ahány szülő. Univerzális rendszereknél, ahol XSD alapon jönnek létre a táblák és dolgozódnak fel az adatok szerencsésebb a táblák létrehozását választani, mert könnyebb automatizálni, mint a mező létrehozást, és kevesebb probléma adódik a NULL értékű mezők hiánya miatt. Hátránya a keresésnél azonos típusú adat esetén több táblában is kell keresni, XML rekonstruáláskor a folyamatot visszafelé is el kell végezni.
A mezőszaporítást abban az esetben érdemes bevetni, ha a struktúra nem változik, és nem okoz implementációs problémát a NULL mezők használata, vagy a szülők száma kisszámú, és gyakran előfordul, hogy több szülő ugyan azon adatú gyereket tárolná. Keresés gyors lesz, és rögtön megmondható a találatról, hogy mely szülőknél szerepel, nincs szükség újabb keresésre. Hátránya a már említett NULL probléma, és adat módosítása során a sort dublikálni kell üzleti logikától függően (mi esetünkben ez fenn állna, ezért nem javallott).
A harmadik lehetőség hasonlít legjobban az XML -> relációs adatbázis problémánál. Minden objektum egyedi, és csak egy szülőhöz kapcsolódik, ezért elég gyermekenként egy hivatkozás tárolása, és a hivatkozás típusának tárolása. Így egy táblában tárolható az összes azonos típusú adat, keresésnél azonnal megmondható mely szülőhöz tartozik, nincs NULL érték probléma, és az egyedi sorok miatt nincs módosítási/törlési probléma sem.
Hátránya, hogy adatbázis szinten nem lehet idegenkulcs ellenőrzést kérni, ezt az üzleti rétegnek kell megvalósítania. A struktúra könnyen bővíthető a későbbiekben újabb szülőkkel.
Mi ez a megoldást választottuk a specifikációhoz. A szülők típusát egy listaérték táblában tároljuk, melyben a hivatkozott tábla neve szerepel.
A fenti feladatra több megoldás is adható, annak függvényében, hogy milyen bonyolultsági szintet célzunk meg, és milyen környezetben szeretnénk üzemeltetni a programot.
Én most egy web service alapú kiszolgálót írok le, mely 2 fő funkcionalitást valósít meg:
Architectúra a Microsoft .NET Framework-re fog támaszkodni, és maximálisan kihasználja a technológia adta előnyőket, melyből a három fő pillért előzőekben érintettem (XML, XSD, SOAP). A felhasznált nyelv a C# lesz, ezen a nyelven adom meg a specifikációt is.
Az adatbázis SQL szintű leírását az [1] tartalmazza, erre építem fel az adatkezelő réteget, ennek segítségével egy üzleti logika réteg fogja kiszolgálni web service-en keresztül a kéréseket. Kliens oldalon vastag klienseket ajánlok a jobb kezelhetőség érdekében, de a publikált web service felületre hamar ráültethető egy ASP.NET alapú kliens oldal, mely képes böngésző alapú eszközöket is kezelni, így akár egy kéziszámítógépről is menedzselhetővé tenni a CSIRT adatbázist.
A lefedendő funkciónalítás:
A komunikáció „stateless” lesz, állapot nélküli. Ezért a feladat érdekessége, hogy mindig a kapott adat és az adatbázisban lévő adat alapján kell megállapítani a változást az adaton, mivel az XMLben nem tárolódik adat arról, hogy milyen változtatások mentek végbe a kliens (vagy másik szerver) oldalon.
Következőekben az egyes funkciókat veszem sorra, hogy milyen üzleti logikát milyen lépéssorozattal valósítanak meg, majd részletezem az implementáláshoz szükséges osztályokat, és szót ejtek használatukról.
Új IODEF dokumentum felvitele.
A szolgáltatás egy XML dokumentumot vár, mely megfelel az XSD leírónak. A kapott dokumentumot felülről lefelé indulva XPath alapján feldolgozza rekurzívan. A dokumentum minden elemét új adattagnak veszi fel az adatbázisba, azoknál az objektumoknál, ahol ID hivatkozás van más objektumokra (ilyen csak IncidentID lehet), nem ellenőrzi, mert későbbi bekerülés lehetséges az adatbázisba, illetve későbbiekben funkcióbővítéssel elérhető, hogy lekérje az adott CSIRT csoport adatbázisából.
A dokumentum feldolgozása a gyökérelemmel kezdődik. Minden szinten az első lépés, hogy az XML element-ek eleget tesznek-e az XSDben megadott formulának. Ha igen, akkor létre hozható az adott IODEF dokumentum root eleme, és kitölthetőek azok az adatok, amik egyszerű típusokból származnak, vagy alaptípusok, mert ezek mező szinten jelennek meg az adatábázisban. Ezek után már van egyedi azonosítónk az incidenshez, létrehozhatóak a gyerekek. A komplex típusokat kell sorra venni, és szintén végig venni az egyszerű típusokat, amik azonnal tárolhatóak a típushoz tartozó táblában. A tábla szülő ID mezője is tölthető, hisz a felülről lefelé elv miatt mindig van már szülő ID, ami használható hivatkozásként, és tudjuk a típusát is, hogy a szülő típusát tároljuk az ID mellett.
Cálom egy teljesen univerzális motor megírása, mivel még mindig sok változtatás várható az osztály-hierarchiában, és így az XSD leírójában. Ha sikerül olyan modellt megadni, mely képes csak az XSDben megadott adatok alapján, és néhány plusz szabály betartása mellett működni, akkor életre hívható egy olyan kiszolgáló oldal, ami sémavezérelten tud működni, és elég csak az XSDt módosítani ahhoz, hogy követni tudja az osztályok változásait. Ehhez természetesen elengedhetetlen az adatbázis változtatása, de az vagy megoldható mezők és táblák felvitelével (többnyire bővítésre számítok, mint sémaváltozásra), vagy SQL tárolt eljárásokkal átalakítható az adatábázis szerkezete az új igényeknek.
Ehhez arra van szükség, hogy az sémában attribútum szinten támogatást kapjon ez az univerzális motor arra vonatkozóan, hogy melyik adattal milyen további dolga van.
Megkötések közül elsőnek az XML element-ek és a táblák párosítását említteném, amire legkézenfekvőbb megoldás, hogy az element típusdefiníció nevét használnám fel, ehhez meg kell szüntetni az összes nested (rejtett) típus definíciót, de ez csak alaki kérdés a sémában, szemantikai változást nem eredményez. Maga a tábla mezői a típus definícióban szereplő element tagok egyszerű típus esetén, és további gyerektáblák ComplexType esetén. A típushoz tartozó táblát még ki kell egészíteni három mezővel, amikről már volt szó, az egyik a sor egyedi azonosítója lenne, a másik kettő a 3-a részben említett szülő ID mező és a szülő tábla neve, ami ez esetben a szülő típus neve.
Így megkapnánk az XSD egy reláció adatbázisú megfelelőjét.
Ezek a megkötések és plusz információk után a beérkező XML dokumentum gyökér eleme IODEF típusúnak kell lenni, és az ilyen nevű táblába kerül egy ID. A RestString táblába rögtön két bejegyzés is kerül, az egyik a restriction, a másik a purpose bejegyzés lesz, ezekhez a sorokhoz az elöbb létrejött IODEF egyedi sor ID-ja kerül be, mint szülő ID, és szülő típushoz az IODEF. Ugyan ezt a logikát követve átalakítjuk az érvényes XML dokumentumot egy relációs adatbázisban tárolt adathalmazzá. Ha valahol sérül menet közben a séma, akkor hibaüzenettel térünk vissza a szolgáltatást hívóhoz, és az adatbázis tranzakciót visszavonjuk, így az összes beszúrásunk visszavonódik, visszaáll az „eredeti” rend.
Az ID-t mi állítjuk elő, ezért az biztosan létezik, míg a szülő típus hivatkozás azért létezik biztosan, mert a szülő ID beszúrásához léteznie kellett ilyen nevű táblának, így az adatbázis konzisztencia is biztos fennáll. Sajnos teljes értékű védelmet, mint idegenkulcs nem tudunk tenni a mezőre, de esemény triggerekkel megoldható a konzisztencia fenntartása.
Módosításnál ez nem sérülhet, mert olyan eset nincs, amikor szülőt cserél egy gyerekelem, ezért csak a törléssel kell foglalkozni (módosítást később részletezem). Azt az ellenőrzést kell végrehajtani, hogy amely táblákban szerepelhet, mint hivatkozás a sor ID-ja, ott ténylegesen szerepel-e, azaz van olyan gyerek, aki hivatkozna a törlendő sorra. Az, hogy melyik táblákban szerepelhet, kiderül a tábla XSD sémájában található ComplexType definíció alapján.
Visszatérve a létrehozásra, az XML dokumentum bekerült az adatbázisba, akkor sikeres választ kell adni a kérésre, és az IODEF azonosítóját.
Sikertelen létrehozás esetén az XML sort kell megjelölni, ami a hibát okozta.
UpdateResult newIODEFDoc(System.Xml.XMLDocument)
UpdateResult osztály a következő tagokat tartalmazza:
bool success - Logikai érték, ami igaz, ha a hívás lefutott sikeresen.
string resultID Sikeres végrehajtás esetén az IODEF IDja, hiba esetén a hibás sor.
string errorStr Hiba esetén szöveges üzenet a hibára, ekkor a resutlID tartalmazza a hibás XML sor számát.
Meglévő IODEF dokumentum lekérése ID alapján
A bemeneti paraméter egy ID. Ezzel a hívással csak a saját tábla ID alapján lehet lekérni az XML dokumentumot, nem pedig az IncidensID alapján, ami globálisan egyedi. Arra a lehetőségre a tetszőleges osztály alapján lekérhető metódusnál lesz lehetőség.
A válasz minden esetben egy XML dokumentum. Ez vagy a kért IODEF dokumentumot tartalmazza, mint gyökér elemet, vagy egy hibát leíró dokumentum Error gyökérelemmel.
Híváskor érkező ID-t meg kell vizsgálni az adatbázisban, hogy szerepel-e az IODEF táblában. Ha szerepel, akkor séma alapján felépíteni az XML dokumentumot a következő lépések alapján:
Sémában megadott egyszerű típusokat generálni, és értékkel kitölteni, majd nested (rejtett) tagokat előállítani a sémában szereplő ComplexType alapján. A már említett név megfeleltetés alapján egyértelmű mely táblában kell a sorokat leszűrni az aktuális elem típusára, és a táblában a szülő ID-t az aktuális ID-ra. Ekkor előállnak a ComplexType egyszerű típusainak értéke, és a tartalmazott ComplexType-okat rekurzívan ugyan így. Érdemes bele generálni a táblák kulcsait az XMLbe, mert így könnyebb lesz a módosított információ feldolgozása, amikor visszaérkezik a kliensről. A séma ne változzon, használjuk erre az attribútumokat, az element részben legyen egy tableID, ahova elrakjuk az adott adat egyedi azonosítóját.
Lekérés után a következőeknek megfelelően fog kinézni egy XML dokumentum:
<IODEF tableID=”1”>
<version>1.0</version>
<purpose>….</purpose>
….
<IncidentID tableID=”2”>
<restriction>public</restriction>
<UID>1234567</UID>
<NAME>CSIRTNAME</NAME>
</IncidentID>
<History tableID=”3”>
…
</History>
…
Hiba esetén a dokumentum egy Error dokumentumot fog tartalmazni, aminek minimális eleme egy message element, ami szöveges formában tartalmazza a hiba üzenetet. Példa:
<Error>
<Message>Nem létezik ilyen számú IODEF dokumentum.</Message>
</Error>
Alakja:
System.Xml.XMLDocument SearchByID(int)
IODEF dokumentum módosítása.
Módosítani egy IODEF dokumentumot csak csoporton belül lehet, ezért nem erős megszorítás az, hogy csak olyan XML dokumentum fogadható el feldolgozásra, ami általunk lett generálva, és szerepel benne a táblák ID hivatkozása. Későbbiekben, ha igény van rá megoldható, hogy tetszőleges IODEF dokumentum módosításra elfogadható legyen, ekkor legegyszerűbb megoldásként szerver oldalon egy tranzakcióban először törölni kell, majd beszúrni az új dokumentumként. Szükséges azon logika megvalósítása is, hogy ekkor képes legyen az AlternativeID-k között is keresni, ne csak az IncidentID-k között.
Fontos szempont bármely módosításnál, hogy az IncidentID és az AlternativeID-k nem változhatnak a dokumentumhoz (az AlternativeID lista bővülhet), azaz egy CSIRT nem változtathatja meg egyszer már létrehozott dokumentum globális egyedi azonosítóját.
A módosítás menete a következő:
UpdateResult ModifyIODEF(System.Xml.XMLDocument)
A metódus egy XML dokumentumot vár, aminek a tableID attribútumai szerepelnek az element részben, de csak a gyökér elemre követeljük meg kötelezően. Mint az új létrehozásánál, a séma alapján be kell járni a fát, és az egyes gyerekeket kikeresni a táblákból. Ha a nested element tagoknál szerepel tableID attribútum, akkor az egyszerű típusú adatokat felül írni a táblában. Ha nem szerepel tableID az element részben, akkor új elemről van szó, be kell szúrni, mint az új elem hozzáadásánál (rekurzívan a gyerekeket is). A végén listát kell készíteni az XMLben szereplő tagokról (beleértve az újonnan felvett elemeket is) és ID-jukról, illetve az adatbázisban szereplő tagokról és ID-jukról (természetesen itt a szülő ID-ja megszorított listáról beszélek). A listát összehasonlítani, és azon sorokat törölni a táblából, ahol nincs párja az XML dokumentumban ebben a magasságban. Ezzel töröltük azon objektumokat az adatbázisból, amik törlődtek az XML dokumentumból. Fontos végrehajtani a rekurzív törlést a séma alapján a fában, hogy törlődjenek az adott taghoz tartozó gyerek elemek is.
A folyamat végeredménye a módosított XML dokumentum adatbázis beli ábrázolása. A folyamat előnye, hogy semmiféle információval nem kellett rendelkezni arról, hogy milyen sorrendben történtek az XML dokumentumban a módosítások, és az adatbázis is használható volt a módosítás ideje alatt.
Web service-eknél gyakori logika az „utolsó mindent visz”. Ha párhuzamosan többet kérik le feldolgozásra ugyan azt a dokumentumot, akkor az utoljára betöltött dokumentum lesz érvényes az adatbázisban. Egy ilyen rendszernél felmerülhet a fizikai törlés nem kívánatos volta. Erre több lehetőség is adott:
· Az elemet csak törlésre jelöljük meg, fizikailag marad az adatbázisban, és vagy szűrve kérhető le, attribútummal megjelölve a törlés időpontját.
· Külön archív adatbázist vezetni, ahol minden törlés elött egy pillanatkép készül a dokumentumról. Ez nagyobb biztonságot ad, és egy verziókövetést a dokumentumhoz.
Minkét esetben további módosítás szükséges az adatbázis kezelési logikán, ami nagyban elbonyolítani a mostani architectúrát.
Az UpdateResult tartalma visszatéréskor:
bool success - Logikai érték, ami igaz, ha a hívás lefutott sikeresen.
string resultID Sikeres végrehajtás esetén az IODEF IDja, hiba esetén a hibás sor.
string errorStr Hiba esetén szöveges üzenet a hibára, ekkor a resutlID tartalmazza a hibás XML sor számát.
Keresés az adatbázisban objektum alapján
Az esetek többségében a lekérés nem ID alapú, mivel a felhasználó adott adatra, vagy adatrészre keresne rá. Ha meghatározza, hogy melyik osztály alapján akar keresni, akkor válaszként megkaphatja a találatnak megfelelő IODEF dokumentumok ID-jait. A válasz azért ID lista, mert nem tudható előre, hogy hány találat lesz az adatbázisban az adott keresésre, és igény szerint a hívó tovább szűkítheti, vagy lazíthatja a keresési feltételt, esetleg részinformációkkal rendelkezik egyes dokumentumokkal kapcsolatban (például tudja melyeket nem akar lekérni biztosan). A találati lista alapján a már leírt lekérő szolgáltatással hozzá férhet a teljes dokumentumhoz.
System.Xml.Document SearchByObjects(System.Xml.XMLDocument)
A paraméter egy XML dokumentum, mely gyökér eleme tartalmaz egy ComplexType típust az XSD sémában megadottak közül. A szerver a típus neve alapján tudja, mely táblában kell keresnie. Fontos, hogy itt a legkülső típus neve nem az element neve a sémában, hanem a típus neve. Gyermekei is ki lehetnek töltve, ott már a normál elnevezést használva.
A feldolgozás a következő módon történik:
A típusnév alapján a rendszer tudja azonosítani mely tábláról van szó, a feltétel összeállításához nyilván kell tartani, hogy mely táblákra milyen megszorítás vonatkozott. Ez a legfelső típus esetében a mezőkre vonatkozó megszorítás. A gyerekeknél rekurzívan értelmezve kell összeállítani az egyszerű típusokra és gyerekenként egy plusz megszorítás hozzávétele, ami a táblát leszűkíti a megfelelő szülő ID-ra és szülő típusra. Mindkét információ rendelkezésünkre áll a szülőről.
A megkapott feltételrendszer segítségével elő állítható az adatbázisra vonatkozó keresés. A megkapott sorok alapján szintén rekurzívan „felfelé” meg kell keresni az IODEF táblát. Ehhez minden sorra végre kell rekurzívan hajtani a következő iterációt: Megnézni a szülőtábla típusát, amit a sor tartalmaz, ha ez nem IODEF, akkor kikeresni a sort a szülőtáblában a szülő ID alapján, majd ott újra végre hajtani ezt az iterációs lépést. Így minden sorhoz megkapjuk, hogy melyik IODEF dokumentumhoz tartozik. Ezek alapján előállítható a válasz, mely tartalmazza a kért ID listát. A dokumentum gyökerének gyerekei <IncidentID tableID=”zzzz”>…</IncidentID> sorok lesznek.
Keresés adatbázisban, tetszőleges mezőben
A „full text” keresés. Keresés egyik leghasznosabb módja, amikor tetszőleges adatra tetszőleges helyen leher keresni. Erre ad lehetőséget ez a metódus. A bemenő paraméter egy string, ami egy szót, vagy szavakat tartalmaz, amire VAGY kapcsolattal fog keresni a kereső. A válasz egy ID lista (mint az előző keresés esetén), ami tartalmazza azon IODEFeket, amikben szerepel ez a szöveg, és plusz információként, hogy melyik osztályban találta meg, és a talált szöveg környezetéből részletet. A gyökérelemben result elemek vannak, amik tartalmaznak egy ID tagot, az IODEF IDjával, egy type tagot, a találat helyének típusával, és a text tagot a szövegrésszel, ahol megtaláltam.
A metódus alakja:
System.Xml.XMLDokument SearchByFullText(string value)
A válasz XML alakja a következő:
<result>
<id>1</id>
<type>Method</type>
<text>….</text>
</result>
Ezen információ alapján a felhasználónak már megjeleníthatő az információ, és szükség esetén az IODEF lekérhető és megjeleníthető.
A szerver oldal használatához szükség van egy kliens oldalhoz (felhasználói felülethez), ami megjeleníti az IODEF dokumentumot, és lehetőséget ad a szerkesztésére.
.NET rendszerben lehetőség van megválasztani, hogy mely platformon valósítjuk meg a kliens felületet a web service szolgáltatásokhoz. Hasonló felület kialakítható lenne ASP.NET és Windows forms alapon is. Én a Windows forms alapút választottam, hogy bemutassam a keretrendszer által nyújtott technikai lehetőségeket, melyekről már írtam az előző részekben (SOAP feletti RPC).
A kliens három funkciót valósít meg:
A kliens program indítás után bekéri a szerver címét, mellyel együtt fog működni. A szerverrel felvett sikeres kapcsolat után a főmenüből lehet az egyes funkciókat elérni.
IODEF dokumentum megjelenítése
A dokumentum kiválasztásához egy keresőablakot dob fel a program, ahol tetszőleges osztálytípus kiválasztása után (az XSD alapján) a statikus mezői kitölthetőek, majd a keresés indítható. Az ablak ennek megfelelően varázsló szerüen elsőnek egy listát jelenít meg az IODEF osztályokkal, majd választás után az osztály elemi típusait lehet kitölteni.
A keresés a web service a SearchByObjects() metódusát hívja meg az objektum alapján elő állított XML paraméterrel.
A válaszként kapott XML dokumentumot fa nézetben megjeleníti. A csúcsokat a ComplexType-ok adják. A csúcs kibontása után az osztály elemi típusainak értékei láthatóak, illetve a gyermekosztályok kibontható megjelenéssel. A kibontott dokumentum hasonló kinézettel rendelkezik, mint egy explorerben kinyított könyvtár faszerkezet.
IODEF dokumentum szerkesztése
Szerkesztés indítható a dokumentum megjelenítése nézetből, vagy közvetlenül a főmenüből, ekkor szintén egy kereső ablak kerül feldobásra a dokumentum lekéréséhez. A kiválasztott dokumentum szerkesztési nézete hasonló, mint a megjelenítési, de kiegészül egy szerkesztő gombbal minden csúcsnál, aminek a hatására szerkeszthetővé válnak az egyszerű típusok egy újabb képernyőn, vagy ezen a képernyőn listából kiválasztható a hozzáadandó gyermek objektum.
A kiválasztott csúcs szerkesztésénél az új ablakban felül az egyszerű típusok beviteli mezői találhatóak, míg alatta egy lista a gyermek elemekről, ahova felvenni lehet olyan gyermekeket egy választólistából, amiben az objektum által tartalmazható gyermekek osztály típus listája van. A listából a kiválasztott elemet törölni is lehet.
A szerkesztés végeztével elküldhető a szerverre a dokumentum. A küldés a ModifyIODEF web service metódus hívásával történik. Sikeres mentésről, vagy a hibáról a program értesítést küld.
IODEF dokumentum létrehozása
A szerkesztő felület jelenik meg egy üres IODEF objektummal, ahova a már szerkesztéskor megszokott logikával lehet újabb gyermekeket felvinni. A szerkesztés további menete megegyezik az ott leirtakkal.
IODEF dokumentum átküldése más szerverre
Bármely nézet esetén lehetőség van a dokumentum elküldésére más szerverekre. Ekkor az adott szerverre a kliensprogram, mint új dokumentumot próbálja meg elküldeni. Ekkor nem a ModifyIODEF, hanem a newIODEFDoc metódus kerül meghívásra. Sikeres küldés esetén az adott folyamat folytatható.
IODEF dokumentumban több helyen használja az incidens ID-ját, mint hivatkozást, viszont egy incidenshez több ID is tartozhat az AlternativeID osztályon keresztül, mivel minden CSIRT saját IDt adhat hozzá. Ez nagyban megnehezíti a karbantartást és keresést az adatbázisban, együtt működést a CSIRT csoportok között. Előfordulhat, hogy a keresés meghiúsul, vagy nagyon lelassul az alternativeIDk keresése, vagy a hivatkozások visszakeresése miatt. Több, egy nagyobb szervezeten belül működő CSIRT csoportok kommunikációja ugyan arról a támadás(-sorozat)ról nehezen összeegyeztethető, visszakereshető.
Egy támadás bekövetkeztekor egyértelműen azonosítható a hely, ahol az információ keletkezett a támadással kapcsolatban, és az időpont, amikor a támadás bekövetkezett (vagy amikor kezdődött). Az egyedi azonosító legyen egy URN alapú a következő formában:
[CSIRT hivatalos neve]:[[csoport]/[hely]/[időpont]/[esetazonosító]]
Ahol:
A CSIRT hivatalos neve, a cég/hivatal/stb bejegyzett hivatalos neve az ország kétbetűs előtagjával kötőjellel elválasztva:
HU-CrystalSyndicate:…
A csoport a szervezeten belüli elnevezési az adott CSIRT csoportnak, minden csoportnak egyedi neve kell legyen egy szervezeten belül.
HU-CrystalSyndicate:szerverszoba
A hely lehet a támadás fizikai helye, de lehet a jelentéshez kapcsolodó logikai hely is, mint „active directory”.
Az időpont az incidens bekövetkeztének időpontja, ha ez nem áll rendelkezésre, vagy nem értelmezhető, akkor a létrehozás időpontja (ezredmásodperc pontosan).
Esetazonosító egy egyedi szám az URN egyediségéhez, abban az esetben, ha az adott idő pillanatban több esemény is bekövetkezett.
Ennek a kulcsnak az előnye, hogy egyedi lesz globálisan, és már maga a kulcs információt hordoz egy kereséshez, azonosításhoz. A kulcs mérete lényegesen megnő, de a mai kapacítások mellett és tömörítési lehetőségek mellett ez elhanyagolható.
Egy esetleges keresésnél, amikor a felhasználó infromációt gyüjtene, de nincs pontos adata, akkor ránézéssel is már információhoz jut az URN alakjából, mint amikor index-ről linkelnek be cikket, és látja, hogy a vélemény rovatból van, melyik témában, és még klikkelés elött előszűrést végezhető, hogy érdekes-e a téma, vagy nem.
Természetesen ez az ember által végzett „határozatlan” keresésnél jelent előnyt, gépi keresésnél az előnye ott jelentkezik, hogy nincs szükség az alternativeID osztályra, és esetleges részletes kereséshez előszűrést lehet végezni kézzel, és ID alapján már tudható mely szervezetek adatbázisaiban érdemes további kutatást megejteni, mely szintén nagyságrendekkel csökkentheti a keresési időket.
Ezt a változtatást nem emeltük be a saját osztályainkba, mert túl nagy változtatásnak ítéltük meg az eredeti koncepcióhoz képest, és nem tisztázott biztonsági kérdés szempontjából ezen ID információtartalma.
A mostani IODEF draft állapotú dokumentumban elég részletes már a technikai paraméterek leírása, de az első két fejezetben leírtak csak részben kerülnek rögzítésre. Nagyon hiányzik a leírásból az incidens bekövetkezésekor végrehajtott cselekvésterv dokumentálása. Ilyen lehet, hogy egy biztonsági rés miatt bekövetkezett incidens után milyen frissítésekre volt szükség az incidens jövőbeni elkerülése végett, vagy milyen egyéb külső programot telepítettek fel (tűzfal, vírusfigyelő), vagy milyen konfigurálást végeztek el a tűzfalon. A saját modellünkben az incidens osztályhoz adtunk hozzá egy ImprovementList osztályt, ami tartalmazza a következő tagokat:
Ezen osztály segítségével pontos akcióterv dokumentálható le lépéssorozattal az incidens részleges vagy teljes megelőzéséhez.
Napjainkban számos P2P hálózat létezik az interneten. Ezek a hálózatok ma még első sorban magán felhasználók igényeit elégítik ki fájlcserélés szinten, de egyre több tapasztalat gyűlik össze működési mechanizmusukkal kapcsolatban. Jól látható az a képességük, ami anno az Internet elődjét is életre hívta, a decentralizáltság és az ebből fakadó előnyök.
A folyamatos kapcsolat lehetőséget teremt a folyamatos kommunikációra, mely a hálózat fokozatos és megállíthatatlan növekedésének egyik alappillére. A hálózaton valaki publikál valami újdonságot, az futótűz szerüen terljed el, és lesz hozzáférhető millió másik ponton. Ez a tulajdonság, hogy az adat dublikálódik, és sok más helyen is hozzáférhető két nagyon fontos eredményt hoz:
A hálón bonyolódó forgalomból további információhoz juthatunk, ha statisztika készül a rajtunk áthaladó adatról és annak irányáról.
Ezen szempontok alapján vizsgáljuk meg, hogy a CSIRT működését hogyan lehetne ötvözni és ezzel tovább fejleszteni egy P2P hálón.
A hálózat egyes pontjai maguk a CSIRT csoportok szerverei. Minden pont tárolja a saját maga által létrehozott adatbázist és az eddigi élete során hasznosnak tartott és összeszedett információt. Egy incidens felülvizsgálatánál a személy, aki a vizsgálatot végzi különböző keresési feltételeket fogalmaz meg, hogy újabb adathoz jusson a hálózaton, mint amikor problémát próbálunk megoldani a google keresővel. A kérdéseket „felteszi” a P2P hálózatra, pont úgy, mint ahogy egy zenei fájlra keres ma rá egy egyetemista. A keresés elindul a hálón, és az egyes pontokról összesített információ áramlik vissza a kérdezőhöz. A felhasználó kiválogatja a számára releváns találatokat, és azokat lekéri saját szerverére.
A fájloknak megfelelnek az egyes incidens adatok, a felhasználóknak a CSIRT csoportok, P2P hálózat típusától függően (mint a Kazaa például) index szerverek működhetnek a hálózaton, mely gyorsítja az egyes keresések végeredményét, és növeli a találati számot. A lekért adat rögtön másolódott, biztosítva ezzel az adat fennmaradását, és nagyobb hozzáférhetőségét.
Ez a folyamat nem csak a találati arányt növeli, hanem a találat minőségét is fokozza, mert csak azok az adatok terjednek el nagy mennyiségben, melyek igazán hasznosnak bizonyultak, így biztosítva egy öntisztító folyamatot az adatban.
(Ezekben az osztályokban nagyon sok a folyószöveg, melynek minősége erősen függ a felviteltől. Azon incidens jelentések fognak nagyobb számban a hálón elterjedni, melyek jobb minőségben írják le a támadást és a hozzá tartozó kezelését vagy védekezést.)
A hálózat „inteligenciája” (találati arány és minőség) az önszerveződésen kívül növelhető értékelés bevezetésével, ekkor nem az incidens, hanem egy-egy csoportot lehet értékelni, és így előrébb sorolni keresésnél a többinél. Ez további sebességi és minőségi előnyt jelent a hálózaton.
A már említett index szerverek beállításával az újonnan érkezett leírások találati aránya is megnövelhető, hogy katalizálja az információ elterjedését. Ez többnyire regisztrációs elven működik, az újonnan felvitt adatot a CSIRT csoport szervere beregisztálja több indexer szerberbe, így biztosítva a publikálást.
Ma már több ilyen hálózat open source alapokra épül, és egyre nagyobb a szakirodalom, mely ezekkel a hálózatokkal foglalkozik. Előnyük az összehasonlíthatatlanul nagyobb elosztott adatbázis létezése, és 24 órás rendelkezésre állás miatt, mint a CSIRT csoportok független adatbázisa, vagy több CSIRT csoport együtt működése. Ehhez persze világméretű (de minimum kontinens szintű) hálózat felépítése szükséges, de az alapok már megvannak, és egy ilyen stílusú csoport munkába állítása lényegesen kisebb költségeket ró a cégre, mint a normál értelembe vett CSIRT osztályok, cégrészek kiépítése, ráadásul azonnal hozzáférhető az információ számukra.
A fentebb vázolt XML + SOAP + WDDI alapú megvalósítás és egy P2P hálózat (Gnucleus) integrálása robbanásszerű eredményt hozna ebben a témában meglátásom szerint.
Összefoglaló
A dolgozatom célja internetes biztonsági eseményeket katalogizáló rendszer tervezése volt. A biztonsági eseményeket kezelő csoport bemutatása után a valós életben tapasztalható menedzsment problémákkal foglalkoztam, elsősorban egy meglévő szervezetbe való bevezetéssel. Az osztályok ismertetése elött szóltam az XML-ről, mint leírónyelvről, előnyeiről, könnyű integrálhatóságáról, és nagy támogatottságáról a különböző rendszerekben. Az [1] munkára épülően közöltem egy XML séma reprezentációt, mely elég rugalmas bármely szervezet incidens menedzsment kezeléséhez, és elég metainformációt tartalmaz egy relációs adatbázisban tárolásához. Érintettem a Microsoft platformon elérhető technikákat, és kiemelten foglalkoztam a SOAP felülettel, mint jövőbe mutató protokollal távoli eljáráshíváshoz.
Specifikáltam a kiszolgálói oldalt, részletezve az egyes funkciónalításokat, kihasználva az XML séma erősségét, egy univerzális motort leírva, függetlenné téve az implementációt a mindenkori IODEF dokumentum tényleges alakjától. Specifikáltam egy Windows Forms alapú klienst, ami a kiszolgáló üzleti logikáját használva lehetőséget ad IODEF dokumentumok szerkesztésére.
Az utolsó fejezetben átfogóan tekintettem a problémára, és megoldási javaslatokat adtam az osztály hierarchia megváltoztatására, illetve egy más megközelítéssel felépített, P2P alapú CSIRT hálózatra.
Forrás hivatkozások
[1] Sebesi Gábor: Internetes biztonsági események
katalogizálása, diplomamunka
2005, ELTE-IK
[2] Terena CSIRT (http://www.terena.nl/), 2004.12.
[3] Defining Incident Management Processes for CSIRTs
(CMU/SEI-2004-TR-015)
1. fejezethez, és a képek forrása.
[4] Microsoft MSDN honlap 2 és 3 fejezethez
XML: http://msdn.microsoft.com/archive/en-us/dnarxml/html/xmlguide.asp?frame=true,
2005.01.20.
XSD: http://msdn.microsoft.com/archive/en-us/dnarxml/html/transschema.asp?frame=true,
2005.02.26.
SOAP: http://msdn.microsoft.com/library/en-us/dnanchor/html/WebServicesAnchor.asp?frame=true,
2005.06.03.
.NET keretrendszer, ASP.NET és további információk:
http://msdn.microsoft.com/netframework/,
2005.04.14.
http://msdn.microsoft.com/library/en-us/dnanchor/html/anch_webdev.asp?frame=true,
2005.06.03.
http://msdn.microsoft.com/library/en-us/dnanchor/html/anchoraspdotnet.asp?frame=true,
2005.06.10.
http://msdn.microsoft.com/library/en-us/dnanchor/html/netfxanchor.asp?frame=true,
2005,05.08.
http://msdn.microsoft.com/library/en-us/dnanchor/html/WebServicesAnchor.asp?frame=true,
2005.06.14.
[5] Microsoft TechNet
http://technet.microsoft.com/default.aspx,
2005.03.07.
[6] W3C oldalak 2 és 3 fejezethez:
XML: http://www.w3.org/TR/2000/REC-xml-20001006,
2005.06.03.
XSD: http://www.w3.org/TR/xmlschema-2/,
2005.06.04.
SOAP: http://www.w3.org/TR/2000/NOTE-SOAP-20000508/,
2005.06.13.
[7] MS fejlesztői konferencia CD/DVD 2001, 2002, 2004
[8] P2P információk:
http://openp2p.com/,
2005.06.14.
http://www.microsoft.com/downloads/details.aspx?FamilyId=5116A614-A487-4DFF-B384-829CD8CE977D&displaylang=en,
2005.06.10.
http://www.gnucleus.com/, 2005.05.01.
http://gnucleus.sourceforge.net/Gnucleus/, 2005.05.01.