__________________________________________________________________________________________________________________________

1. Uvod

U početku razvoja računalne tehnologije ranjivostima su se smatrale pogreške u sklopovlju i programskoj podršci koje napadač može iskoristiti za ostvarenje nekog vlastitog, nedozvoljenog cilja. Do danas, definicija se proširila i na pogreške u konfiguraciji te postavkama računalnih sustava koje se također mogu iskoristiti za izvođenje zlonamjernih aktivnosti. Sve aktivnosti vezane uz stvaranje i primjenu zakrpa kojima se ispravljaju propusti, ispravke pogrešnih konfiguracija i aktivnosti općenito vezane uz sigurnost sustava danas se svrstavaju u kategoriju računalne sigurnosti.

Ispravljanje sigurnosnih nedostataka sustava, aplikacija i usluga čini se kao jednostavan zadatak. Međutim, veličina administrirane računalne mreže izravno utječe na kompleksnost obavljanja tog zadatka. U prosječnoj računalnoj mreži, postoji velik broj računala, korisnika s prijenosnim računalima i specifičnim aplikacijama, te poslužitelja čiji je ispravan i neprekidan rad od velike važnosti za nesmetano funkcioniranje čitave organizacije kojoj mreža pripada. Programska podrška podložna je sigurnosnim propustima, a jednako tako ni proizvođači sklopovske opreme ne izrađuju proizvode vodeći dovoljno brige o sigurnosti. Sve to pred administratore i stručnjake računalne sigurnosti stavlja vrlo zahtjevan zadatak koji u pravilu nikad nije u potpunosti riješen. Praćenje pojavljivanja ranjivosti pojedinih programskih paketa nije jednostavan zadatak i zato postoje pretplatničke liste kod brojnih organizacija koje se bave uočavanjem i kategorizacijom sigurnosnih ranjivosti koao što je npr CARNet CERT.

U idealnom slučaju proizvođači programske podrške trebali bi sami uočiti propuste unutar svojih paketa prije njihovog izlaska na tržište pokretanjem postupaka evaluacije. No zbog dugotrajnosti i cijenepostupka, na tržištu postoji mnogo nedovršenih i nepotpuno verificiranih programskih paketa. Propuste u njima najčešće pronalaze nezavisni istraživači ili članovi istraživačkih timova organizacija koje se bave računalnom sigurnošću. Obično se informacije o pronađenom nedostatku zadržavaju sve dok proizvođač ne objavi potrebnu zakrpu ili ispravku. Često se događa da informacije o nedostatcima u isto vrijeme dođu i do javnosti, što potencijalnim napadačima pruža dovoljno vremena da nesmetano iskorištavaju tu ranjivost.

Zbog svega navedenoga postoji stvarna potreba za učestalim ispitivanjima sigurnosti pojedinih dijelova, ali i čitavih sustava. Učestalost se naravno određuje važnošću dijela sustava te resursa i informacija koji se nalaze na njemu.

__________________________________________________________________________________________________________________________

2. Sigurnosna ispitivanja i životni ciklus razvoja sustava

Glavni razlog provođenja sigurnosnih ispitivanja operacijskih sustava je identifikacija potencijalnih ranjivosti i propusta, te njihovo uklanjanje. Broj poznatih ranjivosti raste svakodnevno, kao i broj računala po osobi, što povećava potrebu za sposobnim i iskusnim administratorima i stručnjacima za računalnu sigurnost. Veoma je važno je da organizacije/ustanove rutinski provjeravaju i testiraju sustave zbog mogućih neispravnih konfiguracija i ranjivosti, kako bi se smanjila vjerojatnost kompromitiranja sustava.

Napadači tipično višekratno skorištavaju ranjivosti koje nisu ispravljane ili one na koje se nisu primjenile sigurnosne zakrpe proizvođača proizvoda/sustava.

„Mali broj mana u softveru odgovorno je za većinu internetskih napada ...Malen broj softverskih ranjivosti razlog su za veliku većinu uspješnih napada jer napadači ne žele ulagati bespotreban napor, već koriste otprije poznate mane i ranjivosti određenog softvera pomoću učinkovitih i lako dostupnih alata. Oni računaju na to da vlasnici sustava neće ispraviti te pogreške i ukloniti ranjivosti“

SANS security Alert, May 2000.

2.1 Životni ciklus razvoja sustava

Slika 2.1 Životni ciklus razvoja sustava

Evaluacija sigurnosti sustava može, i mora se provoditi na različitim stupnjevima razvoja sustava.

Aktivnosti evalucije sigurnosti sustava uključuju, ali nisu limitirane samo na procjenu rizika, certifikaciju i akreditaciju, sigurnosne audite sustava, te sigurnosna ispitivanja u odgovarajućim periodima tijekom životnog ciklusa sustava.Sve te aktivnosti teže k osiguranju pravilnog razvoja i korištenja sustava u suglasnosti s njegovom sigurnosnom politikom (ukoliko postoji).

Jedna od mogućih podjela životnog ciklusa sustava:

· Inicijalizacija- definira se svrha i konfiguracija sustava, te plan razvoja.

· Razvoj i akvizicija– postoji mogućnost da je sustav naručen i konstruiran po uzoru na dokumentirane procedure i zahtjeve

· Implementacija i instalacija- sustav se instlalira i integrira s ostalim aplikacijama na nekoj mreži ili većem sustavu

· Rad i održavanje- sustav radi i održava se prema planu i potrebi

· Odstranjenje- životni ciklus sustava je završen, deaktivira se i odstranjuje s mreže .

Sigurnosna ispitivanja mreže obično se provode nakon što je sustav razvijen, instaliran i integriran.

2.1.1 Faza implementacije

Tijekom faze implementacije, sigurnosno ispitivanje i evluaciju (engl. Security Testing & Evaluation, skraćeno ST&E) provodi se na pojedinačnim dijelovima sustava, i na sustavu kao cjelini.

Sigurnosno ispitivanje i evaluacija naziv je za provjeru, odnosno analizu zaštitnih mjera koje posjeduje i koristi informacijski sustav nakon što je u potpunosti integriran i funkcionalan. Ciljevi sigurnosnih ispitivanja i evaluacije su:

· Otkirvanje implementacjiskih i funkcijskih pogrešaka u dizajnu, koje mogu dovesti do narušavanja sigurnosne politike

· Određivanje pogodnosti sigurnosnih mehanizama, garancija (engl. Assurance) sigurnosnih mjera i ostalih svojstava kako bi se pravilno provodila sigurnosna politika

· Procjenjivanje sutpnja konzistentnosti između dokumentacije i implementacije sustava

Doseg ST&E plana obično se bavi pitanjima računalne sigurnosti, komunikacijske, fizičke, osobne, administrativne te funkcionalne sigurnosti.

2.1.2 Faza rada

Jednom kada sustav postane funkcionalan, važno je provjeriti njegov radni status, tj. radi li sukladno s svojim trenutnim sigurnosnim zahtjevima.Ispitivanje se provodi kako bi se procijenila funkcionalnost sustava. Tipovi testova i njihova učestalost ovise o važnosti sustava ili dijela sustava, te o dostupnim resursima potrebnim za ispitivanje. Ispitivanja sustava trebala bi se provoditi periodički i redovno, pogotovo kad se sustav znatno nadograđuje ili mijenja.

Ispitivanje sustava koji su izloženi stalnim prijetnjama npr internetski serveri, ili oni koji štite važne/povjerljive informacije npr zaštitne stijene, trebalo bi provoditi češće.

Slika 2.2 prikazuje kako bi faza rada trebala biti podijeljena u dva dijela; faza održavanja u kojem sustav može biti prilikom nadogradnje, promjene konfiguracije ili napada, te normalna radna faza.

Slika 2.2 Ispitivanja tijekom faze održavanja i normalnog rada

Tijekom faze održavanja, ST&E treba provoditi koliko i u fazi implementacije. Ista razina ispitivanja može biti potrebna prilikom povratka sustava u radnu fazu, ovisno o važnosti sustava i njegovih aplikacija. Npr. važan poslužitelj ili zaštitna stijena (engl. firewall) zahtjeva cjelovito ispitivanje, dok neki podsustav koji nije kritičan za rad ostatka sustava nije potrebno ispitivati.

2.2 Dokumentiranje rezultata sigurnosnih ispitivanja

Sigurnosna ispitivanja pružaju uvid u prethodne faze aktivnosti životnog ciklusa sustava kao što su analiza rizika i planiranje reakcija u određenim situacijama. Rezultate sigurnosnih ispitivanja treba dokumentirati, i oni moraju biti dostupni svima onima koji se brinu o sustavu općenito; razlog tome je što se razultati mogu koristiti u sljedeće svrhe:

· Kao referentne točke za korektivne akcije

· Prilikom definiranja akcija za otklnjanje identificiranih ranjivosti

· Kao pokazatelj napretka u zadovoljavanju sigurnosnih zahtjeva

· Kako bi se procijenio stupanj implementacije zahtjeva sigurnosti sustava

· Kako bi se provela analiza troškova/koristi pri poboljšanju sigurnosti sustava

· Kao poticaj za provođenje procjene rizika, certifikacije i evaluacije, te poboljšanje performansi

__________________________________________________________________________________________________________________________

3. Tehnike sigurnosnih ispitivanja

Postoji nekoliko tipova sigurnosnih ispitivanja. Sljedeće poglavlje opisuje svaki tip ispitivanja, te njihove nedostatke i dobre karakteristike. Neki tipovi ispitivanja kompletno su automatizirani i zahtjevaju minimalnu ljudsku intervenciju, dok druge treba provoditi ručno. Bez obzira na tip ispitivanja osobe koje iniciraju i provode testove moraju dobro poznavati sustav, te posjedovati znanje iz područja kao što su mrežna sigurnost, zaštitne stijene, sustavi za detektiranje proboja sigurnosnih zaštita (engl Intrusion Detection System, skraćeno IDS), operacijski sustavi, programiranje te mrežni protokoli.

U nastavku biti će govora o sljedećim tipovima ispitivanja:

· Analiza računalnih mreža

· Procjena ranjivosti

· Password cracking

· Preispitivanje dnevnika

· Provjere integriteta

· Detekcije virusa

· Wardriving

· Penetracijska testiranja

· System audit

Često se nekoliko tehnika ispitivanja koriste zajedno kako bi se dobila detaljnija i kompletnija procjena stanja sustava. Na primjer penetracijska ispitivanja obično uključuju skeniranje mreže i procijenu ranjivosti, kako bi se moglo identificirati ranjive dijelove sustava, te usluge koje bi u budućnosti mogle postati metom napada. Neki programi koji provjeravaju ranjivost sustava sadrže i programe za probijanje lozinki (engl. Pasword Cracking Program). Niti jedan od ovih pojedinačnih testova ne daje kompletnu sliku stanja sigurnosti sustava, osim sigurnosnog sustavskog audita.

Nakon provođenja testova, treba provesti određenu proceduru koja uključuje dokumentiranje rezultata ispitivanja, informiranje vlasnika sustava o rezultatima, te otklanjanje otkrivenih ranjivosti.

3.1 Analiza računalne mreže

Analiza računalne mreže u kontekstu sigurnosti nužna je za ispravan i neometan rad svih priključenih računala.

Metoda analize mreža može se podijeliti u četiri koraka:

• prikupljanje informacija o mreži (engl. Network Enumeration),

• skeniranje podmreže i određivanje dostupnosti (engl. Bulk network scanning and probing),

• pronalaženje ranjivosti (engl. Investigation of Vulnerabilities) i

• iskorištavanje ranjivosti (eng. Exploitation of Vulnerabilities).

3.1.1 Prikupljanje informacija o mreži

Prikupljanje informacija uključuje pretraživanje internetskih stranica i novinskih grupa, WHOIS usluga dohvaćanja informacija od informacijskih središta (engl. Network Information Center , skraćeno NIC), te dohvat informacija od DNS poslužitelja (engl. Domain Name Server ). Ovim istraživanjima dobivamo podatke o strukturi mreže i njenim korisnicima do kojih se dolazi bez izravnog pristupa objektu analize. Informacije dohvaćene u ovom koraku obuhvaćaju detalje oko internih IP adresa prikupljenih od DNS poslužitelja, daju uvid u strukturu imenovanja računala ciljanog sustava (imena domena, pod domena i računala) te odnos između IP adresa i fizičkih lokacija računala. Svi ovi podaci koriste se dalje u strukturiranom skeniranju ciljane mreže i potencijalnih ranjivosti na njenim računalima.

3.1.2 Skeniranje podmreže i određivanje dostupnosti

Nakon određivanja adresnog prostora dodijeljenog ciljanoj mreži, slijedi ispitivanje aktivnih računala i usluga. Za to se koriste skeneri komunikacijskih portova (engl. Port Scaners) na razini TCP, UDP i ICMP protokola. Usluge koje se uglavnom traži su HTTP, FTP, SMTP, POP3, ali i brojni drugi.

Rezultat skeniranja je lista svih aktivnih glavnih (engl. Host) računala i popis na njima aktiviranih usluga, usluga, printera, preklopnika (engl. switch), i usmjerivača (engl. router) koji su aktivni u adresnom prostoru kojeg smo skenirali. Moguće je doći i do informacija o postavkama zaštitne stijene ili nekog drugog mehanizma filtriranja. Nakon prikupljanja svih potrebnih podataka u ovom koraku, napadač ili stručnjak za sigurnost može započeti analizu te pronaći najsvježije sigurnosne propuste u dostupnim uslugama.

Skeneri portova kao što je Nmap, prvo identificiraju aktivne hostove u adresnom prostoru, koji koriste Transport Control Protocol/Internet Protocol (TCP/IP) Internet Control Message Protocol (ICMP) ECHO i ICMP ECHO_REPLY pakete. Kada se lociraju sva aktivna glavna računala, pretražuju se oni koji imaju otvorene TCP i UDP komunikacijske portove preko kojih se utvrđuje koji se mrežni servis koristi na tom glavnom računalu.

Svi skeneri imaju drugačije mogućnosti i nedostatke, i koriste različite metode skeniranja. Na primjer, neki su skeneri bolji za skeniranje kroz zaštitne stijene, dok su drugi bolje prilagođeni skeniranju unutar zaštitnih stijena.

Osnovne verzije svih skenera identificiraju aktivna glavna računala, no neki imaju i mogućnost sakupljanja više informacija dok skeniraju otvorene portove, kao što su identificiranje operacijskog sustava koji se koristi na tom računalu. Ovaj se proces naziva uzimanje otiska prsta sustava (engl. System Fingerprinting), tj provodi se otkrivanje operacijskih sustava udaljenih računala.

Otkrivanje operacijskih sustava udaljenih računala provodi se usporedbom mrežnih podatkovnih paketa određenog računala s porukama odgovora (engl. Reply message) poznatih operacijskih sustava. Kao što je identitet osobe moguće otkriti usporedbom njena otiska prsta s otiscima u policijskoj arhivi, tako je moguće utvrditi operacijski sustav udaljenog računala usporedbom njegova mrežnog prometa s karakterističnim „mrežnim otiscima“ operacijskih sustava iz prethodno stvorene baze podataka. Operacijski sustav koji se izvodi na udaljenom računalu moguće je otkriti prisluškivanjem mrežnih podatkovnih paketa koji u normalnom radu putuju među računalima. Takve metode otkivanja operacijskog sustava nazivaju se pasivnima. Aktivne metode uključuju slanje posebno oblikovanih podatkovnih paketa računalu čiji je operacijski sustav potrebno otkriti te analizu odgovora spomenutog računala. Ove metode u radu koriste sigurnosni stručnjaci, ali i zlonamjerni korisnici, za stvaranje mapa udaljenih računalnih mreža, te za utvrđivanje potencijalnih sigurnosnih nedostataka u njima.

