Temu preuzeli: Igor Trgovčić, Marina Marković, Marija Gelo

Sadržaj 1 Uvod 2 Metodologija odgovaranja na incidente 2.1 Priprema prije incidenta 2.1.1 Priprema organizacije 2.1.2 Priprema CSIRT-a 2.2 Otkrivanje incidenta 2.3 Inicijalni odgovor 2.4 Oblikovanje strategije odgovora 2.4.1 Pravne akcije 2.4.2 Administrativne akcije 2.5 Istraživanje incidenta 2.5.1 Prikupljanje podataka 2.5.1.1 Poslužiteljske informacije 2.5.1.2 Mrežni dokazi 2.5.1.3 Ostali dokazi 2.5.2 Forenzička analiza 2.6 Izvještavanje 2.7 Odlučivanje 3 Priprema za odgovaranje na incident 3.1 Identificiranje rizika 3.2 Priprema pojedinih poslužitelja 3.2.1 Snimiti kriptirane kontrolne zbrojeve (engl. checksum) najvažnijih datoteka 3.2.1.1 Korištenje MD5 algoritma za stvaranje kontrolnih zbrojeva 3.3 Povećati ili omogućiti sigurnu reviziju dnevničkih zapisa 3.4 Izrada zaštite središnjeg računala 3.5 Sigurnosna kopija kritičnih podataka 3.5.1 Unix alati 3.5.2 Windows alati 3.5.3 Razumijevanje ograničenja sigurnosnih kopija 3.6 Edukacija korisnika o sigurnosti središnjih računala 4 Priprema mreže 4.1 Instaliranje vatrozida i sustava za detekciju upada 4.2 Korištenje kontrolne liste pristupa na ruterima 4.3 Kreiranje topologije potrebne za nadgledanje 4.4 Enkripcija mrežnog prometa 4.5 Zahtijevanje autentifikacije 4.5.1 Specifičnosti vezane uz neovlašteni pristup 5 Utemeljenje prikladnih politika i procedura 5.1 Određivanje stava odgovora 5.1.1 Razmatranje poslovnih pitanja 5.1.2 Razmatranje zakonskih pitanja 5.1.3 Razmatranje političkih pitanja 5.1.4 Razmatranje tehničkih mogućnosti 5.1.5 Specifičnosti vezane uz DoS napad 5.2 Razumijevanje kako politike mogu pomoći koracima istrage 5.3 Razvoj politika prihvatljivih načina uporabe 5.4 Dizajniranje politika prihvatljivih načina uporabe 5.4.1 Dizajniranje od vrha prema dolje (Top down) 5.4.2 Kreiranje pojedinačnih politika 5.5 Razvoj procedura za odgovor na incidente 6 Kreiranje programskog alata za odgovaranje 7 Osnivanje tima za odgovor na incident 7.1 Odlučivanje o misiji tima 7.2 Obuka tima 8 Nakon otkrivanja incidenta 8.1 Pregled faze početnog odgovora 8.1.1 Dobivanje preliminarne informacije 8.1.2 Dokumentranje koraka koje treba poduzeti 8.1.3 Uspostavljanje procedure bilježenja incidenta 8.2 Zapisivanje detalja nakon početne detekcije 8.2.1 Checkliste za početni odgovor 8.2.2 Bilješke o slučaju 8.3 Deklaracija incidenta 8.4 Sastavljanje tima računalne sigurnosti za odgovaranje na incident(CSIRT) 8.4.1 Određivanje postupaka eskalacije 8.4.2 Provedba obavještavanja 8.4.3 Opseg incidenta i sastavljanje resusra, uključujući i dodjeljivanje vođe tima i tehničkog osoblja 8.4.4 Dodjela vođe tima 8.4.5 Dodjela tehničkog osoblja 8.5 Izvođenje standardnih istražnih koraka 8.6 Vođenje intervjua 8.6.1 Dobivanje kontakt informacija 8.6.2 Intervjuiranje administratora sustava 8.6.3 Intervjuiranje menadžera 8.6.4 Intervjuiranje krajnjih korisnika 8.7 Izrada strategije odgovora 8.7.1 Razmatranja o strategiji odgovora 8.7.2 Politika provjere 9 CERT organizacije 9.1 Tipovi CSIRT organizacija 9.2 Registar hrvatskih CERT-ova 9.2.1 CARNet CERT 9.2.2 Nacionalni CERT 9.2.3 ZSIS CERT 10 Zanimljivosti 11 Usporedba alata za dohvaćanje obrisanih podataka 11.1 eSupport UndeletePlus 11.2 Pandora Recovery 11.3 Recuva 11.4 Rezultati 12 Alati za sigurnost društvenih mreža 12.1 Bitdefender Safego 12.2 Facebook Privacy Scanner 13 Zaključak 14 Literatura

Uvod

Računalni sigurnosni incident je bilo koji nezakonit, neautoriziran ili neprihvatljiva akcija koja uključuje računalni sustav ili mrežu. Takva akcija može uključivati bilo koji od slijedećih događaja:

• Krađu ili razmjenu tajni
• E-mail spam ili dosađivanje
• Neautoriziran ili nezakonit upad u računalni sustav
• Pronevjera
• Posjed ili širenje dječje pornografije
• DoS napadi
• Iznuda
• Bilo koja nezakonita akcija kada se dokazi za takvu akciju mogu pohraniti na računalni medij poput prevare, prijetnji i tradicionalnih zločina

„Sigurnosni incident je čin narušavanja propisanih ili podrazumijevanih sigurnosnih normi. Kako bi određenu aktivnost mogli proglasiti incidentom bitno je da se radi o ciljanoj ilegalnoj aktivnosti. “ [CARNet CERT, str. 5]. Incidente možemo podijeliti u dvije skupine i to prema vrsti i težini incidenta, kao što je prikazano na Slici 1.

Važan dio IT-a je odgovor na sigurnosne incidente, te kako bi ograničili djelovanje napadača potrebno je ustanoviti postupak za njihovo rješavanje. Broj incidenata može se smanjiti, ali ne mogu se svi spriječiti. Zbog toga organizacija mora biti sposobna nositi se sa sigurnosnim incidentima. U tu svrhu osnivaju se timovi za brzo otkrivanje i rješavanje incidenata te saniranje nastale štete. Ti timovi su obično dio CERT-a (eng. Computer Emergency Response Team) - organizacije zadužene za pružanje potpore u slučaju narušavanja sigurnosti neke tvrtke ili organizacije.

--Marina Marković 6. siječnja 2012. (CET)

Metodologija odgovaranja na incidente

Sigurnosni incidenti su često kompleksni problemi te kao sa svakim kompleksnim inženjerskim problemom, koristimo pristup „crne kutije“. Podijelimo veći problem odgovora na incident na komponente i ispitamo ulaze i izlaze svake komponente. Slika 2. prikazuje pristup odgovoru na incidente. Metodologija odgovora se sastoji od 7 koraka:

1. Priprema prije nego što se incident dogodi – poduzeti akcije pripreme organizacije i CSIRT-a prije nego se incident dogodi
2. Detekcija incidenata – identificirati potencijalne računalno sigurnosne incidente
3. Inicijalni odgovor – provesti inicijalnu istragu, snimajući glavne detalje koji okružuju incident, okupljanje tima za odgovor na incidente i obavještavanje onih osoba koje trebaju znati o incidentu
4. Oblikovati strategiju odgovora na incidente - odrediti najbolji odgovor na temelju rezultata svih poznatih činjenica i dobiti pristanak menadžmenta. Odrediti koje civilne, kriminalne, administrativne i druge akcije je primjereno poduzeti, temeljeno na zaključcima istrage.
5. Istražiti incident – obaviti detaljno sakupljanje podataka. Pregledati sakupljene podatke, odrediti što se dogodilo, kada se dogodilo, tko je to učinio i kako spriječiti da se to ne dogodi u budućnosti.
6. Izvještavanje – točno informacijsko izvješće o rezultatima istrage na način da bude korisno donositeljima odluka.
7. Donošenje odluka - mjere za sigurnost zaposlenika i proceduralne promjene, evidentiranje naučenih lekcija, razvoj dugoročnih popravaka za identificirane probleme

Priprema prije incidenta

Priprema vodi uspješnom odgovaranju na incidente. Tijekom ove faze, organizacija treba pripremiti samu sebe kao cjelinu kao i članove CSIRT-a, prije nego se računalni sigurnosni incident dogodi. Pripreme uključuju proaktivne mjere koje CSIRT može poduzeti kako bi osigurao da su organizacijska imovina i informacije zaštićene. Idealno gledajući, pripreme uključuju ne samo nabavu alata i razvojnih tehnika za odgovor na incidente, već i poduzimanje akcija na sustavu i mreži koji su dio incidenta koji će biti potrebno istražiti.

Priprema organizacije

Priprema organizacije uključuje razvoj organizacijskih strategija koje će omogućiti bolji stav organizacije prilikom odgovaranja na incidente. To uključuje poduzimanje sljedećih koraka:

• Implementacija sigurnosnih mjera na poslužitelju
• Implementacija mrežnih sigurnosnih mjera
• Obučavanje krajnjih korisnika
• Upotreba sustava za otkrivanje napada (IDS, engl. Intrusion detection system )
• Stvaranje stroge kontrole pristupa
• Obavljanje pravodobnih procjena ranjivosti
• Redovito obavljanje sigurnosnog kopiranja podataka

Priprema CSIRT-a

CSIRT treba biti definiran u fazi pripreme organizacije prije nego se incident dogodi. Organizacija treba okupiti tim stručnjaka koji će se znati nositi s mogućim incidentima. Priprema CSIRT-a uključuje sljedeće:

• Hardver potreban za ispitivanje računalno sigurnosnih incidenata
• Softver potreban za ispitivanje računalno sigurnosnih incidenata
• Dokumentacija (obrasci i izvješća) potrebna za ispitivanje računalno sigurnosnih incidenata
• Odgovarajuće politike i operativne procedure za implementaciju strategije odgovora na incidente
• Obučavanje osoblja i zaposlenika da odgovaraju na incidente na način koji potpomaže uspješnoj forenzici, istrazi i oporavku

Pri odgovaranju na incidente, ne možemo si dopustiti nepotrebna odgađanja i zato se osnovni resursi trebaju prikupiti prije nego se incident dogodi.

--Marina Marković 6. siječnja 2012. (CET)

Otkrivanje incidenta

Faza otkrivanja incidenata je jedna od najvažnijih u vidu odgovaranja na incidente. To je također jedna od najviše decentraliziranih faza, u kojoj oni s najvećom stručnošću imaju najmanje kontrole. Incident se obično otkrije kada netko posumnja da se dogodio neautorizirani, neprihvatljiv ili nezakonit događaj u organizacijskoj računalnoj mreži ili u opremi za obradu podataka.

Incident može biti prijavljen od strane krajnjeg korisnika, otkriven od strane administratora, pomoću IDS upozorenje i sl. U većini organizacija, krajnji korisnici mogu prijaviti incident na 3 načina:

1. njihovom neposrednom nadzorniku
2. odjelu za pomoć (ili lokalnom odjelu za informacijsku tehnologiju ako ne postoji službeni odjel za pomoć)
3. liniji za incidente koju vodi objekt za informacijsku sigurnost

Bez obzira na koji način se otkrije incident, najvažnije je da se zabilježe svi poznati detalji. Najbitniji detalji su:

• Trenutno vrijeme i datum
• Tko/što je prijavilo incident
• Priroda incidenta
• Kada se dogodio incident
• Uključeni hardver/softver
• Dodirne točke za uključeno osoblje

Nakon bilježenja najbitnijih detalja, treba se aktivirati CSIRT i kontaktirati prikladni ljudi.

--Marina Marković 6. siječnja 2012. (CET)

Inicijalni odgovor

Ova faza označava okupljanje CSIRT-a, prikupljanje mrežnih i drugih podataka, određivanje vrste incidenta koji se dogodio i procjena štete koju je nanio incident. Cilj ove faze je prikupiti dovoljno informacija kako bi se moglo krenuti sa sljedećom fazom, a to je oblikovanje strategije odgovora. Također, potrebno je dokumentirati korake koji moraju biti poduzeti. Ovakav pristup sprječava automatske nepromišljene reakcije i nastanak panike kada se incident dogodi. Osobe uključene u otkrivanje incidenta započinju fazu inicijalnog odgovora. Detalji vezani uz incident trebaju biti dokumentirani od strane onog tko je otkrio incident ili osobe kojoj je javljena mogućnost incidenta (npr. Služba pomoći ili osoblje iz osiguranja). Također, upravljanje odgovorom treba biti prebačeno na CSIRT što prije kako bi se iskoristila stručnost tima. Inicijalni odgovor ne uključuje rukovanje s sustavima uključenim u incident. Ova faza uključuje obavljanje sljedećih zadataka:

• Intervjuiranje sistem administratora koji bi mogao imati uvid u tehničke detalje incidenta
• Intervjuiranje osoblja poslovne jedinice koji bi mogli imati uvid u poslovne događaje koji mogu dati objašnjenje incidenta
• Pregled izvješća o detekciji upada i mrežnih log zapisa kako bi se identificirali podaci koji mogu pokazati da se incident dogodio
• Pregled mrežne topologije i pristup kontrolnim listama kako bi vidjeli mogu li se neki putovi napada isključiti

Minimum ove faze jest određivanje da li se incident zaista dogodio, tip incidenta, koji su sustavi izravno ili neizravno pogođeni, koji korisnici su uključeni, i mogući utjecaj na poslovanje. Kada su prikupljeni ovi podaci, može se prijeći na sljedeću fazu i odluku kako reagirati na incident.

--Marina Marković 6. siječnja 2012. (CET)

Oblikovanje strategije odgovora

Cilj oblikovanja strategije odgovora je određivanje najprikladnije strategije odgovora s obzirom na okolnosti incidenta. Strategija bi trebala uzeti u obzir političke, tehničke, pravne i poslovne faktore koji okružuju incident.

Sljedeći faktori trebaju biti uzeti u obzir kada se odlučuje o količini resursa potrebnih da bi se incident istražio, da li se treba napraviti forenzička kopija bitnih sustava, treba li napraviti kaznenu prijavu ili pokrenuti građansku tužbu i sl.:

• Koliko su kritični pogođeni sustavi?
• Koliko su osjetljive kompromitirane ili ukradene informacije?
• Tko su potencijalni zločinci?
• Je li incident poznat javnosti?
• Koju je razinu neautoriziranog pristupa dosegnu napadač?
• Koje su očite vještine napadača?
• Koliko je vrijeme ispada sustava i korisnika?
• Koliki je novčani gubitak?

Strategija odgovora, među ostalim, treba uzeti u obzir i poslovne ciljeve organizacije. Zbog tog razloga i zbog potencijalnog utjecaja na organizaciju, strategija odgovora treba biti odobrena od menadžmenta više razine.

Povremeno će organizacija morati poduzeti mjere kako bi disciplinirala zaposlenike ili odgovorila na maliciozni postupak izvana. Mjere mogu uključivati kaznenu prijavu, građansku tužbu ili neke administrativne opomene ili opoziv privilegija.

Pravne akcije

Nisu rijetke istrage računalnih sigurnosnih incidenata koji su podložni zakonskom suđenju, ili mogu dovesti do tužbe i sudskog postupka. Dva su potencijalna pravna izbora: podnijeti civilnu tužbu ili obavijestiti pravne službe. Prije nego se odluči pozvati pravne (zakonske) službe, treba odrediti koliko smo truda i resursa spremni uložiti u istragu. Sljedeći kriteriji se trebaju uzeti u obzir prije nego se pozove služba za provedbu zakona:

• Da li šteta/troškovi incidenta zaslužuju kaznenu prijavu?
• Hoće li građanska ili kaznena prijava postići željene rezultate za organizaciju? (Može li se dobiti odšteta od tužene strane?)
• Je li uzrok incidenta razborito utvrđen?
• Ima li organizacija primjerenu dokumentaciju i organizirana izvješća koja će predati istražiteljima?
• Mogu li zakonskim službenicima biti predani opipljivi tragovi za istragu?
• Je li organizacija spremna prihvatiti rizik javne izloženosti?
• Da li postoje prošle aktivnosti nekih individualaca koje zaslužuju poduzimanje pravnih akcija?
• Kako će uključenost pravnih službi utjecati na obavljanje poslovnih aktivnosti?

Administrativne akcije

Discipliniranje ili otpuštanje zaposlenika putem administrativnih mjera danas je češće nego pokretanje građanskih ili pravnih akcija. Neke od administrativnih mjera kojima se discipliniraju zaposlenici uključuju:

