Digitalna forenzika kritične infrastrukture

Primož Kragelj Namen prispevka Izvajanje forenzike v kompleksnih okoljih, kot je kritična infrastruktura, je še dokaj nepokrito področje, vsaj z vidika praktičnih izkušenj. V okviru prispevka so identificirani izzivi, ki predstavljajo primerjalno razliko z izvajanjem tradicionalne digitalne forenzike. Zbrani so tudi predlogi, kako se lahko postopkovno izvede forenzične procese v takšnem okolju. Metodologija Prispevek predstavi kritično infrastrukturo in sisteme SCADA ter poda analizo napada na nuklearni obrat s pomočjo virusa Stuxnet. Standardna metodologija izvajanja računalniške forenzike je obravnavana z vidika kritične infrastrukture, študija primera Stuxnet pa ilustrira možne pristope izvajanja digitalne forenzike v tovrstnih okoljih. Ugotovitve Iz prispevka izhaja, da tudi v Sloveniji nismo imuni na napade na kritično infrastrukturo. Dosegljivi so nekateri akademski prispevki, ki opisujejo fizično varovanje in predvideno ukrepanje obrambnih organizacij Republike Slovenije v takšnih situacijah. Ne najdemo pa dosegljivih virov, ki bi konkretno določali postopke vezane na sisteme varovanja računalniške infrastrukture, kot tudi izvajanja digitalne forenzike v okoljih, ki predstavljajo kritično infrastrukturo. Omejitve raziskave Prispevek v osnovi temelji na izkušnjah iz tujine, saj pri nas ne poznamo obravnavanega primera računalniške forenzike v okoljih kritične infrastrukture. Glede na razumljive interese so tudi javno dostopni podatki pomankljivi in o morebitnih scenarijih lahko zgolj ugibamo. Praktična uporabnost Glede na trende uporabe kritične infrastrukture, predvsem integracije s poslovnimi aplikacijami organizacije, se izkaže, da se zagotavljanje varnosti kritične infrastrukture začne že pri razvoju programske opreme in se nikoli ne konča, iz česar izhaja, da je to živa aktivnost in zahteva proaktivno delovanje vseh vključenih v verigi. Ključne besede: forenzika, kritična infrastruktura, stuxnet

1 Uvod

Definicija kritične infrastrukture izhaja iz zakonskih oz. pravnih določb. Osnova je Zelena knjiga Evropske unije (EU), ki za EU navaja 11 sektorjev kritične infrastrukture (KI) (Evropska komisija, 2005). Od teh 11 sektorjev je Slovenija kot kritično infrastrukturo določila le dva, in sicer energetiko in promet (Uradni List RS *UL RS+, 2011). Določanje KI je namreč v vsaki državi nacionalna zadeva, saj gre za omejene razsežnosti, predvsem v smislu morebitne škode oziroma posledic. Zahteve po neprekinjenem in pravilnem delovanju naprav, ki predstavljajo KI, imajo posledice na postopek izvajanja digitalne forenzike. Namen pričujočega prispevka je opisati izzive,

ki ob metodološkem pristopu in trenutni praksi omogočijo celostno izvedbo računalniške preiskave. V prispevku je najprej predstavljeno širše razumevanje kritične infrastrukture, ki zajema osnovno definicijo in pravno podlago za njeno klasifikacijo. Ključno vlogo v kritični infrastrukturi imajo sistemi SCADA (ang. Supervisory Control And Data Acquisition), ki vsebujejo celotno verigo povezanih naprav, in sicer od nadzornega sistema do aktuatorjev. Sistemi SCADA so lahko povezani tudi s poslovnimi aplikacijami. Z ozirom na logične (predvidene) napade na tovrstna okolja bomo za vsako vrsto napada podali javno znan primer. Podrobneje bomo obravnavali primer dodelanega in kompleksnega računalniškega virusa Stuxnet, ki so ga v zadnjem času že večkrat analizirali, kot je na primer opisano v (Langer, 2012). Za takšno prepoznavnost obstaja več tehtnih razlogov. Izstopa predvsem ta, da noben sistem ni varen pred dobro načrtovanimi virusnimi napadi. Napadi imajo lahko hude posledice do katerih lahko pride tudi v skrbno varovanih sistemih, kot je npr. jedrski obrat. Enako pa lahko velja za katerokoli industrijsko, proizvodno ali infrastrukturno okolje. Posledice napada so vidne kot okvara opreme, sprememba delovanja sistema in v najslabšem primeru negativno vplivajo na okolje in človeka. Iz omenjenega izhaja, da je tako razumevanje posledic in proaktivno delovanje v smislu preprečevanja katastrof tudi stvar nacionalnega interesa. V praksi to pomeni, da preprečevanje tovrstnih napadov zahteva povezanost vseh institucij in deležnikov v celotni verigi uporabe sistemov kritične infrastrukture. Prej omenjeni deležniki niso zgolj upravljavci ter uporabniki kritične infrastrukture, ampak tudi organizacije, ki se ukvarjajo z varnostjo programske opreme, ter proizvajalci strojne in programske opreme in tudi računalniške forenzike. Sodelovanje vseh prej omenjenih organizacij ima skupen cilj – varnost KI, ki je v uporabi in vključuje mehanizme, ki bi pripomogli tako k preprečevanju kot tudi k analizi raznih dogodkov, kar tudi z vidika varnosti podrobneje predstavimo. Koncept izvajanja računalniške forenzike na primeru Stuxnet predstavimo ob predpostavki, da smo prisotni na kraju dogodka. Pri nalogi uporabljamo različne vire, ki vključujejo tudi novičarske strani, saj so bili določeni dogodki, ki se navezujejo na kritično infrastrukturo, sporočeni širši javnosti zgolj prek tovrstnih medijev. Zgolj do določenega nivoja pričakujemo tudi javno dostopen opis uporabljene kritične infrastrukture. Kot zanimivost pa se izkaže dejstvo, da je večina javno dosegljivih referenčnih prispevkov, navedenih v nadaljevanju prispevka, povezana z jedrskimi elektrarnami, kar pa po veljavni klasifikaciji v RS niti ne spada v omenjeno infrastrukturo.

2 Kritična infrastruktura

Bistvenega pomena za razumevanje definicije kritične infrastrukture so zakonske določbe (UL RS, 2011), ki navajajo, da »kritična infrastruktura državnega pomena obsega tiste zmogljivosti, ki so ključnega pomena za državo in bi prekinitev njihovega delovanja ali njihovo uničenje pomembno vplivalo oziroma imelo resne posledice na nacionalno varnost, gospodarstvo, temeljne družbene funkcije, zdravje, varnost in zaščito ter družbeno blaginjo, ocenjene po merilih, ki jih določi Vlada Republike Slovenije«. Primeri KI glede na omenjeno definicijo v RS so prikazani v tabeli 1. Večina t.i. kritične infrastrukture je kontrolirana z uporabo sistemov SCADA. Posledice nepravilnega delovanja sistemov SCADA imajo posledice za samo industrijsko infrastrukturo kot tudi za družbeno skupnosti oz. človeška življenja.