Na primjer ako glavno računalo koristi TCP portove 135 i 139, tada je naj vjerojatnije na računalu instaliran operacijski sustav Windows NT ili 2000. Do tog se zaključka može doći i pomoću rednog broja TCP paketa ili odgovora na ICMP pakete, npr pomoću TTL (engl. Time TO Live) polja, polje zaglavlja IP protokola u kojem je pohranjen maksimalan broj usmjerivača kroz koje paket može proći prije njegova odbacivanja. Spomenuti broj razlikuje se kod pojedinih operacijskih sustava, na primjer kod Windows operacijskog sustava ima vrijednost 32, a kod Linux operacijskog sustava 64.

Ova metoda nije skroz pouzdana jer zaštitne stijene filtriraju/blokiraju određenje portove i vrste prometa. Isto tako administratori mogu konfigurirati sustav da na određene upite odgovara nekonvencionalno, te tako kamuflira koji je operacijski sustav instaliran na računalu. Izbjegavanje udaljenog otkrivanja operacijskog sustava postiže se izmjenama pozdravnih poruka čiji sadržaj može ovisiti o inačici aplikacije koja implementira uslugu, uklanjanjem znakovnih nizova iz datoteka, gašenjem nepotrebnih usluga, te onemogućavanjem ispitnih poruka.

Neki skeneri pomažu pri identifikaciji aplikacije koja koristi pojedini port. Na primjer ako skener otkrije kako je na računalu otvoren port 80, to često znači kako host koristi web poslužitelj. Identifikacija korištene aplikacije ključna je za pronalazak ranjivosti mreže.

Na primjer ranjivosti Microsoftovog IIS poslužitelja veoma se razlikuju od onih Apache web poslužitelja. O kojoj se aplikaciji radi možemo utvrditi ako „slušamo “ na udaljenom portu kako bi se pročitala banner informacija poslana s udaljenog hosta kada se klijent (u ovom slučaju web pretraživač) spoji. Banner informacije obično nisu vidljive krajnjem korisniku (za web servere/pretraživače); ipak kada se pošalje, može pružiti pregršt informacija, uključujući tip i verziju aplikacije, pa čak i tip i verziju operacijskog sustava.

Dok skeneri portova pronalaze aktivna računala, usluge, aplikacije i tipove operacijskog sustava, oni ne pronalaze ranjivosti sustava. Ranjivosti može pronaći jedino osoba koja interpretira rezultate skeniranja. Iz tih se rezultata može utvrditi koje su usluge ranjive. Iako je sam proces skeniranja automatiziran, interpretacija dobivenih podataka nije.

3.1.3 Pronalaženje ranjivosti

Novi sigurnosni nedostaci raznih programskih paketa uočavaju se svakodnevno. Kao dokaz postojanja nedostatka često se osnovnom opisu prilažu i programski kodovi ili aplikacije koje ranjivost iskorištavaju. Tako se svim zlonamjernim korisnicima daje pristup alatima za izvođenje napada. Prethodni korak istraživanja pokrenutih usluga ne daje dovoljne podatke o njihovim postavkama pa je u ovom koraku potrebno obaviti i dio ručnog ispitivanja. Ključne informacije dobivene ovim korakom obuhvaćaju podatke o prisutnim ranjivostima, ali i alatima koji omogućuju njihovo iskorištavanje.

3.1.4 Iskorištavanje ranjivosti

U posljednjem koraku skeniranja mreže podrazumijeva se potpuna pripremljenost napadača odnosno sigurnosnog stručnjaka za izvođenje aktivnosti koje se temelje na iskorištavanju ranjivosti. U ovoj poziciji napadač može učiniti nešto od slijedećeg:

• steći prava administratora sustava,

• preuzeti datoteke s korisničkim imenima i zaporkama,

• sakriti tragove u dnevnicima (engl. Log files ) i osigurati si "stražnji ulaz" kojim ponovo može pristupiti napadnutom računalu,

• preuzeti potencijalno osjetljive podatke,

• postaviti i koristiti alate za izvođenje napada na druga računala u okolici.

3.1.5 Razlozi i nedostatci provođenja ispitivanja

Skeniranja mreža trebala bi se provoditi zbog:

· Otkrivanja neautoriziranih računala koja su spojena na mrežu

· Identificiranja ranjivosti

· Pronalaženja devijacija prilikom korištenja usluga u odnosu na sigurnosnu politiku

· Služi kao priprema za penetracijsko ispitivanje

· Pomoći prilikom konstrukcije IDS-a

· Sakupljanja forenzičkih dokaza

Interpretacija podataka zahtijeva relativno veliku razinu znanja. Skeniranja mogu poremetiti normalno funkcioniranje mreže zauzimajući resurse, pojasne širine (engl. bandwith), te usporavanje vremena odziva mreže. Unatoč tome, mrežna skeniranja su veoma korisna jer omogućuju kontroliranje IP adresnog prostora te provjeru koriste li računala samo dozvoljene aplikacije i mrežene usluge. Rezultate mrežnog skeniranja treba dokumentirati, a nedostatke ukloniti. Sljedeće korektivne mjere mogu biti potrebne nakon obavljenog skeniranja:

· Istražiti i dokumentirati neautorizirana računala

· Odstraniti nepotrebne i ranjive aplikacije

· Modificirati ranjiva računala tako da imaju ograničen pristup nesigurnim aplikacijama

· Modificirati zaštitne stijene kako bi se onemogućio pristup aplikacijama s poznatim ranjivostima

3.2 Provjera ranjivosti sustava

Provjera ranjivosti (engl. Vulnerability scanning) koristi automatizirane alate poput eEye Retina, Nessus i QualysGuard koji predstavljaju relativno jeftina rješenja za pronalaženje ranjivosti. Nedostatak pretstavlja ograničen broj ranjivosti koje mogu prepoznati, te najčešće nemogućnost izvođenja koraka s ciljem poboljšanja sigurnosti.

Skeneri ranjivosti, po konceptu su slični port skenerima. Oni također identificiraju glavna računala i otvorene portove, ali istovremeno daju informacije o ranjivosti, tj sami interpretiraju prikupljene podatke, stoga ne ovise o korisničoj interpretaciji. Većina alata koji procjenjuju ranjivost sustava pokušaju dati savjet kako ukloniti pronađene ranjivosti. Ovakvi skeneri brzi su i jednostavan način za kvantificiranja izloženosti sustava „površinskim ranjivostima“ te za odstranjenje nedostatka prije nego što ih netko uspije iskorisitit. „Površinska ranjivost“ predstavlja ranjivost dijela sustava koji postoji izoliran od ostalih, neovisan o ostalim ranjivostima. Problem utvrđivanja razine rizika jest taj da ranjivost skoro nikad nije nepovezana s ostalima. Na primjer, na nekoj mreži postoji nekoliko ranjivosti malog rizika, koje kad se uzmu u obzir kao cjelina predstavljaju veliku prijetnju sustavu. Alat za procjenu ranjivosti generalno ne bi prepoznao ovakvu prijetnju, stoga bi svaku zasebno kategorizirao kao prijetnju malog rizika, te dao pogrešnu sliku o sigurnosti sustava. Pouzdan način utvrđivanja razine rizika jest provođenje penetraciskih testiranja.

Skeneri ranjivosti pokušavaju identificirati ranjivosti skeniranog računala, te mogu pronaći zastarjele verzije softvera, zakrpe ili nadogradnje potrebne sustavu, kao i utvrditi sličnosti i odstupanja od sigurnosne politike. Kako bi se to postiglo skeneri identificiraju operacijski sustav i najvažnije softverske aplikacije koje se nalaze u njemu te provjeravaju poznate slabosti istih. Skeneri upotreblajvaju velike baze podataka ranjivosti, kako bi mogli identificirati nedostatke poznate u često korištenim operacijskim sustavima i aplikacijama.

Skeneri ranjivosti imaju i značajnih nedostataka. Općenito, mogu identificirati ranjivosti, no ne mogu procijeniti cjelokupni rizik skenirane mreže. Iako je sam proces automatiziran, skeneri ranjivosti mogu kao rezultat skeniranja dati lažno pozitivne rezultate (prijave ranjivost gdje one ne postoji), stoga je važno pažljivo interpretirati prikupljene informacije.

Kako skeneri ranjivosti zahtjevaju više informacija od port skenera kako bi pouzdano otkrili nedostatke na računalu, oni imaju tendenciju generiranja mnogo više mrežnog prometa nego port skeneri, što može imati negativan utjecaj na računala ili mrežni segment kroz koji se prenose informacije.

Još jedno značajno ograničenje jest to da njihova efikasnost ovisi o stalnim aktualizacijama svoje baze podataka kako bi mogli otkriti najnovije ranjivosti. Tako se prije svakog skeniranja preporuča aktualizacija baze ranjivosti. Baze nekih skenera se nadograđuju češće od drugih, stoga bi i to trebao biti jedan od važnijih paremetara prilikom odabira skenera.

Ovi tipovi skenera najbolje otkrivaju dobro poznate ranjivosti sustava, nego neke slabo poznate ili rijetko iskorištavane uglavnom zbog toga što je teško sistematizirati baš sve ranjivosti svih popularnijih operacijskog sustava i aplikacja, također proizvođači ovih alata nastoje zadržati brzinu svojih proizvoda, stoga se naviše fokusiraju na ranjivosti koje su najpoznatije (kada bi željeli otkriti više ranjivosti, potreban je veći broj testova, a time se usporava sam proces skeniranja).

Alati procjene ranjivosti obavljaju sljedeće zadatke:

· Pronalaze sva aktivna računala na mreži

· Utvrde sve aktivne i ranjive usluge na računalima

· Identificiraju application i banner grabbing

· Utvrđuju koji se operacijski sustav koristi na pojedinom računalu

· Pronalaze ranjivosti koje se povezuju s operacijskim sustavom te njegovim aplikacijama

· Pronalaze pogrešno konfigurirane dijelove sustava

· Testiraju podudarnost korištenja aplikacija s sigurnosnom politikom

· Koriste se kao temelj za provođenje penetracijskih testiranja

Postoje dva tipa alata za skeniranje ranjivosti: oni zasnovani na skeniranju mreže, te oni zasnovani na skeniranju računala. Mrežni skeneri koriste se za mapiranje mreža, utvrđivanje otvorenih portova i povezanih ranjivosti. U većini slučajeva ovi sknerei nisu limitirani samo na određene operacijske sustave ciljanih sustava. Skener se može instalirati na jednom računalu mreže, te veoma brzo locira i testira sve ostale hostove na istoj mreži.

Skeneri zasnovani na glavnim računalima (engl. Host based) moraju biti instalirani na svakom pojedinom računalu, a najviše se koriste za otkrivanje pogrešaka u konfiguraciji određenih operacijskih sustava i aplikacija, te njihove ranjivosti (za svaki operacijski sustav postoji specifični skener). Ovi tipovi skenera mogu otkriti ranjivosti s puno većom preciznošću, neki imaju opciju ispravljanja pogrešno konfiguriranih sustava.

Skeniranja ranjivosti trebalo bi se provoditi kao bi se provjerilo jesu li operacijski sustav, te sve veće i važnije aplikacije ažurirane, posjeduju li sve najnovije zakrpe... Preporuka je da se ovaj tip skeniranja provodi svakih 3 do 6 mjeseci, a najvažnije i najeksponiranije sustave kao što su zaštitne stijene, javni serveri, ...trebalo bi stalno provjeravati. Kako niti jedan skener neće otkriti SVE ranjivosti preporuča se korištenje nekoliko njih.

Rezultati alata skeniranja ranjivosti sustava trebaju se dokumentirati, a otkriveni nedostatci otkloniti. Kao rezultat skneiranja sljedeće mjere mogu postati neophodne:

· Nadogradnja ili instaliravanje zakrpi ranjivog djela sustava kako bi se otklonili nedostatci

· Ukoliko neko ažuriranje trenutno nije moguće obaviti jer bi to onesposobilo mnoge druge dijelove, treba postaviti odgovarajuće protumjere (tehničke ili proceduralne) kako bi se smanjio rizik iskorištavanja tih mana dok ne bude moguće uklanjanje

· Poboljšati konfiguraciju, programe i procedure koji se brinu o održavanju sustava kako bi se osigurala rutinska nadogradnja i aktualizacija

3.3 Probijanje lozinki

Programi za probijanje lozinki (engl. Password Crackers) koriste se za otkrivanje slabih lozinki, tj provjeravaju je li korisnik odabrao dovoljno jaku lozinku. Lozinke se čuvaju i prenose (ako je to zbilja potrebno) kao hash kod. Kada se korisnik logira na računalo/sustav, te unese lozinku, generira se njen sažetak, koji se uspoređuje s onim sačuvanim koji pripada pojedinom korisniku. Ako se oba hash koda poklapaju, korisnik je autentificiran.

Tijekom izvođenja penetracijskih testiranja ili stvarnih napada koriste se uhvaćeni hash kodovi. Hash kodovi lozinka mogu se presresti kada se šalju kroz mrežu (koristeći mrežni sniffer) ili dohvatom s ciljnog sustava (ova metoda zahtjeva administrativne ili root ovlasti).

Kada se hash dobavi, programi za probijanje lozinki generiraju kodove dok se god ne dobije identični. Najbrža metoda generiranja hash kodova jest napad riječnikom (engl. dictionary attack), koji koristi sve riječi u riječniku ili tekst datoteci. Postoji mnogo riječnika dostupnih na webu, za sve jezike, imena, popularne tv serije...stoga bilo koja riječ koja se može pronaći u nekom riječniku, ma koliko neobična bila, koliko god se rijetko koristila, predstavlja lozinku koju se može lako probiti.

Jedna od popularnijih metoda probijanja lozinki naziva se hibridni napad (engl. hybrid attack), koji nadograđuje metodu napada riječnika dodavanjem brojčanih vrijednosti ili simbola na riječi iz riječnika. Ovisno o korištenom alatu, za ovaj tip napada poznato je nekoliko varijacija; česte zamjene znakova npr p@ssword, ili dodavanje znakova i brojeva na početaki ili kraj riječi iz riječnika, npr.password99, password$%....

Najmoćnija metoda probijanja lozinki zove se probijanje grubom silom (engl. brute force). Iako metodi često treba mnogo vremena, ipak protekne manje vremena dok se probije nego period u kojem sigurnosne politike zahtjevaju promijenu lozinki. Loznke do kojih se dođe brute force napadom još uvijek su previše slabe.Kod korištenja Brute force napada nasumično odabiru lozinke i izračunava njihove hash vrijednosti, ali zbog pre velikog broja mogućnosti probijanje lozinki često traje i mjesecima. Teoretski, sve se lozinke mogu probiti; uz dovoljno vremena i računala. Penetracijski testeri i napadači često koriste nekoliko rečunala na kojima mogu podijeliti posao pretraživanja svih mogućnosti. Višestruki procesori znatno skraćuju vrijeme potrebno da se probije jaka lozinka.