• Pismo ukora
• Trenutni otkaz
• Obvezno odsustvo na određeno vrijeme (plaćeno ili neplaćeno)
• Preraspodjela radnih dužnosti (smanjena odgovornost)
• Privremeno smanjenje plaća da bi se nadoknadili gubici / štete
• Javna/ privatna isprika za provedena djela
• Oduzimanje određenih povlastica, kao što su pristup mreži ili web-u

--Marina Marković 6. siječnja 2012. (CET)

Istraživanje incidenta

Faza istraživanja uključuje otkrivanje tko, što, gdje, kada, kako i zašto vezano uz incident koji se dogodio. Istraga se provodi pronalaženjem i istraživanjem serverskih i mrežnih dokaza, te dokaza prikupljenih na tradicionalan, netehnički način. Ustanoviti identitet osobe na mreži je izrazito teško. Korisnici postaju sve vičniji upotrebljavati enkripciju, steganografiju (znanstvena disciplina koja se bavi prikrivenom razmjenom informacija), anonimne e-mail račune, lažne e-mailove, krivotvorene IP adrese izvora, MAC adrese, predstavljati se kao netko drugi i upotrebljavati razne druge mjere kako bi sakrili vlastiti identitet u cyber prostoru. Mnoge organizacije se radije usredotoče na otkrivanje onoga što je oštećeno, kako je oštećeno te kako se može popraviti, nego na otkrivanje identiteta počinitelja. Računalno sigurnosna istraga se može podijeliti na 2 faze: prikupljanje podataka i forenzičku analizu.

Tijekom ove faze, prikupljaju se sve bitne informacije potrebne za rješavanje incidenta u sklopu strategije odgovora. U fazi forenzičke analize, ispituju se svi prikupljeni podaci kako bi se odredile informacije vezane uz incident koje odgovaraju na pitanja:tko, što, gdje, kada i kako. Slika 4. prikazuje moguće korake tijekom dvije faze istrage.

Prikupljanje podataka

Prikupljanje podataka je akumulacija činjenica i dokaza koji trebaju biti uzeti u obzir tijekom forenzičke analize. Prikupljeni podaci čine temelj zaključka o tome kako se incident dogodio. Prikupljanje podataka predstavlja nekoliko izazova:

• Elektronički podaci se trebaju prikupiti na forenzički ispravan način.
• Najčešće se prikuplja više podataka nego se mogu pročitati za vrijeme cijelog životnog vijeka
• Podaci se moraju prikupljati na način da se očuva njihov integritet (rukovanje dokazima)

Ovi zahtjevi pokazuju da su potrebne posebne vještine kako bi se prikupili tehnički dokazi. Informacije koje se prikupe mogu se podijeliti na 3 osnovna područja: informacije o poslužitelju, o mreži i ostale informacije.

Poslužiteljske informacije

Prikupljanje podataka temeljenih na poslužitelju uključuje prikupljanje podataka na 2 načina: prikupljanje podataka uživo i forenzičko kopiranje. U nekim slučajevima, dokazi koji se trebaju prikupiti su trenutni (privremeni, kratkotrajni) ili ili izgubljeni kada se žrtvin/bitan sustav isključi. Ovi nestalni podaci mogu pružiti kritične informacije pri razumijevanju prirode incidenta. Ovi podaci daju snimku stanja sustava u vrijeme odgovora. Snimaju se slijedeći nestalne informacije:

• datum/vrijeme sustava
• trenutno pokrenute aplikacije na sustavu
• trenutno uspostavljene mrežne veze
• trenutno otvoreni socketi (portovi)
• prisluškivanje aplikacija na otvorenim socketima
• stanje mrežnog sučelja (promiskuitetno ili ne)

Kako bi se prikupile potrebne informacije, mora se obaviti odgovor uživo engl. live response. On se obavlja kada je računalni sustav još uvijek upaljen i radi. To znači da se informacije na tim područjima trebaju prikupiti bez utjecaja na podatke na ugroženim uređajima. Postoje 3 oblika live response-a:

1. Početni odgovor uživo (engl. initial live response) – uključuje prikupljanje samo nestalnih podataka sa žrtvinog sustava. Obično se izvodi kada se obavlja forenzičko kopiranje medija.

1. Odgovor u dubinu (engl. in-depth response) – ide dalje od prikupljanja samo nestalnih podataka. CSIRT nabavlja dovoljno dodatnih informacija s napadnutog sustava kako bi se mogla odrediti valjana strategija odgovora. Stalni podaci se prikupljaju, poput log datoteka.

1. Potpuni odgovori uživo (engl. full live responses) – ovo je potpuna istraga aktivnog sustava, prikupljaju se svi podaci za istragu umjesto izvođenja forenzičkog kopiranja, koje zahtjeva da se sustav ugasi.

Forenzičko kopiranje pruža „zrcalnu sliku“ ciljnog sustava, te je opravdano ako je incident ozbiljan i potrebno je povratiti obrisani materijal. Pravne službe preferiraju forenzičko kopiranje ciljnih sustava „bit-za-bit, bajt-za-bajt“.

Mrežni dokazi

Mrežni dokazi uključuju informacije prikupljene iz sljedećih izvora:

• IDS zapisi
• Konsensualni nadgledajući logovi
• Nekonsensualno prisluškivanje
• Pen-registar/zamke i tragovi
• Ruter zapisi
• Firewall zapisi
• Autentifikacijski poslužitelji

Organizacija često nadgleda mrežu (konsensualno praćenje) kako bi potvrdila sumnje, prikupila dokaze i identificirala suradnike uključene u incident. Gdje ne uspije poslužiteljska kontrola, praznine može popuniti mrežno nadgledanje. Ono nije namijenjeno sprječavanju napada, nego omogućava organizaciji da obavlja sljedeće zadatke:

• Potvrdi ili odbaci sumnje vezane uz navodni računalni sigurnosni incident
• Prikupi dodatne dokaze i informacije
• Provjeri opseg kompromisa
• Identificira dodatne uključene stranke
• Utvrdi vremensku crtu događaja na mreži
• Osigura usklađenost s željenom aktivnošću.

Ostali dokazi

Odnose se na svjedočanstva i druge informacije prikupljene od ljudi. Ovdje se prikupljaju datoteke o osoblju, intervjuiraju se zaposlenici i svjedoci, i dokumentiraju prikupljene informacije.

--Marina Marković 6. siječnja 2012. (CET)

Forenzička analiza

Forenzička analiza uključuju pregled prikupljenih podataka: log zapisa, konfiguracijske datoteke sustava, sigurnosne veze, datoteke povijesti web preglednika, e-mail poruke i njihovi privitci, instalirane aplikacije, grafičke datoteke. Analizira se softver, pregledavaju oznake datuma / vremena, pretražuju se ključne riječi i poduzimaju se ostali koraci istrage. Također se pretražuju informacije koje su logički obrisane sa sustava kako bi se odredilo da li obrisane datoteke, zanemareni ili prazan prostor sadrže fragmente ili cjelovite datoteke koje bi bile korisne u istrazi. Slika 5. prikazuje glavne korake tijekom forenzičke analize.

Glavne skupine forenzičkih alata su:

• Programski paketi za stvaranje preslika čvrstog diska (eng. Disk imaging software):

bilježe strukturu i sadržaj čvrstog diska. Oni omogućavaju kopiranje podataka i očuvanje načina na koji su datoteke organizirane, kao i njihove međusobne veze. Poznatiji alati ove skupine su: Acronis True Image, Paragon Drive Backup i FarStone Drive Clone.

• Alati za rekonstrukciju programskih paketa i sklopovlja:

omogućavaju kopiranje i rekonstruiranje čvrstih diskova bit po bit. Alati ne mijenjaju, odnosno ne uništavaju, postojeće podatke u procesu rekonstrukcije. Primjer forenzičkog alata koji nudi ovu opciju je EnCase.

• Alati za rukovanje sažetcima poruka (eng. hash):

koriste se za uspoređivanje izvornih podataka sa kopijama, analizu podataka te dodjelu jedinstvene oznake. Primjer ovog alata je ProDiscover.

• Programi za dohvaćanje obrisanih podataka:

otkrivaju lokaciju podataka na računalu koji su označeni za brisanje, ali još uvijek nisu prepisani. Podaci koji nisu prepisani mogu se dohvatiti, no takvi podaci ne moraju uvijek biti cjeloviti i pohranjeni na istom mjestu. Primjeri ovakvih programa su DT Utilities Digital Rescue, Recover My Files.

• Programi za dekriptiranje i otkrivanje zaporki:

primjeri takvih programa su FileZilla, CryptoTools i drugi

--Marina Marković 6. siječnja 2012. (CET)

Izvještavanje

Izvještavanje može biti najteža faza procesa odgovaranja na incidente jer treba napraviti izvješća koja točno opisuju detalje incidenta koji su razumljivi donositeljima odluka, koji mogu podnijeti prepreke pravne kontrole i koji će biti kreirani na vrijeme. Slijede neke preporuke za pisanje izvješća:

• Odmah dokumentirajte – svi koraci i zaključci istrage trebaju biti dokumentirani što prije jer time štedimo vrijeme, promičemo točnost i osiguravamo dostupnost detalja istrage drugima.
• Pišite sažeto i jasno – dokumentiranje istrage zahtjeva disciplinu i organizaciju. Podatke treba zapisivati tako da budu svima jasni, izbjegavati stenografiju, skraćenice, nejasne bilješke i sl.
• Koristite standardne formate – kreirajte format izvješća i pridržavajte ga se. Stvorite obrasce, nacrte i predloške koji organiziraju proces odgovora i potiču bilježenje svih bitnih podataka. To će učiniti pisanje izvješća skalabilnim, uštediti će vrijeme te će promicati točnost.
• Koristite uređivače teksta – zaposlite urednike za čitanje forenzičkih izvješća. To će pomoći razvoju izvješća koja su razumljiva netehničkom osoblju koji imaju utjecaj na strategiju i odluke odgovaranja na incidente (poput kadrovske službe, pravnim savjetnicima, poslovnim vođama...)

--Marina Marković 6. siječnja 2012. (CET)

Odlučivanje

Cilj faze odlučivanja je implementiranje poslužiteljskih, mrežnih i proceduralnih protumjera kako bi se spriječilo da incident ne uzrokuje daljnja oštećenja i kako bi se organizaciju vratilo u siguran i zdrav operativni status. Prije nego se odluče implementirati bilo kakve sigurnosne mjere, potrebno je prikupiti sve dokaze ako se organizacija odlučila na poduzimanje pravne ili administrativne akcije kako ne bi došlo do izmjene ili ugrožavanja dokaznih materijala. Kako bi se riješio incident treba odrediti organizacijske prioritete, odrediti prirodu incidenta, uzroke incidenta ( nedostatak standarda, neusklađenost sa standardima i sl.), povratiti pogođene sustave, popraviti ranjivosti na poslužitelju i mreži (firewall, IDS..), dodijeliti odgovornosti za popravak problema na sustavu te pratiti napredak popravaka, validirati efikasnost protumjera, poboljšati sigurnosne politike i procedure.

--Marina Marković 6. siječnja 2012. (CET)

Priprema za odgovaranje na incident

Priprema za odgovaranje na incident uključuje organizacijske korake te korake pripreme tima za odgovor na računalno sigurnosni incident – CSIRT-a (engl. computer security incident response team). Preporučaju se sljedeći koraci:

• Identificiranje organizacijskih rizika
• Priprema poslužitelja za odgovaranje i oporavak od incidenata
• Priprema mreže implementacijom sigurnosnih mjera
• Donijeti politike i procedure kojima će se postići ciljevi odgovaranja na incidente
• Kreirati programske alate za CSIRT
• Stvoriti CSIRT koji će se moći nositi s incidentima.

Identificiranje rizika

Potrebno je odrediti presudnu organizacijsku imovinu, njihovu izloženost, prijetnje... Presudna imovina (sredstva) predstavlja područja organizacije koja su kritična za osiguranje nastavka poslovanja. Slijede primjeri presudne imovine:

• Ugled organizacije
• Povjerljive poslovne informacije
• Privatne osobne identifikacijske informacije.

Presudna imovina je ona koja proizvodi najveću odgovornost ili potencijalne gubitke organizaciji. Prepoznavanje rizika je bitno jer se resursi potroše na najefikasniji način. Svi resursi ne trebaju biti osigurani na istoj razini. Imovina koja je suočena s najvećim rizikom prima najviše resursa.

„Kako bi se odredilo ocjenjivanje ozbiljnosti sigurnosnog incidenta potrebno je prvo utvrditi ocjene utjecaja za incident. Slika 6. sadrži primjer dodjele takvih ocjena.

Nakon postavljanja ocjena utjecaja organizacije trebali bi koristiti slijedeću tablicu (Slika 7.) za dodjelu ocjena kritičnosti na sustave koji su zahvaćeni incidentom.

Navedena dva sustava ocjenjivanja trebaju se definirati za svaki incident kako bi se mogle odrediti ukupne ocjene utjecaja. Za utvrđivanje ukupnih ocjena utjecaja za pojedini incident organizacije bi trebale slijediti formulu:

ukupna ocjena utjecaja = (trenutna ocjena utjecaja * 2.5) + (predviđena ocjena utjecaja * 2.5) + (ocjena kritičnosti sustava * 5))

Upotrebom rezultata navedene formule, organizacije mogu primijeniti ukupne ocjene utjecaja incidentu, kao što pokazuje tablica na Slici 8.“ [CARNet CERT, str. 17].

--Marina Marković 6. siječnja 2012. (CET)

Priprema pojedinih poslužitelja

Koraci koje treba poduzeti kako bi se pomoglo istražiteljima da efikasno reagiraju na incident:

• Snimiti kriptirane kontrolne zbrojeve (checksum) najbitnijih datoteka
• Povećati ili omogućiti sigurnu reviziju dnevničkih zapisa
• Povećati sigurnosnu obranu poslužitelja
• Napraviti sigurnosnu kopiju najkritičnijih podataka i sigurno pohraniti medij
• Obrazovati korisnike o sigurnosti poslužitelja

Ovi koraci nisu jednokratni proces, već ih treba uključiti u organizacijsku politiku i procedure jer se tijekom vremena mijenjaju korisnici, softver i mrežne konfiguracije.

Snimiti kriptirane kontrolne zbrojeve (engl. checksum) najvažnijih datoteka

Kako bi istražitelji provjerili integritet informacija i kada im je zadnji put pristupljeno, trebat će usporediti sadašnje stanje sustava s „poznato dobrim“ stanjem. Svaka promjena u sustavu tada će biti istražena. Kopija ispravnog sustava treba biti napravljena prije nego se incident dogodi, a najbolje ju je napraviti prije nego se sustav prvi put spoji online. Problem predstavlja uspoređivanje datoteka prije i poslije incidenta – da li uspoređivati liniju po liniju ili atribute poput veličine datoteke. Rješenje je koristiti kriptirane kontrolne zbrojeve (engl. cryptographic checksums), također poznato pod nazivom rezultat provjere poruka (engl. message digest) ili otisak prsta (engl. fingerprint), a predstavlja digitalni potpis. Kontrolni zbroj se kreira primjenom algoritma na datoteku, te je za svaku datoteku jedinstven. Zbog toga je checksum savršen atribut za provjeru integriteta datoteka. Zbog toga je potrebno napraviti kontrolne zbrojeve prije i poslije incidenta te ih usporediti, kako bi se utvrdilo da li je integritet podataka sačuvan.

Korištenje MD5 algoritma za stvaranje kontrolnih zbrojeva

Najšire prihvaćen i najčešće korišten algoritam za stvaranje kontrolnih zbrojeva je MD5 algoritam. Autor algoritma je Ron Rivest, a objavljenje 1992. kao RFC 1321. MD5 algoritam kreira 128-bitni kontrolni zbroj od bilo koje proizvoljno velike datoteke. Postoje mnoge implementacije ovog algoritma za najčešće operativne sustave, poput Unixa i Windowsa.

Za Unix sustave, potrebno je upotrijebiti samo naziv ciljne datoteke kao jedini argument naredbene linije:

 [root@localhost /root]# md5sum /bin/login

Izlaz je kontrolni zbroj fiksne duljine, zajedno s unesenim nazivom datoteke:

113b07d56e9c054fe2d7f15462c7b90a /bin/login

Za Windows sustave, slična je upotreba, osim za kreiranje kontrolnog zbroja binarnih datoteka. Pravilno kreiranje MD5 kontrolnog zbroja za tekstualnu datoteku na Windowsima:

C:\>md5sum boot.ini
f44ece28ee23cd9d1770a5daf6cf51bf boot.ini

