Kiberleti (verzija 2.0)

Simulacije kažejo vnaprej konfigurirano mrežo strežnikov, delovnih postaj (uporabniških računalnikov, notesnikov ipd) in napadalcev. Delovne postaje med seboj komunicirajo s sporočili. Posebnost strežnikov je, da na vsako prejeto sporočilo (zahtevek) pošljejo odgovor (izvedejo storitev, kar ponazorijo s svojim sporočilom) .

Napadalci so tudi računalniki, ki pa le pošiljajo sporočila, ne morejo pa jih prejemati (so omrežju neznani).

Računalniki se lahko okužijo, lahko jih tudi razkužimo in lahko jim dodajamo protivirusno zaščito. Računalnike lahko tudi vklapljamo (privzeto) ali izklapljamo.

Dodajamo lahko nove strežnike, delovne postaje in tudi napadalce. Mrežo lahko (tudi med potekom simulacije) poljubno širimo.

V animacijah je sled sporočil pobarvana modro (privzeto), po koncu sporočila pa ostane še nekaj časa vidna svetlomodro. Zaradi večje nazornosti lahko sledi pobarvamo tudi drugače.Jedro kiberletov je JavaScript Animator.js, vsebuje več razredov. Najbolj pomemben je Animator, ki predstavlja sceno, v katero vnesemo različne komponente, kot so delovne postaje (uporabniški računalniki), strežniki, napadalci ipd. Več o tem kasneje.

Na naši spletni strani imamo vsaj eno instanco razreda Animator, ki predstavlja sceno, pravzaprav kanvas, po katerem rišemo statične slike v ozadju in dinamične, animirane predmete v ospredju. Simulacija teče v diskretnih korakih. in pri tem običajno povečuje števec tStep. Animacija poteka tako, da korakoma povečujemo (ali zmanjšujemo) čas tStep in v vsakem koraku preračunavamo simulirani model in osvežujemo zaslon.

Pri vsakokratnem klicu metode UpdateScene () se izvede zaporedje funkcij:

    updateAnimation1(); // usually static elements before computations in step
    if((running)&&(!doSingleStep))   tStep++;
    updateAnimation2(); // usually computation before visualization
    updateAnimation3(); // scene visualization after computation

Drug pomemben razred je Component, katerega instance so predmeti na simulirani sceni. To so običajno različne računalniške naprave in osebe. Komponente imajo svoje ime in položaj na sceni, predvsem pa imajo dodeljeno podobo (sprite), kot to srečamo v različnih računalniških igrah. Kako je komponenta prikazana, pove njej dodeljena slika, ki jih najdemo v direktoriju "images".

Komponente so dinamični predmeti na sceni, kar pomeni, da njihov položaj določamo z računanjem ali pa z vlečenjem z miško (če to dovolimo).

Vsaki komponenti je torej prirejena ustrezna slika (ikona) in oznaka (opis). Komponente imajo na sceni svoj položaj, ki ga lahko med potekom simulacije tudi spreminjamo. Komponente imajo tudi attribut "isDraggable". Če tega nastavimo na true, lahko tako komponento izberemo s klikom miške in jo tudi premikamo po sceni (morda zaradi boljšega pregleda).

Položaj ikone in oznake vsake komponente lahko prirejamo s parametri shapeDx, shapeDy, nameDx, nameDy, relativno na virtualni položaj komponente na sceni) (kakor ga uporabljamo pri naslavljanju komponente)

Iz razreda Component sta izpeljana razreda Person in Asset, ki ju uporabljamo za tvorbo instanc osebkov in naprav (tipično računalnikov in drugih komponent računalniškega omrežja). Ta dva razreda imata dodatne lastnosti, ki so pač specifične za osebke oziroma za različne računalniške naprave.

Vsaki komponenti izrazreda Asset (torej oprema) pripada še nekaj "računalniških" lastnosti: IP, isInfected, antiVirus, connected, ... .

Ker sceno predstavlja množica osebkov in naprav, so instance teh osebkov oziroma naprav pomnjene v poljih persons oziroma assets. Ti polji uporabljamo v zankah preko vseh osebkov ali vseh naprav.

Sporočila so instance razreda Message. in pomnjena v polju messages. Nastajajo med simulacijo in zaradi vidnosti potekajo (se širijo od izvorne k ciljni komponenti) nekaj časovnih korakov (odvisno od nastavljene hitrosti širjenja, kar določimo s simulacijskim parametrom messageSpeed).

Tudi po dosegu ciljne komponente (ta trenutek pomni obvestilo v spremenljivki timeDelivered) si morda želimo, da še nekaj časa vidimo sled sporočila (od izvorne do ciljne komponente). To nastavljamo s spremenljivko messageTrackDuration. To spremenljivko lahko nastavljamo tudi vsakemu obvestilu posebej.

Instance obvestil lahko tudi verižimo in jih pomnimo v polju nextMsgs. Tako veriženo obvestilo po svojem zaključku sproži naslednje in tako lahko ponazorimo potovanje sporočila po omrežju od ene naprave do druge.

Poenostavljen diagram vseh navedenih razredov ponazoruje spodnja slika.

razredni diagram

V simulacijah uporabljamo tudi druge razrede, na primer dogodke (instance razreda Event). Razred Event se od simulacije do simulacije razlikuje in je torej definiran v vsaki simulaciji posebej.