Jakom Linux/Unix lozinkom smatra se ona koja je duga barem 10 znakova, a sadrži velika i mala slova, te brojeve i znakove. Stvaranje jake lozinke za Windows operacijski sustav nekad je bilo malo složenije zbog toga što su verzije prije Windowsa 2000 koristile LanMan hash sažetke za lozinke. LanMan ne prepoznaje velika i mala slova, te se svi znakovi abecede pretvaraju u velika slova. Ovo efektivno smanjuje broj različitih kombinacija koje osoba koja pokušava probiti lozinku mora isprobati. Druga mana LanMan-a je ta što se sve lozinke čuvaju kao sažetci dugi 7 znakova. Lozinke koje su duge točno 14 znakova podijeliti će se u dvije, dužine 7 znakova, dok se one kraće od 14 znakova nadopunjuju do te duljine. Dijeljenje sažetaka u lozinke dovodi do toga da se lozinka puno lakše probije (dvije lozinke od 7 znakova lakše se razbiju od one duge 14 znakova).

Programi za razbijanje lozinki trebali bi se provoditi na sustavu jednom svakih 6 mjeseci, te ako se otkrije veliki broj neadekvatnih i slabih lozinki koje se može lako probiti treba:

· Ako su odabrene lozinke bile u skladu s sigurnosnom politikom, treba promijeniti istu kako bi se smanjio postotak lozinki koje se mogu lako probiti, no ako ova promijena navede korisnike da počnu zapisivati svoje lozinke, tada je najbolje preći na neki alternativni način autentifikacije.

· Ako probijene lozinke nisu bile odabrane u skladu s sigurnosnim propisima, treba korisnicima istih ukazati na opasnosti njihovog korištenja slabih lozinki, a sustavski administratori mogu postaviti minimalnu duljnu i kompleksnost odabranih lozinki

Na sustavima koji koriste filtre lozinki, preporuča se da se filtri postave tako da primore korisnike na korištenje jakih lozinki, pa prilikom ispitivanja sigurnosti neće biti potrebe provoditi provjere probijanja lozinki.

3.4 Preispitivanje dnevnika (engl. Log review)

Nadzor i bilježenje aktivnosti u informacijskom sustavu vrlo su važni elementi u svakom sustavu za upravljanje sigurnošću. Aktivnosti se mogu bilježiti na razne načine, ovisno o elementu informacijskog sustava na kojem se provode određene aktivnosti ili mu se pristupa.

Kod tehničkih komponenti informacijskog sustava kao što su operacijski sustavi ili aplikacije na radnim stanicama i poslužiteljima ili mrežni uređaji (preklopnici, usmjerivači, zaštitne stijene i sl.), uobičajeno je bilježenje aktivnosti u tzv. log datoteke. Načini bilježenja informacije, razina detaljnosti, format vremenskih znački i drugi parametri bilježenja vrlo često se razlikuju od implementacije do implementacije, a pregledavanje višestrukih log datoteka u velikim ili heterogenim sustavima postaje potpuno nepraktično, pa čak i nemoguće. U složenim informacijskim sustavima, a posebno u onima kod kojih postoje formalni sustavi za upravljanje sigurnošću, od ključne je važnosti da se bilježenje svih aktivnosti važnih za ispravno i sigurno funkcioniranje sustava provodi kontrolirano. Sustavi za centralizirano bilježenje, koji se najčešće koriste u takvim okruženjima, omogućavaju jednostavnije ručno ili automatizirano pregledavanje log zapisa, te njihovo arhiviranje u skladu s definiranom sigurnosnom politikom. Osim toga, korištenjem takvih sustava osigurava se dodatna razina sigurnosti na sustavima koji udaljeno šalju zabilježene aktivnosti; u slučaju da ih se kompromitra od strane neovlaštenih korisnika sve aktivnosti koje su se događale prije kompromitiranja ostaju zabilježene na centralnom sustavu, a zlonamjerni korisnik nema mogućnost njihove naknadne promjene u cilju uklanjanja tragova svojih aktivnosti.

Razni sustavski logovi mogu se koristiti prilikom otkrivanja odstupanja od sigurnosne politike, uključujući i log zaštitne stijene, IDS log, logovi poslužitelja, te bilo koji drugi log koji predstavlja zabilježene podatke o sustavu i mreži na koju je sustav spojen. Preispitivanje dnevnika i analiza mogu predstaviti dinamičku sliku tekućih sistemskih aktivnosti koji se mogu uspoređivati s sigurnosnom politikom da se utvrdi koliko se te akcije podudaraju. U suštini, nadzorni logovi se mogu koristiti za provjeru ponaša li se sustav u skladu s sigurnosnom politikom.

Na primjer, ako se IDS senzor postavi iza zaštitne stijene (unutar privatne mreže), njegovi logovi mogu se koristiti kako bi se proučilo zahtjeve usluga te promet koje stijena propušta u privatnu mrežu. Ako senzor otkrije neovlaštene aktivnosti iza stijene, to indicira kako ona više nije konfigurirana ispravno s sigurnosnog aspekta, te postoji „stražnji ulaz“ do privatne mreže.

Snort je besplatan mrežni IDS (Intrusion Detection System) senzor s opsežnom programskom podrškom, koji je sposoban izvoditi analizu prometa i paketa u stvarnom vremenu. Snort može provesti analizu protokola, traženje sadržaja, a može se koristiti i za detekciju mnogo napada i sondi kao što su prekoračenja međuspremnika, prikrivena skeniranja portova, CGI ( Common Gateway Interface) napade, SMB (System Mesage Block) sonde, te pokušaji udaljenog identificiranja operacijskog sustava. Snort koristi fleksibilan jezik pravila kako bi opisao promet koj treba propustiti, a koji zaustaviti, kao i alat za detekciju koji koristi modularnu plugin arhitekturu. Ovaj program također posjeduje sposobnost alarmiranja u realnom vremenu, kao i ugrađene mehanizme upozorenja za syslog, korisnički definiranu datoteku, Unix socket, ili WinPopup poruke za Windows klijente koristeći Sambin smbclient. Snort se koristi u tri primarne svrhe, kao direktan paket snifer npr tcpdump, kao paket (korisno za debugiranje mrežnog prometa), ili kao kompletan mrežni IDS.

Provjere logova trebale bi se provoditi često, pogotovo nakon većih promjena sustava na glavnim serverima i zaštitnim stijenama. U tu svhu preporučuje se korištenje filtra nad logovima, kako bi se spriječio unos nebitnih stvari i time znatno olakšao posao sustavskim administratorima prilikom identificiranja problema i nedozvoljenih aktivnosti [1].

3.5 Alati za provjeru integriteta datoteka

Za razliku od zaštitnih stijena i IDS sustava koji pružaju zaštitu na mrežnom nivou, alati za provjeru integriteta datotečnog sustava (engl. File Integrity Checker, skraćeno FIC) orijentirani su prema pojedinim poslužiteljima (engl. host based tool).

Instalacijom programa ovog tipa omogućuje se pravovremeno uočavanje neovlaštenih promjena unutar datotečnog sustava, što ih čini posebno korisnima u postupcima detekcije i prevencije malicioznih aktivnosti. Isti su se također pokazali vrlo korisnima i kod forenzičke analize kompromitiranih računala, budući da omogućuju prilično jednostavnu detekciju promijenjenih datoteka i direktorija.

Alat FIC računa i pohranjuje otisak (engl. checksum) za svaki sačuvani podatak, te stvara bazu podataka. Ovi alati pružaju administratoru sustava oruđe za uvid u promijene, osobito one neautorizirane, nad datotekama i podacima. Pohranjene otiske trebale bi se konstantno uspoređivati s novo izračunatima kako bi se utvrdilo je li došlo do kakvih modifikacija. FIC obično čini sastavni dio komercijalnih IDS-ova zasnovanih na poslužiteljima.

Program za provjeru integriteta koristan je alat koji ne zahtjeva visok stupanj interakcije s korisnikom, ali se treba koristiti oprezno kako bi se osigurala pravilna uporaba. Alatu FIC-a potreban je sustav za koji se zna da je siguran, kako bi mogao stvoriti inicijalnu bazu za reference, inače bi mogao generirati hash funkcije kompromitiranog sustava, te odati lažan dojam sigurnosti testeru. Referentna baza podataka mora se pohraniti na mjesto koje nije dostupno s mreže tako da napadi ne mogu kompromitirati sustav i sakriti svoje tragove modificiranjem baze podataka. Alat FIC može isto tako dati lažne pozitivne rezultate; svako ažuriranje podataka, te instaliranje sustavske zakrpe mijenjaju podatke stoga je neophodno ažurirati bazu podataka. Ovaj zahtjev povlači za sobom činjenicu kako je teško bazu podataka održavati aktualnom, no čak i da se provjera obavi samo jednom, prilikom prve instalacije sustava opet može omogućiti provjeru jeli neki podatak bio mijenjan, ukoliko se sumlja u to. Napadači su dokazali kako mogu modificirati podatke na načine koje uobičajeno korišten CRC (Cyclic Redundancy Check) nije mogao otkriti, stoga se preporuča korištenje jačih checksum generatora kao što je SHA-1 kako bi se osigurao integritet podataka pohranjenih u bazi podataka otisaka.

Provjere integriteta podataka trebali bi se provoditi često nad odabranim dijelovima sustava koji bi bili pogođeni u slučaju kompromitiranja, kao i kad se sumlja na kompromitiranje sustava kako bi se utvrdila količina pogođenih sustava i nastale štete. Ako FIC pronađe neautoriziranu promijenu podataka, postoji mogućnost sigurnosnog incidenta, te se slučaj treba istražiti prema procedurama i politici dojavljivaja i reakcije na incidente, ukoliko postoji [1] .

3.6 Antivirusni programi i skeneri

Svi sustavi koji maju pristup Internetu, koriste prijenosne medije ili koriste freeware/shareware softver, u opasnosti su od inficiranja virusima, malicioznim računalnim kodovima.Utjecaj virusa na računalo može biti bezopasno poput pop-up poruke, ili toliko destruktivno da obriše sve podatke pohranjene na računalu. Kada se radi o malicioznim programima uvijek postoji i rizik otkrivanja ili uništavanja osjetljivih ili povjerljivih podataka/informacija.

Postoje dva tipa dostupnih antivirusnih programa: oni koji se instaliraju na mrežnu infrastrukturu, i oni koji se instaliraju na svako pojedino korisničko računalo. Oba tipa programa imaju svoje prednosti i nedostatka, no ako želimo postići najveći stupanj sigurnosti potrebna su nam oba. Virusni detektori koji se instaliraju na mrežnu infrastrukturu, obično se instaliraju na granici mreže sustava zajedno s zaštitnom stijenom. Server based antivirusni programi mogu detektirati viruse prije nego što uđu u privatnu mrežu, ili prije nego što korisnik skine e-mail poruku u kojoj se nalazi virus. Još jedna prednost ovog tipa antivirusnih programa jest ta da iako se svi antivirusni programi moraju redovito ažurirati, to je lakše izvedivo ovom tipu zbog limitiranog broja relacija s računalima domaćinima.

Drugi tip softvera detekcije virusa instalira se na host računala, te može detektirati maliciozne programe u e-mailovima, prijenosnim medijim, hard diskovima, dokumentima, ali samo na lokalnom računalu. Ovaj tip antivirusnih programa ima manji utjecaj na mrežne preformanse, ali općenito ovisi o kranjem korisniku prilikom ažuriranja, iako danas većina antivirusnih programa može automatski ažurirati virusne definicije.

Bez obzira koji se tip antivirusnih programa koristi, on može u potpunosti obavljati svoj zadatak jedino ukoliko ima konstantno svježe ažuriranu bazu podataka virusnih definicija koja mu omogućava prepoznavanje svih poznatih virusa i malicioznih programa. Kako bi otkrili viruse, programi uspoređuju sadržaj datoteka s poznatim definicijama virusa, ukoliko pronađe takvu informaciju, podatke koji sadržavaju virus sprema u karantenu te ukoliko je to moguće oslobađa ih od virusa, inače briše. Sofisticiraniji programi traže i aktivnosti koje sliče aktivnostima virusa kako bi mogli identificirati nepoznate ili mutirane viruse koje s sadašnjom bazom podataka inače ne bi prepoznali.

Virusi te ostali maliciozni programi kao što su Trojanski konji, i crvi mogu djelovati jako destruktivno na sustav, stoga je najvažniji aspekt korištenja antivirusnih programa učestalo i redovito ažuriranje baze podataka (engl. virus definition files), te se tako minimizira mogućnost virusne infekcije sustava [1].

Preporučuju se sljedeći koraci:

· Virusne definicije trebale bi se ažurirati barem jednom dnevno

· Anti virusni programi trebali bi biti aktivni konstantno

· Nakon svakog većeg ažuriranja baze podataka virusnim definicijama, treba izvršiti skeniranje cijelog sustava

3.7 Ispitivanje bežičnih mreža

Bežične LAN (engl. Local Area Network, skraćeno LAN) mreže imaju veću fleksibilnost nego fiksne LAN mreže. Tradicionalni LAN-ovi zahtijevaju kabelsko povezivanje računala s mrežom. Kod bežičnih mreža dovoljna je pristupna točka (engl. access point). Pristupna točka je kabelom spojena na fiksnu mrežu, dok je s druge strane preko antena povezana s uređajima s bežičnim mrežnim karticama. Unutar otvorenog prostora pristupne točke pokrivaju udaljenosti sto metaraili više, dok u zatvorenom ta vrijednost pada naotprilike 30 metara. Područje pokrivenosti se obično naziva ćelija. Korisnici se slobodno kreću unutar ćelija s svojim prijenosnikom ili drugim mrežnim uređajem. Ćelije pristupnih točaka mogu biti povezane tako da omoguće korisnicima roaming unutar ili između građevina.

Naj popularniji bežični LAN protokoli su 802.11b, 802.11g te u novije vrijeme 802.11n. Protokol 802.11 ima ozbiljnih mana u implementaciji WEP-a ( engl. Wireless Equivalnet Privacy protocol, skraćeno WEP), jer se hardver konfigurira nesigurno u početnim postavkama, što olakšava instalaciju ali, ostavlja brigu o sigurnosti na korisnicima. Ponovno korištenje sekvence je glavna slabost bilo kojeg sustava šifriranja. Kada su paketi enkriptirani istom RC4 sekvencom, XOR operacija provedena na dva enkriptirana paketa je jednak XOR-u dva paketa sa čistim tekstom. Analizirajući razlike između dva toka, zajedno sa strukturom tijela okvira, napadač može doći do zaključaka o sadržaju samih okvira sa čistim tekstom. Za izbjegavanje toga WEP koristi IV (engl. Initialization Vectors) za enkripciju različitih paketa s različitim RC4 ključevima. Ipak, IV je dio zaglavlja paketa i nije enkriptiran, tako da prisluškivači mogu uočiti pakete enkriptirane istim RC4 ključem. Kriptografi su identificirali mnoge slabe točke WEP algoritma. RC4 je snažna enkripcija, no napadači nisu ograničeni na frontalni napad na kriptografski algoritam, već mogu napasti bilo koju slabu točku protokola.

Bežični Lan-ovi pružaju mogućnost napadačima da zaobiđu zaštitne stijene i IDS.