Pri kreiranju checksuma za binarnu datoteku, potrebno je upotrijebiti –b zastavicu:

C:\>md5sum -b test.doc
95460dd2eabc0e51e2c750ae8c0cd4b5 *test.doc

Zvjezdica (*) koja prethodi nazivu datoteke upućuje na to da je datoteka binarna. Kako bi automatizirali ovaj proces, stvorimo listu datoteka koje zahtijevaju kontrolni zbroj:

 [root@response root]# cat list
/bin/login
/sbin/ifconfig
/etc/passwd

Tada, kreiramo kontrolne zbrojeve za sve datoteke u listi:

[root@response root]# md5sum `cat list` > list.md5
[root@response root]# cat list.md5
113b07d56e9c054fe2d7f15462c7b90a /bin/login
fe93307aa595eb82ca751e8b9ce64e49 /sbin/ifconfig
fa0ebff965b4edbdafad746de9aea0c3 /etc/passwd

Na kraju, možemo provjeriti kontrolne zbrojeve bilo kada u budućnosti:

 [root@response root]# md5sum -c list.md5
/bin/login: OK
/sbin/ifconfig: OK
/etc/passwd: OK

Postoje alati koji automatiziraju ovaj proces. Jedan od prvih takvih alata je bio Tripwire paket, kreiran 1992. od Gene Kima i Gene Spafforda. Danas je to komercijalni proizvod s proširenom funkcionalnošću, dostupan za Windowse i Unix sustave.

--Marina Marković 6. siječnja 2012. (CET)

Povećati ili omogućiti sigurnu reviziju dnevničkih zapisa

Gotovo svaki operacijski sustav pruža značajne sposobnosti dnevničkih zapisa, no nažalost, one zadane (defaultne) su često manje nego idealne. Kako bi maksimalno iskoristili mogućnosti log zapisa, potrebno je malo podešavanja.

Unix sustavi

Srce i duša Unix log zapisa je syslog, skraćenica za system logging. Syslog.conf se sastoji od 2 polja: selektora i akcije. Polje selektora govori gdje je poruka kreirana i prioritet (važnost poruke). Polje akcije kontrolira gdje je poruka zapisana. Kako bi se sve poruke zapisale na sustav, korisitmo naredbu:

*.* /var/log/syslog

Također se preporuča uspostaviti udaljeno evidentiranje (engl. remote logging). Potreban je poslužitelj koji će služiti samo za primanje syslog poruka putem UDP-a na portu 514. Ostale poslužitelje treba konfigurirati da šalju log poruke na syslog server

Još jedna od mogućnosti je praćenje procesa (engl. process accounting) čime se prate sve naredbe koje korisnik izvršava. Log datoteka se obično nalazi u /var/adm, /ver/log ili /usr/adm direktoriju pod nazivom pacct ili acct. Može se pregledavati s lastcomm ili acctcom naredbom. Problem je što napadač može obrisati ovu datoteku.

Windows sustavi

Zadane postavke Windows log zapisivanja jest da ne bilježe nikakve događaje. Trebalo bi omogućiti sigurnosnu provjeru, provjeru datoteka i direktorijskih akcija, te čuvanje log poruka na udaljenom poslužitelju. Omogućavanje vođenja dnevničkih zapisa obavlja se u Administrative Tools | Local Security Policy | Local Policies |Audit Policy (Windows XP).

Omogućite bilježenje događaja važnih za vaš sustav, minimum bi trebao biti:

• Prijava i odjava
• Upravljanje korisnicima i grupama
• Promjene sigurnosnih politika
• Ponovno pokretanje, gašenje i sistemski događaji

Praćenje procesa je slično kao kod Unix sustava. Kako bi se evidentirale promjene na datotekama i dozvole na direktorijima, datotečni sustav mora biti NTFS. Napadač može lako obrisati datoteku C:\WINDOWS\system32\config\*.evt u kojoj su zapisani svi događaji i zbog toga je potrebno postaviti udaljeno dnevničko zapisivanje (engl. remote logging). Također postoji cijeli niz bilježenja aplikacijskih događaja.

--Marina Marković 6. siječnja 2012. (CET)

Izrada zaštite središnjeg računala

Kada bi sva središnja računala bila sigurna, mnogi sigurnosni incidenti bi bili izbjegnuti. Pripremama prije incidenta nebi smjeli zanemariti nadogradnju obrane središnjih računala. Akcije poduzete za sigurnost središnjeg računala će, ne samo smanjiti izloženost sigurnostim incidentima, nego će isto tako olakšati razrješenje incidenta.

Postoje tri ključne napomene koje treba uzeti u obzir kod sigurnosti središnjeg računala:

• Budite sigurni da su svi operacijski sustavi i aplikacije najnoviji. Koristite zadnje verzije i pobrinite se da su instalirane sve zakrpe i nadogradnje.
• Onesposobite nepotrebne servise. Ako ne koristite aplikaciju ili mrežne servise, oni nebi trebali raditi. Nepotrebni servisi predstavljaju nepotreban rizik.
• Kod konfiguracijskih izbora treba odabrati pažljivo. Sigurnosna izloženost predstavljena je kroz slabu sustavsku administraciju.

--Igor.trgovcic 13:07, 6. siječnja 2012. (CET)

Sigurnosna kopija kritičnih podataka

Redovite sigurnosne kopije cijelog sustava može biti korisna referenca prilikom odgovora na incidente. Sigurnosne kopije pružaju uvid u ono što se mijenjalo, jer osiguravaju kopiju sustava za koju znamo da je valjana. Sigurnosne kopije također pomažu otkriti što je brisano i što je dodano. Dodatno, neke sigurnosne kopije sadrže zapisane informacije vrijeme/datum, koje se mogu koristiti da bi se provjerilo kada se zadnje pristupalo, mijenjalo ili kreiralo daoteke i direktorije. Postoji veliki izbor alata za izradu sigurnosnih kopija, od alata koji se već nalaze u sklopu operacijskog sustava, do komercijalnih alata s raznim mogućnostima. U nastavku ćemo spomenuti neke besplatne alate.

Unix alati

Za Unix, najčešće korišteni uslužni programi su dump, restore, cpio, tar i dd. Svaki program ima svoje prednosti i nedostatke. Jedan od glavnih nedostataka većine programa za izradu sigurnosnih kopija je da resetiraju vrijeme zadnjeg pristupa, eliminirajući taj potencijalno koristan atribut. Dump uslužni program je jedini izbor koji čuva sva tri vrijeme/datum otiska. Prednost tar-a je da je format vrlo poznat, i popularni WinZip program može pregledavati sadržaj tar datoteke. Tar ima fleksibilnost tako da može sačuvati vrijeme zadnjeg pristupa, ali time uništavajući vrijeme izmjene.

Windows alati

Windows sustavi također imaju raznolike opcije za izradu sigurnosnih kopija i vraćanje u prvobitno stanje. Za Windows 2000, uslužni programi za izradu sigurnosnih kopija koji su u sklopu operacijskog sustava se nalaze pod Start – Programs – Accessories – System Utilities – Backup. Za Windows NT standard je program NTBACKUP. Još jedan sustavski program je Backup, koji radi sigurnosnu kopiju datoteka i direktorija s diska na disk.

Razumijevanje ograničenja sigurnosnih kopija

Unatoč prednostima koje pružaju sigurnosne kopije, nisu rješenje za sve probleme kod odgovora na incidente. Jedan od problema je da sigurnosne kopije može biti teško povratiti točno na vrijeme. Prilikom početne istrage, informacije mogu biti potrebne istog trenutka. Nalaženje nekorištenog sustava s potrebnom hardwareskom konfiguracijom na kojemu se može povratiti sigurnosna kopija, obično trebaju dani ili tjedni za to, umjesto sati ili minute. Isto tako, sigurnosne kopije su onoliko dobre koliko je dobar original na temelju kojeg su kreirane. Ako se posumnja da je sustav kompromitiran, ne možemo znati dali je kopija napravljena prije ili nakon što se kompromitiranje dogodilo. Ukoliko se kopija napravila nakon, tada svi hakerski backdoor i trojanski programi ostaju i nakon povrata sigurnosne kopije. Još nešto što se mora uzeti u obzir je vjerodostojnost informacija o vremenu/datumu na sigurnosnim kopijama. Ovisno o tome kako se kopije rade, možda nemaju točne informacije o vremenu zadnjeg pristupa. Neki oblici izrade sigurnosnih kopija će ažurirati sve informacije o zadnjim pristupima u vrijeme kada su kopije napravljene, time brišući potencijalno vrijedne informacije. Uzimajući u obzir te nedostatke, sigurnosne kopije svejedno mogu biti nevjerojatno korisne. Ukoliko su kopije napravljene kada je sustav bio sigurno u dobrom stanju, ako ima točne informacije o vremenu/datumu i ako se može povratiti u odgovarajuće vrijeme, tada vjerojatno mogu biti najbolja opcija za uspoređivanje stanja sustava.

--Igor.trgovcic 13:07, 6. siječnja 2012. (CET)

Edukacija korisnika o sigurnosti središnjih računala

Korisnici mogu igrati ključnu ulogu u ukupnoj sigurnosti. Akcije koje poduzimaju korisnici, često zaobilaze i najbolje postavljen sigurnosni plan. Tako da bi edukacija korisnika trebala biti dio priprema prije incidenta. Korisnici bi trebali znati koje vrste akcija smiju i ne smiju poduzimati na svojim sustavima, s perspektive i računalne sigurnosti i odgovora na incidente. Najčešće ćemo očekivati da korisnici kontaktiraju predodređenu osobu. Općenito, korisnici bi trebali biti upućeni da ne poduzimaju nikakve istraživačke akcije, jer takve akcije mogu često uništiti dokaze i oslabiti učinkovitost kasnijeg odgovora na incident. Poseban problem koji treba uzeti u obzir je opasnost mrežnog software-akoji instaliraju korisnici. Oni mogu instalirati svoje web servere bez autorizacije i prikladne sigurnosti, time dovodeći u opasnost općenite sigurnosti organizacije.

--Igor.trgovcic 13:07, 6. siječnja 2012. (CET)

Priprema mreže

Postoje mnoge mjere na temelju mreže koje se mogu poduzeti u sklopu mogućnosti odgovora na incidente. Logiranje na mrežu je ključno, jer postoje mnogi slučajevi u kojima je praćenje rada mreže jedini način prikupljanja dokaza. Tako da su mrežni administratori odgovorni za mrežnu arhitekturu i topologiju, što se treba razumjeti kako bi shvatili npr. koji redom su sustavi pogođeni. Mrežni administratori isto tako upravljaju vatrozidovima, ruterima i sustavima za detekciju upada, kojima se treba pristupiti kako bi pregledali ključne log datoteke. Od mrežnih administratora se može tražiti da blokiraju određeni promet tijekom odgovora na incidente.

Mrežne sigurnosne akcije uključuju sljedeće:

• Instaliranje vatrozidova i sustava za detekciju upada
• Korištenje kontrolne liste pristupa na ruterima
• Kreiranje topologije potrebne za nadgledanje
• Enkripcija mrežnog prometa
• Zahtijevanje autentifikacije

U sljedećem dijelu detaljnije su obajašnjene prethodno navedene akcije.

Instaliranje vatrozida i sustava za detekciju upada

Kada ruteri, sustavi za detekciju upada i vatrozidovi postoje i kada su konfigurirani optimalno, uljezi su često lako uhavćeni. Način na koji se ti sustavi konfiguriraju ovisi o stavu organizacije prema odgovaranju na incidente. Koji god pristup izabrali, konfiguracija tih uređaja nije jednostavna. Glavna poanta je da umjesto samo postavljanja zaštete mreže, trebamo ih konfigurirati tako da zapisuju aktivnosti.

Korištenje kontrolne liste pristupa na ruterima

Možda najbolji način kako poboljšati upotrebljivost mrežnih uređaja uključuje Cisco ruter. Cisco ruteri se često koriste kao sigurnosni uređeji na mrežama. Ruter se uobičajeno konfigurira s kontrolnim listama pristupa koje dozvoljavaju određeni tip prometa dok istovremena sprječavaju potencijalno opasan promet. Kako bi se lakše koristili logovi, poželjno je postaviti na svim uređajima da imaju isto vrijeme, koristeći Network Time Protocol (NTP). Treba blokirati sve eksterne pristupe na taj port i da su svi uređaji na mreži sinkronizirani. Na taj način, svi logovi zabilježavaju isto vrijeme za događaj. Time si štedimo vrijeme koje bi izgubili na utvrđivanju koje je vrijeme na ruteru, koje na vatrozidu usporedno s uređajem-žrtvom, drugim web stranicama itd.

Kreiranje topologije potrebne za nadgledanje

U slučaju incidenta, mora se poznavati mrežna topologija kako bi se utvrdila najbolja strategija odgovora. Bez informacija o mrežnoj topologiji, nije moguće uvrditi koji su još sustavi pogođeni. A bez znanja o tome koji su ostali sustavi pogođeni, nije moguće imati kvalitetan plan odgovora. U nastavku ćemo vidjeti neke načine koji olakšavaju implementacije tehnika nadgledanja mreže.

Što se može dogoditi

Uljez je postavio mrežno njuškalo (hardware ili software koji pasivno presreće pakete koji putuju mrežom) na kompromitirano središnje računalo. Uljez promatra zaporke i osjetljivi promet, ne samo s kompromitiranog središnjeg računala nego i s bilo kojeg računala koje se nalazi u mreži kompromitiranog. Time se uljez može logirati na bilo koje računalo koje propušta neenkriptirani promet na kompromitiranoj mreži.

Gdje tražiti dokaze

Kako bi odgovorili na taj incident, moramo utvrditi koji sustavi su kompromitirani ukradenim korisničkim imenima i zaporkama. Mičući samo kompromitirano središnje računalo je velika greška, jer će uljez i dalje imati korisnička imena i zaporke ostalih sustava. Ovaj tip incidenta naglažava vrijednost shvaćanja mrežne topologije i održavanje točne mrežne mape.

Kreiranje topološke karte mreže

Točna topološka karta mreže je koristan alat prilikom odgovora na incidente. U idealnom slučaju topološka karta mreže uključuje detalje za sva središnja računala i mrežne konekcije, kao što su načini na koje se središnja računala spajaju, koje mreže koriste switcheve (prespojnike) a koje rutere, i lokalizacija mogućnosti ekterne konekcije. Realno, taj nivo detalja uobičajeno nije prisutan za velike mreže. Prije nego se incident dogodi, mora se omogućiti timu za odgovore na incidente da ima pristup točnim, ažuriranim topološkim kartama.

Kreiranje karte mrežne arhitekture

Dok topološka karta mreže pruža općenito sliku sheme mreže, rijetko prikazuje fizičku lokaciju i konekcije središnjih računala. Odgovaranje na incidente zahtijeva te informacije. Kako bi se proveli kritični koraci odgovora na konzoli pogođenog središnjeg računala, fizička lokacija mora biti poznata. Karta koja pokazuje fizičku arihitekturu meže sačuva dragocjeno vrijeme u slučaju incidenta, i kreiranje takve karte treba biti dio pripreme prije incidenta.

Podržavanje praćenja rada mreže

Kako bi se pratio rad mreže, mora se priključiti platforma za praćenje rada mreže na mrežni uređaj koji ima pristup cijelom mrežnom prometu. Radi uspješnog provođenja priključivanja, moraju se kvalitetno definirati politike i procedure kao dio pripreme prije incidenta. Mora se osigurati da kritične mreže pružaju otvoreni port s pristupom cijelom prometu.

Enkripcija mrežnog prometa

Enkripcija mrežnog prometa povećava sigurnost svake mreže. Dvije popularne implementacije su Secure Sockets Layer (SSL) i Secure Shell (SSH). SSL se koristi za enkriptirani web promet. SSH se koristi za interaktivno logiranje i prijenos podataka. Važno je napomenuti da enkripcija web prometa može omesti detekciju i istragu raznim neautoriziranim i nezakonitim mrežnim aktivnostima. Kada napadači koriste enkriptirane protokole za pristup sustavu, praćenje rada mreže je beskorisno. Sposobnost da se učinkovito odgovori se smanjuje. To se treba imati na umu prilikom implementacije sigurnosne arhitekture.

--Igor.trgovcic 13:23, 6. siječnja 2012. (CET)

Zahtijevanje autentifikacije