Tabela 1: EKI sektorji (UL RS, 2011) Včasih so bili sistemi SCADA izolirani od javnih in drugih omrežij. Zunanji dostop do njih je bil omejen. Dandanes so taka omrežja vedno bolj povezana v širše komercialne sisteme, pogostejša pa je tudi uporaba prenosnih in mobilnih naprav znotraj prej varnega okolja. Pričakovani nivo varnosti se je tako znižal in napadi na take sisteme so postali realnost.

2.1 Predvideni in znani incidenti

Predvidevanje napadov oz. incidentov na kritično infrastrukturo spada v domeno nacionalne varnosti in strategij, kako ravnati v primerih, ko do takšnih napadov pride. Po ugotovljeni definiciji (tabela 1) bi lahko predvidevali napade na vse zgoraj navedene objekte1. Posledice napadov na omenjeno infrastrukturo so lahko različne (Idaho National Laboratory,2008) (US-CERT Control Systems Security Center, 2005):

1) Izguba nadzora nad sistemom 2) Nezmožnost proizvodnje 3) Ogrožena varnost 4) Posledice na okolje 5) Poškodbe ali celo izguba človeških življenj

Primere incidentov, ki imajo za posledico nedelovanje sistemov KI, lahko v grobem razdelimo v dve skupini – namerni in nenamerni, pri čemer je slednji razdeljen v dve podskupini (Nicholson, Webber, Dyer, Patel in Janicke, 2012):

1. Namensko usmerjeni napadi na kritično infrastrukturo, podrobneje opisani v nadeljevanju znotraj poglavja »Možni napadi na SCADA sisteme«

2. Nenamerni napadi kot posledice okužb sistema z zlonamerno kodo 3. Nenamerni napadi, ki so posledice ravnanj povzročenih s strani internega osebja ali

opreme V nadaljevanju so po vrstnem redu predstavljeni primeri zgoraj naštetih skupin. Predstavnik usmerjenih napadov je zagotovo Stuxnet (podrobneje opisan v tem prispevku), drugi referenčni primer pa bi bil napad na kanalizacijo v Avstraliji (Slay in Miller, 2007), kjer je bilo s pošiljanjem

1 Za konkretno analizo bi potrebovali dostop do infrastrukture, kjer bi opravili analizo informacijskega sistema in

KI ter dovoljenje ustrezne institucije za objavo v prispevku.

kontrolnih signalov preko brezžične komunikacije spremenjeno delovanje sistema. Tehnične posledice napada so bile: nedelovanje črpalk, nedelovanje alarmnega sistema in izguba komunikacije med kontrolnim računalnikom in ostalimi komponentami sistema. Posledici aktivnosti napadalca sta bili izlitje 800.000 litrov kanalizacijskih tekočin v lokalne parke in reke ter neznosen smrad. Povzročitelj napada je imel osebne zamere do organizacije. V drugo skupino znanih napadov sodi črv »Zotob« (Roberts, 2005). Glede na javno dostopne informacije je povzročil največ škode v avtomobilski industriji – Daimler Chrysler v USA. Omenjeni črv je povzročil, da so se računalniki ugašali in ponovno zaganjali, omogočal pa tudi dostop do računalnikov, katere bi lahko nekdo uporabil kot del t.i. »botnet-a«. Drugi primer v omenjeni skupini se je zgodil v nuklearni elektrarni Davis-Besse v Ohiu (Poulsen, 2003), kjer je črv prišel v interno omrežje nezaščitenega dela, ki je bil povezan s podizvajalcem omenjene elektrarne. Primer tretje kategorije (nenamerne posledice) je posodabljanje programske opreme v nuklearni elektrarni Hatch (Lumeta Corporation, 2012), kjer sistemski administratorji tekom procesa niso upoštevali vseh dejavnikov posodabljanja. Sistem SCADA je pri posodabljanju ugotovil določene nepravilnosti in posledično ugasnil jedrsko elektrarno. V tem primeru ni bilo nobene nevarnosti za prebivalce, je pa proizvajalec zaradi nedelovanja sistema in časa, potrebnega za vzpostavitev delujočega stanja, utrpel finančne posledice.

3 Opis sistemov SCADA

Koncepti delovanja sistemov SCADA se v glavnem navezujejo na avtomatizacijo delovnih procesov, ki zagotavljajo avtomatsko kontrolo in oddaljeno spremljanje delovnih procesov (National Institute of Standards and Technology [NIST], 2008), med drugim tudi procesov, ki se izvajajo v okviru kritične infrastrukture. Tehnološko gledano so sistemi SCADA tipično sestavljeni iz naslednjih komponent (SANS Institute, 2005) (Kurtz,2006):

1. Senzorji za zaznavanje različnih pogojev (temperatura, pritisk, napetost, pretok,..). 2. Operativna oprema, kot so črpalke, ventili, transformatorske postaje in s pomočjo relejev

kontrolirane naprave. 3. Interni procesorji, ki komunicirajo s senzorji in operativno opremo (povezujejo prej

omenjeni kategoriji naprav). Predstavnik kategorije so razna vezja PLC (programabilni logični kontroler).

4. Komunikacijski kanali med senzorji in operativno opremo kot tudi vezji PLC. Tipično so to žični kabli in brezžične povezave.

5. Kontrolni računalnik za nadzor in upravljanje. Tipično je računalnik v domeni določenega operaterja, ki nadzoruje delovne procese, spremlja obvestila ipd.

6. Komunikacije med kontrolnim računalnikom in internim računalnikom. Tipično gre za večje razdalje, komunikacija pa poteka po najetih linijah, preko satelitov, z uporabo mikrovalov in preko mobilnega omrežja.

Gledano z vidika izvajanja računalniške forenzike na takšnih sistemih je glede na zgornje komponente realno pričakovati uporabne (relevantne) podatke na točkah 3-6, čeprav se dejanske aktivnosti, ki vplivajo na ravnanje celotnega industrijsko kontroliranega okolja, izvaja v točkah 1-2. Tudi v zelo dobrem forenzičnem laboratoriju, ki bi vseboval tako strojne kot tudi programske komponente2, bi lahko reproducirali zgolj del aktivnosti, ki jih spremenjen (okužen) program izvaja. Primer tipičnega sistema SCADA je grafično prikazan na sliki 1.

2 Načeloma bi potrebovali simulator dejanskega okolja