Na samim početcima implementacije bežičnih tehnologija napadači, te ostali snalažljivi korisnici vozili bi se uokolo ureda velikih kompanija opremljni laptopima s bežičnim karticama, i pokušavali se spojiti na nezaštićene pristupne točke (ova se praksa naziva engl. vardriving). Postojale su čak i web stranice sa popisima otkrivenih nezaštićenih mreža. Danas takvo što nije potrebno jer se u svakom dijelu grada može pronaći nezaštićene bežične mreže, a većina ugostiteljskih objekata, hotela, željezničkih i autobusnih kolodvora nudi korištenje usluga bežičnog interneta.

Neke od ranjivosti 802.11b protokola:

· Podložni su neovlaštenim upadima i korištenjem mreže

· Moguće je presresti i nadzirati promet bežične mreže

· Moguće je izvesti napad Client to client

Kako bi se koristio relativno siguran bežični internet, treba stvoriti wireless sigurnosnu politiku te osgurati da ju provode svi korisnici sustava, kao i redovito ispitivanje i pretraživanje mreže kako bi se otkrili krivo konfigurirani LAN ili neautorizirani korisnici [1].

Učestalost ispitivanja i skeniranja mreže ovisi o nekoliko faktora:

· Fizički faktori lokacije; ukoliko se objekt u kojem se koristi bežična mreža nalazi na osami, udaljen od javno dostupnih mjesta, skeniranje nije potrebno provoditi previše često

· Ako je sustav u prošlosti često bio metom napada, treba provjere provoditi na dnevnoj bazi

· Ukiliko su podatci koji su dostupni s mreže osjetljive i povjerljive prirode preporučaju se česta ispitivanja

· Ako se koriste robustnije metode provedbe sigurnosti mreže kao što su WPA (Wi-Fi Protected Access) ili RSN (Robust Security Network) nisu potrebne previše česte provjere sustava

3.8 Penetracijsko testiranje

Etičan haker (eng. ethical hacker, white hat) je stručnjak u području računarstva i računalnih mreža. On napada računalne sustave pokušavajući iskoristiti njihove slabosti, ali, za razliku od zlonamjernih hakera (eng. hacker, black hat), on to čini prema nalogu vlasnika ciljanog sustava i upravo s ciljem identifikacije ranjivosti i sprečavanja djelovanja zlonamjernih hakera. Rad etičnog hakera često se još naziva i penetracijskim testiranjem (engl. penetration testing). Penetracijsko testiranje, unatoč uvriježenom mišljenju, ipak nije samo pokretanje nekoliko alata i izrada izvještaja. U ovom je području potrebna struktura i organizacija koja, osim propisivanja grupe testova, mora osigurati i odgovore na pitanja kvalitete, sveobuhvatnosti i ponovljivosti rezultata. Ta je struktura u ovom području obuhvaćena metodologijom, a razvija se kako bi od penetracijskog ispitivanja učinila alat koji će pružiti što je moguće realističniju sliku o aktualnoj sigurnosti testiranog objekta.

Penetracijsko testiranje, sigurnosno je testiranje u kojem evaluatori pokušavaju zaobići ili probiti sigurnosne postavke sustava, na temelju razumijevanja postavki sustava te njegove implementacije. Cilj penetracijskog testiranja je identificiranje metoda pomoću kojih možemo pristupiti sustavu korištenjem taktika i alata koje inače koriste napadači.

Pen ispitivanjima moguće je dobiti veoma vrijedne informacije o sigurnosnom stanju nekog sustava, no istovremeno, kako bi došli do tih informacija treba uložiti mnogo truda, znanja i opreza kako bi se smanjio rizik za ciljane sustave. Minimalan utjecaj provedbe pen testiranja je usporenje rada mreže te protoka podataka i vremena odgovora mreže zbog skeniranja mreže i procjene ranjivosti. Uvijek postoji i moućnost da se sustav ošteti te postanje neupotrebljiv prilikom ispitivanja. Iako vlasnici sustava imaju koristi od takve informacije, kako bi se njihov sustav mogao srušiti prilikom pravog napada, to nikada nije veoma poželjan ishod, stoga se testiranju treba pristupiti veoma oprezno.

Ako su pen testiranja dizajnirana s ciljem simuliranja napada, a koriste alate i tehnike koje obično koriste napadači, koji su većinom zakonom zabranjeni, važno je dobiti formalni pristanak za izvršavanje ispitivanja na nekom sustavu prije samog početka. Dopuštenje, koje se nekada zove i engl. rules of engagement trebao bi sadržavati:

· Specificirani IP adresni prostor koji se treba ispitati

· Popis poslužitelja, računala te podmreži koje se ne smiju ispitati

· Listu dopuštenih tehinka ispitivanja (kao što su social engeneering, DoS), te alata (password crackers, network sniffers...)

· Vrijeme kada se ispitivanje može provoditi

· Definirati vremenski period u kojem se ispitivanje mora obaviti

· IP adrese računala s kojih će se ispitivanje provoditi kako bi sustavski administratori mogli razlikovati legitimne testove od onih stvarnih malicioznih napada

· Mjesto pristupa tima sustavu i mreži

· Mjere kojima se spriječava nepotrebno obavještavanje zakonodavnih službi zbog krivog tumačenja ispitivanja kao napada

· Kako pen testing tim treba postupati s prikupljenim informacijama

Penetracijske testiranja mogu se obavljati u tajnosti, ili javno, tj svi korisnici sustava upoznati su s testiranjem. Ova se dva tipa ispitivanja nazivaju Blue i Read teaming. Blue teaming provdi se s znanjem svog osoblja zaduženog za održavanje sustava. Read teaming obavlja se bez znanja IT stručnjaka zaduženih za susatav ali s potpunim dopuštenjem i znanjem vlasnika sustava. Prilikom Read teaminga vlasnici sustava ponekad odrede tim ljudi, kako bi se osiguralo da se na napad ne reagira kao na pravi, ili provjerava jeli pravi(ako aktivnost koju provjeravaju nije dio testranja). Ovaj tim ljudi posreduje između vlasnika testiranog sustava te timom koji provodi ispitivanja, olakšava komunikaciju i provjerava aktivnosti. Ovaj tip ispitivanja koristan je ne samo za provjeru sigurnosti sustava, već kao i kontrola reakcija i poduzetih protumjera od strane ljudi koje održavaju i brinu se za sustava, njihovog znanja te do koje mjere provode sigurnosnu politiku sustava. Read teaming može se provoditi s upozorenjem ili bez njega.

Blue teaming je jeftiniji te se i češće provodi, dok se Read teaming provodi rijeđe zbog toga što traje duže i mora se obaviti tajno i neopaženo. Kako bi to izveli, skeniranja i druge akcije moraju se usporiti kako bi bile suptilnije od onih koje IDS te zaštitne stijene testiranog sustava mogu otkriti. Read teaming daje realnije podatke o stanju sigurnosti sustava i spremnosti da se obrani od napada, zbog toga što administratori ne očekuju napad, te obavljaju svoje svakodnevne zadatke.

Pen testovi se mogu složiti tako da simulitaju vanjske ili unutarnje napade. Ako se provode oba tipa ispitivanja, obično se prvo provede vanjsko testiranje, a potom unutarnje. Prilikom vanjskog ispitivanja zaštitne stijene obično ograniče količinu i broj tipova prometa koji se propušta u unutarnju mrežu iz vanjskih izvora. Ovisno o tome kojim je protokolima dopušten prolaz, inicijalni napadi se generalno fokusiraju na uobičajeno korištene i dozvoljene aplikacijske protokole kao što su FTP, HTTP, ili SMTP i POP.

Kako bi se simulirao stvarni napad izvana, testeri ne posjeduju nikakve stvarne informacije o ciljnom sustavu osim IP adresni prostor koji moraju ispitati, te u kojem moraju tajno sakupljati informacije prije napada. Informacije o ciljanom sutavu sakupljaju se na javno dostupnim web stranicama i grupama, te sličnim stranicama. Tada koristeći port skenere i skenere ranjivosti, utvrde ciljna računala, a kako se testiranje najčešće provodit kroz zaštitne stijene količina informacija znatno je manja nego što bi bila kada bi provodili skenirenja unutar sustava. Nakon što se identificiraju izvana dostupna računala, pokušava se kompromitirati jedan od njih, te ako uspiju mogu ga koristit kao uporište i ulaz u sustav, kako bi kompromitirali i ostala koji nisu generalno dostupni izvana. Ovo je razlog zašto je pen testiranje iterativni postupak koji koristi minimalni pristup, s ciljem dobivanja maksimalnog pristupa sustavu. Interni pen test sličan je vanjskome, osim što su testeri sada s unutarnje strane zaštitne stijene, u unutarnjoj mreži, te imaju neku razinu dozvole pristupa sustavu. Testeri tada pokušaju dobiti pristup više razine putem podizanja svog statusa. U ovoj je fazi cilj steći administratorske ovlasti temeljem prethodno stečenih ovlasti manje važnosti. Glavne prepreke tom cilju su primijenjene ispravke koje analizatoru bitno umanjuju broj prisutnih ranjivosti, a time i mogućnost zlouporabe. Dodatnu prepreku predstavljaju alati za provjeru integriteta sustava (uključujući antivirusne alate), koji u nekim slučajevima mogu zaustaviti akcije analizatora. Testeri imaju samo one informacije o sustavu koje inače posjeduje korisnik s njihovom razinom dozvole. Penetracijsko testiranje provodi se u 4 faze:

Slika 3.1 Metodologija pen testiranja u 4 faze

U fazi planiranja, utvrđuju se pravila, finalizira se odobrenje vlasnika sustava, te se postave ciljevi ispitivanja. U ovoj fazi zapravo nema nikakvog ispitivanja.

Faza otkrivanja započinje testiranje sustava. Koriste se mrežni skeneri kako bi se locirale potencijalne mete, te port skenerima i ostalim sličnim tehnikama sakuplja se što više informacija o ciljanom sustavu. Neke od tih tehinka su:

· DNS (Domain Name System) ispitivanje

· InterNIC (whois) queries

· Pretraživanje web poslužitelja ciljanog sustava

· Pretraživanje sustavskih Lightweight Directory access Protocol poslužitelja

· Hvatanje paketa podataka (općenito samo tokom internih testova)

· NetBIOS enumeracija (općenito samo tokom internih testova)

· Network Information System

· Banner grabbing

Druga dio faze otkrivanja jest analiza ranjivosti. Tijekom ove faze, usluge, aplikacije i operacijski sustav skeniranih hostova uspoređuju se s bazama ranjivosti (za skenere ranjivosti, ovaj se proces provodi automatski). Kada tester želi ručno provjeravati ranjivosti, koristi svoju bazu, ili neku javno dostupnu; ovo je dobar način otkrivanja novih ili rijetkih ranjivosti, no puno sporiji postupak. Izvršavanje napada jezgra je pen testiranja. U ovoj se fazi provjeravaju prije identificirane ranjivosti, pokušajima da ih se iskoristi za napad. Ako je neki napad uspješno proveden, ranjivost se potvrđuje, te se postave dodatne sigurnosne postavke kako bi se smanjila mogćnost ponovnog iskorištenja iste ranjivosti.

Exploits su dokumnetirane metode ili programi/skripte koje iskorištavaju ranjivosti. Mnoge baze podataka ranjivosti pružaju exploit naputke ili kodove za većinu identificiranih ranjivosti. U svakom slučaju potrebne su dodatne analize i ispitivanja kako bi se otkrila prava razina rizika koju predstavlja sigurnosno stanje testiranog sustava.

Dok skeneri ranjivosti samo provjeravaju postoji li možda ranjivost, u fazi napada pen testiranja iskorištava se ranjivost, time potvrđujući njeno postojanje. Većina ranjivosti iskorištenih pen ispitivanjima te ostalim malicioznim napadima mogu se svrstati u sljedeće kategorije:

· Mane jezgre (engl. Kernel Flaws)-jezgrin source kod predstavlja jezgru operacijskog sustava, i provodi sigurnosni model sustava, bilo koja greška koja postoji u ovom kodu dovodi u opasnost cijeli sustav

· Preljevanje međuspremnika (engl. Buffer Overflows)-događa se kada programi ne provjeravaju jesu li unosi odgovarajuće dužine, i najčešće se dogode kao posljedice lošeg programiranja. Kada se ovako nešto dogodi, moguće je unijeti vlastiti kod te ga izvršiti s svim privilegijama tekućeg programa. Takvi se programi mogu izvoditi kao root na Unixoidnim sustavima, te kao SYSTEM (administrator) za Windows sustave.

· Symbolic Links (symlink)- datoteka koja pokazije na neku drugu. Često postoje programi koji mogu mijenjati dozvole neke datoteke. Ako se ovi programi izvode s privilegiranim dopuštenjima, korisnik bi mogao strateški stvoriti symlink kako bi naveo te programe na mijenjanje ili izlistavanje sustavskih datoteka

· File Descriptor Attacks- datotečni deskriptori su ne negativni cijeli brojevi koje sustav koristi kako bi imao pregled svih fileova, umjesto da koristi specificirana imena. Kada privilegirani program dodijeli neadekvatan datotečni deskriptor, izlaže datoteku kompromitirajućim situacijama.

· Race Conditions- Race conditions mogu nastati kada program ili proces uđe u privilegirani način izvođenja, ali prije nego što se vrati u normalan način izvođenja, tako korisnik može tempirati napad dok je program/proces u tom stanju. Ako napadač tada uspije kompromitirati program/proces, on je “pobijedio utrku“ . Uobičajeni uvjeti utrke sadržavaju manipulaciju jezgrinih datoteka, te rukovanje signalima

· File and Directory Permission-kontroliraju pristup korisnika i procesa, direktorijima i datotekama . Adekvatne dozvole ključne su za sigurnost svkog sustava. Loše postavljene dozvole mogu dopustiti velik broj napada, uključujući čitanje ili mijenjanje datoteka s lozinkama, ili dodavanja nekog računala na listu od povjerenja

· Trojanci- trojanski programi mogu sadržavati BackOrifice, NetBus, SubSeven, ili mogu biti specijalno izrađeni. Kada se jednom dobije pristup, mogu se koristiti kernel root kit kako bi se pronašao stražnji ulaz u sustav.

· Social Engeneering-naziv je za tehinku nagovaranja ili varanja korisnika sustava kako bi se dobio pristup, ili informacije o sustavu. Tipično se provodi kroz razgovor, telefonski, e-poštom ili licem u lice. Obično se koriste dva standardna pristupa; tester se predstavlja kao korisnik koji ima poteškoća, i kontaktira osobu koja pruža tehinčku pomoć, kako bi dobio informacije o ciljanom mrežnom računalu, dobio korisičko ime i lozinku ili mu resetiraju lozinku kako bi mogao postaviti bilo koju svoju. U drugom se pristupu tester predstavlja kao help desk, te naziva korisnike i navede ih da mu otkriju svoja korisnička imena i lozinke. Pokazalo se da su ove tehnike iznimno uspešne.

Faza izvještavanja događa se simultano s ostale tri faze pen testiranja. U fazi planiranja to su pravila obveze, planovi ispitivanja i pisana dopuštenja. U fazama otkrivanja i napada, stvaraju se pisani logovi, te se šalju periodički izvještaju sustavskim administratiorima ili vlasnicima sustava. Na kraju sveopćeg ispitivanja sastavi se izvještaj koji opisuje pronađene ranjivosti, procjenjuje rizik, te savjete o uklanjanju pronađenih slabosti.