Autentifikacija je temeljena na središnjem računalu ali i na sigurnosnim mjerama mreže. Samo korištenje korisničkih imena i zaporki kao mjeru autentifikacije se pokazalo kao prilično neučinkovito. Korisnička imena i zaporke se često lako pogode ili ih jednostavno zna više od pola organizacije. Korištenje bilo kojih dodatnih protokola, osim korisničkog imena i zaporke, omogućuju postavljanje sigurnije mreže. Mnogi razni autentifikacijski protokoli su besplatno dostupni na internetu. Svaki utječe na mogućnost odgovora malo dugačije. Potrebno je izabrati implementaciju koja povećava sigurnost mreže i pruža učinkoviti trag za tim odgovora na incidente.

Specifičnosti vezane uz neovlašteni pristup

"Neovlašteni se pristup sustavu javlja kada napadač preuzme ovlasti i pristupi sustavima kojima inače nebi smio pristupiti. Napadač obično preuzima korisničke ili administratorske ovlasti iskorištavanjem ranjivosti operacijskog sustava ili programa. Kako bi to učinio, napadač krade korisnička imena i zaporke. Do tih podataka može doći, osim zlouporabom sigurnosnih ranjivosti i socijalnim inženjeringom (više o ovim oblicima napada moguće je pronaći u dokumentima: dokumentima „Socijalni inženjering“ i „Socijalni inženjering putem VoIP tehnologije“, dostupnim na službenim stranicama CERTa).

Primjeri neovlaštenog pristupa su:

• Preuzimanje administratorskih ovlasti poslužitelja elektroničke pošte,
• Postupci koji mijenjaju ili brišu sadržaje web stranica organizacije,
• Pogađanje ili razbijanje zaporki,
• Neovlašteno pregledavanje ili kopiranje osjetljivih podataka, kao što su zapisi o plaćama, medicinske informacije, brojevi kreditnih kartica,
• Pokretanje programa za prisluškivanje paketa na radnoj stanici u svrhu krađe korisničkih imena i zaporki,
• Iskorištavanje dojave o zabrani pristupa na anonimni FTP poslužitelj u svrhu širenja piratskih programa i glazbenih datoteka,
• Lažno predstavljanje putem telefona, resetiranje zaporki elektroničke pošte i
• Upotreba tuđih radnih stanica." [CARNet CERT, str. 24]

--Igor.trgovcic 14:46, 6. siječnja 2012. (CET)

Utemeljenje prikladnih politika i procedura

Koliko god se dosadno i bespotrebno činila tema politika, vrlo je bitna i može odlučivati o uspješnosti istrage incidenta računalne sigurnosti. Bez postojanja prikladnih politika, zaposlenici očekuju određenu privatnost. Ne može se pratiti njihove dnevne aktivnosti, čitati elektroničku poštu, pratiti njihove navike surfanja webom, pristupati njihovoj govornoj pošti ili pregledavati sadržaj njihovog računala kada god se to poželi. Zaposlenici s lošim namjerama mogu elektroničkom poštom slati važne poslovne tajne konkurenciji. Bez prikladnih politika, njihove aktivnosti se ne mogu legalno pratiti. Kada se dogodi sigurnosni incident, istraga može zahtijevati nametljive korake, kao što su praćenje aktivnosti zaposlenika ili neovlaštenih uljeza. Uz određenu pripremu, planiranje, prikladne politike i procedure, može se ostvariti određene ciljeve prilikom odgovora na incident.

Određivanje stava odgovora

Prije nego se počnu razvijati pravila za zaposlenike prema kojima se oni trebaju ponašati, potrebno je odrediti stav kod odgovora na incidente. Vrlo je bitno za organizaciju da odredi svoj stav obrane prije incidenta. Taj stav će diktirati procedure organizacije i ključne prve korake kada se incident dogodi. Kada je organizacija žrtva računalne provale, denial-of-service (DoS) napad, unutarnja krađa intelektualnog vlasništva ili neki drugi oblik računalnog kriminala, organizacija može odgovoriti na nekoliko načina:

• Ignorirati incident
• Braniti se od budućih napada
• Braniti se od budćih napada identificirajući i onemogućavajući pokretače
• Provesti nadgledanje i protuobavještajno skupljanje podataka.

Organizacija može odgovoriti na jedan način ili na više načina istovremeno. Obično je želja stručnjaka sigurnosti da se brzo suzbije incident i primjene tehničke mjere kako bi spriječilo ponavljanje incidenta. Predstavnici zakona i druge organizacije s više ljudske snage i tehničke stručnosti mogu podržavati ideju da se implementiraju tehničke mjere i isto tako skupe dokazi kojima bi se idetificirali počinitelji računalnog kriminala.

Općenito postoji pet faktora koji će utjecati na to kako odgovoriti na raučunalni sigurnosni incident:

• Posljedica koju incident uzrokuje na poslovanje
• Zakonske odredbe i ograničenja
• Politički utjecaj ili korporativna politika
• Tehničke sposobnosti tima za odgovore na incident
• Financiranje i dostupni resursi

U nastavku su detaljnije objašnjeni.

Razmatranje poslovnih pitanja

Nema sumnje da većina kompanija razmatra poslovne odluke prije bilo kojih drugih. Kada web stranicu namjenjenu e-trgovini hakiraju, organizaciji je prioritet popraviti štetu što prije kako bi umanjili gubitak neradom stranice, ali isto tako kako bi sačuvali svoju reputaciju, s time da je poslovni gubitak tijekom nerada stranice važniji. Ukoliko je web stranica procijenjena kao vrijedna imovina, bilo bi poželjno prikupiti digitalne dokaze i pronaći počinitelje. Ako stranica nije vitalan dio poslovanja, tada se može jednostavno odlučiti na krpanje sigurnosnih propusta. U svakom slučaju to je poslovna odluka temeljena na riziku. Puno vremena i truda se može sačuvati identifikacijom sustava koji su važni i razviti politike, procedure i sigurnosnu arhitekturu koji najbolje brane imovinu sadržanu u tim sustavima.

Razmatranje zakonskih pitanja

U današnjem svijetu uvijek je poželjno tražiti pravni savjet prilikom zakonskih radnji koje mogu doći prilikom poduzetih akcija. Pravni savjet može i ne mora podržavati planirane akcije, ali svaka ograničenja ili natuknice koje pružaju savjetnici trebaju se doslovno slijediti.

Razmatranje političkih pitanja

Korporativna politika može zasjeniti sve aspekte organizacije, i također može utjecati na rezultat odgovora na incident. Korporativna politika diktira općeniti filozofiju sigurnosti. Ako je korporativna atmosfera takva da se svima vjeruje, dozvoljavajući svim korisnicima beskonačnu slobodu i fleksibilnost, tada to očito može utjecati na odgovor na incident. S druge strane ako organizacija naglašava sigurnost i štiti svoju imovinu, tada će se odgovori na incidente prilagoditi tome kako bi se provele planirane politike.

Razmatranje tehničkih mogućnosti

Ukoliko ne postoje ljudi s tehničkim mogućnostima potrebnima za prikupljanje informacija iz okoline incidenta, tada se ne može pristupiti kvalitetnom odgovoru na incident. Isto tako je potrebno imati hardware na mjestu ili odgovarajuću konfiguraciju mreže. Poanta je da učinkovito odgovaranje na incident zahtijeva dobre, vrijedne ljude koji su tehnički potkovani, svjesni korporativne politike, obrazovani o poslovanju i sposobni prijaviti točne, korisne informacije višim razinama menadžmenta. Ukoliko fale te sposobnosti, odgovor može biti donešen vođen lošom prosudbom, što može dovesti do osrednjeg rješenja problema ili loših preporuka.

Specifičnosti vezane uz DoS napad

"Napad uskraćivanja usluga (eng Denial of Service – DoS) je akcija koja sprečava ili onemogućuje ovlaštenu upotrebu računalne mreže, sustava ili programa iskorištavanjem resursa kao što je procesor (CPU), memorija, propusnost mreže i prostor na tvrdom disku.

Primjeri DoS napada su:

• zagušenje propusnosti računalne mreže stvaranjem neuobičajeno velikog broja mrežnih paketa,
• slanje posebno oblikovanih TCP/IP paketa poslužitelju s namjerom rušenja operacijskog sustava poslužitelja,
• slanje ilegalnih zahtjeva aplikaciji u svrhu rušenja programa,
• slanje zahtjeva procesoru za koje mu treba puno vremena da ih obradi (npr. slanje zahtjeva za kriptiranjem svakog odgovora poslužitelja),
• uspostavljanje velikog broja sjednica za prijavu na poslužitelj u svrhu sprečavanja korisnika od započinjanja sjednica za prijavu,
• slanje signala na istoj frekvenciji na kojoj radi bežični Internet u svrhu onemogućavanja pristupa legitimnih korisnika i
• zauzimanje prostora na tvrdom disku stvaranjem velikih datoteka i slično.

Mrežna propusnost koju organizacije koriste je uglavnom vrlo velika te je nemoguće uzrokovati uskraćivanje usluga upotrebom jednog računala koje stvara velik promet. Umjesto upotrebe jednog računala, napadač izvodi raspodijeljeni napad uskraćivanja usluga (eng. Distributed Denial of Service – DDoS) i koordinira napad upotrebom više računala. Ako napadač koristi dovoljno računala, opseg stvorenog mrežnog prometa može iskoristiti ne samo resurse ciljanog računala, već i blokirati propusnost mreže za cijelu organizaciju. DDoS napadi su postali popularni i njihove posljedice mogu uzrokovati velike financijske gubitke za napadnutu organizaciju.

U DDoS napadima napadači tipično koriste dva tipa komponenti:

• agente - posebni programski kod koji se pokreće na ugroženim računalima i obavlja stvarni napad i
• upravitelje agenata (eng. handler) – program koji upravlja agentima, govori im kada trebaju obaviti napad, što trebaju napasti i na koji način trebaju izvesti napad.

Agenti se još nazivaju botovima, a skupina računala na kojima se pokreću agenti nazivaju se botnet mreže. U nekim slučajevima napadač ne mora koristiti upravitelja agenata već može izravno davati naredbe botovima. Napadači često koriste velike botnet mreže računala koje se sastoje od tisuća agenata koji izvode napad. Slijedeća slika prikazuje tri koraka DdoS napada." [CARNet CERT, str. 18]

--Igor.trgovcic 14:46, 6. siječnja 2012. (CET)

Razumijevanje kako politike mogu pomoći koracima istrage

Svaki stav ogovora na incidente koji se prihvati treba imati odgovarajuću politiku. Ukoliko se nema zapisana politika, ona svejedno postoji. Razlika je u tome što, ako politika nije zapisana, postoje zakonske odredbe na razini države. Postoje mnogi zakoni koji se primjenjuju kako bi se računalna upotreba u organizaciji držala pod kontrolom. Drastični koraci istrage se nebi trebali činiti bez dodatne pravne potpore. Bilo kako bilo, uz prikladne politike, korporativni istražitelji mogu ubrzati svoju istragu. Uz prikladnu upotrebu politika, odgovoran pravni savjet, odgovarajuće tehničke sposobnosti, korporativni istražitelji mogu poduzimati aktivnosti koje predstavnici zakona ne mogu tehnički izvesti.

Postoji četiri aktivnosti u vezi odgovora na incidente koji mogu zahtijevati odobrenje predstavnika zakona, ali ne korporativnih istražitelja:

• Provođenje praćenja prometa na mrežama
• Provođenje praćenja cijelokupnog sadržaja mreža
• Pretraživanje i pregled računala zaposlenika
• Koordinacija sa stranicama povezanima s incidentom

U nastavku su detaljnije objašnjeni.

Kada se može provesti praćenje prometa na mrežama?

Provođenje praćenja prometa je manje napadan način praćenja rada mreže. Služi dvije svrhe:

• Zaštita privatnosti korisnika mreže
• Dozvoljavanje administratorima sustava pregled mreže i lociranje izvora tehničkih problema

Predstavnici zakona trebaju pribaviti potrebna zakonska odobrenja kako bi mogli provoditi praćenje, dok korporativni istražitelji mogu provesti praćenje prometa na svojim mrežama bez posebnih dozvola.

Kada se može provesti praćenje cjelokupnog sadržaja mreža?

Postoje mnoge situacije kada je praćenje cjelokupnog sadržaja mreže ključno kako bi se otkrile nezakonite i neautorizirane radnje i kako bi se ustanovio identitet pojedinaca koji poduzimaju takve radnje. Može se dobiti dozvola za praćenje od zaposlenika, ako postoje odgovarajuće politike. Tako da otkrivanje počinitelja postaje lakše ukoliko imamo odgovarajuće autorizacijske mehanizme. Tada znamo da je netko od počinitelja osoba koja ima autorizacijske podatke i za koju postoji dozvola za praćenje.

Kada se može pretražiti i pregledati računala zaposlenika?

Postoje zakoni koji određuju kada se smije pratiti komunikacija u realnom vremenu i kada se smije pregledavati sačuvane podatke o komunikaciji.

Koordinacija sa stranicama povezanima s incidentom

Korporativni istražitelji mogu tražiti dokaze od izvora povezanih s incidentom. Takva koordinacija može rezultirati brzim otkrivanjem počinitelja. Ako je uljez dobio pristup mrežama, osoblje na svim prijašnjim stranicama kroz koje je napadač prošao, može brzo pribaviti potrebne informacije. Predstavnici zakona obično trebaju sudski nalog kako bi došli do tih informacija, dok ih korporativni istražitelji mogu jednostavno zatražiti. U svakom slučaju, treba biti oprezan prilikom kontaktiranja prijašnjih stranica, jer se može dogoditi da se kontaktira i napadač. Potrebno je koristiti sigurne kanale kada se obavlja takva vrsta komunikacije.

Zaključak prednosti odgovarajućih politika

Postoji četiri vrste informacija koje korporativni istražitelji mogu pribaviti bez zakonske dokumentacije, za koje bi predstavnicima zakona ona bila potrebna:

• Informacije o pretplatniku – informacije za autoriziranog korisnika računalnog računa dobiven od administratora sustava.
• Informacije o transakcijama – informacije o računu.
• Elektronička komunikacija – sadržaj elektroničke komunikacije spremljen na računalu.
• Praćenje cijelokupnog sadržaja – praćenje sadržaja mreže uz odgovarajući pristanak.

--Igor.trgovcic 14:46, 6. siječnja 2012. (CET)

Razvoj politika prihvatljivih načina uporabe

Prije nego se počnu razvijati temeljna pravila sigurnosti i odgovora na incidente, mora se odlučiti tko je odgovoran za pisanje i ažuriranje politika, i isto tako tko treba provoditi te politike. Politike prihvatljivih načina uporabe utječu na sve u organizaciji: korisnike, menadžere, interne auditore, pravni odjel, administratore sustava i tehničko osoblje. Prema tome, svaka grupa na koju se politike odnose trebaju biti dio procesa njihovih odobravanja.

Postoje određeni savjeti kako razviti učinkovitu politiku prihvatljivih načina uporabe:

• Odlučiti kome se može vjerovati u mreži
• Usmjeriti zaposlenike prema politici prihvatljivih načina uporabe
• Biti doslijedan i jasan u politici prihvatljivih načina uporabe

U nastavku su detaljnije objašnjeni.

Odlučiti kome se može vjerovati

Prva odluka je tak kome se može vjerovati u mreži. Politika prihvatljivih načina uporabe će vjerojatno omogućiti organizaciji pravno stajalište za praćenje zaposlenika i isto tako pojedinaca koji koriste servise daljinskog pristupa. Tako da se treba odrediti dali se želi pratiti sve aktivnosti ili samo one odabrane. Dolazi do potrebe balansiranja između povjerenja zaposlenika i njihove fleksibilnosti nasuprot što sveobuhvatnijoj sigurnosti i nadgledanju.

Usmjeravanje zaposlenika

Kako bi politika bila učinkovita, mora se provesti kroz cijelu korporaciju i uključiti ju u novu orjentaciju zaposlenika. Kada je politika izrađena, svi ju trenutni zaposlenici trebaju pozitivno prihvatiti sa službenim potpisivanjem. Jedna od bitnih stavki dobre sigurnosti i učinkovitog odgovora na incidente je da je to grupni trud, gdje je svaki zaposlenik odgovoran za svoj dio.

Dizajniranje politika prihvatljivih načina uporabe

Kada se počne kreirati politika prihvatljivih načina uporabe, potrebno je sagledati sve u cjelini pa prema detaljima. Isto tako, bolje je kreirati više pojedinačnih politika nego jednu veliku. Prilikom dizajniranja politika treba zapamtiti da treba biti dosljedan u njihovom provođenju.

Dizajniranje od vrha prema dolje (Top down)

Potrebno je pregledati za koje tehničke, pravne i ativnosti ponašanja je potrebno imati kontrole. U nastavku slijedi primjer.