Slika 1: Sistem SCADA, (US-CERT Control Systems Security Center, 2005) Iz slike 1 je razvidno, da se sistem SCADA povezuje v poslovno omrežje tipično za namen izvajanja ostalih poslovnih procesov (npr. spremljanje porabe in zaračunavanje končnim porabnikom glede na porabo). Sistemi SCADA so zaradi dolgotrajnega in dragega postopka zamenjave v uporabi od 8 do 15 let (Idaho National Engineering and Environmental Laboratory, 2004). Iz analize, ki je bila opravljena leta 2004 in je prikazana na sliki 2, lahko vidimo, da je že takrat bilo večina tovrstne opreme izdelano na operacijskem sistemu Windows, sledijo mu UNIX, VMS in Linux ter na zadnjem mestu nekaj nestandardnih platform in operacijskih sistemov. Omenjeni rezultati so prikaz pregleda ponudbe 14 največjih proizvajalcev v omenjenem obdobju. Nekateri od proizvajalcev ponujajo svoje rešitve na več platformah, zaradi česar seštevek vrednosti na spodnjem grafu presega 100 %.

Slika 2: Izbira operacijskih sistemov (Idaho National Engineering and Environmental Laboratory, 2004) Glede na kompleksnost, prepletenost ter dolgo pričakovano življenjsko dobo sistemov SCADA lahko sklepamo, da je zaradi enostavnejše nadgradnje in kompatibilnosti z obstoječim okoljem menjava proizvajalca zelo redka. Posledično se tudi struktura ponudbe, razvidna na sliki 2, najverjetneje ni veliko spremenila. Dopuščamo pa možnost spremembe porazdelitve zaradi objektov, kjer vsi procesi niso bili informatizirani. V takih primerih so bili kasneje dodani sistemi SCADA na posamezne sklope, primer je posodobitev stikališča NEK s strani podjetja ELES (Ministrstvo za okolje in prostor, 2004). 3.1 Možni napadi na SCADA sisteme

Glede na sam razvoj sistemov SCADA, ki so se iz nekdaj zaprtih sistemov razvili v sisteme, ki se povezujejo preko Interneta in uporabljajo standardno strojno in programsko opremo, se je tveganje z vidika varnosti zelo povečalo. Glede na tip napadalca so namerni napadi na kritično infrastrukturo razdeljeni v naslednje kategorije (SANS Institute, 2005):

1.) Škodljiva koda (ang. Malware) 2.) Insajder – nezadovoljni zaposleni v organizaciji. 3.) Heker – posameznik, ki je motiviran, da pridobi nadzor nad določeno kritično

infrastrukturo. V tem primeru motivacijo predstavlja izziv. 4.) Terorist – gre za kategorijo, ki ločuje KI od ostalih sistemov IT.

Vse omenjene kategorije je potrebno pri obravnavanju preiskav, ki se navezujejo na industrijska okolja, upoštevati že v začetni fazi. Z vidika izvajanja računalniške forenzike nas prvotno zanimajo dokazi v digitalni obliki in se ne posvečamo ostalim dokazom oz. posledicam nepravilnega delovanja SCADA sistemov. V začetni fazi izvajanja so to koraki, povezani z zavarovanjem podatkov oz. izdelavo identičnih kopij. Podroben potek je razviden iz standardne metodologije, kjer je celotna forenzična preiskava razdeljena na štiri faze (Departement of Justice [DoJ],2007):

1) Priprava, ki vsebuje tako zavarovanje podatkov, kot tudi identifikacijo, kje se podatki nahajajo.

2) Identifikacija za preiskavo relevantnih datotek, kjer se pregledajo zavarovani podatki in se izvozijo za nadaljnje delo.

3) Analiza, ki vključuje pregled izvoženih podatkov. 4) Poročilo, kjer so opisani postopki, procesi in ugotovitve. Namen tega področja je tudi

razlaga digitalnih dejstev netehničnemu osebju.

V primeru, ko ne moremo pojasniti obnašanja določenega dela sistema tekom forenzične preiskave, je zelo koristno, če lahko njegovo obnašanje simuliramo v testnem okolju.

4 Stuxnet kot študijski primer

Referenčni primer ranljivosti sistemov SCADA je zelo odmeven virus Stuxnet. Omenjeni virus je zanimiv iz več vidikov, kot so dolgotrajnost delovanja, potreben čas za dosego in odkritje dejanskega cilja napada in tehnološka kompleksnost ter dovršenost virusa. Iz spodnje tabele je razvidno, da je bil omenjeni virus zaznan novembra 2008, njegov cilj pa je bil dosežen julija 2010, iz česar izhaja, da se je širil dve leti preden je bil njegov cilj dosežen in posledično ugotovljen. Zanimivo pa je tudi to, da so bili varnostni popravki za ranljivosti, ki jih je uporabljal virus, izdani zelo pozno. Tabela 2: Stuxnet časovnica (Symantec Corporation, 2010)

Datum dogodka Dogodek

20. november 2008 Identificiran trojanski konj Trojan.Zlob, ki izkorišča ranljivost v bližnjicah (LNK datoteke). Kasneje identificiran kot Stuxnet.

April 2009

Revija Hakin9 je objavila podrobnosti o ranljivosti, povezani z izvrševanjem oddaljene kode v storitvi, povezani s printerjem. Kasneje je ranljivost identificirana pod oznako MS10-061.

Junij 2009 Najden zgodnejši primer Stuxneta. Ne izkorišča ranljivosti MS10-046. Ne vsebuje podpisanih gonilnikov.

25. januar 2010

Stuxnet z gonilnikom, katerega podpis je mogoče preveriti z veljavnim certifikatom, ki pripada podjetju Realtek Semiconductor.

Marec 2010 Prva verzija Stuxneta, ki izkorišča ranljivost MS10-046.

17. junij 2010

Virusblokada poroča o W32.Stuxnetu (poimenovan kot RootkitTmphider). Poročajo o ranljivosti v bližnjicah (lnk datoteke) za širjenje okužbe (kasneje identificiran kot MS10-046)

13. julij 2010 Symantec je dodal virusno definicijo kot W32.Temphid

16. julij 2010

Microsoft je izdal poročilo št. 2286198, ki pokriva ranljivost pri izvrševanju bližnjic (lnk datotek). Verisign je preklical certifikat podjetja Realtek Semiconductor.

17. julij 2010 Eset je identificiral nov Stuxnetov gonilnik, katerega podpis je mogoče preveriti s certifikatom podjetja Jmicron Technology

19. julij 2010

Siemens poroča, da preučujejo zlonamerno kodo, ki vpliva na Siemensove WinCC SCADA sisteme. Symantec je preimenoval virus v W32.Stuxnet

20. julij 2010 Symantec spremlja komunikacijo, ki jo povzroča Stuxnet

22. julij 2010 Verisign je preklical certifikat Jmicron Technology.

2. avgust 2010 Microsoft je izdal popravek MS10-064 za ranljivost povezano z bližnjicami.

6. avgust 2010 Symantec poroča, kako Stuxnet okuži PLC in vpliva na industrijske kontrolne sisteme.

14. september 2010

Microsoft je izdal popravek za MS10-061 ter še dva druga popravka za ranljivosti, identificirane v enakem obdobju s strani podjetja Symantec.

30. september 2010 Symantec je predstavil obširno poročilo o virusu Stuxnet.