Pen testiranja su važna za otkrivanje koliko je neki sustav ranjiv, i za definiranje stupnja štete koji može nastati ukoliko se sustav kompromitira. Korektivne mjere mogu uključivati otklanjanje otkrivenih i iskorištenih slabosti, modificiranje sigurnosne politike, stvaranje procedura koje poboljšavaju provođenje sigurnosnih mjera, te edukacija osoblja o utjecaju loše ili nepropisno konfguriranog sustava, na sigurnost [1].

3.9 Sigurnosni audit ( provjera)

Nakon što se provede procjena ranjivosti, a rezultati iskoriste kako bi se ojačala sigurnost sustava, trebao bi se provesti sigurnosni audit (revizija, provjera, ispitivanje). Kao i alati za provjeru ranjivosti, audit alati provjeravaju sigurnosne postavke i zakrpe, ali s drugim ciljem; oni uspoređuju pronađeno s definiranim sigurnosnim politikama. Audit alati mogu koristiti vanjski korisnici koji žele provijeriti slaganje sustava s sigurnosnim mjerilima preformansi (engl. benchmark) objavljenog od strane nekog autoritativnog izvora kao što su SANS, NIST, CIS (Center for Internet Security), NSA (National Standard Agency). Norma koja se obično koristi za stvaranje mjerila performansi zove se ISO/IEC 27002.

Mogu ih koristiti i korisnici sustava kako bi evaluirali i provjerili je li sustav u skladu s sigurnosnim normama. Audit alati obično provode testove prema rasporedu, spremaju rezultate u bazu podataka, pružaju bogatu više razinsku sposobnost izvještavanja. Većina ih prilikom prikaza rezultata priloži listu gdje se mogu nabaviti nedostajuće zakrpe kojima bi se zadovoljilo neko pravilo standarda sigurnosne politike.

Sigurnosna provjera mjeri do koje se razine sustav poklapa s definiranom sigurnosnom politikom, koja je često bazirana na industrijskim standardima ili mjerilima performansi kao što su oni koje objevljuje CSI. Mnoge organizacije naručuju sigurnosnu provjeru, reviziju za sustav ili mrežu kako bi povečali povjerenje korisnika, dobili akreditacije, ili uskladili s regulativima tržišta. Dio sigurnosnih provjera provodi se interno, zbog provjere koliko se dobro sustav poklapa s industrijskim mjerilima performansi, i jesu li prijašnje sigurnosne mjere još uvijek dovoljno dobre. Audit alati rezultate daju u obliku sažetih izvještaja koji olakšavaju prilagođavanje standardima svojim uputama i prijedlozima.

Sljedeće akcije mogu se poduzeti ukoliko sustav nije konfiguriran u skladu s sigurnosnom politikom:

· Odstraniti ranjive usluge koji nisu potrebni

· Reducirati sustav na željenu razinu kako bi se smanjila mogućnost kompromitiranja

· Promijeniti postavke zaštitne stijene kako bi se ograničio pristup ranjivim sustavima ili uslugama

· Promijeniti postavke zaštitne stijene kako bi se ograničio pristup iz IP podmreže koja je izvor kompromitiranja

Sigurnosni audit računala predstavlja ručnu ili uatomatsku mjerljivu tehničku procjenu sustava ili aplikacije. Ručne procjene uključuju intervjuiranje zaposlenika, provođenje skeniranja ranjivosti, pregledavanje kontrola za pristupanju sustavu ili aplikacijama, te analiziranje fizičkih točaka pristupa sustavu.

Automatske procjene ili CAAT (engl. Computer Assisted Auditing Techniques) uključuju audit izvještaje generirane od strane sustava, ili koriste softver kako bi nadgledali i izvještavali o promjenama podataka ili postavki sustava (osobna računala, poslužitelji, usmjernici, preklopnici...) i /ili aplikacija (mrežni usluge, baze podataka....). CAAT-ovi se koriste kada treba provesti audit podataka koji se ne mogu obraditi ručno, ili kako bi se povećala efikasnost i skratilo vrijeme provođenja provjera. Tehnike koje koriste CCAT-ovi uključuju testiranje na prijevare (engl. Fraud testing), Curve data deviation, srednji ili medijan unos podataka prilikom kalkulacija i predviđanja (engl. Average of median user data input calculation and prediction), analiza starosti, analiza duplikata, slojevitost podataka...[6].

Alati koji koriste CAAT tehnike nazivaju se Generalizirani audit softver (engl. Generalized Audit Software). Ovaj je softver dizajniran da čita, procesuira i piše podatke uz pomoć funkcija koje izvode specifične audit rutine s posebno kreiranim makro naredbama. Funkcije generaliziranog audit softvera uključuju importiranje računalnih podataka, stoga se na njih mogu primijeniti i druge funkcije npr sortiranja, pretraživanja, sažetka, slojevitosti, analize, izračuna,....

Ručno provjeravanje logova veoma je zahtjevani dugotrajan posao. S druge strane automatizirani audit alati pružaju mogućnost značajnog smanjenja utrošenog vremena kako bi se generirao izvještaj (predefinirani) koji sistematizira sadržaje logova prema specifičnim aktivnostima.

Korištenjem tradicionalnih metoda, aplikacije i komponente predaju text datoteke loga bez nekog određenog formata procesima koji se brinu za spremanje logova kao što su Syslog za Unix, MS Windows sustavski, sigurnosni ili aplikacijski log-ovi, ili log41. za Javu. Ove tekstualne datoteke obično sadrže samo informacije koje razvojni programer smatra važnima, a ta osoba vjeojatno nije sigurnosni stručnjak. Temeljni problem je dakle da savaka aplikacija ima različite informacije, različitog formata u svom audit zapisu događaja (engl. audit event record) kao i format u kojem bi se taj zapis trebao prikazati u audit log-u. Ova varijanca u formatiranju mnogo različitih aplikacija, koje se stalno mijenjaju i nadograđuju, pretvara posao parsiranja zapisa audit događaja veoma teškim poslom za alate analize, te povećava vjerojatnost pogreške.

Moderni audit usluge kao što je OpenXDAS baziran na Distribuiranim Audit Uslugama (engl. Distributed Auditing Service), pružaju strukturiranu alternativu tekst datotekama bez formata prilikom audit logiranja. XDAS specifikacije definiraju dobro promišljene formate log događaja za događaje povezane sa sigurnošću, s definiranom taksonomijom za sve tipove događaja koji pokrivaju sve moguće scenarije povezane sa sigurnošću kao i stadnardizirani API za prikaz i rukovanje logova i događaja [6].

3.10 Akcije nakon ispitivanja

Ispitivanja obično otkriju probleme kojima s treba odmah pozabaviti. Kako da se ti problemi riješe i minimiziraju zapravo je najvažniji korak procesa ispitivanja. Najčešći razlozi i metode za njihova riješavanja su:

Nedostatak ili krivo provođenje sigurnosne politike: najveći doprinos sigurnosno loše konfiguriranih sustava jest nedostatak sigurnosne politike. Sigurnosna politika je važna jer osigurava konzistentnost. Konzistentnost je ključna komponenta uspješnih sigurnosnih postavki jer vodi k predvidivom ponašanju, te time olakšava održavati sigurne konfiguracije i pomaže pri identificiranju sigurnosnih problema sustava (koji se obično manifestiranju kao devijacije od predvidivih, očekivanih ponašanja).

Sigurnosna bi politika trebla sadržavati:

· Organizacijske standarde, specifikacije uniformnih korištenja specifičnih tehologija, parametara ili procedura

· Privatnost (postoji li nadzor e-pošte ili korištenja weba)

· Prihvatljivi razlozi korištenja sustavskih resursa i računala

· Uloge i odgovornosti (korisnici, administratori,...)

· Odgovornost (audit, rukovanje incidentima)

· Autentifikacija

· Dostupnost resursa (obnova nakon razrušenja, backup, redundancija)

· Usuglašavanje (nepridržavanje pravila, posljedice i kazne)

Krivo konfiguriran sustav ili dijelovi sustava: kada sustav nije konfiguriran propisno i prema preporukama. Postoje brojne akcije koje se mogu upotrijebiti za minimizaciju mogućnosti pogrešnog konfiguriranja:

· Za ključne dijelove sustava, može se odrediti posebene nadzornike koji kontroliraju promjene nastale na tim dijelovima sustava te jesu li one u skladu s sigurnosnom politikom.

· Stvoriti ili koristiti već gotove kontrolne liste koje sadrže listu konfiguracijskih postavki, a ako se one poštuju i primjene sustav postaje sigurniji.

(NE)Pouzdanost softvera: mnogi uspješni napadi iskoristili su pogreške u programskim kodovima korištenog softvera. Problem se može minimizirati na sljedeće načine: ukoliko je kod pisan za potrebe sustava napisao korisnik ili administrator sustava, treba ugraditi adekvatne metode za razvoj i testiranje koda kako bi se osigurala razina kvalitete koda. Za kupljeni komercijalni kod, treba redovito provjeravati postoje li nove zakrpe, te redovito ih ažurirati. Prilikom odabira ovakvih programa, dobro je prvo provjeriti postoje li poznate ranjivosti za taj poroizvod u bazama ranjivosti.

Nemogućnost primjene zakrpi (engl. Failure to Apply patches): Softver je postao toliko kompliciran da su pogreške u njemu neizbježne. Kada se otkrije neka pogreška, proizvaođač obično proizvede zakrpu koja ispravi ili umanji pogrešku kako bi postala neiskoristiva malocioznim napadačima. Nažalost mnogi sustavski administratori nemaju vremena, resursa, ili znanja da na vrijeme primjene zakrpe. Ova se činjenica reflektira u pocjenama kako su se mnogi napadi mogli spriječiti da je sustav bio ažuriran redovito i na vrijeme.

Rezultati ispitivanja mogu ukazivati na potrebu temeljite promijene sigurnosne arhitekture sustava. Na primjer rezultati pen testiranja mogu pokazati potrebu za višeslojnom zaštitnom strategijom s povećanim brojem zaštitnih stijena. Ili potreba ažuriranja sigurnosnim zakrpama velikog broja računala može dovesti do potrebe prihvaćanja centralizirane sheme upravaljanja.

Rezultati ispitivanja dobar su pokazatelj cjelokupne slike sigurnosnog stanja sustava, te operacijske sredine istog, kao i načina da se ta okolina promijeni takoda olakša buduća ispitivanja i smanji rizik ranjivosti sustava [2].

3.11 Sažetak usporedbi tehnika ispitivanja

Tablica 3.1 Sažetak tehnika ispitivanja

Tip testa

Prednosti

Slabosti

Mrežno skeniranje

· Brzina (u usporedbi s pen ispitivanjem i skeniranjima ranjivosti)

· Efikasno skenira računala sustava

· Mnogo besplatno dostupnih alata

· Visok stupanj automatizacije

· Mala cijena troškova

· Ne identificita direktno poznate ranjivosti, iako otkriva četo korištene Trojanske portove

· Koristi se kao uvod u pen testiranje, a ne kao završno ispitivanje

· Zahtjeva mnogo znanja i iskustva prilikom interpretacije rezultata

Skeniranje ranjivosti

· Može biti brzo, ovisno o broju hostova koje treba skenirati

· Postoji nekolicina besplatnih alata

· Visok stupanj automatizacije

· Identificira poznate ranjivosti

· Pruža prijedloge kako smanjiti uočene slabosti

· Visoka cijena (komercijalni skeneri), niska cijena (besplatni alati)

· Jednostavno se redovito koristi

· Daje pogrešne pozitivne rezultate

· Generira veliku količinu prometa prema specifičnom hostu što može dovesti do rušenja računala ili DoS

· Ne rade prikriveno, IDS-ovi , zaštitne stijene pa čak i korisnici ih lako otkrivaju

· Može biti opasan alat u neiskusnim rukama

· Često ne identificira najnovije ranjivosti

· Pronalazi samo površinske ranjivosti, ne i njihove kombinacije

Penetracijska testiranja

· Testira sustave i mreže koristeći metodologije koje inače koriste napadači

· Provjerava ranjivosti

· Pronalazi više od površinskih ranjivosti te pokazuje kako se te ranjivosti mogu iterativno iskorištavati kako bi se dobio veći pristup

· Demonstrira kako ranjivosti nisu čisto teoretske

· Socijalni inžinjering dopušta ispitivanje procedura i ljudskog faktora u sigurnosti sustava

· Zahtjeva visoku razinu iskustva i znanja

· Veoma je naporan i dugotrajan posao

· Vrijeme potebno za probijanje sporih ciljanih hostova može se produžiti na dane

· Zbog golemog utroška ne ispituju se svi hostovi srednjeg ili velikog sustava

· Opasno kada ga izvode neiskusni testeri

· Neke tehinke koje se koriste mogu biti zakonski zabranjene

· Skup postupak

· Može poremetiti organizaciju sustava

Probijanje lozinki

· Brzo identificira slabe lozinke

· Pruža jasnu demonstraciju jačine ili slabosti lozinke

· Lako se implemetiraju

· Mala im je cijena

· Mogu se koristiti u pogrešne svrhe

· Nije dopušteno njihovo korištenje prilikom ispitivanja nekih sustava

Preispitivanje dnevnika

· Pruža upotrebljive i korisne informacije

· Jedini izvor informacije koji daje povijesne informacije

· Naporno je ručno pregledavati podatke

· Automatizirani alati nisu precizni jer mogu izostaviti važne informacije

Provjera integriteta datoteka

· Pouzdani prilikom otkrivanja je li računalo kompromitirano

· Visok stupanj automatizacije

· Niska cijena

· Ne može prepoznati kompromitiranje koje se dogodilo prije istaliranja

· Otisci se moraju ažurirati prilikom ažuriranja sustava

· Otisci datoteka se moraju čuvati na sigurnom mjestu kako ih napadači ne bi mogli izmijeniti

Antivirusni programi

· Izvrsni su prilikom detekcije te otklanjanje i prevencije zaraze vrusima

· Niska do srednja cijena

· Kako bi bili efektivni zahtjevaju konstantna ažuriranja

· Sposobnost reagiranja na nove, brzo replicirajuće viruse je limitirana

Wardriving

· Efektivan način identificiranja neautoriziranih pristupnih točaka

· Ako se presretnu signali neke druge mreže može doći do problema

· Zahtjeva određenu razinu znanja i iskustva

Sljedeća tablica opisuje raspored i listu evaluacijskih faktora za kategorije ispitivanja. U kategoriju 1 spadaju svi oni sustavi koji izvršavaju ključne funkcije u sustavu ili se brinu o njegovoj sigurnosti. Ovi sustavi često uključju:

· Zaštitne stijene, preklopnike, usmjerivače, te obrambene sustave kao što su IDS

· Javno dostupni dijelovi sustava kao što su internet i mali poslužitelji

· DNS poslužitelji te ostali interni sustavi koji bi mogli biti mete napada

Sustavi druge kategorije su generalno svi drugi sustavi, npr. oni koji su zaštićeni zaštitnom stijenom itd... ali ih se svejedno treba redovito ispitivati [1].

Tablica 3.2 Kategorizacija sustava prema važnosti ispitivanja