Tehničke:

• Tko smije dodavati i brisati korisnike?
• Tko smije daljinski pristupiti uređajima?
• Tko smije skenirati uređaje?
• Tko smije posjedovati datoteke s zaporkama i probiti ih?
• Tko dobiva pristup čemu?
• Dali je dozvoljeno pisati u grupe s novostima?
• Dali je dozvoljeno slati kratke poruke?

Ponašanje:

• Kakva upotreba weba je primjerena?
• Kako reagirati na seksualno maltretiranje?
• Tko smije nadzirati i kada?
• Tko smije posjedovati i koristiti hakerske alate?

Kreiranje pojedinačnih politika

Za organizaciju bi moglo biti bolje da kreira više manjih dokumenata politika radije nego izraditi jednu ogromnu politiku prihvatljivih načina uporabe. Manji dokumenti se lakše ažuriraju i lakše se s njima upravlja.

U nastavku slijede neki prijedlozi pojedinačnih politika.

• Politika dozvoljene upotrebe – uređuje kakvo ponašanje se očekuje od svakog korisnika.
• Politika daljinskog pristupa – utvrđuje tko smije pristupiti udaljenom sustavu i na koji način mogu pristupiti.
• Politika korištenja interneta – pokriva kako i kada korisnici smiju koristiti internet.

Razvoj procedura za odgovor na incidente

Objasnili smo utemeljenje politika koje sadržavaju ono što se planira napraviti. Procedure su implementacija politika organizacije. Npr. ako je politika odgovora istražiti sve incidente tada procedure obuhvaćaju utemeljenje nadgledanja mreže, istraživanje servera i održavanje točnih mrežnih karata.

--Igor.trgovcic 16:45, 6. siječnja 2012. (CET)

Kreiranje programskog alata za odgovaranje

Bez obzira na status mreže, središnje računalo i pripremu kroz politike, programski alat za odgovaranje mora biti spreman odgovoriti na incidente. Taj alat je ključna komponenta pripreme prije incidenta, i jedna je od rijetkih komponenti pod našom kontrolom. Programski alat za odgovaranje uključuje hardware, software i dokumentaciju korištenu prilikom odgovora.

Hardware

Forenzička hardwareska platforma korištena danas je snažna i moguće ju je konfigurirati. Koristi komponente pune veličine, ima priključke za eksterne uređaje, mrežnu karticu i uređaj za pisanje po optičkim medijima. Takva platforma je izdrživa i fleksibilna prilikom odgovaranja na incidente. Za takvu platformu su potrebni veliki tvrdi diskovi, SCSI kartica, mrežna kartica i optički uređaj. Procesor i memorija trebaju biti što snažniji, jer je vrijeme uvijek bitno prilikom odgovora.

Software

Mnogi specifični softwareski alati se koriste prilikom odgovora na incidente, kako bi se mogli istražiti različiti operacijski sustavi i aplikacije.

Neki od osnovnih komponenti softwareskog programskog alata su sljedeći:

• Nekoliko operacijskih sustava kao što su Windows NT, Windows 2000, Windows XP, Linux.
• Safeback, EnCase, DiskPro ili neki drugi forenzički softwareski paketi korišteni da se rekreira točna slika računalnih medija.
• Svi driveri za sav hardware (obavezno!)
• Nekoliko boot diskova
• Software koji omogućuje pregledavanje gotovo svih vrsta datoteka
• Slika kompletnih postavki na nekom mediju (DVD).

Dokumentacija

Tim računalne sigurnosti za odgovaranje na incidente mora dokumentirati sve aktivnosti i otkrića. Dokumentacija je potrebna za daljnje disciplinske, građanske ili kriminalne parnice, ali isto tako i za temeljit odgovor na incident. Ključna područja za doumentaciju uključuju kako je dokaz prikupljen, sve aktivnosti provedene i gdje i kako su dokazi čuvani. Kako bi se pojednostavila kompletna dokumentacija, postoje standardizirana izvješća i obrasci koji mogu biti od pomoći. Preporuka je da programski alat za odgovaranje na incidente ima oznake za dokaze.

--Igor.trgovcic 16:45, 6. siječnja 2012. (CET)

Osnivanje tima za odgovor na incident

Nakon što se dogodi incident računalne sigurnosti, tada je već prekasno okupiti tim stručnjaka za obradu incidenta. Ne možete očekivati od neutreniranog i nespremnog osoblja da uspije! Vi ćete htjeti osoblje koje želi raditi, koje obraća pažnju na detalje, drži sve pod kontrolom, ne požurivaju važne stvari, a dokumetiraju što rade. Ovdje ćemo razmatrati dodjeljivanje vođe tima i tehničkog osoblja za tim za odgovor na incident. Ovdje ćemo pogledati neke temelje za osnivanje nekog tima.

Odlučivanje o misiji tima

Misija vašeg tima računalne sigurnosti za odgovaranje na incident(CSIRT) može postići sve ili gotovo sve od sljedećeg:

• Odgovor na sve sigurnosne incidente ili na sumnjiv incidenate korištenjem organiziranog, formalnog istražnog postupka
• Provesti potpunu istragu bez pristranosti (dobro, koliko je to moguće)
• Brzo potvrditi ili odagnati bilo provale ili sigurnosni incident koji se zapravo dogodio
• Procijeniti štete i opseg incidenta
• Uspostaviti 24/7 telefon za klijente za vrijeme trajanja istrage
• Kontrola i sadržaj incidenta
• Prikupiti i dokumentirati sve dokaze vezane uz slučaj
• Održavanje lanca (štite dokaza nakon prikupljanja)
• Odaberite dodatnu potporu kada je to potrebno
• Zaštitite prava privatnosti utvrđenih zakonom i / ili korporativnom politikom
• Osigurati vezu za pravilnu provedbu zakona i zakonskih ovlasti
• Održavanje odgovarajuće povjerljivosti incidenta za zaštitu organizacije od nepotrebnih izlaganja
• Osigurati vještačenje
• Osigurati upravljanje preporukama rukovanja incidentom koje se u potpunosti podupirane činjenicama

--Marija Gelo 19:16, 6. siječnja 2012. (CET)

Obuka tima

Važnost dobre obuke je jako bitna. Danas postoje mnogi tečajevi koje pružaju obuke za odgovore na incidente, i sami ti tečajevi su jako dobri. Neke od tih institucija koje nude te tečajeve su Foundstone, Carnegie Mellon i SANS. Isto tako dobra stvar je da se tim priključi nekim profesionalnim organizacijama da bi nastavili svoje obrazovanje ili da se druže s pojedincima koje mogu pozvati kao pomoć na jedan dan. Većina onih koji provode zakon i privatnih tvrtki koji reagiraju na incident računalne sigurnosti imaju uvid u svu vašu vitalnu imovinu, pa tako mogu nehotice prikupiti određene podatke koji nisu u okviru orginalnog incidenta, tako npr. agenti za provedbu zakona mogu saznati tko vara svog supružnika, tko koristi drogu ili tko ima kaznenu povijest. Postoji nekoliko profesionalnih organizacija koje omogućavaju časnicima za provedbu zakona da se pomiješaju sa profesionalaca za računalnu sigurnost:

• InfraGard - FBI program osmišljen za rješavanje potreba za privatnim i javnim sektorom za razmjenu informacija, na nacionalnoj i lokalnoj razini
• High Technology Crime Investigation Association (HTCIA) - Udruga za poticanje i olakšavanje razmjene informacija koje se odnose na istrage za računalni incident računalo i sigurnost
• Information Systems Security Association (ISSA) - neprofitabline međunarodne organizacije informacijske sigurnosti profesionalaca i praktičara. On pruža obrazovne forume, publikacije i međusobne interakcije
• Forum of Incident Response and Security Teams (FIRST) - koalicija koja okuplja timove za odgovor na incident vlade, komercijalnih i akademskih organizacija.

--Marija Gelo 19:16, 6. siječnja 2012. (CET)

Nakon otkrivanja incidenta

Ovdje ćemo govoriti što treba napraviti nakon što se određeni incident otkrije ili sumnja se na njega. Nakon prvog početnog odgovora na incident, govorimo o različitim strategijama koje možete uzeti u obzir. Tijekom početne faze odgovora, morate uzeti najmanje nametljiv istražne korake, dok koordinirate i sastavljate vaš tim stručnjaka za obradu incidenta.

Pregled faze početnog odgovora

Odmah nakon upozorenja da je možda došlo do incidenta računalne sigurnosti,vaša organizacija će biti suočena s mnogim izazovima, i trebat će vam proces koji potiče sljedeće:

• Brzo i učinkovito donošenje odluka
• Brza akumulacija informacija u forenzičkom ispravanom načinu
• Pravilno eskalacija incidenta
• Brza obavijest sudionika potrebnih za okupljanje tima računalne sigurnosti za odgovaranje na incident

Kako bi svladali te izazove, trebat će vam dokumentiran, dobro uvježban postupak. Na idućoj slici možete vidjeti korake početnog odgovora na incident.

Dobivanje preliminarne informacije

Jedan od prvih koraka bilo kojeg istraživanja je dobivanje dovoljno informacija kako bi se odredio odgovarajući odgovor. To je cilj faze početnog odgovora. Početni odgovor vaše organizacije trebao bi uključivati aktivnosti kao što su :

• Primanje početne obavijesti o incidentu
• Zapisivanje detalja nakon početne obavijesti , uključujući deklaraciju incidenta
• Sastavljanje CSIRT-a
• Izvođenje tradicionalnih istražnih koraka
• Provođenje intervjua
• Određivanje da li je incident eskalirao ili ne

Ideja je da prikupiti dovoljno informacija da se razvije odgovarajuća strategija odgovora.

Dokumentranje koraka koje treba poduzeti

Druga svrha faze početnog odgovora je dokumentiranje koraka koji se moraju poduzeti. Takva organizacija i disciplina sprječava paniku kad se incident otkrije. Strukturirani početni odgovor također promiče formalno izvještavanje i potiče održavanje dobre metrike. Zapisivanjem pojedinosti o incidentu na organizirani način, vaša organizacija će imati točan broj (ili barem precizniji broj) vrste napada koji se dogodi, njihovu učestalost, štete uzrokovane tim napadima, kao i učinke tih napada na vašu organizaciju. Takva mjerenja su kritična za mjerenje povrata na ulaganje (ROI).

Uspostavljanje procedure bilježenja incidenta

Provedba snažnog programa odgovora na incident zahtijeva sudjelovanje svih zaposlenika. Međutim, ne možete očekivati da svi unutar vaše organizacije budu tehnički sposobni ili da stave kao svoj prioritet odgovor na incident Budući da nikad ne znate tko će posrnuti u digitalni zločin prvi, važno je uspostaviti bilježenje procedure za korisnike da bi izvijestili potencijalne incidente sigurnost računala.

Trebali biste obavijestiti krajnje korisnike kako prijaviti incidente (putem telefona, e-mail, intranet web stranice, ili drugi način). Također, razmislite o stvaranju plakata o svijesti računalne sigrunosti, takav plakat može poslužiti kao uvijek prisutan podsjetnik za svoje zaposlenike kako bi biti oprezan.

Izrada procesa odgovora za incident jasnog za korisnike pomoći će izbjeći zbunjenost. Zaposlenici trebaju vježbati zbog marljivost i prijaviti incident sudioniku CSIRT-a (obično help desk). Mnoge organizacije koriste helpdesk za rješavanje problema krajnjih korisnika. Dobra je ideja napraviti checklistu početnog odgovora specialno za help desk zaposlenike koji nisu profesionalci za sigurnost, ali su prva linija u procesu izvještavanja incidenta. Cilj faze početnog odgovora je imati iskusne veterane koji mogu preuzeti kontrolu nad situacijom. Stoga, najvažniji cilj programa svijsnosti računalne sigrunosti je olakšati pokretanje i uključenost CSIRT-a.

--Marija Gelo 19:21, 6. siječnja 2012. (CET)

Zapisivanje detalja nakon početne detekcije

Provedba organiziranog programa odgovora na incident traži checkliste. Jedna od takvih checklista je checklista za početni odgovor, za zapisivanje detalja nakon početne obavijesti o incidentu. U ovom trenutku, ako je moguće da incident dogodio, možete i proglasiti incident.

Checkliste za početni odgovor

Predlaže se da se koristi checklista za početni odgovor kao mehanizam za zapisivanje okolnosti oko izvještavanja o incidentu. Te checkliste možemo podijeliti u dva dijela : jedna za opće informacije i jedna za više pojedinosti.

Prvi dio checkliste za početni odgovor

Prvi dio checkliste za početni odgovor je manje tehnički dio, koji se koristi za upit prvih odgovarača (krajnji korisnik) za sljedeće podatke:

• Datum kad je incident otkriven ili počeo
• Kontakt informacije osobe koja popunjavanja obrasac
• Kontakt informacije osobe koja je otkrila incident
• Vrsta incidenta
• Lokacija kompjutera pogođenom incidentom
• Datum kad je incident prvi put primjećen
• Opis fizičke sigurnosti na mjestu
• Kako je incident otkriven
• Tko je pristupao ili dotaknuo relevantne sustave od početka incidenta
• Tko je imao fizički pristup ugroženom sustavu od početka incidenta
• Tko trenutno zna o incidentu

Drugi dio checkliste za početni odgovor Drugi dio checkliste za početni odgovor može biti korišten od članova CSIRT-a za rješavanje tehničkih pojedinosti oko incidenta. Vrlo je vjerojatno da će CSIRT član morati osobno odgovoriti na dobivanje i zapisivanje ove informacije. Checkliste za početni odgovor se može koristiti za rješavanje sljedećih pitanja:

• sustav pojedinosti
• napraviti i modelirati relevantne sustave
• operacijski sustav
• primarni korisnici sustava
• administrator sustava za sustav
• mrežne adrese ili IP adrese relevantnih sustava
• naziv mreže sustava
• postoji li modem veza na sustav
• kritične informacije koje bi mogle biti u sustavu
• incident zatvorenost
• da li je incident u tijeku
• da li je nadgledanje mreže potrebno ili se već provodi
• da li je sustav i dalje spojen na Internet/mrežu, ako ne, tko je ovlašten za micanje sustava iz mreže i kad će opet biti online
• da li postoji backup za odgovarajuće sustave
• da li su poduzete korektivne mjere do sada (kao filtiranje paketa, nova pravila vatrozida ili nekih drugih protumjera)
• da li su prikupljene informacije pohranjene na zaštićen,falsificiran način
• preliminarna istraga
• IP adrese uključene u incident
• da li su već poduzeti istražni koraci ili akcije
• da li se trebaju napraviti forenzičke kopije relevantnih sustava ili logička kopija relevantnih sustava je dovoljna

Možete vidjeti da u drugom dijelu checkliste za početni odgovor zahtijeva dublje znanje za svoje zahtjeve. Te stavke su više usmjerene prema incidentima računalnih provala ili mrežnih napada, ali je informacija također važna za odgovaranje na druge incidente, kao što su unutarnja pitanja ljudskih resursa.

Bilješke o slučaju

Iako se preporučuje da organizacija sama napravi svoju checklistu, neki misle da su takve checkliste glomazne ili su zbunjujuće. Isto tako je moguće da vaša organizacija ne može provesti program odgovora na incident putem checkliste zbog političkih ili novčanih problema. Ako se neka organizacija ipak ne odluči za checkliste, onda je poželjno i korisno koristiti bilješke o slučaju.

Bilješke o slučaju je sva dokumentacija koja bilježi korake koji su poduzeti tijekom procesa odgovora na incident. Savjet od članova CSIRT je održavanje dobro pisanih bilješki i detalja oko incidenta. Ove bilješke mogu stvoriti temelj za kazneni ili građanski postupak, i bez checkliste, te bilješke će biti presudne za ubrzanje svakog slučaja koji vaša organizacija želi uspostaviti. Učite članove vašeg tima da dokumetiraju "tko, što, kada, gdje i kako" informacije koje okružuju incident.

--Marija Gelo 19:21, 6. siječnja 2012. (CET)

Deklaracija incidenta

Kada je izvješteno o nekoj sumnjivoj aktivnosti, većinom odmah se vidi da li zapravo ta aktivnost incident računalne sigurnosti ili ne. No, u nekim slučajevima, može biti teško utvrditi na temelju checkliste da li se incident dogodio. Ako još uvijek nije jasno da li je neka sumnjiva aktivnost incident, ta se aktivnost treba tretirati ako incident sve dok se istragom ne pokaže drugačije. Ali da se ne troši mnogo vremena na ne incidente, postoje neka pitanja koja se mogu razmatrati :