Iz razpoložljivih analiz (ESET, 2010) (Symantec Corporation, 2010) (Langer, 2012), del katerih je tudi zgoraj prikazana časovnica, je razvidno, da je bil dejanski cilj napada usmerjen na določene naprave. Lokacija naprav pa ni nujno, da je unikatna zgolj za Natanz, kjer je bil virus odkrit. Kljub velikemu številu okuženih računalnikov v podanem obdobju, na večini računalnikov niso bile ugotovljene druge zlonamerne aktivnosti kot posledica okužbe. Natanz je obrat v Iraku namenjen bogatenju urana. Obsega 100.000 kvadratnih metrov površine in je zgrajen 8 metrov pod zemljo. Iz poročila (Institute for Science and International Security 2009), je razvidno, da skupna kapaciteta znaša 7052 centrifug (naprav), kar z vidika Irana bistveno pripomore k hitrejši izdelavi urana za jedrsko orožje. Natanz je bil domnevna tarča usmerjenega napada Stuxnet.

4.1 Kako je virus okužil sistem ter se širil in posodabljal

Obstajata dva načina širjenja virusa Stuxnet: prek mreže in prek ključev USB (Symantec Corporation, 2010). Širjenje prek ključev USB izhaja iz domneve, da nekateri (večina) sistemi SCADA nimajo dostopa do interneta in da se na takih napravah večina datotek izmenjuje s pomočjo ključev USB. Ugotovitve kažejo, da je to osnovna metoda za širjenje virusa. Dodatno ima virus implementiran tudi mehanizem posodabljanja (Symantec Corporation, 2010) preko interneta. Po okužbi enega računalnika se Stuxnet širi na vse ostale dosegljive (in ranljive) računalnike v mreži. Na okuženem računalniku virus preveri, ali je na njem nameščena programska oprema proizvajalca Siemens ter prisotnost vezij PLC. Če ugotovi prisotnost vezij PLC, virus preveri vrsto vezij, njihovo konfiguracijo in nabor priključenih fizičnih komponent. V primeru, da konfiguracija ustreza njegovemu dejanskemu cilju, v PLC pošlje svojo kodo in ga posledično reprogramira. Virus je za svoje širjenje preko ključev USB uporabljal dva načina (odvisno od verzije Stuxneta):

ranljivost, ki omogoča avtomatski zagon pri pregledovanju vsebine

z zagonom vsebin preko datoteke autorun.inf

Obe ranljivosti sta bili popravljeni s strani Microsofta, s čimer so posledično onemogočili širjenje virusa (in morebitnih naslednjih virusov). Tekom celotne analize zlonamerne kode, ki so jo opravili pri Symantecu, se je izkazalo, da je virus zlorabil štiri različne ranljivosti tipa ničelnega dne (ang. »0-day«):

t.i. »bližnjica« (ang. Windows Shortucut), namenjena zagonu programa na okuženem računalniku

storitev tiskanja (ang. Print Spooler Service), namenjena zagonu programa na oddaljenem računalniku

dve ranljivosti, povezani s pridobitvijo nadzora nad sistemom (odkriti interno v Microsoftu in glede na objave tudi popravljeni)

Poleg izkoriščanja ranljivosti operacijskega sistema velja izpostaviti tudi nepojasnjen način pridobitve dveh digitalnih certifikatov (od podjetja RealTek Semiconductor in JMicron Technology), namenjenih preverjanju digitalnega podpisa gonilnikov v okviru operacijskega sistema, ki sta bila namenjena zakrivanju oz. predstavljanju lažne identitete v okviru operacijskega sistema. Glede na usmerjenost napada s pomočjo virusa Stuxnet lahko predvidevamo, da bi napadalec razvil virus tudi za drugo vrsto operacijskega sistema, če bi ga uporabljal ciljni sistem SCADA.

4.2 Aktivnosti na osebnem računalniku in PLC

Pri sedanji analizi Stuxneta se zavedamo končnega cilja virusa, kar je okužba specifičnega tipa PLC naprav. Poleg samih funkcij za širjenje je omenjeni virus vseboval tudi kodo za originalni Simaticov PLC kontroler, ki je spremenila komunikacijsko rutino kontrolerja. Način delovanja po okužbi oz. vstavljanju spremenjene kode na PLC je, da se dejansko vse izvaja na PLC in računalnik (PC) ni več potreben za njegovo izvajanje (virusa). Tehnično gledano, ko je ugotovljeno, da je na računalnik priključen pravi tip naprave, virus na sistemu zamenja knjižnico DLL in okuži PLC. Koncept delovanja oz. povezovanja je razviden na spodnji sliki.

Slika 3: Komunikacije med PCjem in PLCjem (Symantec Corporation, 2010) Nadzorno-upravljalska aplikacija WinCC je namenjena vizualizaciji stanja procesov, trenutnih vrednosti spremenljivk in prikazu napak znotraj sistema. Poleg kontrole industrijskega okolja omogoča tudi upravljanje s proizvodnimi procesi. Naslednja slika grafično prikazuje spremenjeno komunikacijsko rutino, ki jo pri svojem delovanju paketno uporablja celoten sistem WinCC v povezavi z orodjem Step 7 in vezjem PLC kot zadnjo programabilno komponento v verigi.

Slika 4: Spremenjena komunikacijska rutina (Symantec Corporation, 2010)

Po okužbi z virusom Stuxnet se originalna datoteka s7otbxdx.dll preimenuje v datoteko s7otbxsx.dll in originalno datoteko zamenja z lastno verzijo. S tem Stuxnet pridobi nadzor nad PLC in lahko prestreže katerikoli dostop do PLC vezja. Leva stran slike prikazuje normalno delovanje sistema, pri katerem Siemensov program uporablja različne funkcionalnosti, shranjene v knjižnici s7otbxdx.dll, za dejansko komunikacijo s PLC. Konkretno je razvidna uporaba funkcije s7blk_read, ki je poklicana s strani aplikacije WinCC/Step 7 in ima direkten dostop do PLC. Desna polovica slike pa prikazuje obnašanje sistema z zamenjanim DLL, kjer pa se z uporabo enake funkcije prikaže spremenjeno vrednost v aplikaciji WinCC.

5 Forenzična preiskava