Tip testa	Kategorija 1 Frekvencija	Kategorija 2 Frekvencija	Koristi
Mrežno skeniranje	Konstantno do svaka 4 mjeseca	Svakih 6 mjeseci	· Enumerira mrežnu strukturu i utvrđuje set aktivnih računala, te korištenog softvera · Pronalazi neidentificirana računala · Pronalazi otvorene portove i usluge
Skeniranje ranjivosti	Svaka dva mjeseca i svaki put kada se ažurira baza ranjivosti	Svakih 6 mjeseci	· Enumerira mrežnu strukturu i utvrđuje set aktivnih računala, te korištenog softvera · Identificira ciljani set računala na kojima se fokusira skeniranje · Pronalazi potencijalne ranjivosti nad tim setom · Validira kako su operacijski sustav i sve važnije aplikacije ažurirane
Penetracijska testirnaja	Godišnje	Godišnje	· Utvrđuje koliko je sustav ranjiv na napade te razinu štete koja se može prouzročiti · Testira reakcije, zanje, te implementaciju sigurnosne politike od strane zaposlenika
Razbijanje lozinki	Konstantno	Konstantno	· Verificira kako je sigurnosna polica efektivna pri zahtjevanju jakih lozinki, te verificira izabiru li korisnici lozinke u skladu s politikom
Preispitivanje dnevnika	Dnevno	Tjedno	· Validira kako sustav funkcionira u skladu s očekivanjima
Integritiy Checkers	Mjesečno, te ako se sumlja u incident	Mjesečno	· Detektira neautorizirane modifikacije datoteka
Antivirusni programi	Dnevno ili po potrebi	Po potrebi	· Otkriva, briše viruse prije nego što se uspiju instalirati na sustav
Wardriving	Tjedno	Svakih 6 mjeseci	· Detektira neautorizirane bežične pristupne točke

__________________________________________________________________________________________________________________________

4. Strategije sigurnosnih ispitivanja

Odlučivanje o tipu i učestalosti ispitivanja sustava kroz fazu rada i fazu održavanja uključuje prioritizaciju procesa zasnovanu na sigurnosnim kategorijama, cijeni planiranih testova, i koristi koje će sustav imati od tog ispitivanja. Kada se odlučuje što će se ispitivati, tijekom implementacijske faze uključuje samo jedan sustav, dok je ista odluka prilikom ispitivanja tijekom radne faze puno kompliciranija. Kako bi se maksimizirala vrijednost ispitivanja, prilikom procesa prioritetiziranja trebala bi se uzeti u obzir međupovezanost dijelova sustava.

4.1 Određivanje sigurnosne kategorije

FIPS publikacija pruža standarde za određivanje sigurnosne kategorije informacijskog sustava. Kategorizacija može biti od velike koristi prilikom određivanja prioriteta sustava prilikom ispitivanja. FIPS-ove sigurnosne kategorije bazirane su na potencijalnim posljedicama za sustave, kad bi se dogodio neki događaj koji bi ugrozio informacijski sustav organizacije koji vlasnike spriječava u obavljanju dodijeljene dužnosti, zaštiti svoja dobra, ispunjava svoje legalne obveze, održi svakodnevne funkcije, te zaštiti svoje korisnike te ostale individue nekako povezane s njom. Sigurnosne kategorije trebaju se koristiti u kombinaciji s procjenama ranjivosti te informacijama o mogućim prijetnjama kako bi se odredio rizik koji prijeti nekom sustavu. FIPS Publikacija definira tri razine potencijalnih posljedica za sustav ili pojedince, kada bi se dogodio proboj sigurnosti (npr. povreda povjerljivosti, integriteta ili dostupnosti) [5].

Određivanje prioriteta dijelova sustava nad nekim drugima koji se trebaju ispitivati trebalo bi se rangirati prema sigurnosnoj kategoriji, cijeni ispitivanja, potrebnim i trenutno dostupnim resursima, te dobitkom.

Potencijalni utjecaj na sustav je NIZAK ukoliko:

· Gubitak povjerljivosti, integriteta ili dostupnosti imaju malen ili limitiran negativan efekt na sustavske operacije, ili osoblje i korisnike; što efektivno znači da mogu (i) uzrokovati degradaciju u sposobnosti izvođenja zadataka do te mjere da su funkcionalne samo osnovne funkcije sustava, te je njihova efektivnost značajno smanjena; (ii) rezultirati manjim materijalnim te financijskim gubitcima; (iii) dovesti do nekog oblika povrede privatnosti

Potencijalni utjecaj na sustav je UMJEREN ukoliko:

· Gubitak povjerljivosti, integriteta ili dostupnosti imaju ozbiljan negativan efekt na sustavske operacije, ili osoblje i korisnike; što efektivno znači da mogu (i) uzrokovati znatnu degradaciju u sposobnosti izvođenja zadataka do te mjere da su funkcionalne samo osnovne funkcije sustava, te je njihova efektivnost značajno smanjena; (ii) rezultirati znatnim materijalnim te financijskim gubitcima; (iii) dovesti do nekog oblika povrede osoblja ili korisnika, ne uključujući gubitak života ili zadobivanje ozbiljnih ozljeda

Potencijalni utjecaj na sustav je VISOK ukoliko:

· Gubitak povjerljivosti, integriteta ili dostupnosti imaju ozbiljan do katastrofičan negativan efekt na sustavske operacije, ili osoblje i korisnike; što efektivno znači da mogu (i) uzrokovati znatnu degradaciju u sposobnosti izvođenja zadataka do te mjere da nije moguće izviditi niti primarne funkcije sustava; (ii) dovesti do velikih materijalnih i financijskih gubitaka; (iii) dovesti do nekog ozbiljnog oblika povrede osoblja ili korisnika.

4.2 Utvrđivanje cijene provođenja svakog tipa ispitivanja po sustavu

Kada se odrede sustavske sigurnosne kategorije, trebala bi se procijeniti i cijena testova koji se namjeravaju provoditi. Cijena ovisi o nekoliko faktora:

· Veličina sustava koji se treba ispitivati-LAN, baza podataka, neka veća aplikacija....

· Kompleksnost sustava koji se treba ispitivati-ispitivanje mreže i sustava neke velike organizacije koja koristi heterogene operacijske sustave biti će skuplje

· Razina ljudske interakcije potreben za pojedini test

· Izvedivost odabira uzorka za izvođenje testa, te veličina uzorka (možda nema smisla provesti mrežno skeniranje na malom uzorku računala, takav tip pen testiranja je u potpunosti prihvatljiv).

4.3 Procjena dobitaka

Kako bi se osiguralo da cijena ispitivanja neće prevazići važnost tog dijela sustava, treba identificirati te kvanitificirati koji su dobitci provođenja ispitivanja. Iako je najočitiji dobitak provođenja sigurnosnih ispitivanja identficiranje ranjivosti prije nego što ih iskoisti neki napadač, postoji još niz pogodnosti, a neke od njih su:

· Vrijednost dobivenog znanja o sustavu i mrežama koje nije postojalo prije ispitivanja-poboljšano znanje o sustavu vodi ka njegovom lakšem upravljanju, organizaciji poslova te zaštiti

· Znatno smanjenje mogućnosti uspješnog upada u sustav ili remećenja obavljanja svakodnevnih zadataka- ispitivanjem te ispravkom otkrivenih mana, smanjuje se broj ranjivosti koje mogu biti iskorištene

__________________________________________________________________________________________________________________________

5. Upravljanje sigurnosnim rizikom

Sigurnosni rizik definira se kao mogućnost realizacije nekog neželjenog događaja, koji može negativno utjecati na povjerljivost (engl. confidentiality), integritet (engl. integrity) i raspoloživost (engl. availability) informacijskih resursa. Pod informacijskim resursima podrazumijevaju se sva ona sredstva koja se koristi u svrhu ostvarivanja ciljeva (hardver, softver, ljudski resursi, podaci i sl.). Precizna identifikacija, odnosno klasifikacija informacijskih resursa prvi je korak procesa upravljanja sigurnosnim rizikom. Na temelju njega određuje se koji resursi zahtijevaju kakav tretman sa stanovišta sigurnosti. Upravljanje sigurnosnim rizikom (engl. Risk Management), disciplina koja je proizašla iz potrebe za standardizacijom i formalizacijom postupaka vezanih uz upravljanje sigurnošću. Definira se kao proces identifikacije onih čimbenika koji mogu negativno utjecati na povjerljivost, integritet, i raspoloživost računalnih resursa, kao i njihova analiza u smislu vrijednosti pojedinih resursa i troškova njihove zaštite. Završni korak obuhvaća poduzimanje zaštitnih mjera koje će identificirani sigurnosni rizik svesti na prihvatljivu razinu, u skladu s ciljevima organizacije.

Proces upravljanja sigurnosnim rizicima sastoji se od tri faze:

– procjena rizika (engl. Risk Assessment);

– umanjivanje rizika (engl. Risk Mitigation);

– ispitivanje i analiza (engl. Evaluation and Assessment).

5.1 Procjena rizika

Cjelokupan proces upravljanja sigurnosnim rizikom uključuje identifikaciju, analizu i uklanjanje rizika, kao i njegovo periodičko ispitivanje i evaluaciju, dok je faza procjene rizika vezana isključivo uz konkretno određivanje sigurnosnog rizika, vezanog uz pojedini resurs. Detaljna analiza svih prijetnji i ranjivosti, vjerojatnosti realizacije rizika i mogućih posljedica, kao i analiza troškova/dobiti (engl. cost/benefit) sigurnosnih kontrola za uklanjanje rizika, postupci su uključeni u ovaj proces. Rezultati provedenog postupka procjene rizika redovito se koriste prilikom odluke na kojim će se mjestima i u kojoj mjeri rizik reducirati, a na kojim će se mjestima primijeniti druge tehnike upravljanja rizikom (ignoriranje, prebacivanje drugim organizacijama i sl.). Proces procjene rizika sastoji se od devet koraka; Identifikacija i klasifikacija resursa (engl. Asset Identification); Identifikacija prijetnji (engl. Threat identification); Identifikacija ranjivosti (engl. Vulnerability Identification); Analiza postojećih kontrola (engl. Control Analysis); Vjerojatnost pojave neželjenih događaja (engl. Likelihood Determination); Analiza posljedica (engl. Impact Analysis); Određivanje rizika (engl. Risk Determination); Preporuke za umanjivanje (engl. Control Recommendation); Dokumentacija (engl. Result Documentation) [12].

5.2 Umanjivanje rizika

Umanjivanje rizika druga je faza procesa upravljanja sigurnosnim rizikom, u kojoj se analiziraju, evaluiraju, a kasnije i implementiraju odgovarajuće sigurnosne kontrole. Rizik se umanjuje u onoj mjeri koja će zadovoljiti potrebe i ciljeve organizacije. Na koji će se način i u kojoj mjeri umanjivati rizik, donosi se na temelju detaljne evaluacije ponuđenih rješenja. Ideja je da se implementiraju ona rješenja koja su financijski najprihvatljivija, ona koja će rezultirati što kvalitetnijim i što pouzdanijim sigurnosnim kontrolama, s minimalnim utjecajem na misiju i poslovne procese organizacije.

Opcije za umanjivanje rizika

– Umanjivanje rizika – pristup koji podrazumijeva implementaciju odgovarajućih sigurnosnih kontrola s ciljem umanjivanja identificiranog sigurnosnog rizika.

– Transfer rizika – u ovom slučaju se rizik i troškovi u slučaju njegove realizacije prebacuje nekoj drugoj organizaciji (engl. outsourcing);

– Prihvaćanje rizika – postupak kojim se identificirani rizik prihvaća kao takav bez implementacije ikakvih sigurnosnih kontrola. Ukoliko cost/benefit analize pokažu da je veći trošak ulagati u zaštitu resursa, nego što predstavlja njegov gubitak, tada se primjenjuje ovaj pristup. Odluka o prihvaćanju rizika povlači veliku odgovornost, i redovito zahtjeva pismeno izvješće o tome tko je odgovoran i zašto kontrole nisu implementirane;

– Odbacivanje rizika – pristup koji podrazumijeva potpuno zanemarivanje sigurnosnog rizika. Opovrgavanje ili svjesno ignoriranje rizika u nadi da on nikada neće biti realiziran potpuno je neprihvatljiv pristup i ne smije se provoditi niti u jednom slučaju.

Rizik koji ostaje nakon implementacije sigurnosnih kontrola naziva se rezidualnim rizikom i on podrazumijeva sve one prijetnje i ranjivosti za koje se smatra da ne zahtijevaju dodatni tretman u pogledu umanjivanja postojećeg rizika. Prisutnost rezidualnog rizika posljedica je provedenih cost/benefit analiza kojima je ustanovljeno da su troškovi zaštite veći od troškova u slučaju njegove realizacije [12].

5.3 Ispitivanje i analiza

Budući da su informacijski resursi podložni vrlo čestim promjenama, potreba za periodičkim analizama i evaluacijama neophodna je za održavanjem jednom postignute razine sigurnosti. Promjene u mrežnoj i računalnoj opremi, nadogradnja ili instalacija novih programskih paketa, promjene u ljudskom kadru i sl., sve su elementi koji utječu na sigurnosni rizik u informacijskim sustavima. Ukoliko se o ovakvim promjenama ne vodi dovoljno računa, sustav se vrlo brzo može dovesti u stanje koje predstavlja neprihvatljiv sigurnosni rizik za organizaciju i njene poslovne ciljeve. Koliko često će se provoditi proces procjene rizika ovisiti će primarno o dinamici promjena u organizaciji. Ukoliko je sustav izložen čestim promjenama, procjenu rizika poželjno je raditi češće [12].

__________________________________________________________________________________________________________________________

6. Evaluacija sustava

Zbog kompleksnosti informacijskih tehnologija sve je teže odlučiti zadovoljava li neki sustav određene kriterije i funkcionalnosti. Ovo je posebice naglašeno u polju IT sigurnosti. Iz ovih su razloga još krajem 70ih godina prošlog stoljeća pokrenute inicijative vlada mnogih država kako bi se utvrdile sheme, a posebice katalozi kriterija i evaluacijskih ustanova koje bi, kao neutralna strana, provodile sigurnosnu evaluaciju i certifikaciju IT proizvoda i sustava.Sigurnost se može evaluirati unutar posebnih sustava koji rade u poznatoj okolini, npr vojni infromacijski sustavi, kao i unutar proizvoda, koji se mogu proizvoditi za masovno tržište kao što su osobni sigurnosni alati. Certifikati se izdaju od strane nacionalnih agencija koje mogu ovlastiti evlauacije kao i izdavanja evaluacijskih izvještaja akreditiranim ustanovama (engl. Information technology security evaluation facilities, skraćeno ITSEF). Trošak evaluacije snosi sponzor evaluacije, koji je i najčešće i proizvođač objekta evaluacije.Iako postoje osnovane kritike o generalnoj nesigurnosti IT sustava kao i na neprikladan metrički pristup trenutnim evaluacijskim kriterijima, danšnji korisnici trebaju pomoć prilikom analize sigurnosnih alternativa na tržištu s obzirom na zahtjeve svojih sustava, te informacija koje treba zaštititi. Evaluacija i certifikacija od strane neutralne i nezavisne organizacije čini se kao najbolja solucija, a evaluacijski kriteriji način su za podizanje razine usporedivosti sigurnosnih certifikata. Korištenjem standardiziranih dokumentiranih evaluacijskih procedura i alata može doprinjeti pridržavanju četiriju osnovnih principa evaluacije; objektivnost, konzistentnost, ponovljivost i nepristranost.