• Da li postoji postavljeni sustav ili ispad mreže koja je uzrokovala nedostupnost sredstava u vrijeme kad je incident prijavljen?
• Da li postoji izvanredni ili nespomenut ispad usluga mreže koja je uzrokovala nedostupnost sredstava tijekom vremena kad je sumnjivi incident prijavljen?
• Da li zaraženi sustav nedavno nadograđen, rekonfuguriran ili na neki drugi način izmjenjen da uzrokuje sumnjivu aktivnost koja je prijavljena?
• Da li se obavljalo testiranje na mreži koje bi zaključalo račun ili uzrokovao nedostatak sredstava?
• Za unutranje incidente, ima li opravdanja za aktivnosti koje je zaposlenik napravio koje uklanjaju ili ublažuju sumnju?

Ako ne možete odmah reći da li je došlo do incidenta, preporučuje se da se dodijeli slučaj incidenta ili broj incidenta, praveći incident vrijedan truda. Nakon što se deklarira incident, to znači da incident ima broj incidenta incident broj koji će se koristiti kao posebna oznaka tog incidenta. Brojevi incidenta često su izrađeni na način koji pokazuje kronologiju, kao i vrstu incidenta. Pa bi zbog toga možda željeli razviti sustav numeriranja incidenta koji vam omogućuje praćenje kronologije incidenata vašeg istraživanj i ukazivati na tipa incidenta.

--Marija Gelo 19:16, 6. siječnja 2012. (CET)

Sastavljanje tima računalne sigurnosti za odgovaranje na incident(CSIRT)

Mnoge organizacije formiraju CSIRT tim kao odgovor na određenu situaciju ili događaj, a ne osnovane, centralizirane timove koji su posvećeni regiranju na incidente. Stoga, tim CSIRT treba biti popunjen u realnom vremenu, nakon što je incident otkriven. Da bi sastavili tim ispravo za određeni incident, vaša organizacija mora utvrditi vrste vještina i resursa koji su potrebni da bi se odgovorilo na određeni incident. Različita organizacijska područja mogu doprinijeti hardverskom, softverskom i tehničkom znanju i radnoj snazi za potporu odgovora na incident. Znajući koga kontaktirati i kada je jedan od najvećih izazova za odgovor na incident. Međutim, ne biste htjelo proći kroz procese obavještavanja i eskalacije incidenta dok niste sigurni da se incident dogodio.

Sastavljanje CSIRT-a zahtijeva sljedeće aktivnosti:

• Određivanje postupaka eskalacije
• Provedbu obavještavanja
• Opseg incidenta i sastavljanje resusra, uključujući i dodjeljivanje vođe tima i tehničkog osoblja

Određivanje postupaka eskalacije

Svaki incident ne zahtjeva odgovor s međunarodnim CSIRT-om mobiliziranim za najgori mogući scenarij. Treba se odrediti da li će neki incident biti obrađen na lokalnoj razini ili korporativnoj. Obično incidenti koji uključuju unutarnje zaposlenike obrađivaju lokalno, utječu samo na lokalne jedinice poslovanja, i ne uključuju krađu poslovnih tajni ili otkrivanje podataka klijenta, biti će obrađeni na lokalnoj razini. Više teški incidenti koji uključuju autsajdere ili utječu na više lokacija mogu biti obrađene na korporativnoj razini. Tablica obuhvaća mnoge od uobičajenih incidenata koji mogu biti prijavljena i pruža smjernice kako bi mogli eskalirati incidenata u vašoj organizaciji. Dok Tablica 1 daje smjernice koga obavijestiti kada se dogodi incident, ona ne spominje kada.

Provedba obavještavanja

Vaša organizacija mora imati središnje mjesto kontakta za sve otkrivene ili sumnjive incidenate. Ova točka kontakta treba biti stalni član vašeg CSIRTa, koji je dobro upućen u vaše organizacijske eskalacije i obavještavanja. Te točke kontakta za svoju organizaciju, CSIRT članovi trebju biti uspostavljene puno prije nego što se dogodi incident. Checklista za obavještavanje treba sadržavati podatke potrebne za kontaktiranjei svih igrača, uključujući i predstavnike iz svih mogućih sastavnica vašegCSIRTa.

Preporučuje se da se održavaju točke kontakta za ljudske resurse, opće savjete, mrežne operacije, korporativnu istragu, fizičku sigurnost, vanjsko provođenje zakona, različite poslovne jedinice unutar vaše organizacije, i bilo koji drugi element kritičan za vaš program odgovora na incident. Vaši CSIRT članovi moraju znati pravila sudjelovanja.

To znači da su trebaju znati kada koristiti kontaktne informacije zabilježene u vašoj organizacijskoj checklisti za obavještavanje i kada obavijestiti odgovarajuće pojedince za incident u tijeku ili dobiti njihovo sudjelovanje u procesu odgovora na incident. Unutarne istrage obično zahtijevaju različita pravila o obavijesti nego vanjski incidenti sigurnosti. Što više ljudi obavijestite o unutranjoj istrazi, veće su šanse da će predmet vaše istrage nać da su on ili ona središte vaše istrage. Dakle, vaše obavijesti trebaju uključivati samo osobe koje:

• trebaju znati o istrazi
• koje mogu zapravo pomoći u istrazi
• neće biti zbunjene, u panici ili na neki drugi način ometati istragu
• nisu bliski prijatelji osumnjičenog

Opseg incidenta i sastavljanje resusra, uključujući i dodjeljivanje vođe tima i tehničkog osoblja

Odgovor na incident većinom zahtjeva brze odluke, a brzina kojom ste djelovati često štedi vrijeme i novc vaše organizacije, kao što i odražava njezin ugled. Budući da demokratski proces ne donosi brze odluke, morate imenovati sposobne glavne istražitelje, ili vođe tima, za CSIRT. Prvi korak u sastavljanju CSIRT je utvrditi stručnost potrebnu za rad. Na primjer, ako je Cisco router žrtva incidenta, Cisco stručnjak bi trebao biti u timu. Broj i vrsta osoba u tim ovisi o ovim čimbenicima:

• Broj domaćina koji su uključeni u incident
• Broj operacijskih sustava koji su uključeni u incident
• Broj sustava koji su uključeni, ranjivi, ili iskorišteni
• Vremenski okvir u kojem istragu treba ostvariti
• Potencijalna izloženost ili profila slučaja
• Želja vaše organizacije za većim ili manjim timom
• Da li je pranica moguća
• Da li je istraga interna
• Da li je predmet istrage svjestan istrage

Dodjela vođe tima

Sva računalom povezana straživanja zahtijevaju profesionalce koji razumiju i tehničke aspekte incidenta i istražni postupak za incidente računalne sigurnosti. Vaša organizacija mora odrediti nekoga tko će ispuniti ulogu vođe tima koji može odmah obuhvatiti incident i dobiti pravo osoblje kako bi mu pomoglo u brzom donošenju odluke. Kako bi se osigurali da ste odabrali učinkovitog vođu tima, potrebno je odabrati nekoga tko može ostvariti sljedeće zadatke:

• Upravljanje vašim organizacijskim CSIRTom tijekom cijelog procesa odgovora
• Upravljanje procesom intervjua kada pričamo sa svjedocima, administratorima sustava, krajnjim korisnicima, pravnim savjetnicima, menadžerima i drugim
• Osigurati izvješća o stanju i komunicirati sa menadžmentom o napretku odgovora
• Uvjerite se da su korištene najbolje prakse i pravilne tehnike odgovora
• Osigurati sveobuhvatnu analizu incidenta
• Zaštitite dokaza stečenih tijekom istrage
• Obavite forenzička umnožavanja i analize ako je potrebno
• Sastaviti, upravljajte i predstavite istražna izvješća i ponude preporuke za upravljanje
• oRazumite pravna pitanja i korporativne politike
• Osigurati nepristranu istragu bez sukoba interesa

Dodjela tehničkog osoblja

Dok vaš vođa tima može biti posvećen incidentu puno radno vrijeme, vaši članovi tima mogu pomoć u istrazi na skraćeno radno vrijeme i privremeno. To je posebno za manje organizacije koje se ne mogu opskrbiti sa osobljem s punim radnim vremenom. Obično, morat ćete zatražiti pomoć od drugih poslovnih jedinica i stvoriti CSIRT sastavljen od odgovarajućih tehničkih savjetnika.Tehnički savjetnik je zaposlenik ili izvođač koji razumije detalje sustava i tehnologije uključene u istrazi. Vaša organizacija treba dobiti onoliko koliko je potrebo tehničkih savjetnika za pravilno odgovaranja na incident. Ove osobe trebaju imati sljedeće kvalitete:

• Kompletno znanje operativnih sustava uključenih sustava
• Sposobnost za pregled evidencije i drugih dokaza i jasno izvještavati
• Razumijevanje odgovarajućih tehnika rukovanja dokazima
• Sposobnost za obavljanje odgovarajuće procjene štete
• Sposobnost za utvrđivanje prirode incidenta i identificiranje specifičnih tehničkih pojedinosti
• Sposobnost da se preporuči kako popraviti stanje
• Kapacitet za održavanje perspektive da je tehnološki dokazi mogu biti kritični za rješavanje incidenta
• Vještine dokumentiranja za zapisivanje svih istražnih koraka jasno i sažeto
• Sposobnost da se da potpora vođi tima
• Sposobnost za obavljanje intervjua kada je to potrebno

Nakon što je CSIRT ili istražni tim sastavljen, spremni ste za početak istrage.

--Marija Gelo 19:21, 6. siječnja 2012. (CET)

Izvođenje standardnih istražnih koraka

Faza istrage uključuje određivanje tko, što, kada, gdje, kako i zašto okružuje incident. Jedan od najboljih načina da se pojednostavne tehnička istraživanja je podijela dokaza koje prikupite u tri kategorije:

• host baziran dokaz - ovaj podatak obično je prikupljen iz Windows ili Unix sustava ili uređaja koji su zapravo uključeni u incident (žrtve sustava ili sustav koji se koristi u cilju kaznenog djela)
• mrežno baziran dokaz - ovaj tip dokaza obično je prikupljen od routera, IDS, nadziranja mreža, ili neki mrežni čvor ne odmah uključen u incident
• ostali dokazi - u ovoj kategoriji, obično opisuje podatke o svjedočenju koji doprinosepredmetu, kao što su motiv, namjera, ili neki drugi nedigitalni dokaz.

Informacije koje ste dobili iz ove tri kategorije će vam pomoći odgovoriti na preliminarna pitanja koja ćete možda imati nakon nesreće. Kategorija ostali dokazi uključuje svjedočenje i ostale informacije dobivene od ljudi. To je zbirka dokaza nakon više tradicionalnih, ili netehničkih istražnih tehnika. To je kada se prikupljaju osobne datoteke, intervju zaposlenika,intervju svjedoka incidenta i dokumentirane prikupljene informacije. Ostali mogući izvori podataka uključuju vremenske kartice, vrpce video kamera, evidencije zaposlenika (kao što su performanse mišljenja i kršenja sigurnosti), sustavi govorne pošte, telefonski poziv, i faks. Kad god je moguće, ove informacije trebaju biti prikupljene prije uzimanja bilo kakvih tehničkih prikupljanja podataka.

--Marija Gelo 19:16, 6. siječnja 2012. (CET)

Vođenje intervjua

Ako se saznaje o sumnjivom incidentu, prvi korak je početi s upitom tko, što, kada, gdje i zašto pitanjima. Ova pitanja vam omogućujui da utvrdite neke činjenice oko incidenta, kao što su lokacija relevantnih sustava, administrativne kontakte, što se moglo dogoditi i kada, i tako dalje. Iako je odgovor na svako pitanjemožda neće biti dostupan, što više odgovora možete dobiti, to će biti lakše vama procijeniti situaciju. Evo nekoliko važnih pitanja koje trebate pitati dok formirate početnu hipotezu o incidentu:

• Što se dogodilo?
• Kada se to dogodilo?
• Koji sustavi su relevantni / ugroženi / uključeni?
• Tko bi to mogao napraviti?
• Tko koristi ugrožene / relevantne sustave?
• Koje akcije su već poduzete?
• Koja je korporativna politika na takav incident?

Trebat ćete prilagoditi pitanja incidentu. Pitajte pitanja polako i zapišite sve odgovore. Točnost je najvažniji kriteriji. Recite ljudima s kojim pričate da uzimate bilješke i zamolite ih da uspore kada je to potrebno.

Dobivanje kontakt informacija

Budite sigurni da ste dobili sljedeće informacije o svakom pojedincu s kojim ste imali intervju tijekom istrage:

• puno ime i prezime
• poslovna titula
• ime tvrtke
• telefonski broj
• e-mail adresa

Ovi identificirajući podaci su kritična ako trebate kontaktirati te ljude za dodatne informacije. Kada pravite izvještaj, trebali biste uključiti sve kontakt informacije za svaku osobu koja vam pruža informacije (ili vam ne pruža ništa, ali ste je intervjuirali).

Intervjuiranje administratora sustava

Mnogi sumnjivi incidenti mogu se klasificirati kao neincidenti nakon razgovora s administratorom sustava ili krajnjim korisnikom. To je osobito istinito kada obavijest o sumnjivom incidentu dolazi od vatrozida ili IDS. Često, intervjui su sve što je potrebno za dijagnosticiranje sumnjivog incidenta i formuliranje strategije odgovora.

Evo nekoliko primjera pitanja za administratore sustava:

• Jeste li primjetili bilo kakve nedavne neobične aktivnosti?
• Koje aplikacije pružaju daljinski pristup u sustav?
• Koliko ljudi imaju administratorski pristup sustavu?
• Koje su prijavne sposobnosti sustava i mreža?
• Koje sigurnosne mjere su trenutno poduzete u sustavu?

Intervjuiranje menadžera

Menadžeri često imaju vrijedne uvide u poslovne utjecaj i štete uzrokovane sigurnosnim incidentima. Često presudno kod intervjuiranja menadžera odrediti koji su rizici uključeni u sigurnosni incident i kakva šteta je uistinu učinjena. Evo nekoliko primjera pitanja za menadžere:

• Ima li nekih posebno osjetljivih podaka i aplikacija u sustavu?
• Postoje li kadrovska pitanja kojih bismo trebali biti svjesni?
• Je li bilo ikakvih testiranja propusnosti ovlaštenih za sustav ili mrežu?
• Koji je najgori mogući scenarij koji se može odigrati na temelju onoga što znamo o ovom incidentu?

Intervjuiranje krajnjih korisnika

Krajnji korisnici mogu pružiti relevantne informacije, osobito u slučajevima u kojima su krajnji korisnici prijavili sumnjive aktivnosti. Krajnji korisnici može opisati neprirodan način ponašanja u sustavu na koristan način. Na primjer, jedan od najčešćih izvješća koje smo vidjeli od korisnika Windowsa je: "Moje računalo bio pod kontrolom, ali ne mojom tipkovnicom i mišom ". Administrator sustava bez znanja softvera virtualne mreže računalna (VNC) će vjerojatno odbaciti to izvješće kao samo još jedan ludi korisnik. No, bilo koji iskusan istraživač bi odmah izvukao bitne podatke koji proizlaze iz promatranja krajnjeg korisnika i prepoznao VNC backdoor-miljenika hakera.

--Marija Gelo 19:21, 6. siječnja 2012. (CET)

Izrada strategije odgovora

Vaša strategija odgovora nedvojbeno najvažniji aspekt odgovora na incident. To je faza u kojoj razmatrate koje korektivne korake treba poduzeti za oporavak od incidenta. Vaša strategija može također uključivati pokretanje štetne radnje protiv unutarnjeg zaposlenik ili vanjskog napadača. Bez obzira na okolnosti, vjerojatno će zahtijevati više brainstorming-a da odredite najbolji način odgovora za vašu organizaciju.

Razmatranja o strategiji odgovora

Vaša strategija odgovora treba uzeti u obzir sve što znamo o incidentu, što se promijenilo tijekom vremena, a zatim faktor u političkom, tehničkom, pravnom i poslovnom utjecaju koji se treba uzeti u obzir. Dakle, razvoj strategije odgovora može biti iterativan proces, a vi možete prethoditi mnoge mogućnosti prije nego što konačni odgovor strategije provode. Upravljanje poslovnom linijom, upravljanje ljudskim resursima, IT sigurnost, i pravne savjeti mogu biti uključeni u definiranje i odobravanje strategije, ovisno o prirodi incidenta. Ova razmatranja dalje kompliciraju i usporavaju proces. Ovo su neki zajednički faktori koje ćete vjerojatno uzeti u obzir prilikom utvrđivanja vaše strategije odgovora :