Preiskava elektronskih naprav se kot panoga razvija že dalj časa. V tem obdobju so nastale različne metodologije, ki se razlikujejo glede na področje delovanja avtorjev. Široko gledano se faze metodologije med seboj prepletajo in ni nujno, da predstavljajo v vseh primerih zgolj linearni postopek. Glede na obravnavani primer Stuxnet in uporabo metodološkega pristopa (DoJ, 2007) bomo v nadaljevanju prispevka predstavili izvajanje celotne forenzične preiskave ob upoštevanju metodologije, ki zajema zavarovanje podatkov, forenzično preiskavo, analizo ter dokumentiranje ugotovitev. Prvi in hkrati najbolj pomemben del je priprava podatkov za nadaljnjo obdelavo ob upoštevanju forenzičnih načel. Ta del vključuje t.i. identifikacijo, kje vse se lahko nahajajo za celotno preiskavo relevantni podatki, in v nadaljevanju zavarovanje teh podatkov. Del te identifikacije zajema tudi splošno pripravo, ki v primeru kritične infrastrukture pomeni upoštevanje vseh možnih napadov na sisteme SCADA, navedenih zgoraj v poglavju »Opis sistemov SCADA«. Iz omenjenih točk izhaja, da je potrebno upoštevati vse scenarije, po katerih bi lahko bil določen stroj namenoma napačno krmiljen, kar vključuje tako človeški faktor kot tudi računalniški virus, ki je v primeru Stuxnet spremenil krmiljenje in delovanja končnega stroja. Po opravljeni identifikaciji in upoštevanju teoretičnega izhodišča (oz. idealnem primeru), da smo prisotni na kraju, kjer je (bil) virus Stuxnet aktiven, in ker v danem trenutku ne poznamo konceptov širjenja virusa kot tudi ne vseh podrobnosti celotnega sistema SCADA, bi glede na predhodno identifikacijo ugotovili, da je za forenzično preiskavo pomemben računalnik, na katerem je nameščena nadzorna aplikacija (WinCC), kot tudi z njim povezan sistem PLC, ki skrbi za končno krmiljenje strojev. Ustvarili bi istovetno kopijo trdega diska na računalniku, kjer je nameščena Siemensova WinCC programska oprema, namenjena krmiljenju sistemov SCADA, torej nadzorni računalnik (oz. vseh nadzornih računalnikov, če bi jih bilo več). Izziv pa bi predstavljalo zavarovanje podatkov na vezju PLC. Pri namenskih mikrokontrolerjih, vključno z vsemi zunanjimi napravami, je dokaj zahtevno ugotoviti, kaj se zgodi ob izklopu takšne naprave (npr. izguba aktivnega programa ali trenutnih podatkov v pomnilniku na vezju). V praksi poznamo zavarovanje podatkov na t.i. živih sistemih in izdelavo identičnih kopij nosilcev podatkov. V primeru izvedljivosti zavarovanja podatka na živem sistemu bi le tega tudi izvedli. Po vsej verjetnosti bi izvedli tudi zavarovanje podatkov z vseh dosegljivih elektronskih naprav, ki imajo neko pomnilniško kapaciteto, npr. ključ USB. Nadaljevanje preiskave bi izvedli v laboratoriju, kjer bi z različnimi forenzičnimi tehnikami (izločanje na podlagi zgoščenih vrednosti, seznamom aktivnih procesov, primerjave z originalnimi datotekami,...) ugotavljali oz. identificirali datoteke, ki so pomembne za nadaljnjo analizo. Identificirane datoteke iz vseh pregledovanih elektronskih naprav bi izločili in pripravili za nadaljnji postopek. Glede ne to, da gre za datoteke z zlonamerno kodo, bi skrbeli za varnost s ciljem preprečevanja nadaljnjega širjenja virusa.

Po opravljeni identifikaciji sledi analiza, ki vključuje pregled aktivnosti izločenih datotek (po vsej verjetnosti se ti dve fazi lahko rahlo prepletata, ker se lahko kakšna manjkajoča datoteka naknadno ugotovi). V okviru analize poskušamo ugotoviti, kako so omenjene datoteke prišle v sistem in tudi kaj dejansko počnejo v sistemu. Analiza med drugim vključuje zaganjanje datotek v varnem okolju, razhroščevanje datotek, preverjanje vzpostavljanja internetnih povezav in spremembe, ki jih posamezen proces naredi v operacijskem sistemu. Pri analizi aktivnosti, ki jih izvajajo procesi, pa upoštevamo tudi anti-forenzične pristope, saj pod določenimi pogoji virus izbriše sledi. Takšen primer je izbris datotek na okuženem ključu USB, enkrat ko so te datoteke prenešene na elektronsko napravo - strežnik. Omenjeni virus ima implementiranih več mehanizmov zavajanja preiskovalca, npr. preverjanje internetne povezave na legalne (logične naslove) naslove- Windows Update. Langer v svojem prispevku (Langer, 2012) zelo poglobljeno prikaže, kako so z uporabo različnih programskih pripomočkov, namenjenih t.i. reverznemu inženiringu, prišli do psevdo kode, in jo glede na javno dostopne podatke o konkretnem industrijskem okolju povezali v smiselno celoto. Iz ugotovljenega lahko povzamemo, da je za preiskovalca zelo pomembno poznavanje celotnega okolja – v konkretnem primeru tako postopkov bogatenja urana kot celotnega sestava obrata. Del analize je tudi reproduciranje aktivnosti virusa oz. zlonamerne kode. To pomeni, da bi morali razpolagati z enakim ali simuliranim okoljem in v njem ponovili postopek okužbe informacijskega sistema kot tudi posledic, ki jih omenjena okužba povzorči. Analiza bi pokazala tudi povezovanje na kontrolne strežnike s katerimi je Stuxnet po okužbi komuniciral (University of California, 2009), in sicer gre za dva strežnika:

• www.premierfutbol.com • www.todaysfutbol.com

Glede na številčnost okužb in aktivnosti virusa so imeli v konkretnem primeru dovolj časa, da so (Symantec) s spremembo DNS zapisov pakete, ki so prihajali na originalna strežnika, preusmerili na svoj strežnik in spremljali mrežni promet. V idealnem primeru (da bi se na kraju samem opravil pripravljalni postopek s pomočjo namenskega programa za spremljanje mrežnega prometa) bi lahko prej omenjeno povezovanje ugotovili že na kraju samem. Gre sicer za netipičen postopek, za katerega je tudi vprašljiva zakonitost (spremljanje mrežnega prometa se pravno razume kot prisluškovanje). Z vidika forenzične metodologije širitev preiskave na druge informacijske sisteme pomeni ločen postopek oz. ponovitev vseh korakov forenzične metodologije na dotičnem sistemu, enkrat, ko se fizično locira dotični strežnik. Vsebinsko se ti informacijski sistemi navezujejo drug na drugega, vendar gre za popolnoma drugi sistem, kjer potrebujemo ustrezno pravno podlago. V dejanskem primeru pojava virusa Stuxnet v obratu, namenjen bogatenju urana, ki se nahaja v Iraku, je bilo nemogoče izvesti procese po omenjenih korakih. Računalniški strokovnjaki, zaposleni v podjetjih, ki se ukvarjajo z izdelavo protivirusne zaščite, so razpolagali z določenimi segmenti virusa (datoteke, ki so vsebovale kodo tako za širjenje, posodabljanje kot tudi krmiljenje mikrokontrolerjev), na podlagi katerih so izvajali t.i. reverzni inženiring in ugotavljali, kaj koda počne (ESET, 2010) (Symantec Corporation, 2010) (Langer, 2012). Glede na večjo količino obravnavanih podatkov so tekom analize ugotovili, da se je Stuxnet čez čas tudi spreminjal oz. uporabljal štiri do sedaj znane načine okužbe na ciljnem računalniku, kar pomeni, da so ga še naprej razvijali in je bil kot projekt zelo aktiven. Podrobnosti so razvidne v spodnji tabeli, razvidno pa je, da prva različica iz leta 2009 ni uporabljala certifikata za preverjanje podpisa gonilnika, ostale različica pa so uporabljale ali Realtekov oz. Jmicronov certifikat. Poleg več uporabljenih različic so pri analizu ugotovili povezljivost (oz. obstaja velika verjetnost) s trojanskim konjem »Duku« in razvojno platformo poimenovali »Tilded«. Povezljivost je bila ugotovljena glede na podobnosti v kodi, avtor prispevka (Kaspersky Lab ZAO, 2011) pa je omenil, da se platforma še razvija, da imamo do sedaj dva predstavnika omenjene platforme (Stuxnet in Duku) ter da so lahko zunaj še ostali programi z zlonamerno kodo.