a) Nepristranost: sve evaluacije moraju se provesti bez postojanja pristranosti evaluatora

b) Objektivnost: Rezultati svih testova moraju se doiti s minimumom subjektivnog suda ili mišljenja

c) Konzistentnost: Ponovnom evaluacijom istog TOE-a nad istom sigurnosnom metom istog ITSEF-a mora se doći do istih zaključaka i rezulata kao i prilikom prve evaluacije

d) Ponovljivost: Ponovnom evaluacijom istog TOE-a nad istom sigurnosnom metom različitog ITSEF-a mora se doći do istih zaključaka i rezulata kao i prvi ITSEF koji je proveo evaluaciju

Aspekti efikasnosti postupka, kao što je identifikacije ranjivosti, snaga mehanizama, te iskoristivost ranjivosti, poseban su tip problema jer u postupak evaluacije uvode subjektivne faktore kao što je iskustvo i intuicija. Subjektivnost se ne može do kraja isključiti iz procesa evaluacije. On zahtijeva umješanost strane s neovisnim pregledom nad evaluacijom kao što su Certifikacijske agencije, koje osiguravaju konzistentnost i usporedivost među rezultatima različitih ITSEF-a.Što je viša razina evaluacije i jačina mehanizama, korisnik može biti sigurniji u protumjere ugrađene u IT sustav proizvoda. Evaluacijska razina koju zahtijeva korisnik ovisi o prihvatljivoj razini poznatog rezidualnog rizika, i može se odrediti analizom rizika i prijetnji za specifičnu situaciju. Sustav ili dio sustava s višom evaluacijskom razinom skuplji su zbog toga što se prilikom razvoja i evaluacije mora provesti kompliciranije i skuplje testove [4].

Slika 6.1 Osnovni principi evaluacije

Nekoliko procesa pridonosi sigurnosti sustava. Slika 6.2 prikazuje idealiziran kontekst unutar kojeg se evaluacija i certifikacija sustava uključuju u njegov životni ciklus.

Slika 6.2 Procesi sigurnosne petlje životnog ciklusa sustava

Strelice na slici prikazuju kako jedan proces daje ulazne parametre za sljedeću fazu. Procesi mogu biti djelomice isprepleteni, a cijela sekvenca procesa bi trebala biti iterativna i beskonačna.

Prilikom evaluacijskog proces asustav se procijenjuje i testira s obzirom na zadane sigurnosne kriterije, a prilikom certifikacijskog procesa potvrđuje se valjdnanost rezultata evaluacije te jesu li se korektno primjenili evaluacijski kriteriji. U procesu akreditacije sustava potvrđuje se kako je korištenje sustava prihvatljivo unutar određene okoline, s namjenom za točno određenu primjenu.

Prilikom procesa sigurnog rada akreditiranog sustava, on se koristi prema odobrenim procedurama, no promijene u okolini mogu zahtijevati promijene u samom sustavu, što ga opet dovodi, ili samo njegov dio, do faze razvoja itd..[3].

6.1 Proces evaluacije

Postoji mnogo detalja u kojima se evaluacija nekog sustava razlikuje u različitim nacijama s obzirom na vlastitu nacionalnu shemu provođenja evaluacije. Razlikuju se zbog zakona o sigurnosti, nacionalne sigurnosti, nadležnosti različitih tijela... Kada se provodi kao komercionalna aktivnost, evaluacija postaje ovisna o ekonomskim uvijetima IT tržišta. Mora biti komercijalno isplativa i izvedena u odgovarajućem roku.

Evaluacija se može provoditi nakon razvojne faze TOE-a, a naziva se naknadna evaluacija (engl. Consecutive evaluation), ili paralelno s razvojem TOE – tekuća evaluacija (engl. Current evaluation).

Glavna razlika između ova da tipa evaluacije je dostupnost raznih dijelova i resursa TOE-a. Prilikom naknadne evaluacije svi su potrebni resursi dostupni od samog početka procesa, dok se tekuća evaluacija obavlja s ovisnošću o razvojnom procesu sustava ili proizvda. Jedna od prednosti tekuće evaluacije jest ta da naručitelj može brzo reagirati na probleme koji su otkriveni evaluacijom dijela sustava, no treba uzeti u obzir i moguća kašnjenja prilikom razvoja koja usporavaju i zaustavljaju cjelokupni proces.

Ponekad evaluatorima trebaju i radne verzije nekih dijelova sustava kao što je testna dokumentacije ili izvorni kod ili hardverski dizajn kako bi mogli procijeniti primjene stadnarada razvojnih programera.

Stupanj povjerenja koji se dobije evaluacijom ovisi o razini evaluacije i jačini mehanizama kojima se ona provodi. Što je viša razina evaluacije, povećava se količina relevantnih informacija koje se koriste ali i dobivaju, stoga je potreban je veći napor kako bi se došlo do valjane evaluacije . Tako se proces evaluacije može smatrati jedinstveno ali kompleksno mjerenje koje se provodi s stupnjem točnosti karakteriziran evaluacijskom razinom. Posljedica ovoga je ta da što se više mora osloniti na protumjere TOE-a, npr kako bi se rizik reducirao na prihvatljivu razinu, toliko mora biti viši evaluacijska razina i jačina mehanizama za provjeru [3].

6.1.1 Uključene strane

Ove su strane direktno uključene u proces evaluacije; sponzor evaluacije, developeri IT sustava, ITSEF, te certifikacijsko tijelo ili agencija (engl. Certification Body, skraćeno CB).

Uloga ITSEF-a jest da obavlja evaluaciju sustava po uzoru na nacionalnu shemu i prema standardiziranim kriterijima kao neovisna organizacija. Unutar ITSEF-a, uloga evaluatora jest izvođenje detaljnog i nepristranog pregleda objekta evaluacije, pronaći njegove ranjivosti, te utvrditi do koje su mjere sigurnosni ciljevi TOE-a zadovoljeni njegovom implementacijom. Evaluatori su odgovorni za detaljno dokumentiranje svih obavljenih provjera prilikom evaluacije, krajnji evauacijski izvještaj.

Sponzor evaluacije najčešće jest distributer objekta evaluacije (engl. Target of Evaluation, skraćeno TOE), rijeđe korisnik ili konstruktor koji žele dokazati kako TOE zadovoljava sve zadane sigurnosne ciljeve. Sponzor je taj koji povjerava evaluaciju TOE-a određenom ITSEF-u, definira sigurnosne ciljeve koje bi TOE trebao ispunjavati, te prima Evaluacijski izvještaj, a kasnije i certifikat. Izraz developer koristi se kao referenca na organizaciju koja razvija TOE ili njegove dijelove. Ukoliko developer nije i sponzor, mora se uključiti u proces evaluacije time da ITSEF-u dostavi sve tražene informacije i dokumentaciju nastalu prilikom razvoja TOE-a.

Certifikacijska agencija kao glavne ciljeve postavlja:

· Stvoriti uvjete pod kojima bi rad svih ITSEF-a koji rade po istoj shemi evaluacijskog procesa bio precizan i konzistentan, a njihovi zaključci valjani, ponovljivi i konzistentni.

· Pružati neovisnu potvrdu kako je evaluacija provedena u sukladnosti s odobrenim kriterijima i standardima, metodama i procedurama.

6.1.2 Faze evaluacijskog procesa

Evaluacijski proces obično se dijeli u 3 faze; priremnu, izvršnu i završnu fazu. U praksi postoji mnogo opcija i alternativnih putova, pogotovo ako se evaluacije provodi paralelno prilikom razvoja sustava.

Faza 1-Pripremna faza

Prva ili pripremna faza uključuje inicijalni kontakt između sponzora i ITSEF-a, studiju izvedivosti evaluacije, kako i pripreme za evlauaciju. Studija izvedivosti nije nužna, no preporuča se sponzorima i developerima bez prijašnjeg iskustva u evaluaciji. Ovom se studijom dobije kompetan uvid sigurnosni objekt u pitanju. Kada se ustanovi kako je uspješna evaluacija moguća, sastavlja se lista potrebnih resursa koji trebaju biti dostupni evaluatorima prilikom evaluacije. Ova faza uključuje i potpisivanje ugovora među naručiteljem i ITSEF-om, koji uzima u obzir nacionalne regulative kao i kaluzulu o tajnosti ii neotkrivanju.

Sponzor dostavlja ITSEF-u sigurnosne ciljeve (engl. Security Targets) za TOE, te definira opseg procesa evaluacije. ITSEF procjenjuje vjerojatnost uspješne evaluacije, koristeći relevantne informacije o TOE-u. Ukoliko ITSEF nije zadovoljan prilikom preliminarne procjene, preispituje sigurnosne ciljeve te savjetuje sponzora koje su potrebne promijene kako bi se omogućila precizna evaluacija.

Evaluacijski radni tijek za specifični TOE ovisi o resursima koji su dostupni evaluatorima, te kriterijima po kojima se provodi sama evaluacija koja ovisi od institucije do institucije, te o državi u kojoj se provodi evaluacija. Zacrtan se posao podijelu u evaluacijske aktivnosti koje evaluatori trebaju obaviti u zadanom vremenu. Zadatak razvoja evaluacijskog radnog programa sličan je planiranju razvoja softverskog životnog ciklusa.

Faza 2- Izvršna faza

Druga ili izvršna faza predstavlja glavni dio evaluacijskog procesa. Evaluatori izvode evaluatorske zadatke definirane kriterijima provedbe evaluacje ITSEF organizacije za koju rade. Ova faza uključuje ispitivanja sigurnosti sustava, te se kao rezultat istih priprema evaluacijski tehnički izvještaj (engl. Evaluation Technical Report, skraćeno ETR).

Evaluatori sastave listu potencijalnih ranjivosti. Problemi koji se identificiraju mogu se svrstati u dvije skupine; oni koje sponzori mogu otkloniti u odgovarajućem vremenu i uz suglasnost ITSEF-a, te oni koje sponzor ne može, odnosno ne želi riještiti. Ukoliko spadaju u ovu drugu skupinu, proces evaluacije se najčešće prekida.

Faza 3- Završna faza

U Trećoj ili završnoj fazi ITSEF dostavlja završnu verziju ETR-a sponzoru/naručitelju evaluacije, kao i Certifikacijskoj agenciji, kojoj će ovaj izvještaj poslužiti kao baza za certifikacijski proces. Kako ETR sadrži osjetljive informacije, on nesmije biti javno dostupan dokument, te mora biti podležan pravilima nacionalne sheme države u kojoj se provodi evaluacija. ETR veoma je koristan prilikom re-evaluacije TOE-a.

6.1.3 Razumijevanje TOE

Evaluacjia se sastoji od kombinacije teorije, eksperimenata i promatranja. Razumijevanje TOE-a prvi je preduvijet kvalitetne evaluacije. To se razumijevanje stiče procjenom sigurnosnih ciljeva i drugih resursa i dijelova sustava s obziroma na kriterije korektnog ponašnja proizvoda/sustava, tj može li se TOE ponašati na bilo koji drugačiji način osim onog definiranog u zahtjevima sigurnosnih ciljeva, jeli TOE ranjiv na očekivane prijetnje.

Općenito objekti evaluacije previše su kompleksni kako bi se samo ispitivanjem provjerilo zadovoljavaju li svoje sigurnosne ciljeve. Tako da se dio evaluacije obavlja analizom dokumentacije o konstrukciji i funkcionalnosti sustava/proizvoda, stoga nikada ne možemo biti u potpunosti sigurni, već samo s povećanom vjerojatnošću tvrditi kako TOE zadovoljava svoje sigurnosne zahtjeve. Dobro dokumentirani sustavi/proizvodi, pisani u programima i razvojnim okolinama s dobro definiranom sintaksom uvelike olakšavaju posao evaluatorima.

6.1.4 Sigurnosne zadaće, resursi i prijetnje

Sigurnosni ciljevi specificiraju sigurnosne zadaće TOE-a, povezujući prijetnje i resurse s svakom pretpostavljenom funkcionalnošću. Sigurnosni ciljevi enumeriraju prijetnje u ispitivanom sustavu, kao i resurse koje bi TOE trebao štititi. Poželjno je da prijetnje i resursi budu identificirani prije evaluacije, od strane developera kako bi evaluatori mogli provjeriti jesu li liste prijetnji i reusrsa konzistentne s sigurnosnim funkcijama i zadaćama individualnih lista. Sigurnosni ciljevi identificiraju protumjere (engl. Countermesures), koje se implementiraju za zaštitu resursa od raznih prijetnji, kako bi zadovoljili određene sigurnosne zahtjeve. Sigurnosni zahtjevi identificiraju pojedine ciljeve koje svaka protumjera mora zadovoljiti, npr. TOE koristi identifikacijske i autorizacijske funkcije kako bi se utvrdio identitet korisnika koji želi pristupiti sustavu ili koristiti proizvod . Određene se prijetnje i resursi teže specifciraju u sigurnosnim ciljevima IT proizvoda, nego sustava. Rezultati evaluacije proizvoda mogu se puno bolje koristiti kada treba procijeniti od strane kupca kako taj proizvod može zaštititi njihove stvarne resurse koristeći svoje proutmjere.

6.1.5 Korektnost i efikasnost

Prilikom evaluacije treba odgovoriti na dva važna pitanja:

a) Prikazuju li za to zaduženi dijelovi sustava da TOE korektno implementira sigurnosne ciljeve?

b) Jesu li sigurnosne mjere implementirane u TOE-u efektivne protiv identificiranih prijetnji, i jesu li lišene iskoristivih ranjivosti?

Korektnost se bavi sljedećim:

a) Postoji li adekvatan opis funkcija koje provode sigurnost u sigurnosnim ciljevima, i pružaju li djelovi sustava dokaze kako se te funkcije korektno implementiraju u TOE

b) Jesu li razvojni programeri sljedili discipliniran razvojni program, takav da se primjerena razina povjerenja može uspostaviti u detaljnost i točnost opisane funkcije na jednoj razini apstrakcije da on bude korektan da se totalni efekti opisani na nižim razinama barem nadziru na višim razinama apstrakcije.

Efikasnost je potrebno promatrati kao listu koja sadrži različite aspekte na kojima TOE može podbaciti.:

a) Jesu li funkcije koje provode sigurnost sposobe zaštititi određeni resurs od prijetnji specificiranih u sigurnosnim ciljevima (primjerenost funkcionalnosti)

b) Je li dizajn takav da, kada bi se provela korektna implementacije individualnih funkcija koje provode sigurnost, TOE bi bio siguran kao cjelina. (Povezanost funkcionalnosti)

c) Ima li TOE kao cjelina u svojoj radnoj okolini iskoristvih ranjivosti?

6.1.6 Komponente, funkcije i mehanizmi

TOE se sastoji od komponenti, koje su i same sastavljene od drugih komponenti, itd dok se sustav ne rastavi na osnovne komponente. Komponenta može implementirati više od jedne funkcije. U slučaju osnovne komponente, oni djelovi koji sadrže implementaciju svake funkcije nazivaju se funkcionalne jedinice. Važno je da se sigurnosne funkcije identificiraju kako bi se mogle mapirati u sigurnosnim ciljevima na svim razinama apstrakcije prilikom evaluacije. Logika algoritma koji implementira funkcija naziva se mehanizam.