• Ima li vaša organizacija ima formalni / javni stav o odgovoru na napade da ga se mora pridržavati kako bi bio u skladu s kupcima i medijima?
• Je li osumnjičeni napad iz inozemstva, čineći ga teškim slijediti tehnički i legalno?
• Postoje li bilo kakvi pravni zahtjevi koji mogu utjecati na odgovor?
• Može li se riskirati javno objavljivanje incidenta klijentima ili javnost?
• Kako ste provodili slične incidente u prošlosti?
• Koji su prošlii zapisi / radni učinci pojedinaca koji su uključeni?
• Hoće li istraga koštati više od očekivanog?

Politika provjere

Kada reagirati na incident, akcije koje se mogu poduzeti određuju ne samo tehničke pojedinosti slučaja, ali i postojeća politika vaše organizacije. Jedan od prvih koraka koje treba poduzeti tijekom početne procjene je utvrđivanje postojeće politike, jer se mnoge radnje mogu poduzeti samo ako je to primjereno postojećoj politici.

Nadalje, status istraživača utječe koje akcije će biti poduzete. Na primjer, osobe za provedbu zakona općenito imaju veća ograničenja od administratora odgovornih za pogođene sustave. Najveći prioritet treba biti određivanje politike dviju od najvažnijih temeljnih potreba projekta: nadzor mreže i računalna forenzike. Nadzor mreže i forenzička ispitivanja računalnih sustava općenito su kritične za istraživanja mrežnih upada. Međutim, bez odgovarajuće politike, praćenje može biti ograničeno. Također, pobrinite se da bilo koji postojeći prihvatljivi način uporabe i suglasnost za praćenje pravila primijenite na svoju situaciju. Opće pravilo je da ne pretpostavljate ništa, osobito kad kazne za pogreške mogu biti teške, moguće da uključuju osobne i građanske odgovornosti.

--Marija Gelo 19:16, 6. siječnja 2012. (CET)

CERT organizacije

„CERT organizacije su zadužene za pružanje potpore i obrane od napada na računalne sustave, kao i za razmjenu informacija te surađivanje s vladom, industrijom i međunarodnim partnerima. Osim CERT organizacije, postoji i CERT koordinacijski centar (CERT Coordination Center – CERT/CC)) koji predstavlja opširniji CERT program. Program je usredotočen na identificiranje i rješavanje postojećih i potencijalnih sigurnosnih prijetnji, uključujući obavještavanje i obrazovanje administratora i drugog tehničkog osoblja organizacije, koordinaciju sa skupinama za rješavanje sigurnosnih incidenata u svijetu. CERT/CC je glavni centar za rješavanje računalnih sigurnosnih problema. Prvi je osnovan u studenom 1988. godine u Sjedinjenim Američkim Državama, nakon napada crva „Morris Worm“ koji je srušio velik dio Internet mreže i ukazao na mnoge propuste u mrežnoj sigurnosti. Ubrzo nakon tog događaja DARPA (eng. Defense Advanced Research Projects Agency) je osnovala institut SEI (eng. Software Engineering Institute) koji je imao sposobnost brzo i učinkovito koordinirati komunikaciju među stručnjacima u slučaju sigurnosnog incidenta.

CERT/CC osoblje pruža tehničke savjete i koordiniraju odgovore na sigurnosne incidente, identificiraju trendove u napadačkim metodama, analiziraju ranjivosti programskih paketa te pružaju načine rješavanja sigurnosnih problema u budućnosti. Zbog rasta Interneta i pojave profinjenih tehnika napada javlja se potreba za dodatnim resursima i mogućnostima rješavanja sigurnosnih problema. Kako bi se ostvarili dodatni resursi i mogućnosti CERT/CC je postao dio CERT programa. Ostala područja CERT programa uključuju edukaciju, istraživanje i razvoj, obavještavanje javnosti, forenziku i globalnu suradnju.“ [CARNet CERT]

Tipovi CSIRT organizacija

"Postoje različiti tipovi CSIRT (eng. Computer Security Incident Response Team)organizacija. Neke su namijenjene pružanju potpore cijelim državama. Na primjer Japanski CERT (eng. Japan Computer Emergency Response Team Coordination Center - JPCERT/CC) je jedna od takvih organizacija. Osim toga, postoje i one CSIRT organizacije koje pružaju pomoć određenoj regiji u svijetu, kao što je AusCERT za azijsko-pacifičko područje, te one koje pružaju svoje usluge sveučilištima i komercijalnim organizacijama. Postoje i korporacijske grupe koje nude CSIRT usluge klijentima uz proviziju. Neke od glavnih skupina CSIRT organizacija uključuju slijedeće:

• Unutarnji CSIRT – pruža usluge rukovanja incidentima svojim partnerskim organizacijama. To može biti CSIRT za banku, tvornicu, sveučilište ili vladinu agenciju.
• Nacionalni CSIRT – pruža usluge rukovanja incidentima državi. Na primjer, Japanski CERT (JPCERT/CC) ili Singapurski CERT (SingCERT).
• Koordinacijski centri – koordiniraju i olakšavaju upravljanje incidentima među raznim CSIRT organizacijama. Na primjer CERT koordinacijski centar (CERT/CC) ili US-CERT (eng. United States – CERT).
• Centar za analizu – usredotočen je na prikupljanje podataka iz različitih izvora i utvrđivanje trendova i uzoraka u pojavi sigurnosnih incidenata. Prikupljene se informacije mogu koristiti za predviđanje budućih incidenata te za rana upozorenja.
• Prodavačke skupine – upravljaju izvještajima o ranjivostima u svojim programskim paketima i uređajima. Mogu se formirati unutar organizacije i određivati jesu li proizvodi ranjivi te u slučaju da jesu razviti strategije koje uklanjaju problem i smanjuju posljedice.
• Organizacije za rješavanje incidenta - pružaju usluge upravljanja incidentima uz proviziju drugim organizacijama." [CARNet CERT, str. 9]

--Marina Marković 6. siječnja 2012. (CET)

Registar hrvatskih CERT-ova

CARNet CERT

Web URL: http://sigurnost.carnet.hr
Korisnici: Svi korisnici unutar .carnet.hr domene

Želite li prijaviti računalno-sigurnosni incident u koji je uključena akademska ili obrazovna zajednica Hrvatske, svakako kontaktirajte CARNetov CERT na e-mail adresu cert@carnet.hr. U slučaju da šaljete povjerljive podatke, preporuča se korištenje PGP/GPG enkripcije.

Javni PGP ključ CARNetovog CERT-a može se nabaviti na svim većim poslužiteljima za razmjenu PGP ključeva ili ovdje: https://sigurnost.carnet.hr/kontakt/ccert-PGP.

Prijava računalno-sigurnosnih incidenata "Računalno-sigurnosni incident je svaki događaj koji narušava barem jedan od aspekata računalne sigurnosti (prema CIA modelu – Confidentiality, Integrity, Availability), odnosno za posljedicu ima gubitak povjerljivosti, cjelovitosti ili raspoloživosti podataka, odnosno sustava koji te podatke poslužuje, obrađuje, prenosi ili pohranjuje. To bi, drugim riječima, značilo da je, kao posljedica računalno-sigurnosnog incidenta informacija postala neovlašteno dostupna nekome, informacija je promijenjena ili je prestala biti dostupna svojim legitimnim korisnicima.

Što treba sadržavati prijava? Kako bi vam CARNet CERT bio u mogućnosti pomoći potrebno je da vaša prijava incidenta sadrži osnovni skup podataka nužnih za uspješnu obradu incidenta. Podaci koje prijava mora sadržavati su:

• IP adresa i/ili ime računala koje je izvor napada
• IP adresa i/ili ime računala koje je napadnuto
• izvod iz log datoteke ili slični podaci iz kojih je moguće rekonstruirati o kakvoj se vrsti računalno-sigurnosnog incidenta radi
• datum, točno vrijeme i vremensku zona napada

Incidente možete prijaviti na adresu elektroničke pošte cert@carnet.hr.

Kome prijaviti incident? Incidenti se u pravilu prijavljuju Abuse službama nadležnim za mreže iz kojih napad potiče. Stoga, u slučaju napada na vaše osobno računalo, potrebno je utvrditi mrežu iz koje dolazi napad te incident prijaviti Abuse službi nadležnoj za tu mrežu. Kako nije uvijek jednostavno utvrditi izvor napada, u slučaju nemogućnosti jednostavne identifikacije mreže, prijavu pošaljite Abuse službi svog ISP-a. U slučaju da je do incidenta došlo u vašoj organizaciji, kontaktirajte svog sistem administratora ili administratora resursa. Incident prijavljujete CARNet CERT-u ako vaša prijava nadležnoj Abuse službi nije zaustavila ilegalne mrežne aktivnosti, te postoji potreba za posredovanjem u rješavanju incidenta.

E-mail adrese hrvatskih Abuse službi:

• Amis Telekom - abuse@amis.hr
• B.net - abuse@bnet.hr
• CARNet - abuse@carnet.hr
• Globalnet - abuse@globalnet.hr
• H1 Telekom - abuse@h1telekom.hr
• Iskon - abuse@iskon.hr
• Magic Telekom - abuse@mtnet.hr
• Metronet - abuse@metronet.hr
• Optika kabel TV - abuse@oktv.hr
• Optima Telekom - abuse@optima-telekom.hr
• T - Hrvatski Telekom - abuse@t-com.hr
• TELE2 - abuse@tele2.hr
• VIPnet - abuse@vip.hr
• Voljatel telekomunikacije - abuse@voljatel.hr"

(preuzeto s: https://sigurnost.carnet.hr/sigurnost-carnet/incidenti/)

Nacionalni CERT

Web URL: http://www.cert.hr
Korisnici: Nacionalni CERT nadležan je za cijelu hrvatsku domenu .hr, odnosno za  sve davatelje Internet usluga (ISP) u Republici Hrvatskoj i korisnike koji se ne nalaze carnet.hr domeni i koji nisu tijela državne vlasti.

"Nacionalni CERT osnovan je u skladu sa Zakonom o informacijskoj sigurnosti RH i prema tom zakonu jedna od zadaća je obrada incidenata na Internetu, tj. očuvanje informacijske sigurnosti u RH.Prema Pravilniku o radu Nacionalnog CERT-a, on se bavi incidentom, ako se jedna od strana u incidentu nalazi u RH (odnosno, ako je u .hr domeni ili u hrvatskom IP adresnom prostoru).Nacionalni CERT ima pravo iz područja svoje nadležnosti donositi upute, smjernice, preporuke, savjete i mišljenja.

Misija Nacionalnog CERT-a: Prevencija i zaštita od računalnih ugroza sigurnosti javnih informacijskih sustava u Republici Hrvatskoj.

Ciljevi rada Nacionalnog CERT-a: Nacionalni CERT u okviru svog djelovanja provodi proaktivne i rekativne mjere. Proaktivnim mjerama djeluje prije Incidenta i drugih događaja koji mogu ugroziti sigurnost informacijskih sustava, a u cilju sprečavanja ili ublažavanja mogućih šteta. Informacije o proaktivnim mjerama se javno objavljuju.

Proaktivne mjere podrazumijevaju:

• praćenje stanja na području računalne sigurnosti i objavljivanje sigurnosnih obavijesti u svrhu priprema za sprečavanje šteta
• kontinuirano praćenje računalno-sigurnosnih tehnologija te se sva nova saznanja prikupljaju i diseminiraju
• javno objavljivanje novih informacija u svrhu edukacije najšire javnosti i unapređenju svijesti o značaju računalne sigurnosti
• provođenje detaljne edukativne obuke za specifične grupe korisnika

Reaktivnim mjerama djeluje se na Incidente u Republici Hrvatskoj te druge događaje koji mogu ugroziti računalnu sigurnost javnih informacijskih sustava u Republici Hrvatskoj.Reaktivne mjere podrazumijevaju:

• na osnovu prikupljenih saznanja izrađuju se i distribuiraju sigurnosna upozorenja, javno ili ciljano
• Nacionalni CERT prikuplja, obrađuje i priprema sigurnosne preporuke o slabostima u informacijskim sustavima te ih javno distribuira i arhivira u svom informacijskom sustavu
• koordinacija rješavanja značajnijih Incidenata u koje je uključena barem jedna strana iz Republike Hrvatske

Nacionalni CERT surađuje s relevantnim tijelima (Zavod za sigurnost informacijskih sustava - ZSIS CERT, Ured Vijeća za nacionalnu sigurnost - UVNS, CARNet CERT i Ministarstvo unutarnjih poslova RH), a također i sa stranim CERT-ovima preko članstva u Forum of Incident Response and Security Teams (FIRST) i radne grupe TF-CSIRT.

U djelokrug rada Nacionalnog CERT-a nije uključeno:

• operativno rješavanje problema i briga o sigurnosti pojedinih sustava
• kažnjavanje problematičnih korisnika
• arbitraža u sporovima
• pokretanje krivičnih prijava" (preuzeto s: http://www.cert.hr/onama])

"Kako bi vam Nacionalni CERT bio u mogućnosti pomoći potrebno je da vaša prijava incidenta sadrži osnovni skup podataka nužnih za uspješnu obradu incidenta. Incidente možete prijaviti e-mailom na adresu ncert@cert.hr, a prijava mora sadržavati:

• originalne log datoteke (sa poslužitelja ili mrežnih i sigurnosnih uređaja) iz kojih se vide neželjene mrežne aktivnosti te o kojoj se vrsti incidenta radi
• vaš opis incidenta
• datum, točno vrijeme (po mogućnosti u minutu i sekundu) i vremenska zona
• IP adresa i/ili ime računala koje je napadnuto
• IP adresa i/ili ime računala koje je izvor napada
• ako je uz incident vezan e-mail, URL zloćudne stranice ili nešto drugo, tada je potrebno priložiti i te podatke. E-mail priložite uz prijavu zajedno s cjelokupnim zaglavljem (headerom)."

Po prijavi incidenta dobit ćete odgovor potvrde da je vaša prijava zaprimljena." (preuzeto s: http://www.cert.hr/oincprijavi)

ZSIS CERT

Web URL: http://www.zsis.hr
Korisnici: CERT ZSIS nadležan je za državna tijela, tijela jedinica lokalne i područne (regionalne) samouprave, pravne osobe s javnim ovlastima te pravne i fizičke osobe koje u svom  poslovanju ostvare pristup ili postupaju s klasificiranim i neklasificiranim podacima.

"U slučaju računalno-sigurnosnog incidenta kojeg sami ne mogu ukloniti, tijela mogu preko svog koordinatora za CERT kontaktirati CERT ZSIS-a radi traženja pomoći u rješavanju incidenta.Računalno-sigurnosni incident prijavljuje se ispunjavanjem obrasca za prijavu incidenta u kojem se navode svi podaci potrebni za učinkovito otklanjanje problema. Ispunjeni obrazac šalje se službenom poštom no, obzirom da je za rješavanje incidenata često potrebna žurnost, ispunjeni se obrazac može dostaviti i elektroničkom poštom, ali prije toga mora biti enkriptiran javnim ključem koordinatora za CERT. Obrazac se nalazi na adresi: http://www.zsis.hr/Site/LinkClick.aspx?fileticket=4lPx9I37oOg%3d&tabid=107&mid=459

Po zaprimljenoj prijavi, a ovisno o vrsti i težini incidenta, CERT ZSIS pristupa otklanjanju ili koordinira rješavanje incidenta. Izvješća o računalno-sigurnosnim incidentima, koji su unutar nekog tijela državne vlasti u Republici Hrvatskoj otklonjeni bez pomoći CERT ZSIS-a, dostavljaju se CERT-u ZSIS-a na popunjenom obrascu svakih šest mjeseci." (preuzeto s: http://www.zsis.hr/site/CERTZSISa/Ra%C4%8Dunalnosigurnosniincidenti/tabid/107/Default.aspx)

--Marina Marković 6. siječnja 2012. (CET)

Zanimljivosti

Na stranicama Zaklade otvorene sigurnosti (Open Security Foundation) mogu se pronaži statistički podaci o računalno sigurnosnim incidentima iz cijelog svijeta. Baza podataka izgubljenih podataka (DataLossDB) OSF-a prikuplja informacije o događajima koji uključuju krađu, gubitak ili otkrivanje osobnih identifikacijskih podataka. Grafovi prikazani na slikama ispod preuzeti su sa stranice http://datalossdb.org/statistics gdje se mogu pregledavati statistike po godinama. Sljedeći grafovi se odnose na razdoblje od 2003. godine pa do danas.

Grafikon 1 izvor

Grafikon 2 izvor

Kao što vidimo na grafikonu 1, najveći broj incidenata dogodio se 2008, a zatim slijedi 2011. Grafikon 2 prikazuje tipove incidenata i njihovu učestalost:

• 17% otpada na hakiranje (upad u računalu, s tim da podaci nisu nužno javno objavljeni)
• 16% krađa prijenosnika
• 11% FraudSe = prijevara ili muljaža, socijalni inženjering
• 11% Web = računalni/web upad, podaci su često javno objavljeni
• 8% Disposal_Document = pronalazak dokumenata koji nisu pravilno pohranjeni

Grafikon 3 izvor

Grafikon 4 izvor‎

Na 3. grafikonu vidimo incidente po gospodarskim granama:

• 48% Biz = poduzeća
• 19%Gov = vlada
• 17% Med = medicina
• 16% Edu= akademska (obrazovna) zajednica,

a na 4. grafikonu su prikazani incidenti koji ulkjučuju ove tipove podataka:

• CCN = brojevi kreditnih kartica
• SSN = brojevi zdravstvenog osiguranja
• NAA = ime, prezime
• EMA = e-mail adrese
• MISC = razno
• MED = zdravstveni podaci
• ACC = podaci o računu
• DOB = datum rođenja
• FIN = financijske informacije
• UNK = nepoznato
• PWD = lozinke
• ADD = adrese

Također, na ovim stranicama moguće je pronaći godišnja i mjesečna izvješća o incidentima. Prema godišnjem izvješću za 2011. godinu, dogodilo se 369 incidenata, kojima je pogođeno 126 749 634 zapisa, od čega najviše otpada na poslovne podatke.

--Marina Marković 6. siječnja 2012. (CET)

Usporedba alata za dohvaćanje obrisanih podataka

Kada nastupi faza oporavka od incidenta i saniranje nastale štete, potrebna nam je pomoć alata za dohvaćanje obrisanih podataka, ako je došlo do brisanja. Zbog toga sam se ja odlučila usporediti 3 besplatna alata za dohvaćanje obrisanih podataka. Sve alate sam instalirala na virtualnoj mašini (Windows XP SP3) i kao inicijalni lagani test (test 1), nekoliko datoteka sam obrisala (prvo u Recycle Bin, zatim sam ispraznila i Recycle Bin). Htjela sam provjeriti hoće li ovi alati uspjeti pronaći i vratiti ove datoteke na Slici 9. Za malo teži test (test 2), napravila sam fomat jedne perticije na kojoj je bilo 771 MB podataka (383 datoteke) kako bi provjerila koliko uspješno alati vraćaju izgubljene particije (slika 10)..

Slijede rezultati alata:

• eSupport UndeletePlus dostupno ovdje
• Pandora Recovery dostupno ovdje
• Recuva dostupno ovdje

eSupport UndeletePlus

Na slici 11. vidimo sučelje eSupport UndeletePlus alata. Nažalost, besplatna verzija ne dolazi sa svim opcijama. Naime, moguće je samo skeniranje obrisanih datoteka,ali ne i vraćanje. Sučelje je prilično jednostavno, kao i mogućnosti u opcijama koje su lako razumljive.
Test 1. Na slici 12. su rezultati pretrage datoteka koje su izbrisane iz Recycle Bina. Nažalost, ovaj alat nije pronašao niti jednu od obrisanih. Skeniranje C particije koja je veličine cca 9 GB je trajalo 8 min.
Test 2. Skeniranje formatirane E particije, koja je veličine cca 1 GB je trajalo minutu i 30 sekundi.Rezultati su prikazani na slici 13. Pošto u besplatnoj veriji nije omogućeno vraćanje datoteka, po sloobodnoj procjeni bih rekla da je alat pronašao 2/3 datoteka. Teško je procijeniti jer pronađene datoteke nemaju svoje stare nazive.

Slika 11.

Slika 12.

Slika 13.

Pandora Recovery

Pri pokretanju Pandore automatski vam se pali Wizard koji olakšava rukovanje alatom. Prvo vas upozorava da sve datoteke koje ste odlučili vratiti, ne smijete vraćati na particiju s koje su podaci izgubljeni. Dobar savjet :) Inače postoji mogućnost da će se datoteke koje vraćate prepisati preko izgubljenih datoteka koje još niste vratili. Također će vas pitati da li vam "obrisane" dateteke nisu možda još uvijek u Recycle Binu... :) Ako kažete da nisu, odabirete particiju s koje želite vratiti podatke te vrstu pretraživanja: obično i "surface", koje je mnogo detaljnije. Obično skeniranje ćete odabrati ako tražite konkretnu datoteku kojoj znate ime, datum kreiranja, veličinu i sl. Za malo "ozbiljnije" skeniranje odabirete površinsko skeniranje. Na slici 14. prikazano je sučelje Pandore.
Test 1. Pandora nažalost nije briljirala na ovom testu. Skeniranje C particije je jako dugo trajalo, a pronašla je samo 1 sliku i 2 mp3 datoteke od svih onih obrisanih.
Test 2. Skeniranje E particije je trajalo 5 minuta, pronašla je 447 datoteka veličine 541,7 MB (dakle, nije uspjela pronaći sve) što vidimo na slici 15. Pozitivna stvar je što postoji mogućnost vraćanja datoteka. Te podatke je uspjela vratiti na C particiju u roku 3 min i 37 sekundi što vidimo na slici 16.