Tabela 3: Verzije Stuxneta (Kaspersky Lab ZAO, 2011)

Ime datoteke

Velikost (bajti)

Datum nastanka Kje in kdaj je bil uporabljen

Digitalni podpis in datum

Mrxcls.sys 19840 1. 1. 2009 Stuxnet (22. 6. 2009) Ne

Mrxcls.sys 26616 1. 1. 2009 Stuxnet (1. 3. 2010/14. 4. 2010) Realtek, 25. 1. 2010

Mrxnet.sys 17400 25. 1. 2010 Stuxnet (1. 3. 2010/14. 4. 2010) Realtek, 25. 1. 2010

Jmidebs.sys 25552 14. 7. 2010 Verjetno Stuxnet Jmicron, nepoznan

Zadnji korak z vidika metodologije vsebuje pripravo pisnega dokumenta. Omenjeni dokument je primarno namenjen predstavitvi odgovorov, ki so povod za samo sprožitev forenzičnega postopka, in služi kazenskemu postopku. Dokument navaja zgolj ugotovljena dejstva in služi za razlago oz. interpretacijo digitalnih dokazov laičnemu občinstvu. Če povezamemo zadnje ugotovitve, bi z vidika digitalne forenzike ugotovili, da je bil računalnik okužen z zlonamerno kodo, z ugotovljenim časom okužbe bi lahko povezali čas priklopa ključa USB na računalnik, s simulacijo pa pokazali posledice, ki jih povzroči virus v celotnem obratu. Kazenski postopek je vedno uveden zoper eno ali več oseb, katero se povezuje z dogodki oz. posamezno aktivnostjo, kar za preiskovalce pomeni, da bi glede na ugotovitve in z izvajanjem ostalih opravil (npr. razgovori) lahko identificirali osebo, ki je npr. vstavila ključ USB v računalnik.

6 Koncepti zaščite v sistemih kritične infrastrukture

Interes zavarovanja kritične infrastrukture se razteza od nacionalnih inštitucij do vsake posamezne organizacije, ki za svoje delovanje uporablja kritično infrastrukturo. Zaradi različnih interesov so podjetja pridobila certifikate za splošne standarde ISO, ki se ukvarjajo z varnostjo (ISO 27002), dočim pa so v raznih industrijskih panogah v okviru združenj razvili lastne standarde, kot na primer v ameriških podjetjih American Gas Association (AGA), American Petroleum Institute in North American Electricity Reliability Council (NERC). Standardi so stopili v veljavo leta 2009 in vsi ponudniki morajo izkazati skladnost z omenjenimi standardi (Nicholson, Webber, Dyer, Patel in Janicke, 2012). Poleg omenjenih so varnost industrijskih kontrolnih sistemov (ang. Industrial Control Systems - ICS) temeljito obdelali v National Institute for Standards and Technology (NIST) ter v Institute of Electronics and Electronics Engineers (IEEE). Če povzamemo vse ugotovitve, lahko priporočila, standarde in zakonodajo strnemo v naslednje kategorije, ki zajemajo tako varnost kot tudi preventivo:

1. Varnost kritične infrastrukture z vidika nacionalnega interesa, kjer zakonodajalec poskrbi, da so sprejeti ustrezni akti, ki zagotavljajo zahtevano stopnjo varnosti kot tudi aktivnosti v primeru, da pride zaradi kateregakoli razloga do nedelovanja ali napačnega delovanja elementov KI.

2. Varnost elementov KI za obdobje razvoja3, kar pomeni, da je programska oprema ustrezno razvita in testirana.

3 V primeru Stuxnet bi lahko upoštevali dobro prakso razvoja programske opreme, ki med drugim pravi, da

parametri niso permanentno napisani v programski kodi. Sistematično gledano bi lahko upoštevali tudi ostale

ugotovitve in posledično pripravili bolj robusten sistem – npr. onemogočili spreminjanje datotek na strežnikih ali

spremembo kode v čipu PLC.

3. Varnost elementov KI za obdobje delovanja, ki vključuje tako procese povezane s posodabljanjem operacijskih sistemov kot tudi dopolnjene procese varnosti KI glede na novo odkrite ranljivosti ter planirane varnostne preglede

Del varnostnih politik pokriva analizo tveganja, ki se ukvarja predvsem z verjetnostjo in posledicami napada na KI in načini zmanjševanja tveganj glede na njihovo identifikacijo (Ralstona, Graham in Hieb, 2007). Skrb za varnost KI je deloma razvidna tudi iz težko dostopnih javnih podatkov in podjetij, ki skrbijo za tovrstno infrastrukturo ter med drugim izvajajo varnostne preglede sistemov SCADA. Po drugi strani pa je tudi razumljivo, da ni v interesu vsakega podjetja, da javno oznanja napade na njihovo infrastrukturo, s čimer je tudi omejeno število znanih napadov na tovrstno infrastrukturo. Vsi navedeni ukrepi pripomorejo k varni KI, ki bi jo lahko preprosto definirali kot okolje v katerega s uporabo računalniške tehnologije ni mogoče vdreti.

7 Izzivi z vidika računalniške forenzike