Funkcije se dijele na važne i nevažne za provođenje sigurnosti. Ukoliko ispunjenje sigurnosnog cilja ne ovisi o specifičnoj funkciju, ona se smatra nevažnom.

6.1.7 Iskoristive ranjivosti

Postoji više načina kako bi se onemogućila određena protumjera, neki su jednostavniji od drugih. Obično napadač mora onemogućiti više od jednog zaštitnog mehanizma kako bi izveo uspješan napad na TOE. Razvojni programeri predviđaju načine na koje bi TOE moga biti napadnut te sukladno s time odabiru zaštine mjere. Evaluatori nezavisno istražuju TOE s gledišta napadača kako bi otkrili način na koji bi se kompromitirala neka zaštitna mjera. Uspješan napad otkriva iskoristivu ranjivost, no nekad nije nti potrebno provoditi ispitivanje, ako je samo teoretska analiza dovoljna za utvrđivanje iskoristive ranjivosti.

Evaluatori završavaju nezavisnu analizu provođenjem penetracijskih testiranja kako bi se provjerilo jeli neka potencijalna ranjivost zaista iskoristiva.

6.1.8 Krajnji rezultati

TOE uspiješno prolazi evaluaciju samo ako dobije prolazne ocjene za sve kriterije efikasnosti i korektnosti za ciljanu evaluacijsku razinu. Ovo implicira kako u završnoj fazi evaluacije ne postoji niti jedna iskoristiva ranjivost u funkcionalnosti TOE-a, te kako je zadovoljena minimalna razina jačine mehanizama za provedbu sigurnosnih zahtjeva. Evaluacija ne prolazi ako postoji makar jedan kriterij korektnosti ili efikasnosti koji nije zadovoljen, ili ako se otkrije neka iskoristiva ranjivost.

Evaluatori svoje nalaze uspoređuju s tvrdnjama proizvođača, te ako je njihova dokumentacija nepotpuna, ili pogrešna TOE ne prolazi evaluaciju dok se pogreške ne isprave.

6.1.9 Re-evaluacija i ponovno korištenje evaluacijskih rezultata

Kada se neki IT proivod ili sustav evaluira i certificira, certifikat/certifikacijski izvještaj se može odnostiti i primijeniti samo za evaluiranu verziju i konfiguraciju istog. Vjerojatno je kako će se sigurnosni zahtjevi kao i sami evaluirani proizvodi i sustavi promijeniti s vremenom i situacijama. Iz ove činjenice proizlazi poteba za re-evaluacijom proizvoda ili sustava. Primjeri promijene TOE-a su npr povećanje razine evaluacije ili dodavanje funkcija koje provode sigurnost.

Ponovno korištenje evaluacijskih rezultata prilikom re evaluacije smanjuje vrijeme i količinu rada, gdje rezultati originalne evaluacije mogu ali i ne moraju biti valjane u kontekstu re evaluacije TOE-a.

6.2 Evaluacijske tehnike i alati

Tehnički ekvivalenti rezultata evaluacije podržani su kada se koriste standardne procedure uključujući korištenje primjerenih evaluacijskih tehnologija. Tijekom evaluacijskog procesa evaluatori mogu koristiti alate i tehnike kojima ostvaruju najbolji omjer cijene i preformansi, te najkraće potrebno vrijeme. Korištenjem takvih tehnika pomaže pri ostvarivanju objektivnosti, konzistentnosti, te ponovljivosti [3].

Osnovne evaluacijske tehnike:

· Neformalan pregled (engl. Informal Examination)- najjednostavnija evaluatorska tehinka koja se bazira na proučavanju dokumentacije

· Complianyc analysis- metodičnija tehnika koja se koristi za provjeru dvije prezentacije konzistentnosti; za svaku komponentu više razine provjerava je li implementirana korektno i na nižoj razini, te za svaku komponentu niže razine provjerava u višim razinama je li njeno postojanje opravdano

· Analiza sljedljivosti (engl. Traceabitity analysis)- koristi se za opis pojma korektnog usavršavanja funkcija koje provode sigurnost kroz reprezentacije TOE-a, do krajnje implementacije u formi izvršnih kodova i električnih krugova. Provjerama jesu li funkcije koje provode sigurnost sigurnosnih ciljeva pravilno usklađene kroz arhitekturni dizajn, implementaciju i funkcionalnost TOE-a, evaluatori povećavaju povjerenje u ispitivani objekt. Dakle, osnovna tehnika evaluacije jest praćenje sigurnosnih funkcija kroz razne reprezentcije TOE-a, sve do i uključujući sveukupne funkcionalnosti TOE-a.

6.2.1 Alati za evaluaciju

· Animacijski alati – obično se koriste u ranim fazama razvoja TOE-a, kako bi se provjerilie reprezentacije visoke razine kao što su sigurnosni ciljevi. Ovi se alati najčešće koriste kako bi se izvršila formalna specifikacija ikako bi se provjerila svojstva te razine reprezentacije.

· CASE alati- oni se kriste za dobivanje detaljnog dizajna sustava, a evaluatori ih koriste za detaljnu validacju dizajna, pomoću validacijskih opcija koje alat posjeduje. Neke od pogrešaka koje se mogu pronaći koristeći ove metode su; tok podataka koji nije konzistentan imeđu dijagramima različitih razina hijerarhije dizajna, podatke koji se generiraju ali ih nikada ne koriste procesi, postojanje referenci na nedefiniranim objektima.

· Alati za detaljnu provjeru dizajna mogu provjeravati kako semantički i sintaktički source kod odgovara specifikacijama, izvode provjere korektnosti na sintaksnoj (kompletnost, koherencija) ili semantičkoj razini, stvaraju poveznice između funkcija i specifikacija, proučavaju tijek podataka...

· Alati za analizu source koda provjeravaju nepravilno korištenje podataka, beskonačne petlje, nedohvatljive dijelove koda, neželjene ovisnosti podataka, funkcionalnost koda s formalnom specifikacijom.

· Alati za analizu hardvera- pomoću CAD (engl. Computer Aided Design)alata

· Audit i alati za provjeru konfiguracije [3]

__________________________________________________________________________________________________________________________

7. Ispitivanje jednostavnog audit alata

Brz i jeftin način ispitivanja sigurnosti računalnog sustava pretstavljaju web zasnovani audit alati. Brojne tvrtke pružaju ovu uslugu, a koliko su pouzdani teško je procijeniti, no za osobna računala sasvim su dovoljni. Veoma su praktični jer se veoma brzo može doći do popisa potencijalnih ranjivosti, kao i mjesta gdje možemo pronaći odgovarajuće zakrpe za njih. Jedan od takvih alata je i Belarc Advisor audit tool. Većim se i kopleksnijim sustavima preporučuje cjeloviti audit.

BelarvAdvisor gradi detaljan profil instaliranog softvera i hardvera, uključijući i primjenjene zakrpe i serijske brojeve softvera, te prikazuje rezultate u web pregledniku. Sve se informacije PC profila čuvaju privatno na računalu, i ne šalju web poslužiteljima.

Slika 7.1 Belarc Advisor izvještaj

Aplikacija analizira slabe točke računala, pritom provjeravajući elemente kao što su aktualizacije antivirusnih definicija, jesu li sve dostupne zakrpe primjenjene... Koristi CIS bentchmark testove kako bi ocjenio stanje računala i time prikazao cjelovitu sigurnosnu razinu računala. Ovaj alat ne analizira samo softver i komponente operacijskog sustava, njegov detaljan izvještaj sadržava i popis fizičkih komponenti; npr. ne samo koliko je RAM memorije ugrađeno u računalo, već i koje je vrste i koje slotove zauzima.

Ovaj program ne riješava pronađene probleme, ali predlaže kako se najbolje pozabaviti njima.

Izvještaj započinje s osnovnim podacima kao što su proizviđač računala, instalirani RAM, veličina hard diska, tip i brzina procesora. Ali isto tako prikazuje proizvođača matične ploče, i hard diska, serijski broj šasije, tip i brzinu sabirnice, multimedijske komponente...te još mnogo toga. U izvještaju se nalaze i detalji o Windows instalaciji, uključujući i koje su zakrpe instalirane, a koje nam nedostaju, kao i listu korisničkih računa računala...

Ovim alatom dobivamo pregledan izvještaj o memorijskim modulima, lokalnim diskovnim jedinicama, pisačima, instaliranim licencama, instaliranom softveru, multimadijske informacije, anti virusni status... Izvještaj se može sačuvati, ili ponovo generirati po potrebi.

Veličina Belarc Advisor-a je 1519KB, a rađen je za sljedeće operacijske sustave: Windows Vista, 2003, XP, 2000, NT, ME, 98 i 95. Zahtijeva Internet Explorer ili Netscape verzije 3 ili više, Opera, Mozilla i Firefox također.

Sve u svemu, ovo je zanimljiv i jednostavan audit alat, jednostavan za uporabu, te predstavlaj brz i jeftin način skeniranja računala, koji pritom izgrađuje detaljan profil instalirnaog hardvera i softvera. Veoma je jednostavan za korištenje, po završetku instalacije i prihvaćanja licence, jednim klikom dođe se do rezultata.

Alat je dostupan na [11].

__________________________________________________________________________________________________________________________

8. Zaključak

Evaluacija je skup i dugotrajan proces, a sponzori evaluacija za uzvrat ne moraju nužno dobiti sigurniji proizvod. Evaluacijom se najčešće fokusiraju na evaluiranje dokumentacije, a ne tehničke korektnosti ili zasluge samog proizvoda. Prilikom pripreme evaluacijskih dokaza i ostale dokumentacije vezane za evaluaciju vrijeme i trud koji se ulože golemi su, a nekada, ovisno o veličini TOE-a, proizvod može zastarit dok se proces završi. Još jedan problem evaluacije je taj kako se sustav evaluira za točno određenu konfiguraciju, i određene uvjete rada i okoline.

Zajednički kriterij za sigurnosnu evaluaciju informacijskih tehnologija (engl. Common Criteria for Information Technology Security Evaluation, skraćeno Common Criteria ili CC) predstavlja internacionalnu normu (ISO/IEC 15408)[9] za računalnu sigurnost. Certifikacija Zajedničkim kriterijem donekle je ograničena samo na IT alate. Dok se druge norme kao što je npr. ISO/IEC 27002[10] bave i međudjelovanjem, upravljanjem sustavom, treniranjem korisnika, sigurnosnim politikama.

Ako proizvod dobije certifikat Zajedničkog Kriterija ili nekog kriterija sličnog njemu, to nužno ne znači kako je on kompletno siguran. Na primjer Microsoft Windows 2000 cetrificiran je produkt razine EAL4+, ali regularno su izlazile nove sigurnosne zakrpe za otkrivene ranjivosti. Ovo je moguće jer proces dobivanja ceritfikata dopušta sponzoru evaluacije neke pretpostavke o operacijskom okruženju proizvda kao i jačini prijetnji s kojima se proizvod susreće u tom okruženju. Na tim se pretpostavkama evaluiraju sigurnosne funkcije proizvoda. Kako je MS windows 2000 dobio certifikat EAL4+, trebao bi se smatrati sigurnim samo u pretpostavljenom okruženju i okolnostima koje su se pretpostavljale prilikom evaluacije. Kada bi bilo koja od ovih sigurnosnih ranjivosti bila iskoristiva u evaluirenoj konfiguraciji proizvoda, certifikat bi trebalo povuči, ili sponzor može naručiti re- evaluaciju proizvoda kako bi se uključile zakrpe koje riješavaju pronađene ranjivosti unutar evaluirane konfiguracije, a ukoliko to ne učini ukida se cerifikat nad tim prozvodom.

MS Windows 2000 ostaje EAL4+ bez uključenja aplikacije bilo kojih sigurnosnih zakrpa na svoju evaluiranu konfiguraciju, što pokazuje limitacije kao i snagu evaluirane konfiguracije [7].

Generalni principi informacijske sigurnosti trebali bi biti jednostavnost; sigurnosni mehanizmi, kao i sami sustavi trebali bi biti što jednostavniji, kompleksnost je uvijek korijen mnogih sigurnosnih pitanja i problema; sigurnost sustava nesmije ovisiti o tajnosti njegove implementacije ili komponenti. Nadalje, kada se dogodi ispadanje sustava, sigurnosne mjere trebale bi još uvijek funkcionirati. Uvjek je dobro što je moguće više odvojiti funkcionalnosti sustava kao i uloge korisnika, sistemskih i sigurnosnih administratora.

Korisnici sustava bi trebali shvaćati potrebu sigurnog sustava, no sigurnosne postavke bi isto tako trebale omogućavati korisnicima da nesmetano obavljaju svoje svakodnevne zadatke. Ukoliko korisnici smatraju da su sigurnosni zahtjevi previše ograničavajući, uvijek će pronaći način da ih zaobiđu ili kompromitiraju (npr. zapisuju digačke i jake lozinke na lako vidljivim i javno dostupnim mjestima). Primjena samo jednog sigurnosnog mehanizma općenito je nedovoljno. Sigurnosni mehanizmi moraju biti slojeviti tako da kompromitiranje jednog sigurnosnog mehanizma ne dovodi do komprimitiranja cijelog sustava. Kada je sustav kompromitiran treba dokumentirati događaj jer prikupljene informacije mogu pomoći pri identifikaciji metoda i exploita koje je koristio napadač, te prilikom poboljšanja sigurnosti sustava, kao i za otkrivanje i kaznenog gonjenja počinitelja. No čak i uz sve ove mjere opreza, nitko ne može garantirati kako će sustav biti stopostotno siguran, stoga jedino što možemo učiniti jest ispitivati najizloženije točke sustava, provjeravati jesu li virusne definicije ažurirane, a zaštitne stijene dobro konfigurirane. J

__________________________________________________________________________________________________________________________

Jump to: navigation, search

9. Literatura

[1] Guideline on Network Security Testing , NIST Special Publication 800-42, October 2003

[2] Network Security Bible, Dr. Eric Cole, Dr. Ronald Krutz, and James W. Conely, lWiley Publishing Inc

[3] Information Technology Security Evaluation Manual,Version 1.0, ECSC-EEC-EAEC, Brussels - Luxembourg 1992, 1993.

[4] Recent Development in Information Technology Security Evaluation – The Need for Evaluation Criteria for multilateral Security, Kai Rannenberg, Department for Telematics, Institute for Informatics and Society, University of Freiburg, Germany

[5] FIPS Publication 199, Information and Information System Security Categorization Standard, December 2003

[6] Sigurnosni audit računala; http://en.wikipedia.org/wiki/Computer_security_audit, srpanj 2008.

[7] Zajednički kriterij; http://en.wikipedia.org/wiki/Common_Criteria, srpanj 2008

[8] Sigurnosni audit, pren testiranja, provjera ranjivosti;shttp://www.isp-planet.com/technology/2004/security_toolkit_intro.html, srpanj 2008.

[9] ISO 15408 norma; http://www.clusit.it/whitepapers/iso15408-1.pdf, srpanj 2008.

[10] ISO_17799 norma; http://en.wikipedia.org/wiki/ISO_17799, srpanj 2008.

[11] Belarc audit alat; http://www.belarc.com/free_download.html, srpanj 2008.

[12] Risk Management Guide for Information Technology Systems, NIST Special Publication 800-30, October 2001.