Simulacija Varnost pisarne

Ta simulacija sicer temelji na prej navedenih razredih oziroma objektih, dodane pa ima še dogodke, ki naj bi predstavljali varnostne incidente. Posamezen dogodek je primerek iz razreda Event. Ta ima kot lastnosti tip dogodka, njegov opis in tarčo (to je lahko žrtev napada).
Dogodke hranimo kot ločeno JSON datoteko z imenom scenario.json, ki jo preberemo v polje events. Zamenjava te JSON datoteke v bistvu smremeni scenarij simulacije.
Med potekom simulacije "korakamo" od dogodka do dogodka.
Vsak dogodek obdelujemo v funkciji processEvent, ki dejansko predstavlja odločitveno drevo. Prva delitev v tem drevesu je narejena v skladu z naborom vseh možnih dogodkov. Naslednje delitve pa predstavljajo nabore možnih akcij ob nastopu posameznega dogodka.

Trenutno imamo v odločitvenem drevesu predvideno obravnavo naslednjih tipov varnostnih dogodkov (vsi niso napadi):

DOS/DDOS, MITM, Phishing, Whale-phishing, Spear-phishing, Snooping, Ransomware, Password, Traffic analysis, TCP/SYN, UDP, ICMP, Data diddling, SQL Injection, URL Interpretation, Cross-site scripting, DNS Spoofing, Session Hijacking, Brute force, Web, HTTP, Insider Threat, Trojan Horse, Keylogger, Drive-by, XSS, Eavesdropping, Birthday, Malware, Salami, Data thief visit, Asset thief visit , New employee, Social Engineering, HW selfrepair, SW selfrepair.

Vsi navedeni tipi dogodkov še niso implementirani !.

Posebnost simulacije varnosti v pisarni je še, da omogoča 3D predstavitev pisarne, ki je realizirana s tehnologijo Babylon.js. 3D predstavitev pisarne omogoča različne poglede(projekcija, fokusirana na osebek, ki ga izberemo s klikom) ali pogled na pisarno s strani te osebe (takoimenovani pogled v prvi osebi). 3D predstavitev pisatne lahko povežemo oziroma sinhroniziramo s samo simulacijo.

Simulacija Modri proti rdečim

Ker je obravnavana simulacija večuporabniška, je bolj kompleksna in za spreminjanje moramo poznati nekaj več programiranja. Na strežnem računalniku teče strežni program, napisan v Javi. Tako simulacija scene kot simulacija članov obeh ekip je pisana v JavaScript, medsebojna komunikacija pa poteka preko WebSockets.

Slika predstavlja nekoliko poenostavljen UML diagram javanskega strežnega programa. Večina logike je v razredu CGCenter. (tu poteka vzpostavitev strežne vtičnice WebSocket, pošiljanje sporočil odjemalcem in razpoznavanje njihovih odgovorov.)

Za vsako tvorjeno sceno odpre program novo instanco razreda Scene in pri prijavi udeležencev odpre v tej sceni instanco iz razreda Participant. Instanca razreda Watchdog sama po sebi nima drugega pomena kot stalno preverjanje, ali so predavatelj (vodja igre) in udeleženci še aktivni. Po določernem času, če so vsi udeleženci izstopili iz svojih spletnih strani, program tako sceno ukine.

Tako predavatelj (vodja scene) kot udeleženci vstopajo preko svojih spletnih strani in pri zagonu take strani se vzpostavi ustrezna vtičnica ( webSocket, povezana s strežnim programom) na njihovi spletni strani.

Spletna stran predavatelja (scena.html) je v bistvu predelan kiberlet o varnosti v pisarni. Odstranjena je 3D vizualizacija, ki bi sicer bila načeloma možna, a bi zaradi potencialno velikega števila avatarjev modre in rdeče ekipe (lahko jih je tudi več 10) postala nepregledna, verjetno tudi bolj počasna. Dodana pa je možnost komunikacije preko WebSockets.

Na spletne strani udeležencev (cg.html) pa lahko gledamo kot na nekakšne daljince, s katerimi upravljamo sceno.
Kot že rečeno, komunikacija poteka preko WebSockets, ki si izmenjujejo sporočila. Ta so nizi naslednje splošne oblike:

ukaz##parameter1## parameter2## ... parametern##

Pri tem je ## ločilo med deli sporočila. Med parametri tipično zasledimo kodo scene (saj jih istočasno lahko poteka več). Spletne strani udeležencev in scene komunicirajo med seboj posredno preko strežnega programa, ki deluje kot nekakšna dispečerska postaja. Za boljše razumevanje si lahko ogledamo primere preprostih spletnih klepetalnic, narejenih s pomočjo WebSockets (glej https://github.com/TooTallNate ).

Ker poteka komunikacija med vtičnicami preko vrat, morajo ta vrata poznati tako javanski strežni program kot odjemalci (scene.html, cg. html). Strežni program prebere ta podatek, iz datoteke cgConfig.xml. Odjemalci pa dobijo ta podatek v datoteki cgConfig.js. V slednji datoteki je tudi navedena lokacija strežnega programa (spremenljivka hostName).
Kiberletzi so predvideni tudi za namestitev po protokolu HTTPS. V tem primeru moramo uporabiti vtičnice tipa WSS (in ne WS). Po katerem protokolu smo namestili kiberlete, je prav tako razvidno iz obeh konfiguracijskih datotek.