Izvajanje računalniške forenzike v okoljih kritične infrastrukture ima poleg tehnoloških izzivov tudi izzive, povezane z omogočanjem oz. onemogočanjem delovanja sistemov. Glede na naravo naprav so ti izzivi predvsem povezani s časom izvajanja (nujnih) aktivnosti, ki so potrebni za ugotavljanje oz. identifikacijo relevantnih podatkov za izvajanje računalniške forenzike. Na časovnici bi to primerjalno videli, da vzdrževalci na neki infrastrukturi odpravijo napako v relativno hitrem času (npr. nekaj minutah), zaradi forenzičnih postopkov pa bi se omejeno nedelovanje sistema lahko zavleklo v ure. Kot primer bi navedel, da bi bilo mesto Ljubljana lahko brez vode nekaj ur, ker bi I.) ugotavljali, kako pravilno zavarovati podatke na kritični infrastrukturi, ter II.) izvedli sam postopek zavarovanja podatkov. Za določene sisteme se za zagotavljanje varnosti predvideva redundanca, kar pa seveda ni nujno v vseh primerih. Iz omenjenega izhaja, da izvajanje računalniške forenzike živih sistemov niti ni možno. Enako velja tudi za primer Stuxnet, kjer se na dejanskih strojih, namenjenih bogatenju urana, računalniška forenzika oz. posamezne aktivnosti niso izvajale, ampak so jih podjetja, npr. Symantec, izvajala v lastnih laboratorijih4. Vemo pa tudi, da je v računalništvu lahko zelo enostavno prirediti neko aktivnost oz. nenamernost in jo narediti težko izsledljivo5. V konkretnem primeru (država Iran in obrat za bogatenje urana v Natanzu) so inšpektorji IAEA (International Atomic Energy Agency) gledali, kako množično menjajo centrifuge, namenjene bogatenju urana. Iranski pristojni organi jim niso razkrili, zakaj to počnejo (Zetter, 2011), saj po vsej verjetnosti niti sami v tistem trenutku niso vedeli, kaj je narobe. Vedeli pa so, da pa se proizvodnja ne izvaja po načrtih. Eden od izzivov predstavlja razpoložljivost dnevniških datotek t.i. »logov«. Posamezne naprave, ki delujejo v celotni verigi neke industrijske infrastrukture niti nimajo pomnilniških kapacitet, da bi hranili dnevniške datoteke, po vsej verjetnosti pa jih tudi težko prenesemo v forenzični laboratorij. Če pogledamo širše, si tudi težko predstavljamo laboratorij, kjer bi imeli pri roki opremo za vse možne industrijske sisteme. Iz omenjenega izhaja, da so potrebni strokovnjaki (proizvajalec, vzdrževalec opreme), ki s svojo tehnično pomočjo in poznavanjem delovanja sistema pomagajo računalniškim forenzikom pri analizi delovanja neke zlonamerne kode v industrijski infrastrukturi. Za primerjavo, glede na število razpoložljivih naprav, si lahko pogledamo forenziko mobilnih telefonov, kjer je v uporabi tudi ogromno število naprav, vendar so prej ali slej vse podprte za

4 V dotičnem primeru je potrebno razumeti tudi politično okolje in čas pojava virusa, zaradi česar se je

računalniška forenzika izvajala drugje. 5 Npr. pri Stuxnetu bi lahko nekdo od zaposlenih vstavil namerno ključ USB v računalnik znotraj omrežja. Aprila

2011 so aretirali nekoga, ki naj bi s ključem USB prinesel Stuxnet v Natanz (Sale, 2012).

pridobivanje podatkov na fizičnem ali na logičnem nivoju. Pri mobilnih napravah je to izvedljivo iz preprostega razloga, ker je povezljivost med mobilnim telefonom in forenzično napravo, namenjeno zavarovanju podatkov, implementirana na način, ki uporablja standardne protokole (USB, Bluetooth). Primerov pri mobilnih napravah, kjer se naprava za zavarovanje podatkov priključi na serijske pine mobilne naprave, skoraj ni iz preprostega razloga, ker so podrobnosti pinov in komunikacijskega protokola poznane zgolj proizvajalcem omenjenih naprav. Priklop na serijske pine najdemo pri nekaterih starejših tipih telefonov. Iz ugotovljenega izhaja, da je potrebno za izvajanje računalniške forenzike v okoljih KI upoštevati morebitne posledice, ki lahko nastanejo zaradi dalj časa onemogočenega delovanja sistema. Tipično se računalniška forenzika izvaja, ko se je dogodek že zgodil in bi glede na pomembnost lahko bila ta infrastruktura bolj pripravljena za morebitne forenzične preiskave. Glede na trende, da so tudi sistemi SCADA podvrženi napadom preko interneta, je po vsej verjetnosti samo vprašanje časa, kdaj se bo digitalna forenzika ustrezno pripravila za obravnavanje tovrstnih primerov. Dober zgled v pravo smer predstavljalo priporočila dobre prakse izvajanja računalniške forenzike v sistemih KI, ki jih je predstavil Mark Fabro (Idaho National Laboratory, 2008). Obravnaval je forenzične izzive v takih sistemih, forenzično predpripravo sistemov ter zagon in vzdrževanje forenzičnega programa. V okviru forenzične predpriprave je izpostavil naslednje faze:

1) Identifikacija sistemskega okolja in specifik sistema 2) Definicija zahtev za specifično okolje 3) Ustvarjanje delovnih pogojev za identifikacijo, zavarovanje in ohranitev digitalnih dokazov

ter digitalnih sledi Zgoraj navedeni koraki se ujemajo s forenzično metodologijo in podrobneje specificirajo potrebne korake v prvi, najpomembnejši fazi, kjer se spoznava okolje in tudi zavaruje podatke za namen forenzične preiskave. Vemo, da računalniška forenzika ni zgolj tehnično pogojena, ampak so potrebni tako predpisi na nacionalnem nivoju kot tudi strokovno usposobljeno osebje za obravnavanje incidentov v tovrstnem okolju. Če povzamemo, bi izzive, ki jih prinaša bolj zahtevno okolje, kot je KI, lahko razdelili v dve skupini:

1) Organizacijski izzivi 2) Tehnični izzivi

Med organizacijske izzive lahko štejemo naslednje:

1) Kompetence osebja in tehnične sposobnosti reprodukcije dotičnega okolja 2) Zagotovitev izvajanja osnovnih aktivnosti na kraju dogodka za potrebe računalniške

forenzike 3) Prenos ugotovljenih dejstev do proizvajalca programske opreme

Kot tehnične izzive pa lahko navedemo naslednje:

1) Zavarovanje podatkov v širšem smislu oz. z upoštevanjem metodologije 2) Reproduciranje dogodka, vključno z analizo 3) Predstavitev ugotovitev (npr. poročilo) ali predstavitev na sodišču ali pred drugim

organom kot dokaz v elektronski obliki Potrebno je tudi razumeti namen računalniške forenzike, saj se vse postopke izvede z namenom ugotavljanja kazenske odgovornosti in je z vidika izvajalca potrebno razumevanje poznavanje celotnega sistema in posledično tudi razlage dogodkov, ki so privedli do neželenega obnašanja sistema.

8 Zaključek