Slika 14.

Slika 15.

Slika 16.

Recuva

Pri pokretanju Recuve prvo se pokreće Wizard koji vas pita koju vrstu datoteka tražite (možete odabrati sve), pa će vas pitati gdje sus se nalazile te datoteke (možete odabrati ne znam), te kao zadnji korak možete odabrati želite li dubinsko skeniranje (engl. deep scan) ili ne.Na slici 17. vidimo sučelje alata Recuva koje je dosta jednostavno.
Test 1. Recuva je ovaj test položila s ocjenom izvrstan, uspješno je pronašla sve obrisane datoteke te sam ih uspješno i vratila kao što vidimo na slici 18. Jedina negativna stvar je što su datoteke pod drugim imenom, no to je manje bitno. Skeniranje C particije je trajalo cca 2 minute, a vrijeme potrošeno na vraćanje datoteka praktički zanemarivo.
Test 2. Kao i na 1. testu, i ovdje je Recuva pokazala zavidnu sposobnost u pronalasku i vraćanju izbrisanih datoteka. Particiju je skenirala za cca 1 minutu i pronađeno je cca 1 GB podataka. Kao i kod svih alata pronađene datoteke su obično rangirane u 3 stanja: izvrsno (označene zelenom bojom), loše (narančasto) i nepovrativo (crveno) što vidimo na Slici 19. Vraćanje 1,17 GB podataka trajalo je 445,95 sekundi (7 i pol minuta).Uspješno su vraćene sve datoteke, samo 4 mp3 datoteke nisu bile u izvrsnim stanju jer su bile prepisane nekom drugom datotekom pa nisu vraćene. Nažalost, struktura datoteka i mapa te njihovi nazivi nisu zadržani, tako da nije moguće točno provjeriti koje datoteke nisu vraćene (slika 20.).

Slika 17.

Slika 18.

Slika 19.

Slika 20.

Rezultati

1. Recuva
2. Pandora Recovery
3. eSupport UndeletePlus

S obzirom na količinu pronađenih obrisanih datoteka, mogućnost vraćanja te brzinu tih dviju akcija, lakoću upravljanja, jednostavnost sučelja i ponuđenih ostalih mogućnosti, smatram da je Recuva zaslužila prvo mjesto, Pandora drugo, te eSupport treće, najviše zbog tog jer nije u potpunosti besplatan i nema mogućnost vraćanja pronađenih obrisanih datoteka.

--Marina Marković 6. siječnja 2012. (CET)

Alati za sigurnost društvenih mreža

Bitdefender Safego

Bitdefender Safego jedna je od prvih aplikacija namijenjenih zaštiti korisnika od malwarea i sličnih oblika zlouporabe isključivo na društvenim mrežama. Prvotno je izdana inačica za najpopularniju društvenu mrežu Facebook, a nakon toga i za Twitter. Nakon što korisnik instalira aplikaciju na svojem Facebook ili Twitter profilu, odnosno dopusti aplikaciji pristup određenim podacima sa svojeg profila (listi prijatelja, porukama na Facebook zidu itd.), dobiva mogućnost skeniranja liste svojih prijatelja u potrazi za malicioznim korisnicima (i botovima), kao i malicioznim linkovima unutar komentara, poruka i sl. Aplikacija također nudi mogućnost provjere korisničkog računa prije nego se što se odlučimo dodati vlasnika tog računa kao prijatelja, a moguće je i provjeriti primljene direktne poruke (ako to aplikaciji dopustimo). Aplikacija pritom otkriva i spam poruke kao i pokušaje preotimanja računa. Važna je činjenica da aplikacija u pozadini stalno vrši spomenute provjere te odmah obavještava korisnika u slučaju otkrivanja neke sigurnosne prijetnje. Također postoji i opcija za automatska upozoravanja prijatelja kod kojih aplikacija primijeti zlouporabu računa.

Nakon što se aplikacija instalira na Facebook profilu, potrebno je dopustiti aplikaciji pristup određenim podacima s profila kao što su: osnovne informacije, informacije o profilu, slike, video, informacije koje ostali ljudi dijele s nama te pristup podacima u bilo koje vrijeme, jer aplikacija radi u pozadini i informira o potencijalnim štetnim sadržajima u realnom vremenu. To možemo vidjeti na slici 22.

Neke od ključnih značajki aplikacije su pretraživanje newsfeed-ova i zaraženog sadržaja u realnom vremenu, cijelo vrijeme, zatim „Friend’o’meter“ koji pomaže u zaštititi i koji izgrađuje listu "sigurnih" prijatelja koji također koriste Bitdefender Safego, te integrirani Quickscan, koji provjerava računalo svakih 60 sekundi. Sve te komponente možemo vidjeti na slici 23.

• Bitdefender Safego dostupno ovdje

--Igor.trgovcic 17:30, 6. siječnja 2012. (CET)

Facebook Privacy Scanner

Facebook Privacy Scanner je alat koji skenira postavke privatnosti na Facebooku i prikazuje upozorenja za one postavke koje možda nemaju postavljenu zaštitu pristupa ili za osobne informacije koje su vidljive drugima. Slika 24. prikazuje proces skeniranja.

Kako bi se skener koristio, prvo je potrebno postaviti knjižnu oznaku (bookmark) koja sadrži link za pokretanje alata (na slici je označeno s crvenim pravokutnikom). Bookmark se može preuzeti s web stranice čiji je izvor dostupan na linku dolje. Nakon toga se treba jednostavno prijaviti na Facebook profil i kliknuti na prije spomenuti bookmark. Tada počinje skeniranje i ukoliko su sve komponente privatnosti uspješno postavljene, alat izbaci rezultat da je sve u redu. Stavke koje alat skenira su sljedeće: privatnost foto albuma, personalizacijske postavke, osobne podatke, kontaktne informacije, prijatelje, tagove, informacije o konekciji i dali smo blokirali sve aplikacije preko kojih mogu biti vidljive osobne informacije.

• Facebook Privacy Scanner dostupno ovdje

--Igor.trgovcic 17:27, 6. siječnja 2012. (CET)

Zaključak

Brz i ekeftivan odgovor je najbitnija stvar pri odgovaranju na računalne sigurnosne incidente. Također, korištenje ustanovljenih procedura (uključujući očuvanje dokaza) i obavještavanje organizacija za incidente i / ili zakonodavnih službi pomaže očuvati sustave drugih žrtava ili potencijalnih žrtava. Korištenje najboljih praksi trebalo bi minimizirati štetu računalne mreže od napada te maksimizirati prilike da se nađe izvor napada, spriječiti daljnje napade te pronaći stranke odgovorne za napad. Prije nego se incident dogodi, treba biti upoznat s ustanovljenim procedurama, praksama i dodirnim točkama. .Kako bi znala postaviti odgovarajuće razine zaštite, organizacije trebaju provoditi procjenu rizika. Osim provođenja procjena rizika i poboljšavanja zaštite sustava, organizacije trebaju grupe za rješavanje sigurnosnih incidenata. Mnoge sigurnosne incidente je nemoguće spriječiti jer svakodnevnim razvojem tehnologije i znanosti nastaju i nove vrste incidenata. Zaštitom i osiguravanjem kritičnih dijelova računalne mreže bave se CSIRT organizacije. Postoji nekoliko faza koje su dio postupka za rješavanje incidenta kao što su priprema, otkrivanje i analiza, obuzdavanje / iskorjenjivanje te oporavak. U fazi odgovaranja na incident potrebno je identificirati i procijeniti detalje incidenta, poduzeti korake kako bi minimizirali daljnji nastanak štete. Ne smije doći do oštećenje i napada središnjeg računala, potrebno je snimiti i prikupiti informacije. U svezi s tim, preporuča se napraviti kompletna kopija pogođenih sustava, napraviti bilješke, zadržati zapise i očuvati podatke te osigurati evidentiranje kontinuiranog napada. Što se tiče dijeljenja informacija, za komunikaciju o incidentu ne smiju se koristiti pogođeni sustavi. Potrebno je obavijestiti odgovorne ljude u organizaciji, odgovarajuće organizacije ili CERT-ove kada se dogodi incident. Također, treba procijeniti i odlučiti da li treba obavijestiti žrtve i javnost o incidentu i nastalim šteta, te u skladu s tim je li potrebno obavijestiti i neke pravne ili zakonodavne službe. Zadnji korak je donošenje odluka i poduzimanje akcija kako bi se spriječilo događanje sličnog incidenta. Jedan od najvažnijih, a često i najtežih koraka je izvještavanje o incidentu. Izrađivanje izvješća nam omogućuje procjenjivanje snaga i slabosti organizacije pri odgovaranju na incidente. Kako bi znala postaviti odgovarajuće razine zaštite, organizacije trebaju provoditi procjenu rizika. Osim provođenja procjena rizika i poboljšavanja zaštite sustava, organizacije trebaju grupe za rješavanje sigurnosnih incidenata. Mnoge sigurnosne incidente je nemoguće spriječiti jer svakodnevnim razvojem tehnologije i znanosti nastaju i nove vrste incidenata. Zaštitom i osiguravanjem kritičnih dijelova računalne mreže bave se CSIRT organizacije. Postoji nekoliko faza koje su dio postupka za rješavanje incidenta kao što su priprema, otkrivanje i analiza, obuzdavanje / iskorjenjivanje te oporavak.

--Marina Marković 6. siječnja 2012. (CET)

Literatura

• Best Practices for Network Security, Incident Response, and Reporting to Law Enforcement (2004.) dostupno 5.1.2011. na: of contact/24 8 G8_Best_Practices_Network_Security_en.pdf http://www.coe.int/t/dghl/cooperation/economiccrime/cybercrime/documents/points%20of%20contact/24%208%20G8_Best_Practices_Network_Security_en.pdf
• CARNet CERT, LS&S (2009.): Upravljanje sigurnosnim incidentima, dostupno 5.1.2011. na: http://www.cert.hr/sites/default/files/CCERT-PUBDOC-2009-06-266.pdf
• CARNet CERT, LS&S (2010.):Računalna forenzika, dostupno 5.1.2011. na: http://www.cert.hr/sites/default/files/NCERT-PUBDOC-2010-05-301.pdf
• National Institute of Standards and Technology(2008.): Computer Security Incident Handling Guide, dostupno 5.1.2011. na: http://csrc.nist.gov/publications/nistpubs/800-61-rev1/SP800-61rev1.pdf
• Prosise C., Mandia K. (2003.): Incident response & Computer Forensics, second edition, The McGraw-Hill Companies, Inc.
• http://sigurnost.carnet.hr/, dostupno 5.1.2011.
• http://www.cert.hr/, dostupno 5.1.2011.
• http://www.cert.hr/node/17526 , dostupno 5.1.2011.
• http://www.zsis.hr/, dostupno 5.1.2011.
• http://datalossdb.org/, dostupno 5.1.2011.
• http://undeleteplus.com/, dostupno 5.1.2011.
• http://www.pandorarecovery.com/download/, dostupno 5.1.2011.
• http://www.piriform.com/recuva/builds, dostupno 5.1.2011.
• http://www.reclaimprivacy.org/, dostupno 5.1.2011.
• http://techdows.com/2010/05/fix-facebook-privacy-issues-with-facebook-privacy-scanner.html, dostupno 5.1.2011.
• http://apps.facebook.com/bd-safego/, dostupno 5.1.2011.