S prispevkom smo povzeli osnovne definicije oz. pogoje, kdaj govorimo o kritični infrastrukturi. Že iz definicije izhaja, da gre za infrastrukturo, ki je povezana z nacionalno varnostjo. Posledično bi lahko navedli, da gre tudi za nacionalni interes, da je omenjena infrastruktura varna. V primeru, ko pride do morebitnega napada, mora omogočati forenzičnim preiskovalcem zadovoljive sledi (v primerjavi s tradicionalno forenziko) za ugotavljanje aktivnosti, ki so privedle do nepravilnega obnašanja nekega sistema. Iz ugotovitev preiskovalcev virusa Stuxnet izhaja, da so tisti, ki so ga razvili, zelo dobro poznali ciljno okolje, in sicer tako obrat za bogatenje urana kot tudi procese bogatenja urana ter so bili hkrati tehnološko sposobni razviti program, ki je izkoriščal ranljivost »napad ničelnega dne« operacijskega sistema, ponaredil digitalne podpise, hkrati skril v kontrolirano industrijsko okolje ter spremenil delovanje industrijskega okolja in tudi operaterjem prikazoval drugačne podatke na računalniških monitorjih. Iz navedenega lahko sklepamo, da gre za sodelovanje zelo strokovne skupine, ki je bila sestavljena iz osebja, ki je imelo zelo dobro računalniško znanje in poznavanje procesov povezanih z jedrsko tehnologijo. Aprila 2011 so aretirali dvojnega agenta, ki naj bi v omrežje Natanza prinesel virus, še vedno pa ostaja odprto vprašanje o avtorjih omenjene programske opreme. Tehnično gledano je z vidika izvajanja računalniške forenzike pri vseh postopkih potrebno upoštevati tako specifike industrijskega okolja, v katerem se izvaja preiskava, kot tudi vse tehnične značilnosti takšnega okolja. Kot smo navedli pri opisu sistemov SCADA gre za tehnično opremo, ki v sklop povezuje razne senzorje, do omrežnih tehnologij (omrežne povezave med sistemi), katere bi v določenih primerih segale do mobilnih naprav. Izkaže se tudi, da je za opravljanje forenzične preiskave ključnega pomena poznavanje samega področja delovanja SCADA sistema, v konkretnem primeru procesi bogatenja urana, kot tudi strojne opreme, na katerih se omenjeni procesi izvajajo. Opravljena tehnična analiza Stuxneta je zelo podrobna in nam da neko razumljivo sliko o njegovem delovanju, širjenju in cilju. Širše gledano pa bi lahko zaradi interesa državljanov imeli predpise in strategije, ki bi podjetjem nalagali uporabo opreme, ki izpolnjuje zahteve glede varnosti, in povezano s tem uporabne artefakte, ki bi jih uporabljali računalniški forenziki pri svojem delu ter tudi omogočili izvajanje aktivnosti po neki uveljavljeni oz. prilagojeni metodologiji glede na namembnost sistemov.

9 Literatura

Departement of Justice. (2007). Digital forensic analysis methodology. Pridobljeno na: http://www.justice.gov/criminal/cybercrime/docs/forensics_chart.pdf

ESET. (2010), Stuxnet Under the Microscope. Pridobljeno na: http://go.eset.com/us/resources/white-papers/Stuxnet_Under_the_Microscope.pdf

Evropska komisija. (2005). Green Paper on a European Programme for Critical Infrastructure Protection. Pridobljeno na: http://eur-lex.europa.eu/LexUriServ/site/en/com/2005/com2005_0576en01.pdf

Idaho National Engineering and Environmental Laboratory. (2004). Review Of Supervisory Control And Data Acquisition Systems (SCADA). Pridobljeno na: http://www.inl.gov/technicalpublications/Documents/3310858.pdf

Idaho National Laboratory. (2008). Recommended Practice: Creating Cyber Forensics Plans for Control Systems. Pridobljeno na: http://www.inl.gov/technicalpublications/Documents/4113665.pdf

Institute for Science and International Security. (2009). IAEA Report on Iran. Pridobljeno na: http://www.isisnucleariran.org/assets/pdf/Iran_IAEA_Report_Analysis_5June2009.pdf

Kaspersky Lab ZAO. (2011). Stuxnet/Duqu: The Evolution of Drivers. Pridobljeno na: http://www.securelist.com/en/analysis/204792208/Stuxnet_Duqu_The_Evolution_of_DriversKurtz, L. R. (2006). Securing SCADA Systems. Indianapolis, Wiley Publishing.

Langer, R. (2012). Lagner's Stuxnet Deep Dive S4 Video. Digitalbond. Pridobljeno na: http://www.digitalbond.com/2012/01/31/langners-stuxnet-deep-dive-s4-video/

Lumeta Corporation. (2012). SCADA security incidents will become more prevalent. Pridobljeno na: http://www.lumeta.com/news/pr073008.html

Ministrstvo za okolje in prostor. (2004). Razširjeno poročilo o varstvu pred ionizirajočimi sevanji in jedrski varnosti v RS leta 2004. Pridobljeno na: http://www.uvps.gov.si/fileadmin/us.gov.si/pageuploads/Zakonodaja_in_dokumenti/Ionizirajoca_sevanja/Letna_porocila/2004/RazsirjenoLetnoPorocilo2004Slo.pdf

National Institute of Standards and Technology. (2008). Guide to Industrial Control Systems (ICS) Security. Pridobljeno na: http://csrc.nist.gov/publications/nistpubs/800-82/SP800-82-final.pdf

Nicholson, A., Webber, S., Dyer, S., Patel, T. in Janicke, H. (2012). SCADA security in the light of Cyber-Warefare, Computers & Security, 31(4), 418-436.

Poulsen, K. (2003). Slammer worm crashed Ohio nuke plant network. Security Focus. Pridobljeno na: http://www.securityfocus.com/news/6767

Ralstona, P. A., Graham J. in Hieb J. (2007). Cyber security risk assessment for SCADA and DCS networks. ISA Transactions, 46(4), 583-594.

Roberts, P. F. (2005). Zotob, PnP Worms Slam 13 DaimlerChrysler Plants. eWeek.com. Pridobljeno na: http://www.eweek.com/c/a/Security/Zotob-PnP-Worms-Slam-13-DaimlerChrysler-Plants/

Sale, R. (2012). Stuxnet Loaded by Iran Double Agents. Issource.com. Pridobljeno na: http://www.isssource.com/stuxnet-loaded-by-iran-double-agents/

SANS Institute. (2005). Security for Critical Infrastructure SCADA Systems. Pridobljeno na: http://www.sans.org/reading_room/whitepapers/warfare/security-critical-infrastructure-scada-systems_1644

Slay, J. in Miller, M. (2007). Lessons learned from the maroochy water breach. Critical Infrastructure Protection, 2007(253), 73-82.

Symantec Corporation. (2010). W32.Stuxnet Dossier. Pridobljeno na: http://www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers/w32_stuxnet_dossier.pdf

University of California. (2009). Cyberthreats, Vulnerabilities and Attacks on SCADA Networks. Pridobljeno na: http://gspp.berkeley.edu/iths/Tsang_SCADA Attacks.pdf

Uredba o evropski kritični infrastrukturi. Uradni list RS, št. 35/2011. Pridobljeno na: http://www.uradni-list.si/1/objava.jsp?urlid=201135&stevilka=1799

US-CERT Control Systems Security Center. (2005). An Undirected Attack Against Critical Infrastructure. Pridobljeno na: http://www.us-cert.gov/control_systems/pdf/undirected_attack0905.pdf

Zetter, K. (2011). How Digital Detectives Deciphered Stuxnet, the Most Menacing Malware in History. Pridobljeno na: http://www.wired.com/threatlevel/2011/07/how-digital-detectives-deciphered-stuxnet/all/1